webrtc代码走读五（JitterBuffer）

原创

已于 2022-02-01 11:58:11 修改 · 4.5k 阅读

38 ·

CC 4.0 BY-SA版权

文章标签：

#webrtc #p2p #tv

于 2022-01-31 08:29:25 首次发布

本文围绕JitterBuffer展开，介绍其是实时音视频重要模块，能处理数据包问题、降低卡顿。阐述了其在音视频系统中的位置、工作原理，分析了WebRTC里视频JitterBuffer的运行机制、抖动延迟计算及视频帧渲染时间计算，还介绍了相关模块结构、流程及抖动与延迟的计算方法。

一、什么是JitterBuffer

Jitter Buffer也叫做抖动缓冲区，它是实时音视频里面的一个重要模块，它对数据包丢失、乱序、延迟到达等情况进行处理，平滑的向解码模块输出数据包/帧，抵抗各种弱网情况对播放/渲染造成的影响，降低卡顿，提高用户的观看体验。

二、JitterBuffer在音视频系统中的位置

JitterBuffer在实时音视频系统中的位置如下所示：

三、视频JitterBuffer的工作原理

1. JitterBuffer的核心思想

Jitter buffer的核心思想是用时间换空间，以增大端到端的延迟为代价来换取视频通话的流畅性。当网络不稳定时（抖动发生），增加buffer的长度，多缓存一些数据，以应对将来可能发生的抖动；当网络稳定下来时，减小buffer的长度，少缓存一些数据，降低视频端到端的延迟，提高实时性。因此jitter buffer的运行过程是一个根据抖动来动态调整buffer长度的过程。好的jitter buffer能够在保证尽量不卡的前提下降低端到端的延迟，即它能够在延迟和卡顿率之间取得较好的平衡。

2. 产生抖动的原因

1) 网络传输路径改变。例如，当前的传输路径是A，但是下一刻路径A上的某个路由器出现了故障，这时候数据包的路径就会发生改变，导致端到端的传输时长发生变化。

2) 网络自身的抖动。很多情况下网络有噪声，产生抖动是很正常的。

3) 网络发生拥塞。拥塞发生的时候，数据包会在路由器上排队，导致端到端延迟变大。

4) 抗丢包手段带来的额外抖动。网络出现丢包的时候，我们一般会使用nack/arq去重传数据，重传会带来额外的延迟。
3. 计算抖动的方法

数据包传输时长的变化就是抖动，假设相邻的两个数据包packet1和packet2，它们发送时间戳是send_timestamp1和send_ timestamp2，接收时间戳是recv_ timestamp1和recv_ timestamp2，那么它们之间的抖动可以按照下面的方法计算：

这是最简单的计算方法，要想准确计算出网络抖动还需要考虑很多因素，这里不再赘述。

4. JitterBuffer的工作原理

1) 接收侧收到数据包，开始组帧，这一步是必须的，帧不完整会导致花屏。

2) 每个帧组好之后，放进buffer里，然后按照帧序号进行排序。

3) 检查帧的参考关系。对于解码器来说，如果一个帧的参考帧丢失了，那么这个帧将解码失败或者花屏，所以参考关系必须要满足之后才能把数据送进解码器里。

4) 根据每一帧的时间戳（采集时间戳或者发送时间戳）以及接收时间戳计算抖动。这里的难点在于如何精确计算抖动。

5) 根据抖动计算buffer的长度。

6) 根据抖动自适应的调整buffer长度。抖动越大，预留的buffer长度越大，这样可以利用增加延迟的方式来降低卡顿；抖动越小，预留的buffer长度越小，这样可以降低延迟。

四、浅析webrtc里的视频JitterBuffer

1.WebRTC里视频JitterBuffer的运行机制

Jitterbuffer被两个线程操作，写线程负责组帧完成之后把数据写入JitterBuffer里，读线程负责从JitterBuffer里读取数据然后解码。

写线程：

1) 判断当前视频帧是否有效，把帧插入buffer里，然后移除buffer里过期的、无效的帧；

2) 判断帧之间的参考关系是否已经满足；

3) 如果当前帧可以解码，那么激活解码线程（读线程）。

读线程：

1) 找到buffer中第一个可以解码的帧（假设它是frame）：如果这个帧的渲染时间戳是无效的，那么根据当前的抖动（开始的时候抖动值是0，它在步骤3中被更新）计算每个帧的渲染时间戳（render timestamp），并保存在帧信息中，然后根据这个帧的渲染时间戳和当前时间计算最大需要等待的时间（最大的等待时间不会超过200毫秒），然后休眠等待；

2) 如果在等待的时间内还有新的可以解码的帧到来，那么重复步骤2，直到超时；

3) 根据frame的时间信息以及帧大小计算新的抖动值，并用这个抖动更新当前的抖动。

2. 计算抖动延迟

抖动延迟由网络抖动延迟、解码延迟、渲染延迟构成。其中，解码延迟和渲染延迟比较稳定，网络抖动延迟是动态变化的。计算网络抖动是Jitterbuffer的核心之一。webrtc认为网络抖动由两个部分构成：

1) 网络噪声带来的抖动延迟，也叫做网络排队延迟。

2) 传输大的视频帧（特别是关键帧）对网络造成冲击带来的抖动延迟。

为了准确估算出抖动延迟，必须要估算出网络排队延迟和信道速率（通过信道速率可以计算大的视频帧对网络造成的冲击所带来的延迟）。webrtc使用卡尔曼滤波估算网络排队延迟和信道速率。卡尔曼滤波是一种预测的算法，它以协方差为标准，根据上一时刻的系统状态估算当前时刻系统的状态，然后根据当前的测量值调整当前时刻系统的状态，最后得到当前最优的系统状态。它认为估算出来的值和测量出来值都是有偏差的，因此要根据一个偏好因子（卡尔曼滤波增益系数）来判断我们最后需要的值更加偏向于估计值还是测量值。由于卡尔曼滤波比较复杂，这里并不打算深入探讨，下面介绍一下使用卡尔曼滤波计算网络抖动延迟的大致流程：

1) 抖动的计算与信道速率、网络排队延迟有关，因此要计算抖动，就必须先计算信道速度和网络排队延迟。

2) 把信道速率和网络排队延迟当作系统状态，算法的目标就是估算出最优的信道速度和网络排队延迟。假设系统是一个线性系统，如果网络非常好，那么很容易估算出当前系统的状态等于上一个时刻的系统状态，也就是说信道速度和网络排队延迟保持不变。

3) 但是实际上网络是动态变化的，因此需要对估算出的这个系统状态（即信道速度和网络排队延迟）进行调整。

4）调整的具体方式：

5）根据抖动延迟的观测值（两帧传输时长的变化值）和预测值（根据上一个系统状态推导出来），计算它们的残差；

6）利用残差计算网络噪声；

7）根据抖动延迟观测值、前后两帧大小差值、网络噪声、系统误差协方差等计算卡尔曼增益系数。

8)利用卡尔曼增益系数更新系统状态（即信道速率和网络排队延迟）。

9）根据更新后的系统状态