WebRTC JitterBuffer详解：抖动网络下如何保证流畅播放

WebRTC JitterBuffer详解：抖动网络下如何保证流畅播放

前面几篇已经讲了发送端如何控制码率、Pacer 如何控制发包节奏。到了接收端，问题换了一个方向：网络不会保证 RTP 包准时、按序、完整到达。包可能早到、晚到、乱序、丢失、重复，甚至关键帧的一部分先到，另一部分绕了半个互联网才回来。JitterBuffer 要做的事情，就是在“不完美的网络”和“尽量稳定的播放”之间做缓冲、排序和取舍。

视频 JitterBuffer 不是简单的 std::queue。它更像机场行李转盘加安检：同一航班的行李可能不是一起出来，缺了一个箱子要不要等，等多久，乘客是否先走，后面航班是否会被堵住，这些都要判断。WebRTC 接收端也一样：同一帧可能拆成多个 RTP 包，JitterBuffer 要根据 sequence number、timestamp、marker bit、帧依赖关系判断一帧是否完整，是否值得等待丢失包，是否应该触发 NACK，是否需要放弃旧帧以保护低延迟。

1. 抖动、乱序和帧重组

网络抖动指的是包到达间隔不稳定。发送端可能每 5ms 发一个包，但接收端看到的可能是 2ms、20ms、1ms、30ms 这样忽快忽慢。乱序则是后发的包先到了，先发的包后到了。丢包就是某些包永远不到，或者迟到到已经没意义。

对视频来说，RTP 包通常不是一包一帧。一帧视频可能被拆成多个 RTP 包：

Frame A timestamp=1000
  RTP seq 10