流媒体之MP4码流解析。
mp4应该算是一种比较复杂的媒体格式了，起源于QuickTime。以前研究的时候就花了一番的功夫，尤其是如何把它完美的融入到视频点播应用中，更是费尽了心思，主要问题是处理mp4文件庞大的“媒体头”。当然，流媒体点播也可以采用flv格式来做，flv也可以封装H.264视频数据的，不过Adobe却不推荐这么做，人家说毕竟mp4才是H.264最佳的存储格式嘛。
这几天整理并重构了一下mp4文件的解析程序，融合了分解与合并的程序，以前是C语言写的，应用在Linux上运行的服务器程序上，现在改成c++，方便我在其他项目中使用它，至于用不用移植一份c#的，暂时用不到，等有必要了再说吧。这篇文章先简单介绍一下mp4文件的大体结构，以及它的分割算法，之后再写文章介绍如何把mp4完美应用在点播项目中。
一、MP4格式分析
MP4(MPEG-4 Part 14)是一种常见的多媒体容器格式，它是在“ISO/IEC 14496-14”标准文件中定义的，属于MPEG-4的一部分，是“ISO/IEC 14496-12(MPEG-4 Part 12 ISO base media file format)”标准中所定义的媒体格式的一种实现，后者定义了一种通用的媒体文件结构标准。MP4是一种描述较为全面的容器格式，被认为可以在其中嵌入任何形式的数据，各种编码的视频、音频等都不在话下，不过我们常见的大部分的MP4文件存放的AVC(H.264)或MPEG-4(Part 2)编码的视频和AAC编码的音频。MP4格式的官方文件后缀名是“.mp4”，还有其他的以mp4为基础进行的扩展或者是缩水版本的格式，包括：M4V, 3GP, F4V等。
mp4是由一个个“box”组成的，大box中存放小box，一级嵌套一级来存放媒体信息。box的基本结构是：
其中，size指明了整个box所占用的大小，包括header部分。如果box很大(例如存放具体视频数据的mdat box)，超过了uint32的最大数值，size就被设置为1，并用接下来的8位uint64来存放大小。
一个mp4文件有可能包含非常多的box，在很大程度上增加了解析的复杂性，这个网页上http://mp4ra.org/atoms.html记录了一些当前注册过的box类型。看到这么多box，如果要全部支持，一个个解析，怕是头都要爆了。还好，大部分mp4文件没有那么多的box类型，下图就是一个简化了的，常见的mp4文件结构：
一般来说，解析媒体文件，最关心的部分是视频文件的宽高、时长、码率、编码格式、帧列表、关键帧列表，以及所对应的时戳和在文件中的位置，这些信息，在mp4中，是以特定的算法分开存放在stbl box下属的几个box中的，需要解析stbl下面所有的box，来还原媒体信息。下表是对于以上几个重要的box存放信息的说明：
看吧，要获取到mp4文件的帧列表，还挺不容易的，需要一层层解析，然后综合stts stsc stsz stss stco等这几个box的信息，才能还原出帧列表，每一帧的时戳和偏移量。而且，你要照顾可能出现或者可能不出现的那些box。。。可以看的出来，mp4把帧sample进行了分组，也就是chunk，需要间接的通过chunk来描述帧，这样做的理由是可以压缩存储空间，缩小媒体信息所占用的文件大小。这里面，stsc box的解析相对来说比较复杂，它用了一种巧妙的方式来说明sample和chunk的映射关系，特别介绍一下。
这是stsc box的结构，前几项的意义就不解释了，可以看到stsc box里每个entry结构体都存有三项数据，它们的意思是：“从first_chunk这个chunk序号开始，每个chunk都有samples_per_chunk个数的sample，而且每个sample都可以通过sample_description_index这个索引，在stsd box中找到描述信息”。也就是说，每个entry结构体描述的是一组chunk，它们有相同的特点，那就是每个chunk包含samples_per_chunk个sample，好，那你要问，这组相同特点的chunk有多少个？请通过下一个entry结构体来推算，用下一个entry的first_chunk减去本次的first_chunk，就得到了这组chunk的个数。最后一个entry结构体则表明从该first_chunk到最后一个chunk，每个chunk都有sampls_per_chunk个sample。很拗口吧，不过，就是这个意思:)。由于这种算法无法得知文件所有chunk的个数，所以你必须借助于stco或co64。直接上代码可能会清楚些：
1. 首先直接分析entry
2. 然后，通过stco或co64获知chunk总个数之后，开始还原映射表
读出stsc之后，就可以综合stbl下的所有box，推算出视频和音频帧列表，时戳和偏移量等数据。下面截图展示获取到的关键帧列表：
有了关键帧列表之后，就可以继续我们一下个题目，就是mp4文件的分割。实现mp4的分割，是把mp4应用到点播系统中最关键的技术环节，做不到这个，就无法实现点播播放mp4影片的“拖动”。
现在我们就来看看MP4文件格式到底是什么样的。
1、概述
MP4文件中的所有数据都装在box（QuickTime中为atom）中，也就是说MP4文件由若干个box组成，每个box有类型和长度，可以将box理解为一个数据对象块。box中可以包含另一个box，这种box称为container box。一个MP4文件首先会有且只有一个“ftyp”类型的box，作为MP4格式的标志并包含关于文件的一些信息；之后会有且只有一个“moov”类型的box（Movie Box），它是一种container box，子box包含了媒体的metadata信息；MP4文件的媒体数据包含在“mdat”类型的box（Midia Data Box）中，该类型的box也是container box，可以有多个，也可以没有（当媒体数据全部引用其他文件时），媒体数据的结构由metadata进行描述。
下面是一些概念：
track 表示一些sample的集合，对于媒体数据来说，track表示一个视频或音频序列。
hint track 这个特殊的track并不包含媒体数据，而是包含了一些将其他数据track打包成流媒体的指示信息。
sample 对于非hint track来说，video sample即为一帧视频，或一组连续视频帧，audio sample即为一段连续的压缩音频，它们统称sample。对于hint track，sample定义一个或多个流媒体包的格式。
sample table 指明sampe时序和物理布局的表。
chunk 一个track的几个sample组成的单元。
在本文中，我们不讨论涉及hint的内容，只关注包含媒体数据的本地MP4文件。下图为一个典型的MP4文件的结构树。
2、Box
首先需要说明的是，box中的字节序为网络字节序，也就是大端字节序（Big-Endian），简单的说，就是一个32位的4字节整数存储方式为高位字节在内存的低端。Box由header和body组成，其中header统一指明box的大小和类型，body根据类型有不同的意义和格式。
标准的box开头的4个字节（32位）为box size，该大小包括box header和box body整个box的大小，这样我们就可以在文件中定位各个box。如果size为1，则表示这个box的大小为large size，真正的size值要在largesize域上得到。（实际上只有“mdat”类型的box才有可能用到large size。）如果size为0，表示该box为文件的最后一个box，文件结尾即为该box结尾。（同样只存在于“mdat”类型的box中。）
size后面紧跟的32位为box type，一般是4个字符，如“ftyp”、“moov”等，这些box type都是已经预定义好的，分别表示固定的意义。如果是“uuid”，表示该box为用户扩展类型。如果box type是未定义的，应该将其忽略。
3、File Type Box（ftyp）
该box有且只有1个，并且只能被包含在文件层，而不能被其他box包含。该box应该被放在文件的最开始，指示该MP4文件应用的相关信息。
“ftyp” body依次包括1个32位的major brand（4个字符），1个32位的minor version（整数）和1个以32位（4个字符）为单位元素的数组compatible brands。这些都是用来指示文件应用级别的信息。该box的字节实例如下：
4、Movie Box（moov）
该box包含了文件媒体的metadata信息，“moov”是一个container box，具体内容信息由子box诠释。同File Type Box一样，该box有且只有一个，且只被包含在文件层。一般情况下，“moov”会紧随“ftyp”出现。
一般情况下（限于篇幅，本文只讲解常见的MP4文件结构），“moov”中会包含1个“mvhd”和若干个“trak”。其中“mvhd”为header box，一般作为“moov”的第一个子box出现（对于其他container box来说，header box都应作为首个子box出现）。“trak”包含了一个track的相关信息，是一个container box。下图为部分“moov”的字节实例，其中红色部分为box header，绿色为“mvhd”，黄色为一部分“trak”。
