音视频质量优化真的是博大精深。
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注定无法找出什么是完整的帧
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
