webrtc QOS方法二（FEC原理）
一、概述
webrtc冗余打包方式有三种：Red（rfc2198）、Ulpfec（rfc5109）、Flexfec（草案）。其中Red和Ulpfec要成对使用。
二、RedFEC
简单将老报文打包到新包上。如下图所示，冗余度为1时，RFC2198打包情况：
这种方法在实际应用中几乎不怎么用，因为冗余包只能保护特定一个报文，这种方法带宽占用量很大，恢复能力有限，性价比很低。webrtc里面说使用了RFC2198冗余，实际上仅仅是借用该协议的封装格式，封装FEC冗余报文。
三、UlpFEC
将一组M个报文进行异或，生成N（N就是FEC的冗余度）个FEC报文，打包出去。这组报文任意丢其中的N个，都可以通过这组(M-N)个报文+FEC冗余包恢复回来，比简单的RFC2198保护的范围扩大了很多。例如下面示意图：D为媒体包，R为冗余包，该图所示的冗余度为2。
1、发送端打包示意图
2、网络丢包示意图
3、丢包恢复示意图
若UlpFEC异或所有报文，带宽占用量也比较大，在实际应用会根据网络情况进行适当取舍。webrtc通过PacketMaskTable表格在选取需要异或的报文。PacketMaskTable表格有连续丢包（kFecMaskBursty、kPacketMaskBurstyTbl）、随机丢包（kFecMaskRandom、kPacketMaskRandomTbl）两种模型。
理论上webrtc可以通过损失程度和乱序情况相关的反馈，自适应选择kFecMaskRandom还是kFecMaskBursty，效果比较好。但是可惜的是，webrtc这块功能缺失，默认使用随机丢包模型。
四、FlexFEC
同UlpFEC实现方式，ULPFEC仅在1D行数组上进行异或，FlexFec更灵活，引进了交织算法，可以在1D行、列、2D数组异或。
1、1D行异或
2、1D列异或
3、2D行列异或
这块还是草案，如何选择异或模式的代码看没深入下去。后续补充。
五、FEC算法汇总
FEC是无线传输领域的一个前向纠错的算法。网上搜资料的时候经常把无线的算法看的云里雾里的，研究半天都不知道这个和视频传输有什么关系。
无线传输领域的FEC算法主要有TURBO、LDPC、POLAR这三种。
音视频传输领域的FEC算法有如下几种：
1、webrtc的opus音频使用的是inband FEC
2、webrtc的视频ulpfec使用的是异或XOR
3、webrtc的视频flexfec使用的是交织编码。
六、webrtc代码分析
1）使能FEC
webrtc默认使能Red+Ulp的FEC。Flex仅在实验阶段，还不能正式使用。
2）封装FEC
- 发送冗余报文处理
RTPSenderVideo::SendVideo。当编码器支持时间分层，可以仅冗余level 0的视频数据。否则，就要冗余所有视频数据。冗余度是根据丢包率动态调整。
- 冗余报文个数确定
ForwardErrorCorrection::NumFecPackets 存储媒体报文数*保护因子。
- 根据丢包率动态调整冗余度
VCMFecMethod::ProtectionFactor
参考
https://webrtcglossary.com/red/
https://webrtcglossary.com/ulpfec/
https://www.cnblogs.com/x_wukong/p/8193290.html
https://blog.csdn.net/u010178611/article/details/82656838