如何为 Web 播放选择合适的视频编解码器

编解码器选择是产品决策，不只是压缩决策

视频编解码器很容易被讨论得很糟。有人把 AV1、H.264、VP9 和 HEVC 放在一张图表上比较，指着最小的文件，然后宣布胜者。这不是生产环境中 Web 播放的工作方式。

一次编解码器决策会影响启动时间、缓冲、续航、CDN 成本、设备兼容性、编码基础设施、法律风险和支持工单。对于拥有大型编码集群的流媒体服务来说“最好”的编解码器，不一定适合只有五个产品视频的营销网站。

有用的问题不是“哪个编解码器最好？”而是：哪个编解码器能让这类受众以最低的运营风险获得良好的播放体验？

简短版本：2026 年该用什么

对大多数 Web 团队来说，实际答案大致如下：

• 使用 H.264 作为基线。 它很老，但足够高效，硬件解码支持广泛，仍然是最安全的兼容层。
• 当视频量或带宽成本值得时，加入 AV1。 AV1 可以提供出色的压缩效果，尤其是在较低码率下，但编码更慢，旧设备可能需要回退。
• 主要在受众和流程已经偏向 VP9 时使用 VP9。 它仍然有用，尤其是在 WebM 工作流以及一些 Android/桌面环境中，但 AV1 是更面向未来的开放编解码器。
• 在 Web 上谨慎使用 HEVC。 对 Apple 用户占比较高的受众来说它可能很有吸引力，但浏览器/平台支持和许可复杂性使它不适合作为通用默认选择。

这听起来可能很保守。确实如此。视频故障并不隐蔽。如果播放失败，用户不会欣赏你的压缩率。

了解四种主要的 Web 编解码器

H.264：仍然重要的乏味默认选择

H.264，也称为 AVC，仍然是 Web 上最安全的视频基线。它几乎可以在所有地方播放：桌面浏览器、移动浏览器、智能电视、旧设备、社交嵌入以及原生应用的 webview。

它的优势很简单：

• 支持范围非常广
• 编码工具成熟
• 硬件解码可靠
• 在移动端电池表现良好
• 流式播放支持可预测

它的弱点也很清楚。它的压缩效率不如 AV1 或 HEVC。在相同质量水平下，H.264 通常需要更多比特。如果你提供大量视频，这个差异会变成真实的 CDN 成本。

不过，对于短片、产品视频、文档视频以及中低流量网站，H.264 通常是正确的第一份编码。

AV1：高效但有真实取舍的编解码器

AV1 是现代 Web 交付中最强的开放编解码器选择。在相同码率下，它通常能提供比 H.264 和 VP9 更好的质量，尤其适合低带宽用户。这使它对流媒体平台、重媒体发布者、教育网站，以及任何认真关注传输成本的团队都很有吸引力。

但 AV1 不是免费的。编码在计算上成本较高，尽管现代编码器和硬件加速已经有了很大改进。播放支持也取决于设备。较新的桌面设备、Android 设备和电视越来越有能力；较旧的手机和笔记本电脑可能没有高效的硬件解码。

实用规则是：AV1 很适合作为额外 rendition，而不是唯一 rendition。 除非你能严格控制播放环境，否则请将它与 H.264 回退搭配使用。

这个决策类似于静态图像格式选择：只有当支持、编码时间和质量在真实环境中都站得住脚时，更好的压缩才有意义。同样的取舍思路也适用于像 AVIF 与 WebP 这样的图像格式决策。

VP9：仍然有用，但不再令人兴奋

VP9 是 AV1 成熟之前主要的开放替代方案。它可以比 H.264 高效得多，并且在许多基于 Chromium 的浏览器、Firefox、Android 环境以及一些电视平台上有稳固支持。

如果满足以下情况，VP9 仍然有意义：

• 你已经有 VP9 编码流程
• 你的受众主要是 Chrome、Firefox、Android 或智能电视
• 你需要 WebM 交付
• AV1 编码成本目前还不可接受

不过，对于 2026 年的新流程，VP9 作为长期高级编解码器更难被证明合理。如果你要超越 H.264，AV1 通常是更好的战略押注。

HEVC：技术上强大，运营上别扭

HEVC，也称为 H.265，效率很高，并且在一些生态系统中被广泛使用。它在 Apple 设备上尤其相关，因为硬件支持很常见。

问题不在于质量。问题在于 Web 实用性。浏览器支持长期以来较为碎片化，许可比开放编解码器更复杂，跨平台行为也可能不均衡。对于 Apple 用户占比较高的受众，或接近原生应用的工作流，HEVC 可以是一个聪明的补充，但它很少是最干净的通用 Web 默认选择。

如果你的分析数据显示 Safari/iOS/macOS 受众占比很高，HEVC 可能值得测试。如果你需要一个面向广泛 Web 的高级编解码器，请优先选择 AV1。

从你的受众开始，而不是从编解码器表格开始

在选择格式之前，先用自己的分析数据回答三个问题：

1. 哪些浏览器和设备真的在观看你的视频？ 桌面 Chrome 与低端 Android、iPhone 上的 Safari、应用内浏览器或智能电视并不相同。
2. 视频有多长？ 一个 12 秒的 hero 循环和一节 90 分钟的课程有非常不同的经济性。
3. 用户实际消耗了多少视频？ 页面浏览量不是观看时长。只有当人们观看的秒数足够让编解码器产生影响时，带宽节省才最重要。

如果你的视频流量较轻，一个压缩良好的 H.264 MP4 可能已经足够。如果视频是产品的核心，请使用多个 rendition 和现代编解码器。

将编解码器选择与交付模式匹配

简单嵌入式视频

对于只有少量视频的小网站，从以下组合开始：

• H.264 视频
• AAC 音频
• MP4 容器
• 合理的分辨率和码率
• 海报图
• 在适当位置使用延迟加载

这个组合并不亮眼，但有效。你也可以在 MP4 回退之前，可选地添加 AV1 或 VP9 作为 WebM source：

<video controls preload="metadata" poster="poster.jpg">
  <source src="demo-av1.webm" type="video/webm; codecs=av01.0.05M.08">
  <source src="demo-h264.mp4" type="video/mp4; codecs=avc1.4d401f, mp4a.40.2">
</video>

浏览器会选择它能播放的第一个 source。请在真实设备上测试，而不只是你的开发笔记本电脑。

流式播放和长视频播放

对于更长的内容，自适应码率流式播放比任何单一编解码器都更重要。HLS 和 MPEG-DASH 允许播放器根据网络和设备条件在不同质量级别之间切换。

一个实用的流式播放 ladder 可能包括：

• 面向广泛兼容性的 H.264 renditions
• 面向有能力的现代客户端的 AV1 renditions
• 多种分辨率和码率
• 在有用时使用独立音频 renditions
• 针对启动和切换行为调优的分片大小

编解码器选择和码率 ladder 设计应该一起测试。如果启动很慢、分片太大，或中端设备难以解码，那么某个码率下漂亮的 AV1 编码并没有帮助。

不要忽视硬件解码

软件支持某个编解码器，并不等于它被很好地支持。软件解码可能增加 CPU 使用率、消耗电池并导致掉帧。对于移动用户、电池供电的笔记本电脑以及 4K 播放来说，这一点尤其重要。

测试时，请关注：

• CPU 和 GPU 使用率
• 电池消耗
• 掉帧
• 笔记本电脑风扇噪音
• 手机发热
• 启动延迟
• 拖动响应速度

这就是“最佳压缩”可能输给“足够好且硬件解码”的地方。一个播放流畅但文件更大的 H.264 文件，可能比一个在旧硬件上消耗用户电池的较小 AV1 文件更好。

码率仍然比团队承认的更重要

编解码器选择无法拯救草率的码率 ladder。许多 Web 视频之所以浪费，是因为它们以制作母版设置导出，然后在没有合理交付计划的情况下上传。

作为 H.264 SDR Web 播放的粗略起点：

• 720p：约 2–4 Mbps
• 1080p：约 4–8 Mbps
• 4K：约 12–25 Mbps

AV1 和 HEVC 在相似感知质量下通常可以更低，但内容很重要。人物讲话镜头与游戏录制、屏幕录制、动画、体育或颗粒感较强的胶片，其压缩方式都不同。

始终进行视觉测试。压缩指标有帮助，但人类感知决定视频是否可接受。

容器和 MIME 类型也是工作的一部分

编解码器不是文件格式。H.264 通常以 MP4 交付。AV1 可根据目标支持和流程，以 WebM 或 MP4 交付。VP9 通常是 WebM。音频编解码器选择同样重要：AAC 仍然是安全的 MP4 音频默认选择，而 Opus 在 WebM 工作流中非常出色。

提供正确的 MIME 类型。确保 range requests 正常工作。有意识地配置缓存。损坏的 header 可能导致视频拖动失败，或迫使不必要的重新下载。如果视频在生产环境和本地表现不同，请检查实际的 HTTP response；在生产环境中调试重定向和 HTTP headers 的方法可以直接应用于媒体交付。

衡量播放，而不只是页面速度

通用性能评分可以标记沉重的页面，但它们无法完整解释视频体验。请跟踪视频专用信号：

• 首帧时间
• 启动延迟
• 重新缓冲比例
• 实际交付的平均码率
• 掉帧
• 按浏览器和设备划分的错误率
• 观看时长和放弃点

页面审计仍然有助于发现周边问题：过大的海报图、阻塞渲染的脚本、糟糕的延迟加载，以及播放器周围的布局偏移。如果你的团队把 Lighthouse 作为第一轮检查，请把它当作优先级排序工具，而不是最终裁决；Lighthouse 报告需要解读，尤其是在重媒体页面上。

一棵实用决策树

把它作为起点：

1. 需要最大兼容性？ 使用 H.264 MP4。
2. 每个用户会观看很多分钟的视频？ 在支持的地方添加 AV1 renditions。
3. 受众主要是 Apple 设备？ 考虑将 HEVC 作为额外 rendition，而不是唯一选择。
4. 已经投入 VP9？ 如果表现良好，就继续保留；不要在没有证据的情况下急着迁移。
5. 长视频或网络条件多变？ 先使用自适应流式播放，再去纠结某一个编解码器。
6. 低端移动端受众？ 优先选择硬件解码格式和保守码率。
7. 短装饰性视频？ 考虑它是否真的应该是视频。静态图像、动画或更短的循环可能更好。

<!-- tool-cta:start -->

💡 试试这个: 使用 Video Converter 测试不同编解码器在你的内容上的实际效果，让你的决定基于真实输出，而不是通用基准测试。

<!-- tool-cta:end -->

理性的默认建议

如果你今天正在构建或更新 Web 视频流程，从这里开始：

• 编码一个可靠的 H.264/AAC MP4 回退。
• 为能从中受益的浏览器和设备添加 AV1。
• 对长视频内容使用自适应流式播放。
• 在真实设备上测试，包括较旧和较低端的硬件。
• 上线后监控播放错误和缓冲。

编解码器选择不是一次性声明。它是一项维护选择。浏览器支持会改进，硬件会变化，编码工具会变快，你的受众也会迁移。定期复盘这个决策，但不要追逐每一个新的编解码器公告。正确的编解码器，是你的用户能够以可接受质量流畅播放、不会浪费带宽，也不会让交付栈变脆弱的那个。