一、冗余报文和媒体报文组织结构优化点
以单帧10个媒体报文,冗余度20%为例。这里webrtc输出要有10个媒体包2个冗余包。webrtc输出的报文序列如下:
代码实现如下:
UlpfecGenerator::AddPacketAndGenerateFec:攒够足够的帧
ForwardErrorCorrection::EncodeFec:根据媒体报文个数和冗余度,计算要生成的冗余报文个数。
ForwardErrorCorrection::GenerateFecPayloads:通过这组媒体报文数据,连续生成num_fec_packets个冗余报文。
EnqueuePackets函数,一口气把num_fec_packets个冗余报文全部发送出去。
可以看出这种打包方式,会增加FEC解码端的解码时间。 建议优化改成FEC和媒体报文交织打包发送。如下:
二、冗余报文的保护个数限制
UlpfecGenerator::AddPacketAndGenerateFec函数限制如下:
目前webrtc限制,仅支持48bit的掩码,若是单帧视频报文数大于48的话,后续报文不会push到media_packets_队列,也就不会参与冗余。降低了FEC的保护能力。实际根据rfc8627协议格式,flexfec可以保护108个媒体包。这里的限制不合理。
flexfec_header_reader_writer.h文件报文格式定义:
三、仅支持1D列冗余模式
可以引入2D行列冗余模式,对抗连续丢包和随机丢包两种丢包模型。
文章来源:https://www.toymoban.com/news/detail-601082.html
但是这种打包方式冗余度偏高,对于延时要求不是特别严苛的场景下,可以考虑多帧冗余打包。文章来源地址https://www.toymoban.com/news/detail-601082.html
到了这里,关于webrtc QOS方法二.4(flexfec 实现可优化点)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!