FEC原理及其实现

视频会议中通常使用的FEC/QOS技术，这方面的资料比较复杂和稀少，根据这么多年的工作经验，做一下分享。

 在IP视频通话中丢包造成的影响多种多样。其中对视频质量的影响主要有：马赛克现象、局部变形(图像的某些区域不清晰)、图像模糊、屏幕频繁刷新或闪烁、视音频不同步、帧率下降、图像静止等等。对音频质量的影响包括：总体音频失真、间断或间歇性噪音、音频中断等。而对内容和演示数据质量的影响则包括：幻灯片模糊变形、翻页速度减慢或屏幕频繁刷新和图像静止等等。另外，丢包还会引起过度延迟，甚至是通话中断。
       IP视频通话中丢包造成的影响程度主要由丢包率、丢包随时间变化情况和视频通话中各个终端和设备的能力所决定。正如我们通常认为的那样，丢包率越高，对视频通话的影响也更为明显。

一：差错控制技术

1. ARQ  ：是一种按需重传的机制，发送者通过接受者的反馈得知有报文在传输过程中有丢失，就重传该报文。

缺点：通信信道的利用率不高，也就是说信道还远远没有被数据流占满，需要接收方发送ACK，这样影响传输效率。可以想象，这种方式发送方肯定需要一个buffer来存储获取到的数据。重复发送数据包也会影响传输速度。可以称之为后向纠错。

2. FEC ：是一种前向性纠错技术，发送方将要发送的数据加上一定的冗余纠错码一起发送，接收方则根据纠错码对接收到的数据进行差错检测，如发现差错，则由接收方进行纠错。

特点：使用纠错码，单信道通信，发送方无需设置缓存。

二：FEC

在计算机通信中主要有丢失和错误两种差错。错误的原因是某些比特数据发生畸变；丢失的原因是某些数据包没有收到。底层协议通常需要考虑这两种情况，如链路层的FEC使用差错校正码对既有丢包又有错误码的情况依然能重建正确的数据。它通常由硬件来实现，采用RS编码，汉明码等。

传输差错反映到通讯高层只是数据包的丢失。因此工作在传输层或者应用层的FEC可通过丢失矫正码和已知包数来处理丢失情况。

纯的FEC技术不必重传数据，但是编解码增加了计算的开销和复杂性，用处理能力和带宽来换取可靠性和较小的回复延迟，在丢包率较高的情况下，性能明显下降，整体性能取决于丢失最严重的接收者。

三、目前基本看到的FEC编码算法的有parity, Reed-Solomon, Hamming, LDPC, XOR


Current FEC standards lack sufficient flexibility to be
usable for many use cases, including RTCWEB:
目前FEC标准中针对很多应用情况，都缺乏足够的伸缩性，包括先前的webRTC版本
===============================
1. parity, Reed-Solomon, and Hamming codes,
都需要额外的协议支持，也不是RTP格式里涵盖的标注，已经废弃的RFC2733(XOR算法)和RFC3009中定义了一套此协议。
2. 最新的RFC5109(XOR算法)定义了ULPFEC，这个是和RTP协议定义实现的。
3. RFC6105 RTP Payload Format for 1-D Interleaved Parity。
4. RFC 6682 Raptor FEC, 所谓的喷泉编码
5. RFC 6865 Reed-Solomon FEC


1、最新的WebRTC版本中有实现了FLEXFEC
===============================
RFC5109中定义的ULPFEC以及FLEXFEC

2、有一个OPENFEC开源项目如下编码实现    http://openfec.org/accueil.html
===============================
LDPC-Staircase codec
Reed-Solomon GF(256) codec
2D parity codec

LDPC from file codec

3、更加小巧的feclib http://feclib.sourceforge.net/

===============================

    该算法也是开源的，但是代码量比较小，只需在工程中添加其相关的几个代码文件即可；

不过该算法不能纠正数据包内部的错误，直接通过冗余包找到丢失的数据包；如果需要纠正数据包内部的错误，其官网推荐了另外一个算法RSCODE http://rscode.sourceforge.net/