ts视频恢复方法

TS流是早些年QT类流行之前的一种视频分包解决方案，一般采用264视频编码的比较多，早期用于电视台的信号传播，因为那个年代信号传播一直不太稳定，所以这类结构的视频更多的考虑两个因素，1、分包；2、容错性。

分包的概念很好理解，方便传输，方便校验，所以包长度不能太长，否则容易导致丢包，所以TS包被限定在188字节，可能现在来看太小了，但在当初这个方案已经是优化过的；有关容错性说直白点就是前帧的错误不要影响到后帧，在这当时也是很先进的理念，前帧解析出错直接舍弃，但是要保证后帧的解析正常。TS可以说是一种淘汰的方案，早些年索尼和佳能有做过MTS类的视频可以看成是TS的一个变体，现在已经很少能遇到这种结构的视频了。因为QT类的如MP4 MOV等很好的解决这些问题，而且方案比TS要优秀的多！好了讲了这么多概念性的东西，下面来看看今天这个案例。

故障存储:U盘 32G /FAT32

故障现象:

这个U盘用在某款汽车上，做为行车记录仪的存储设备，估计可能是车机来进行控制，提供前、后、左、右四路摄像机采集画面。出事故后回看视频发现少了一段，于是找到们进行恢复。

故障分析:

多路的同时写入一般存在排队，所以会导致碎片化，只不过区别是不同的方案可能碎片数量不一样。如果要保证各路传输过来的信号能够尽快的“同步”写入，这个时候碎片数量会多，因为排队的数据块会更小；反之则数据块更大但是延迟会严重，可能会导致A写了20%，B才写入10%。不同的方案，效果不一样。回到这个案例，其碎片数量不算多，以下是一个正常文件的碎片列表。

还有一点比较奇怪的是格式为TS,但是厂家还是固执的给标识成MP4，这个有点儿挂羊头卖狗肉的感觉了。因为对比QT类和TS类，前者肯定对管理程序的软、硬件要求更高，编码和解码的开销也更大，当然效果是更好的。所我想厂家在开发时可能也在QT类和TS类之间犹豫过，最终选择了更容易、更老的TS类，但是文件扩展名却保留了MP4。

故障处理:

TS类的之前就处理过不少，写过程序，不过发现由于TS类本身就允许很多自定义值的添加，相对比较宽松，所以导致不同厂家对一些自定义值改动比较大，所以不同的厂家还是需要对程序进行微调才能实现，不具备通用性。基于以上考虑就是遇到不同方案就进行程序的改写，这仅仅是碎片定位方案。重组方案更是如此，不断的变化中，效果也不能达到像QT类那般“丝滑“， 这一切都是TS的结构导致的，所以没办法只能遇到不同的案例进行不同的处理。以下为程序处理这个案例的一个效果图，程序具体了碎片定位和重组功能，重组的功能目前还是不太好，只能说勉强够用。

最终找到了29G多的数据，可以看到这是一个四路的鱼眼视频，对比查看后没有发现客户要的数据，根据上下文件名我个人推测可能在录制上出现问题导致终端没有写入成功。因为其使用的是大块的方案，这种方案还是风险较大的，一旦某个块传输出问题可能会导致后续的块都写入出错。

这就是TS记录仪的恢复方法，大家在遇到此类问题时，可以和我们联系。