截斷的 MP4 視頻：完整新手指南)
如何用 Untrunc 免費快速修復(fù)截斷的 MP4 視頻完整新手指南【免費下載鏈接】untruncRestore a damaged (truncated) mp4, m4v, mov, 3gp video. Provided you have a similar not broken video.項目地址: https://gitcode.com/gh_mirrors/unt/untruncUntrunc 是一個免費開源的命令行工具用于 MP4 視頻修復(fù)——基于一個完好樣本恢復(fù)被截斷的 MP4/M4V/MOV/3GP 視頻。當(dāng)視頻的索引結(jié)構(gòu)丟失、但數(shù)據(jù)流仍在時它能重建出可播放的文件。適合會用命令行、且能拿到同設(shè)備樣本的用戶。先確認你的文件是否適合做 MP4 視頻修復(fù) 運行修復(fù)前先做三個判斷可以避免無效操作。適合的場景文件在寫入過程中被中斷斷電、存儲卡拔出、傳輸中斷、錄制軟件崩潰文件是 MP4 家族的容器格式mp4、m4v、mov、3gpm4a 音頻同理文件頭或索引結(jié)構(gòu)損壞但數(shù)據(jù)主體大部分還在你能提供一個來自同一相機或同一 App的完好視頻作為樣本不適合的場景文件完全為空或數(shù)據(jù)流本身大面積損壞——Untrunc 重建的是容器結(jié)構(gòu)不恢復(fù)丟失的媒體數(shù)據(jù)找不到同設(shè)備、同編碼配置的樣本視頻。README 的說明很直接沒有同款樣本時修復(fù)機會很小文件來源不明無法確認它與樣本的編碼參數(shù)接近運行前必須確認原始損壞文件已備份后續(xù)所有操作都在副本上進行樣本視頻本身可正常播放你有一個可以執(zhí)行命令行的環(huán)境Linux、macOS或 Windows 下的 Docker/WSL快速運行 Untrunc 的最小上手路徑Docker 與源碼編譯兩種安裝方式任選其一。Docker 方式不需要配置任何依賴推薦優(yōu)先嘗試。方式一Docker依賴最少git clone --recurse-submodules https://gitcode.com/gh_mirrors/unt/untrunc cd untrunc docker build -t untrunc .如果構(gòu)建時出現(xiàn) Temporary failure resolving 的網(wǎng)絡(luò)錯誤可在構(gòu)建命令后追加--networkhost。方式二從源碼編譯按README.md中的 Installing from git 章節(jié)操作核心步驟是三步git clone --recurse-submodules克隆倉庫--recurse-submodules不可省略libav目錄是編譯依賴進入libav目錄執(zhí)行./configure make構(gòu)建 Libav回到倉庫根目錄用g一次性編譯main.cpp mp4.cpp atom.cpp track.cpp file.cpp log.cpp codec.cpp codec_*.cpp codecstats.cpp等源文件鏈接libavformat、libavcodec、libavresample、libavutil不同系統(tǒng)可能遇到鏈接報錯如BZ2_bzDecompressInit、lzma_stream_decoder未定義README.md列出了對應(yīng)的額外鏈接參數(shù)-lbz2、-llzma、-lX11、-lvdpau、-ldl按報錯逐條添加即可。macOS 還需追加-framework參數(shù)見 README。如何正確使用修復(fù)命令完整流程、參數(shù)與結(jié)果判斷 拿到可執(zhí)行文件后修復(fù)的主流程只有一條命令參數(shù)順序不能顛倒先寫完好樣本再寫損壞文件。./untrunc /path/to/working-video.mp4 /path/to/broken-video.mp4在 Docker 中運行時把視頻目錄掛載進容器的/filesdocker run -v /path/to/videos/:/files untrunc /files/working_video /files/broken_video結(jié)果如何判斷成功當(dāng)前目錄生成損壞文件名_fixed.mp4例如broken-video_fixed.mp4日志中無 Failed recovering the file 錯誤。用播放器實際播放確認畫面、聲音、時長失敗日志出現(xiàn) Failed recovering the file。程序默認先按 FIRST 策略定位mdat起點失敗后會自動依次嘗試 SAME、SEARCH、LAST 三種策略全部失敗才報錯常用參數(shù)完整用法見./untrunc無參數(shù)時的輸出參數(shù)作用何時用-o 文件名指定輸出文件名不想用默認_fixed.mp4后綴時-i打印樣本視頻的編碼器和 MOV 結(jié)構(gòu)信息修復(fù)前先確認樣本能被正確解析-a測試樣本視頻排查樣本問題-s用樣本模擬修復(fù)自身驗證工具鏈?zhǔn)欠裾２粍诱鎸嵨募?v/-w詳細日志 / 調(diào)試日志修復(fù)失敗后定位問題-q/-e靜默 / 只報錯誤批量處理或只要結(jié)論時-d嘗試修正音視頻漂移修復(fù)后出現(xiàn)音畫不同步-m/-M分別用相同偏移或搜索包起點定位 mdat默認策略失敗后手動指定-b 偏移量手動指定 mdat 起始字節(jié)已知數(shù)據(jù)起點時-B不跳過零字節(jié)PCM 音頻異常時嘗試-S 十六進制串在樣本文件中搜索字節(jié)串并輸出偏移輔助定位數(shù)據(jù)位置注意只傳一個樣本文件時Untrunc 只做分析配合-i、-a、-t等參數(shù)不會執(zhí)行修復(fù)。修復(fù)前的三項檢查清單輸入文件、參考樣本、備份驗證? 把這三項做完再運行主命令能覆蓋大部分本可避免的失敗。輸入文件要求確認損壞文件確實是 MP4 家族容器且文件大于 0 字節(jié)先運行./untrunc -i working-video.mp4確認樣本能正常輸出編碼器與結(jié)構(gòu)信息連-i都跑不通的樣本不要用用-s對樣本做一次模擬修復(fù)確認工具鏈本身工作正常參考樣本選擇優(yōu)先級排序同一設(shè)備 同一 App 同類配置 其他來源。設(shè)備不一致時成功率明顯下降分辨率、幀率、碼率盡量與損壞文件一致樣本不需要長幾秒到幾十秒即可準(zhǔn)備 2 個以上不同時間點的樣本備用備份與驗證修復(fù)輸出是新文件不覆蓋輸入替換或刪除原始文件前必須先用播放器完整驗證輸出對重要素材驗證時重點檢查開頭、結(jié)尾和隨機中間位置失敗排查按現(xiàn)象定位問題 每個現(xiàn)象對應(yīng)一個直接可執(zhí)行的動作按日志輸出對號入座?，F(xiàn)象可執(zhí)行動作日志出現(xiàn) Failed recovering the file重跑并追加-v -w保留完整日志再依次嘗試-m、-M改變 mdat 定位策略報錯無法打開文件檢查路徑拼寫、文件權(quán)限確認兩個文件都存在且可讀修復(fù)成功但播放跳幀、花屏用-i分別查看樣本和損壞文件的編碼信息換成編碼參數(shù)更接近的樣本重跑修復(fù)后音畫不同步加-d參數(shù)重跑讓程序嘗試修正漂移輸出沒有音軌或 PCM 音頻異常加-B參數(shù)不跳過零字節(jié)重跑輸出只有開頭一小段mdat 起點定位偏差嘗試-M搜索包起點或用-S定位后配合-b手動指定Docker 構(gòu)建時域名解析失敗構(gòu)建時追加--networkhost仍不行則確認宿主機網(wǎng)絡(luò)原理速覽一個完好視頻為什么能借給損壞視頻判斷能不能用只需要理解這一點MP4 文件由一個個原子atom拼接而成。ftyp聲明文件格式moov索引與元數(shù)據(jù)——每個樣本的時長、位置、編碼參數(shù)都在這里mdat真正的音視頻數(shù)據(jù)流視頻被截斷時最常見的損傷是moov丟失或損壞索引沒了而mdat里的數(shù)據(jù)往往完好。播放器沒有索引就無法播放所以文件看起來壞了。Untrunc 做的事情是解析完好樣本的moov結(jié)構(gòu)把它映射到損壞文件的mdat數(shù)據(jù)流上重新生成一份索引寫出新文件。它不改動視頻內(nèi)容本身——這正是樣本必須來自同設(shè)備、同編碼配置的原因借來的是結(jié)構(gòu)模板模板和內(nèi)容對不上修復(fù)就失敗。項目入口文檔、源碼與輔助工具只列你下一步會用得到的位置均在倉庫內(nèi)無外部依賴。README.md安裝git/Docker/zip/CentOS/Arch與使用說明編譯報錯對照表DockerfileDocker 鏡像的構(gòu)建定義含依賴清單moovfirst/README.txt輔助工具 moovfirst 的說明——把moov原子移到文件開頭讓視頻適合流式播放它無第三方依賴g -o moovfirst main.cpp file.cpp atom.cpp log.cpp即可編譯COPYINGGPL 許可全文核心源碼mp4.cpp容器解析與修復(fù)流程、atom.cpp原子解析、track.cpp軌道處理、codec_*.cpp各編解碼器處理libav/Libav 依賴git 子模塊源碼編譯時由它提供頭文件與靜態(tài)庫下一步行動與風(fēng)險提示建議的執(zhí)行順序備份原始損壞文件所有操作在副本上進行用./untrunc -i 樣本.mp4驗證樣本可解析必要時-s模擬自檢對副本執(zhí)行./untrunc 樣本.mp4 損壞副本.mp4完整播放驗證輸出文件確認后再處理原始文件失敗時保留-v -w日志對照上一節(jié)表格逐一嘗試適用邊界修復(fù)依賴同款樣本沒有同設(shè)備樣本時成功率很低Untrunc 重建容器結(jié)構(gòu)mdat數(shù)據(jù)流本身損壞的部分無法恢復(fù)它不承諾對任何文件有效輸出文件務(wù)必驗證后再決定取舍原始文件在驗證完成前不要刪除備份是你唯一的安全底線【免費下載鏈接】untruncRestore a damaged (truncated) mp4, m4v, mov, 3gp video. Provided you have a similar not broken video.項目地址: https://gitcode.com/gh_mirrors/unt/untrunc創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 如何用 Untrunc 免費快速修復(fù)截斷的 MP4 視頻：完整新手指南
如何用 Untrunc 免費快速修復(fù)截斷的 MP4 視頻完整新手指南【免費下載鏈接】untruncRestore a damaged (truncated) mp4, m4v, mov, 3gp video. Provided you have a similar not broken video.項目地址: https://gitcode.com/gh_mirrors/unt/untruncUntrunc 是一個免費開源的命令行工具用于 MP4 視頻修復(fù)——基于一個完好樣本恢復(fù)被截斷的 MP4/M4V/MOV/3GP 視頻。當(dāng)視頻的索引結(jié)構(gòu)丟失、但數(shù)據(jù)流仍在時它能重建出可播放的文件。適合會用命令行、且能拿到同設(shè)備樣本的用戶。先確認你的文件是否適合做 MP4 視頻修復(fù) 運行修復(fù)前先做三個判斷可以避免無效操作。適合的場景文件在寫入過程中被中斷斷電、存儲卡拔出、傳輸中斷、錄制軟件崩潰文件是 MP4 家族的容器格式mp4、m4v、mov、3gpm4a 音頻同理文件頭或索引結(jié)構(gòu)損壞但數(shù)據(jù)主體大部分還在你能提供一個來自同一相機或同一 App的完好視頻作為樣本不適合的場景文件完全為空或數(shù)據(jù)流本身大面積損壞——Untrunc 重建的是容器結(jié)構(gòu)不恢復(fù)丟失的媒體數(shù)據(jù)找不到同設(shè)備、同編碼配置的樣本視頻。README 的說明很直接沒有同款樣本時修復(fù)機會很小文件來源不明無法確認它與樣本的編碼參數(shù)接近運行前必須確認原始損壞文件已備份后續(xù)所有操作都在副本上進行樣本視頻本身可正常播放你有一個可以執(zhí)行命令行的環(huán)境Linux、macOS或 Windows 下的 Docker/WSL快速運行 Untrunc 的最小上手路徑Docker 與源碼編譯兩種安裝方式任選其一。Docker 方式不需要配置任何依賴推薦優(yōu)先嘗試。方式一Docker依賴最少git clone --recurse-submodules https://gitcode.com/gh_mirrors/unt/untrunc cd untrunc docker build -t untrunc .如果構(gòu)建時出現(xiàn) Temporary failure resolving 的網(wǎng)絡(luò)錯誤可在構(gòu)建命令后追加--networkhost。方式二從源碼編譯按README.md中的 Installing from git 章節(jié)操作核心步驟是三步git clone --recurse-submodules克隆倉庫--recurse-submodules不可省略libav目錄是編譯依賴進入libav目錄執(zhí)行./configure make構(gòu)建 Libav回到倉庫根目錄用g一次性編譯main.cpp mp4.cpp atom.cpp track.cpp file.cpp log.cpp codec.cpp codec_*.cpp codecstats.cpp等源文件鏈接libavformat、libavcodec、libavresample、libavutil不同系統(tǒng)可能遇到鏈接報錯如BZ2_bzDecompressInit、lzma_stream_decoder未定義README.md列出了對應(yīng)的額外鏈接參數(shù)-lbz2、-llzma、-lX11、-lvdpau、-ldl按報錯逐條添加即可。macOS 還需追加-framework參數(shù)見 README。如何正確使用修復(fù)命令完整流程、參數(shù)與結(jié)果判斷 拿到可執(zhí)行文件后修復(fù)的主流程只有一條命令參數(shù)順序不能顛倒先寫完好樣本再寫損壞文件。./untrunc /path/to/working-video.mp4 /path/to/broken-video.mp4在 Docker 中運行時把視頻目錄掛載進容器的/filesdocker run -v /path/to/videos/:/files untrunc /files/working_video /files/broken_video結(jié)果如何判斷成功當(dāng)前目錄生成損壞文件名_fixed.mp4例如broken-video_fixed.mp4日志中無 Failed recovering the file 錯誤。用播放器實際播放確認畫面、聲音、時長失敗日志出現(xiàn) Failed recovering the file。程序默認先按 FIRST 策略定位mdat起點失敗后會自動依次嘗試 SAME、SEARCH、LAST 三種策略全部失敗才報錯常用參數(shù)完整用法見./untrunc無參數(shù)時的輸出參數(shù)作用何時用-o 文件名指定輸出文件名不想用默認_fixed.mp4后綴時-i打印樣本視頻的編碼器和 MOV 結(jié)構(gòu)信息修復(fù)前先確認樣本能被正確解析-a測試樣本視頻排查樣本問題-s用樣本模擬修復(fù)自身驗證工具鏈?zhǔn)欠裾２粍诱鎸嵨募?v/-w詳細日志 / 調(diào)試日志修復(fù)失敗后定位問題-q/-e靜默 / 只報錯誤批量處理或只要結(jié)論時-d嘗試修正音視頻漂移修復(fù)后出現(xiàn)音畫不同步-m/-M分別用相同偏移或搜索包起點定位 mdat默認策略失敗后手動指定-b 偏移量手動指定 mdat 起始字節(jié)已知數(shù)據(jù)起點時-B不跳過零字節(jié)PCM 音頻異常時嘗試-S 十六進制串在樣本文件中搜索字節(jié)串并輸出偏移輔助定位數(shù)據(jù)位置注意只傳一個樣本文件時Untrunc 只做分析配合-i、-a、-t等參數(shù)不會執(zhí)行修復(fù)。修復(fù)前的三項檢查清單輸入文件、參考樣本、備份驗證? 把這三項做完再運行主命令能覆蓋大部分本可避免的失敗。輸入文件要求確認損壞文件確實是 MP4 家族容器且文件大于 0 字節(jié)先運行./untrunc -i working-video.mp4確認樣本能正常輸出編碼器與結(jié)構(gòu)信息連-i都跑不通的樣本不要用用-s對樣本做一次模擬修復(fù)確認工具鏈本身工作正常參考樣本選擇優(yōu)先級排序同一設(shè)備 同一 App 同類配置 其他來源。設(shè)備不一致時成功率明顯下降分辨率、幀率、碼率盡量與損壞文件一致樣本不需要長幾秒到幾十秒即可準(zhǔn)備 2 個以上不同時間點的樣本備用備份與驗證修復(fù)輸出是新文件不覆蓋輸入替換或刪除原始文件前必須先用播放器完整驗證輸出對重要素材驗證時重點檢查開頭、結(jié)尾和隨機中間位置失敗排查按現(xiàn)象定位問題 每個現(xiàn)象對應(yīng)一個直接可執(zhí)行的動作按日志輸出對號入座?，F(xiàn)象可執(zhí)行動作日志出現(xiàn) Failed recovering the file重跑并追加-v -w保留完整日志再依次嘗試-m、-M改變 mdat 定位策略報錯無法打開文件檢查路徑拼寫、文件權(quán)限確認兩個文件都存在且可讀修復(fù)成功但播放跳幀、花屏用-i分別查看樣本和損壞文件的編碼信息換成編碼參數(shù)更接近的樣本重跑修復(fù)后音畫不同步加-d參數(shù)重跑讓程序嘗試修正漂移輸出沒有音軌或 PCM 音頻異常加-B參數(shù)不跳過零字節(jié)重跑輸出只有開頭一小段mdat 起點定位偏差嘗試-M搜索包起點或用-S定位后配合-b手動指定Docker 構(gòu)建時域名解析失敗構(gòu)建時追加--networkhost仍不行則確認宿主機網(wǎng)絡(luò)原理速覽一個完好視頻為什么能借給損壞視頻判斷能不能用只需要理解這一點MP4 文件由一個個原子atom拼接而成。ftyp聲明文件格式moov索引與元數(shù)據(jù)——每個樣本的時長、位置、編碼參數(shù)都在這里mdat真正的音視頻數(shù)據(jù)流視頻被截斷時最常見的損傷是moov丟失或損壞索引沒了而mdat里的數(shù)據(jù)往往完好。播放器沒有索引就無法播放所以文件看起來壞了。Untrunc 做的事情是解析完好樣本的moov結(jié)構(gòu)把它映射到損壞文件的mdat數(shù)據(jù)流上重新生成一份索引寫出新文件。它不改動視頻內(nèi)容本身——這正是樣本必須來自同設(shè)備、同編碼配置的原因借來的是結(jié)構(gòu)模板模板和內(nèi)容對不上修復(fù)就失敗。項目入口文檔、源碼與輔助工具只列你下一步會用得到的位置均在倉庫內(nèi)無外部依賴。README.md安裝git/Docker/zip/CentOS/Arch與使用說明編譯報錯對照表DockerfileDocker 鏡像的構(gòu)建定義含依賴清單moovfirst/README.txt輔助工具 moovfirst 的說明——把moov原子移到文件開頭讓視頻適合流式播放它無第三方依賴g -o moovfirst main.cpp file.cpp atom.cpp log.cpp即可編譯COPYINGGPL 許可全文核心源碼mp4.cpp容器解析與修復(fù)流程、atom.cpp原子解析、track.cpp軌道處理、codec_*.cpp各編解碼器處理libav/Libav 依賴git 子模塊源碼編譯時由它提供頭文件與靜態(tài)庫下一步行動與風(fēng)險提示建議的執(zhí)行順序備份原始損壞文件所有操作在副本上進行用./untrunc -i 樣本.mp4驗證樣本可解析必要時-s模擬自檢對副本執(zhí)行./untrunc 樣本.mp4 損壞副本.mp4完整播放驗證輸出文件確認后再處理原始文件失敗時保留-v -w日志對照上一節(jié)表格逐一嘗試適用邊界修復(fù)依賴同款樣本沒有同設(shè)備樣本時成功率很低Untrunc 重建容器結(jié)構(gòu)mdat數(shù)據(jù)流本身損壞的部分無法恢復(fù)它不承諾對任何文件有效輸出文件務(wù)必驗證后再決定取舍原始文件在驗證完成前不要刪除備份是你唯一的安全底線【免費下載鏈接】untruncRestore a damaged (truncated) mp4, m4v, mov, 3gp video. Provided you have a similar not broken video.項目地址: https://gitcode.com/gh_mirrors/unt/untrunc創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考