3、音频编解码器深度解析：Opus、G.711、iLBC 的原理与选择

做 WebRTC 音频同步，绕不开编解码器。说白了，你选的编码器直接决定了音频包的体积、延迟和抗丢包能力。我见过不少团队花大量精力调网络、调缓冲，结果发现是编码器选错了——嗯，这种坑踩一次就够了。

今天咱们就把 WebRTC 里最常见的三种编码器掰开揉碎讲清楚：Opus、G.711、iLBC。它们各自适合什么场景？原理上有什么差异？怎么选？

3.1 Opus：WebRTC 的瑞士军刀

Opus 是 IETF 标准化的开源编码器，也是 WebRTC 的强制实现编码器。我个人习惯把它叫做「音频界的万能胶」——它既能做语音，也能做音乐，还能在极低延迟下保持高质量。

为什么 Opus 这么强？因为它内部其实是两个编码器的混合体：

• SILK：基于线性预测，擅长语音，低比特率下表现好
• CELT：基于 MDCT 变换，擅长音乐和通用音频

Opus 会根据输入信号自动切换或混合这两种模式。你想想看，一个编码器能同时覆盖 6 kbps 到 510 kbps 的比特率范围，延迟还能低到 5 ms——这在几年前简直不敢想。

Opus 还有一个杀手锏：丢包隐藏（PLC）。当网络丢包时，Opus 会利用前一帧的数据预测当前帧的内容。我在项目中遇到过 20% 的丢包率，Opus 依然能保持可懂度——换成 G.711 早就断断续续了。

3.2 G.711：老当益壮的 PCM 编码

G.711 是 ITU-T 在 1972 年制定的标准，说白了就是最原始的脉冲编码调制（PCM）。它把模拟信号直接量化成 8 位采样，采样率 8 kHz，比特率固定 64 kbps。

为什么 WebRTC 还要支持这么老的编码器？两个原因：

1. 兼容性：很多老旧的 PBX 电话系统和 PSTN 网络只认 G.711
2. 低延迟：G.711 的编码延迟只有 0.125 ms，几乎是零延迟

但 G.711 的缺点也很明显：

• 比特率固定 64 kbps，带宽占用大
• 几乎没有抗丢包能力，丢一个包就是一段噪音
• 只支持 8 kHz 采样率，音质上限低

G.711 有两种压扩方式：μ-law（北美/日本）和 A-law（欧洲/中国）。WebRTC 默认使用 A-law，但两端协商时会自动匹配。

3.3 iLBC：为丢包而生的编码器

iLBC（Internet Low Bitrate Codec）是 Global IP Sound 开发的免费编码器，后来被 Google 收购并开源。它的设计目标很明确：在丢包环境下保持语音可懂度。

iLBC 的核心原理是帧独立编码。每个 20 ms 或 30 ms 的音频帧都是独立编码的，不依赖前后帧。这意味着即使丢了一帧，也不会影响其他帧的解码。

对比一下：

特性	Opus	G.711	iLBC
比特率	6-510 kbps	64 kbps 固定	13.3/15.2 kbps
编码延迟	5-60 ms	0.125 ms	30-40 ms
采样率	8-48 kHz	8 kHz	8 kHz
抗丢包	优秀（PLC）	差	优秀（帧独立）
复杂度	高	极低	中
适用场景	通用实时通信	老系统兼容	高丢包网络

iLBC 的比特率只有 13.3 kbps（30 ms 帧）或 15.2 kbps（20 ms 帧），比 G.711 省了 4 倍带宽。但它的编码延迟较高，30-40 ms 的延迟在实时通话中已经算偏大了。

3.4 如何选择？

选编码器其实就是在带宽、延迟、质量、兼容性之间做权衡。我一般按这个思路来：

• 默认选 Opus：WebRTC 官方推荐，绝大多数场景都能胜任
• 需要兼容老系统时用 G.711：比如对接 SIP 网关、传统 PBX
• 高丢包弱网环境用 iLBC：帧独立编码的特性在丢包 10% 以上时优势明显

还有一个细节：WebRTC 的 SDP 协商中，编码器的优先级是可以调整的。你可以把 Opus 放在第一位，G.711 和 iLBC 作为备选。这样两端协商时会优先使用 Opus，如果对方不支持再降级。