第2章媒体引擎与编解码器

课程目录第2章媒体引擎与编解码器

媒体引擎与编解码器：音频编解码器（Opus、G.711）、视频编解码器（VP8、VP9、H.264）、编解码器选择策略

聊到 WebRTC 的媒体引擎，说白了就是整个实时通信的「心脏」。我刚开始接触 WebRTC 时，总觉得编解码器就是个压缩工具，选一个能用的就行。后来踩了不少坑才明白——选错编解码器，延迟、卡顿、花屏全来了，用户体验直接崩盘。

这一章，咱们就深入聊聊音频和视频编解码器。我会结合自己实际项目中的经验，帮你理清 Opus、G.711、VP8、VP9、H.264 这些家伙到底该怎么用。

音频在实时通信里其实比视频更敏感。你想想看，视频卡一下还能忍，声音断断续续或者有回声，用户立马就挂电话了。

Opus 是我个人最推荐的音频编解码器。它支持从 6 kbps 到 510 kbps 的码率范围，采样率从 8 kHz 到 48 kHz。说白了，一个 Opus 就能搞定语音和音乐两种场景。

我记得有一次做在线教育项目，老师那边网络不太好，但 Opus 自动降码率后，声音依然清晰可辨。换成 G.711 的话，早就断断续续了。

  核心优势：
  动态码率调整：网络差时自动降码率，网络好时提升质量
支持 FEC（前向纠错）：丢包时能恢复部分数据
低延迟：默认 20ms 帧长，可低至 2.5ms

我的经验： 在移动端项目中，我习惯把 Opus 的帧长设为 40ms。虽然延迟稍高，但能显著降低 CPU 消耗，对手机续航更友好。

G.711 是 PCM 编码，分 A-law 和 μ-law 两种。它不压缩，码率固定 64 kbps。你可能会问：「都什么年代了还用这个？」

嗯，这里要注意。G.711 最大的优势是兼容性。很多老旧的 PBX 电话系统、SIP 网关只认 G.711。如果你要做 PSTN 互通，G.711 是绕不开的。

我曾经在一个视频会议项目中，客户要求兼容传统电话网络。我们不得不同时支持 Opus 和 G.711，通过 SDP 协商来动态切换。

视频编解码器这块，争议一直很大。我见过不少团队因为选错编解码器，导致产品上线后兼容性问题一堆。

VP8 是 WebRTC 最早支持的视频编解码器。它免费、开源，而且实现简单。Chrome 和 Firefox 默认都支持 VP8。

我个人觉得 VP8 最大的优点是「稳」。它不像 VP9 那样追求极致压缩率，但编码速度快，解码复杂度低。在低端手机上，VP8 的表现往往比 H.264 更流畅。

避坑指南： 我曾经在 Android 设备上遇到过 VP8 硬解不兼容的问题。部分老款芯片的 VP8 硬件解码器有 bug，导致花屏。解决方案是回退到软件编码，或者强制使用 H.264。

VP9 是 VP8 的升级版，压缩率比 VP8 高 30%-50%。这意味着同样的画质，VP9 只需要更少的带宽。

但 VP9 有个硬伤——编码复杂度高。在实时通信场景下，VP9 的编码延迟比 VP8 高不少。我测试过，在同等硬件条件下，VP9 的编码时间大约是 VP8 的 2-3 倍。

所以我的建议是：如果你的用户带宽有限（比如 4G 网络），而且设备性能足够，可以考虑 VP9。否则，还是老老实实用 VP8 或 H.264。

H.264 是视频编解码器里的「老大哥」。几乎所有设备都支持 H.264 硬件编解码，包括 iPhone、Android 手机、甚至智能电视。

为什么 WebRTC 不默认用 H.264？说白了就是专利问题。H.264 需要支付专利授权费，而 VP8/VP9 是免费的。不过在实际项目中，H.264 的硬解支持率确实是最高的。

我记得有一次做跨平台视频通话，iOS 端用 H.264 硬编，Android 端用 VP8 软编。结果 Android 端发热严重，帧率上不去。后来统一改成 H.264 硬编，问题就解决了。

选编解码器不是拍脑袋决定的。我总结了一套策略，你可以参考：

  核心原则： 永远不要只支持一种编解码器。通过 SDP 协商，让客户端根据自身能力选择最合适的编解码器。这是 WebRTC 设计之初就考虑到的。

最后说一句，编解码器的选择没有银弹。我见过太多团队纠结于「哪个编解码器最好」，结果忽略了实际场景的测试。我的建议是：先跑起来，再优化。用默认配置上线，然后根据用户反馈逐步调整。

好了，这一章的内容就到这里。编解码器是媒体引擎的核心，选对了事半功倍，选错了处处踩坑。希望我的经验能帮你少走一些弯路。