# 音频编解码器 · Opus 与它的超能力

> WebRTC 音频几乎都用 Opus——一个万能编解码器：码率 6 到 510 kbps 无级可调、内建 FEC 抗丢包、静音时 DTX 省带宽、语音音乐通吃。这一章讲清 Opus 的这些超能力、AudioEncoder/AudioDecoder 抽象，以及为什么它是实时音频的理想选择。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-10-01
- 原文：https://daiw.org/manual/webrtc/audio-codecs
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 音频编解码器 · Opus 与它的超能力

音频要传，先得压缩。WebRTC 支持几种音频编解码器，但**主力几乎只有一个——Opus**。它是为实时通信量身打造的“万能编解码器”，一身超能力。这一章看它，以及音频编解码器的抽象。

## AudioEncoder / AudioDecoder 抽象

和[视频一样](https://daiw.org/manual/webrtc/video-encoder-abstraction)，音频编解码器藏在统一抽象后：**`AudioEncoder`** / **`AudioDecoder`**（`api/audio_codecs/`）。上层[ACM](https://daiw.org/manual/webrtc/acm) 只面对这个接口，不关心具体是 Opus 还是 G.711。编解码器由**工厂**（[可在依赖里替换](https://daiw.org/manual/webrtc/factory-and-context)）创建，[SDP 协商时取交集](https://daiw.org/manual/webrtc/media-session)决定用哪个。抽象让 WebRTC 能支持多种编解码器，但实践中——**Opus 一枝独秀**。

## Opus：一个顶一堆

**Opus**（RFC 6716）是 IETF 标准的开源编解码器，几乎是实时音频的标准答案：

<Callout type="info">
  **Opus 的超能力，是“万能 + 自适应”：一个编解码器覆盖从窄带语音到高保真音乐的全部场景，且几乎每个参数都能实时调。**

  - **码率无级可调（6~510 kbps）** —— 从几 kbps 的能听清的语音，到几百 kbps 的高保真音乐，**同一个编解码器**平滑覆盖。[拥塞控制](https://daiw.org/manual/webrtc/rate-control)一变码率，Opus 立刻[跟着调](https://daiw.org/manual/webrtc/video-encoder-abstraction)，无需换编解码器。
  - **语音 + 音乐通吃** —— 内部融合了两种技术（语音用 SILK、音乐 / 高频用 CELT），自动适配内容。开会说话、放段音乐，它都行。
  - **低延迟** —— 帧长可低至几毫秒，适合实时对话。
  - **内建 [FEC](https://daiw.org/manual/webrtc/fec)** —— **in-band FEC**：在下一个包里编码一份上一个包的低码率副本。丢一个包，下一个包里带着它的备份，直接补上——[音频抗丢包](https://daiw.org/manual/webrtc/fec)的利器，无需额外的 [FEC 流](https://daiw.org/manual/webrtc/fec)。
  - **DTX（不连续传输）** —— 你不说话时（静音），Opus **停止发送**或只发极少的“[舒适噪声](https://daiw.org/manual/webrtc/neteq-operations)”参数，**省下大量带宽**。会议里大部分时间你在听不在说，DTX 就一直在省。

  **一个 Opus，把“该多清晰、抗不抗丢包、静音省不省”全包了**——这种全能和自适应，正是实时通信要的。所以 WebRTC 里[音频编解码协商](https://daiw.org/manual/webrtc/media-session)几乎总是选 Opus。
</Callout>

## 老兵：G.711

WebRTC 也支持 **G.711**（PCMU / PCMA，即 μ-law / A-law）——最老的数字语音编解码器（1972 年！），固定 64 kbps、几乎不压缩、[静态 payload type](https://daiw.org/manual/webrtc/payload-types)。它音质一般、费带宽，但**兼容一切**（所有电话系统都懂），所以留作和传统电话网（PSTN）互通的**保底**。日常 WebRTC 通话不会用它，但和电话网关对接时它是通用语。

## 音频编码的特点：小、密、弱依赖

对比[视频](https://daiw.org/manual/webrtc/video-encoder-abstraction)，音频编码有几个决定后续设计的特点：

- **包小** —— 一个 20ms 的 Opus 包才几十到几百字节（[一个 RTP 包装得下](https://daiw.org/manual/webrtc/rtp-packet)），不像视频[一帧要切几十个包](https://daiw.org/manual/webrtc/video-packetization)。
- **包密** —— 每 20ms 一个，一秒 50 个，很频繁。
- **帧间依赖弱** —— Opus 帧基本**自解码**（不像视频[强依赖参考帧](https://daiw.org/manual/webrtc/frame-reference-finder)）。所以丢一个音频包，**只影响那 20ms**，不会像视频那样[毁一串](https://daiw.org/manual/webrtc/video-decode-recovery)。

<Callout type="info">
  **“包小、密、弱依赖”这三个特点，直接塑造了音频接收侧的设计。** 正因为丢一个包只毁 20ms、且语音[短时可预测](https://daiw.org/manual/webrtc/neteq-plc)，音频才能玩[丢包隐藏（PLC）](https://daiw.org/manual/webrtc/neteq-plc)——[编造](https://daiw.org/manual/webrtc/neteq-plc)那 20ms 以假乱真的填充；正因为包密而小，音频才能做精细的[时间伸缩](https://daiw.org/manual/webrtc/neteq-timestretch)（拉伸 / 压缩几毫秒）来[微调播放节奏](https://daiw.org/manual/webrtc/neteq-buffer-delay)。这些精细手段的舞台，就是下面要讲的 [NetEq](https://daiw.org/manual/webrtc/neteq-overview)。**编解码器的特性，决定了抖动缓冲的玩法**——音频和视频在这里彻底分道。
</Callout>

## 小结与下一章

音频编解码器藏在 **`AudioEncoder`/`AudioDecoder`** 抽象后，[协商取交集](https://daiw.org/manual/webrtc/media-session)——而主力几乎只有 **Opus**：码率 **6~510 kbps 无级可调**、**语音音乐通吃**、低延迟、**内建 [in-band FEC](https://daiw.org/manual/webrtc/fec)**（下包带上包副本抗丢包）、**DTX**（静音省带宽）。**G.711** 老而全兼容，留作和电话网互通的保底。音频编码“**包小、密、弱依赖**”的特点，让接收侧能玩[丢包隐藏](https://daiw.org/manual/webrtc/neteq-plc)和[时间伸缩](https://daiw.org/manual/webrtc/neteq-timestretch)——这是和视频分道的根本。

编解码器接进来，由 ACM 统管。下一章看 ACM。👉 [ACM 音频编码模块](https://daiw.org/manual/webrtc/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/