【原创】FEC/QOS 音视频实测DEMO

FEC/QOS 音视频实测DEMO将以实际音视频作为测试对象,真实反映本方案给多媒体系统抗丢包能力带来的提升。DEMO界面如下图1所示:

图1   FEC/QOS 音视频实测DEMO界面

本DEMO支持如下特性:

  • 使用Direct进行摄像头、麦克风的采集和输出
  • 使用ffmpeg进行高效图像缩放等前置filter
  • 视频H264 HighProfile编码、解码
  • 音频AAC-LC、AAC-LD、AAC-ELD编码、解码(三种标准可选,44.1KHZ 16bit 2通道立体声)
  • 音视频RTP传输(带FEC\QOS功能)
  • 人为丢包测试功能
  • 实时统计输出线路丢包延时情况

DEMO的内部框架如下图所示:

图2   DEMO的内部框架

在视频采集缩放线程与视频编码线程之间,我们采用高效的双队列机制(队列元素为指针,进出队列无数据拷贝),如果视频编码性能非常充足的情况下,我们也可以将二者合并为一个线程。编码线程与网络发送线程分离,避免网络拥塞影响编码线程(这个对于UDP来说不成立,但对于RTMP这类TCP系统来说,网络收发线程与音视频编解码线程的分离是必须的,因为网络的抖动将影响音视频处理环节。站在系统设计的角度,我们为UDP和TCP统一使用上述架构)。

在音视频发送模块内,我们都配有定时握手包发送线程,这个线程与音视频使用相同的发送通道(端口),仅在包头上予以区别。它的作用非常重要,主要包括两个方面:为NAT穿越提供保障,当我们的客户端(内网IP)向服务器(公网IP)发送数据时,链路路由器会为该通讯链路映射“端口”,这样服务器(公网IP)向该客户端发送数据时,只需将收到的数据包的IP地址和端口翻转作为发送目标IP和端口便能向其发送数据。路由器在收到服务器的数据包时,检查本地存在对应的映射“端口”,予以放行,否则将丢弃这一数据包(这是基于安全的考虑,外网向内网发送数据不得不防)。值得注意的是,路由器上“端口”是有时效性的,超过一定时间即会失效,为了保证服务器能持续有效的向客户端发送数据,客户端必须以心跳包的方式向服务器发送数据以保持“端口”的有效性(客户端根据业务情况不一定向服务器持续发送数据包,可能只作为接收者)。以上是对C/S模式下NAT的简要描述,P2P模式等其他情况请参考专门的资料。定时握手包的另一个作用是传输自定义的信道统计数据,这个类似于RTCP协议,接收方统计出下行丢包率后可以通过本握手包告知发送方,以便通知对方调整发送甚至编码策略。

音频的处理流程与视频类似,因为音频编码耗时非常低,我们一般将音频采集与编码放到一个线程内进行。音频的输出与视频不同,因为它需要按固定的输出频率工作,驱动将发起定时输出线程,我们只需要在该线程内向指定内存存入指定数量的PCM数据即可。(输出频率、存放数量由音频输出通道数、采样率、采样点字节数的配置而定)

若本地IP与远端IP设置一样,则进入本地回环模式,此时将不存在任何网络丢包,我们可以通过设置手动丢包来模拟测试。若本地IP与远端IP不同,且不属于同一网段,我们可以使用开源的WANEM来进行模拟丢包、延时、抖动、重复包等情况,这一方式后面我们将专门予以介绍。

图3    随机4%丢包,不使用FEC时的情况

当使用4%随机丢包时,若关闭发端FEC功能,接收端视频将出现经常性花屏,声音出现丢失断续。若使用20%冗余度,视频花屏概率将大幅降低(不会完全消除,因为丢包是随机的,短时间内可能出现连续大量丢包的情况,超过20%冗余度的无失真抗丢包率是16.67%即会出现花屏)

若使用按间隔丢包,每6个包丢一个(丢包率将恒定为16.67%),此时选择20%冗余度可以实现无失真恢复,视频流畅无花屏,音质良好无断续。

图4    每6个包丢1个包(16.67%丢包),20%冗余度无失真恢复

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注