上个月公司做了一次大规模的素材库迁移从旧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个是严重损坏大量帧数据丢失修复不了只能从备份里找。最终的检测配置供参考模式抽样抽样时长5秒并行数4机械硬盘智能超时开检测音频开检测重复开尝试修复开分类方式复制保留原文件不动