在瀏覽器裡修復損壞的影片 —— 檔案不上傳

這一頁到底在檢查什麼

選一個影片,這一頁會把整條位元流走一遍,找出畫面資料壞掉的影格,並在時間軸上標出它們的位置。修復會匯出一個只含能正常解碼的影格的新檔案,播放時不會卡在損壞處。全程在你的裝置上完成,不上傳。

在 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 之類的編碼用別的方式排布影格,拿這把尺去量會全部顯示為損壞,所以這一頁選擇拒絕。

常見問題