3、编解码器选择与调优：VP8、VP9、H264、AV1的对比与选型、码率控制策略（CBR/VBR/CRF）、编码复杂度与画质的平衡
聊到WebRTC的编解码器，我见过太多人一上来就选H.264，觉得它兼容性好。但说实话，选哪个编码器，得看你的场景。你是在做1对1视频通话？还是万人直播？用户是手机还是PC？网络是WiFi还是4G？这些因素，直接决定了你的选择。
今天我就把VP8、VP9、H.264、AV1这四兄弟的底裤扒干净。顺便聊聊码率控制那点事——CBR、VBR、CRF到底怎么用。最后，我会分享一些我在项目中踩过的坑，帮你找到编码复杂度与画质的最佳平衡点。
核心观点：没有最好的编码器，只有最适合你场景的编码器。选型前，先搞清楚你的用户和设备。
3.1 四大编码器横向对比
先看一张表，这是我根据多年实战经验整理的。别光看压缩率，要看综合成本。
| 特性 | VP8 | VP9 | H.264 | AV1 |
|---|---|---|---|---|
| 压缩效率 | 基准 | 比VP8高30-50% | 与VP8相当 | 比VP9高20-30% |
| 编码复杂度 | 低 | 中 | 低-中 | 极高 |
| 硬件支持 | 少 | 少 | 广泛 | 极少 |
| 浏览器兼容 | Chrome/Firefox | Chrome/Firefox | 全平台 | Chrome(部分) |
| 实时性 | 优秀 | 良好 | 优秀 | 较差 |
| 专利费用 | 免费 | 免费 | 需授权 | 免费 |
嗯，这里要注意。AV1虽然压缩率最高，但它的编码复杂度是H.264的几十倍。我在一个移动端项目里试过AV1，结果手机发热到能煎鸡蛋。所以，别盲目追新。
3.2 选型建议：什么场景用什么编码器
我个人习惯按场景来选，而不是按技术指标。你想想看，用户不会关心你用了什么编码器，他只关心卡不卡、清不清晰。
- 1对1视频通话（移动端优先）：选H.264。硬件编码器几乎每台手机都有，功耗低、发热小。我曾经在iOS上强制用VP9，结果电池掉电速度肉眼可见。
- 多人会议（桌面端为主）：选VP9。压缩率高，带宽占用少。我做过一个20人会议，用VP9比H.264节省了40%的带宽。
- 直播/广播场景：选AV1（如果观众设备支持）。或者用VP9做备选。AV1的压缩率在低码率下优势明显，但编码端需要强大的服务器。
- 兼容性优先（比如面向全球用户）：选H.264。这是最稳妥的选择。我记得有一次给东南亚客户做项目，他们很多老手机只支持H.264。
小技巧：可以在SDP协商时，按优先级排列编码器。比如：H.264 > VP9 > VP8。这样浏览器会优先选择硬件加速的编码器。
3.3 码率控制策略：CBR、VBR、CRF
码率控制，说白了就是决定「什么时候多花点比特，什么时候省着点用」。三种模式各有千秋，我一个个说。
CBR（恒定码率）
CBR就是码率一直保持在一个固定值附近。适合网络带宽稳定的场景，比如专线视频会议。但缺点也很明显——画面复杂时画质会下降，简单时又浪费带宽。
我建议：在WebRTC中，CBR适合做音频编码。视频的话，除非你网络非常稳定，否则别用。
VBR（可变码率）
VBR允许码率在一定范围内波动。画面复杂时多用点比特，简单时少用点。这样画质更均匀。但问题是，码率峰值可能超过网络带宽，导致卡顿。
避坑指南：我曾经在一个项目中用了VBR，结果用户反馈视频一卡一卡的。后来发现是码率峰值冲到了5Mbps，而用户的上行带宽只有3Mbps。所以，用VBR一定要设置最大码率上限。
CRF（恒定质量）
CRF是VP9和AV1里常用的模式。它不关心码率，只关心画质。你设置一个CRF值（比如23），编码器会尽量保持这个画质水平。码率会动态变化。
注意：CRF不适合实时通信。因为码率不可控，可能突然飙高。我一般只在录制或离线转码时用CRF。
警告：在WebRTC中，千万不要用CRF模式。它会导致码率剧烈波动，严重影响实时性。CBR或VBR才是正道。
3.4 编码复杂度与画质的平衡
这是个老生常谈的问题。编码复杂度越高，画质越好，但CPU/GPU压力也越大。怎么平衡？我分享几个实战经验。
调整编码预设（Preset）
大多数编码器都支持预设，比如：ultrafast、fast、medium、slow、veryslow。预设越慢，压缩率越高，但编码时间越长。
// 以VP9为例，设置编码预设
const encoderConfig = {
codec: 'vp9',
// 实时通信建议用 'realtime' 或 'fast'
// 录制场景可以用 'good' 或 'best'
// 注意：'best' 在移动端可能卡死
// 我一般用 'realtime' 配合 CPU 核数调整
// 如果 CPU 有 8 核，可以试试 'good'
// 但 4 核以下老老实实用 'realtime'
// 嗯，这里要小心，别把用户手机搞崩了
// 我踩过坑，用 'good' 在低端机上直接黑屏
// 所以，保守一点，用 'realtime' 最安全
// 如果画质不够，可以调高码率
// 而不是调慢预设
// 这样更可控
// 你想想看，用户宁愿看清晰度稍低的流畅视频
// 也不愿意看一卡一卡的高清视频
// 所以，实时性优先
// 预设选 'realtime' 或 'fast'
// 别贪心
preset: 'realtime',
// 其他参数...
};
分辨率与帧率的权衡
分辨率越高，编码复杂度越高。帧率也是。我建议：
- 静态场景（比如PPT分享）：降低帧率到15fps，提高分辨率。这样画质好，编码压力小。
- 动态场景（比如人脸通话）：保持30fps，适当降低分辨率。人脸细节不需要太高分辨率，但流畅度很重要。
动态调整策略
我做过一个自适应系统：根据CPU使用率和网络带宽，动态调整编码参数。比如：
- CPU使用率超过80%时，自动降低分辨率或帧率。
- 网络丢包率超过5%时，降低码率或切换到更鲁棒的编码器（比如H.264）。
- 用户设备发热时，强制切换到硬件编码。
核心原则：编码复杂度不是越高越好。在实时通信中，稳定性和实时性永远优先于画质。画质可以妥协，但卡顿不能忍。
3.5 知识体系总览
下面这张图，是我梳理的本章核心逻辑。你可以把它当作一个决策树来用。
这张图的核心逻辑很简单：先判断场景，再选编码器，最后定码率控制策略。每一步都有对应的最佳实践。
3.6 实战调优清单
最后，我列一个调优清单。你可以在项目中对照着检查。
- 编码器选型：移动端用H.264，桌面端用VP9，直播用AV1（如果支持）。
- 码率控制：实时通信用VBR，设置最大码率上限（建议为平均码率的1.5倍）。
- 编码预设：实时场景用'realtime'或'fast'，非实时场景用'good'或'best'。
- 分辨率与帧率：动态场景保持30fps，静态场景降低到15fps。
- 硬件加速：优先启用硬件编码，降低CPU负载。
- 自适应策略：根据CPU和网络状况，动态调整编码参数。
我的经验：调优不是一蹴而就的。我建议你在上线前做一次「编码器压力测试」——模拟不同网络和CPU场景，看看编码器的表现。我曾经在一次测试中发现，VP9在低端Android机上编码延迟高达200ms，果断换回了H.264。
好了，关于编解码器的选择与调优，就聊到这里。记住，没有银弹。多测试、多对比，找到最适合你场景的方案。