录屏软件突然崩了、电脑断电、进程被强制结束，辛苦录了大半天的素材打不开，播放器提示“文件已损坏”或“无法渲染此文件”——这种经历，拍过视频、做过在线课程、搞过游戏解说的人大概率都撞上过。市面上号称能“万能修复”的工具不少，但真正在本地、免费、还能把截断的 MP4/MOV 救回来的，我最先想到的还是 untrunc。
untrunc 是 GitHub 上开源的视频修复工具，专治“录到一半被掐断”导致文件结构不完整的视频。它的思路和普通修复软件很不一样：不需要原来的完整视频，而是借一个“和损坏文件同源”的好视频，把损坏文件里缺失的索引信息重建出来。这个思路决定了它能救回很多其他工具搞不定的文件，但也决定了它有一定的使用前提。这篇文章就把 untrunc 到底是什么、原理怎么走、实际怎么用、坑在哪里一次讲清楚。
1. 录屏文件损坏的本质：索引丢了，不是画面没了
先说一个很多人会误解的点：录到一半断电，视频文件不是“整个坏了”，而是画面的数据其实大多还在，只是文件的“目录”没写完。
MP4、MOV 这类容器格式，内部结构大致分两块：一块叫 mdat，里面装的是真正压缩好的视频帧和音频帧数据；另一块叫 moov，相当于整份文件的目录索引，记录每一帧数据在这个文件里的偏移量、时长、编码参数、音视频轨道的对应关系。正常录制的流程是先把画面写进 mdat，等录制结束后再统一生成 moov，把索引追加到文件里。
问题就在这里：如果你在录制过程中进程崩溃、拔电源、或者录屏软件自己挂了，程序根本没机会执行“写入 moov”这一步。你拿到的是一个没有目录、只有正文的文件。播放器打开它，第一件事就是找 moov，找不到就立刻报错。很多修复软件说“修复失败”，不是它技术不行，而是它默认所有 MP4 文件都必须有完整的 moov，遇到缺失的情况直接放弃。
理解了这一点，你就明白了：修复的关键不是“找回画面数据”，而是“重建目录”。视频帧那些二进制数据只要没被覆盖，大概率还安安静静躺在文件里，只是没人知道它们各自的位置和顺序。
1.1 为什么播放器说“文件已损坏”，但文件大小却很正常
我见过很多用户反馈：损坏的视频文件大小看着挺正常的，比如录了一个小时，显示 1.2GB，但就是打不开。这其实是正常的，因为 mdat 数据体量大，占比接近 99%；moov 索引只有几十到几百 KB。文件大小主要由 mdat 决定，索引丢失对文件大小的影响几乎看不出来。因此，靠“文件大小是否合理”来判断视频还有没有救，是没什么意义的。
真正有用的判断方式，是用十六进制查看器或者 untrunc 自带的检测去扫描 mdat 内部，确认关键编码参数（比如 SPS/PPS 头）还在不在。如果这些关键参数也丢了，修复难度会大很多，但 untrunc 在某些场景下仍能靠参考文件补齐。
1.2 为什么普通修复软件救不了，而 untrunc 可以
常规修复工具的思路是“猜”：根据文件尾部残留的数据，尝试猜测 moov 的位置和参数，强行补一个目录。这招对轻微损坏（比如只是 moov 位置偏移、大小字段错误）有效，但录到一半被 kill 的场景，moov 压根不存在，猜的难度就很高，而且音视频轨道的精确时间戳很难猜准。
untrunc 走的是另一条路：找参考。你手里如果有一个“和损坏视频由同一台设备/同一个配置录制出来的正常视频”，它里面就包含了完整的 moov 结构。untrunc 解析这个好文件的 moov，获得编码格式、分辨率、帧率、音视频轨道参数，然后在损坏文件里扫描这些参数对应的帧数据，逐一重建新的索引。相当于你丢了房子的设计图，但邻居家的同户型房子还在，你照着邻居家的图纸把自家的房梁、水管、电路重新标好位置。
这个设计非常聪明，因为同一个设备同一个设置录出来的文件，结构高度一致——帧大小分布、编码器的 SPS/PPS、时间戳间隔都几乎一模一样。参考文件提供的不是“通用模板”，而是“和你这个视频高度匹配的专用模板”。
2. untrunc 的工作原理拆解：参考文件为何是万能钥匙
上面说了个大方向，这一节我们把 untrunc 工作的每个环节拆开看。只有明白了原理，你才能知道它什么时候能用、什么时候不能用、为什么有时候需要反复试不同参考文件。
2.1 第一步：解析参考文件的 moov
untrunc 先打开你提供的正常视频，把它的 moov atom 完整解析出来。它会读取这些关键信息：
- 视频轨道：编码格式（H.264、HEVC 等）、分辨率、帧率、颜色参数
- 音频轨道：编码格式（AAC、MP3 等）、采样率、声道数、码率
- 轨道间的交错关系：哪些 sample 属于视频、哪些属于音频，大概的排列规律
这些信息就是“重建图纸”的模板。
2.2 第二步：在损坏文件里扫描可用的帧数据
有了模板，untrunc 开始在损坏文件的 mdat 里从头到尾扫描，试图识别出每一个独立的视频帧和音频帧。它认得 H.264 的起始码（0x00000001）和 NAL 单元结构，也认得 AAC 的帧头部。每找到一个帧，它会记录这个帧在文件里的偏移量、大小、时间戳，把帧排列起来。
这一步是修复成败的核心。如果录制中断时文件尾部还有未写完的半帧数据，untrunc 会自动忽略掉不完整的帧，只保留完整的帧来重建索引。
2.3 第三步：重建 moov 并输出新文件
帧都扫描到并排列好之后，untrunc 根据参考文件中的参数，重新写一份新的 moov，把它和 mdat 数据合并，输出成一个新的、带完整索引的 MP4 文件。新文件可以直接用播放器打开，也可以导入剪辑软件继续编辑。
我在实际操作中的体会是：这套流程对“连续录制后强制中断”的文件成功率非常高。但如果是文件本身就写不全、帧数据大量损坏（比如硬盘坏道读不出来），那扫描阶段就会缺帧，修复后的视频会有卡顿、丢帧、音画不同步，运气不好直接失败。
2.4 为什么参考文件必须是“同源”的
这是 untrunc 最容易被误解、也最影响成败的点。参考文件不是随便拿一个 MP4 就行，它要求的是“同一个录制环境下生成的正常文件”。
原因是：不同相机、不同录屏软件、不同编码参数，生成的文件结构细节差异很大。比如 iPhone 拍的视频和安卓手机拍的视频，moov 结构、sample 排列规律完全不同；同一个软件，如果你改了分辨率和码率，生成的文件结构也不一样。用一个参数不匹配的参考文件去修，untrunc 扫描出来的帧可能格式对不上，重建出来的索引是错的，播放会花屏或者无法播放。
所以，日常使用 untrunc 的正确习惯应该是：每次开始大规模录制前，先录一个 3~5 秒的同配置测试片段，存好，别删。真出问题了，它就是最好的参考文件。别等到视频坏了才到处翻旧文件碰运气。
3. 安装与准备：十分钟把 untrunc 跑起来
untrunc 本身是个命令行工具，源码托管在 GitHub，而且需要编译。对不熟悉命令行的朋友来说，一上来就编译可能有点劝退。这里我把三个平台的实际做法都捋一遍，选一条适合你的。
3.1 Linux 下的编译安装
先装依赖。untrunc 依赖 libmp4v2，不同发行版包名略有区别，但 Debian/Ubuntu 系可以直接：
sudo apt install git build-essential libmp4v2-dev然后拉源码编译：
git clone https://github.com/ponchio/untrunc.git cd untrunc make编译产物就是一个untrunc可执行文件，直接在当前目录调用。
值得注意的是，Libav 系的工具链版本变化可能会影响编译，遇到报错的话，优先检查 libmp4v2-dev 是否装好，以及 make 输出的错误路径。新版系统上如果直接 make 失败，可以考虑用项目里的untrunc.c单独编译，但这就是折腾了，非必要不建议新手自己搞。
3.2 macOS 下的快捷方案
macOS 上最省事的是用 Homebrew：
brew install untrunc装好后直接有untrunc命令可用。如果你之前用过brew tap玩过一些第三方包，需要注意 untrunc 的 formula 在 core 仓库，不需要额外 tap。
3.3 Windows 下的几种路子
Windows 用户最常问的就是“有没有现成的 exe”。老实说，官方仓库没有维护现成的 Windows 二进制包，需要自己编译，或者去找第三方编译好的版本（搜“untrunc windows exe”能搜到一些热心网友的构建产物，但来源要自己把好关，毕竟这类小工具有人会在里面塞东西）。
我自己在 Windows 上更推荐两种方式：
第一种是装 WSL，在 Ubuntu 子系统里按 Linux 方式编译，再用命令行操作。步骤一次配好，后续就固定用。
第二种是找带 GUI 的第三方版本。GitHub 上有一些项目基于 untrunc 封装了图形界面，功能上就是帮你选参考文件、选损坏文件、点运行，逻辑不变。对不熟悉命令行的用户友好很多。不过 GUI 版本本质上还是调用核心算法，不会改变修复成败，所以别指望“图形化 = 成功率更高”，参考文件的匹配程度才是核心。
3.4 准备参考文件的几条具体路径
说回参考文件，这里有几条具体的获取路径，按优先级排：
- 如果录制软件支持“边录边生成索引”或者有“试录模式”，提前录一个几秒的片段，这是最优解。
- 如果损坏文件来自某台摄像机，找这台摄像机拍摄的其他正常视频，哪怕时长不同、内容不同，只要分辨率和帧率一致，可用性就很高。
- 如果是直播伴侣或录屏软件录制，找同一天、同设置录出来的另一个正常文件。
- 实在找不到，可以在网上找“同型号相机 + 同参数”的样片试试，成功率看运气，但值得一试。
4. 实操过程：命令行一步步救回损坏视频
理论说清楚，下面进入实战。我以一个典型场景为例：用录屏软件录制在线课程，录到 45 分钟时软件崩溃，生成的lesson.mp4无法播放。同一天早些时候我试录过一个 10 秒的test.mp4，配置相同。
4.1 先检查损坏文件的健康状况
修之前先确认文件有没有救的价值。用 ffprobe 看一眼：
ffprobe lesson.mp4大概率会输出类似moov atom not found的报错。这个报错基本就确认了：文件没有索引，适合用 untrunc 修复。如果报错是别的，比如Invalid data found when processing input，说明文件可能损坏得更严重，但不是绝对没救。用 untrunc 跑一次就知道了。
4.2 执行修复命令
untrunc 的命令行格式非常规矩，先放参考文件，再放损坏文件：
./untrunc test.mp4 lesson.mp4执行后程序会输出解析过程，包括从参考文件读出了多少轨道、扫描到了多少视频帧、重建索引到哪个阶段。如果顺利，命令结束后同一目录下会出现一个lesson_fixed.mp4文件。
这里有一个很容易忽略的点：损坏文件路径里如果包含特殊字符或空格，记得用引号包起来，比如"./untrunc test.mp4 'My Lesson 2024.mp4'"。不包的话命令会被 shell 拆分开，报错找不到文件，这个坑很基础但真的很常见。
4.3 修复后别急着删原文件
生成的_fixed.mp4先用 ffprobe 验证一下：
ffprobe lesson_fixed.mp4重点看三件事：
- 视频流和音频流是否都在
- 分辨率、帧率是否和原始配置一致
- 时长是否符合预期（比如 45 分钟的课，修复后出来的时长应该在 44 分多，因为最后几秒数据可能不完整）
确认没问题再考虑删原文件。我的习惯是修好后把原文件留一周，等整个项目交付完再删，因为现阶段压制的、上传的版本可能还会出问题，留着原文件便于重新修复。
4.4 用 GUI 版本操作的差异点
如果你用的是第三方 GUI 版本，操作逻辑无非就是两个输入框一个按钮：参考文件选test.mp4，损坏文件选lesson.mp4，点 Start / Fix，等进度条跑完，在设定好的输出目录找文件。唯一要留意的就是输出路径别和输入路径重叠，避免覆盖。
还有一种常见的 GUI 变体是让你批量选择“参考文件夹”，它会在文件夹下所有正常文件里自动挑一个最匹配的。这个功能很实用，适合手头有一堆历史录屏素材、不确定哪个参数匹配的情况。但批量模式下你没法人为控制参考文件，如果它选错了一个分辨率差异很大的文件，修复效果会打折，用的时候心里要有数。
5. 常见问题与排查技巧：实战中踩过的那些坑
工具用熟了之后，真正的分水岭在于遇到问题能不能快速判断原因。我把这段时间实际使用中踩过、见过的坑整理成一版速查表。
| 现象 | 常见原因 | 排查与解决 |
|---|---|---|
| 修复后视频时长只有几秒 | 参考文件与损坏文件编码参数差异大，扫描阶段只识别出少量完整帧 | 换一个更匹配的参考文件，最好同设备同配置录制 |
| 修复后画面花屏、撕裂 | 重建索引时帧的偏移量对齐出错，常见于参考文件帧结构差异 | 尝试用 ffmpeg 先把参考文件转为与损坏文件相同的编码参数，再作为参考 |
| 修复过程报 “cannot find reference file” | 路径错误或文件损坏 | 先用 ffprobe 确认参考文件可正常播放 |
| 修复后没有声音 | 音频轨参数匹配不上，或录制时就没录到音频流 | 用 ffprobe 检查原始损坏文件是否包含音频帧信息；换参考文件重试 |
| 修复后视频卡顿、音画不同步 | 部分帧数据丢失，索引偏差累计 | 看修复日志里“skipped”数量，如果很多，说明损坏严重，可接受降级播放或放弃 |
| 找不到合适的参考文件 | 相机/软件已变，老参数文件没了 | 用相同设备、相同设置重新录一个最小片段；尝试网络同型号样片 |
除此之外，还有几个我自己总结出来的经验，写下来供参考：
第一，录屏软件崩溃后，第一件事是复制原始文件，永远别在原文件上反复操作。有些工具会在原地尝试改写文件头部，多跑几次可能把原本还能救的数据搞坏。先cp一份再动手，成本极低，收益巨大。
第二，修复前先把该磁盘的剩余空间确认好。untrunc 需要读一个损坏文件、写一个新文件，输出体积和原始 mdat 差不多大。如果你录的是一个 50GB 的长视频，磁盘剩余空间不足，修复到一半会因为写不进去报错，白白浪费时间。
第三，参考文件选择上，“宁可参数一致、不要文件名相似”。我见过有人看到一个文件名相近的旧视频就拿去当参考，结果分辨率差了一倍，修复出来一塌糊涂。文件名毫无意义，ffprobe 看编码参数才是硬道理。
第四，如果多个参考文件都失败，可以试试先用 ffmpeg 把候选参考文件统一转成损坏文件疑似相同的编码参数。这个方法成功率不是百分百，但在找不到非常贴合的参考时，值得一试。命令参考：
ffmpeg -i candidate.mp4 -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 128k candidate_normalized.mp4然后再用这个candidate_normalized.mp4当参考去跑 untrunc。注意这只是一种补救策略，不如原生同源文件可靠。
第五，修复后的文件虽然能播放，但不代表能直接进剪辑软件。有些剪辑软件对 moov 结构要求更严，可能还会报错。遇到这种情况，用 ffmpeg 重新封装一遍：
ffmpeg -i lesson_fixed.mp4 -c copy lesson_remux.mp4这步不做任何重编码，只是把容器结构标准化，经常能解决剪辑软件不认的问题。
6. 最后再分享一点个人经验
我把 untrunc 备在工具库里之后，给自己定了一条规矩：正式的录屏项目开始前，必录 5 秒试片并单独建目录存起来。这 5 秒文件占用空间可以忽略，但关键时刻就是救命稻草。u盘、移动硬盘、网盘我都放了一份，反正也就几百 KB。
还有一点想提醒：untrunc 不是万能修复工具，它擅长的是“结构不完整”这一类问题。如果是文件被恶意清空、磁盘坏道读不出来、视频帧数据大面积损坏，它能做的有限。所以判断“要不要用 untrunc”，就看一个问题——文件大小是否接近正常值。如果大小明显不对（比如 45 分钟的视频只有几 MB），那说明数据已经丢了，神仙也救不回来；如果大小看着正常，只是打不开，那 untrunc 值得一试。
用这个工具的核心，说到底就是把“索引”这个概念想明白。视频文件不是一张完整的大图，它是一堆数据块加一份目录。目录丢了，数据还在，就有得救。untrunc 给了我们一份从邻居家借来的图纸，照着它把目录重建出来，那些以为已经丢了的画面和声音，往往都还在原处等着你。
