10、音视频编解码：VP8/VP9/H264对比、Opus音频编码、编解码器协商
各位同学，今天我们来聊聊WebRTC里最核心、也最“烧脑”的一块——音视频编解码。说实话，我刚开始接触WebRTC时，觉得编解码就是个黑盒子，数据扔进去，压缩完传出去就完事了。直到有一次线上会议出现花屏、卡顿，排查了三天才发现是编解码器协商出了问题。从那以后，我再也不敢小看这个环节了。
编解码器，说白了就是音视频数据的“压缩打包工”。你想想看，原始的视频数据一秒钟可能几十MB，不压缩根本没法在网络上实时传输。而WebRTC要做的，就是在不同浏览器、不同设备之间，找到双方都支持的编解码器，然后高效地压缩、传输、解压。今天我们就来掰扯清楚这几个主流编解码器的区别，以及它们是怎么“握手”的。
10.1 视频编解码三巨头：VP8、VP9、H.264
WebRTC里最常见的视频编解码器就这三个。我个人习惯把它们分成两派：H.264是“老牌贵族”，硬件支持最广；VP8是“开源先锋”，Google亲儿子；VP9是“后起之秀”，压缩率更高但计算量也更大。
10.1.1 H.264：最成熟的“万金油”
H.264，也叫AVC，是视频编解码领域的老大哥。几乎所有现代设备——手机、电脑、摄像头——都内置了H.264的硬件编码器。这意味着什么？意味着你用H.264编码时，CPU几乎不费什么力气，功耗低、发热小。
核心特点：
- 硬件加速支持最广泛，从iPhone到Android到PC都支持
- 压缩效率不错，但不如VP9
- 专利授权问题复杂，但在WebRTC场景下通常免费
我在项目中遇到过一个问题：某款国产手机在H.264硬件编码时，输出的视频流每隔几秒就会跳一帧。排查下来发现是厂商的驱动实现有bug，最后只能降级到软件编码。嗯，这里要注意：硬件编码虽然快，但不同厂商的实现质量参差不齐。
10.1.2 VP8：Google的“开源反击”
VP8是Google收购On2公司后推出的开源编解码器。它的诞生背景很简单：Google不想被H.264的专利费卡脖子。VP8的压缩效率跟H.264基本持平，但它是完全免费的，没有任何专利授权问题。
WebRTC刚推出时，VP8是强制要求支持的编解码器。也就是说，所有支持WebRTC的浏览器，都必须能解码VP8。这保证了最基本的互通性。
| 特性 | VP8 | H.264 |
|---|---|---|
| 专利费用 | 免费 | 有专利池，但WebRTC场景通常豁免 |
| 硬件加速 | 较少 | 非常广泛 |
| 压缩效率 | 中等 | 中等 |
| 浏览器支持 | Chrome、Firefox原生支持 | Chrome、Safari、Edge支持 |
10.1.3 VP9：更高压缩率的“未来之星”
VP9是VP8的升级版，压缩率比H.264高出约30%-50%。这意味着同样的画质下，VP9只需要更少的带宽。对于带宽有限的移动网络来说，这简直是福音。
但VP9也有它的短板：计算复杂度高。软件编码时，CPU占用率比H.264高出一大截。硬件加速虽然也在普及，但远不如H.264那么成熟。
我的建议：
如果你的应用场景是桌面端、带宽充足，优先用H.264（硬件加速省电）。如果是移动端、带宽紧张，可以考虑VP9。VP8作为兜底方案，保证所有浏览器都能通。
10.2 Opus音频编码：全能型选手
音频编码这块，WebRTC几乎只用Opus。为什么？因为它太强了。Opus是一个“混合型”编解码器，它同时支持语音和音乐，码率可以从6kbps到510kbps动态调整。你想想看，6kbps是什么概念？比电话线路还低，但Opus依然能保持可懂度。
我记得有一次做跨国会议，网络状况极差，丢包率高达20%。其他音频编码器基本都废了，但Opus配合FEC（前向纠错）居然还能听清对方说话。这就是Opus的厉害之处。
Opus核心参数：
- 采样率：8kHz到48kHz
- 码率：6kbps到510kbps
- 帧长：2.5ms到60ms（低延迟场景用短帧）
- 支持立体声和环绕声
在WebRTC中，Opus是强制要求支持的音频编解码器。也就是说，任何WebRTC客户端都必须能编解码Opus。这省去了很多协商的麻烦。
10.3 编解码器协商：SDP Offer/Answer模型
好了，现在我们知道有哪些编解码器了。但问题是：两个WebRTC客户端怎么知道对方支持什么？这就涉及到编解码器协商了。
WebRTC使用SDP（Session Description Protocol）来完成协商。流程很简单：发起方（Offerer）发送一个SDP Offer，里面列出了它支持的所有编解码器，以及每个编解码器的参数。接收方（Answerer）收到后，从列表里选一个自己支持的，然后返回SDP Answer。
这个过程有点像点菜：你拿着菜单（Offer）说“我能做宫保鸡丁、鱼香肉丝、麻婆豆腐”，对方（Answer）说“我要鱼香肉丝，少放辣”。
下面我用一张图来展示这个流程：
在实际的SDP中，编解码器是通过RTP映射号来标识的。比如H.264的映射号通常是96或97，VP8是98，VP9是99。每个编解码器后面还会跟一堆参数，比如H.264的packetization-mode、profile-level-id等。
避坑指南：
我曾经遇到过一个坑：某浏览器在SDP Offer里同时列出了H.264的两种封装模式（0和1），但接收方只支持模式1。结果协商出来的模式是0，导致接收方解码失败。后来我强制在Offer里只发模式1，问题就解决了。所以，不要假设对方能处理所有参数组合，尽量只发你确定对方能支持的配置。
10.4 如何选择编解码器？
说了这么多，到底该怎么选？我给大家一个实用的决策流程：
- 先看硬件：如果设备有H.264硬件编码器，优先用H.264。省电、省CPU。
- 再看带宽：如果带宽低于500kbps，考虑VP9。同样码率下VP9画质更好。
- 最后看兼容性：如果对方是Safari或老版本浏览器，H.264最稳妥。如果对方是Chrome/Firefox，VP8/VP9都没问题。
在实际项目中，我通常的做法是：在SDP Offer里按优先级排列编解码器。比如：
// 伪代码：设置编解码器优先级
const codecPreferences = [
{ name: 'H.264', priority: 1 }, // 首选
{ name: 'VP9', priority: 2 }, // 次选
{ name: 'VP8', priority: 3 } // 兜底
];
// 在创建Offer时，按优先级排序
const offer = await peerConnection.createOffer();
offer.sdp = sortCodecsByPriority(offer.sdp, codecPreferences);
await peerConnection.setLocalDescription(offer);
这样，接收方会优先选择H.264，如果它不支持，再尝试VP9，最后才是VP8。保证了最好的用户体验。
小技巧：
你可以通过RTCRtpSender.getCapabilities()来查询当前浏览器支持的编解码器。这样在创建Offer之前，就能知道对方大概率会选什么，提前做好准备。
好了，关于编解码器的对比和协商，今天就聊到这里。记住一句话：没有最好的编解码器，只有最适合当前场景的编解码器。多测试、多踩坑，你慢慢就会找到感觉。
公众号:蓝海资料掘金营，微信deep3321