先看清视频坏在哪,再修

这一页到底在检查什么

在 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 之类的编码用别的方式排布帧,拿这把尺子量会全部显示为损坏,所以这一页选择拒绝。

常见问题