视频格式对比：MP4、WebM、MOV、AVI 按用途选择

2026-04-13发布 9分钟阅读

摘要 (TL;DR)

去年一位做视频剪辑的朋友问我：“这是 MP4 文件，为什么 Premiere 读不了？“扩展名确实是 .mp4，但里面装的是 Sony 相机出的 HEVC 10 比特 4:2:2，他的工具链只认 H.264。容器没问题，问题在编码器。这一句”扩展名是盒子，编码器是内容物”几乎就是视频格式 90% 的内容，所以我直接放在最前面。

视频格式里最有用的一个区分是容器（MP4、WebM、MOV、AVI、MKV）和编码器（H.264、H.265/HEVC、AV1、VP9、ProRes）。容器是包装，编码器是里面的压缩算法。实操建议从这条分裂出来。面向公开网络，MP4 + H.264 仍然是最稳的默认。带宽紧张又能接受更长编码时间时，AV1 或 H.265 装在 MP4 或 WebM 里能在等画质下做到显著更小的文件。剪辑母带通常用 MOV + ProRes。长期归档则常用 MKV + AV1 或 H.265，因为 MKV 在多音轨、字幕、章节方面非常灵活。AVI 不是”默认高画质”，它只是个老容器，对现代元数据和字幕支持有限。H.265 在等画质下比 H.264 大约高效 40–50%，但有专利费和老设备兼容问题；AV1 免版税，但 2025 年硬件编码器仍偏少。

背景与概念

容器把视频、音频、字幕、章节、元数据装在同一个文件里。MP4 基于 ISO Base Media File Format，WebM 是面向网络的 Matroska 子集，MOV 是 Apple 的 QuickTime 容器，AVI 可追溯到 1992 年，MKV（Matroska）扩展性强、对编码器几乎不挑。

编码器才是真正压像素的算法。H.264（AVC）自 2003 年标准化以来，在 20 多年里成了事实标准，几乎所有设备都有硬件解码。H.265（HEVC）在等画质下能做到 H.264 大约一半的码率，但要受专利池许可约束，老设备的硬件支持也不均衡。AV1 由 AOM（Alliance for Open Media）于 2018 年发布，目标是达到 HEVC 级别甚至更好的效率且免版税。VP9 在 WebM 和 YouTube 里广泛使用。ProRes 是 Apple 的剪辑用编码器，故意保留较低压缩率以换取剪辑时帧级解码的快速响应。所以画质不是容器的属性——画质由编码器、码率、编码器设置决定。

实战中还有两个概念会反复出现。码率控制决定编码器是按恒定码率（CBR）以适合可预测流，还是平均码率（ABR），还是恒定质量目标（CRF, Constant Rate Factor）。点播交付里 CRF 通常在更小的平均文件下做出更好的画质，因为编码器把比特用在需要的地方，简单镜头则少用。GOP 结构——即帧内（I）、预测（P）、双向（B）帧的排列——同时影响压缩效率和拖动定位的速度。GOP 紧（I 帧多）拖动友好；GOP 松压缩更好。流媒体管线常常把 GOP 长度对齐分段边界（比如每 2 秒），让 ABR 切换无缝。

对比与数据

容器常用编码器浏览器播放元数据与字幕压缩效率备注
MP4H.264、H.265、AV1H.264 全平台广泛（ID3、章节）取决于编码器网络交付的默认
WebMVP9、AV1Chrome、Firefox、Edge、Safari 较新版WebVTT 字幕AV1 下很强开放、免版税
MOVH.264、ProRes 等直接网页播放有限轨道模型非常丰富适合剪辑macOS、iOS 原生
AVIXvid、DivX 等现代浏览器较差有限老旧低效兼容老资料
MKV几乎任何编码器直接网页播放有限极其灵活取决于编码器归档常用

像”高效 50%“这种数字是等画质下的粗略平均。实际结果严重依赖内容、码率、预设、编码器。在没有先匹配画质目标前，跨编码器比较码率几乎没有意义。

实战场景

**场景 1 — 在公开网站上分发视频。**最稳的默认是 MP4 + H.264 High Profile + AAC-LC。一段 90 秒的产品介绍，我经常用 ffmpeg -c:v libx264 -crf 23 -preset slow -c:a aac -b:a 128k，1080p 大约 8MB，看起来很干净。如果想省带宽且观众用较新浏览器，再加一个 WebM 源（AV1 或 VP9），让 <video> 元素自己选最合适的。字幕用单独的 WebVTT 轨，便于无障碍和被发现。

场景 2 — 保存剪辑母带。剪辑时间线适合轻压缩格式，比如 MOV + ProRes 422。我曾在 DaVinci Resolve 直接拿 HEVC 源剪辑，结果每个剪点都卡顿；转码成 ProRes 422 代理后，同一项目在同一台机器上能实时回放。代价是文件大——10 分钟 1080p 大约 8GB——但每帧解码很便宜，所以拖动和裁剪都很顺。剪完之后再单次编码到交付格式（H.264 或 H.265），千万别拿交付编码器当编辑底片。

**场景 3 — 长期归档。**为多年后还能用而存的母带，MKV + AV1 是个不错的现代默认。我一直在用 SvtAv1EncApp --preset 4 --crf 28 重压老的 4K 母带，体积落到 H.264 原版的 40–55%，在校准过的显示器上看不出区别。AV1 免版税，压缩效率强，MKV 还能在一个文件里装多条音轨、字幕、章节。归档拷贝用 CRF + 充裕码率以避免明显损失。

**场景 4 — 面向大量观众的自适应流。**做规模化的直播或点播时，“用哪个容器”的问题部分被流容器的问题取代：fMP4 分段配 HLS 或 DASH 通常承载 H.264 与 H.265，WebM 分段则承载 VP9 或 AV1。重要的不是扩展名，而是分段是否对齐 IDR/I 帧边界，让 ABR 播放器能干净地切换码率。这里”用哪个容器”的争论大部分会消失，因为 CDN 和打包器决定了线上格式。

常见误解

**“AVI 总是高画质。“**AVI 只是一个老容器；画质由内部编码器和码率决定。同一编码器装在 MP4 或 MKV 里画质几乎一致，且字幕和元数据支持更好。

**“MOV 是 Apple 专属。“**MOV 起源于 QuickTime，但在 Windows 与 Linux 上的播放器支持也很广。比较弱的环节是浏览器直接播放——Web 交付时重新封装成 MP4。

**“H.265 总是好过 H.264。“**它确实更高效，但许可成本和老设备硬件支持的不均衡让 H.264 在面向异质公众时仍是更稳的默认。

**“AV1 是新标准。“**势头确实存在——Intel Arc、Apple M3 系列、NVIDIA RTX 40 系列都已带 AV1 硬件编码器——但截至 2026 年初，多数生产级直播管线仍跑在 H.264 或 H.265 上，因为实时 AV1 编码在功耗、热量和可靠编码器的许可成本上都不便宜。AV1 适合批量编码和归档，不太适合大规模实时入流。

**“分辨率越高越好看。“**前提是源和显示都支持。低码率的 4K 画质可能比高码率的 1080p 还差，因为编码器没足够比特描述多出来的像素。在 Web 交付里，按”分辨率对应的目标码率”去想，而不是只看分辨率。

**“看扩展名就能知道画质。“**一个 .mp4 文件可能装的是 1Mbps 的 H.264 也可能是 20Mbps 的 H.265；扩展名什么也说明不了。决定前用 ffprobe 或 MediaInfo 之类的工具检查实际编码器、码率、分辨率、帧率。

决策清单

  1. 最终用途是什么？
    • 公开 Web 交付：MP4 + H.264 回退；可行时再加 AV1。
    • 内部或特定播放器：先核对该播放器的编码器清单。
    • 剪辑母带：MOV + ProRes 或同类。
    • 长期归档：MKV + AV1 或 H.265。
  2. **观众的设备和浏览器分布如何？**老硬件占比高就必须留 H.264 回退。
  3. **优先文件体积还是画质？**体积优先 → AV1 或 H.265。兼容优先 → H.264。
  4. **多音轨、字幕、章节是否重要？**重要就选 MKV 或带完整轨道结构的 MP4。
  5. **成本结构如何？**算上 H.265 许可（如果适用）、AV1 编码时间和能耗。
  6. **以后还会再剪辑吗？**在交付编码之外另存一份剪辑级母带（MOV + ProRes 或同类），下次修订就不必从已经有损的文件再退化。

补一句实战经验：音频通常比创作者想象的更重要。听众对视频压缩伪影的容忍度比对削波或编码差的音频高得多。Web 交付下 AAC 128kbps 立体声是合理的下限；偏音乐的内容用 192–256kbps 或 WebM 里的 Opus 在相近码率下能听出明显更好。资产之间统一采样率（视频里通常 48kHz）能避免剪辑中重采样伪影。

相关工具

上述场景中的实际转换可以在 Patrache Studio 视频转换工具 里试。和视频搭配的缩略图、海报、开场静帧请遵循 图像压缩完全指南 的格式规则，控制整页体积。如果要把可扫描的二维码贴到视频或包装上，先看 二维码安全 了解静态码与动态码的取舍再印刷或发布。

参考资料

相关工具

tools.patrache.studio/video/converter/