VP9 还是 H.265？一次压缩选型翻车后的复盘
去年做存储优化，我面临一个选择：同样一部 1080p 电影，用 VP9 还是 H.265（HEVC）压？当时拍脑袋选了 H.265，结果在兼容性和编码成本上连吃两记闷棍。这篇文章把那次选型的前因后果摊开，给同样纠结的人省点时间——参数表网上到处是，但"为什么选错"的经验很少人写。
一、先给结论（免得你划到底）
- 要兼容性、要省心：H.264 永远是地板，别看不起它。
- 要体积、播放端可控（自己的 App、Chrome、较新安卓/iOS）：VP9 更香，免版税，Web 原生支持好。
- 要体积、播放端是苹果/智能电视/老 Windows：H.265 生态更成熟。
- 别为那 10%~15% 体积差去承担编码时间和兼容性风险，除非你真的在乎每 GB。
二、翻车点一：编码时间
我原以为 H.265 只是"慢一点"。实测同一台机器、同画质目标（用 CRF 等效对比）：
| 编码 | 相对编码时间 | 同画质体积 |
|---|---|---|
| H.264 (libx264, slow) | 1x | 基准 |
| H.265 (libx265, slow) | 4~5x | 约 -30% |
| VP9 (libvpx-vp9, cpu-used=1) | 6~8x | 约 -32% |
一部两小时片子，H.264 半小时压完，VP9 要三个多小时。批量几百部时，这个差距直接决定你要不要加机器。我当时没算这笔账，压了二十部才发现时间成本爆炸——电费和机器折旧加起来，省下的存储根本不划算。
三、翻车点二：播放端兼容性
H.265 的坑在老设备。我压完丢给测试同事，他的老款 Windows 笔记本（没装 HEVC 扩展）直接黑屏报错——Windows 对 HEVC 解码是收费授权的，很多裸机根本不带。VP9 反而因为 Chrome 和安卓原生支持，在 Web 端和手机端一路畅通。
所以"体积更小"的 H.265，省了存储，却可能把成本转嫁到用户的解码能力上。这个权衡我当时完全没考虑——我只看了压缩率曲线，没看用户设备分布。
四、画质维度
同体积比画质，H.265 和 VP9 是同一梯队，都比 H.264 好一截；AV1（更新的 royalty-free 编码）更好但编码慢到离谱（20x+），现阶段不实用。但"同体积"是理想条件——实际我为了控制时间，VP9 的 cpu-used 只能开到较高值（编码更快但画质略降），结果 VP9 的实际画质反而没拉开优势。也就是说：VP9 的理论优势，需要你舍得花编码时间才能兑现。
五、授权与专利
这是很多人忽略的暗坑：
- H.264 / H.265 受 MPEG-LA / HEVC Advance 专利池约束，商业分发要交专利费（虽然个人非商业基本没人管，但做产品得上心）。
- VP9 / AV1 由 Google/开放媒体联盟推，免版税，做 Web 服务没有授权顾虑。
- 所以如果你做的是面向公众的产品，VP9/AV1 在法律层面更干净。
六、我现在的分层做法
- 存档母带：H.264 CRF 18，求稳求快，十年后还能播，不赌新编码的生命周期。
- Web 端流媒体：VP9，浏览器零成本解码，省下的体积是真金白银的带宽费。
- 交付给客户的下载文件：默认 H.264，兼容性 MAX；客户明确要小体积才给 H.265 版，并附解码说明。
- 未来观察 AV1：等硬件解码普及（现在新手机/显卡开始支持），再考虑迁移，不抢跑。
七、一个判断框架
选型前先问三个问题：
1. 谁来看？ 可控设备 → VP9/H.265 随便；不可控大众 → H.264 保底。
2. 规模多大？ 几百部以上，编码时间就是钱，优先快编码。
3. 体积敏感吗？ 不敏感就别折腾新编码。
八、实测对比（一段 2 分钟 1080p 动画）
| 方案 | 体积 | 编码耗时 | 我老笔记本能播？ |
|---|---|---|---|
| H.264 CRF 20 | 85 MB | 18 s | 能 |
| H.265 CRF 24 | 58 MB | 82 s | 不能（无 HEVC 扩展） |
| VP9 CRF 32 | 56 MB | 140 s | 能（Chrome） |
体积 H.265/VP9 都省了约 30%，但 H.265 老设备翻车——这就是我说的"省了存储、坑了用户"。
九、别陷入"参数最优"陷阱
我翻车的根源不是技术判断错，是只优化了单一指标（体积）。真实世界里，编码时间、播放兼容性、授权成本、维护复杂度都是变量。压缩选型不是"选最好的"，是"选最不添乱的"。
那次复盘后我把"兼容性优先"写进了团队规范：默认 H.264，新编码只在新项目、可控端、且确有体积诉求时才启用。技术参数漂亮，抵不过上线前的兼容性一票否决。