webrtc冗余打包方式有三种:Red(rfc2198)、Ulpfec(rfc5109)、Flexfec(草案)。其中Red和Ulpfec要成对使用。
参考:RED (REDundant coding) - WebRTC Glossary
RFC 2198 - RTP Payload for Redundant Audio Data
简单将老报文打包到新包上。如下图所示,冗余度为1时,RFC2198打包情况:
这种方法在音视频领域几乎不使用,因为冗余包只能保护特定一个报文,这种方法带宽占用量很大,恢复能力有限,性价比很低。只是早期的T38传真、RFC2833收号会使用该协议,因为传真和收号的数据量比较小。
webrtc里面说使用了RFC2198冗余,实际上仅仅是借用该协议的封装格式,封装FEC冗余报文。
参考:ULPFEC (Uneven Level Protection Forward Error Correction) - WebRTC Glossary
RFC 5109 - RTP Payload Format for Generic Forward Error Correction
详细参考:
将一组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这块功能缺失,默认使用随机丢包模型。
同UlpFEC实现方式,ULPFEC仅在1D行数组上进行异或,FlexFec更灵活,引进了交织算法,可以在1D行、列、2D数组异或。
3)2D行列异或
需要注意,开启FlexFEC需要同时使能 WebRTC-FlexFEC-03/Enabled && WebRTC-FlexFEC-03-Advertised/Enabled 否则会出现死机异常
这块还是草案,如何选择异或模式的代码看没深入下去。后续补充。
FEC是无线传输领域的一个前向纠错的算法。无线传输领域的FEC算法主要有TURBO、LDPC、POLAR这三种。
音视频传输领域的FEC算法有如下几种:
1、webrtc的opus音频使用的是inband FEC和交织编码。
2、webrtc的视频ulpfec使用的是异或XOR。
3、Reed Solomon算法比较复杂,理论上数据恢复能力比较强。
webrtc默认使能Red+Ulp的FEC。Flex仅在实验阶段,还不能正式使用。
发送冗余报文处理
RTPSenderVideo::SendVideo。当编码器支持时间分层,可以仅冗余level 0的视频数据。否则,就要冗余所有视频数据。冗余度是根据丢包率动态调整。
BitrateAllocator::OnNetworkChanged
->VideoSendStreamImpl::OnBitrateUpdated
->ProtectionBitrateCalculator::SetTargetRates
->media_optimization::VCMLossProtectionLogic::UpdateMethod
->media_optimization::VCMNackFecMethod::UpdateParameters
ForwardErrorCorrection::NumFecPackets 存储媒体报文数*保护因子。
参考:
webrtc fec - 明明是悟空 - 博客园
FEC算法_Cloudy_cn的专栏-CSDN博客_fec算法
ulp-fec,flex-fec mask表解读_zhenfei2017的博客-CSDN博客