在浏览器里修复损坏的视频 —— 文件不上传

这一页到底在检查什么

选一个视频,这一页会把整条码流走一遍,找出画面数据坏掉的帧,并在时间轴上标出它们的位置。修复会导出一个只含能正常解码的帧的新文件,播放时不会卡在损坏处。全程在你的设备上完成,不上传。

在 MP4 或 MOV 里,每个 H.264 / HEVC 帧是这样存的:一个长度数字,紧跟着那么多字节的画面数据,然后是下一个长度,依此类推,首尾相接直到这一帧的数据用完。这条链必须严丝合缝地落在末尾。如果某个长度是 0,或者指到数据结束之后,那这一帧的字节就不是文件声称的那些东西。

检查长度结构后，工具还会按关键帧分组实际解码。解码失败的帧组会被移除，检查从下一个关键帧继续；由于错误可能延迟返回，时间轴标记的是受影响的帧组，不一定能精确到某一帧。

如果你曾经把一个坏视频喂给 ffmpeg、看见 `Invalid NAL unit size (0 > 1241)` 一行行滚过,那报的就是同一件事。播放器碰上它通常是卡住、跳过,或者糊成一片色块 —— 因为对着不存在的字节,它们也只能做到这些。

验证需要浏览器支持该视频的解码。无法解码此视频的浏览器，也无法验证修复副本。

两种「坏」,长得完全不一样

**画面数据被写坏的帧。** 有什么东西写错了字节 —— 拷到 U 盘时中断、存储卡开始出问题、同步跑到一半死掉。文件的长度和索引都完好,视频也能正常打开,但里面某些帧已经不可用。在时间轴上,它们是散落在损坏发生处的标记。

**被截断的视频。** 下载或传输提前停了。文件头仍然声称原来的时长,所以播放器显示的是完整长度的进度条,但画面数据到中途就没了。这一页靠「文件声称的时长」与「实际能读到的最后一帧」之差把它认出来 —— 在时间轴上是末尾一整块灰色。

把两者分开说是有必要的,因为它们对应的预期完全不同。散落的损坏往往只让你这里少一秒、那里少一秒。而一个在 40% 处被截断的文件缺的是整整 60% 的视频,任何工具都造不出从未被写下来的东西。

为什么修完会变短

视频帧不是各自独立的。关键帧能单独成立,但它后面的帧是以「与它的差异」的形式存着的 —— 所以一旦关键帧的数据坏了,所有依赖它的帧同样不可用,哪怕这些帧自己的字节完全没问题。这就是为什么一个只有十个坏帧的文件,可能丢掉远多于十帧。

修复只保留真正能解出来的帧,并把空洞合上,让产物能一口气播完、而不是在损坏处冻住。代价是产物比原片短,短多少取决于丢了多少。这个数字在你决定之前就会显示,产物页上还会再说一次。

默认模式会原样拷贝保留下来的画面，不重新编码。完整解码检查需要时间；选择尽量保留模式时，还会重新编码保留的视频。

**声音会保留,而且保持同步。** 合上空洞意味着画面不再对得上原始长度的声音,所以音轨会沿着完全相同的边界裁开 —— 每一段保留下来的画面都带着它自己那一段声音,平移量也一样。段内两者是锁死的;只有段与段的接缝处音频可能有偏差,而且不会超过半个音频包、约十毫秒。这比任何人能察觉到的口型不同步小一个数量级。

这一页做不到的事

**压根打不开的文件不在射程内。** 每个 MP4 都带一份索引,说明每一帧在什么位置。如果这份索引坏了或者丢了 —— 录制没有正常收尾时很常见 —— 就没有可以走的地图,这一页会直接说清楚,而不是转着圈假装在忙。要救这种文件,得靠原始来源,或者靠一个能通过猜测帧边界来重建索引的工具。

**音轨不做损坏检查。** 已有音频包会按照保留的视频片段裁剪并拷贝。损坏或此前已经丢失的声音无法通过这一步恢复。

**只支持 H.264 与 HEVC。** 只有这两种编码是用长度前缀存帧的,而那正是这项检查读的东西。MJPEG、MPEG-4 Part 2 之类的编码用别的方式排布帧,拿这把尺子量会全部显示为损坏,所以这一页选择拒绝。

常见问题