3. 接收端缓冲策略：自适应抖动缓冲(Jitter Buffer)设计

抖动缓冲，说白了就是接收端的一个“蓄水池”。

网络不是完美的。RTP包到达的时间，就像早晚高峰的地铁——有时候三秒来一趟，有时候半分钟没影。你想想看，如果解码器直接按到达时间播放，那声音会忽快忽慢，画面会一顿一顿。这就是抖动（Jitter）带来的问题。

我个人习惯把Jitter Buffer比作“时间橡皮筋”。它把不稳定的到达时间，拉伸成稳定的播放节奏。今天我们就来聊聊，这根橡皮筋怎么设计才够聪明。

3.1 为什么需要自适应？

固定大小的缓冲区，在真实场景下根本扛不住。

我记得有一次做视频会议项目，网络好的时候延迟只有20ms，一到高峰期直接飙到200ms。如果缓冲区设小了，卡顿频繁；设大了，延迟又高得没法用。用户骂娘，老板拍桌子。

所以，缓冲区必须能“看人下菜碟”——网络好就缩小，网络差就扩大。这就是自适应。

3.2 自适应Jitter Buffer的核心模块

一个完整的自适应Jitter Buffer，通常包含下面几个部分。我画了张图，方便你理解整体架构。

3.3 抖动估算：怎么算才准？

估算抖动，不能只看单个包的延迟。网络波动是随机的，得用统计方法。

我常用的方法是 指数加权移动平均（EWMA）。公式很简单：

// 抖动估算（EWMA）
jitter = (1 - alpha) * jitter + alpha * |delay - avg_delay|

// 其中：
// alpha 是平滑因子，通常取 0.1 ~ 0.3
// delay 是当前包的端到端延迟
// avg_delay 是平均延迟（也用 EWMA 计算）

3.4 深度决策：什么时候该动？

有了抖动值，接下来就是决定缓冲区深度。这里有几个关键策略：

• 阈值触发：抖动值超过某个上限，就增大缓冲区；低于下限，就缩小。
• 滞后比较：增大和缩小的阈值不一样，避免频繁切换。比如抖动 > 50ms 才增大，< 30ms 才缩小。
• 安全余量：缓冲区深度 = 当前抖动值 × 安全系数（通常 2~4 倍）。

举个例子，假设当前抖动是 40ms，安全系数取 3：

buffer_depth = jitter * safety_factor
             = 40ms * 3
             = 120ms

这意味着缓冲区会保留 120ms 的数据。即使网络突然变差，也有足够的数据撑过波动期。

3.5 缓冲区调整的平滑过渡

直接改变缓冲区深度，会导致播放速率突变。你想想看，如果突然从 100ms 跳到 200ms，音频会“顿”一下，视频会“跳”一下。

所以，调整必须平滑。我常用的方法是 播放速率微调：

• 增大缓冲区：暂时减慢播放速率（比如 0.98x），让数据积累起来。
• 缩小缓冲区：暂时加快播放速率（比如 1.02x），消耗多余数据。

变化幅度要控制在人耳/人眼感知不到的范围。一般来说，±2% 的速率变化，用户基本无感。

3.6 参数配置参考

下面是我在实际项目中总结的参数表，供你参考：

参数	推荐值	说明
EWMA 平滑因子 (alpha)	0.125	对网络变化反应适中，避免抖动值剧烈波动
安全系数	2 ~ 4	根据网络质量动态调整，网络差时取大值
增大阈值	50ms	抖动超过此值，开始增大缓冲区
缩小阈值	30ms	抖动低于此值，开始缩小缓冲区
播放速率变化范围	±2%	超出此范围，用户可能感知到音调变化
缓冲区最大深度	500ms	超过此值，直接丢包或请求重传

3.7 避坑指南

做自适应Jitter Buffer，有几个坑我踩过，分享给你：

• 不要只看抖动值：我曾经只根据抖动调整缓冲区，结果网络出现连续丢包时，缓冲区虽然够大，但数据本身丢了，播放还是卡。后来我加入了丢包率作为辅助指标。
• 注意初始缓冲：刚开始播放时，缓冲区是空的。如果立刻开始播放，遇到第一个网络波动就会卡。我习惯先缓存 100~200ms 的数据再开始播放。
• 小心“饿死”和“撑死”：缓冲区空了叫“饿死”，满了叫“撑死”。饿死时静音或重复上一帧，撑死时丢弃旧数据。这两种情况都要有兜底策略。