视频区域黑着时我现在会先检查播放器状态再考虑文件是不是坏了。这次一份海浪文件只是等索引到达几秒后就出了画面。另一份已经触发媒体错误。继续等也没有恢复。外观都像没播出来。处理方式却不能一样。我测了8秒冰岛海浪的两版普通MP4它们同为960×540、去掉音轨区别是索引在前或在后。两份媒体数据的哈希一致。画面内容没有因此再变一次。下面尾部索引的截图里播放器仍在读取并等待索引与首帧。这一刻不足以判定文件损坏。这份文件在Chromium中的两次首帧等待分别是5.773秒、5.792秒。服务端当时忽略Range没有按浏览器请求只返回某段字节。播放器需要等顺序读取到文件尾部的moov才能继续。moov可以理解成描述视频如何组织的一部分信息。数据正在传输。起播所需却还没齐。同一服务支持范围读取后尾部版两次首帧变成0.776秒、0.813秒。请求记录显示浏览器先取文件尾部再回到前方取数据。视频内容没有换。这个结果不支持“没画面就是视频坏了”的猜测接下来更该查所需字节有没有到达。索引在末尾也并不总要整段顺着下载完。第二张是索引在前且支持Range的版本截取时已显示第6秒画面。图里的首帧约0.51秒是那一次的记录。它和第一张的截取时点不同也同时改了索引位置与响应条件。不能用两图计算前置效果。两图只说明等待与已取得画面的状态比较等待要用前面的成对测试。我在同轮用 图映 ImgIng 中文工作台完成了完整海浪WebM的体积优先MP4导出。产品输出带分片结构单独保留了保存记录。这两图来自本地受控复现页面并非产品导出失败的截图。记录文件来源可以避免把不同实验的等待归到同一个工具上。知道索引会晚到以后也不能一概劝人耐心等。第二段Herzliya海浪在WebKit测试构建里就没有等来画面。普通MP4尾部索引、服务端忽略Range的两次测试分别在18.161秒、18.159秒触发媒体错误。观察到35秒都没见首帧。服务端后来写完全部5068844字节也不等于播放器恢复。这次还有个容易漏掉的细节媒体错误的文字说明是空的。只看报错文案就会误判成仍在加载。我按错误事件核对状态。35秒不代表“还需要再等这么久”。这次没有继续定位根因不能据此认定原视频损坏或正式版Safari一定失败。用的是WebKit26.5测试构建并非正式版Safari。这些数字来自2026年9月30日的本地HTTP实验。Chromium为149.0.7827.55测试构建。每个条件重复两次。服务端让所有活动视频响应共享每秒256 KiB写入额度各请求开始另等80毫秒。这没有完整模拟真实网络。首帧也按视频帧通知计时。这些时间仅是本轮观察不能照搬为网页统一的等待上限。冰岛素材为Alexander Grebenkov的Ocean waves at Lækjavik beach, Iceland采用CC BY 3.0许可。第二段来自דוד שי的Water waves in Herzliya beach采用CC BY-SA 4.0。普通对照片均做了8秒截取、缩放、静音转换与重封装配图为复现页面。素材并非我自摄。再遇到视频黑着时先检查媒体是否已报错错误信息为空也保留记录。没有错误时再核对请求是否仍在读取以及尾部信息能否按范围取回。确认状态以后才决定继续观察还是转入失败排查。我不会把未出画面直接写成损坏也不会把已出现的错误继续显示成加载。记录状态以后再决定下一步比笼统地“多等一会儿”更具体。