webrtc和fec-离成功中间的坑

音视频质量优化真的是博大精深。

fec之前的流程已经分析过了,但是距离从P2P改成SVC模式的路还是比较长的,

RR中的fraction_loss作为fec的基础参数,并不一定会作为fec的冗余度,其中是有rtt的check,在media_optil里面,会根据rtt判断是否启用fec(rtt>20ms),这是合理的,因为如果rtt特别短说明网络情况特别好,在这个条件下选择nack不使用fec

并且fec的冗余度fec_rate的生成,fraction_loss只是一个参数,其中还有编码器很多相关的东西,也都在media_optil中,真正的rate是在计算后并且check之后才会输出。

在解码中其实也有很多坑

传入payload层的都是只剩媒体的包

这意味着,fec的解码模块其实是停止在此,但是RTP包能否被解成完整的帧,帧能否播成图像其实都是一系列的问题。

H264在Webrtc中与fec其实存在着许多矛盾,通过ulpfec保护的包,两者一起通过Red格式发送,拥有了一系列完整的seq,然而

在传入payload前,fec包被踢出,意味着之后的包不再连续,不具备头标志的H264注定无法找出什么是完整的帧

你可能感兴趣的:(#,WebRTC,#,Ulpfec)