6.5.4 Opus：为实时互动而生（Opus, RFC 6716）

互动场景的苛刻约束

VoIP、视频会议、在线游戏语音，对音频编码提出了一组与音乐分发截然不同的要求 [14]：

• 算法延迟必须极低：往返延迟超过约 150 ms 就会明显干扰对话节奏，编码器自身只允许贡献毫秒级——MP3/AAC 的长窗设计（数百毫秒流水线）直接出局
• 内容混合：语音与音乐随时交替（通话中放歌），单一优化方向的编码器必然偏科
• 码率与网络自适应：丢包、抖动、带宽波动是常态，编码器要能无级变速

2012 年，IETF 以 RFC 6716 标准化的 Opus 就是这份考卷的答卷——由 Xiph.Org 与 Skype（彼时属 Microsoft）联手，开源且免版税。

混合架构：SILK + CELT

Opus 的解法别具一格：不是折中，而是双修——内置两套引擎，按内容与码率自动切换甚至叠加 [14]：

• SILK：源自 Skype 的语音编码器。基于 LPC（线性预测编码） 的声道模型——把语音建模为 "激励源 + 声道滤波器"（回忆 5.2.2 的线性预测分析），对 8~24 kHz 采样率的语音高效而低延迟
• CELT（Constrained Energy Lapped Transform）：Xiph 为低延迟音乐编码设计的变换编码器。MDCT 家族，但帧长可短至 2.5 ms，以能量守恒为核心的快速比特分配——音乐内容与高频成分的保障

两者的协同分三档：低码率语音走纯 SILK，高码率音乐走纯 CELT，中间地带（如带背景音乐的语音）则 混合模式——SILK 处理低频语音成分，CELT 接管 8 kHz 以上的高频。

灵活的规格参数

Opus 的参数空间几乎是为 "自适应" 量身定制：

• 帧长：2.5 / 5 / 10 / 20 / 40 / 60 ms 六档，延迟与效率按需取舍
• 码率：6 ~ 510 kbit/s 连续可调，单声道到 255 声道
• 采样率：8 / 12 / 16 / 24 / 48 kHz 五档，窄带电话到全频带音乐全覆盖

配合内置的 FEC（前向纠错） 与丢包隐藏（PLC）设计，Opus 成为 WebRTC 的强制音频编码（第七章将再会），也广泛用于 WhatsApp、Discord、游戏语音等一切实时场景。

音频编码的终点？

从 MP3 到 Opus，音频编码的三代进化恰好对应三种价值取向：MP3 开创了 "够用就好" 的感知压缩，AAC 把 音质/码率比 推向极致，Opus 则证明 低延迟与高质量可以兼得。三条线索合流之处，就是今天流媒体的标准音频栈——AAC 负责点播分发，Opus 负责实时互动。

音视频两条编码进化线至此全部收拢。理论清单已经足够长——是时候动手验证了。下一节，practice_7：让 x264 与 x265 在同一段素材上真刀真枪地比一场。