视频文件打不开？untrunc 让损坏的 MP4 无损复活，真实修复全过程

视频文件打不开？untrunc 让损坏的 MP4 无损复活，真实修复全过程

【免费下载链接】untruncRestore a truncated mp4/mov. Improved version of ponchio/untrunc项目地址: https://gitcode.com/gh_mirrors/un/untrunc

深夜十一点，你把相机的存储卡插进电脑，准备导出白天给女儿拍的生日视频。双击文件，播放器弹出一个刺眼的提示框："无法播放此文件"。你慌了，又试了三个播放器，全都不行。文件还在，大小也有 1.2GB，可它就是打不开——那段只属于你家的画面，好像就这么没了。

先别急着格式化存储卡。untrunc正是为这个瞬间而生的免费开源工具：它不重新编码画面，只重建文件结构，把"打不开"的视频原样救回来。画质一帧不损，速度还快得离谱。这篇文章带你从头走一遍完整的修复过程，包括它为什么会坏、坏在哪里、以及遇到卡壳时怎么应急。

视频文件为什么说坏就坏：一本被撕掉目录的书

MP4、MOV、M4V 这类格式，本质上是一本结构精巧的"书"。

"正文"叫 mdat，里面密密麻麻地装着真正的画面帧和声音采样——这是这本书的血肉，占了文件体积的 99%。

"目录"叫 moov，记录了每一帧数据的确切位置、时长、分辨率、编码参数——这是书的骨架和目录页。

关键点在于：大多数相机为了边拍边写，会把 moov（目录）放在文件末尾。于是当你正在录制时突然断电、存储卡出坏道、或者拔卡拔早了，文件就会在某个位置被"拦腰截断"。目录页没了，正文却完整地躺在那里——就像一本书被撕掉了目录和索引，纸张全在，但你翻不到任何一页。

普通播放器只认目录，找不到就直接罢工。而 untrunc 的思路完全不同：它从另一本"好书的目录"里，借来结构模板，再去坏书的正文里逐帧核对，最后给你重印一本完整的新书。正文一个字节都不动，所以画质是 100% 无损的。

动手：找一个"模板"，跑一条命令

修复的前提只有一个：手里得有一支同一台设备拍出的健康视频。同一台相机、同样的分辨率和编码设置、时间别隔太久，成功率就高。原因是它要拿这支好视频的 moov 当"目录模板"，模板和你坏视频的结构越接近，匹配越精准。

先把工具装好。Ubuntu 上三步搞定：

sudo apt-get install libavformat-dev libavcodec-dev libavutil-dev git clone https://gitcode.com/gh_mirrors/un/untrunc cd untrunc && make sudo cp untrunc /usr/local/bin

装好后，把好视频和坏视频放进同一个文件夹，执行：

untrunc healthy.MP4 broken.MP4

这句大白话就是：把 healthy 的结构模板套到 broken 的数据上，重新组装。程序会先解析好视频的 moov，再去坏视频里找到 mdat 正文，然后一帧一帧地匹配 H.264 画面和 AAC 音频。

几秒钟到几十秒后（这个分支号称比原版快 10 倍以上），当前目录会多出一个文件，名字是坏视频加了个_fixed后缀：

broken_fixed.MP4

双击它——能播了。那一刻你会觉得之前的心急火燎都是值得的。

卡住了？这三次"意外"我都替你踩过

不是每次都这么顺利，否则这篇文早该结束了。说说我实际撞上的三个坎。

第一道坎：程序中途抱怨unable to find correct codec -> premature end，然后停住，进度条大概停在 60%。

意思是：它在这儿认不出接下来这段数据属于哪个轨道，默认"到此为止"了。这不代表后面的内容坏了，只是它太谨慎。加上-s让它跳过未知字节、继续往后扫：

untrunc -s healthy.MP4 broken.MP4

配上-v能看到更详细的过程日志，方便判断它到底卡在哪一段：

untrunc -v -s healthy.MP4 broken.MP4

第二道坎：修复成功了，但声音和画面对不上。

这通常是时间戳坏得太彻底。untrunc 专门提供了一个 beta 参数-sv，意思是拉伸或压缩视频的时长去匹配音频，能救回不少音画错位的片子：

untrunc -sv healthy.MP4 broken.MP4

第三道坎：输出文件名不满意，或者你想把结果直接放到指定目录。

默认的_fixed后缀在某些批量场景下很碍事。用-dst指定输出位置或文件名：

untrunc -dst restored_folder/ broken.MP4 untrunc -dst full_recovery.MP4 healthy.MP4 broken.MP4

对了，还有两个几乎没人提但很实用的参数：

• -dw：只分析、不写文件。想先看看这视频有没有救、能修到多少百分比，又不想污染目录，用它。
• -it：列出两个视频各自包含哪些轨道（视频轨、音频轨、还有 GoPro 的 gpmd 数据轨等），修复前看一眼就能提前判断匹配度。

修不动的时候，把工具当成"体检仪"

如果加了-s还是大面积报错，先别怪运气。untrunc 有个很聪明的自我诊断玩法：拿好视频自己跟自己比。

untrunc healthy.MP4 healthy.MP4

同一支健康的视频，理应完美匹配。如果它连这个都报错，说明好视频本身的编码结构比较冷门，或者你用的 ffmpeg 版本不兼容（这个项目对 ffmpeg 的版本号很敏感，官方推荐 3.3.9 附近的稳定组合）。

再深一层，可以用-lsm找出文件里所有的 mdat 和 moov 的位置，确认坏视频的正文到底在哪一段、有没有被切掉一截：

untrunc -lsm broken.MP4

如果 moov 和 mdat 的位置都不对劲，还能用-sm强制在找不到结构时也去搜 mdat 正文，属于最后的倔强。而如果你是索尼相机的用户，拍摄中突然断电还会留下一种叫 RSV 的"录制中"残骸文件，untrunc 甚至为它专门做了-rsv-ben模式。

修复之后：它不只是一条命令

用顺手之后你会发现，untrunc 的生态比想象中完整。Windows 用户有现成的预编译版本和图形界面；想隔离依赖、避免"内存不足"的尴尬，官方 Dockerfile 一条命令就能起服务：

docker build -t untrunc . docker run --rm -v ~/Videos/:/mnt untrunc /mnt/ok.mp4 /mnt/broken.mp4

源码结构也足够清爽：src/mp4.cpp和src/atom.cpp负责 MP4 容器的解析与重建，src/avc1/处理 H.264/AVC，src/hvc1/处理 HEVC/H.265，src/common.cpp提供底层工具函数。真要较真，翻着源码就能把它吃透。

但说回最本质的东西——这个工具最动人的时刻，从来不是命令行里那行绿色的成功提示，而是你双击修复后的文件，看到画面动起来的那一瞬间。它不创造画面，它只是帮你把差点丢失的画面原样找回来。

所以，如果你此刻抽屉里就躺着一张"打不开"的存储卡，别删，别格式化。先找到那台设备，重新拍一小段健康视频，然后跑一遍上面的命令。大多数时候，奇迹就这么发生了。

平时记得常备份；但备份之外，知道有 untrunc 这样的免费后手在，心里总是踏实一些。

【免费下载链接】untruncRestore a truncated mp4/mov. Improved version of ponchio/untrunc项目地址: https://gitcode.com/gh_mirrors/un/untrunc