mp4文件格式解析（一） (2010-09-01 17:55:04) 转载原文 标签： http://blog.sina.com.cn/s/blog_46460bb30100ke59.html 分类： 多媒体文件标准解析 原文地址：mp4文件格式解析（一）作者：可下人间 目前MP4的概念被炒得很火，也很乱。最开始MP4指的是音频（MP3的升级版），即MPEG-2 AAC标准。随后MP4概念被转移到视频上，对应的是MPEG-4标准。而现在我们流行的叫法，多半是指能播放MPEG-4标准编码格式视频的播放器。但是这篇文章介绍的内容跟上面这些都无关，我们要讨论的是MP4文件封装格式，对应的标准为ISO/IEC 14496-12，即信息技术 视听对象编码的第12部分：ISO 基本媒体文件格式（Information technology Coding of audio-visual objects Part 12: ISO base media file format）。ISO/IEC组织指定的标准一般用数字表示，ISO/IEC 14496即MPEG-4标准。 MP4视频文件封装格式是基于QuickTime容器格式定义的，因此参考QuickTime的格式定义对理解MP4文件格式很有帮助。MP4文件格式是一个十分开放的容器，几乎可以用来描述所有的媒体结构，MP4文件中的媒体描述与媒体数据是分开的，并且媒体数据的组织也很自由，不一定要按照时间顺序排列，甚至媒体数据可以直接引用其他文件。同时，MP4也支持流媒体。MP4目前被广泛用于封装h.264视频和AAC音频，是高清视频的代表。 现在我们就来看看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”。 4.1 Movie Header Box（mvhd） “mvhd”结构如下表。 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 creation time 4 创建时间（相对于UTC时间1904-01-01零点的秒数） modification time 4 修改时间 time scale 4 文件媒体在1秒时间内的刻度值，可以理解为1秒长度的时间单元数 duration 4 该track的时间长度，用duration和time scale值可以计算track时长，比如audio track的time scale = 8000, duration = 560128，时长为70.016，video track的time scale = 600, duration = 42000，时长为70 rate 4 推荐播放速率，高16位和低16位分别为小数点整数部分和小数部分，即[16.16] 格式，该值为1.0（0x00010000）表示正常前向播放 volume 2 与rate类似，[8.8] 格式，1.0（0x0100）表示最大音量 reserved 10 保留位 matrix 36 视频变换矩阵 pre-defined 24 next track id 4 下一个track使用的id号 “mvhd”的字节实例如下图，各字段已经用颜色区分开： 4.2 Track Box（trak） “trak”也是一个container box，其子box包含了该track的媒体数据引用和描述（hint track除外）。一个MP4文件中的媒体可以包含多个track，且至少有一个track，这些track之间彼此独立，有自己的时间和空间信息。“trak”必须包含一个“tkhd”和一个“mdia”，此外还有很多可选的box（略）。其中 “tkhd”为track header box，“mdia”为media box，该box是一个包含一些track媒体数据信息box的container box。 “trak”的部分字节实例如下图，其中黄色为“trak”box的头，绿色为“tkhd”，蓝色为“edts”（一个可选box），红色为一部分“mdia”。 mp4文件格式解析（二） (2010-07-15 21:26:59) 转载 标签： mp4 it 分类： 工作•开发 4.2.1 Track Header Box（tkhd） “tkhd”结构如下表。 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 按位或操作结果值，预定义如下： 0x000001 track_enabled，否则该track不被播放； 0x000002 track_in_movie，表示该track在播放中被引用； 0x000004 track_in_preview，表示该track在预览时被引用。 一般该值为7，如果一个媒体所有track均未设置track_in_movie和track_in_preview，将被理解为所有track均设置了这两项；对于hint track，该值为0 creation time 4 创建时间（相对于UTC时间1904-01-01零点的秒数） modification time 4 修改时间 track id 4 id号，不能重复且不能为0 reserved 4 保留位 duration 4 track的时间长度 reserved 8 保留位 layer 2 视频层，默认为0，值小的在上层 alternate group 2 track分组信息，默认为0表示该track未与其他track有群组关系 volume 2 [8.8] 格式，如果为音频track，1.0（0x0100）表示最大音量；否则为0 reserved 2 保留位 matrix 36 视频变换矩阵 width 4 宽 height 4 高，均为 [16.16] 格式值，与sample描述中的实际画面大小比值，用于播放时的展示宽高 “tkhd”的字节实例如下图，各字段已经用颜色区分开： 4.2.2 Media Box（mdia） “mdia”也是个container box，其子box的结构和种类还是比较复杂的。先来看一个“mdia”的实例结构树图。 总体来说，“mdia”定义了track媒体类型以及sample数据，描述sample信息。一般“mdia”包含一个“mdhd”，一个“hdlr”和一个“minf”，其中“mdhd”为media header box ，“hdlr”为handler reference box，“minf”为media information box。下面依次看一下这几个box的结构。 4.2.2.1 Media Header Box（mdhd） “mdhd”结构如下表。 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 creation time 4 创建时间（相对于UTC时间1904-01-01零点的秒数） modification time 4 修改时间 time scale 4 同前表 duration 4 track的时间长度 language 2 媒体语言码。最高位为0，后面15位为3个字符（见ISO 639-2/T标准中定义） pre-defined 2 “mdhd”的字节实例如下图，各字段已经用颜色区分开： 4.2.2.2 Handler Reference Box（hdlr） “hdlr”解释了媒体的播放过程信息，该box也可以被包含在meta box（meta）中。“hdlr”结构如下表。 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 pre-defined 4 handler type 4 在media box中，该值为4个字符： “vide”— video track “soun”— audio track “hint”— hint track reserved 12 name 不定 track type name，以‘\0’结尾的字符串 “hdlr”的字节实例如下图，各字段已经用颜色区分开： 4.2.2.3 Media Information Box（minf） “minf”存储了解释track媒体数据的handler-specific信息，media handler用这些信息将媒体时间映射到媒体数据并进行处理。“minf”中的信息格式和内容与媒体类型以及解释媒体数据的media handler密切相关，其他media handler不知道如何解释这些信息。 “minf”是一个container box，其实际内容由子box说明。 一般情况下，“minf”包含一个header box，一个“dinf”和一个“stbl”，其中，header box根据track type（即media handler type）分为“vmhd”、“smhd”、“hmhd”和“nmhd”，“dinf”为data information box，“stbl”为sample table box。下面分别介绍。 下图为“minf”部分字节实例，其中红色为box header，蓝色为“smhd”，绿色为“dinf”，黄色为一部分“stbl”。 mp4文件格式解析（三） (2010-07-15 21:48:21) 转载 标签： mp4 it 分类： 工作•开发 4.2.2.3.1 Media Information Header Box（vmhd、smhd、hmhd、nmhd） Video Media Header Box（vmhd） 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 graphics mode 4 视频合成模式，为0时拷贝原始图像，否则与opcolor进行合成 opcolor 2×3 ｛red，green，blue｝ Sound Media Header Box（smhd） 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 balance 2 立体声平衡，[8.8] 格式值，一般为0，-1.0表示全部左声道，1.0表示全部右声道 reserved 2 Hint Media Header Box（hmhd） 略 Null Media Header Box（nmhd） 非视音频媒体使用该box，略。 4.2.2.3.2 Data Information Box（dinf） “dinf”解释如何定位媒体信息，是一个container box。“dinf”一般包含一个“dref”，即data reference box；“dref”下会包含若干个“url”或“urn”，这些box组成一个表，用来定位track数据。简单的说，track可以被分成若干段，每一段都可以根据“url”或“urn”指向的地址来获取数据，sample描述中会用这些片段的序号将这些片段组成一个完整的track。一般情况下，当数据被完全包含在文件中时，“url”或“urn”中的定位字符串是空的。 “dref”的字节结构如下表。 字段 字节数 意义 box size 4 box大小 box type 4 box类型 version 1 box版本，0或1，一般为0。（以下字节数均按version=0） flags 3 entry count 4 “url”或“urn”表的元素个数 “url”或“urn”列表 不定 “url”或“urn”都是box，“url”的内容为字符串（location string），“urn”的内容为一对字符串（name string and location string）。当“url”或“urn”的box flag为1时，字符串均为空。 下面是一个“dinf”的字节实例图。其中黄色为“dinf”的box header，由红色部分我们知道包含的“url”或“urn”个数为1，红色后面为“url”box的内容。紫色为“url”的box header（根据box type我们知道是个“url”），绿色为box flag，值为1，说明“url”中的字符串为空，表示track数据已包含在文件中。 4.2.2.3.3 Sample Table Box（stbl） “stbl”几乎是普通的MP4文件中最复杂的一个box了，首先需要回忆一下sample的概念。sample是媒体数据存储的单位，存储在media的chunk中，chunk和sample的长度均可互不相同，如下图所示。 “stbl”包含了关于track中sample所有时间和位置的信息，以及sample的编解码等信息。利用这个表，可以解释sample的时序、类型、大小以及在各自存储容器中的位置。“stbl”是一个container box，其子box包括：sample description box（stsd）、time to sample box（stts）、sample size box（stsz或stz2）、sample to chunk box（stsc）、chunk offset box（stco或co64）、composition time to sample box（ctts）、sync sample box（stss）等。 “stsd”必不可少，且至少包含一个条目，该box包含了data reference box进行sample数据检索的信息。没有“stsd”就无法计算media sample的存储位置。“stsd”包含了编码的信息，其存储的信息随媒体类型不同而不同。 Sample Description Box（stsd） box header和version字段后会有一个entry count字段，根据entry的个数，每个entry会有type信息，如“vide”、“sund”等，根据type不同sample description会提供不同的信息，例如对于video track，会有“VisualSampleEntry”类型信息，对于audio track会有“AudioSampleEntry”类型信息。 视频的编码类型、宽高、长度，音频的声道、采样等信息都会出现在这个box中。 Time To Sample Box（stts） “stts”存储了sample的duration，描述了sample时序的映射方法，我们通过它可以找到任何时间的sample。“stts”可以包含一个压缩的表来映射时间和sample序号，用其他的表来提供每个sample的长度和指针。表中每个条目提供了在同一个时间偏移量里面连续的sample序号，以及samples的偏移量。递增这些偏移量，就可以建立一个完整的time to sample表。 Sample Size Box（stsz） “stsz” 定义了每个sample的大小，包含了媒体中全部sample的数目和一张给出每个sample大小的表。这个box相对来说体积是比较大的。 Sample To Chunk Box（stsc） 用chunk组织sample可以方便优化数据获取，一个thunk包含一个或多个sample。“stsc”中用一个表描述了sample与chunk的映射关系，查看这张表就可以找到包含指定sample的thunk，从而找到这个sample。 Sync Sample Box（stss） “stss”确定media中的关键帧。对于压缩媒体数据，关键帧是一系列压缩序列的开始帧，其解压缩时不依赖以前的帧，而后续帧的解压缩将依赖于这个关键帧。“stss”可以非常紧凑的标记媒体内的随机存取点，它包含一个sample序号表，表内的每一项严格按照sample的序号排列，说明了媒体中的哪一个sample是关键帧。如果此表不存在，说明每一个sample都是一个关键帧，是一个随机存取点。 Chunk Offset Box（stco） “stco”定义了每个thunk在媒体流中的位置。位置有两种可能，32位的和64位的，后者对非常大的电影很有用。在一个表中只会有一种可能，这个位置是在整个文件中的，而不是在任何box中的，这样做就可以直接在文件中找到媒体数据，而不用解释box。需要注意的是一旦前面的box有了任何改变，这张表都要重新建立，因为位置信息已经改变了。 mp4文件格式解析（四） (2010-07-15 22:04:13) 转载 标签： mp4 it 分类： 工作•开发 5、Free Space Box（free或skip） “free”中的内容是无关紧要的，可以被忽略。该box被删除后，不会对播放产生任何影响。 6、Meida Data Box（mdat） 该box包含于文件层，可以有多个，也可以没有（当媒体数据全部为外部文件引用时），用来存储媒体数据。数据直接跟在box type字段后面，具体数据结构的意义需要参考metadata（主要在sample table中描述）。 普通MP4文件的结构就讲完了，可能会比较乱，下面这张图是常见的box的树结构图，可以用来大致了解MP4文件的构造。 这篇文章主要面向一些对MP4文件结构没有太多了解的初学者，算是篇比较初级的文章，本人也是参考了一些资料写出来的，对于MP4文件中涉及的一些概念没有太深入的了解，因此其中应该是有一些错误理解，希望大家抱着批判的眼光读这篇文章。如果有错误的地方，还请大家不吝赐教。该文主要参考了标准和网友wqyuwss的blog系列文章：mp4文件格式 当前位置: 主页>流媒体开发>音视频编解码> MP4文件格式分析 时间:2010-07-22 11:02来源:CSDN博客 作者:落鹤生 点击: 1659次 [mp4文件格式]获取mp4文件信息 - 计算电影长度,计算电影图像宽度和高度,计算电影声音采样频率,查找sample,查找关键帧 收藏到： TAG: mp4 [mp4文件格式]获取mp4文件信息1 - 计算电影长度 方法1 从mvhd - movie header atom中找到time scale和duration，duration除以time scale即是整部电影的长度。 time scale相当于定义了标准的1秒在这部电影里面的刻度是多少。 例如audio track的time scale = 8000, duration = 560128，所以总长度是70.016，video track的time scale = 600, duration = 42000，所以总长度是70 方法2 首先计算出共有多少个帧，也就是sample（从sample size atoms中得到），然后 整部电影的duration = 每个帧的duration之和（从Time-to-sample atoms中得出） 例如audio track共有547个sample，每个sample的长度是1024，则总duration是560128，电影长度是70.016；video track共有1050个sample，每个sample的长度是40，则总duration是42000，电影长度是70 [mp4文件格式]获取mp4文件信息2 - 计算电影图像宽度和高度 从tkhd – track header atom中找到宽度和高度即是。 [mp4文件格式]获取mp4文件信息3 - 计算电影声音采样频率 从tkhd – track header atom中找出audio track的time scale即是声音的采样频率。 [mp4文件格式]获取mp4文件信息6 - 查找sample 当播放一部电影或者一个track的时候，对应的media handler必须能够正确的解析数据流，对一定的时间获取对应的媒体数据。如果是视频媒体， media handler可能会解析多个atom，才能找到给定时间的sample的大小和位置。具体步骤如下： 1．确定时间，相对于媒体时间坐标系统 2．检查time-to-sample atom来确定给定时间的sample序号。 3．检查sample-to-chunk atom来发现对应该sample的chunk。 4．从chunk offset atom中提取该trunk的偏移量。 5．利用sample size atom找到sample在trunk内的偏移量和sample的大小。 例如，如果要找第1秒的视频数据，过程如下： 1． 第1秒的视频数据相对于此电影的时间为600 2． 检查time-to-sample atom，得出每个sample的duration是40，从而得出需要寻找第600/40 = 15 + 1 = 16个sample 3． 检查sample-to-chunk atom，得到该sample属于第5个chunk的第一个sample，该chunk共有4个sample 4． 检查chunk offset atom找到第5个trunk的偏移量是20472 5． 由于第16个sample是第5个trunk的第一个sample，所以不用检查sample size atom，trunk的偏移量即是该sample的偏移量20472。如果是这个trunk的第二个sample，则从sample size atom中找到该trunk的前一个sample的大小，然后加上偏移量即可得到实际位置。 6． 得到位置后，即可取出相应数据进行解码，播放 [mp4文件格式]获取mp4文件信息7 - 查找关键帧 查找过程与查找sample的过程非常类似，只是需要利用sync sample atom来确定key frame的sample序号 确定给定时间的sample序号 检查sync sample atom来发现这个sample序号之后的key frame 检查sample-to-chunk atom来发现对应该sample的chunk 从chunk offset atom中提取该trunk的偏移量 利用sample size atom找到sample在trunk内的偏移量和sample的大小 MP4文件格式的解析，以及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文件的分割算法 所谓“分割”，就是把大文件切成小文件，要实现mp4的分割， · 首先，需要获取到关键帧列表 · 然后，选择要分割的时间段（比如从关键帧开始） · 接着，重新生成moov box（注意所有相关的box 以及 box size都需要改变） · 最后，拷贝对应的数据，生成新文件 第一点，上面已经介绍了，第二点，只需要遍历关键帧列表，就能找到离你想要分割的时间段最接近的关键帧，第四点就是“copy-paste”的工作，关键在于第三点。因为这一步涉及到stbl下的所有box，必须重新生成entrys，同样的，其他的box都还好，只需要保留关键帧所对应的sample和chunk，其余的删掉即可，只是stsc box的比较麻烦，说起来比较啰嗦，还是直接看代码吧： 修改完box之后，需要重新生成moov box，由于moov box的大小以及时长等信息都发生了改变，所以需要box的大小做相应的修改，这点千万不能忘记，否则播放器会解析错误。重新生成box之后，还要计算一下分割后的数据的长度，由于数据长度也发生了改变，所以修改mdat box的大小的同时，要同时修改stbl下所有box的chunk offset，切记！ 以下是整个的逻辑过程： 好了，所有这些都实现之后，就具备了做mp4点播系统的条件了。不过，要做mp4点播，还有一些其他的问题需要解决，我将在下一篇文章中介绍。 Hint tracks are a series of instructions in a mp4 container file that tell a server how to transmit packets. Hint tracks always refer to another track, most likely an audio or video media track. This series of instructions tells the server when to send the packet, what type of RTP header to add, if there is any extra data in the packet, and how much data to send in the packet. To save on space, a hint can contain a pointer to the media track, instead of duplicating that data. It will also tell what SDP to add for the track that is referenced. So, a file that is hinted should have a media track, and an associated hint track for that media track. There are some mp4 container files that just have hint tracks - these are called "fat hints " and are usually not playable locally. These are illegal in ISMA, so we won 't talk about them. To create hint tracks for a mp4 file is fairly simple with the mp4creator program. Just execute the: mp4creator -hint=