FEC前向纠错_由于前向纠错法

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

实时音视频领域UDP才是王道       

       在 Internet 上进行音视频实时互动采用的传输层方案有TCP（如：RTMP）和UDP（如：RTP）两种。TCP协议能为两个端点间的数据传输提供相对可靠的保障，这种保障是通过一个握手机制实现的。当数据传给接收者时，接收者要检查数据的正确性。发送者只有接到接收者的正确性认可才能发送下一个数据块。如果没有接到确认报文，这个数据块就得重传。尽管这种机制对传送数据来说是非常合理的，但当用它在Internet传输实时音视频数据时就会引发很多问题。首先就是延迟问题，在传输信道丢包率较高时，TCP的传输质量下滑严重，重传拥塞导致音视频延时非常大，失去实时互通的意义。特别是无线信道（WIFI、4G、3G）下，使用TCP做双向互通通讯稳定性欠佳，易出现音视频长时间卡住不动然后快放的现象。 

      更多的产品选择采用的协议是UDP（一般上层应用层协议为RTP，以提供序号和音视频同步的服务）。UDP同 TCP 相比能提供更高的吞吐量和较低的延迟，非常适合低延时的音视频互动场合。

UDP传输存在的问题：

UDP性能的提高是以不能保障数据完整性为代价的，它不能对所传数据提供担保，常见的问题有包乱序、包丢失、包重复。无线信道（WIFI、4G、3G）下，UDP包乱序和包丢失可以说是常态。

关于包乱序和包丢失的原因，参考诸多文献总结如下：

乱序原因：

   （A） 路由器的存储队列导致的包乱序。

   （B） UDP包据经过不同的路由造成了发送数据的混乱。 

丢包原因：
   （A） 当路由器和网关发生拥塞时，某些包可能被丢弃，发生这种情况一般是由于网络中传输的数据包大于网络信道的承载能力。
   （B） 分组数据在传送时有生存时间限制以避免路由中死循环的出现，网络状况恶劣时，分组可能超时丢失。
   （C） 接收端工作超载运行时可能因调度困难而不能及时处理网口数据。

       视频码流的少量丢失都会导致解码后的视频出现花屏的现象。H264、HEVC这样的高压缩率视频压缩标准使得压缩的冗余度非常低，码流的丢失除了影响本帧的解码外，还将影响以此为参考的视频帧解码，导致花屏的累积扩散，直至下一个关键帧的到来视频画面方能恢复。虽然解码器内部会做一定的错误掩盖处理，但效果并不理想，特别是采用ffmpeg这类开源的解码器，其错误掩盖算法做得比较简单。为此，在很多产品中不得不采用较小的GOP（较小的I帧间隔），以期在出现丢包花屏后能尽快的用I帧码流刷新画面。这种方法副作用较大，而且某些场合下甚至会适得其反。因为I帧压缩效率远不如P帧、B帧，I帧往往比P帧、B帧大很多，频繁的I帧将给传输信道带来持续的波动压力，造成更严重的丢包、乱序。另外，因为编码器码率控制的缘故，I帧占用较多的码流后，紧接着的P、B帧将不得不采用较大的QP量化参数（较差的图像质量）以保证码率的局部可控，这样带来的直观感受是图像随着I帧间隔周期性的发虚、马赛克。乱序的UDP包不经过顺序恢复直接送解码器同样会导致解码花屏，因为解码器内部会将迟到的数据包丢弃。

       综上所述，工程中急需一种抗丢包、抗乱序的增强型UDP方案来提升实时音视频传输效果，经过多年的积累与完善，我们推出了一套基于RTP并采用FEC前向纠错和后端QOS处理的完整解决方案，效果非常明显。

使用FEC\QOS武装RTP

        对于丢包，我们采用改进型的vandermonde矩阵FEC(Forward Error/Erasure Correction）前向纠错技术来进行丢包恢复，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包。

对于包乱序和包重复，我们采用QOS乱序恢复处理，该QOS方案特点是在没有丢包的情况下，不引入任何系统延时，并且可以通过可控的丢包等待时延来适应不同的信道乱序程度。QOS需要在接收端进行FEC解码前进行，确保送FEC解码模块的数据包序号是正确的（不存在乱序，仅存在丢包）。

众多产品案例表明：采用FEC+QOS+RTP的组合，能显著提升UDP传输的丢包、乱序抵抗力，为上层音视频服务提供有力保障。下图1是各模块在系统中的位置说明。

　　　　　　　　　　　　　　　　图1 FEC、QOS在RTP系统中的位置

需要说明如下几点：

（A）从差错控制角度看，传输信道可以分为随机信道、突发信道和混合信道。在随机信道中，丢包出现是随机的，且相互统计独立，满足正态分布。在突发信道中，丢包是集中出现的，在一些短促的时间区间会出现大量的丢包，而在这些时间区间之外又存在较长的无丢包区间。混合信道则是上述二者的合体。本方案侧重于对具备随机信道特性的传输链路进行改进优化。

       对 Internet信道的丢包特性研究发现，大多数情况下其满足随机信道的特点，丢失的都是单个包。连续两个或以上包同时丢失的概率虽然比纯随机过程要高，但发生的概率还是要比单包丢失低，发生连续丢失10个以上包的概率就更低了。由于单包丢失出现的最频繁，我们的抗丢包方案主要侧重于对单包丢失的修复，同时也应该兼顾连续丢失的少量包的修复。对大量连续丢失的包的修复相对来说就显得不那么重要了（出现概率低，修复的代价大）。

（B）当然，任何差错控制方案都是有其最大纠错能力限制，当丢包率超出当前系统的纠错能力时，丢包无法恢复，对于视频应用来说意味着视频将出现花屏。

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

测试效果

本方案为C++开发，提供PC、Android（JNI）、IOS跨平台的支持。为了方便测试，我们在PC下开发了几个简易测试DEMO用于验证演示。

（A）数据验证DEMO

下图所示为数据验证DEMO界面，它以指定的数据作为测试源，可帮助用户更好的理解处理流程。

                                                         　　　图2  数据流程验证DEMO

       测试工具为点对点工作模式，可在两台PC上各自运行（同时也支持单机模式，只需将收发IP地址均设置为本地IP即可），以实现双方之间RTP（FEC+QOS）通讯。

       软件收发自定义的测试包数据，提供了模拟丢包功能，支持按固定间隔丢包或者按随机比率丢包；支持设置FEC冗余度或者选择冗余度自适应，支持设置QOS丢包等待时延等参数。

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

图3 Wireshark观察冗余包情况

需要说明的是：程序主动丢包是在UDP发送层进行，所以即可能丢媒体包也可能丢冗余包。

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

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

       当选择每5个包丢弃1个包时（丢包率20%），丢包情况如下图4所示：

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

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

　　　　　　　　　　　图5  20%冗余度时，每5个包丢弃1个包时的恢复情况

（B）音视频实测DEMO

　　　　　　　　　　　　　　　　　　　图6 音视频实测DEMO

本DEMO支持如下特性：

（1）使用Direct进行摄像头、麦克风的采集和输出

（2）使用ffmpeg进行高效图像缩放等前置filter

（3）视频H264 HighProfile编码、解码

（4）音频AAC-LC、AAC-LD、AAC-ELD编码、解码（三种标准可选，44.1KHZ 16bit 2通道立体声）

（5）音视频RTP传输（带FEC\QOS功能）

（6）人为丢包测试功能

（7）实时统计输出线路丢包延时情况

DEMO的内部框架如下图7所示：

　　　　　　　　　　　　　　图7  DEMO内部线程框架

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

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

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

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

注意：真实的视频对比效果请跳转视频对比效果 观看

　　　　　　　
  　　　　　　　　图8 使用4%随机丢包，关闭FEC时经常性花屏，声音间歇断续

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

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

　　　　　　　　 图7 使用16.67%恒定丢包，FEC使用20%冗余度时音视频效果良好

转自：http://blog.csdn.net/mediapro/article/details/50393685