故障存储:32G TF卡   fat32文件系统  簇大小32sec

故障现象:

此卡被人为恶意格式化，然后又写入了一些数据。

故障分析:

看似平常的案例但经过分析却远比想象中复杂，两个原因：

1、 碎片多.（图1，图2）

图1可以看到写入的文件并不多，由于文件基本上是一分钟生成一个（类似于小米、360的1分钟方案），这个方案的优点是摄像头以时间为单位进行数据采集->数据写入->封装成MP4，这样文件不容易出错，终端设备的负荷也比较小。缺点是文件数量多，碎片相对也多。图2可以看到碎片数量为6，可能感觉不多，但这一类方案是刚格式化的卡由于空间大，能做到碎片少，随着写入的增加没有写入的碎片化越来越多，最终就是碎片数量多且小，小到只有一簇。这种极端情况下，讲真，什么软件都不可能完美重组，因为音视频帧数据块过小且交叉存储导致程序算法无法区分碎片从属关系。

碎片产生的原因，实际上用这种方案的原因都差不多，在生成文件的同时会生成日志文件和JPG预览文件，两个文件和视频文件进行了交叉，日志文件还好区分，但是JPG的数据区就很难了，因为本质上无论是那种视频编码其最终还是要走压缩的路，一旦压缩数据区是无法区分的。

2、 编码并不是常见的hvc而是hev.

Mp4文件视频编码常见的方案是avc 和 hvc,对应的是裸流264和265，为什么名称不一样，因为avc/hvc进行了编码。但是这次遇到却是裸流的265，可以看到图3中编码为hev.裸流可以理解为最原始的，不需要修饰的编码，这种情况下恢复的难度会更大，特别是在第1种情况存在的时候。因为只有很精确的定位和分离碎片才能得到比较好的效果。

根据这种复杂的情况，我们使用通用恢复软件来扫描并定位文件的目录，FAT32格式化后只要目录项所在簇没有覆盖就能定位文件的第一个簇，也就是文件头所在。

图1：格式化后写入了大约几百M视频文件

图2：格式化后写入的文件存在碎片

图3： “裸流”hev(265)编码

故障处理:

由于文件名中就包含了日期和时间所以这个也可以精确定位到客户需要的文件，经过通用软件扫描发现客户要的文件名都在，而且第一簇起始是相对靠中间的，所以恢复的机率还是比较大的。

下图可以看到通用恢复软件只会定位到文件目录所在的第一个簇，也就是文件头所在，但是后边的区域就是直接以长度获取了，所以肯定是不能用的。通过这个方法成功定位了客户所要的时间段，由于是采用裸流，所以计划提取文件头所在的簇，得到第一帧画面，来和客户确定数据。但是发现失败了，因为以一个簇为单位进行提取发现视频帧是不完整的，说明碎片极小可能只有一个簇的大小（可以理解为首帧长度>簇长度）。

经过使用不同的方案反复测试，发现没有比较好的办法应对，但是也找到了此类文件的规律，其采用moov后置方案，基本上可以判断在head和moov之间的数据就是此文件的所有簇列表，现在的问题是需要精确的定位碎片并分离数据，但是用常规的方法却无法做到。最后想到之前处理的一个JPG碎片案例，使用遍历方法不断以簇为单位写入，再查看数据，然后根据此方案再结合一些265视频裸流的特征制定了以下恢复方案：

1、 获取文件区间

2、 视频帧自身特征来缩小范围

3、 日志和JPG文件头来缩小范围

4、2和3没有地方直接遍历

根据此方案，重新写了一个小程序进行碎片的筛选和定位，写入一轮再查看一轮，最终完成定位和重组，好在文件较小，所需要的文件也就6个，所以最终效果是极其完美的。如下图可以看到，一个6.35M的文件，簇分割是400多个，但是定位一轮下来，碎片数量已经达到了130多个,比例还是比较高的，多数情况下是2簇或者1簇为单位。

下图为恢复效果，所有文件播放没有任何问题，视频帧及音频帧全部正常，恢复的成功验证了方案的可行性。

这就是扬视界智能摄像头格式化后写入部分文件的恢复方法，大家在遇到此类问题时，可以和我们联系！