视频已经读出了宽高和时长拿它画封面却得到一张空图。这次我测了不同加载阶段的绘制结果才把这个看着矛盾的现象拆开。样本是同一段冰岛海浪素材转出的两种格式规格相同6秒长、宽640px、高360px。尺寸能读出来。绘制也没报错。可在元信息刚就绪时得到的画布里没有一处海浪像素全图透明度都是零。接下来要弄清的是这一步究竟已经拿到了什么。浏览器读到的宽高和时长能回答视频多大、持续多久却不能证明当前画面已经可供绘制。页面据此摆好播放器后也只是把显示区域摆对了。空画布可以有正确尺寸。“宽高不为零”这种检查拿到了布局所需的信息却漏掉了后面真正要画的内容。产品侧核对我用的是图映 ImgIng导入上述海浪MP4后界面读到310KB和无音轨。视频工作台仍属面向桌面Chrome和Edge的Beta功能。我这里只核对了导入、定位和当前帧预览没有导出整片。播放器显示的素材元信息和海浪画面提供了一个直观参照。下面的加载阶段对照来自单独的浏览器实验不能反推成图映内部的实现方式。这张图看的是导入后的信息区与播放器里面的尺寸和时长可以帮助确认拿到哪份文件。另一张尚待绘制的画布有没有像素还得单独查。产品的“预览当前帧抠像效果”也有自己的结果含义本轮无人海浪显示“当前帧没有识别到明显主体”。这不等于截帧失败。预览区的颜色不能直接算进空封面的故障次数。我用海浪的MP4和WebM对照了不同加载阶段每种格式在每个内核各重复10次。测试环境是Chromium 149开源构建、Firefox 151和WebKit 26.5不是Safari正式版。三组都通过本机HTTP服务读取文件没有弱网条件。元信息事件loadedmetadata触发时的60次绘制全是透明空图对应状态读数为1。没有异常抛出。这个结果让我把“调用成功”和“拿到画面”分开记只盯着日志有没有报错就会把空图放过去。接着把绘制位置放到当前播放位置的数据就绪事件loadeddata。同样的样本和重复次数下60次都得到有非黑且不透明像素的海浪图。对照只改变绘制时机没有换一段更好截的视频。元信息交代完素材规格后画封面仍得检查当前画面数据能不能提供可画的内容。前一步有用途。只是它做完的工作不能替后一步交差。导入界面的尺寸可以先显示出来生成初始封面还得等对应画面数据。图里是本次自建的截帧复现页。两块画布采用首批实验实际保存的PNG左边没有海浪像素右边已有内容它们不是图映的两个处理模式。素材来自 Alexander Grebenkov 的冰岛海浪影片按 CC BY 3.0 使用测试时截短、缩放并转码。有一处我不想把结论写得太满不能顺手把某个状态数字当成所有路径下的充分证明。本轮另一个新帧回调对照里碰到的例外就发生在Chromium的WebM上有一次已经能画出像素读到的状态却仍是1。这个单次时序不足以解释所有浏览器行为倒是提醒我别把实验里常见的事件顺序写成固定时间表。本篇先处理初始加载时的空图。拖动到指定时刻能否截准还需要另一套判断。再看输出时我会先确认透明度。全图alpha为0的画布贴在黑底上也会看成黑屏即使实际没有一层不透明的黑色画面。源视频本身就是黑开场时等到数据就绪也不会把内容变成海浪。本轮加过黑开场的对照保留了这个区别。等数据解决的是有无可画内容无法替素材选择好看的封面。这两个问题一起修就容易把等待条件越堆越长。我给这轮实验留下的检查顺序很简单先记下尺寸和时长来确认视频规格再核对绘制挂在哪个加载阶段。接着读取输出的透明度并看实际画面。尺寸正确但整张透明时我会先把元信息回调里的截帧挪到当前画面数据就绪之后做对照。等海浪真的出现后再讨论这张图适不适合当封面。手机、省流模式和损坏文件这些尚未测过的条件暂时不在这套本机短视频结论覆盖的范围内。素材来源Ocean waves at Lækjavik beach, IcelandAlexander GrebenkovCC BY 3.0。