网页里的 MP4 迟迟不出画面。我会先保留原文件。再次导出以前还有一个检查值得做。负责一个小站时每多生成一个版本都要重新上传、检查和替换链接。如果等待原因尚未确定就反复改文件之后更难追溯原因。这次实测给了我一个可以先做的对照媒体内容不变只调整它在文件里的组织方式。我用 图映 ImgIng 的视频压缩工作台实际导出了两段海浪素材也另做了一组普通 MP4 的重封装实验。两件事需要分开看。工作台产物有自己的封装结构不能拿普通 MP4 的测试结果替它下结论。下面比较的是我单独准备的头部索引版和尾部索引版目的是排查起播等待不做画质评测。先解释两个容易混在一起的动作。重新编码会重新处理视频的编码内容这次重封装则保留已有媒体负载调整容器内的索引布局。我把两段真实海浪各制作成 8 秒、960×540、25fps 的普通 MP4再分别得到头尾两个版本。从这一步开始没有再次编码比较对象的内容才算固定下来。两张海浪图看起来相似还不够。我检查了两个版本中 mdat 的有效负载也就是文件内承载媒体数据的那部分。每对头尾版本的 SHA256 哈希相同。这提供了字节层面的对照依据。整个文件的哈希不必相同。容器布局已经变了。也不能把这个检查说成“所有重封装操作都不会改变内容”。普通 MP4 里的 moov 保存播放所需的元信息和索引。播放器需要先拿到它。索引在尾部时就要先读取文件尾部。本文的头部版只是把这项等待条件改变了。FFmpeg 的格式文档也将普通文件的 faststart 与分片输出分开描述。两者不能仅凭 MP4 后缀归为同一类产物。我测了 A 样本在 Chromium 149 中的两种布局。服务端都忽略 Range 范围请求。每秒传输预算固定为 256 KiB。尾部索引版两次首帧等待为 5.773 秒和 5.792 秒中位数 5.782 秒。头部版两次为 0.479 秒和 0.483 秒中位数 0.481 秒。计时从设置视频地址到第一次帧回调两个组合各测两次。这组数字支持的是一个很具体的判断本次起播等待可以在媒体负载不变的条件下缩短。它不能说明哪个编码器的画质更好也不能算成调低码率带来的收益。先保留内容才好单独看出布局的影响。若同时把分辨率、编码方式和索引位置都换掉结果即使更快也不好解释。交付方式也会影响同一个尾部文件。下面两张图来自较大的 B 样本使用同一份尾部索引 MP4。第一张是不支持范围读取时仍在等待第二张是支持范围读取后已出现画面。它们是本地受控复现页展示的是读取方式对等待状态的影响不是两份不同画质视频的比较。配图里的 B 样本约 5.07 MB。前面的 5.782 秒与 0.481 秒属于 A 样本。两者不能互换。图也不是图映的操作界面。实际工作台导出的两份文件都含有多组 moof 和 mdat属于分片 MP4。因此我没有把“普通 MP4 搬索引”的步骤写成图映内部做法也没有承诺所有导出视频都会更早显示。本轮测量于 2026 年 9 月 30 日在 macOS 26.5.2 上完成。每条视频请求开始前还设置了 80 毫秒等待。网络条件是本地人为控制的不能直接当作线上访问速度。配图海浪来自 דוד שי 的 Wikimedia Commons 素材按 CC BY-SA 4.0 使用做了截取、缩放和转码。素材非本人拍摄。遇到自己的视频起播慢时我会先保存原文件和可复现的页面地址。接着在同一浏览器、同一交付条件下比较原文件与仅重封装的副本并核对媒体负载是否保持一致。首帧等待变了就留下两份文件及测量条件。没有改善也如实记录。等布局和读取方式检查清楚再决定是否另开一轮编码参数实验别让第一次排查就同时改掉所有变量。