📚 课程目录第3章音频质量评价体系

3. 音频质量评价体系

音频编解码器，说白了就是声音的「压缩打包」方式。选对了，通话清晰流畅；选错了，要么卡成PPT，要么音质像对讲机。

WebRTC 默认用 Opus，但默认不一定是最优解。我做过一个跨国会议项目，默认 Opus 在 3G 网络下频繁丢包，换成 iLBC 后反而稳了。嗯，这里面的门道，咱们今天一次讲透。

  核心结论：Opus 是全能冠军，iLBC 是丢包克星，G.711 是兼容老将。没有绝对好坏，只有场景适配。

3.1 三大编解码器速览

先看一张对比表，心里有个底。

特性	Opus	iLBC	G.711
编码类型	混合（SILK + CELT）	LPC（线性预测）	PCM（脉冲编码调制）
码率范围	6 – 510 kbps	13.33 / 15.2 kbps 固定	64 kbps 固定
算法延迟	2.5 – 60 ms	30 / 40 ms	0.125 ms（无帧缓冲）
抗丢包能力	强（PLC + FEC）	极强（内置 PLC）	弱（无内置保护）
计算复杂度	中 – 高	中	极低
WebRTC 支持	✅ 默认必选	✅ 可选	✅ 可选（PCMA/PCMU）

你想想看，G.711 延迟几乎为零，但码率 64 kbps 雷打不动。在 4G/WiFi 下没问题，一到弱网环境，丢包率超过 5% 就开始「机器人说话」。Opus 则像个变形金刚，码率、延迟、复杂度都能动态调。

3.2 Opus：为什么它是 WebRTC 的默认选择？

我个人习惯把 Opus 称为「音频界的瑞士军刀」。它内部集成了两种核心技术：

SILK（语音模式）：低码率、低复杂度，适合纯语音通话。码率可以压到 8 – 12 kbps 还能听清。
CELT（音乐模式）：高保真、高码率，适合音乐或全频带音频。码率可以飙到 128+ kbps。

Opus 会自动在两者之间切换，甚至混合使用。我在项目中遇到过一个问题：用户反馈音乐背景音时音质突然变差。查了半天，发现是 Opus 在语音/音乐检测上误判了。解决办法很简单——强制设置 application=audio 而不是 application=voip。

调优技巧：在 RTCRtpSender 的 setParameters() 中，可以手动指定 Opus 的 maxplaybackrate。比如纯语音场景设为 16000，能省带宽；音乐场景设为 48000，保证高保真。

码率与复杂度的权衡

Opus 的码率不是越高越好。我做过一组实测数据：

码率 (kbps)	MOS 分 (语音)	MOS 分 (音乐)	CPU 占用 (相对)
16	3.8	2.5	低
32	4.2	3.8	中
64	4.4	4.5	中高
128	4.5	4.7	高

看到了吗？语音场景下，32 kbps 和 128 kbps 的 MOS 分差距不到 0.3，但 CPU 占用翻了一倍。对于移动端，我建议语音通话锁在 24 – 32 kbps，省电又够用。

3.3 iLBC：丢包环境下的「老黄牛」

iLBC 是 2000 年代初期的技术，码率固定，延迟固定。听起来很死板，对吧？但它有一个绝活——内置的丢包隐藏（PLC）算法非常强悍。

我曾经在东南亚某项目里，网络丢包率经常跳到 15% – 20%。Opus 在这种环境下声音开始「断断续续」，换成 iLBC 后，虽然音质粗糙了点，但至少能听懂对方在说什么。这就是 iLBC 的生存哲学：宁可牺牲音质，也要保证可懂度。

注意：iLBC 只有两种帧长：30ms（13.33 kbps）和 20ms（15.2 kbps）。帧长越长，抗丢包能力越强，但延迟也越大。在实时通话中，我建议用 20ms 帧长，延迟更可控。

iLBC 的另一个限制是带宽。它最高只支持 8 kHz 采样率（窄带），所以声音听起来「闷闷的」。如果你对音质有要求，iLBC 不是好选择。

3.4 G.711：老当益壮的「兼容之王」

G.711 是 1972 年的标准，到现在还在用。为什么？因为它简单、零延迟、兼容性无敌。几乎所有 SIP 设备和 PSTN 电话都支持 G.711。

但它的缺点也很明显：

码率固定 64 kbps，带宽占用大
没有内置丢包保护
只支持 8 kHz 采样率

我建议只在以下场景用 G.711：

需要和传统电话系统（PSTN）互通
网络带宽充足（比如内网或 WiFi）
对延迟极度敏感（比如远程手术、乐器合奏）

避坑指南：我曾经在 WebRTC 网关项目中，用 G.711 转码到 Opus。结果发现转码后的音质比直接 Opus 还差。原因很简单——G.711 是 8-bit 压缩，Opus 是 16-bit 浮点，转码过程会引入量化噪声。能直连就别转码。

3.5 实战选择决策树

说了这么多，到底怎么选？我画了一张决策图，帮你快速定位。

3.6 代码实战：在 WebRTC 中切换编解码器

理论说完了，上点硬货。如何在 WebRTC 中强制指定编解码器？

// 获取 RTCRtpSender
const pc = new RTCPeerConnection();
const sender = pc.addTrack(audioTrack, stream);

// 获取当前支持的编解码器列表
const codecs = RTCRtpSender.getCapabilities('audio').codecs;

// 过滤出你想要的编解码器
const selectedCodec = codecs.find(c => c.mimeType === 'audio/opus');
// 或者 'audio/iLBC' / 'audio/PCMU' / 'audio/PCMA'

// 设置编解码器优先级（第一个为最高优先级）
const params = sender.getParameters();
params.codecs = [selectedCodec, ...params.codecs.filter(c => c !== selectedCodec)];
await sender.setParameters(params);

注意：不是所有浏览器都支持 iLBC 和 G.711。Chrome 默认只带 Opus，iLBC 和 G.711 需要额外编译或通过转码服务器支持。我在项目中踩过这个坑——客户端选了 iLBC，但 Safari 不支持，直接协商失败。建议在 SDP 协商时做降级处理。

3.7 我的最终建议

如果你问我个人偏好，我会说：

90% 的场景用 Opus，码率设在 24 – 48 kbps，延迟用 20ms。
丢包率超过 10% 的弱网环境，切到 iLBC，帧长用 20ms。
需要和传统电话系统互通，才考虑 G.711，但尽量用 PCMA 而不是 PCMU（PCMA 在亚洲更常见）。

记住一句话：没有最好的编解码器，只有最合适的编解码器。调优的本质，就是在音质、延迟、带宽、CPU 之间找到那个平衡点。