录屏软件突然崩了、电脑断电、进程被强制结束辛苦录了大半天的素材打不开播放器提示“文件已损坏”或“无法渲染此文件”——这种经历拍过视频、做过在线课程、搞过游戏解说的人大概率都撞上过。市面上号称能“万能修复”的工具不少但真正在本地、免费、还能把截断的 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 第一步解析参考文件的 moovuntrunc 先打开你提供的正常视频把它的 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 上最省事的是用 Homebrewbrew 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 给了我们一份从邻居家借来的图纸照着它把目录重建出来那些以为已经丢了的画面和声音往往都还在原处等着你。