本文主要是介绍FEC改善UDP（RTP）传输音视频的问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 FEC概念
前向纠错也叫前向纠错码(Forward Error Correction，简称FEC)，是增加数据通讯可信度的方法。在单向通讯信道中，一旦错误被发现，其接收器将无权再请求传输。前向纠错编码（FEC）技术通过在传输码列中加入冗余纠错码，在一定条件下，通过解码可以自动纠正传输误码，降低接收信号的误码率（BER）。FEC 是利用数据进行传输冗余信息的方法，当传输中出现错误，将允许接收器再建数据。其基本原理是：在发送端，通过将k bit信息作为一个分组进行编码，加入（n-k）bit的冗余校验信息，组成长度为nbit的码字。码字经过信道到达接收端之后，如果错误在可纠范围之内，通过译码即可检查并纠正错误bit，从而抵抗信道带来的干扰，提高通信系统的可靠性。
2实时音视频UDP传输
在Internet上进行音视频实时互动采用的传输层方案有TCP（如：RTMP）和UDP（如：RTP）两种。
TCP协议能为两个端点间的数据传输提供相对可靠的保障，这种保障是通过一个握手机制实现的。当数据传给接收者时，接收者要检查数据的正确性。发送者只有接到接收者的正确性认可才能发送下一个数据块。如果没有接到确认报文，这个数据块就得重传。尽管这种机制对传送数据来说是非常合理的，但当用它在Internet传输实时音视频数据时就会引发很多问题。首先就是延迟问题，在传输信道丢包率较高时，TCP的传输质量下滑严重，重传拥塞导致音视频延时非常大，失去实时互通的意义。特别是无线信道（WIFI、4G、3G）下，使用TCP做双向互通通讯稳定性欠佳，易出现音视频长时间卡住不动然后快放的现象。 更多的产品选择采用的协议是UDP（一般上层应用层协议为RTP，以提供序号和音视频同步的服务）。
UDP同TCP相比能提供更高的吞吐量和较低的延迟，非常适合低延时的音视频互动场合。
2.1 UDP传输存在的问题
UDP性能的提高是以不能保障数据完整性为代价的，它不能对所传数据提供担保，常见的问题有包乱序、包丢失、包重复。无线信道（WIFI、4G、3G）下，UDP包乱序和包丢失可以说是常态。
乱序原因：
（1）路由器的存储队列导致的包乱序。
（2）UDP包据经过不同的路由造成了发送数据的混乱。
丢包原因：
（1） 当路由器和网关发生拥塞时，某些包可能被丢弃，发生这种情况一般是由于网络中传输的数据包大于网络信道的承载能力。
（2） 分组数据在传送时有生存时间限制以避免路由中死循环的出现，网络状况恶劣时，分组可能超时丢失。
（3） 接收端工作超载运行时可能因调度困难而不能及时处理网口数据。
视频码流的少量丢失都会导致解码后的视频出现花屏的现象。H264、HEVC这样的高压缩率视频压缩标准使得压缩的冗余度非常低，码流的丢失除了影响本帧的解码外，还将影响以此为参考的视频帧解码，导致花屏的累积扩散，直至下一个关键帧的到来视频画面方能恢复。虽然解码器内部会做一定的错误掩盖处理，但效果并不理想，特别是采用ffmpeg这类开源的解码器，其错误掩盖算法做得比较简单。为此，在很多产品中不得不采用较小的GOP（较小的I帧间隔），以期在出现丢包花屏后能尽快的用I帧码流刷新画面。这种方法副作用较大，而且某些场合下甚至会适得其反。因为I帧压缩效率远不如P帧、B帧，I帧往往比P帧、B帧大很多，频繁的I帧将给传输信道带来持续的波动压力，造成更严重的丢包、乱序。另外，因为编码器码率控制的缘故，I帧占用较多的码流后，紧接着的P、B帧将不得不采用较大的QP量化参数（较差的图像质量）以保证码率的局部可控，这样带来的直观感受是图像随着I帧间隔周期性的发虚、马赛克。乱序的UDP包不经过顺序恢复直接送解码器同样会导致解码花屏，因为解码器内部会将迟到的数据包丢弃。
综上所述，工程中急需一种抗丢包、抗乱序的增强型UDP方案来提升实时音视频传输效果，目前基于RTP并采用FEC前向纠错和后端QOS处理的完整解决方案，效果非常明显。
3 FEC/QOS
对于丢包，我们采用改进型的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帧。
这篇关于FEC改善UDP（RTP）传输音视频的问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
