告别“文件已损坏“：用 untrunc 无损拯救截断视频的实战指南-开发者社区

告别"文件已损坏"：用 untrunc 无损拯救截断视频的实战指南

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

untrunc 是一款开源免费的 MP4/MOV 视频修复工具，专治断电、拔卡、传输中断导致的"截断"视频。它的核心价值是无损修复：不重新编码任何一帧画面，只把丢失的索引信息重建回来，修复后的画质与原始素材完全一致。接下来，我会带你从头到尾走通一次真实修复，并告诉你哪些坑是新手最容易踩的。

播放器弹出"文件已损坏"，其实画面还活着

手机拍了一段再也拍不回来的画面，播放器却冷冷地回你一句"文件已损坏，无法播放"。大部分人在这时选择删除，而他们删掉的，往往是文件里依然完好无损的那 95% 的视频数据。

这不是玄学，而是 MP4 文件的结构决定的。你可以把播放器理解成一个极其较真的图书管理员：它不认"内容"，只认"目录"。目录对不上，整本书就被判定为无法借阅。而 untrunc 要做的，就是帮你把这份目录补回来——画面本身，可能一帧都没丢。

你的视频属于哪种"坏法"？先分清截断与覆写

在动手之前，先搞清楚一件事：不是所有"坏视频"都有的救。

截断型损坏：文件写到一半被中断（突然断电、强行拔卡、传输断线），文件尾部残缺。这是 untrunc 的主场，项目名字里的 truncated 说的就是这种情况。
覆写型损坏：数据本身被破坏，比如磁盘坏道、病毒改写、被其他文件覆盖。这种情况下原始字节已经不存在了，任何工具都无力回天。

关键点在于：截断 ≠ 内容丢失。截断丢的是"尾巴"，而 MP4 的索引恰好常常住在尾巴上。所以很多人以为视频"没救了"，其实是索引没写完而已。

认识 untrunc：专为截断视频而生的开源工具

untrunc 的项目描述只有一句话：Restore a truncated mp4/mov——恢复截断的 MP4/MOV 文件。它是经典项目 ponchio/untrunc 的改进版，而这个 fork 带来的提升相当实在：

处理速度比原版快 10 倍以上，同时把内存占用压得很低；
支持超过 2GB 的大文件，4K 素材也能处理；
遇到无法识别的字节序列可以跳过，而不是直接放弃；
对 GoPro、索尼 XAVC 等特殊设备的视频做了专门支持。

从源码结构也能看出它的专注：src/avc1/ 处理 H.264/AVC 编码，src/hvc1/ 处理 HEVC/H.265 编码，src/mp4.cpp 和 src/atom.cpp 负责 MP4 容器的解析与重建。主流手机、相机、运动设备拍的视频，基本都在它的射程之内。

无损的秘密：它修复的不是画面，而是"目录"

为了讲清楚原理，我借用一个比喻：一本带索引的相册合订本。

这本相册的正文是几百张照片，最后一页是一张"索引表"，记录着每张照片在第几页、拍摄时用了什么参数。你作为一个普通人，直接翻照片就能看；但播放器不行，它必须先读索引表，才能知道"第一张照片在文件哪个位置、占多少字节、下一张从哪开始"。

现在假设这本相册的索引页被撕掉了（文件截断）。照片一页没少，但播放器读不到索引，只能报"文件损坏"。untrunc 干的事是：找一本同款的相册，复印它的索引表，装回到坏相册里。它绝不重新冲洗任何一张照片，所以画质 100% 保持原样，速度也快——因为重建索引远比重新编码一整个视频便宜。

具体到文件层面，"索引页"对应 MP4 里的 moov 元数据，"照片正文"对应 mdat 数据块。untrunc 从健康视频里提取轨道信息、帧大小、时间戳这些"索引模板"，再回到损坏视频的数据区里，逐个识别每一帧属于哪个轨道、应该有多长，最后用模板把索引重建出来，写成一个新文件。

为什么必须备一个"同款"参考视频？两个新手最常见的坑

看到这里你可能已经发现了：untrunc 需要一个"同款相册"来复印索引，也就是一个没坏的参考视频。这是它的使用前提，也是新手栽跟头最多的地方。

坑一：随便找一个视频当参考。参考视频和损坏视频如果来自不同设备、不同分辨率、不同编码参数，索引模板就对不上号，修复结果基本靠运气。官方文档说得非常直白：理想情况下，参考视频必须来自同一台设备，否则修复成功的希望很渺茫。

坑二：拿损坏文件自己当参考。有人觉得"反正都是同一台相机拍的"，就用损坏文件本身当参考。结果当然是无解——它自己的索引也丢了，拿什么复印？

所以挑选参考素材请遵循三条：同一台设备、相同的录制设置（分辨率、帧率、编码格式）、尽量相近的录制时间。你不需要刻意囤素材，平时随便拍的一段正常视频，只要满足这三条，就能在关键时刻派上用场。

完整实战：从装好工具到拿到修复文件

理论说够了，现在动手。这里以 Linux 为例，完整流程就三步。

先安装编译依赖并获取源码：

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

macOS 用户用 Homebrew 装好 ffmpeg 与 yasm 后同样执行 make；不想折腾依赖的话，项目自带的 Dockerfile 可以一键构建镜像，Windows 也有现成的 GUI 版本可以下载。

然后，把你准备好的健康视频和损坏视频放在同一个目录，执行修复：

untrunc good.mp4 broken.mp4

几秒到几十秒后，你会看到目录里多出一个broken_fixed.mp4——这就是修复产物。用任意播放器打开它，如果画面、声音、时长都正常，恭喜你，一次无损救援完成了。

一个小提醒：修复前先给损坏文件做个备份。untrunc 只读不写原文件，但多一份拷贝总是安心。

修复不顺时，用问答式自查

不是每次修复都一帆风顺。如果你遇到下面这些情况，先别急着放弃，按图索骥排查：

问：输出文件只有画面没有声音？答：音频轨道没被正确识别。多半是参考视频的音频编码与损坏视频不一致，换一个更"同款"的参考素材再试。

问：画面和声音对不上？答：时间戳信息损坏严重时，可以加上-sv参数，让视频自动伸缩来匹配音频时长。这个功能标着 beta，但值得一试。

问：提示找不到可用的结构？答：加上-sm参数强制搜索 mdat 数据块，即使文件外层结构已经面目全非，也还有一线希望。

问：想看看它到底在干什么？答：加-v或-vv进入详细日志模式，每个识别步骤都会打印出来。如果还是搞不定，把日志和两个文件一起保留，去社区求助时它们就是最有用的线索。

问：文件太大，跑起来吃力？答：这个 fork 本身就针对大文件和低内存做了优化，如果还嫌慢，可以先用-dw只做分析不写文件，确认可行后再正式修复。

不同人群，怎么用最省心

普通手机用户：最简单。备份损坏文件，找一段同手机拍的健康视频，一条命令搞定，全程不需要任何视频知识。
运动相机与航拍玩家：GoPro 和索尼 XAVC 格式是 untrunc 的重点支持对象，你的设备通常自带一堆正常素材可以当参考。
摄影工作室：批量修复场景下，用-dst指定输出目录，配合-skip跳过已处理的文件，就能把修复流程串成流水线。
索尼相机用户：如果遇到的是录制中途异常断电产生的 RSV 文件，加上-rsv-ben参数走专用恢复流程，这是普通工具没有的绝活。

进阶：它还有哪些隐藏技能？

除了修视频，untrunc 还有几个经常被忽略的用法。-a进入分析模式，能帮你摸清一个视频文件的轨道结构；-it直接打印所有轨道信息，排查问题时非常好用；-ms可以把视频转为流式布局，方便网页端边下边播；-u则能把手头分离的 mdat 数据块和 moov 索引重新拼合。这些命令的完整说明，在项目源码的 src/main.cpp 里都有注释，感兴趣的话值得翻一翻。

它甚至带了可选 GUI（untrunc-gui），嫌命令行麻烦的人也能用上图形界面。