MP4 网页加载慢、进度条拖不动怎么办？

MP4 的 moov 索引是什么，为什么会影响起播

moov 是 MP4 的目录，播放器必须先读到它才能开播。一个 MP4 文件由若干个 atom（也叫 box）顺序拼成，最常见的三个是：

• ftyp：文件类型声明，只有几十字节，永远在开头。
• mdat：真正的音视频数据，占文件体积的 99% 以上。
• moov：时长、分辨率、编码参数，以及每一帧在 mdat 里的偏移位置。

编码器边录边写 mdat，写完之前并不知道总共有多少帧，所以默认在最后才把 moov 补到文件尾部。本地播放器可以随意跳读，差别不明显；网页播放器靠 HTTP 下载，顺序读到的是一大段 mdat，索引却在最后。

我们用 ffmpeg 默认参数导出了一段 60 秒、1920×1080、约 46MB 的 H.264 MP4，查看顶层结构：moov 只有 66KB，却排在第 45.96MB 之后。做 FastStart 之后，moov 移到第 32 字节处，文件总字节数一个不差，仍是 46,023,203 字节，整个过程在普通电脑上不到 0.2 秒。

moov 在尾部一定会卡吗？关键看服务器支不支持 Range

服务器支持 Range 时影响较小，不支持时影响很大。Range 请求允许浏览器只下载文件的某一段。浏览器发现开头没有 moov，会直接请求文件末尾那一段，拿到索引后再回到需要的位置继续读。

为了看清楚差别，我们在本机起了一个限速约 32Mbps 的测试服务器，用 Chromium 打开一段 18.1MB、30 秒 720p 的 MP4，记录拿到时长信息（loadedmetadata）的时间和浏览器发出的请求：

本机测试几乎没有网络延迟，所以支持 Range 时两者只差几毫秒；真实网络里，那一次“跳到末尾”的额外请求要多花一个往返，手机网络下常见 100～300 毫秒。不支持 Range 的服务器才是真正的重灾区：文件越大，等待越久，一个 500MB 的视频在 32Mbps 带宽下要等两分钟以上。

一些老式虚拟主机、自己写的下载接口、部分网盘外链不会返回 Accept-Ranges: bytes，也不回应 206 状态码。这类环境下，FastStart 几乎是必做项。

怎么把 MP4 优化成快速播放

在浏览器里做一次 FastStart 流拷贝即可，不需要重新压缩。具体顺序：

1. 先确认文件本身没问题：用视频编码检测器能读出时长、视频编码和音频编码，说明索引完整。
2. 打开优化 MP4 快速播放，选择文件并点击优化。工具复制原有音视频流，只重写容器结构，视频不上传服务器。
3. 下载结果，本地播放一遍，检查画面方向、声音和结尾是否完整。
4. 用新文件替换网页、CMS 或对象存储里的旧文件；有 CDN 的话记得刷新缓存，否则访客拿到的仍是旧版本。

以后自己导出视频时，可以留意导出设置里有没有“网络优化”“Fast Start”一类选项，HandBrake 的“Web Optimized”就是它。导出时勾上，就省掉了事后处理这一步。

FastStart 之后还是慢，还要查什么

FastStart 只解决索引位置，其余瓶颈要分开排查。按下面的症状对照处理：

码率偏高是第二常见的原因，按视频压缩指南先把体积降下来；画面根本出不来、只有声音或完全打不开，属于兼容问题，可以顺着视频打不开排查指南逐项检查。时长超过 10 分钟、访客网络差异很大的站点，更适合切成 HLS（M3U8）分段播放，而不是继续优化单个 MP4。

FastStart 会不会影响画质和兼容性

不影响画质，也不会降低兼容性。FastStart 使用流拷贝，视频和音频的编码数据逐字节保留，分辨率、帧率、码率、声道都不变。moov 在开头本身就是 MP4 规范允许的标准布局，主流播放器和浏览器都能正常识别。

• 体积：基本不变，最多相差几 KB 的对齐数据。
• 耗时：只有读写一遍文件的时间，远快于转码。
• 字幕与数据轨：小鹿 Video 的优化工具只保留主视频和音频，内嵌软字幕需要单独保存。
• 重复处理：对已经 FastStart 的文件再做一次没有副作用。

网页上的 MP4 加载慢，先做一次 FastStart，再看服务器是否支持 Range——这两步能排除大部分“本地秒开、网页转圈”的情况。