端到端延迟是一条流水线

从你动一下到对方屏幕亮起，整段延迟 $\Delta$ 是流水线上各段耗时之和：

$\Delta = \underbrace{t_{\text{capture}}}_{\text{采集}} + \underbrace{t_{\text{encode}}}_{\text{编码}} + \underbrace{t_{\text{net}}}_{\text{网络}} + \underbrace{t_{\text{jbuf}}}_{\text{抖动缓冲}} + \underbrace{t_{\text{decode}}}_{\text{解码}} + \underbrace{t_{\text{render}}}_{\text{渲染}}$

人能感到”实时”的红线约 200 ms（one-way）。每段都要榨干到几十毫秒以内才合格。

各段的典型量级

段	典型耗时	说明
采集	16–33 ms	一帧周期（60→16ms / 30fps→33ms），相机驱动缓冲
编码	5–30 ms	取决于编码器、分辨率、CPU
网络（RTT/2）	20–150 ms	单程传播 + 排队，跨境大
抖动缓冲	20–100 ms	故意加的，吸收网络抖动（B09）
解码	5–30 ms	与编码对称
渲染	16–33 ms	等 vsync 周期

总和稍不留神就超 200 ms，所以每一段都在”抠时间”。

为什么 200 ms 是红线

人耳对延迟的容忍随场景变化：

• < 150 ms：对话自然，感觉不到延迟。
• 150–300 ms：能察觉轻微滞后，但可接受。
• > 400 ms：明显打断对话节奏，“对讲机”式说话。

电话网（PSTN）历史上瞄准 150 ms one-way（ITU-T G.114 建议）。WebRTC 把同样的目标带到互联网，用 UDP + 自适应码率 + 抖动缓冲达成。

各段为何要分清

延迟不是均匀分布的，而是集中在某几段。优化要找瓶颈段：

• 跨境通话里，$t_{\text{net}}$ 占大头（光速限制 + 路由跳数），物理不可压缩。
• 局域网里 $t_{\text{net}}$ 极小，瓶颈转移到 $t_{\text{encode}}$ + $t_{\text{jbuf}}$——这时降低编码复杂度（用硬件编码）或缩小抖动缓冲更有效。

易错点

• 延迟 ≠ 网络延迟。很多人把 “实时性” 等同于 ping 值（RTT），但端到端延迟还包括采集、编码、缓冲等本机处理时间。本机在低端设备上可能比网络还慢。
• 抖动缓冲是”故意加的”延迟，不是 bug。它用 20–100 ms 的固定延迟换取平滑播放（B09）。在极低延迟场景（云游戏）会大幅缩小甚至去掉，代价是抗抖动能力下降。

参考

• ITU-T G.114: One-way transmission time
• WebRTC latency budget (webrtc.org)

队头阻塞：TCP 在实时场景的致命伤

TCP 保证可靠、有序，靠的是重传 + 等待。一旦某个包丢失，发送方继续发，但接收方应用层看不到后续包——它们在 TCP 缓冲区里排队等丢失的那个补回来。这种”前面一个卡住后面全部”的现象叫队头阻塞（Head-of-Line blocking, HoL）。

丢包 $P_1$ 后，即使 $P_2, P_3$ 已正确到达，应用层也要等 1 个 RTT（重传往返）才能看到 $P_2$：

发送: P1 ✗(丢) P2 P3 P4 ...
接收缓冲: [等P1']          ← P2,P3 已到但应用看不到
1 RTT 后: P1' 到达 → 应用一次性看到 P1' P2 P3 P4

对文件传输这是好事（顺序正确）。对实时视频这是灾难——这 1 个 RTT（跨境可能 200 ms）期间所有”准时到达”的新帧都被一个过期的丢失帧卡住。

实时视频的时效性

视频帧的价值随时间衰减。第 $t$ 时刻产生的帧，到 $t + 100\text{ms}$ 就基本没用了（播放早已过了那个时刻）。重传回来的旧帧：

$\text{价值}(\text{重传帧}, t_{\text{到达}}) \approx 0$

但它的存在让后续新帧全部延迟到达——用一帧没用的旧帧拖累无数新帧，得不偿失。

UDP：丢了就丢了

UDP 不保证可靠、不保证顺序，每个包独立投递。丢一个包，后续包照常到达应用层：

发送: P1 ✗(丢) P2 P3 P4 ...
接收应用: [P2 P3 P4 ...]   ← 立刻可用，P1 缺失造成一帧花屏

画面上出现短暂的”花屏”或”卡顿”（解码缺帧），但延迟不累积——后续帧正常播放。对实时通信，宁可偶尔花一下，也不能让延迟滚雪球。

WebRTC 在 UDP 上自建按需可靠性

UDP 完全不重传也不行（关键帧丢了就彻底花屏）。WebRTC 在应用层（RTP 之上）实现按需重传：

• 普通帧丢了：直接丢弃，等下一帧（NACK 都不发，太晚了）。
• 还来得及补的帧：发 NACK 请求重传（B08）。
• 关键帧彻底丢了：发 PLI 请求全新 IDR（B08）。

这种”按延迟预算决策”的重传策略，比 TCP 的”无条件重传”灵活得多。

QUIC 的启示：在 UDP 上重建”准 TCP”

有意思的是，HTTP/3 的 QUIC 协议也用 UDP——因为 TCP 的 HoL 在多路复用 HTTP 里也是问题。QUIC 在 UDP 上重建了类似 TCP 的可靠传输，但每条流独立，一个流丢包不阻塞其他流。WebRTC over QUIC（正在标准化）会进一步降低延迟。

易错点

• “WebRTC 用 UDP” 不完全准确。WebRTC 的媒体流用 SRTP（加密的 RTP）over UDP；但信令（SDP 交换、ICE 协商）通常走 WebSocket over TCP。两套通道分工：媒体走 UDP 抢延迟，信令走 TCP 抢可靠。
• TCP 不是”绝对不能用于实时”。在某些受限网络（公司防火墙只开 443），WebRTC 会回退到 TCP 上的 TURN 中继，代价是延迟增加。这是工程权衡，不是技术纯洁性。

参考

• Head-of-line blocking (维基百科)
• User Datagram Protocol — RFC 768
• QUIC: A UDP-Based Multiplexed Transport (RFC 9000)

RTP 头部：让 UDP 还原成连续媒体

裸 UDP 只给你一个 payload 和源/目的端口，不知道包的先后、是什么编码、什么时候播。RTP（Real-time Transport Protocol, RFC 3550）在 UDP 之上加一个 12 字节（最小）头部，盖三个关键”章”：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               synchronization source (SSRC) identifier        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

三个核心字段

1. Sequence Number（16 位）

每发一个 RTP 包序号 +1（绕回）。接收端用它：

• 排序：UDP 包可能乱序到达，按 seq 重排。
• 丢包检测：发现 seq 跳变（如收到 5、6、8）就知道 7 丢了，触发 NACK（B08）。

初始值随机，避免不同会话的包混淆。

2. Timestamp（32 位）

这是 RTP 最重要的字段——给媒体装上时间轴。它不是”墙钟时间”（wall clock），而是采样时钟的计数：

• 视频：通常 90 kHz 时钟，每帧 timestamp 增加 $90000 / \text{fps}$（30fps → 每帧 +3000）。
• 音频：通常等于采样率（Opus 48 kHz → 每采样 +1，每帧 20ms → +960）。

同一帧的所有 RTP 包共享相同 timestamp（一帧切片成多个包），不同帧 timestamp 递增。接收端用 timestamp 决定何时播放和音视频同步。

3. Payload Type（PT，7 位）

标识这个包的负载编码格式：

PT	编码	媒体
0	PCMU (G.711 μ-law)	音频
111	Opus	音频
96+	动态类型（H.264/VP8/AV1）	视频

PT < 96 是静态分配（RFC 3551 固定），≥ 96 是动态分配（SDP 协商时绑定）。

SSRC：流标识

每个 RTP 流有个随机 32 位 SSRC（Synchronization Source）。一路通话里有视频流、音频流各自一个 SSRC，接收端靠它分流和同步。

音视频同步：RTCP SR 的关键作用

只靠 RTP timestamp 没法跨流同步——视频用 90kHz、音频用 48kHz，时钟基准不同。RTCP Sender Report (SR) 携带 (NTP timestamp, RTP timestamp) 配对：

SR 包: (墙钟时间 T_wall, 该时刻对应的 RTP timestamp T_rtp)

接收端收到 SR 后，可以把任意 RTP timestamp 换算成墙钟时间：

$t_{\text{wall}} = T_{\text{wall, SR}} + (T_{\text{rtp}} - T_{\text{rtp, SR}}) / \text{clock\_rate}$

有了墙钟时间，视频流和音频流就能对齐——这就是 lip sync（唇形同步）的实现。

易错点

• RTP timestamp 单位不是秒。视频用 90kHz 所以数字很大（一帧 3000 而不是 0.033）。读代码看到 timestamp 要除以时钟频率才是秒。
• seq 绕回不是错误。16 位最多 65536 个包，30fps × 50 包/帧 几分钟就绕回一次。接收端要处理 wrap-around（用模 65536 的差值判断先后）。
• RTP 不保证任何可靠性。它只是”贴标签”的协议，丢包、乱序仍由 UDP 决定，恢复靠 B08 的 NACK/FEC/PLI。

参考

• RTP — RFC 3550
• RTP Profile for Audio/Video — RFC 3551
• RTP timestamp & synchronization (webrtc glossary)

GCC：基于延迟梯度的拥塞控制

WebRTC 用 GCC（Google Congestion Control，IETF draft-ietf-rmcat-gcc）估带宽。和 TCP 的丢包驱动（loss-based）拥塞控制（如 CUBIC）不同，GCC 主要看延迟变化——在丢包发生前就预判拥塞。

核心观测量：到达时间增量（ODT）

接收端记录每两个相邻包的到达时间差 $\Delta t_{\text{arrival}}$ 和发送时间差 $\Delta t_{\text{send}}$（从 RTP timestamp 推），定义延迟梯度：

$m_{t_i} = \Delta t_{\text{arrival}} - \Delta t_{\text{send}} = (t^r_i - t^r_{i-1}) - (t^s_i - t^s_{i-1})$

• $m > 0$：包到达间隔 > 发送间隔 → 路上排队变长 → 拥塞苗头。
• $m \approx 0$：排队稳定，链路通畅。
• $m < 0$：排队缩短（之前堵的正在消化）。

把一段时间的包组成”块”（典型 60ms 内的包），算块级 ODT 作为信号。

趋势线检测（Trendline Detector）

原始 ODT 噪声大（网络抖动），GCC 对最近的 ODT 序列做线性回归，求斜率 $k$：

• $k > \theta$（阈值）：明显上升趋势 → 降码率。
• $k \le \theta$：稳定或下降 → 增码率（探测）。

阈值 $\theta$ 自适应（基于噪声估计），避免误判。这是 GCC “提前预警”的关键——在丢包发生前看到排队增长。

状态机：增 / 持 / 减

GCC 维护一个 AIMD（Additive Increase, Multiplicative Decrease）风格的状态机：

状态	触发	动作
Increase	$k \le \theta$，过载解除	码率按 $\alpha$ 缓慢加（探测带宽）
Hold	不确定	保持当前码率
Decrease	$k > \theta$	码率乘 0.85（快速降，避免丢包）

增得慢、降得快——和 TCP CUBIC 同样的设计哲学，避免震荡。

闭环：RTCP 反馈 + 发送端调整

接收端：测 ODT → 趋势检测 → 估可用带宽 Â_t
   ↓ 通过 RTCP TWCC（Transport-wide CC）反馈每包到达时间
发送端：融合接收端估计 + 自身基于丢包的估计
   ↓
编码器：setTargetBitrate(Â_t)
   ↓
下一批包以新码率发出

TWCC（Transport-wide Congestion Control）是 WebRTC 当前的反馈机制：发送端给每个包打序号，接收端周期性（每 100ms）回报”哪些包何时到达”，发送端据此算 ODT。比旧的 REMB（直接报带宽估计值）更细粒度。

降码率 vs 丢包：编码器配合

GCC 决定降码率时，编码器通过跳帧、降量化参数（QP）、降分辨率实现：

• 降 QP：每帧更糊但帧率不变。
• 跳帧：30fps → 15fps，每帧仍清晰但卡顿感增加。
• 降分辨率：1080p → 720p，省带宽但模糊。

具体策略是编码器内部的码率控制（rate control），见 B13 的量化环节。

易错点

• GCC 不是只看延迟，也看丢包。GCC 有两个子控制器：基于延迟的（本文重点）和基于丢包的（TFRC-like）。两者结果取较小值，避免冲突。
• TWCC 反馈本身也会丢包。反馈包走 RTCP（UDP），同样可能丢。GCC 对反馈缺失有容错（用历史趋势外推），但持续丢失会导致估计滞后。

参考

• GCC 算法规范 — draft-ietf-rmcat-gcc-02
• A Google Congestion Control Algorithm for Real-Time Communication (Holmer et al., 2015)
• Transport-wide Congestion Control (TWCC)

NACK / FEC / PLI：按延迟预算分层抗丢包

丢包不可避免（UDP），WebRTC 用三种机制按代价分层恢复：

机制	代价	延迟	适用
NACK	1 RTT 重传	+RTT	还来得及的丢包
FEC	多发冗余	0（即时恢复）	高频小丢包
PLI	重发关键帧	+RTT + 编码	彻底失步

NACK（Negative Acknowledgement）

接收端发现 seq 缺失（如收到 5、6、8），向发送端发 NACK：“包 7 没收到，请重传”。

发送: P5 P6 P7(丢) P8 P9 ...
接收: P5 P6 [缺7] P8 P9 → 发 NACK(7)
发送收到 NACK → 重发 P7
接收: ... P7' → 补上

关键判据：剩余播放时间。接收端的抖动缓冲（B09）会给每个包留一段缓冲时间 $T_{\text{jbuf}}$。如果 $T_{\text{jbuf}} > \text{RTT}$，重传来得及，发 NACK；否则放弃，等下一帧。

NACK 是 RTP/RTCP 的反馈消息（RFC 4585），可以多次重发（同一个 NACK 重复发几次防 NACK 本身丢失）。

FEC（Forward Error Correction）

不靠重传，提前多发一点冗余数据，接收端用冗余就地算回丢失的包，0 额外延迟。

最简单的 FEC 是 XOR 编码：发 $k$ 个源包 $P_1 \dots P_k$ 后，发一个冗余包 $F = P_1 \oplus P_2 \oplus \dots \oplus P_k$。任一包丢失，用 $F$ 和其余 $k-1$ 个异或还原：

$P_i = F \oplus \bigoplus_{j \ne i} P_j$

代价：多发 1 个包（带宽 +$1/k$）。WebRTC 用更灵活的 Reed-Solomon 或 UlpFEC（RFC 5109）做分层冗余。

FEC 适合网络稳定但偶发小丢包的场景（无线网络常见 1-5% 随机丢包）。但 FEC 的冗余是”未丢也付”——好网络下浪费带宽，所以 WebRTC 根据当前丢包率动态调 FEC 强度。

PLI（Picture Loss Indication）

当关键帧（IDR）或它的依赖帧丢失，后续 P 帧全部失参考，解码器彻底失步，画面持续花屏。NACK/FEC 都救不了（太多了）。

这时接收端发 PLI：“我整个画面崩了，请立刻发一个全新的 IDR 关键帧”。

发送端收到 PLI 后强制编码一个 IDR（即使码率控制觉得不该发），解码器用它重置参考帧状态，画面恢复。

代价：IDR 帧很大（比 P 帧大 10×），瞬时码率飙升可能加剧拥塞，形成”丢包→PLI→大帧→更堵”的恶性循环。所以 PLI 是最后手段。

三者如何配合

WebRTC 的丢包恢复是自适应分层：

1. 正常：少量丢包，靠 NACK 补（延迟可承受时）。
2. 网络差：丢包率上升，加大 FEC（提前防御，避免重传延迟）。
3. 彻底崩：失步，PLI 重置。

策略由丢包率、RTT、抖动缓冲深度共同决定。Opus 音频还内置了自己的 FEC（见 B18），独立于视频层的 FEC。

易错点

• NACK 不是 ARQ（虽然机制相似）。NACK 是接收端主动报”丢了”，ARQ 还包括 ACK（确认收到）。RTP 用 NACK-only 是为了省反馈带宽。
• FEC 不是”重传”。FEC 是单向发送，接收端自己恢复，没有往返延迟。这是它在实时场景相对 NACK 的优势——代价是恒定带宽开销。
• PLI 之前通常已发多次 NACK 失败。PLI 不是丢一个包就触发，而是解码器检测到参考帧断裂（IDR 或其依赖丢失）才发。

参考

• RTP/AVPF feedback messages — RFC 4585
• UlpFEC — RFC 5109
• WebRTC FEC & NACK (webrtc.org docs)

抖动缓冲：用延迟换流畅

网络包到达间隔不均匀——有的紧挨着来、有的隔很久。这种到达时间的不一致叫抖动（jitter）。如果来一个播一个，播放会一卡一卡（来慢的瞬间没数据播）。

抖动缓冲（jitter buffer）在接收端故意囤一段时间的数据，再以恒定速率喂给解码器，吸收抖动。

抖动的来源

包在网络里走的延迟 $d_i$ 不是常数，而是 $d_i = \bar d + \delta_i$，其中 $\delta_i$ 是抖动项。来源：

• 路由器排队延迟波动（其他流量抢占带宽）
• 路由变化（不同路径长度不同）
• 物理层重传（无线 Wi-Fi/4G 常见，MAC 层重传耗时几 ms 到几十 ms）

抖动让 RTP timestamp（发送节奏）和到达节奏不同步：

发送: |--包1--|--包2--|--包3--|--包4--|    均匀 20ms
到达: |包1|----包2、3挤一起----|--包4--|    忽快忽慢

缓冲如何工作

播放器维护一个队列，包到达先入队，按 RTP timestamp 顺序出队播放：

包到达 → [JitterBuffer 队列] → 以恒定 20ms 间隔出队 → 解码 → 播放

关键参数是播放延迟 $D_{\text{play}}$——包到达后等多久才播。等的时间 = 缓冲深度。如果 $\delta_{\max}$ 是最大抖动，要 $D_{\text{play}} \ge \delta_{\max}$ 才不卡顿。

跷跷板：延迟 vs 流畅

$\text{流畅性} \uparrow \Leftrightarrow D_{\text{play}} \uparrow \Leftrightarrow \text{延迟} \uparrow$

缓冲越大越流畅（吸收更大抖动），但端到端延迟越大（B04 的 $t_{\text{jbuf}}$ 增大）。缓冲越小越实时，但抖动超过缓冲就卡顿。

这是 WebRTC 最核心的工程权衡之一：

• 通话场景：抖动容忍低（要 200ms 红线），缓冲 20–100 ms。
• 直播场景：延迟容忍高（几秒可接受），缓冲 1–5 秒，画面极流畅。
• 云游戏：延迟极致敏感，缓冲 < 20 ms 甚至去缓冲，靠 FEC/NACK 抗丢包代替。

自适应抖动缓冲

固定缓冲深度既不灵活也浪费——网络好时囤太久没必要，网络差时又不够。WebRTC（如 Google 的 NetEq for audio）用自适应缓冲：

1. 持续测量到达间隔的统计（均值、方差、最大）。
2. 估计满足某分位（如 95%）抖动所需的 $D_{\text{play}}$。
3. 动态调整播放延迟。

调整时为避免”突然变速”导致音调变化，音频用 时间拉伸（WSOLA、PIC 等算法）微调音频长度——轻微拉伸或压缩几毫秒，听感自然，实现平滑过渡。

NetEq：音频抖动缓冲的特殊性

WebRTC 音频用 NetEq（Google 的专利算法），不只是缓冲，还做：

• 加速/减速播放：缓冲太多时快放（不超速、压音高），太少时慢放。
• PLC（Packet Loss Concealment）：包真丢了来不及补，用前一帧的波形外推合成一段”假音频”填补，听感比静音好。

易错点

• 抖动 ≠ 延迟。延迟是 $\bar d$（平均到达时间），抖动是 $\delta$（围绕均值的波动）。低延迟高抖动的链路（如某些卫星）仍需要大缓冲。
• 缓冲深度是”动态目标”不是”固定队列长度”。代码里通常存”目标播放延迟 $D_{\text{play}}$“，队列实际长度会随到达波动，目标是让 $D_{\text{play}}$ 满足当前抖动分布。

参考

• Jitter buffer (维基百科)
• Network Jitter (RFC 3550 §6.3.1)
• NetEq: A New Audio Jitter Buffer (Google)

原始视频有多大：算一笔账

一路未压缩 1080p 视频：

$\underbrace{1920 \times 1080}_{\text{像素}} \times \underbrace{3}_{\text{YUV/RGB 通道}} \times \underbrace{30}_{\text{fps}} \times \underbrace{8}_{\text{比特}} = 1{,}490{,}630{,}400 \text{ bps} \approx 1.49 \text{ Gbps}$

家宽通常 10–100 Mbps，连这一路的零头都传不动。所以必须压缩——而压缩能成功，是因为视频里有海量冗余。

两类冗余：空间与时间

空间冗余（Spatial Redundancy）

一帧画面里相邻像素往往相似——蓝天、白墙、纯色背景，大块区域像素值几乎相同。JPEG 这类帧内压缩就是去这个冗余（DCT 把低频能量集中到少数系数，详见 B13）。一帧能压 10–50 倍。

时间冗余（Temporal Redundancy）

相邻帧之间往往变化很小——背景不动、只有人在动。第 $n$ 帧和第 $n+1$ 帧的差异远小于整帧数据。视频编码器不存整帧，只存差异（残差 residual），这是视频比图片能压更多倍的核心。

数学上，相邻帧的互信息 $I(X_n; X_{n+1})$ 接近帧自身的熵 $H(X_n)$，即 $H(X_{n+1} | X_n) \ll H(X_{n+1})$——给定前一帧，当前帧的”新信息”很少。

运动补偿：时间冗余的利用

光存”差异”还不够，因为画面在动——同一个物体在两帧里位置不同，直接相减残差仍很大。运动补偿（motion compensation）先估计物体的位移，再算位移后的差异：

1. 把当前帧切成小块（宏块，见 B13）。
2. 在参考帧里搜索最相似的块，记录位移向量 $(\Delta x, \Delta y)$——这步叫运动估计（motion estimation）。
3. 用参考帧 + 位移重建一个预测块 $\hat{X}$。
4. 只编码残差 $\epsilon = X - \hat{X}$，残差能量远小于原块。

$\text{码流} = \underbrace{\text{运动向量}(\Delta x, \Delta y)}_{\text{小}} + \underbrace{\text{残差}\,\epsilon}_{\text{远小于整块}}$

这是 H.26x / VPx / AV1 共同的核心思路，带来了 100–1000 倍的压缩比。

压缩比与失真：率失真理论

视频压缩是有损的（lossy）。编码器在码率 $R$ 和失真 $D$ 之间权衡——这是信息论的率失真理论（rate-distortion theory）：

$D(R) = \min_{\text{编码器}} E[\|X - \hat X\|^2] \quad \text{给定码率} \le R$

更狠量化（B13）→ 更低码率但更糊（$D$ 增大）。编码器的任务就是在 $R$ 和 $D$ 之间找最佳折中点，对每个宏块单独决策。

易错点

• “压缩” 不是把每个像素都算一遍。编码器对静态区域用大块（16×16 甚至 64×64，几乎不传残差），细节区域用小块（4×4），自适应选择——这是 H.265/AV1 比 H.264 强的核心改进。
• 时间压缩依赖”参考帧”。一旦参考帧丢失或损坏，所有依赖它的帧都失真（误差传播）。这就是为什么 B08 的 PLI 要重置关键帧——一切从头开始。

参考

• Data compression (维基百科)
• Motion compensation (维基百科)
• Rate-distortion theory

三种帧类型：参考依赖决定延迟

视频码流不是一串同质的帧，而是三种类型的混合，区别在参考关系：

I 帧（Intra-coded，关键帧）

• 自给自足：只用本帧数据解码，不依赖任何其他帧。
• 也叫 IDR（Instantaneous Decoding Refresh）或关键帧（keyframe）。
• 体积大（≈ 帧内 JPEG 压缩，1–100 KB）。
• 作用：随机访问点、错误恢复、解码器初始化。

P 帧（Predictive）

• 单向参考：参考前面的 I/P 帧做预测（运动补偿）。
• 体积小（只存残差 + 运动向量，1–10 KB）。
• 不能独立解码——必须先有参考帧。

B 帧（Bi-directional）

• 双向参考：同时参考前面和后面的帧。
• 体积最小（双向预测更准，残差更小）。
• 代价：要先有”后面那一帧”才能解码当前帧——引入额外延迟和重排序。

为什么 WebRTC 几乎不用 B 帧

B 帧的双向参考要求编码器先有未来帧才编码当前帧，这导致两个问题：

1. 编码延迟：编码器要缓存若干未来帧才能开始编码当前帧。典型的 B 帧结构 I B B P B B P 需要至少 2 帧的”前瞻”（lookahead），在 30fps 下是 66 ms——直接吃掉 B04 的延迟预算。
2. 乱序与重排序：B 帧的解码顺序 ≠ 显示顺序（编码顺序 I P B B，显示顺序 I B B P）。这要求 RTP 按解码顺序发包，接收端解码后再重排序显示——增加缓冲和复杂度。
3. 抗丢包更难：B 帧依赖前后帧，任一参考丢失影响更大；重传延迟也更敏感（要等后续帧）。

对实时通信，省下的那点带宽不值得用 66+ ms 延迟换。所以 WebRTC 的编码器（即使支持 B 帧）默认禁用，只用 I P P P P P ... 的结构：

I P P P P P P P P P I P P P ...   ← 每隔一段来一个 IDR 重置

直播 vs 点播的取舍

• 点播（VOD）：B04 延迟预算宽松（几秒缓冲），大量用 B 帧（H.264 main profile 的 IBBPBBP 结构），压缩效率最高。
• 直播：延迟 1–3 秒，少用 B 帧或单 B 帧。
• 通话/云游戏：延迟 < 200 ms，完全不用 B 帧。

这是同一编码器（如 x264）在不同场景下的配置差异——不是协议限制，是延迟预算决定的工程选择。

关键帧间隔（GOP）

I P P P ... P I P P ... 两个 I 帧之间的距离叫 GOP（Group of Pictures）长度：

• 短 GOP（如 30 帧 = 1 秒）：抗丢包好（PLI 后很快来新 I），随机访问快，但码率高（I 帧多）。
• 长 GOP（如 300 帧 = 10 秒）：压缩效率高，但丢包后误差传播久。

WebRTC 通常用动态 GOP——正常时长时间不主动发 I（节省带宽），只在收到 PLI 或场景切换时才发。

易错点

• IDR 是 I 帧的特殊子类。普通 I 帧仍可能被后续帧参考（不影响参考链）；IDR 强制清空所有参考帧，确保后续 P 帧不会参考 IDR 之前的帧——这是”画面重置”的语义。
• B 帧不是”双向预测必然更好”。在低延迟场景里 B 帧的延迟代价超过它的压缩收益，禁用是更优解。

参考

• Video compression picture types (维基百科)
• GOP, I/P/B frames (FFmpeg docs)

一帧画面变成比特的六步流水线

H.264/VP8/AV1 内部把一帧画面编码成比特的流程高度一致：

帧 → 1.分块 → 2.预测(运动估计) → 3.残差 → 4.变换 → 5.量化 → 6.熵编码 → 比特流

1. 分块（Macroblock / CTU）

把画面切成小方块。H.264 用固定 16×16 的宏块（macroblock）；H.265/AV1 用更大的 CTU（Coding Tree Unit，最大 64×64）并自适应细分（四叉树）。

帧 (1920×1080) → 16×16 宏块 → 8160 个块 (120×68)

每个块独立处理——这是为什么不同区域可以有不同压缩强度（静态大块、动态小块）。

2. 预测：帧内 + 帧间

每个块预测一个估计 $\hat X$，分两种：

• 帧内预测（intra）：用本帧已编码的相邻像素预测（如”这块是水平渐变”）。
• 帧间预测（inter）：在参考帧里搜索最相似的块，记录运动向量 $(\Delta x, \Delta y)$。这步叫运动估计（motion estimation, ME）。

运动估计是计算最重的环节——对每个块在参考帧的搜索窗口里枚举所有位移，算 SAD（Sum of Absolute Differences）：

$\text{SAD}(\Delta x, \Delta y) = \sum_{i,j} |X_{ij} - R_{i+\Delta y,\, j+\Delta x}|$

SAD 最小的位移就是运动向量。1080p 一帧的 ME 计算量极大，硬件编码器靠专用 ASIC 加速。

3. 残差（Residual）

预测值 $\hat X$ 和原值 $X$ 的差：

$\epsilon = X - \hat X$

如果预测准（静态场景），$\epsilon \approx 0$，几乎不传数据。这是压缩的主要来源。

4. 变换（Transform）

对残差做 DCT（离散余弦变换，H.264）或整数近似变换：

$C(u,v) = \sum_{x=0}^{N-1}\sum_{y=0}^{N-1} \epsilon(x,y) \cos\frac{(2x+1)u\pi}{2N} \cos\frac{(2y+1)v\pi}{2N}$

DCT 把图像能量集中到左上角少数低频系数——大部分系数接近 0，便于压缩。直觉：自然图像的低频成分（大面积平滑）能量高，高频成分（细节边缘）能量低。

5. 量化（Quantization）

把变换系数除以量化步长 $Q$ 取整：

$C_q(u,v) = \text{round}\!\left(\frac{C(u,v)}{Q}\right)$

这一步是有损的源头——大量小系数被量化成 0（直接丢弃）。$Q$ 越大压缩越狠、画质越糊。

$Q$ 由 QP（Quantization Parameter）控制，H.264 里 $Q = 2^{(QP-4)/6}$。QP 每加 6，量化步长翻倍；QP 每加 1，码率约降 12.5%（经验法则）。码率控制算法（见 B07 GCC 触发的调整）就是动态选 QP 达到目标码率。

6. 熵编码（Entropy Coding）

把量化后的系数无损压成最短比特。H.264 用 CAVLC 或 CABAC（基于上下文的自适应二进制算术编码）：

• 游程编码（RLC）：把一串 0 压成”连续多少个 0”。
• 算术编码：把整个序列编码成 $[0,1)$ 区间内一个浮点数，理论上达到熵极限。

CABAC 比 CAVLC 压缩率高 5–15%，但计算更重——这是高 profile 的代价。

率失真优化（RDO）

每一步编码器要决策（用什么预测模式、多大块、什么 QP），目标是在码率 $R$ 和失真 $D$ 间最优。H.264 用 RDO（Rate-Distortion Optimization）：

$\min_{\text{模式}} J = D + \lambda R$

拉格朗日乘子 $\lambda$ 由 QP 决定，平衡”画质损失”和”码率开销”。这是编码器性能差距的核心——x264 的 RDO 比简易编码器省 20%+ 码率。

易错点

• 量化是有损，变换是无损。DCT/IDCT 数学上可逆（忽略浮点误差），能量损失发生在量化环节。所以”高 QP = 糊”的根本原因是大量高频系数量化为 0。
• 运动估计不直接压缩，残差才压缩。ME 只是找最像的参考块，让残差尽量小；真正的压缩在残差变换 + 量化 + 熵编码。但 ME 质量直接决定残差大小，间接决定压缩效率。

参考

• H.264/MPEG-4 AVC (维基百科)
• Discrete cosine transform
• CABAC entropy coding (H.264)

NAL 单元：把比特流切成有结构的小包

熵编码产生的比特串本身没有边界——一帧的尾和下一帧的头混在一起。H.264 用 NAL（Network Abstraction Layer）把比特流切成一个个NAL 单元（NALU），每个单元是带类型的自描述块。

Annex-B 起始码分隔

最常见的字节流格式（Annex-B，文件存储用）用起始码（start code）分隔 NALU：

00 00 00 01 | NAL头(1B) | NAL负载(RBSP) | 00 00 00 01 | NAL头(1B) | ...

起始码 00 00 00 01（4 字节）或 00 00 01（3 字节，少见）。它保证在码流里唯一——编码时若负载里出现 00 00 03 就插入一个 03 字节（emulation prevention），破坏假起始码，解码时再去掉。

RTP 装载：不用起始码

WebRTC 走 RTP 时不用 Annex-B 起始码——每个 NALU 直接放进一个 RTP 包的 payload（或用 FU-A 分片大 NALU）。RTP 头部的长度字段已经标明边界，不需要起始码。这是为什么 WebRTC 的 H.264 payload 格式（RFC 6184）和文件的 Annex-B 不同：

文件: SC | NALU1 | SC | NALU2 | ...
RTP:  [RTP头] [NALU1]    单包单 NALU
      [RTP头] [FU-A指示] [NALU1分片1] [NALU1分片2] ...   大 NALU 分片

NAL 类型

NALU 头 1 字节里的 type 字段（5 位）决定负载类型（H.264 表 7-1）：

Type	名称	含义
1	非 IDR 片	普通 P 帧的片（slice）
5	IDR 片	关键帧的片（IDR = I 帧重置参考）
6	SEI	补充增强信息（元数据）
7	SPS	Sequence Parameter Set：分辨率、帧率、编码配置
8	PPS	Picture Parameter Set：量化矩阵、熵编码模式

Type 1 vs 5 的区别：都是”片”数据，但 type 5 是 IDR（强制重置），type 1 是依赖前面参考的普通片。

为什么 SPS/PPS 必须先到

解码器要解码任何片（type 1 或 5），必须先有对应的 SPS 和 PPS：

• SPS 告诉解码器：分辨率 1920×1080、宏块数、帧号范围、参考帧数限制等。
• PPS 告诉解码器：用 CAVLC 还是 CABAC、量化矩阵、默认 QP 等。

没有 SPS/PPS，解码器不知道怎么解释后续比特。所以 WebRTC 协商建立连接后，发送端先发 SPS、PPS，再发 IDR，三者构成可解码的最小集合。PLI（B08）触发重发时也连带重发 SPS/PPS/IDR。

易错点

• NAL ≠ 帧。一帧可能切成多个 NAL（一帧多个 slice，或大 slice 分多个 FU-A 包）。“一个 NAL = 一帧”是常见误解。
• RTP payload 不是 Annex-B。直接把文件里的 H.264 字节流塞进 RTP 会出错（带起始码），必须按 RFC 6184 转 payload 格式。这是 WebRTC 集成常见坑。
• IDR（type 5）和 I 帧（type 1 的 intra slice）不同。普通 I 帧（intra-coded slice）仍是 type 1，不重置参考；IDR 是 type 5，强制清空参考帧缓冲。WebRTC 关键帧请求 PLI 触发的是 IDR。

参考

• H.264 NAL unit structure (ITU-T H.264 §7.4.1)
• RTP Payload Format for H.264 — RFC 6184
• H.264 Bitstream Analysis (Elecard)

NAL 头 1 字节 8 比特位域

NAL 单元头部正好 1 字节，分成 3 个字段：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 
+-+-+-+-+-+-+-+-+
|F|NRI|  Type   |
+-+-+-+-+-+-+-+-+

比特	字段	长度	含义
7	forbidden_zero_bit	1	恒为 0。若为 1 表示该 NALU 有错（如传输错误）
5–6	nal_ref_idc (NRI)	2	重要性：3=最高（参考价值大），0=可丢弃
0–4	nal_unit_type	5	NAL 类型（见 B14 表）

类型字段实例

解码器读 type 字段（低 5 位）决定如何处理：

字节 (hex)	二进制 (F NRI Type)	type	含义
0x67	0 11 00111	7	SPS，NRI=3（最重要）
0x68	0 11 01000	8	PPS，NRI=3
0x65	0 11 00101	5	IDR 片，NRI=3
0x61	0 11 00001	1	非 IDR 片，NRI=3
0x41	0 10 00001	1	非 IDR 片，NRI=2
0x01	0 00 00001	1	非 IDR 片，NRI=0（最低）

验证 0x67 = 0110 0111：bit 7 = 0（forbidden）、bits 5–6 = 11（NRI=3）、bits 0–4 = 00111（type=7）✓。

NRI 决定丢包优先级

NRI 标记这个 NALU 的”参考价值”：

• NRI = 3：SPS/PPS/IDR，丢失会导致大面积失步，必须高优先级保护（FEC、NACK 优先重发）。
• NRI = 1–2：被参考的 P 帧。
• NRI = 0：不被参考（如 B 帧、非参考 P 帧），丢了影响小，可以优先丢。

WebRTC 在拥塞时可以按 NRI 优先级丢包——先丢 NRI=0 的（影响小），保住 NRI=3 的（关键帧和参数集）。这就是不同 NALU 字节不同的原因：编码器事先标记好重要性，让传输层据此调度。

位域的高效性

用位域（bit field）而不是整数标记类型，是为了省字节——NAL 头只占 1 字节，对大量小 NALU（每帧几十个）累积可观。H.265 把头扩到 2 字节是因为类型空间不够（新增更多 slice 类型、 temporal layer 等）。

FU-A 分片头

大 NALU（如关键帧几十 KB）超过 MTU（约 1200 字节）时，WebRTC 用 FU-A（Fragmentation Unit type A）把它切成多个 RTP 包：

每个分片 RTP payload = [FU-A 指示字节(1B)] [FU-A 头(1B)] [NALU 分片数据]
FU-A 头: |S|E|R| Type|
         S=1 首片, E=1 尾片, R 保留, Type 是原 NAL 类型

接收端按 S/E 标记重组：收齐所有分片后拼回完整 NALU。中间分片丢失则整个 NALU 作废（依赖它的帧失真）。

易错点

• 读 NAL 头要先做 emulation prevention 移除。码流里的 00 00 03 要去掉 03 还原 00 00，否则会把 03 误读进头部。但 NAL 头本身在最前面，不会被 prevention 影响——影响的是 RBSP（负载）部分。
• type 1 也可能是 IDR？不，IDR 严格是 type 5。但 type 1 的片可能用帧内预测（intra slice，不依赖参考），看起来像 I 帧——区别在是否重置参考帧缓冲。NAL type 区分的是”片在参考链里的角色”，不是”宏块是否帧内编码”。

参考

• H.264 NAL header syntax (ITU-T H.264 §7.4.1)
• RFC 6184 §5: RTP Payload Format for H.264
• [H.264 Bitstream Wizard (在线分析工具)](https:// annexb.com / https://github.com/ireader/media-server)

视频编码器的代际更替

WebRTC 支持多种视频编码器，候选双方协商（SDP offer/answer）选一个：

编码器	发布	压缩效率	硬件支持	专利
H.264 (AVC)	2003	基准	几乎所有设备	收费（MPEG-LA）
VP8	2008	≈ H.264	较广	免费（Google）
H.265 (HEVC)	2013	≈ H.264 的 2×	主流设备	收费，专利混乱
VP9	2013	≈ H.265	Chrome/Android	免费
AV1	2018	≈ H.265 的 1.3×，比 VP9 强 30%	普及中	免费（AOMedia）

H.264：兜底默认

H.264 是事实标准——几乎所有设备（手机、PC、IoT）都有硬件编解码。WebRTC 把 H.264 作为强制支持的基线，确保任意两端能联通。即使效率不如新编码器，它的”通”价值无可替代。

专利上 H.264 受 MPEG-LA 收费，但浏览器厂商（通过授权）对终端用户免费。

VP8/VP9：免版税方案

Google 收购 On2 后开源 VP8（2010），作为 H.264 的免费替代。VP8 在 Chrome/Android 上硬件支持广，Firefox 也支持。

VP9 是 VP8 的下一代（YouTube 默认），压缩效率追上 H.265，且支持分层编码（SVC，见 B17）——这对多人会议很有用。

AV1：新王

AV1 由 AOMedia（Google、Mozilla、Cisco、Amazon、Netflix、Microsoft 等）2018 年发布，目标”比 VP9 节省 30% 码率，比 H.265 也强”。特点：

• 完全免专利费——这是针对 H.265 专利混乱（HEVC Advance 专利池事件）的直接回应。
• 压缩率最高——同等画质下比 H.264 省 50%+ 带宽。
• 代价：编码复杂度极高——AV1 软编比 H.264 慢 10–100×，硬件解码器 2023 年起才在主流 GPU 普及。

WebRTC 把 AV1 作为可选编码器，双方都支持时优先用。

协商：SDP offer/answer

WebRTC 建立连接时通过 SDP（Session Description Protocol）交换能力：

Offer: a=rtpmap:96 H264/90000
       a=rtpmap:97 VP8/90000
       a=rtpmap:98 AV1/90000
Answer: a=rtpmap:96 H264/90000    ← 只选 H.264（不支持其他）

双方取交集，按优先级选最高的共同支持编码器。这就是为什么有时高清有时糊——协商结果是 H.264 还是 AV1 直接决定同样带宽下的画质。

为什么 H.265 几乎不在 WebRTC 里

H.265 压缩效率好但：

1. 专利混乱：多个专利池（MPEG-LA、HEVC Advance、Technicolor）收费不透明，浏览器厂商（尤其 Mozilla、Google）拒绝支持。
2. 实时编码复杂度高：H.265 的 CTU + 复杂预测模式让实时编码延迟大。
3. AV1 抢了位置：免费的 AV1 在效率上不输 H.265，浏览器厂商直接跳过 H.265 做 AV1。

所以 WebRTC 主流是 H.264（兜底）+ VP8/VP9（Google 系）+ AV1（新王），H.265 几乎缺席。

易错点

• “AV1 总是最好”——不。AV1 软编吃 CPU，低端设备上实时编码可能掉帧；硬件解码不普及的旧设备无法播。协商时若对方不支持 AV1，必须降级。
• 编码器 ≠ 协议。H.264/VP8/AV1 是编码标准，RTP/SRTP 是传输协议。同一 RTP 通道可以传不同编码器的码流，靠 PT（payload type，B06）区分。

参考

• H.264, H.265, VP9, AV1 对比 (维基百科)
• AV1 (AOMedia Video 1)
• WebRTC media codec requirements (W3C)

SVC：一路码流多层结构

SVC（Scalable Video Coding）让单路码流里嵌套多层，接收端按网络能力取不同子集：

• 时间层（Temporal）：帧率分层。底层 = 关键帧 + 少量 P，加层 = 更多 P 帧。
• 空间层（Spatial）：分辨率分层。底层 = 360p，加层 = 720p，再上 = 1080p。
• 质量层（SNR/Quality）：同分辨率不同 QP。底层粗略，加层细节。

每层依赖下层（不能丢底层用上层），所以丢上层保底层总能得到可解码的（低质量）画面。

时间 SVC 示例

VP9 / AV1 的典型时间分层（3 层，目标 30fps）：

帧:   T0    T2    T1    T2    T0    T2    T1    T2    T0
层:    0     2     1     2     0     2     1     2     0
      IDR         P           P             P           IDR
 fps:  3.75        7.5         7.5          7.5         ← 只收 T0
       11.25                   11.25                    ← 收 T0+T1
       30                                                ← 收 T0+T1+T2

• T0 层（3.75fps）：只有关键帧 + 每 8 帧一个 P，极流畅但卡。
• T0+T1（11.25fps）：流畅很多。
• T0+T1+T2（30fps）：完整帧率。

关键性质：T2 帧只依赖 T0/T1，丢掉 T2 不影响 T0/T1 解码。服务器只转发 T0 给网络差的客户端，画面变成 3.75fps 但不卡顿不花屏。

多人会议的杀手锏

传统会议：每个人要发 N 路码流给 N 个接收者（或者 SFU 服务器转码）。带宽和 CPU 都爆炸。

SVC 方案：每个人只发一路 SVC 码流（含所有层），SFU（Selective Forwarding Unit）服务器不转码，只按每个接收者的能力选择性转发：

发送端 A → [T0 T1 T2 全层] → SFU
                         ├→ 给网络好的 B：转发 [T0 T1 T2]（30fps 高清）
                         ├→ 给网络差的 C：只转发 [T0]（3.75fps 流畅）
                         └→ 给移动端 D：转发 [T0 T1]（中等）

服务器只做”按需丢层”的转发，零编码成本——这就是大型视频会议（Zoom、Google Meet）能扛几十人的核心机制。

SVC vs Simulcast

两种相关但不同的技术：

• SVC：单路码流嵌层，层之间有依赖（T2 依赖 T1）。
• Simulcast：发送端并行发多路独立码流（360p / 720p / 1080p 各一路），服务器选一路转发。

SVC 带宽更省（层间共享数据），但编码更复杂；Simulcast 编码简单（多路独立编码），但带宽 ×3。WebRTC 同时支持两者，VP9/AV1 偏 SVC，H.264 因不支持 SVC 通常用 Simulcast。

空间 SVC 的难点

时间 SVC 容易（只是丢帧），空间 SVC（多分辨率嵌套）技术上难——下层用低分辨率预测，上层要用上采样，编码效率有损。所以实际产品多用 Simulcast 模拟空间可分层（发多路不同分辨率），SVC 主要用于时间分层。

易错点

• SVC 不是”码流可变分辨率”魔法。底层和上层是预编码时确定的，接收端只能取已编码的层，不能任意插值（如不能从 360p SVC 码流取出 500p）。
• 丢层有顺序：必须丢上层保下层（T2→T1→T0），不能反过来。丢 T0 会让 T1/T2 全部失参考。
• SVC 抗丢包 ≠ FEC。SVC 是”丢一层还能播低质量”，FEC 是”丢包补回来”。两者正交，可以同时用。

参考

• Scalable Video Coding (维基百科)
• VP9 SVC (Google)
• SFU architecture (WebRTC)

Opus：实时音频的统治级编码器

Opus（RFC 6716，Xiph.Org + Skype/Microsoft 联合开发）是 IETF 标准化的音频编码器，几乎垄断实时音频。WebRTC 强制要求支持 Opus。它的优势集中在四点：

1. 极低算法延迟

编码器	典型帧长	算法延迟
MP3	26 ms	50+ ms
AAC	20 ms	40+ ms
Opus	2.5–60 ms 可选	5 ms（语音模式）

Opus 的算法延迟 = 帧长 + 滤波器开销，最短可到 5 ms。这是通话可接受的关键——MP3/AAC 那种几十 ms 延迟在实时场景直接出局。

2. 码率范围极广

Opus 单一编码器覆盖 6 kbps 到 510 kbps：

• 6–16 kbps：窄带语音（NB，8kHz 采样）——极低带宽（如卫星电话）。
• 16–40 kbps：宽带语音（WB，16kHz）。
• 40–64 kbps：超宽带/全带语音（SWB/FB，48kHz）——VoIP 标准。
• 64–510 kbps：音乐模式（FB + 立体声）——接近透明音质。

一个编码器从电话音质到 CD 音质通吃，没有切换编码器的麻烦。

3. SILK + CELT 双引擎

Opus 内部是两个编码器的智能切换：

• SILK（来自 Skype）：专为语音优化，处理 8–24kHz，用 LPC（线性预测编码）建模人声声道——语音清晰、低码率。
• CELT（来自 Xiph）：专为音乐和瞬态优化，处理 32–48kHz，用 MDCT（改进离散余弦变换）保高频细节——音乐透明。

编码器实时分析输入：人声为主用 SILK，音乐/复杂声音用 CELT，也可以两者混合（低频 SILK + 高频 CELT）。这是 Opus “语音音乐通吃”的技术根源。

4. 内置 FEC：抗丢包

Opus 自带 in-band FEC：当前帧预测下一帧可能丢，在当前帧里嵌入下一帧的低码率副本。下一帧真丢了，用上一帧里的副本恢复（音质略降但无断音）。

这与 B08 的 RTP 层 FEC 不同——Opus FEC 在编码器内部、对每个包自适应、带宽开销精确控制（只在丢包率高时启用）。接收端解码 Opus 时自动检测并使用 FEC。

DTX：静音压缩

DTX（Discontinuous Transmission）：检测到静音时停止发包，只周期性发一个 SID（Silence Insertion Descriptor）帧描述背景噪声特性。接收端用 SID 合成”舒适的背景噪声”（comfort noise），听感自然。

通话里平均有 50% 时间某方在静音（对方说话时你不出声），DTX 直接省 50% 音频带宽。这就是为什么”我不说话时网络流量明显下降”。

易错点

• Opus 不等于”无延迟”。5 ms 是算法延迟（编码 + 解码），端到端还要加网络延迟 + 抖动缓冲（B09）几十 ms。整体仍受 B04 的延迟预算约束。
• DTX 让”卡顿感”不同。静音时不发包，恢复说话的第一个包若丢失，接收端长时间无声（没有 comfort noise 衔接）——这是 DTX 的副作用，需要 Opus 的 PLC（丢包隐藏）配合。
• Opus FEC 是可选的，由发送端配置 useinbandfec=1。不启用时退化为 RTP 层 FEC 或纯 NACK。

参考

• Opus codec — RFC 6716
• Opus 官方网站 (opus-codec.org)
• Opus application (VoIP vs Audio)