文件格式:MP4
故障描述:
两个损坏的视频文件，一个为400多M，一个为1.3G左右。某晚会使用多机位进行录制，数据通过摄像机采集后直接保存到存储设备中，当天录制了很多个文件，这两个文件也在其中，但是最后发现其它文件均正常，这两个文件无法播放！
故障分析：
直接播放文件，直接报错,如下图:
看这个报错信息，播放器连编码都解析不了直接成了不可识别文件，估计是文件结构体没有封装完毕，而视频、音频的编码是保存在文件结构体中的，在WINHEX中查看文件后证明了之前的猜测！
让客户提供样本文件进行分析，分析后发现这种视频和普通摄像机的结构有很大差异。
视频格式比较常见，但是音频却使用了非高清且是压缩率较高的编码，一般来说这种现场录制的音频多偏向于使用高清方案，很显然这个是个例外（这也是为何文件容量如此小的原因，压缩率高了，占的空间自然少了）；视频竟然没有使用统一的逻辑长度值，而是使用动态逻辑长度VBR（注：这个逻辑长度并非原始帧长度，虽然原始长度本就是动态的，但在视频的逻辑层如时间轴一般是使用VBE静态长度的方案），这个让人比较疑惑，因为逻辑长度VBR从文件结构来讲是允许的但是却会增加解码时的开销（解一帧就要获取一帧的逻辑长度）。这个奇葩的方案让人很困惑，后来我仔细想，可能是这些摄像机仅仅是负责采集，并没有打包封装文件结构的功能，这些工作最后是交给那台存储设备来完成，从这一点讲那台存储设备是参与了打包封装工作的，一边收集采集信息，一边打包，所以逻辑长度最后全部采用了动态方案这可能是唯一合理的解释！
修复方案：
这方面不多说，CHS数据实验室早就有成熟的视频修复方案，而且开发出了程序，直接让程序搞定结构体部分！这部分比较麻烦的就是音频块的确认，由于压缩率极高而且没有很明显的规律所以要不断调节程序，把一大堆音频HEX值分拣成一条一条的有序音频，所以这儿消耗了不少时间，当然最后的效果是极其完美的！
上图：重新生成结构体
搞定音频后，比较棘手的就是视频的逻辑长度VBR了，前边说过想要把视频块物理长度和逻辑长度对应是极其困难的，这个估计只有打包程序自己知道（采集指令是其发出，所以控制时长对它来说是很简单的事儿），经过艰难的处理，最终成功解决这个问题！
上图：修复后的效果