超级会员免费看
本文深入探讨WebRTC中的NACK机制，用于处理视频传输中的丢包问题。NACK通过RTCP反馈告诉发送端哪些包未收到，发送端再通过RTX重传丢失的包。文章介绍了NACK的基本原理、包位置的判断算法以及WebRTC中的处理流程，包括是否丢包的判断、乱序包的处理等。
在之前的文章 WebRTC系列-Qos系列之音频设置丢包重传nack介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章 WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。
在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的 RTX机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。
1. NACK简述
WebRTC里视频默认是开启nack，然后使用RTX进行重传(音频的实现不一样，如果开启NACK也是使用原来的ssrc重新传递包)；对于RTX本文也会介绍到,RTX不会使用原来的SSRC重传这个丢失的包，而是会使用一个新的ssrc去重传这个包，一般情况下这个包的ssrc是媒体payload的ssrc+1，例如视频H264是96，那么对应的RTX就是RTX=97；
NACK的全称是Negative Acknow
订阅专栏 解锁全文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
