【实时音视频传输/流媒体通信】FEC前向纠错的原理和实现

TCP协议的重传机制对实时音视频传输而言，如果网络质量很差，丢包率很高，重传机制导致传输延迟急剧增加，传输质量严重下滑。实时音视频传输协议一般采用UDP（应用层基于UDP的RTP协议，为视频传输提供序号和音视频同步服务），UDP具有高吞吐和低延时的特点。然而，基于UDP的RTP传输在复杂的公网环境下，特别是3G、4G、WIFI网络时面临丢包、乱序、重复、抖动等问题，严重影响实时音视频的传输效果。应用层的 FEC （Forward Error Correction，前向纠错）是一项有效防止丢包的技术，是一种实时视频传输的有效可靠的解决方案。

---

差错控制技术

FEC是一种在单向通信系统中控制传输错误的技术，通过连同数据发送额外的信息进行错误恢复，以降低比特误码率。发送方将要发送的数据加上一定的冗余纠错码一起发送，接收方则根据纠错码对接收到的数据进行差错检测，如发现差错，则由接收方进行纠错。FEC又分为带内FEC和带外FEC。FEC是通过添加冗余信息的传输采用预先确定的算法。1949年汉明（Hamming）提出了可纠正单个随机差错的汉明码。1960年Hoopueghem、Bose和Chaudhum发明了BCH码，Reed与Solomon提出ReedSolomon（RS）编码，纠错能力很强，后来称之为里德-所罗门误码校正编码（The reed-solomon error correction code，即后来的附加的前向纠错）。ITU-T G.975/G.709规定了“带外FEC”是在SDH层下面增加一FEC层，专门处理FEC的问题。带外FEC编码冗余度大，纠错能力较强。FEC有别于ARQ，发现错误无须通知发送方重发。一旦系统丢失了原始的数据包，FEC机制可以以冗余报文加以补入。例如有一数据包为“10”，分成二个报文，分别为“1”和“0”，有一冗余报文“0”，收到任意两个报文就能组装出原始的包。但这些冗余报文也会产生额外负担。（摘自维基百科）

ARQ（Automatic Repeat-reQuest，自动重传请求），是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议，拥有错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

---

调研在音视频传输中应用FEC

FEC前向纠错技术广泛应用于信息处理的各个领域，各种纠错码，如汉明码、BCH码、Reed-Solomon（RS）码、卷积码、Turbo码、低密度奇偶校验码（Low Density Parity check codes，LDPC），这些纠错码一般多用于底层协议（如数据链路层），进行以比特串为单位的纠错。

实际项目开发中，无需关注数据链路层的底层协议，但可以在应用层采用FEC，以每个packet为单位进行丢包检测和恢复。因为UDP协议能够保证包内数据的正确性，所以无需考虑包内纠错情况。我们可以利用FEC，对UDP包进行丢包恢复。

我们在RTP协议的自定义字段上扩展出FEC包组头（Group head），一个组（group）是一个完整的相互独立的FEC处理单元，它由k个媒体包和r个冗余包组成，组内的每个包都拥有组号，根据组号的连续性来判断该组是否丢失数据包，选择性地进行恢复，如果冗余包丢失则不用恢复。FEC编码冗余度被定义为冗余包个数r和原始媒体包数k的比值，冗余度越高，说明抗丢包能力越强，但传输效率也会相应降低，因此FEC算法是一种传输效率和抗丢包能力的折中考虑。丢包恢复的条件：收到的媒体包数+收到的冗余包数>=group原始媒体包数，只要满足以上条件，即可恢复丢包。当网络没有丢包时，FEC模块不会引入时延，当网络出现丢包时，必须等待一个group的包全部到达，并恢复出丢失的包后再上传给应用层，因此会造成一定的延时。

整个传输流程如下：发送端对采集到的音频数据首先进行视频h264编码，然后FEC编码引入冗余包，最后打包成RTP发送出去，接收方进行FEC解码，恢复丢失的数据包。此外，对于包的乱序和抖动问题，利用接收端的QOS策略(抖动缓冲，解决UDP包乱序、包重复等问题)，通过map排序和设置等待时延来恢复包的乱序、解决网络抖动问题，以适应不同信道状态下的视频传输。通过以上策略，旨在找出一个合理的方案，提升UDP传输的丢包、乱序问题，为实时视频的传输提供有力的保障。

---

FEC : partiy，Reed-Solomonz， Hamming，LDPC，XOR

1. parity，Reed-Solomon， Hamming codes,
这三种FEC算法都需要额外的协议支持，不是RTP格式里涵盖的标注，已经废弃的RFC2733(XOR算法)和RFC3009中曾有定义

2. RFC 5109(XOR算法)定义了ULPFEC和FLEXFEC，和RTP协议定义一起实现
3. RFC 6105 RTP Payload Format for 1-D Interleaved Parity
4. RFC 6682 Raptor FEC, 喷泉编码
5. RFC 6865 Reed-Solomon FEC

源码

WebRTC版本中实现了FLEXFEC

OPENFEC开源项目（http://openfec.org/accueil.html）：LDPC-Staircase codec、Reed-Solomon GF(256) codec、2D parity codec、LDPC from file codec

feclib （http://feclib.sourceforge.net/）可以通过冗余包找到丢失的数据包，但无法找到数据包内部错误

RSCODE（ http://rscode.sourceforge.net/）可以纠正数据包内部错误