故障存储: 64G TF卡/exfat/ 簇（块)大小256sec
故障现象:
客户使用APP查看2024-01-06的数据时发现仅有两条时长很短的视频，其它文件全部不可见。如图1，卡内剩余空间还有45.2G，客户反映并没有做过初始化之类的操作，所以初步排除格式化之类的情况。
图1：卡的剩余空间还有45.2G，排除格式化的情况
图2：使用了目前主流的exfat文件系统
故障分析:
360确实可以，采用了exfat这种比较主流的操作系统，下面来分析下文件结构，看看360的方案是否能让人眼前一亮。如图3，可以看到360采用的是扩展名为BIN的文件来存储数据，肉眼可见的特征如下:
1、bin扩展名，此扩展名在360系中似乎代表了二进制流的自定义文件；
2、文件大小都是64M，且不存在碎片直接连续分配；
通过深入分析确定了以上两条，而且第2条的特征说明其符合“文件型”二进制自定义文件，即以文件为单位进行IO操作，推断其流程基本如下：
创建BIN文件-->IO是以BIN为文件为基准->当达到最大长度时切换至下一个BIN文件
具体是统一批量创建若干文件，还是一个写满再创建新BIN文件，这个就不清楚了。这种方式管理的好处是可以预先知道BIN文件的MAX值，在这个MAX值内合理分配视频流，相对来说管理是比较有效率的属于”预定义“的管理模式，稳定性也比较强。当然缺点也是有的，那就是浪费了空间，不过在这种比较小而精的采集设备上，基本上可以忽略不计（受限于CCD硬件其采集的文件不可能过大）。
这个方案个人感觉用在门铃这种小而精的设备上确实效果很好，比常见的MP4方案更稳定（MP4方案经常会出现封装出错的问题），另外使用自定义二进制文件写入效率更高，因为只需要把采集的声音和画面直接以裸流的形式写入（比如265编码直接写入，去掉了中间打包成HVC编码的环节），另外安全性也更高，因为BIN文件需要后期分离、组合才能得到真正的视频流和音频流，单独的BIN文件是无法被任何播放器解析的。
图3：360采用了BIN类开发方案，也就是二进制流的自定义文件结构
故障处理:
通过分析BIN文件得出:
1、由于采用双摄像头，所以IO时采集的数据是排队写入，两个通道的数据是“叠加”到一起的;
2、视频编码采用了265;
3、BIN二进制流中使用比较严谨的分块方式，给出了当前数据块的时间信息；
整合以上分析结果，写了一个小程序对BIN文件中的数据块进行分离和重组，最终成功找到客户需要的共10条视频文件。这里把音频块直接剔除了，因为音频是以后期合成MP4的方式体现的，客户只要求有视频画面，所以不再对音频进行单独的处理。
图5：360可视门铃BIN文件分离/重组程序
图6：成功恢复的10条视频
图7：播放效果（已对画面做了马赛克处理）
360和小米两个厂商都是“软”实力极强大的，然后涉足了很多硬件领域，这一类厂商有极强的软件开发能力，虽然硬件是代工的，但是方案肯定是这类厂商自行设计的，无论是使用现有的MP4方案还是自定义的BIN方案，两个厂商的开发实力让人侧目。
这就是360可视门铃的恢复方法，对于各种智能摄像头、可视门铃，CHS恢复的效果可以做到取证级---确保每一帧画面都100%正常，目前已成功助力过国内各大公检法机构的取证请求，大家在遇到此类问题时，欢迎和我们联系！
