视频素材库迁移后的完整性验证：我们团队的检测方案

上个月公司做了一次大规模的素材库迁移，从旧NAS搬到新服务器，涉及一万多个视频文件。迁移本身很顺利，但迁完之后怎么验证文件完整性成了问题。

这篇记录一下我们最终采用的检测方案，以及过程中踩的几个坑。

最初我写了个shell脚本调ffprobe检查每个文件的容器是否可解析。跑完之后发现了30多个明显损坏的文件（文件头都读不出来）。

但后来剪辑师反馈，有些文件能打开、能播放前几秒，但播放到中间就花屏或卡死。这种"表面正常但中间帧损坏"的情况，只查文件头是发现不了的。

我们用的是批量视频损坏检测工具的抽样模式。它的检测逻辑是：对每个视频的头部、中部、尾部三个位置各取一段做实际解码。任意一个位置解码失败就判定为损坏。

相比全量解码（把整个视频从头到尾解一遍），抽样模式快很多，但准确度已经足够------中间帧损坏的情况基本都能抓到。

三种模式的实际耗时对比（以我们的12000个文件为样本）：

模式	耗时	发现损坏数	漏检情况
容器	约40分钟	34个	后续抽样又发现53个
抽样	约4.5小时	87个	全量复查未发现新增
全量	预估20+小时	未完整跑	-

抽样模式的性价比最高。我们后来拿抽样发现的87个损坏文件用全量模式复查了一遍，结果一致，没有误判。

坑1：并行数设太高

一开始设了8线程，结果机械硬盘的IO直接拉满，检测速度反而比4线程还慢。后来改成4线程，速度提升了大概30%。如果是SSD可以适当调高。

坑2：没开智能超时

有几个4K长视频（单个文件8-10GB），用默认的60秒超时直接被判超时了。开启智能超时后，工具会根据文件大小自动延长超时时间，大文件不再被误判。

坑3：忘了勾音频检测

第一轮跑完之后，有个同事反馈某个视频画面正常但没有声音。回头看发现是音频流损坏了，但我们第一轮没勾"检测音频"选项。第二轮勾上之后又多发现了3个音频损坏的文件。

顺手勾了"检测重复"，结果发现了将近600个重复视频，占了大约180GB空间。工具用的是文件头尾各1MB的哈希加文件大小来判断重复，速度很快。

87个损坏文件里，23个被成功修复（修复原理是用ffmpeg重新封装，不重新编码）。修复后的文件我们逐个播放验证过，画面和声音都正常。

剩下64个是严重损坏（大量帧数据丢失），修复不了，只能从备份里找。

供参考：