先看清影片壞在哪,再修

這一頁到底在檢查什麼

在 MP4 或 MOV 裡,每個 H.264 / HEVC 影格是這樣存的:一個長度數字,緊接著那麼多位元組的畫面資料,然後是下一個長度,依此類推,首尾相接直到這個影格的資料用完。這條鏈必須嚴絲合縫地落在末尾。如果某個長度是 0,或者指到資料結束之後,那這個影格的位元組就不是檔案聲稱的那些東西。

這一頁從頭到尾逐格量的,就是這一件事。這也是它能告訴你損壞**在哪**、而不只是「影片播不了」的原因:每個壞影格都有位置和時間戳記,所以損壞可以畫在時間軸上。

如果你曾經把一個壞影片餵給 ffmpeg、看見 `Invalid NAL unit size (0 > 1241)` 一行行滾過,那報的就是同一件事。播放器碰上它通常是卡住、跳過,或者糊成一片色塊 —— 因為對著不存在的位元組,它們也只能做到這些。

這項檢查不需要視訊解碼器,所以它對你的瀏覽器根本播不了的檔案同樣有效。它讀的是位元組,不是畫面。

兩種「壞」,長得完全不一樣

**畫面資料被寫壞的影格。** 有什麼東西寫錯了位元組 —— 複製到 USB 隨身碟時中斷、記憶卡開始出問題、同步跑到一半掛掉。檔案的長度和索引都完好,影片也能正常打開,但裡面某些影格已經不可用。在時間軸上,它們是散落在損壞發生處的標記。

**被截斷的影片。** 下載或傳輸提前停了。檔頭仍然聲稱原來的長度,所以播放器顯示的是完整長度的進度條,但畫面資料到中途就沒了。這一頁靠「檔案聲稱的長度」與「實際能讀到的最後一個影格」之差把它認出來 —— 在時間軸上是末尾一整塊灰色。

把兩者分開說是有必要的,因為它們對應的預期完全不同。散落的損壞往往只讓你這裡少一秒、那裡少一秒。而一個在 40% 處被截斷的檔案缺的是整整 60% 的影片,任何工具都造不出從未被寫下來的東西。

為什麼修完會變短

影格不是各自獨立的。關鍵影格能單獨成立,但它後面的影格是以「與它的差異」的形式存著的 —— 所以一旦關鍵影格的資料壞了,所有依賴它的影格同樣不可用,哪怕這些影格自己的位元組完全沒問題。這就是為什麼一個只有十個壞影格的檔案,可能丟掉遠多於十格。

修復只保留真正能解出來的影格,並把空洞合上,讓產物能一口氣播完、而不是在損壞處凍住。代價是產物比原片短,短多少取決於丟了多少。這個數字在你決定之前就會顯示,產物頁上還會再說一次。

不重新編碼。留下來的影格是逐位元組複製的,所以剩下這部分的畫質就是原畫質 —— 而整件事在幾秒內完成,不是幾分鐘。

**聲音會保留,而且保持同步。** 合上空洞意味著畫面不再對得上原始長度的聲音,所以音軌會沿著完全相同的邊界裁開 —— 每一段保留下來的畫面都帶著它自己那一段聲音,平移量也一樣。段內兩者是鎖死的;只有段與段的接縫處音訊可能有偏差,而且不會超過半個音訊封包、約十毫秒。這比任何人能察覺到的嘴型不同步小一個數量級。

這一頁做不到的事

**根本打不開的檔案不在射程內。** 每個 MP4 都帶一份索引,說明每個影格在什麼位置。如果這份索引壞了或者不見了 —— 錄影沒有正常收尾時很常見 —— 就沒有可以走的地圖,這一頁會直接說清楚,而不是轉著圈假裝在忙。要救這種檔案,得靠原始來源,或者靠一個能透過猜測影格邊界來重建索引的工具。

**音軌的損壞檢查不出來。** 聲音會被帶過去並保持同步,但它從來沒有被**檢查**過 —— 要找出一個壞掉的音訊封包,得把它送進解碼器,那是和讀長度前綴完全不同、也慢得多的活。一個畫面完好、聲音壞掉的影片,在這項掃描裡會顯示為「完整」。

**只支援 H.264 與 HEVC。** 只有這兩種編碼是用長度前綴存影格的,而那正是這項檢查讀的東西。MJPEG、MPEG-4 Part 2 之類的編碼用別的方式排布影格,拿這把尺去量會全部顯示為損壞,所以這一頁選擇拒絕。

常見問題