2、视频编码基础：H.264/H.265/VP8/VP9/AV1编码器简介、编码原理、码率控制模式

做WebRTC开发，绕不开视频编码。说白了，编码器就是那个把摄像头采集的原始视频流「压缩」成网络能传得动的数据的东西。我刚开始接触这个领域时，总觉得编码器就是个黑盒子，参数调一调，码率降一降，完事。后来踩了不少坑才明白——不理解编码器原理，你连WebRTC的码率自适应都调不明白。

这一章，我把几个主流编码器掰开揉碎讲清楚。不扯太深奥的数学公式，重点讲工程里怎么用、怎么选。

2.1 主流编码器概览

目前WebRTC生态里，常见的编码器就这五个：H.264、H.265、VP8、VP9、AV1。它们各有各的脾气。

2.2 编码原理：从像素到比特流

所有视频编码器的核心逻辑其实差不多。我画了一张图，帮你快速建立整体认知。

你看，不管H.264还是AV1，流程骨架都差不多。区别在于每个环节的具体算法复杂度。举个例子，H.264的帧内预测有9种模式，到了H.265就变成了35种，AV1更是搞出了56种。算法越复杂，压缩率越高，但编码耗时也越长。

2.3 各编码器核心差异

2.3.1 H.264 — 兼容之王

H.264在WebRTC里地位很特殊。几乎所有浏览器、手机、硬件编码器都支持它。我在项目中遇到过最极端的情况：一个客户要求兼容到2012年的Android平板，那会儿VP8都跑不利索，最后只能硬上H.264 Baseline Profile。

H.264的编码单元是宏块（16x16），支持多参考帧、CABAC熵编码。它的码率控制模式很成熟，CBR、VBR、CRF都有。

2.3.2 H.265 — 高码率场景的利器

H.265把宏块扩展成了CTU（最大64x64），帧内预测方向翻倍，还引入了SAO（样点自适应补偿）。压缩率比H.264提升约40%。但问题是——专利费太乱。我有个朋友做直播产品，因为H.265专利问题被律师函警告过。所以WebRTC里H.265一直不温不火。

2.3.3 VP8 — WebRTC的「亲儿子」

VP8是Google收购On2后开源的项目。它和H.264结构很像，但去掉了专利包袱。VP8的码率控制有个特点：它更倾向于保持画质稳定，码率波动会比H.264大一些。早期Chrome和Firefox之间通话，默认就是VP8。

2.3.4 VP9 — 压缩率黑马

VP9是VP8的全面升级版。它引入了超块（64x64）、递归分割、更精细的运动矢量。YouTube用VP9把带宽降了50%。但在WebRTC里，VP9的编码速度是个问题。我记得2018年做项目时，软编VP9 1080p 30fps，i7 CPU直接飙到80%占用。现在硬件加速好多了，但移动端还是慎用。

2.3.5 AV1 — 未来的答案

AV1由开放媒体联盟（AOM）开发，目标是比VP9再省30%码率。它的编码工具极其丰富：CDEF滤波、帧级超分辨率、交替参考帧……但代价是编码复杂度爆炸。目前WebRTC里AV1主要靠SVT-AV1等软编库，实时编码1080p需要高端CPU。不过趋势很明显——Netflix、YouTube都在推AV1，硬件编码器也在陆续落地。

2.4 码率控制模式详解

码率控制，说白了就是编码器怎么分配比特数。选错了模式，要么画面糊成马赛克，要么带宽撑爆。我见过太多人把CBR和VBR搞混，结果推流卡成PPT。

2.4.1 CBR（恒定码率）

CBR模式下，编码器会拼命把输出码率压到目标值。画面简单时加填充数据，画面复杂时降低画质。WebRTC的带宽估计模块（GCC）最喜欢CBR，因为码率可预测。但代价是——你可能会看到画面突然变糊，然后又恢复。

2.4.2 VBR（可变码率）

VBR允许码率在一定范围内波动。画面静止时码率低，运动剧烈时码率高。画质比CBR稳定，但码率不可控。在WebRTC里，纯VBR很少用，因为带宽估计模块会疯掉——它刚算出带宽够，下一秒码率就飙上去了。

2.4.3 CRF（恒定质量）

CRF模式直接固定量化参数（QP）。编码器不管码率多少，只保证每一帧的质量一致。这个模式在离线转码里很常用，但实时通信基本不用。为什么？因为码率完全不可控，可能前一帧100kbps，后一帧就跳到2Mbps。WebRTC的带宽自适应根本反应不过来。

2.4.4 Capped VBR — WebRTC的最佳实践

我个人最推荐的是Capped VBR。它结合了VBR的画质优势和CBR的码率可控性。你设一个目标码率，再设一个最大码率（比如目标码率的1.2倍）。编码器在大部分时间按VBR工作，但码率超过上限时自动降质。这样既保证了画质，又不会撑爆带宽。

2.5 编码器选型实战建议

说了这么多，到底怎么选？我总结了一张决策表，你直接拿去用。