WebRTC中丢包重传机制的实现

最新推荐文章于 2024-08-07 07:46:16 发布

rtc8_com

最新推荐文章于 2024-08-07 07:46:16 发布

阅读量5.4k

点赞数

分类专栏： WebRTC

本文链接：https://blog.csdn.net/onlycoder_net/article/details/76870445

版权

本文介绍了WebRTC中的丢包重传机制，包括前向纠错（如flexfec）和重传策略。当接收方检测到丢包时，通过发送NACK请求，发送方会在历史记录中查找并重传数据包。同时，WebRTC会考虑RTT时间范围和pacing模块来优化重传过程。

摘要由CSDN通过智能技术生成

 
 当网络质量突然变的很差并开始丢包时，声音听起来音质会变差，画面帧速会下降，甚至会完全卡住。我们可能需要某种机制来应对这种情况。在WebRTC中，主要有两种机制来应该网络变差的情况： 

前向纠错：在每个数据包中，您将添加一些关于前一个信息的信息，以防丢失，您需要重新构建它们（flexfec是WebRTC [1]中的新格式）。
重传：当接收方检测到有丢包时，它会发送NACK类型的RTCP包给发送方，发送方会重发这些数据。

 
 这些机制可以根据网络条件进行组合，也可以针对特定情况进行调整，如[2]中所述的可扩展视频。在Chrome中，理论上音频，视频丢包都可以重传，但默认情况下只会启用视频丢包重传。下面会详细介绍丢包重传的具体实现。 

 
 RTP接收方 

 
 丢包重传的请求是由RTP接收方发起的。当RTP接收方检测RTP包头中的seq属性发现有丢包时，丢包重传机制就会启用。但是，是否检测到下一个RTP包不是自己预期想要的哪个就会要求重传呢？比如当前RTP序号是99，下一个来的包序号是101，哪就是否意味着序号为100的包就丢了呢？由于RTP协议是基于UDP的，而UDP又是无序传输的。再下一个包又可能就是序号为100的包。WebRTC会以500毫秒周期性的检测