webrtc代码走读五（JitterBuffer）-CFANZ编程社区

一、什么是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）根据更新后的系统状态计算抖动延迟：

3. 根据抖动延迟计算视频帧的渲染时间

得到网络抖动延迟之后，计算总的抖动延迟：jitter_delay = net_jitter_delay + decode_delay + render_delay。然后根据抖动延迟和当前的时间，计算什么时候渲染当前的视频帧，然后根据渲染时间和当前时间确定当前帧在解码之前需要等待的时间（wait_time），通过wait_time保证了各个视频之间是平滑的，减少了卡顿。另外在等待的时间内也可以缓存更多的视频帧，避免了下一次遇到弱网时再次卡顿。

PacketBuffer：负责帧的完整性，保证组成帧的每个包序列号连续，并且有一个包标识帧的开始，有一个包标识帧的结束；

RtpFrameReferenceFinder：负责给每个帧设置好参考帧，同时兼顾GOP内各帧的连续性；

FrameBuffer：负责帧的连续性和可解码性，这里帧的连续性是指某帧的所有参考帧都已经收到，帧的可解码性是指某帧的所有参考帧都已经被解码；

VCMJitterEstimator：计算抖动(googJitterbufferMS)，用于计算目标延迟(googTargetDelayMs)，用于音视频同步；

VCMTiming：计算当前延迟(googCurrentDelayMs)，用于计算渲染时间。

五、 JitterBuffer结构和基本流程

RtpVideoStreamReceiver类收到RTP包后，交给PacketBuffer类缓存、排序。

PacketBuffer收集满1个完整的帧后，交还给RtpVideoStreamReceiver类。

RtpVideoStreamReceiver类将一个完整的帧交给RtpFrameReferenceFinder。

RtpFrameReferenceFinder类缓存最近的GOP，每个完整帧落在一个GOP中会填充好该帧的参考帧，交还给RtpVideoStreamReceiver。

RtpVideoStreamReceiver将填充好参考帧的完整帧交给FrameBuffer，FrameBuffer判断某帧的所有参考帧都收到认为该帧连续，在某帧的所有参考帧都解码后认为该帧可以解码，从而可以交给解码器。

可以认为JitterBuffer的这些模块分三个层次分别做了RTP包的排序、GOP内帧的排序、GOP之间的排序：

包的排序：PacketBuffer；
帧的排序：RtpFrameReferenceFinder；
GOP的排序：FrameBuffer。

六：帧完整性 - PacketBuffer

6.1 包缓存

PacketBuffer类有两个类型的包缓存：

std::vector data_buffer_，数据缓存，保存包原始数据，用于拼接整帧原始数据；

std::vector sequence_buffer_，排序缓存，保存包连续性信息，用于缓存包序列号等信息并排序成完整的帧。

6.2 帧的开始和结束

在这里重点强调一帧第一个包的标识是因为该标识对判断帧的完整性有重要作用，另外，一帧的最后一个包就是简单根据RTP头中的marker位来标识，只有在第一个包、最后一个包都取到并且中间的所有包都连续的情况下，才认为是一个完整的帧。

6.3 插入RTP数据包 - PacketBuffer::InsertPacket

数据缓存、排序缓存这两个包缓存都是初始长度为size_(512)的数组，一旦缓存满会倍增容量，直到达到最大长度max_size_(2048)。

插入包的过程就是把数据填入这两个缓存的过程，同时会判断是否出现丢包，如果出现丢包则等待，在没有出现丢包的情况下，会判断是否已经获得了完整的帧，如果已经组装好了若干完整的帧，则通过OnAssembledFrame回调通知RtpVideoStreamReceiver。

6.4 丢包检测 - PacketBuffer::UpdateMissingPackets

PacketBuffer维护一个丢包缓存missing_packets_，主要用于在PacketBuffer::FindFrames中判断某个已经完整的P帧前面是否有未完整的帧，如果有，该帧可能是I帧，也可能是P帧，这里并不会立刻把这个完整的P帧向后传递给RtpFrameReferenceFinder，而是暂时清除状态，等待前面的所有帧完整后才重复检测操作，所以这里实际上也发生了帧的排序，并产生了一定的帧间依赖。