WebRTC（九）：JitterBuffer

JitterBuffer

Jitter

“Jitter”指的是连续到达的媒体包之间时间间隔的变化。在网络传输中，由于：

• 网络拥塞
• 路由路径变化
• 队列排队
• 不同链路带宽差异

导致包之间的接收时间不一致，这就是网络“抖动”。

作用

**JitterBuffer（抖动缓冲区）**的作用是：

• 缓冲网络传输过来的数据包
• 重新排序乱序的包
• 缓冲一定时间再输出
• 实现稳定的音视频帧输出，避免播放中出现 卡顿、跳帧、音频破音

工作流程图

网络接收 ← UDP/RTP 包 ← jitterbuffer ← 解码器 ← 播放器/渲染器
                            ↑          ↑
               排序 + 重组 + 时间控制  + 丢包填补（PLC）

流程详解

1. 接收数据包

• 每个 RTP 包有 sequence number 和 timestamp。
• 收到包后，判断是否乱序、丢包。

2. 缓存和排序

• 将包插入 buffer 中合适位置（基于 sequence number 排序）。

3. 播放控制

• 到达播放时间时，提取对应时间戳的包进行解码。
• 若包未到达（丢包或延迟）：
  • 等待一段时间（等待时间配置或自适应）；
  • 或直接丢帧；
  • 或填补（音频使用 PLC，视频可能重复前帧或跳过）。

4. 自适应控制

• 根据网络条件（RTCP 报告、丢包率、延迟）动态调整缓冲大小（WebRTC 的核心机制之一）。

常用参数

WebRTC中JitterBuffer

WebRTC 是目前最复杂、最智能的抖动缓冲实现之一，支持：

• 音频 JitterBuffer
• 视频 JitterBuffer
• 网络自适应算法
• FEC（前向纠错）/NACK（重传）
• Audio/Video 同步

音频 JitterBuffer

模块路径：webrtc/modules/audio_coding/neteq/

功能

• 乱序处理；
• 丢包补偿（使用 PLC、CNG、FEC）；
• 动态调节；
• 语音平滑（低码率时很关键）；

原理

             RTP Packet
                 ↓
          NetEq::InsertPacket
                 ↓
     [DecoderBuffer + PacketBuffer]
                 ↓
        NetEq::GetAudio (解码并补偿)
                 ↓
          音频帧 → 播放器

PLC、CNG、FEC

概念

PLC（Packet Loss Concealment）

目标：帧丢失时，合成一个与上一帧相似的语音片段，避免“卡顿”或“哑音”。

常用方法：

• 波形复制：简单地复制上一帧波形；
• 线性预测（LPC）：建模语音信号特性，预测缺失内容；
• 谱域合成：复制频谱形状，适用于宽带语音（如 Opus）；

WebRTC 实现：

• 位于 NetEq 模块中的 Expand 类；
• 插入虚拟音频帧（通常是 10ms）；
• 结合时间戳推进逻辑，自动衔接解码帧。

NetEq::GetAudio() 会判断是否缺帧，如缺则调用 Expand::Process() 生成伪音频。

CNG（Comfort Noise Generation）

目标：通话静音时生成背景噪声，增强自然感、避免“真空”感。

常用方法：

• 在“活动语音”段估计背景噪声特征；
• 静音时合成类似背景噪声（白噪声加滤波）；
• 由编码器定期发送 SID（Silence Insertion Descriptor）帧；

WebRTC 实现：

• 使用 RFC 3389 标准 CNG；
• 位于 NetEq 的 ComfortNoise 模块；
• 接收 SID RTP 包并生成伪噪声；
• 在编码器中设置：audio_coding_module->EnableCN(true);

FEC（Forward Error Correction）

目标：通过发送冗余信息，让接收端自行恢复丢失的帧。

常用方法：

• Opus 内建 FEC：发送低码率副本；
• Redundant Encoding (RED)：同一个 RTP 包携带多个编码帧；
• ULPFEC（RFC 5109）：按 RTP 层进行异或编码恢复丢包；

WebRTC 实现：

• 支持 Opus FEC（内建）；

• 支持 RED + ULPFEC 组合（多用于视频，但音频也适用）；

• 启用方式：

  config.audio.send_codec_spec.codec_inst.pltype = 111; // opus
  config.audio.send_codec_spec.enable_fec = true;
  

Opus 中 FEC 和 DTX 可协同工作（低带宽时启用 DTX 静音，失真时启用 FEC）

对比

WebRTC 中启用方式

启用 PLC（默认开启）

无需显式设置，NetEq 自动启用：

NetEq::GetAudio() 自动判断是否丢包 → Expand::Process()

启用 CNG

AudioSendStream::Config config;
config.send_codec_spec.codec_inst.pltype = 9; // G.729 CN
config.send_codec_spec.enable_dtx = true;     // 打开 DTX

对于 Opus，也可以开启 DTX（自动静音 + CNG）：

config.send_codec_spec.enable_dtx = true;

启用 FEC（以 Opus 为例）

config.send_codec_spec.enable_fec = true;

也可通过 SDP 启用 RED + ULPFEC：

a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1; usedtx=1

NetEq

功能

关键类：NetEqImpl

核心类是：

class NetEqImpl : public NetEq {
 public:
  int InsertPacket(const RTPHeader& header, rtc::ArrayView<const uint8_t> payload) override;
  int GetAudio(AudioFrame* audio_frame) override;
  ...
};

InsertPacket()

int NetEqImpl::InsertPacket(const RTPHeader& header,
                            rtc::ArrayView<const uint8_t> payload)

处理 RTP 包输入：

• 插入 packet_buffer_
• 检查有效性、乱序
• 更新时间戳信息

GetAudio()

int NetEqImpl::GetAudio(AudioFrame* audio_frame)

执行一次音频播放输出：

• 调用 decision_logic_->GetDecision() 选择行为
• 行为包括：
  • kNormal：正常解码
  • kExpand：PLC 补偿
  • kAccelerate：播放加速
  • kCng：背景噪声
• 执行相应模块生成音频帧返回

运行机制：时间推进和缓冲策略

NetEq 使用内部“播放时钟”推进播放，假设 10ms 一帧，每次 GetAudio() 会：

1. 计算目标 timestamp
2. 判断当前 packet buffer 是否含有该 timestamp 的帧
3. 没有 → 触发补偿
4. 有 → 解码返回

源码解析

PacketBuffer

存储 RTP 包，支持按 timestamp 排序 + 乱序插入：

class PacketBuffer {
  bool InsertPacket(Packet&& packet);
  absl::optional<Packet> GetNextPacket(uint32_t timestamp);
};

DecoderDatabase

注册各种 RTP payload type 到解码器：

class DecoderDatabase {
  bool RegisterPayload(uint8_t payload_type, AudioDecoder* decoder);
  AudioDecoder* GetDecoder(uint8_t payload_type);
};

可扩展添加自定义解码器。

Expand（PLC）

用于在丢包时合成连续音频：

class Expand {
  void Process(AudioFrame* frame);
};

算法核心：基于最近解码帧的频率模式生成伪数据。

视频 JitterBuffer

模块路径：webrtc/modules/video_coding/

功能

• 基于帧（Frame）级缓存；
• 管理多个 RTP 包拼装一个视频帧；
• 处理 I/P/B 帧依赖关系；
• 异步解码与播放，配合 AVSync。

核心类：

• VCMJitterBuffer：包级缓存；
• FrameBuffer：帧组装器；
• FrameBufferController：根据解码状态/网络反馈动态调节 buffer；

原理

1. DeliverRtp(RTP packet)
   ↓
2. Insert into FrameBuffer (reorders and assembles)
   ↓
3. Mark frame as complete
   ↓
4. Notify decoder thread (via AsyncInvoker)
   ↓
5. Decoder calls NextFrame()
   ↓
6. FrameBuffer returns suitable frame based on timing

源码解析

FrameBuffer 接口类

class FrameBuffer {
 public:
  void InsertFrame(std::unique_ptr<EncodedFrame> frame);
  std::unique_ptr<EncodedFrame> NextFrame();
};

特点：

• 接收完整帧（非 RTP 包级）；
• 和 NACK 控制、帧到达策略分离；
• 提供解码时间控制（配合 Timing 类）；

RtpVideoStreamReceiver

接收 RTP 包并重组帧，组装完成后推入 FrameBuffer：

bool RtpVideoStreamReceiver::OnRtpPacket(const RtpPacketReceived& packet)

• 组装 VCMPacket（含 marker bit, seq, timestamp）；
• 查找是否构成完整帧（依赖 FrameBuffer::InsertFrame()）；
• 完整帧则通知解码线程处理。

VideoReceiveStream::StartDecodeLoop()

负责调用解码逻辑：

std::unique_ptr<EncodedFrame> frame = frame_buffer_->NextFrame();
decoder_->Decode(frame);

解码线程会持续等待并从 FrameBuffer 中提取适合解码的帧。

时间同步逻辑（配合 Timing 类）

视频帧不是立刻解码，而是要等待“最佳播放时间”：

Timing::RenderTimeMs(uint32_t frame_timestamp, int64_t now_ms)

内部通过系统时间、RTP timestamp 差计算出：

• 当前帧是否提前（buffering）
• 当前帧是否延迟（丢帧）
• 帧间 jitter 均值估计（变更播放时钟）

丢包处理（NACK / Frame Missing）

1. FrameBuffer::InsertFrame() 内部跟踪丢帧（依据 sequence number）；
2. 控制模块向上层触发 NACK；
3. 使用 rtp_rtcp::RTCPeerFeedback 上报丢帧；
4. 等待 retransmit 后再组帧。

动态自适应机制

WebRTC 会根据网络反馈（RTCP）动态调整 jitterbuffer：

与 AV 同步的协作

WebRTC 中，音频是时钟主导（anchor），视频 jitterbuffer 会与音频同步，控制渲染时间戳，使音画同步。

总结

WebRTC 的 JitterBuffer 构建了高度模块化、可插拔、跨平台的实时缓冲机制，实现了在复杂网络环境下高质量的音视频通信体验。