总结TS文件格式,早在几个月前就有了这个想法,但一直拖到今天才真正准备写一篇博文来介绍。

再不介绍的话,估计几月后又要去故纸堆里翻东西了,毕竟个人笔记中总结记录的东西太多,搞不好哪天给意外弄丢了。

该系列打算写三篇,本篇是第一篇,从局外人角度看TS封装;第二篇介绍封装的细节;第三篇介绍常见兼容性问题。

1. Android的实现

  本次博文(下个博文介绍细节吧)以Android实现的MPEG2TSWriter.cpp来介绍,其包括两部分功能:ts_muxer + writer,前者是文件格式封装,

后者是写数据到文件。如果想读懂Android的实现,则需要对native层多媒体开发的基础库——foundation的实现有一定的了解,尤其是AMessage/

ALooper/AHandler/HanderReflect这些Android消息处理模型,否则,你可能都不知道函数调用到哪儿了。

  当然,为了理解消息处理模型,我特地写了一个demo,抛开文件封装的细节来验证Android的消息模型。

  同时,我也用另外一种方式,抛开Android依赖,使用C语言,实现了一个ts_muxer,参考这个开源项目(Pluto-Project中的一个子模块)。这个实现

的封装格式细节,大部分是移植Android的,当然,为了解决诸多兼容性问题,加入了我的一些优化。有需要的可以拿去,就当我是雷锋。。。

2. TS格式是什么?有什么特点?

  TS格式跟MP4格式类似,是一种视频文件封装格式(当然,内部可以有声音数据)。

  TS格式的存在,有其核心竞争力——录制中系统crash,已存入存储设备的数据,仍能回放。相反,MP4封装格式数据写入过程中,如果意外终止,

那么前面写入的数据就都废了,不能播放。

3. TS与MP4封装格式差异

  上面第2条给出了结论,但是为什么是这样的结果?答案是——封装格式差异导致其能否在中断后进行回放。

  再进行更细节解释:

  3.1. MP4这种封装格式,只有在写完最后一笔音视频帧后,由其用户发起结束封装,才能写入文件头数据。因此,假如还没写头就意外crash,

文件头自然就写不到文件中,也就不能进行播放。

  3.2. TS这种封装格式,每写入一帧数据,都会将头数据和编码数据一起打包,写入到文件中。而在播放时,即使某帧数据异常,而该帧后面的帧只要数

据正常,根据头信息,仍能抽取出该编码帧,就可以进行解码了。

  3.3. 能否播放的一个前置条件是,能否从文件中抽取完整的编码帧出来,能的话就可以恢复回放,不能的话就无法回放。

4. 一个形象的比喻

  上面第3段是用比较专业的术语来回答能否回放以及背后原因,但作为一个外行人来看,可能还是一头雾水,那么我就做个形象的比喻来讲背后的机制。

  毕业论文,我们都写过,目录整理,是在什么时候做的?

  当然是在每一个章节都仔细校对、排版完成后,才能进行!因为目录里要加入每一个章节的开始页码!

  对了,MP4就是类似一本书,用文件头记录每一帧的起始地址、大小、时间戳等信息。

  TS格式呢?其实也是类似一本书,但是这本书是特制的,现在读书的小朋友已基本不再使用了,那就是——毛笔字练习本。每一页只能写固定数量的字,

如果欲写入的一段故事内容已经完成,该页还空着几个空格,那么将这些空的地方也填充上固定字!下一个故事必须从下一页开始写起。

  而TS文件格式呢,是按照188Bytes的包来写的,一个编码帧肯定不止188个字节(aac音频帧除外),因此,一个编码帧通常打包到若干个188Bytes的

基础包中,而在解封装(demux)时,再从这若干个188Bytes基础包中抽取出来。每帧的第一个188Bytes的包,会加入一些同步字节来标记帧类型、帧时间

戳等信息,用于分割前后不同的编码帧。

5. 应用场景

  TS这种格式,通常用于误码严重的场景中,因为方便找到同步字节进行恢复。

  例如,电视台的无线信号,传到家用电视机里,由于信道不稳定,可能产生了误码,这个没事,干脆就把该帧数据丢掉不要即可,等到检测到下一帧的

同步起始包,再进行新包的数据提取。再比如,行车记录仪类产品,一般也用该封装格式,当撞车发生时,记录仪设备可能瞬间物理损坏,如果是mp4格式,

则不能查看事故前的视频图像。