5、编解码器基础：H.264与VP8/VP9对比、SDP中的编解码协商、编解码器优先级

各位同学，今天我们聊点硬核的。编解码器，说白了就是WebRTC的"翻译官"。你这边摄像头采集了一堆像素，那边要还原成画面，中间全靠它压缩和解压。我做了这么多年音视频，见过太多因为编解码器选错导致卡顿、花屏的案例。今天咱们就把H.264、VP8、VP9这几个主流选手掰开揉碎讲清楚。

5.1 三大编解码器：H.264、VP8、VP9

先说说它们的身世。H.264是MPEG家族的，专利池很深，但硬件支持最广。VP8是Google搞的，开源免费，当年就是为了对抗H.264的专利壁垒。VP9是VP8的升级版，压缩率更高，但计算复杂度也上去了。

我个人习惯把这三者比作汽车：H.264是丰田卡罗拉——哪儿都能修，皮实耐用；VP8是五菱宏光——便宜够用，别指望太多；VP9是特斯拉——技术先进，但充电桩（解码能力）不是哪儿都有。

我在项目中遇到过一件事：有个客户非要用VP9做1080p视频会议，结果用户的老笔记本CPU直接飙到90%，画面还一卡一卡的。后来换成H.264，CPU降到40%，流畅度反而上去了。你想想看，技术指标再漂亮，也得看实际场景。

5.2 SDP中的编解码协商

WebRTC里两端怎么商量用哪个编解码器？靠SDP（Session Description Protocol）。说白了就是一份"能力清单"，A端说"我会H.264、VP8"，B端说"我也会H.264、VP8，但我更想要VP8"，然后双方握手确定。

来看一个典型的SDP片段：

m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1
a=rtpmap:97 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=96
a=rtpmap:100 rtx/90000
a=fmtp:100 apt=97
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=98

注意看这行：m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101。后面的数字是payload type编号，顺序就是优先级。96排最前，说明发送方最想用H.264。如果接收方也支持，就会选96。

5.3 编解码器优先级

优先级怎么定？不是拍脑袋的。我一般遵循这几个原则：

1. 硬件解码优先：能用硬解就别用软解，省电省CPU。H.264硬解覆盖率最高。
2. 带宽敏感场景用VP9：比如移动端弱网环境，VP9的低码率优势明显。
3. 低延迟场景用H.264或VP8：VP9编码延迟偏高，不适合实时互动。
4. 兼容性兜底：至少保留一个所有端都支持的编码器。

实际在Chrome里，默认优先级是：VP8 > H.264 > VP9。为什么VP8排第一？因为Google亲儿子，而且VP8的专利风险最低。但如果你用Safari，它可能只支持H.264。所以跨浏览器通信时，我建议把H.264提到最前面。

5.4 知识体系总览

下面这张图把编解码器选择、SDP协商、优先级决策串起来了。建议保存下来，以后做方案设计时对照着看。

5.5 实战建议

最后给几条实在的建议：

• 多端互通场景：把H.264放在SDP第一位，VP8兜底。这是最稳妥的方案。
• 纯Chrome生态：用VP8，省去专利烦恼，而且Chrome对VP8优化最好。
• 移动端弱网：尝试VP9，但要做好降级预案——一旦CPU过高或编码超时，立刻切回H.264。
• 调试时：用chrome://webrtc-internals查看实际协商结果，别猜。