音频编解码器 · Opus 与它的超能力
WebRTC 音频几乎都用 Opus——一个万能编解码器：码率 6 到 510 kbps 无级可调、内建 FEC 抗丢包、静音时 DTX 省带宽、语音音乐通吃。这一章讲清 Opus 的这些超能力、AudioEncoder/AudioDecoder 抽象，以及为什么它是实时音频的理想选择。
音频编解码器 · Opus 与它的超能力
音频要传，先得压缩。WebRTC 支持几种音频编解码器，但主力几乎只有一个——Opus。它是为实时通信量身打造的“万能编解码器”，一身超能力。这一章看它，以及音频编解码器的抽象。
AudioEncoder / AudioDecoder 抽象
和视频一样，音频编解码器藏在统一抽象后：AudioEncoder / AudioDecoder（api/audio_codecs/）。上层ACM 只面对这个接口，不关心具体是 Opus 还是 G.711。编解码器由工厂（可在依赖里替换）创建，SDP 协商时取交集决定用哪个。抽象让 WebRTC 能支持多种编解码器，但实践中——Opus 一枝独秀。
Opus：一个顶一堆
Opus（RFC 6716）是 IETF 标准的开源编解码器，几乎是实时音频的标准答案：
Opus 的超能力，是“万能 + 自适应”：一个编解码器覆盖从窄带语音到高保真音乐的全部场景，且几乎每个参数都能实时调。
- 码率无级可调（6~510 kbps） —— 从几 kbps 的能听清的语音，到几百 kbps 的高保真音乐，同一个编解码器平滑覆盖。拥塞控制一变码率，Opus 立刻跟着调，无需换编解码器。
- 语音 + 音乐通吃 —— 内部融合了两种技术（语音用 SILK、音乐 / 高频用 CELT），自动适配内容。开会说话、放段音乐，它都行。
- 低延迟 —— 帧长可低至几毫秒，适合实时对话。
- 内建 FEC —— in-band FEC：在下一个包里编码一份上一个包的低码率副本。丢一个包，下一个包里带着它的备份，直接补上——音频抗丢包的利器，无需额外的 FEC 流。
- DTX（不连续传输） —— 你不说话时（静音），Opus 停止发送或只发极少的“舒适噪声”参数，省下大量带宽。会议里大部分时间你在听不在说，DTX 就一直在省。
一个 Opus，把“该多清晰、抗不抗丢包、静音省不省”全包了——这种全能和自适应，正是实时通信要的。所以 WebRTC 里音频编解码协商几乎总是选 Opus。
老兵：G.711
WebRTC 也支持 G.711（PCMU / PCMA，即 μ-law / A-law）——最老的数字语音编解码器（1972 年！），固定 64 kbps、几乎不压缩、静态 payload type。它音质一般、费带宽，但兼容一切（所有电话系统都懂），所以留作和传统电话网（PSTN）互通的保底。日常 WebRTC 通话不会用它，但和电话网关对接时它是通用语。
音频编码的特点：小、密、弱依赖
对比视频，音频编码有几个决定后续设计的特点：
- 包小 —— 一个 20ms 的 Opus 包才几十到几百字节（一个 RTP 包装得下），不像视频一帧要切几十个包。
- 包密 —— 每 20ms 一个，一秒 50 个，很频繁。
- 帧间依赖弱 —— Opus 帧基本自解码（不像视频强依赖参考帧）。所以丢一个音频包，只影响那 20ms，不会像视频那样毁一串。
小结与下一章
音频编解码器藏在 AudioEncoder/AudioDecoder 抽象后，协商取交集——而主力几乎只有 Opus：码率 6~510 kbps 无级可调、语音音乐通吃、低延迟、内建 in-band FEC（下包带上包副本抗丢包）、DTX（静音省带宽）。G.711 老而全兼容，留作和电话网互通的保底。音频编码“包小、密、弱依赖”的特点，让接收侧能玩丢包隐藏和时间伸缩——这是和视频分道的根本。
编解码器接进来，由 ACM 统管。下一章看 ACM。👉 ACM 音频编码模块。
参考资料
- [1] libwebrtc 源码.
api/audio_codecs/audio_encoder.h、audio_decoder.h、modules/audio_coding/codecs/opus/。 - [2] IETF RFC 6716「Opus」、RFC 3551「G.711」。
- [3] Opus 项目.https://opus-codec.org/