分类目录归档:文档

【原创】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%冗余度无失真恢复

 

【原创】FEC/QOS 数据测试型DEMO——–QOS功能验证

本DEMO的另一项测试功能是针对QOS来的,通过分析收发包延时结果,我们可以进一步了解丢包对系统延时的影响。在发送的媒体包时,我们在其负载中加入了系统当前时间,通过记录回环后的媒体包的接收时间(以应用层接收为准,即经过了QOS、FEC解码处理后)来计算该媒体包的来回总时长。

首先,我们选择不丢包,其他参数配置情况:冗余度20%(Group中10个媒体包配2个冗余包),两个媒体包之间的发送间隔为60ms,得到的媒体包“收发延时”情况如下图1所示。

图1 不丢包时,媒体包收发延时情况

因为媒体包为本地回环且无丢包发生,QOS、FEC均未做任何处理,延时非常低。可见与缓存一段时间数据再排序的QOS算法相比,本方案的QOS算法在没有丢包时将不会引入任何延时。

当我们选择每10个包丢弃一个时,时延情况如下图2所示:

图2 每10个包丢弃1个时,媒体包收发时延情况

下面我们来解释这一现象。每10个包丢弃1包时的情况如下图3所示:

图3  每10个包丢弃1个的情况示意

在QOS阶段,0号媒体包丢失,接下来收到的1号媒体包不能直接输出给后续FEC环节,需要等待最多200ms(QOS丢包延时设置为200ms),若仍然未收到0号媒体包则直接输出1号媒体包以及收到的后续媒体包。同样,当收到1号冗余包时也需要等待200ms方能输出。

在FEC阶段,当收到1~9号媒体包时因发现存在丢包而不直接输出给上层应用,直到收到1号冗余包时具备了FEC恢复的条件(收到媒体包数+收到冗余包数>=GROUP媒体包数),恢复0号媒体包并输出0~9号媒体包给上层应用。这样计算来0号媒体包被恢复输出总计需要800ms以上(60ms收到1号媒体包+8*60ms收到2~9号媒体包+2*60ms收到1号冗余包+1号冗余包在QOS环节等待200ms)。

当18号媒体包的丢失,19号媒体包会在QOS环节等待200ms,此时间段内会陆续收到冗余包0和冗余包1,200ms后仍然未等到18号媒体包的到来则直接输出到FEC恢复环节实现恢复。这样计算来18号媒体包被恢复输出总计需要约200ms。

由上例可见,当GROUP比较大时,若丢包发生在GROUP的前部,QOS环节的处理将影响后续包的时延指标。同时,前部丢失的媒体包不得不等待较长时间,直至尾部的冗余包到来方能恢复,造成延时进一步增大。下面我们比较GROUP SIZE为5时的情况。

图4  GroupSize为5时,每10个包丢1个的情况

可见采用较小的FEC GROUP可以改善丢包延时情况。

【原创】FEC/QOS 数据测试型DEMO——–FEC功能验证

本方案为C++开发,提供PC、Android(JNI)、IOS跨平台的支持,为了方便测试,在PC下开发了一个简易测试DEMO如下图1所示,该DEMO主要用于验证功能,能直观的展示所有收发包数据。

 

图1  FEC/QOS 数据测试型DEMO界面

测试工具为点对点工作模式,可在两台PC上各自运行(同时也支持单机模式,只需将收发IP地址均设置为本地IP即可),以实现双方之间RTP(FEC+QOS)通讯。软件收发自定义的测试包数据,提供了模拟丢包功能,支持按固定间隔丢包或者按随机比率丢包;支持设置FEC冗余度或者选择冗余度自适应,支持设置QOS丢包等待时延等参数。

测试工具内部默认使用10个媒体包外加冗余度(数量由选择的冗余度决定)作为一个GROUP,当选择冗余度20%时,一个GROUP由10个媒体包附加2个冗余包组成。下图是Wireshark的观察情况,10个媒体包后面紧接着2个冗余包。

图2  Wireshark截包观察GROUP组成

需要说明的是:程序主动丢包是在UDP发送层进行,所以即可能丢媒体包也可能丢

冗余包。下面我们以20%冗余度为例说明系统对各类丢包率的抵抗能力。

当选择每10个包丢1个包时(丢包率10%),一个GROUP中最多只会丢弃1个包,20%的冗余度足够抵抗这一丢包率,测试结果也验证了这一结论,接收到的所有媒体包序号均保持连续,丢包率从10%降为0%,实验情况如上图1所示。

当选择每5个包丢弃1个包时(丢包率20%),丢包情况如下所示:

图3  每5个包丢弃1包时的情况

对于第一个GROUP,一共丢弃了三个包,包括0号媒体包、5号媒体包、0号冗余包。因为接收的媒体包数为8个加接收的冗余包数1个,总数小于总媒体包数(10个),因此接收端FEC无法恢复。对于第二个GROUP,只丢失了两个媒体包,可以正常恢复。下图4的实验结果也说明了推断的正确性,0号媒体包、5号媒体包丢失,13号、18号媒体包被成功恢复,系统丢包率从20%降低到10%左右。

图4  经过FEC恢复后的数据包情况

当选择每4个包丢弃1个包时(丢包率25%),一个GROUP中将丢弃3个数据包,必然不满足FEC恢复条件,无法恢复,此时将原样输出收到的数据包,入下图5所示:

图5  丢包率过高无法恢复的情况

需要说明的是:丢包是针对传输层数据包(媒体包和冗余包)进行的,DEMO软件中只显示媒体包部分,没有显示冗余包。“下行丢包率”参数是统计的传输层数据包的丢失率,而“下行丢包率(经过丢包恢复)”是统计的应用层媒体包的丢失率,所以会出现后者比前者还高的情况。

当系统丢包率达到FEC特定冗余度的理论极限时,丢包将无法恢复,此时唯有加大冗余度才能实现恢复功能。实际应用时,应该对线路的网络丢包情况做一定统计分析,以确定最佳的冗余度方案,这个往往是比较困难和繁琐的,为此我们推出的自动冗余度方案,从一定程度上解决了这个问题。

若定义“无失真抗丢包能力”为可百分百无失真恢复丢失的媒体包的能力。下表是各冗余度下,传输层“无失真抗丢包能力”的估算情况:

是不是10个冗余包配2个冗余包时,信道丢包率只要低于16.67%就肯定可以无失真恢复呢?这个不一定,因为丢包的分布情况是随机的,比如100个包里丢10个包,10个包是连续丢还是随机均匀丢对FEC恢复来说是完全不同的。FEC并不能解决所有丢包问题,但可以显著提升系统的抗丢包能力。

【原创】RTP抗丢包方案概述

           对于UDP丢包,我们采用改进型的vandermonde矩阵FEC (Forward Error /Erasure Correction)前向纠错技术来进行丢包恢复,由发送方进行FEC编码引入冗余包,接收方进行FEC解码并恢复丢失的数据包。对于包乱序和包重复,我们采用QOS乱序恢复处理,该QOS方案特点是在没有丢包的情况下,不引入任何系统延时,并且可以通过可控的丢包等待时延来适应不同的信道乱序程度。QOS需要在接收端进行FEC解码前进行,确保送FEC解码模块的数据包序号是正确的(不存在乱序,仅存在丢包)。众多产品案例表明:采用FEC+QOS+RTP的组合,能显著提升UDP传输的丢包、乱序抵抗力,为上层音视频服务提供有力保障。下图1是各模块在系统中的位置说明。

需要说明如下几点:

(1)从差错控制角度看,传输信道可以分为随机信道、突发信道和混合信道。在随机信道中,丢包出现是随机的,且相互统计独立,满足正态分布。在突发信道中,丢包是集中出现的,在一些短促的时间区间会出现大量的丢包,而在这些时间区间之外又存在较长的无丢包区间。混合信道则是上述二者的合体。本方案侧重于对具备随机信道特性的传输链路进行改进优化。互联网丢包、乱序现象的出现很难预知,人们对 Internet信道的丢包特性研究发现,大多数情况下其满足随机信道的特点,丢失的都是单个包。连续两个或以上包同时丢失的概率虽然比纯随机过程要高,但发生的概率还是要比单包丢失低,发生连续丢失10个以上包的概率就更低了。由于单包丢失出现的最频繁,我们的抗丢包方案主要侧重于对单包丢失的修复,同时也应该兼顾连续丢失的少量包的修复。对大量连续丢失的包的修复相对来说就显得不那么重要了(出现概率低,修复的代价大)。

(2)当然,任何差错控制方案都是有其最大纠错能力限制,当丢包率超出当前系统的纠错能力时,丢包无法恢复,对于视频应用来说意味着视频将出现花屏。为了改善系统在高丢包率下的用户体验,避免长时间花屏无法刷新的现象,我们建议使用者采用ARQ(自动请求重发)+FEC机制,这里的ARQ请求并不是请求远端重发丢失的数据包,因为那样相当于走了TCP这类内嵌ARQ功能协议的老路,必然引入不可控的延时。这里的ARQ只是请求远端即刻编码视频关键帧,避免长时间花屏无法刷新的现象,ARQ请求一般通过额外的TCP信道发出(在绝大多数的系统中,通讯双方一般会有TCP的信令通道,用于双方业务层信令的交互)。ARQ的发起是根据FEC解码输出视频码流是否丢包作为判断依据,发送端和接收端都需要对ARQ的频率做一定的保护措施,避免频繁的发起和响应,造成过多的I帧(过多I帧的副作用前面已有列举)。