4、WebRTC媒体引擎：VP8/VP9/H264编解码器对比、Opus音频编码、Simulcast与SVC分层编码
聊到WebRTC的媒体引擎，说白了就是解决两个核心问题：怎么把视频压得又小又清楚，以及怎么在网络不好的时候还能流畅播放。我做了这么多年音视频，见过太多项目在这上面栽跟头。今天咱们就把这块掰开揉碎了讲清楚。
4.1 视频编解码器三兄弟：VP8、VP9、H264
WebRTC默认支持三种视频编码器。嗯，这里要注意，不是所有浏览器都支持全部三种。我当年刚接触WebRTC时，就因为这个踩过坑。
核心结论：H264兼容性最好，VP9压缩率最高，VP8是保底方案。
4.1.1 H264：老大哥，兼容性王者
H264是硬件编码器支持最广泛的格式。从手机到摄像头，几乎都有H264硬编硬解。我在项目中遇到过一个问题：客户要求支持老旧Android设备，那些设备软解VP8卡得要命，换成H264硬解就丝滑了。
- 优点：硬件支持广泛，功耗低，延迟可控
- 缺点：专利授权问题（虽然WebRTC里免费用），压缩率不如VP9
- 适用场景：移动端、低功耗设备、需要硬件加速的场景
4.1.2 VP8：谷歌亲儿子，保底方案
VP8是WebRTC的默认编码器。为什么？因为它是开源免费的，没有任何专利包袱。我记得2012年刚做WebRTC时，VP8是唯一的选择。
- 优点：开源免费，所有浏览器都支持，编码速度快
- 缺点：压缩率一般，同等画质下码率比H264高20%左右
- 适用场景：跨浏览器通信、不想碰专利问题的项目
4.1.3 VP9：后起之秀，压缩率之王
VP9是VP8的升级版，压缩率比H264高30%-50%。你想想看，同样的带宽，VP9能传更高清的视频。我建议在桌面端优先考虑VP9，特别是做屏幕共享的时候。
- 优点：压缩率极高，支持SVC（后面会细说）
- 缺点：编码计算量大，硬件支持不如H264
- 适用场景：桌面端、带宽受限场景、屏幕共享
| 特性 | H264 | VP8 | VP9 |
|---|---|---|---|
| 压缩率 | 中等 | 较低 | 最高 |
| 硬件支持 | 最广泛 | 较少 | 有限 |
| 编码速度 | 快 | 快 | 慢 |
| 专利问题 | 有 | 无 | 无 |
| 浏览器支持 | Chrome/Firefox/Safari | 全部 | Chrome/Firefox |
4.2 Opus音频编码：全能选手
Opus是我个人最喜欢的音频编码器，没有之一。它同时支持语音和音乐，码率从6kbps到510kbps都能工作。我曾经在一个项目中，用Opus在8kbps的码率下实现了可懂的电话质量通话。
小技巧：Opus的采样率建议设为48000Hz，帧长20ms。这是延迟和质量的黄金平衡点。
Opus的几个关键参数：
- 采样率：支持8kHz到48kHz
- 帧长：2.5ms到60ms，默认20ms
- 码率：6kbps到510kbps
- 复杂度：0到10，越高越耗CPU
为什么WebRTC选Opus？说白了，它把Celt（音乐编码）和SILK（语音编码）合在了一起。说话时用SILK模式，放音乐时自动切到Celt模式。你根本不用操心，它自己就搞定了。
4.3 Simulcast与SVC：网络自适应两大法宝
这部分是WebRTC媒体引擎里最核心的。为什么？因为网络状况千变万化，你不能指望所有用户都有稳定的带宽。Simulcast和SVC就是解决这个问题的。
4.3.1 Simulcast：同时发送多个流
Simulcast的意思是，发送端同时编码出多个不同分辨率的视频流。比如同时发送720p、480p、360p三个流。接收端根据自己网络状况，选一个合适的流来收。
我在项目中遇到过一个问题：一个用户用4G网络，另一个用WiFi。如果用单流，4G用户卡得要死。换成Simulcast后，4G用户自动切到360p流，WiFi用户看720p，体验好多了。
Simulcast的缺点：带宽浪费。发送端要同时编码多个流，上行带宽消耗大。比如720p+480p+360p三个流，总码率可能比单流高50%。
4.3.2 SVC：分层编码
SVC（Scalable Video Coding）是另一种思路。它只编码一个流，但这个流包含多个层：基础层+增强层。基础层保证基本画质，增强层提升清晰度。
举个例子：一个SVC流包含3层。网络差时只收基础层（360p），网络好时收全部三层（720p）。你想想看，这比Simulcast省带宽多了。
- 时域分层：控制帧率，比如15fps基础层+30fps增强层
- 空域分层：控制分辨率，比如360p基础层+720p增强层
- 质量分层：控制码率，比如低码率基础层+高码率增强层
注意：VP9支持SVC，H264的SVC扩展（H264-SVC）在WebRTC中支持有限。VP8不支持SVC。所以如果你要用SVC，VP9是首选。
4.4 知识体系总览
下面这张图把本章的核心逻辑串起来了。我建议你多看几遍，理解各个组件之间的关系。
4.5 实战选择建议
说了这么多，到底怎么选？我根据自己的经验，给你几个实用建议：
- 移动端优先H264：硬件解码省电，发热低。我做过测试，同样720p视频，H264硬解比VP8软解省电40%。
- 桌面端优先VP9：带宽利用率高。特别是做屏幕共享时，VP9的压缩率优势非常明显。
- 音频无脑选Opus：别纠结，Opus就是目前最好的选择。码率设32kbps，帧长20ms，效果杠杠的。
- Simulcast vs SVC：如果服务器带宽充足，用Simulcast；如果带宽紧张，用VP9的SVC。
避坑指南：我曾经在一个项目中，所有客户端都用VP9+SVC，结果发现某些老款Android手机解码VP9时发热严重，帧率掉到10fps以下。后来改成H264+Simulcast才解决问题。所以一定要考虑终端设备的解码能力。
好了，这一章的内容就到这里。媒体引擎是WebRTC的基石，理解了编解码器和自适应策略，你就能在实际项目中做出合理的技术选型。记住，没有最好的方案，只有最适合你场景的方案。
公众号:蓝海资料掘金营，微信deep3321