尧图网站建设 
简介untrunc是一套用于恢复损坏截断的MP4、M4V、MOV、3GP等视频的C开源工具面向有命令行基础的中级开发者和视频后期维护者。它通过参照一个完好的同源视频来修复受损文件适用于录像中断、导出异常等场景对M4A等音频同样有效。包内共42个文件以23个C源文件cpp和10个头文件h为主覆盖编解码器解析、轨道处理、原子解析等核心逻辑另附工程配置文件及Dockerfile便于二次编译与容器化使用。压缩包仅72KB代码精简但功能完整适合学习MP4容器结构与容错恢复原理。目前已有1670人学习/下载说明其在实际问题中的参考价值。通过阅读源码读者可掌握基于Libav的修复思路并针对具体损坏情况调整恢复策略。1. untrunc救的是哪类视频截断、打不开、但数据还在的mp4与mov很多“恢复视频”的需求不是来自剪辑事故而是来自“文件还在结尾没了”。无人机航拍时电量耗尽、行车记录仪被直接断电、手机录到一半内存卡被拔出都可能让一段mp4、m4v、mov或3gp只留下残缺的文件头。系统播放器打不开ffprobe也只回一句“moov atom not found”。untrunc就是专治这类截断损坏的开源命令行工具它不靠瞎猜而是拿一个类似的、没有中断的视频当模板把坏文件里残余的帧数据重新拼成可播放的mp4。它适合两类人手里还有同一台设备录过完好视频的人以及想批量处理监控、相机备份目录里一堆打不开文件的人。读完这篇你能搞明白它为什么能救、什么时候救不了、怎么一次跑通。2. 先看MP4盒子结构moov被切断为什么就“救不了”修复截断mp4之前得先理解一个反直觉的事实mp4不是一坨连续编码的数据而是由一堆叫“box”的盒子嵌套组成的。播放器打开文件时并不是老老实实从头读到尾而是先找“目录”再按目录跳到具体位置取数据。所以才会出现“文件有几百MB却打不开”的情况——因为目录丢了数据再多也没人知道从哪一帧开始播。2.1 MP4是盒子套盒子ftyp打头、mdat装数据、moov当目录一个常规MP4文件的开头是ftyp box它声明文件使用哪个QuickTime/MP4规范、支持的品牌体积很小起“门牌号”作用。紧接着大概率是moov box里面装着mvhd、trak、mdia、stbl这一长串元数据再往后是mdat box里面才是真正的H.264/H.265码流和音频采样数据。其中moov里的stbl子box尤为重要stco记录每一帧在文件里的绝对偏移stsz记录每一帧的大小stts记录每一帧的时刻与时长。播放器靠这一整套索引把mdat里一个又一个“图像切片”按时序解码出来。如果moov在文件尾部而损坏恰好从尾部切掉moov往往整个消失。播放器打开文件时找不到目录只能报错。你可能觉得“数据都还在为什么不能从头扫到尾播呢”——因为mp4不是流媒体直播那种扁平结构没了stco播放器无法知道哪些字节是帧数据、哪些字节是box头、哪些是音轨交叉写入的间隔强行按顺序解大概率第一帧都找不到。反过来说那些做了faststart优化的文件moov被前置到文件头部截断时通常只丢mdat尾部的几秒数据文件依然能打开。这类文件根本不需要untrunc用ffmpeg直接重新封装一次就能出片。所以真正需要修复的是“moov丢了、mdat还在”的文件。还有个知识点直接影响修复成功率视频轨如果是H.264帧数据内部自带start code00 00 00 01untrunc扫描mdat时可以借此找到每一帧的边界。如果视频轨是H.265结构类似但参数集名称不同老版本untrunc可能识别不了需要换支持HEVC的新版或手动指定codec。后面第5章会专门讲这个坑。2.2 三种高发的截断姿势录制中断、拷贝中断、索引被腰斩最常见的场景是录制中断。手机、无人机、行车记录仪在异常断电时文件系统被强制卸载实际写入速度跟不上的部分直接丢失。这种损坏通常是“文件末尾缺了一段”前边几百MB码流完好只是moov没写进去或写了一半。untrunc对这种文件的恢复成功率最高因为残余数据质量高尺寸也完整。第二种是拷贝中断。从相机SD卡拷到电脑时拔卡、断USB、网络传输到一半失败导致目标文件的大小停留在某一时刻。这里要注意某些“拷贝中断”的文件操作系统文件表里的大小比实际数据还小或正好卡在某个box的中间修复时依然能找回大部分内容但如果是U盘主控写入时掉电可能连MDAT中间都缺了数据块恢复出来就会花屏或跳帧。第三种是索引被腰斩。部分录制设备默认把moov放到文件末尾整个文件长这样ftyp 少量free 全部mdat moov。你用网盘或FTP传输这种文件时如果传输在中途被掐断丢的正是最后的moov。这种场景下数据几乎100%完好缺的只是“目录”untrunc恢复效果极佳。判断坏文件是否值得修复有一个朴素标准先看文件大小。一个正常1080p手机录像每秒码率约10-20Mbps1分钟大约100多MB如果坏文件只剩几百KB说明连数据都被砍光了这时结构修复没有任何意义。先用ls -l bad.mp4看一眼体积再决定要不要折腾这是最省时间的步骤。2.3 动手前先用十六进制确认里头还有“货”开工前我一般会做一步快检用十六进制工具看一眼坏文件头部和尾部确认ftyp还在、mdat还在只是moov丢了。熟悉本领域的人称之为“先摸清坏文件的家底”避免白跑一晚上。# 查看文件头部能正常看到 ftyp 占前几字节 xxd bad.mp4 | head -20 # 搜索文件里的关键 box 标识moov、mdat 出现的位置 grep -aob ftyp\|moov\|mdat bad.mp4 | head -20xxd展示前十几行主要确认文件头不是全零说明不是空文件。grep -aob会把ftyp、moov、mdat三种box标识在文件里的字节偏移打出来如果能看到mdat偏移值但找不到moov这就是untrunc能处理的典型形态如果连mdat都找不到说明数据层损坏直接放弃。这条命令不会修改原文件可以放心跑。做完这一步你对“值不值得修”就有底了。注意grep -aob的偏移量是十进制字节位置。moov一般出现在文件头附近或文件尾部如果你只看到ftyp和free没有moov那么修复希望很大。3. 准备工具链编译untrunc并挑一个正确的参考文件untrunc不是一个能下载完直接双击的图形程序它本质上是C源码依赖FFmpeg的库来解析容器和解码参数。在不同的发行版上编译差异不小但整体思路一致先把FFmpeg开发库装好再编译源码最终得到一个可执行的二进制。本节把Linux和macOS的主流程都讲一遍Windows用户可以在WSL里跑同样命令。3.1 编译安装从源码到可用二进制系统依赖方面Debian/Ubuntu系通常需要libavformat-dev、libavcodec-dev、libavutil-dev、libavdevice-dev这几个包macOS用户用Homebrew安装ffmpeg时需要带上能输出静态库的选项。装好之后进入untrunc源码目录编译。# 进入源码目录先看仓库里是否自带Makefile ls -l # 自带Makefile时直接编译 make # 如果make报错或链接不通过可以手工编译 # gcc -o untrunc untrunc.c -lavformat -lavcodec -lavutil -lm # 编译成功后验证可用性 ./untrunc不带参数直接运行./untrunc会打印usage帮助信息这是确认编译成功最直接的方法。如果提示缺少libavformat.so说明动态库路径没找到常见做法是检查ldconfig -p | grep libavformat或者把FFmpeg安装目录加入LD_LIBRARY_PATH。这里最绕人的坑是老版本untrunc源码与新版本FFmpeg库的API不兼容编译报错时不要死磕直接换一个新的fork版本源码再试这种坑不值得花时间。3.2 参考文件怎么挑只有名称相似是不够的untrunc的工作原理决定了它必须有一个参考文件。坏文件与好文件的编码格式、分辨率、帧率越接近恢复出来的结果越可靠。最理想的参考文件就是同一台设备、同一个拍摄模式下紧挨着坏文件录的那一段正常视频。比如无人机连续拍摄时航段1损坏了航段2完好那么航段2就是救航段1最好的模板。参考文件至少要满足三点。第一视频编码一致H.264的就是H.264H.265的就是H.265混用基本白搭。第二分辨率完全一致同样是4K3840x2160和3840x2160不能差一像素。第三音视频轨道结构一致如果坏文件是双音轨录音设备录的参考文件也最好有同样多的音轨不然修复后可能丢音轨。下面是挑选参考文件时的检查清单。检查项命令要求编码格式ffprobe -v quiet -show_streams -select_streams v:0 -show_entries streamcodec_name good.mp4与坏文件一致分辨率同上看width、height严格一致帧率ffprobe -v quiet -show_streams -select_streams v:0 -show_entries streamavg_frame_rate good.mp4与坏文件预期接近音轨数ffprobe -v quiet -show_streams -show_entries streamcodec_type good.mp4与坏文件录制时的音轨数一致3.3 实在找不到参考文件时怎么办如果你手里只有孤零零一个坏文件可以先别慌。手机厂商、运动相机、行车记录仪这类固定参数设备你手头随便找一个同分辨率、同时长的旧视频哪怕不是同一个日期拍的也值得一试。常见做法是先用ffprobe扫出你手头所有mp4的分辨率和编码筛出匹配项再逐一作为参考文件跑untrunc最后拿ffprobe验证哪个结果能读出时长和SPS信息。这个“用候选列表试一圈”的过程不复杂但能救回意想不到的文件。注意参考文件不要拿转码后的文件。用格式工厂或剪辑软件二次导出过的mp4容器参数已经重写和相机直出的结构相差很大修复成功率会明显下降。优先找原始直出的文件。4. 跑通恢复流程最小命令、参数与结果验证工具链就绪后真正执行修复反而很简单。核心思路就是一条命令untrunc后面跟两个文件第一个是正常参考文件第二个是损坏文件。本节从最小命令讲起再展开参数怎么选最后给出恢复后必须做的三连验证。4.1 最小恢复命令先跑出结果再说# 语法untrunc 参考好文件 损坏文件 ./untrunc good.MP4 bad.mp4 # 常见变体指定输出的文件名 ./untrunc -o fixed.mp4 good.MP4 bad.mp4执行过程中untrunc会先读取参考文件的moov元数据再扫描坏文件里的mdat数据最后把两者合并成新文件。命令行里第一个参数永远是参考文件第二个才是损坏文件这个顺序反了会直接报错或者把好文件覆盖掉。合并没有发生之前原文件不会被改动这一点还算安全。扫描和解析通常需要几秒到几十秒取决于视频时长和硬盘读取速度耐心等它跑完输出文件默认生成在当前目录具体文件名以运行./untrunc时打印的usage为准。4.2 核心参数按usage走别照搬老教程不同分支的untrunc参数略有差异最稳妥的方式是先在终端跑一次./untrunc看它自己打印的帮助再按需取用。但通用高频参数基本跑不掉-o指定输出文件路径批量修复时尤其好用避免默认文件名把参考文件顶掉-q进入静默模式脚本里循环跑的时候能减少大量中间日志-c手动指定视频编码方式当自动探测失败、但你能确定坏文件是H.265时有的版本支持这样强制指定。还需要理解-d这类时长参数有些版本支持限制处理时长只恢复坏文件前N秒的内容。当文件后半段已经完全损坏、但你还想抢救前面几分钟素材时给untrunc一个合理的时长上限可以避免它在损坏区反复尝试导致输出文件无法播放。至于具体参数名不同分支确实不同我通常的做法是先把usage输出保存下来再动手写脚本。4.3 恢复后的三连验证ffprobe、ffplay、全解码测试修出来的文件能不能用不能只说“播放器能打开”。我一般按下面三步验证每步都有不同的目的# 1. 用 ffprobe 确认容器结构时长、分辨率、帧率是否已恢复 ffprobe -v error -show_entries formatduration,size:streamcodec_name,width,height,avg_frame_rate -of defaultnoprint_wrappers1 fixed.mp4 # 2. 用播放器实际播一遍确认能出画面且有声音 ffplay -autoexit fixed.mp4 # 3. 全解码测试逐帧过一遍解码器检查有没有花屏或解码错误 ffmpeg -v error -i fixed.mp4 -f null - 21 | head -50第一步看结构信息duration字段是不是大于零是不是和坏文件应有时长接近第二步是主观检查重点看开头和结尾两处有没有绿屏、卡帧、声音是否同步第三步是把整段视频完整解码一遍-f null -只解码不输出任何解码错误都会打印到stderr。三步全过再谈交付。如果第三步刷出一堆error说明修复文件只能“打开”不能“正常播”后期转码也会中途失败。5. untrunc避坑排查恢复失败和“能放但不对”的五个高发问题untrunc不是万能后悔药它有自己的失效边界。下面这五类情形是真实使用中最高发的坑每一条都按“现象-原因-解决”展开看过之后能帮你省下大量试错时间。5.1 “moov atom not found”但文件头还在现象ffprobe直接报错打不开但用xxd看文件头ftyp完全正常大小也有几百MB。原因moov box位于文件尾部被截断整段删掉了播放器和ffprobe都无法重建索引。解决这正是untrunc的典型对口场景直接执行最小修复命令即可。如果执行时提示“cannot find video track”之类信息先确认参考文件的视频track存在再看坏文件里mdat是否完整。若grep -aob只能搜到mdat的box头但后续偏移比实际文件大小还大那就是文件被截断在了mdat中间这种修复出来通常后半段是绿屏实际价值有限。5.2 恢复成功但时长不对画面快进现象修复出来的视频能正常播放但总时长远小于参考文件比如参考文件有30分钟恢复结果只有3分钟画面像是被快进。原因坏文件丢失了部分帧数据或者SPS/PPS引用的帧率信息与参考文件不一致导致stts时间基错乱。解决检查参考文件是否真的匹配——分辨率相同、帧率相同、编码profile相同差一个都不行另外明确一点untrunc恢复的是“能找回多少数据”不是变魔术补全画面。如果3分钟已经是坏文件里全部完好的数据那就接受这个结果。想进一步确认用第4章的ffprobe看输出文件avg_frame_rate是否在合理范围。5.3 没有参考文件时靠同规格视频“碰运气”现象坏文件来自某台已经报废的旧设备找不到任何同机素材我拿手机随便录了一段同分辨率视频当参考执行后报“track size mismatch”或输出花屏。原因untrunc会把参考文件的moov容器参数直接套用到坏文件上如果参考文件的GOP结构、编码profile、音频采样率与坏文件差距过大扫描出的帧数量与容器索引无法匹配。解决唯一可行路径是扩大候选池把能拿到的同规格mp4全部试一遍用ffprobe验证每次输出是否有正常时长。这个做法不保证成功但运气好的时候能救回某些老设备素材。也有商业工具能做无参考文件恢复但那个优先级低先把untrunc这条便宜的路径走完再考虑。5.4 H.265/HEVC视频修复出来全是绿屏现象运动相机的高帧率H.265视频修复成功但播放时画面全是绿色马赛克一点有效内容都看不到。原因老版本untrunc对HEVC的解析支持不完整VPS/SPS/PPS参数集没有被正确写入输出文件。解决优先尝试支持H.265的更新分支版本如果编译环境不便更新检查是否存在-c h265之类的codec指定参数强制按HEVC解析。千万不要指望一个旧二进制通吃所有编码拿不同版本各跑一次再用ffplay验证成本低收益高。5.5 修出视频后音频丢失或音画不同步现象修复后的mp4视频轨完好但完全没有声音或者有声音却比画面晚半秒。原因参考文件音轨参数与坏文件不一致或者坏文件的音频数据在截断时被部分丢弃untrunc扫描时没有找到可配对的音频帧。解决先用ffprobe看参考文件有没有音轨、声道数是多少如果参考文件是单声道而坏文件录制时是立体声尽量找一个音轨参数吻合的参考文件。对于音画不同步可以用ffmpeg将修复文件与原始音频重新封装处理步骤见下面命令块。这一步属于事后补救能解决一部分不同步问题但不能凭空造出丢失的音频轨道。# 提取坏文件里还能读出的音频轨前提ffmpeg 能部分解析坏文件 ffmpeg -v error -i bad.mp4 -vn -acodec copy audio.m4a # 重新封装用修复后的视频轨 提取出来的音频轨合成新文件 ffmpeg -v error -i fixed.mp4 -i audio.m4a -map 0:v:0 -map 1:a:0 -c copy final.mp46. 把恢复做成脚本批量修复与自动验证单文件修复跑通后真正能派上大用场的场景是批量处理。比如监控摄像头SD卡拔出来后里面几十个mp4全部损坏或者相机备份目录里混杂着大量打不开的素材。逐条手敲命令既费时又容易漏我一般会写一个简单的bash循环自动完成“找参考文件-执行修复-自动验证”三步并把验证结果打印成清单。#!/bin/bash # batch_fix.sh批量恢复目录里的截断 mp4 GOOD_DIR./good # 参考视频目录 BAD_DIR./bad # 损坏视频目录 OUT_DIR./out # 恢复输出目录 mkdir -p $OUT_DIR for bad in $BAD_DIR/*.mp4; do [ -f $bad ] || continue name$(basename $bad) good$GOOD_DIR/$name if [ ! -f $good ]; then echo SKIP $name : no reference file continue fi out$OUT_DIR/${name%.mp4}_fixed.mp4 untrunc -q -o $out $good $bad || { echo FAIL $name continue } dur$(ffprobe -v error -show_entries formatduration -of defaultnw1:nk1 $out 2/dev/null) echo OK $name - duration${dur:-0}s done这个脚本的逻辑不复杂遍历坏文件目录找同名参考文件找不到就跳过执行untrunc时加上-q静默参数避免日志淹没关键信息恢复完成后立即用ffprobe抽取时长时长为空或为零就说明这次修复没有产出有效文件。这么做最大的好处是能筛掉大量无效结果只保留下真正可以进后期流程的素材。恢复出来的成品如果头尾有多余黑场还可以用ffmpeg无损切割掉首尾两秒把素材修整成可直接剪辑的状态。我第一次批量处理这类素材时就是因为没有按设备区分参考文件把同一台无人机里4K和1080P两种规格混在一起跑结果恢复出来一半文件时长异常白跑了一晚上。后来养成了习惯批量修复前先按分辨率和编码分组每组单独指定参考文件跑完再自动验证一遍——这步排查动作救回了我后来好几批监控素材。希望这些流程也能帮到你少踩坑。本文还有配套的精品资源点击获取 MP4截断文件修复：untrunc原理与实战指南
简介untrunc是一套用于恢复损坏截断的MP4、M4V、MOV、3GP等视频的C开源工具面向有命令行基础的中级开发者和视频后期维护者。它通过参照一个完好的同源视频来修复受损文件适用于录像中断、导出异常等场景对M4A等音频同样有效。包内共42个文件以23个C源文件cpp和10个头文件h为主覆盖编解码器解析、轨道处理、原子解析等核心逻辑另附工程配置文件及Dockerfile便于二次编译与容器化使用。压缩包仅72KB代码精简但功能完整适合学习MP4容器结构与容错恢复原理。目前已有1670人学习/下载说明其在实际问题中的参考价值。通过阅读源码读者可掌握基于Libav的修复思路并针对具体损坏情况调整恢复策略。1. untrunc救的是哪类视频截断、打不开、但数据还在的mp4与mov很多“恢复视频”的需求不是来自剪辑事故而是来自“文件还在结尾没了”。无人机航拍时电量耗尽、行车记录仪被直接断电、手机录到一半内存卡被拔出都可能让一段mp4、m4v、mov或3gp只留下残缺的文件头。系统播放器打不开ffprobe也只回一句“moov atom not found”。untrunc就是专治这类截断损坏的开源命令行工具它不靠瞎猜而是拿一个类似的、没有中断的视频当模板把坏文件里残余的帧数据重新拼成可播放的mp4。它适合两类人手里还有同一台设备录过完好视频的人以及想批量处理监控、相机备份目录里一堆打不开文件的人。读完这篇你能搞明白它为什么能救、什么时候救不了、怎么一次跑通。2. 先看MP4盒子结构moov被切断为什么就“救不了”修复截断mp4之前得先理解一个反直觉的事实mp4不是一坨连续编码的数据而是由一堆叫“box”的盒子嵌套组成的。播放器打开文件时并不是老老实实从头读到尾而是先找“目录”再按目录跳到具体位置取数据。所以才会出现“文件有几百MB却打不开”的情况——因为目录丢了数据再多也没人知道从哪一帧开始播。2.1 MP4是盒子套盒子ftyp打头、mdat装数据、moov当目录一个常规MP4文件的开头是ftyp box它声明文件使用哪个QuickTime/MP4规范、支持的品牌体积很小起“门牌号”作用。紧接着大概率是moov box里面装着mvhd、trak、mdia、stbl这一长串元数据再往后是mdat box里面才是真正的H.264/H.265码流和音频采样数据。其中moov里的stbl子box尤为重要stco记录每一帧在文件里的绝对偏移stsz记录每一帧的大小stts记录每一帧的时刻与时长。播放器靠这一整套索引把mdat里一个又一个“图像切片”按时序解码出来。如果moov在文件尾部而损坏恰好从尾部切掉moov往往整个消失。播放器打开文件时找不到目录只能报错。你可能觉得“数据都还在为什么不能从头扫到尾播呢”——因为mp4不是流媒体直播那种扁平结构没了stco播放器无法知道哪些字节是帧数据、哪些字节是box头、哪些是音轨交叉写入的间隔强行按顺序解大概率第一帧都找不到。反过来说那些做了faststart优化的文件moov被前置到文件头部截断时通常只丢mdat尾部的几秒数据文件依然能打开。这类文件根本不需要untrunc用ffmpeg直接重新封装一次就能出片。所以真正需要修复的是“moov丢了、mdat还在”的文件。还有个知识点直接影响修复成功率视频轨如果是H.264帧数据内部自带start code00 00 00 01untrunc扫描mdat时可以借此找到每一帧的边界。如果视频轨是H.265结构类似但参数集名称不同老版本untrunc可能识别不了需要换支持HEVC的新版或手动指定codec。后面第5章会专门讲这个坑。2.2 三种高发的截断姿势录制中断、拷贝中断、索引被腰斩最常见的场景是录制中断。手机、无人机、行车记录仪在异常断电时文件系统被强制卸载实际写入速度跟不上的部分直接丢失。这种损坏通常是“文件末尾缺了一段”前边几百MB码流完好只是moov没写进去或写了一半。untrunc对这种文件的恢复成功率最高因为残余数据质量高尺寸也完整。第二种是拷贝中断。从相机SD卡拷到电脑时拔卡、断USB、网络传输到一半失败导致目标文件的大小停留在某一时刻。这里要注意某些“拷贝中断”的文件操作系统文件表里的大小比实际数据还小或正好卡在某个box的中间修复时依然能找回大部分内容但如果是U盘主控写入时掉电可能连MDAT中间都缺了数据块恢复出来就会花屏或跳帧。第三种是索引被腰斩。部分录制设备默认把moov放到文件末尾整个文件长这样ftyp 少量free 全部mdat moov。你用网盘或FTP传输这种文件时如果传输在中途被掐断丢的正是最后的moov。这种场景下数据几乎100%完好缺的只是“目录”untrunc恢复效果极佳。判断坏文件是否值得修复有一个朴素标准先看文件大小。一个正常1080p手机录像每秒码率约10-20Mbps1分钟大约100多MB如果坏文件只剩几百KB说明连数据都被砍光了这时结构修复没有任何意义。先用ls -l bad.mp4看一眼体积再决定要不要折腾这是最省时间的步骤。2.3 动手前先用十六进制确认里头还有“货”开工前我一般会做一步快检用十六进制工具看一眼坏文件头部和尾部确认ftyp还在、mdat还在只是moov丢了。熟悉本领域的人称之为“先摸清坏文件的家底”避免白跑一晚上。# 查看文件头部能正常看到 ftyp 占前几字节 xxd bad.mp4 | head -20 # 搜索文件里的关键 box 标识moov、mdat 出现的位置 grep -aob ftyp\|moov\|mdat bad.mp4 | head -20xxd展示前十几行主要确认文件头不是全零说明不是空文件。grep -aob会把ftyp、moov、mdat三种box标识在文件里的字节偏移打出来如果能看到mdat偏移值但找不到moov这就是untrunc能处理的典型形态如果连mdat都找不到说明数据层损坏直接放弃。这条命令不会修改原文件可以放心跑。做完这一步你对“值不值得修”就有底了。注意grep -aob的偏移量是十进制字节位置。moov一般出现在文件头附近或文件尾部如果你只看到ftyp和free没有moov那么修复希望很大。3. 准备工具链编译untrunc并挑一个正确的参考文件untrunc不是一个能下载完直接双击的图形程序它本质上是C源码依赖FFmpeg的库来解析容器和解码参数。在不同的发行版上编译差异不小但整体思路一致先把FFmpeg开发库装好再编译源码最终得到一个可执行的二进制。本节把Linux和macOS的主流程都讲一遍Windows用户可以在WSL里跑同样命令。3.1 编译安装从源码到可用二进制系统依赖方面Debian/Ubuntu系通常需要libavformat-dev、libavcodec-dev、libavutil-dev、libavdevice-dev这几个包macOS用户用Homebrew安装ffmpeg时需要带上能输出静态库的选项。装好之后进入untrunc源码目录编译。# 进入源码目录先看仓库里是否自带Makefile ls -l # 自带Makefile时直接编译 make # 如果make报错或链接不通过可以手工编译 # gcc -o untrunc untrunc.c -lavformat -lavcodec -lavutil -lm # 编译成功后验证可用性 ./untrunc不带参数直接运行./untrunc会打印usage帮助信息这是确认编译成功最直接的方法。如果提示缺少libavformat.so说明动态库路径没找到常见做法是检查ldconfig -p | grep libavformat或者把FFmpeg安装目录加入LD_LIBRARY_PATH。这里最绕人的坑是老版本untrunc源码与新版本FFmpeg库的API不兼容编译报错时不要死磕直接换一个新的fork版本源码再试这种坑不值得花时间。3.2 参考文件怎么挑只有名称相似是不够的untrunc的工作原理决定了它必须有一个参考文件。坏文件与好文件的编码格式、分辨率、帧率越接近恢复出来的结果越可靠。最理想的参考文件就是同一台设备、同一个拍摄模式下紧挨着坏文件录的那一段正常视频。比如无人机连续拍摄时航段1损坏了航段2完好那么航段2就是救航段1最好的模板。参考文件至少要满足三点。第一视频编码一致H.264的就是H.264H.265的就是H.265混用基本白搭。第二分辨率完全一致同样是4K3840x2160和3840x2160不能差一像素。第三音视频轨道结构一致如果坏文件是双音轨录音设备录的参考文件也最好有同样多的音轨不然修复后可能丢音轨。下面是挑选参考文件时的检查清单。检查项命令要求编码格式ffprobe -v quiet -show_streams -select_streams v:0 -show_entries streamcodec_name good.mp4与坏文件一致分辨率同上看width、height严格一致帧率ffprobe -v quiet -show_streams -select_streams v:0 -show_entries streamavg_frame_rate good.mp4与坏文件预期接近音轨数ffprobe -v quiet -show_streams -show_entries streamcodec_type good.mp4与坏文件录制时的音轨数一致3.3 实在找不到参考文件时怎么办如果你手里只有孤零零一个坏文件可以先别慌。手机厂商、运动相机、行车记录仪这类固定参数设备你手头随便找一个同分辨率、同时长的旧视频哪怕不是同一个日期拍的也值得一试。常见做法是先用ffprobe扫出你手头所有mp4的分辨率和编码筛出匹配项再逐一作为参考文件跑untrunc最后拿ffprobe验证哪个结果能读出时长和SPS信息。这个“用候选列表试一圈”的过程不复杂但能救回意想不到的文件。注意参考文件不要拿转码后的文件。用格式工厂或剪辑软件二次导出过的mp4容器参数已经重写和相机直出的结构相差很大修复成功率会明显下降。优先找原始直出的文件。4. 跑通恢复流程最小命令、参数与结果验证工具链就绪后真正执行修复反而很简单。核心思路就是一条命令untrunc后面跟两个文件第一个是正常参考文件第二个是损坏文件。本节从最小命令讲起再展开参数怎么选最后给出恢复后必须做的三连验证。4.1 最小恢复命令先跑出结果再说# 语法untrunc 参考好文件 损坏文件 ./untrunc good.MP4 bad.mp4 # 常见变体指定输出的文件名 ./untrunc -o fixed.mp4 good.MP4 bad.mp4执行过程中untrunc会先读取参考文件的moov元数据再扫描坏文件里的mdat数据最后把两者合并成新文件。命令行里第一个参数永远是参考文件第二个才是损坏文件这个顺序反了会直接报错或者把好文件覆盖掉。合并没有发生之前原文件不会被改动这一点还算安全。扫描和解析通常需要几秒到几十秒取决于视频时长和硬盘读取速度耐心等它跑完输出文件默认生成在当前目录具体文件名以运行./untrunc时打印的usage为准。4.2 核心参数按usage走别照搬老教程不同分支的untrunc参数略有差异最稳妥的方式是先在终端跑一次./untrunc看它自己打印的帮助再按需取用。但通用高频参数基本跑不掉-o指定输出文件路径批量修复时尤其好用避免默认文件名把参考文件顶掉-q进入静默模式脚本里循环跑的时候能减少大量中间日志-c手动指定视频编码方式当自动探测失败、但你能确定坏文件是H.265时有的版本支持这样强制指定。还需要理解-d这类时长参数有些版本支持限制处理时长只恢复坏文件前N秒的内容。当文件后半段已经完全损坏、但你还想抢救前面几分钟素材时给untrunc一个合理的时长上限可以避免它在损坏区反复尝试导致输出文件无法播放。至于具体参数名不同分支确实不同我通常的做法是先把usage输出保存下来再动手写脚本。4.3 恢复后的三连验证ffprobe、ffplay、全解码测试修出来的文件能不能用不能只说“播放器能打开”。我一般按下面三步验证每步都有不同的目的# 1. 用 ffprobe 确认容器结构时长、分辨率、帧率是否已恢复 ffprobe -v error -show_entries formatduration,size:streamcodec_name,width,height,avg_frame_rate -of defaultnoprint_wrappers1 fixed.mp4 # 2. 用播放器实际播一遍确认能出画面且有声音 ffplay -autoexit fixed.mp4 # 3. 全解码测试逐帧过一遍解码器检查有没有花屏或解码错误 ffmpeg -v error -i fixed.mp4 -f null - 21 | head -50第一步看结构信息duration字段是不是大于零是不是和坏文件应有时长接近第二步是主观检查重点看开头和结尾两处有没有绿屏、卡帧、声音是否同步第三步是把整段视频完整解码一遍-f null -只解码不输出任何解码错误都会打印到stderr。三步全过再谈交付。如果第三步刷出一堆error说明修复文件只能“打开”不能“正常播”后期转码也会中途失败。5. untrunc避坑排查恢复失败和“能放但不对”的五个高发问题untrunc不是万能后悔药它有自己的失效边界。下面这五类情形是真实使用中最高发的坑每一条都按“现象-原因-解决”展开看过之后能帮你省下大量试错时间。5.1 “moov atom not found”但文件头还在现象ffprobe直接报错打不开但用xxd看文件头ftyp完全正常大小也有几百MB。原因moov box位于文件尾部被截断整段删掉了播放器和ffprobe都无法重建索引。解决这正是untrunc的典型对口场景直接执行最小修复命令即可。如果执行时提示“cannot find video track”之类信息先确认参考文件的视频track存在再看坏文件里mdat是否完整。若grep -aob只能搜到mdat的box头但后续偏移比实际文件大小还大那就是文件被截断在了mdat中间这种修复出来通常后半段是绿屏实际价值有限。5.2 恢复成功但时长不对画面快进现象修复出来的视频能正常播放但总时长远小于参考文件比如参考文件有30分钟恢复结果只有3分钟画面像是被快进。原因坏文件丢失了部分帧数据或者SPS/PPS引用的帧率信息与参考文件不一致导致stts时间基错乱。解决检查参考文件是否真的匹配——分辨率相同、帧率相同、编码profile相同差一个都不行另外明确一点untrunc恢复的是“能找回多少数据”不是变魔术补全画面。如果3分钟已经是坏文件里全部完好的数据那就接受这个结果。想进一步确认用第4章的ffprobe看输出文件avg_frame_rate是否在合理范围。5.3 没有参考文件时靠同规格视频“碰运气”现象坏文件来自某台已经报废的旧设备找不到任何同机素材我拿手机随便录了一段同分辨率视频当参考执行后报“track size mismatch”或输出花屏。原因untrunc会把参考文件的moov容器参数直接套用到坏文件上如果参考文件的GOP结构、编码profile、音频采样率与坏文件差距过大扫描出的帧数量与容器索引无法匹配。解决唯一可行路径是扩大候选池把能拿到的同规格mp4全部试一遍用ffprobe验证每次输出是否有正常时长。这个做法不保证成功但运气好的时候能救回某些老设备素材。也有商业工具能做无参考文件恢复但那个优先级低先把untrunc这条便宜的路径走完再考虑。5.4 H.265/HEVC视频修复出来全是绿屏现象运动相机的高帧率H.265视频修复成功但播放时画面全是绿色马赛克一点有效内容都看不到。原因老版本untrunc对HEVC的解析支持不完整VPS/SPS/PPS参数集没有被正确写入输出文件。解决优先尝试支持H.265的更新分支版本如果编译环境不便更新检查是否存在-c h265之类的codec指定参数强制按HEVC解析。千万不要指望一个旧二进制通吃所有编码拿不同版本各跑一次再用ffplay验证成本低收益高。5.5 修出视频后音频丢失或音画不同步现象修复后的mp4视频轨完好但完全没有声音或者有声音却比画面晚半秒。原因参考文件音轨参数与坏文件不一致或者坏文件的音频数据在截断时被部分丢弃untrunc扫描时没有找到可配对的音频帧。解决先用ffprobe看参考文件有没有音轨、声道数是多少如果参考文件是单声道而坏文件录制时是立体声尽量找一个音轨参数吻合的参考文件。对于音画不同步可以用ffmpeg将修复文件与原始音频重新封装处理步骤见下面命令块。这一步属于事后补救能解决一部分不同步问题但不能凭空造出丢失的音频轨道。# 提取坏文件里还能读出的音频轨前提ffmpeg 能部分解析坏文件 ffmpeg -v error -i bad.mp4 -vn -acodec copy audio.m4a # 重新封装用修复后的视频轨 提取出来的音频轨合成新文件 ffmpeg -v error -i fixed.mp4 -i audio.m4a -map 0:v:0 -map 1:a:0 -c copy final.mp46. 把恢复做成脚本批量修复与自动验证单文件修复跑通后真正能派上大用场的场景是批量处理。比如监控摄像头SD卡拔出来后里面几十个mp4全部损坏或者相机备份目录里混杂着大量打不开的素材。逐条手敲命令既费时又容易漏我一般会写一个简单的bash循环自动完成“找参考文件-执行修复-自动验证”三步并把验证结果打印成清单。#!/bin/bash # batch_fix.sh批量恢复目录里的截断 mp4 GOOD_DIR./good # 参考视频目录 BAD_DIR./bad # 损坏视频目录 OUT_DIR./out # 恢复输出目录 mkdir -p $OUT_DIR for bad in $BAD_DIR/*.mp4; do [ -f $bad ] || continue name$(basename $bad) good$GOOD_DIR/$name if [ ! -f $good ]; then echo SKIP $name : no reference file continue fi out$OUT_DIR/${name%.mp4}_fixed.mp4 untrunc -q -o $out $good $bad || { echo FAIL $name continue } dur$(ffprobe -v error -show_entries formatduration -of defaultnw1:nk1 $out 2/dev/null) echo OK $name - duration${dur:-0}s done这个脚本的逻辑不复杂遍历坏文件目录找同名参考文件找不到就跳过执行untrunc时加上-q静默参数避免日志淹没关键信息恢复完成后立即用ffprobe抽取时长时长为空或为零就说明这次修复没有产出有效文件。这么做最大的好处是能筛掉大量无效结果只保留下真正可以进后期流程的素材。恢复出来的成品如果头尾有多余黑场还可以用ffmpeg无损切割掉首尾两秒把素材修整成可直接剪辑的状态。我第一次批量处理这类素材时就是因为没有按设备区分参考文件把同一台无人机里4K和1080P两种规格混在一起跑结果恢复出来一半文件时长异常白跑了一晚上。后来养成了习惯批量修复前先按分辨率和编码分组每组单独指定参考文件跑完再自动验证一遍——这步排查动作救回了我后来好几批监控素材。希望这些流程也能帮到你少踩坑。本文还有配套的精品资源点击获取