360可视门铃双摄版恢复案例

家用的智能摄像头恢复了很多，但是可视门铃的恢复却是第一次，现代社会似乎已经全方位处于监控网络之下。360的产品很多，可视门铃只是其众多品牌中的一个，这个案例能让我们窥视到360的开发小精产品的理念。

故障存储:  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%正常，目前已成功助力过国内各大公检法机构的取证请求，大家在遇到此类问题时，欢迎和我们联系！