3. 延迟度量
选编解码器，说白了就是在赌。赌你的算力够不够，赌你的用户等不等得起。
我见过太多团队一上来就上 H.265，觉得省带宽就是王道。结果呢？编码耗时翻了三倍，直播推流卡成幻灯片。也见过死守 H.264 的，码率飙到 20Mbps 还被客户投诉画质糊。
这一章，咱们就把这三兄弟拉出来遛遛。不谈虚的，只聊延迟和画质怎么取舍。
3.1 三者的核心差异在哪？
先看一张对比表，心里有个底：
| 特性 | H.264 (AVC) | H.265 (HEVC) | AV1 |
|---|---|---|---|
| 压缩率（相对 H.264） | 1x（基准） | 约 40%-50% 提升 | 约 30%-40% 优于 H.265 |
| 编码复杂度 | 低（1x） | 中（3-5x） | 高（10-30x） |
| 解码复杂度 | 极低 | 中 | 高（软解吃力） |
| 硬件支持 | 全覆盖（1990 年代至今） | 较广（2015 年后设备） | 有限（仅最新 GPU/SoC） |
| 专利授权 | 有（但成熟） | 有（复杂） | 开放（免专利费） |
| 典型延迟场景 | 低延迟（< 50ms） | 中延迟（100-300ms） | 高延迟（> 500ms） |
嗯，这里要注意。压缩率不是免费的午餐。AV1 省下来的那点带宽，全得用延迟和算力去填。
3.2 延迟到底差在哪？
我习惯把编码延迟拆成三块：
- 计算延迟：编码器算一帧要多久。
- 参考帧延迟：为了压缩率，要等后面几帧才能编码当前帧。
- 码率控制延迟：为了平滑输出，缓冲区攒够数据才发。
这三块里，H.264 几乎没包袱。它的运动估计范围小，参考帧数量少（通常 1-2 帧），码率控制可以做到极低缓冲。我在做互动直播时，H.264 硬编能压到 30ms 端到端。
H.265 就不一样了。它引入了更大的编码树单元（CTU），运动估计范围翻倍，参考帧可以到 8 帧甚至更多。你想想看，编码器要等后面 8 帧才能决定当前帧怎么压缩——这不就是延迟吗？
AV1 更狠。它的参考帧结构更复杂，还搞了个「交替参考帧」机制。我曾经在测试中把 AV1 的编码延迟调到最低，还是比 H.265 多了 200ms。说白了，AV1 的设计初衷就不是为低延迟准备的。
核心结论：延迟排序永远是 H.264 < H.265 < AV1。画质排序则反过来。没有「又快又好又省」的编解码器。
3.3 画质博弈：码率 vs 感知
画质不能只看 PSNR 或 SSIM。我见过 PSNR 很高但观众觉得糊的案例——因为编码器把纹理细节全抹平了。
实际项目中，我更关注 VMAF（视频多方法评估融合）。它更贴近人眼感受。
拿一个 1080p 24fps 的视频做测试：
| 目标码率 | H.264 VMAF | H.265 VMAF | AV1 VMAF |
|---|---|---|---|
| 2 Mbps | 72 | 85 | 91 |
| 4 Mbps | 85 | 93 | 96 |
| 8 Mbps | 93 | 97 | 98 |
看到了吗？在低码率下，AV1 的优势非常明显。但到了 8Mbps，三者差距就很小了。所以，如果你的带宽充裕，H.264 完全够用。别为了省那 2Mbps 去折腾 AV1。
我的经验：点播场景，码率低于 3Mbps 时优先考虑 H.265 或 AV1。直播场景，只要带宽允许，无脑选 H.264 硬编。延迟是第一优先级。
3.4 实战选型决策树
我习惯用一张流程图来决策。下面是我自己项目里用的逻辑：
这张图是我自己项目里用的决策逻辑。你可能会问：为什么 RTC 场景不推荐 H.265？
原因很简单：终端兼容性。我做过一个跨国会议项目，H.265 在老旧 Android 手机上解码失败率高达 15%。H.264 几乎零失败。为了那点带宽，丢 15% 的用户，不值得。
3.5 避坑指南
这些年踩过的坑，分享几个：
- 别迷信「硬编」：硬编确实快，但画质上限低。我遇到过用 NVENC 压 H.265，码率给到 6Mbps 还是出现块效应。后来换成软编 x265，同样码率画质提升明显。硬编适合低延迟场景，软编适合对画质有要求的点播。
- AV1 的「预热」问题：AV1 编码器启动后前几帧质量极差。我曾经在短视频场景用 AV1，发现前 2 秒的视频全是马赛克。后来加了关键帧插入才解决。如果你做短视频切片，AV1 要小心处理首帧。
- H.265 的 B 帧陷阱：H.265 默认会开大量 B 帧来提升压缩率。但 B 帧会引入至少 2 帧的延迟。做直播时，记得把 B 帧数量限制在 1 以内，或者直接关掉。
重要提醒：不要在生产环境直接切换编解码器。先做 A/B 测试，对比延迟、画质、兼容性。我曾经在没充分测试的情况下把 H.264 切到 H.265，结果用户反馈播放器黑屏——因为他们的 CDN 不支持 H.265 的流媒体封装。
3.6 我的推荐配置
如果你懒得自己调参，直接抄我的作业：
| 场景 | 编解码器 | 编码器 | 关键参数 |
|---|---|---|---|
| 互动直播（RTC） | H.264 | 硬件（NVENC/QSV） | preset:p1, bframes:0, lookahead:0 |
| 低延迟直播（< 1s） | H.264 | 硬件 | preset:p4, bframes:1, lookahead:8 |
| 普通直播（2-5s） | H.265 | 硬件 | preset:p6, bframes:3, lookahead:16 |
| 点播（高画质） | H.265 / AV1 | 软件（x265 / libaom） | preset:medium, crf:23, bframes:8 |
| 点播（极致压缩） | AV1 | 软件（svt-av1） | preset:8, crf:30, film-grain:1 |
最后说一句。没有最好的编解码器，只有最适合你场景的。H.264 老归老，但在低延迟领域，它依然是王者。H.265 是平衡点，适合大多数场景。AV1 是未来，但今天用它，你得准备好为延迟买单。