第三章 主流编码器详解：从 H.264 到 AV1
编码器，说白了就是流媒体系统的「心脏」。你推流再快、网络再好，编码器不给力，画面全是马赛克，用户照样骂娘。我这些年调过的编码器少说也有几十种，从硬件编码器到纯软件实现，踩过的坑能写满一个笔记本。今天咱们就把 H.264、H.265 和 AV1 这三兄弟掰开揉碎了讲清楚。
核心观点：没有最好的编码器，只有最适合场景的编码器。低延迟场景下，编码器的选择直接影响端到端延迟 30%-50%。
3.1 H.264/AVC：老将出马，一个顶俩
H.264 发布于 2003 年，到现在二十多年了，依然是流媒体领域使用最广泛的编码标准。为什么？兼容性好，几乎所有设备都支持。我在做直播项目时，第一版用的就是 H.264，因为要兼容用户手里的各种老旧手机。
编码器结构
H.264 编码器核心结构可以概括为「五步走」：
- 帧内预测：利用当前帧已编码的像素预测当前块，去除空间冗余
- 帧间预测：参考前后帧的运动补偿，去除时间冗余
- 变换量化：对残差做 DCT 变换，再量化压缩
- 熵编码：用 CAVLC 或 CABAC 把数据压缩成比特流
- 环路滤波：去块效应滤波，提升主观画质
常用配置参数
实际项目中，我一般用 x264 这个开源实现。它的参数体系很成熟，但新手容易懵。我挑几个最关键的说说：
| 参数 | 作用 | 推荐值（低延迟） |
|---|---|---|
preset |
编码速度与压缩率的权衡 | veryfast 或 faster |
tune |
针对特定场景优化 | zerolatency |
profile |
编码特性集 | baseline（兼容性优先） |
level |
分辨率与码率上限 | 4.1（1080p 够用） |
我的经验：低延迟直播场景，preset 别用 ultrafast。虽然它最快，但压缩率太差，码率会飙得很高。我一般从 veryfast 起步，如果 CPU 有余量再降到 faster。
3.2 H.265/HEVC：省一半码率，多一倍麻烦
H.265 是 H.264 的继任者，2013 年标准化。它的核心卖点很直接：同等画质下，码率比 H.264 低 40%-50%。
为什么会这样？H.265 引入了几个关键改进：
- 更大的编码块：从 H.264 的 16x16 扩展到 64x64，对大分辨率画面更友好
- 更精细的预测：帧内预测模式从 9 种增加到 35 种
- 改进的运动补偿：支持 1/8 像素精度，运动估计更准
- 并行化设计：Tile 和 WPP 技术，方便多核 CPU 加速
但 H.265 有个大问题——专利授权。我当年在一个商业项目里用 H.265，法务部门查了三个月才搞定授权费用。这也是为什么很多互联网公司转向了 AV1。
x265 配置要点
x265 是 H.265 最流行的开源实现。它的参数和 x264 类似，但多了些 HEVC 特有的选项：
# 低延迟直播配置示例
x265 --input input.yuv --output output.hevc \
--preset veryfast \
--tune zerolatency \
--profile main \
--crf 23 \
--keyint 60 \
--no-open-gop \
--no-scenecut注意：H.265 的 zerolatency tune 和 H.264 的行为不同。H.265 的 lookahead 机制默认会引入几帧延迟，必须配合 --no-scenecut 和 --no-open-gop 才能真正做到零延迟。我踩过这个坑，直播画面延迟了 3 帧，排查了半天才发现是 scenecut 在作怪。
3.3 AV1：开源之光照进现实
AV1 是 2018 年由开放媒体联盟（AOM）推出的开源编码标准。它的目标是：比 H.265 再省 30% 码率，而且完全免费。
AV1 的编码器实现主要有两个：
- libaom：AOM 官方参考实现，压缩率最高，但编码速度慢得令人发指
- SVT-AV1：Intel 主导的优化实现，速度比 libaom 快 5-10 倍，适合实际部署
我目前在用的主要是 SVT-AV1。它的参数设计很清晰，和 x264/x265 的哲学不太一样：
| SVT-AV1 参数 | 对应 x264 概念 | 低延迟推荐值 |
|---|---|---|
--preset |
编码速度（0-13，数字越大越快） | 8 或 10 |
--crf |
质量目标（0-63，越小质量越好） | 30-35（直播场景） |
--tune |
优化方向 | 0（VQ 主观质量） |
--enable-overlays |
叠加层支持 | 0（关闭，减少延迟） |
关键对比：同样 1080p@30fps 的直播流，H.264 需要 4Mbps，H.265 需要 2.5Mbps，AV1 只需要 1.8Mbps。但 AV1 的编码耗时是 H.264 的 10-20 倍。所以低延迟场景下，AV1 更适合离线转码，实时编码还得靠硬件加速。
3.4 编码器参数调优：CRF、Preset、Tune
这三个参数是编码器调优的「三驾马车」。我面试高级工程师时，必问这个问题。
CRF：质量优先模式
CRF（Constant Rate Factor）是固定质量模式。编码器会根据画面复杂度自动分配码率，简单画面少用码，复杂画面多用码。
- 取值范围：0-51（x264），0-63（x265/SVT-AV1）
- 常见取值：18-28。18 接近无损，28 属于中等质量
- 低延迟场景：我一般用 23-25。太低了码率会飙，太高了画质崩
避坑指南：CRF 模式不适合带宽受限的场景。比如你给用户推 1Mbps 的流，用 CRF 23 可能实际码率跑到 3Mbps，用户全卡了。这时候应该用 --bitrate 固定码率模式。
Preset：速度与质量的博弈
Preset 控制编码器在「速度」和「压缩率」之间的取舍。x264 的 preset 从慢到快依次是：
placebo → veryslow → slower → slow → medium → fast → faster → veryfast → superfast → ultrafast每提升一档，编码速度大约翻倍，但码率会增加 5%-10%。
我个人的经验法则：
- 离线转码：用
slow或veryslow，省带宽就是省钱 - 实时直播：用
veryfast或faster，延迟优先 - 硬件编码器：preset 通常对应芯片的功耗模式，选中间档最稳妥
Tune：场景化调优
Tune 是编码器的「场景预设」。它告诉编码器：你现在要处理的是什么类型的视频？
| tune 值 | 适用场景 | 效果 |
|---|---|---|
film |
电影、电视剧 | 保留胶片颗粒感，提升主观画质 |
animation |
动画、卡通 | 优化平坦区域，减少色块 |
grain |
高噪点视频 | 保留噪点纹理，避免画面「塑料感」 |
zerolatency |
直播、视频通话 | 禁用 lookahead，最小化编码延迟 |
fastdecode |
低性能解码设备 | 牺牲压缩率，降低解码复杂度 |
我曾经犯过的错：有一次做游戏直播，画面全是快速运动的场景，我用了 tune film，结果画面糊成一团。后来换成 tune zerolatency 加上 --no-deblock，效果好了很多。记住：tune 不是万能药，要根据实际内容测试。
3.5 如何选择？一张图说清楚
说了这么多，到底该用哪个编码器？我整理了一个决策流程：
嗯，编码器这块内容确实不少。但记住一点：参数是死的，场景是活的。同样的配置，换一个内容类型，效果可能天差地别。我每次上线新业务，都会花至少一周时间做编码器参数对比测试，用 PSNR、SSIM、VMAF 这些客观指标加上主观盲测，才能确定最终方案。