📚 课程目录第3章卡顿定义与用户体验

3. 卡顿定义与用户体验

编码器选型，说白了就是给视频数据找个合适的“压缩打包工”。

我见过不少团队，一上来就纠结“哪个编码器最好”。其实没有绝对的“最好”，只有“最合适”。你的场景、终端、带宽，才是决定因素。

今天咱们就把 H.264、VP8、VP9 这三兄弟掰开揉碎聊清楚。再讲讲码率控制——CBR、VBR、CRF 到底怎么选。

三大编码器横向对比

先看一张对比表，心里有个底：

特性	H.264	VP8	VP9
诞生时间	2003	2008	2013
专利许可	需付费（MPEG-LA）	免费（BSD）	免费（BSD）
硬件支持	极广泛（几乎所有设备）	较广泛（Chrome/Android）	有限（较新设备）
压缩效率	基准	比 H.264 高约 10-15%	比 H.264 高约 30-50%
编码复杂度	低	中	高
WebRTC 默认	Chrome/Safari 首选	Firefox 旧版默认	需协商启用

H.264：最稳妥的选择

我个人习惯，在商业项目中首选 H.264。为什么？

硬件编码器遍地都是。从 iPhone 到树莓派，从 Intel 到 ARM，几乎都有 H.264 硬编硬解。功耗低、发热小、延迟稳。
兼容性无敌。你永远不用担心对方浏览器不支持。Safari 甚至只支持 H.264。
生态成熟。调优参数、分析工具、第三方库，一抓一大把。

我的建议：如果你的用户群体覆盖 iOS 和旧设备，或者对功耗敏感（比如移动端直播），直接锁 H.264 硬编。别折腾。

但 H.264 也有短板。压缩率不如后两者。同样画质，码率要高 20-30%。带宽吃紧时，它先扛不住。

VP8：被低估的老兵

VP8 现在用得少了。但我记得 2015 年左右，Firefox 和 Chrome 默认都用它。

它的优势是免费、开源。如果你做的是纯 WebRTC 项目，不想碰专利问题，VP8 是个安全选项。

不过说实话，VP8 的压缩效率只比 H.264 好一点点。编码器实现质量也参差不齐。Google 自己的 libvpx 还行，第三方实现就不好说了。

避坑：我曾经在一个跨平台项目中用 VP8 软编，结果 Android 低端机发热严重，帧率直接掉到 15fps。后来切回 H.264 硬编，问题解决。VP8 软编的 CPU 开销，比你想象的大。

VP9：高压缩率的未来

VP9 是真正的“省带宽利器”。同样画质，码率能比 H.264 低 40% 左右。

我在一个远程协作项目里试过 VP9。720p 视频，H.264 要 1.5Mbps，VP9 只要 800Kbps。画面细节还更清晰。

但代价也很明显：

编码慢。VP9 的编码复杂度是 H.264 的 3-5 倍。实时编码时，CPU 占用飙升。
硬件支持有限。只有较新的 Intel（第 7 代+）、NVIDIA（Pascal+）、Apple（M1+）才支持 VP9 硬编。
延迟偏高。VP9 的编码延迟比 H.264 大，不适合超低延迟场景（比如在线教育中的白板同步）。

  适用场景：带宽受限但终端性能较强的场景。比如 4K 直播、远程医疗影像共享。如果用户都是 M1 Mac 或 iPhone 12 以上，VP9 硬编是个好选择。

码率控制模式：CBR vs VBR vs CRF

选完编码器，还得告诉它“怎么控制码率”。

三种模式，各有各的脾气。

模式	全称	核心逻辑	码率波动	画质稳定性	典型场景
CBR	恒定码率	强制输出码率接近目标值	极小	差（复杂场景画质下降）	直播推流、视频会议
VBR	可变码率	允许码率波动，追求画质	较大	好	点播、录播
CRF	恒定质量	固定量化参数，码率自适应	最大	极好	本地录制、后期处理

CBR：WebRTC 的默认选择

WebRTC 内部默认用 CBR。为什么？因为实时通信最怕“码率突然飙升”。

你想想看，视频会议中，如果画面突然复杂（比如有人站起来走动），VBR 模式会瞬间提高码率。但网络带宽是固定的，结果就是丢包、卡顿、花屏。

CBR 模式强制码率平稳。哪怕画面变复杂，编码器也会降低画质来维持码率。虽然画质会波动，但至少不卡。

调优技巧：在 WebRTC 中，CBR 的目标码率不要设得太死。我一般留 10-15% 的余量。比如目标 1Mbps，实际设 1.1-1.15Mbps。这样编码器有喘息空间，画质更稳。

VBR：适合非实时场景

VBR 模式允许码率在合理范围内波动。简单画面用低码率，复杂画面用高码率。

优点是画质好。缺点是码率不可控。

我在做录播项目时常用 VBR。因为网络不是问题，存储也不是问题。但实时推流中，我基本不用 VBR——除非你做了码率自适应。

CRF：画质优先的终极方案

CRF 模式，说白了就是“我不管码率，我只要画质”。

你设定一个质量等级（比如 23），编码器自动调整量化参数。画面简单时码率低，画面复杂时码率高。

CRF 的码率波动非常大。同一段视频，CRF 23 的码率可能在 500Kbps 到 5Mbps 之间跳。实时通信根本扛不住。

注意：CRF 模式在 WebRTC 中基本不可用。除非你做了码率平滑或缓冲区。我见过有人强行用 CRF 推流，结果网络抖动时直接崩掉。别踩这个坑。

实战选型建议

说了这么多，到底怎么选？我总结一个决策流程：

先看终端。如果用户主要是 iOS/Safari，直接 H.264 硬编。别想别的。
再看带宽。带宽充足（>2Mbps），H.264 够用。带宽紧张（<1Mbps），考虑 VP9。
再看延迟。超低延迟（<100ms），H.264 硬编 + CBR。延迟容忍度高（>500ms），VP9 + VBR 也行。
最后看功耗。移动端直播，H.264 硬编是王道。VP9 软编会让手机发烫。

  我的默认配置：H.264 硬编 + CBR 模式。目标码率根据分辨率设定：720p 用 1.5Mbps，1080p 用 3Mbps。留 10% 余量。这个配置在 90% 的场景下都能稳定运行。

编码器选型决策流程图

下面这张图，帮你快速定位：

避坑指南

最后，分享几个我踩过的坑：

别迷信 VP9。VP9 压缩率虽高，但编码延迟大。我在一个在线教育项目里试过 VP9，结果白板同步延迟从 50ms 飙到 200ms。学生反映“老师写完了，我这边还没显示”。后来切回 H.264，问题解决。
CBR 不是越稳越好。码率设得太死，复杂场景画质会崩。我建议留 10-15% 的余量。
硬编不是万能的。有些低端手机的 H.264 硬编实现有 bug。比如某款千元机，硬编出来的视频每隔几秒会花一帧。遇到这种情况，可以降级到软编。
别忘了测试。编码器选型一定要在目标设备上跑一遍。我见过一个项目，开发机是 MacBook Pro，上线后用户全是低端 Android 机，结果 VP9 软编直接卡成 PPT。

嗯，编码器选型这块，核心就是“看场景、看终端、看带宽”。没有银弹，只有权衡。