故障文件:222M样本文件

故障现象:

针对样本文件做了清空结构体操作，来测试下程序查找数据区（音、视频帧）的极限。

故障分析:

软件使用环境：大类->高清视频，小类->打开样本文件，其它设置为默认情况下的扫描结果如下图。可以看到一个文件被分隔出36个数据区，这个明显是不正常的。

分析及解决方案:

使用分析工具可以查看到其采用的音频格式和常见的SOWT一样是LPCM，唯一的区别是有4个单独的TRAK来负责记录每一个声道，如下图：

独立的TRAK正常情况下就会产生四个独立的音频数据区，这个是必然的（如下图），因为音频不存在逻辑TRAK其是需要有实体数据来体现的。而松下使用的是四个声道连续存储的方案，这也是高清音频最优的一种方案。连续存储方便编码和解码时连续IO，这样可以有效降低资源的占用，提升IO效率。

特殊之处有两个：

1、 音频数据块长度竟然使用了动态长度VBR的方案，这个在高清音频中是极罕见的，因为本身PCM就是固定长度，所以一般是使用固定长度。如下图：

2、 音频块中实际上只存储了两个TRAK，另外两个TRAK全部为00，这种情况极有可能是物理硬件上可能仅有两个拾音MIC, 但是其支持最高四个拾音MIC（这个和支持八声道但只在硬件上给出四个四个拾音MIC一个道理）。这个反映到数据底层，就是会有两个TRAK的数据区全部为00，因为没有波形输入，如下图。

有了分析，就会有对应的解决方案，通过在高级设置修改参数就可以成功解决，连续的两个音频块MAX值为134844，只要设置这个值就可以了。

扫描设置->高级设置

视频类通用设置->00/FF最大长度 填入值13744, 注意这里单位是字节，点击确定

重新扫描可以看到程序已经成功识别了整个文件，如下图。这个特殊的情况告诉我们，松下是一个另类要小心对待，还有就是只要经过详细的分析所有问题都会找到一个对应的方案。