如果你正在制作视频、转换已有文件，或为网站准备视频内容，那么选择合适的格式和压缩参数就是最重要的决定之一。文件并非越小越好：它还必须能在浏览器中可靠播放、适用于智能手机、便于高效解码，并为实际用途保留足够的画质。
我研究了 MP4、WebM、H.264、H.265/HEVC、VP9、AV1、FFmpeg、x264 编码预设、浏览器兼容性、移动设备硬件解码以及视频质量评估。我还进行了实际压缩实验：用多个 CRF 值编码同一个源视频，通过肉眼观察和客观指标比较结果。
如果需要一份视频文件尽可能兼容各类浏览器、手机和外部应用程序，我最终决定优先采用 MP4 + H.264。
对于主要在手机上观看的短视频，如果快速加载和小文件体积比保留每一处细节更重要，我选择了 x264 CRF 30。原因是我发现，即使在大尺寸桌面显示器上正常播放，也看不出 CRF 22 与 30 之间有明显差别。
但这里必须强调一个重要前提：我并不建议电影、高品质视频制作或以最高视觉保真度为目标的素材使用 CRF 30。对于这些用途，更保守的数值（通常可以从 CRF 20 左右开始）可能更合适。我没有对故事长片或高品质电影画面进行同等程度的测试，因此这些参数仅应作为另行测试的起点。
本文会说明这一选择背后的技术依据、实际压缩结果、实验的局限，以及如何为自己的项目选择视频格式与质量参数。
1. 视频容器和视频编解码器不是一回事
在比较 MP4 和 WebM 之前，首先要理解容器与编解码器的区别。
容器负责将视频、音频、时间戳和元数据放在同一个文件中。视频编解码器则决定视频帧如何压缩和解码。
例如，MP4 可以封装 H.264、HEVC 或 AV1 视频。即使扩展名相同，不同组合的压缩特性及设备要求也可能不同。
| 组成部分 | 示例 | 作用 |
|---|---|---|
| 视频容器 | MP4, WebM, MOV, MKV | 封装视频、音频及时间信息 |
| 视频编解码器 | H.264, HEVC, VP9, AV1 | 压缩和解压缩视频帧 |
| 音频编解码器 | AAC, Opus, MP3 | 压缩和解压缩音频 |
| 视频编码器 | x264, x265, SVT-AV1, libvpx-vp9 | 执行视频压缩编码 |
将文件名的扩展名从 .webm 改成 .mp4，并不会转换视频编码。同样，把 AV1 放进 MP4 容器，也不会让不支持 AV1 解码的设备突然能够播放。
讨论视频兼容性时，必须综合考虑容器、视频编码、音频编码、编码配置文件（profile）、位深以及播放环境。
2. MP4 与 WebM：网页视频应该选哪个？
MP4 和 WebM 都是成熟的现代视频容器。由于实际表现取决于内部使用的编解码器，因此没有一种格式在所有情况下都更好。
MP4 + H.264：实际使用中的广泛兼容性
使用 H.264 视频和 AAC 音频的 MP4 长期以来具备极其广泛的兼容性。主流桌面浏览器、移动浏览器、操作系统自带播放器以及许多第三方应用程序都支持它。
智能手机和计算机上的硬件视频解码器也普遍支持这种组合。与软件解码相比，硬件解码通常可以降低 CPU 占用、提高播放效率并减少耗电。
它的主要劣势在于压缩效率。新一代编解码器通常能以更低的码率提供接近的感知画质。
不过，当可靠播放比把文件压缩到极致更重要时，H.264 仍然是非常好的选择。
WebM + VP9：压缩高效，适合浏览器
WebM 通常包含 VP8、VP9 或 AV1 视频，音频则一般采用 Opus 或 Vorbis 编码。
在视觉质量相近时，VP9 的压缩效率通常优于 H.264。目前的浏览器普遍支持它，包括现代版本的 Safari。
因此，断言 Safari 完全不支持 WebM 或 VP9 是不准确的。浏览器兼容性已经随着时间明显改善。
更重要的限制来自浏览器之外。操作系统原生应用、旧设备和第三方软件对 WebM 的支持可能不如常规 H.264 MP4 稳定一致。
如果应用只在浏览器中运行，而且可以控制播放能力，那么 WebM 是不错的选择。但如果访客可能下载视频并用各种软件打开，MP4/H.264 依然更可预测。
实际差异对比
| 需求 | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| 现代浏览器播放 | 极佳 | 很好 |
| 旧版浏览器和设备兼容性 | 通常更强 | 更依赖具体环境 |
| 下载后的文件兼容性 | 通常更强 | 不同原生应用间的表现较难预测 |
| 压缩效率 | 良好 | 通常更高 |
| 硬件解码 | 覆盖非常广 | 较普遍，但取决于设备 |
| 最适合的场景 | 只提供一份且需广泛兼容的文件 | 已知客户端环境下的高效网页视频分发 |
问题的关键不在于 WebM 是否优秀，而在于：对你的具体环境来说，压缩效率优势是否值得以一定的兼容性作为交换。
3. H.264、H.265、VP9 与 AV1：该选哪种视频编码？
每种主流视频编解码器，都在压缩效率、编码成本、硬件支持、软件兼容性及授权许可之间做出了不同权衡。
| 编解码器 | 压缩效率 | 实际兼容性 | 典型用途 |
|---|---|---|---|
| H.264 / AVC | 良好 | 极佳 | 普通网页视频、移动播放、文件下载 |
| H.265 / HEVC | 通常优于 H.264 | 取决于环境 | 兼容的 Apple 设备、受控环境、高分辨率视频 |
| VP9 | 通常优于 H.264 | 现代浏览器中很好 | 基于浏览器的视频分发 |
| AV1 | 潜在压缩效率极高 | 支持不断增加，但旧设备仍有限制 | 现代流媒体及兼容设备 |
这些只是定性比较，并非适用于所有素材的码率排行榜。实际效率取决于视频内容、编码器实现、目标质量、编码预设和测量方法。
H.264：成熟、易于高效解码、支持广泛
H.264 经过高度优化，获得了大量硬件与软件的支持。如果视频需要在不安装专用播放器的情况下可靠播放，这种成熟度就是优势。
它的不足是新编码往往能更高效地压缩视频。此外，H.264 涉及专利及许可问题，相关商业分发场景需要自行审查。
H.265 / HEVC：压缩更高效，但兼容性需要权衡
在画质相近时，HEVC 可以比 H.264 显著降低码率。它尤其适合高分辨率内容，以及能够控制设备兼容性的环境。
许多 Apple 设备对 HEVC 的支持非常好。但浏览器和外部应用的支持情况会因操作系统、安装的解码组件而异；许可授权也是需要考虑的因素。
HEVC 可以是出色的选择，但我不会直接把它作为通用网站唯一可下载的视频格式。
VP9：实用的开放式替代方案
VP9 具有良好的压缩性能，并广泛兼容现代浏览器。如果视频始终在浏览器内播放，而且播放环境可预测，它很有吸引力。
对于我的使用场景，主要缺点是用户下载视频或通过原生应用打开时可能遇到兼容性问题，因为这些应用未必能稳定支持 WebM 或 VP9。
AV1：压缩效率出色，但硬件支持尚未普及到所有设备
AV1 是最有前景的现代视频编解码器之一。与较旧的编码相比，它可以显著节省码率，硬件解码支持也在不断扩大。
不过，旧设备可能没有 AV1 解码器，或者只能使用软件解码。软件解码高分辨率视频可能消耗更多 CPU 资源和电量，并在性能较弱的设备上造成播放问题。
如果可以控制播放环境，AV1 很值得认真考虑。如果一份文件必须兼容新旧设备以及普通的外部播放器，H.264 仍是更稳妥的默认选择。
MDN 视频编解码器指南提供了这些编码格式及其浏览器要求的实用资料。
4. 只用一种视频格式，还是提供多个版本？
这是视频分发架构中最重要的决策之一。
如果允许提供多个版本，网站就可以为兼容的设备使用 AV1 或 VP9，并为其他环境提供 H.264 作为回退方案。这样既能提升压缩效率，也能维持广泛的播放兼容性。
但维护多个版本也会增加编码、存储、缓存、验证以及播放版本选择的复杂度。
如果每个源视频只能生成一份最终文件，优先考虑兼容性通常更合适。
我选择 MP4/H.264，是因为我希望同一份视频能在主流浏览器、智能手机和常见的下载后播放场景中正常使用，而不依赖其他格式。
这并不是说 MP4/H.264 的压缩效率最高，而是我认为可靠、可预测的播放表现比新编码可能带来的体积优势更重要。
5. 为什么移动视频的优化重点不同
视频压缩方案应该符合内容实际被观看的方式。
主要在手机上观看的短片，与在大屏电视上观看的长篇电影，需求并不相同。前者更看重加载速度和移动流量消耗，后者可能更重视画质和细节。
对于面向手机的短视频，更小的文件可以带来几项好处：
- 开始播放前需要传输的数据更少。
- 在受限网络下，下载可能更快完成。
- 设备上占用的存储空间更少。
- 用户消耗的移动数据流量更少。
- 编码码率降低后，在带宽有限时播放可能更稳定。
不过，文件较小并不意味着视频绝对不会缓冲或卡顿。网络波动、峰值码率、服务器行为、播放缓冲机制以及设备解码性能都很重要。
移动端兼容性不仅取决于扩展名，还受到硬件解码能力、编码 profile 与 level、位深、色度子采样、分辨率、帧率和峰值码率的影响。在页面上显示为 390 CSS 像素宽的视频，在高像素密度手机屏幕上可能对应多得多的物理像素。因此，把单帧缩小到 390 像素宽进行检查，并不一定等同于在那部手机上观看原始视频。务必测试实际设备和真实播放条件。
CRF 控制的是质量，而不是强制规定精确的最高码率。即使视频整体很小，复杂画面也可能出现很高的瞬时码率峰值。如果必须确保在特别慢的网络上可靠播放，应考虑显式码率或 VBV 限制、合适的分辨率上限，并在接近真实的网络条件下测试。
核心原则很简单：针对预期的观看体验进行优化，而不是一味追求抽象意义上的最高画质。
6. 理解 x264 的 CRF：数值越低画质越好，越高文件越小
选择 H.264 后，接下来的难题是决定压缩得有多激进。
在 x264 中，恒定质量因子（Constant Rate Factor，CRF）用于控制画面细节保留与文件体积之间的平衡。
CRF 越低，通常画质越好、文件越大；CRF 越高，通常文件越小，但压缩损失越明显。
CRF 不会指定精确的码率或输出体积。编码器会根据源素材分配比特，因此简单画面与高细节画面在相同 CRF 下，也可能产生体积相差很大的文件。
CRF 也不决定解码器的基础兼容性。两个正确编码的 H.264 视频，即使分别使用 CRF 22 和 CRF 30，也可以拥有相同的编解码器、profile、level、像素格式、分辨率和帧率。
区别主要在于压缩质量和码率特征。
尤其要注意：不同编解码器实现的 CRF 数字不能直接对比。x264 中的 CRF 30，并不等于 AV1 编码器中 CRF 30 所对应的视觉质量。
7. 我的实际压缩实验：CRF 22 到 32
我想弄清楚视频究竟可以压缩到什么程度，才会在正常播放时出现明显差别。
我选择了一段较短、已经压缩过的视频，分别用 CRF 22、24、26、28、29、30、31 和 32 生成 H.264 对比文件。
实验保留了分辨率、帧率、时长和总帧数等视频关键属性，并保持编码器设置一致，以便评估单独改变 CRF 的影响。
测试结果表明，不同设置产生的文件体积差异很大。
| CRF | 相对于原始文件的近似体积 | 含义 |
|---|---|---|
| 22 | 63% | 压缩较保守，保留更多细节 |
| 24 | 49% | 文件更小，画质只额外损失少量 |
| 26 | 38% | 进一步减小体积，同时保留相当多细节 |
| 28 | 30% | 文件紧凑，与源素材仍较为相似 |
| 29 | 26% | 压缩更加激进 |
| 30 | 23% | 我认为最适合这段测试素材的折中选择 |
| 31 | 21% | 体积继续缩小，但源画面保真度下降 |
| 32 | 19% | 本次测试中体积最小，测得的画质损失也最大 |
这些百分比仅来自本次测试素材，不能视作任意视频的典型节省比例。表中的百分比都经过独立四舍五入；计算精确的相对节省量时，应使用原始文件大小，而不是将表中的舍入数值相除。
最令我意外的是：即使在大尺寸桌面显示器上正常播放，我也看不出 CRF 22 与 CRF 30 之间有明显的视觉差异。
我也检查了压缩更加激进的版本，包括 CRF 32；正常播放那段特定视频时，依然没有注意到明显差别。
这一观察很重要，因为这些视频本来主要用于较小的手机屏幕。如果在桌面显示器上画质下降都不会干扰观看，我就没有多少理由为不改善目标观看体验的额外细节付出明显增加的文件体积。
不过，这只是针对某类源素材的主观观察，并不能证明所有用户、所有手机或所有视频都会得到相同结果。高像素密度的手机屏幕和较近的观看距离，仍可能暴露压缩瑕疵，尤其是在精细细节和渐变区域。
8. 客观测量证实画质确实有所损失
正常播放时看不出区别，并不意味着两份视频在数学上完全相同。
我还使用客观图像质量指标比较了编码后的文件。随着 CRF 升高，视频与源素材的相似度逐渐降低。
在统一缩小尺寸、旨在近似高像素密度手机显示效果的比较中，具有代表性的 SSIM 数值如下：
| CRF | 近似 SSIM | 相对于 CRF 28 的输出体积 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
趋势很明确：压缩越激进，测得的编码视频保真度越低。仔细检查还能发现细线条和纹理中的轻微差别。
然而，对于这段测试素材，正常观看体验依旧非常接近。这正是为什么客观指标和主观评价应该结合使用。
SSIM 衡量的是图像相似度，而不是完整的人类观看体验。它无法全面反映时间维度的压缩瑕疵、感知锐度、运动表现，或观看者对某些细节的主观重视程度。
VMAF 是另一项有用的感知质量指标。Netflix 在 2026 年 6 月发布了VMAF v1 模型，其中包括针对手机观看条件设计的模型。这些模型明确考虑了屏幕尺寸和相对观看距离会部分影响感知画质。
本次调查中，一段采用保守设置编码的样本，报告的平均 VMAF 约为 95；但对所有激进 CRF 设置，并没有完整且一致的 VMAF 测量序列。因此，我没有用 VMAF 声称 CRF 30 或 32 达到了某种通用画质门槛。
能得出的实际结论更有限：本次测试的短视频在正常播放时，非常能够承受激进的 H.264 压缩。
9. 为什么我为手机短视频选择 CRF 30
比较各个文件后，我决定对类似的、主要在移动设备上观看的短视频采用 CRF 30。
理由很简单：
- 视频很短，并不以电影级画质为目标。
- 快速加载和更小的下载文件很重要。
- 在大尺寸桌面显示器上，我看不出 CRF 22 与 30 之间有明显差别。
- 与保守的设置相比，CRF 30 生成的文件小得多。
- CRF 32 在这段测试素材上看起来也能接受，但面对更复杂的素材时，我对它的把握较小。
与 CRF 28 相比，CRF 30 使测试输出文件缩小了约 21%；与 CRF 22 相比，缩小幅度超过 60%。
对于追求观感舒适、加载迅速且带宽消耗合理的手机短片，这样的取舍值得。
但前提极其重要：我选择 30，是基于实际观看用途与测试素材的结果，而不是因为 30 天然就是手机最好的 CRF。
手机并不要求使用 CRF 30，也完全可以播放保真度高得多的编码视频。选择 CRF 30，是在可以接受的情况下，有意识地牺牲部分源画面保真度来换取更小的文件。
如果要将这个设置用于内容差异很大的视频集合，我会先测试多段有代表性的素材，包括复杂运动、暗场、渐变、文字和精细纹理。
10. 为什么我不建议电影或高品质视频采用 CRF 30
这是本次实验最重要的局限。
不要把我对 CRF 30 的测试结果直接套用到故事长片、高端视频作品、专业素材或以大屏观看为主的视频上。
这类内容可能包含细腻的渐变、胶片颗粒、暗光场景、复杂运动、精细表面纹理和经过仔细调色的色彩。保留这些细节，可能比节省一部分带宽更重要。
对于常规的高质量 1080p 视频，我会先选用保守得多的 x264 参数，即CRF 20 左右，再根据素材测试它上下的数值。
如果重视视觉保真度，可以把 CRF 18–22 作为实用的起始范围；但具体合适的值也可能超出这个区间，取决于分辨率、内容和需求。
这一建议与常见的编码指南基本一致。例如，HandBrake 的画质设置文档建议，在很多 1080p x264 使用场景下可以采用约 RF 20–24。
我并没有对故事长片或高品质电影素材进行同样的受控实验。因此，我不能声称 CRF 20 在所有情况下都是最佳值，也不能说 CRF 22 一定足够，或任何特定电影在 CRF 30 下必然难以接受。
正确的方法是选取具有代表性的镜头，用几个不同的质量设置编码，在目标显示设备上比较，找出进一步压缩会明显损害画面的临界点。
如果视频需要存档、后续编辑，或作为未来再次编码的源文件，就应该把高品质母版与用于分发的压缩版本分别保留。
11. 为什么我采用 x264 的 veryslow 预设
CRF 控制压缩质量的一个方面，而 x264 的预设决定编码器愿意投入多少计算量来寻找高效的编码方式。
x264 提供从很快到很慢的多种预设。通常，更慢的预设会占用更多 CPU 时间，但能在视觉质量相近的情况下实现更高的压缩效率。
我用同一段源视频比较了 medium 与 veryslow。在测试采用的质量设置下，veryslow 生成的文件更小。
如果视频只需离线编码一次，却会被反复使用很多次，增加一些处理时间可能很划算。
因此，我选用了 -preset veryslow。
但这并不意味着它始终最佳。如果视频必须立即处理、CPU 资源昂贵，或有大量积压任务需要转换，那么 slow 或 medium 可能更符合实际运营需求。
预设主要影响编码复杂度与压缩效率。它不会把 H.264 变成另一种编解码器，也不会让输出文件天然无法在手机上播放。
12. 对于动画视频，我使用 x264 的 animation 调优
当源素材是绘制的动画或日式动画风格画面时，我会在 x264 中使用 -tune animation。
这与 CRF 设置不同。调优参数会修改编码器的部分决策，以适应特定画面特征。animation 调优面向手绘线条、大片平涂色彩区域以及风格化运动等素材特征。
因此，我的偏好是：
- 日式动画或其他绘制动画：使用
-preset veryslow -tune animation。 - 普通真人实拍视频：不要自动启用 animation 调优；先使用编码器默认设置，或单独评估适合的调优选项。
需要正确理解调优的作用。-tune animation 并不保证画质明显提升或文件变小。它只是改变编码器的行为，效果取决于素材。
我另外做过一次固定 CRF 的对比，检验 animation 调优的影响。在那次实验中，开启调优让文件体积增加了约 6%，而测得的图像相似度略有提高。肉眼看到的差别很小。
主要的 CRF 22–32 文件大小对比并未开启 animation 调优。因此，不能假定开启 -tune animation 后，该实验中的精确体积和压缩比例仍会相同。
尽管如此，对于日式动画素材，我依然偏向使用专门的 animation 调优，并将其产生的大小与画质纳入这类内容的编码方案评估。
编码器调优应该被视为依赖素材特征的调整，而不是放之四海皆准的画质升级。
13. 我为手机短篇动画视频推荐的 FFmpeg 设置
对于确实需要转码的常规 SDR 日式动画视频，我会把下面这条命令作为编码方案的起点：
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4这条命令明确指定了几个关键选择：
-c:v libx264：使用 H.264 软件编码器。-preset veryslow：优先提高压缩效率，而不是编码速度。-tune animation：启用面向动画的编码调优。-crf 30：采用我针对这种短视频选择的激进恒定质量目标。-profile:v high：选择现代设备广泛支持的 H.264 profile。-pix_fmt yuv420p：输出 8 位 4:2:0 视频。-map 0:v:0：选择第一路视频流。-map '0:a:0?'：在存在音频时选择第一路音频流。-c:a aac -b:a 128k：存在音频时，将其编码为常见的 AAC 音频。-movflags +faststart：将 MP4 初始化元数据移到接近文件开头的位置。
这只是示例命令，不能直接适用于所有输入素材。不同源视频可能需要额外处理。
特别是，不能在缺乏适当色彩管理的情况下，将 HDR 或 10 位素材直接转换成 8 位 SDR，否则可能出现色彩错误、高光细节丢失或明显色带。旋转元数据、可变帧率、采样宽高比、隔行扫描源、不常见的音频声道布局，以及分辨率兼容性限制，也都需要关注。
如果源视频的帧率和尺寸已经合适，通常保留它们更便于比较，也能避免不必要的缩放或运动变化。除非确有必要，否则不要强制把可变帧率素材转换为恒定帧率，因为这个过程可能复制或丢弃帧。如果要缩放，请保持显示宽高比，并确保尺寸符合所选 4:2:0 像素格式的要求。分辨率、帧率或 H.264 level 过高，可能超出旧设备的解码能力，因此有时必须主动降低分辨率或帧率以确保兼容。
14. 高品质视频更保守的 FFmpeg 起始设置
如果画质保真度远比文件体积重要，应该从较低的 CRF 开始，再评估效果。
例如，对于常规 SDR 真人实拍视频，下面的命令可以作为合理的实验起点：
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4示例中的 slow 预设是实用的通用起点，并不是说它比 veryslow 更好。如果可以接受额外的编码时间，使用 veryslow 同样合理。
这一高品质编码方案只是建议拿来测试的起点，并非我通过短视频实验验证过的最佳配置。
对于高品质视频，可以先尝试 CRF 18、20 和 22，再根据实际观感选择。难以处理的颗粒或运动画面可能需要不同设置，而存档母版可能需要温和得多的压缩。
15. 没有必要，就不要重新编码视频
有损视频压缩必然付出代价。已经压缩过的文件再次编码时，可能引入新的压缩瑕疵，即使新视频看起来与原文件很接近。
转码之前，先确认原文件是否已经满足兼容性、体积和画质需求。
如果文件本来就包含兼容的 H.264 视频和 AAC 音频，也不需要视觉处理，那么直接复制数据流可能比再次进行有损编码更合适。
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4这项操作会原样复制压缩后的视频和音频流，不再重新编码。它可以调整容器布局，同时避免又一轮有损压缩。
不过，通常不能指望它像重新编码并降低画质那样显著缩小文件。
如果现有视频已经足够小、兼容性好而且画质可以接受，保留原样也许就是最好的优化。
16. 不要只看文件大小：还要验证编码结果
FFmpeg 成功退出，并不能自动证明视频满足所有要求。
首先用 FFprobe 检查输出文件中的媒体流：
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4确认编解码器、像素格式、画面尺寸、帧率、时长和音频流。
然后完整解码输出视频，以检测部分损坏或解码错误：
ffmpeg -v error -xerror -i output.mp4 -f null -进行压缩实验时，应比较从同一源文件生成的输出。保持重要变量不变，每次只调整一项主要参数。
实际播放视频、观察运动画面并检查细节，特别注意渐变、暗部、运动物体和文字。
条件允许时，可使用 SSIM、PSNR 或 VMAF 等客观指标辅助肉眼对比。不要把某一个高分视为所有压缩瑕疵都不可见的证明。
最后，要在具有代表性的设备上，以及下载到本地后播放的场景中进行测试。浏览器支持信息很有价值，但当兼容性是主要目标时，真实播放测试尤其重要。
17. 确保网站正确分发 MP4 文件
再好的编码设置，也无法弥补糟糕的网页视频分发方式。
对于普通的渐进式 MP4 播放，应设置正确的 Content-Type: video/mp4 响应头，并在需要分段获取及拖动进度条时支持 HTTP 字节范围请求。
FFmpeg 的 +faststart 选项会把普通 MP4 文件的初始化信息移到接近文件开头的位置。这有利于渐进式加载，但不会提高视觉质量，也不会降低码率。
可以使用一个基本的 HTML 视频元素来播放 H.264 MP4：
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>preload 属性只是给浏览器的提示，并非严格的下载量限制。浏览器的自动播放规则也可能要求视频静音，或视频本身没有音轨。
如果页面包含多个视频，避免立即下载全部视频。只在需要时加载，可以减少移动数据消耗并提升用户感受到的响应速度。
对于手机短片，优化视频下载调度的重要性，可能不亚于缩小编码后文件本身。
18. 应该选择什么视频格式和画质？
答案取决于你希望优化的目标。
| 你的目标 | 建议的起始方案 |
|---|---|
| 一份同时适合网页播放和下载、兼容性广的视频 | MP4 + H.264；有音频时使用 AAC |
| 可提供多个格式版本的现代浏览器分发 | AV1 或 VP9，并提供 H.264 回退版本 |
| 在支持的设备上尽可能提高压缩效率 | 评估 AV1 |
| 可以控制的 HEVC 兼容播放环境 | 考虑 MP4 + HEVC |
| 以文件体积为优先的手机短视频 | 测试代表性素材后考虑 x264 CRF 30 |
| 日式动画或其他绘制动画 | 评估 x264 的 -tune animation |
| 高品质电影或高端视频 | 从接近 20 的较保守 CRF 开始测试 |
| 离线编码且 CPU 时间不是主要限制 | 考虑 x264 slow 或 veryslow |
| 需要快速处理且 CPU 资源有限 | 考虑 x264 medium 或 slow |
| 现有视频已经满足需求 | 直接保留或在不重新编码的情况下重新封装 |
| 归档或后续编辑 | 将高品质母版与分发文件分开保存 |
19. 我的最终选择，以及实验究竟证明了什么
研究视频格式、兼容性、编码效率和实际压缩结果后，我为面向手机的短视频选择了一套实用的分发方案。
格式选择 MP4 + H.264，因为对浏览器、手机、下载文件和外部应用程序来说，可预测的兼容性比通过新编码得到理论上最小的文件更重要。
编码器选择 libx264，预设为 veryslow，因为我可以离线编码这些视频，额外处理时间也在可接受范围内。
对于日式动画视频，我会使用 animation 调优，同时明白它只会调整编码器行为，并不能保证文件更小或在任何素材上画质都更好。
对于主要在手机上观看的短视频，我选择 CRF 30，因为实验显示，文件体积显著减小，而正常播放时没有出现我能察觉的明显差别，即使在大尺寸桌面显示器上比较也是如此。
这一结果并不意味着 CRF 30 适合电影或高品质素材。对于更重视精细细节、渐变、颗粒和整体保真度的内容，我会从 CRF 20 左右或其他适当保守的值开始测试。我并没有对电影素材进行相应的受控研究，因此不会把这个数值说成已经得到实验验证的最佳值。
最重要的结论是：不存在一种对所有视频都最好的编解码器、格式或 CRF 数值。
如果最重视广泛兼容性，而且只准备一份文件，MP4/H.264 是稳妥的默认选择。如果可以提供回退格式，并希望获得更高压缩效率，可以研究 VP9 和 AV1。如果你在压缩主要通过手机观看的短片，就测试较高的 CRF 是否能在不影响目标观看体验的前提下充分缩小文件。如果是电影或高端素材，应采用更保守的画质参数并认真验证。
先确定播放需求，再选择编解码器，最后确定压缩质量。随后，在真正相关的设备和条件下测试结果。与仅仅因为某种编码或 CRF 设置更先进、更高效或者更常被推荐就照搬相比，这种方法更可靠。