MP4文件分析
概述
MP4文件中的所有數(shù)據(jù)都裝在box（QuickTime中為atom）中，也就是說(shuō)MP4文件由若干個(gè)box組成，每個(gè)box有類型和長(zhǎng)度，可以將box理解為一個(gè)數(shù)據(jù)對(duì)象塊。box中可以包含另一個(gè)box，這種box稱為container box。
一個(gè)MP4文件首先會(huì)有且只有一個(gè)“ftyp”類型的box，作為MP4格式的標(biāo)志并包含關(guān)于文件的一些信息;
之后會(huì)有且只有一個(gè)“moov”類型的box（Movie Box），它是一種container box，子box包含了媒體的metadata信息；
MP4文件的媒體數(shù)據(jù)包含在“mdat”類型的box（Midia Data Box）中，該類型的box也是container box，可以有多個(gè)，也可以沒有（當(dāng)媒體數(shù)據(jù)全部引用其他文件時(shí)），媒體數(shù)據(jù)的結(jié)構(gòu)由metadata進(jìn)行描述。
文件結(jié)構(gòu)
整個(gè)文件由Box組成，所有的數(shù)據(jù)都在Box內(nèi)定義。Box可以層級(jí)嵌套，例如，moov可以包含多個(gè)trak。
aligned(8) class Box (unsigned int(32) boxtype, optional unsigned int(8)[16] extended_type)
{
unsigned int(32) size;
unsigned int(32) type = boxtype;
if (size==1)
{
unsigned int(64) largesize;
}
else if (size==0)
{
// box extends to end of file
}
if (boxtype==‘uuid’) {
unsigned int(8)[16] usertype = extended_type;
}
}
note: 就是說(shuō)一般情況下Box是以8個(gè)字節(jié)開頭，接著就是Box的數(shù)據(jù)。這個(gè)8個(gè)字節(jié)分別表示size和type。size是整個(gè)Box的字節(jié)數(shù)，含size和type本身。type是4個(gè)可讀的字符。例如:File Type Box的type就ftyp。 標(biāo)準(zhǔn)的type都是4個(gè)字符，如果要自定義的type，則需要把type設(shè)為"uuid"，然后再附上16個(gè)字符作為自定義type.
參考代碼
以一個(gè)長(zhǎng)度為10秒的MP4為例，其結(jié)構(gòu)可能如下：
type: ftyp, size: 24
type: mdat, size: 8884701
type: mdat, size: 136125
type: moov, size: 4656
- ftyp
一個(gè)ftyp對(duì)文件的類型進(jìn)行描述，指明其符合哪些格式。一般就是mp4格式了。符合本文檔的媒體類型有很多種，box條目的種類也不同，所以需要brand與compatible_brands的來(lái)說(shuō)明此文件內(nèi)的box的種類。文檔中定義了isom, avc1, iso2, mp71, iso3這些brand應(yīng)有的格式，當(dāng)解碼器在讀出其brand后，就知道該文件的格式了。
aligned(8) class FileTypeBox extends Box(‘ftyp’) {
unsigned int(32) major_brand;
unsigned int(32) minor_version;
unsigned int(32) compatible_brands[]; // to end of the box
}
- mdat
上例中有2個(gè)mdat，一個(gè)是視頻內(nèi)容、另一個(gè)音頻內(nèi)容。對(duì)于h264, aac編碼的媒體來(lái)說(shuō)，其視頻mdat中內(nèi)容是nal，對(duì)于音頻來(lái)說(shuō)，其內(nèi)容為aac的一幀。mdat中的幀依次存放，每個(gè)幀的位置、時(shí)間、長(zhǎng)度都由moov中的信息指定。可以看出，mdat是很好組建的，這種Box只含有數(shù)據(jù)。
aligned(8) class MediaDataBox extends Box(‘mdat’) {
bit(8) data[];
}
- moov
moov存放影片的所有信息，一個(gè)moov含有多個(gè)trak。通常對(duì)于一個(gè)片子來(lái)說(shuō)，就是一個(gè)視頻trak，一個(gè)音頻trak。MP4文件的重點(diǎn)也在于此。
(1) trak / tkhd
對(duì)于視頻trak，存寬、高信息；對(duì)于音頻trak，存音量信息。并不是太重要，真正初始化解碼器要靠 stsd中的信息。
(2) trak / mdia / hdlr
標(biāo)明該trak是視頻還是音頻
(3) trak / mdia / minf / stbl
所有重要的表都在這里。其中，
- stsd: 編碼器CODEC信息
- stsz: 用于sample的劃分，通常一個(gè)sample可以對(duì)應(yīng)于frame。
- stsc: 多個(gè)sample組成一個(gè)trunk，不過(guò)實(shí)際操作中可以讓一個(gè)sample直接構(gòu)成一個(gè)trunk
- stco: trunk在文件中的位置，用于定位。
- stts / ctts: 指定每個(gè)sample的PTS, DTS
(4) trak / edts / elst
把視頻分為多段segment, 每個(gè)的起始時(shí)間和時(shí)長(zhǎng)。
MP4快速拉流
參考鏈接： Optimizing MP4 Video for Fast Streaming
看這段
You can see the browser makes 3 requests before it can start playing the video. In the first request, the browser downloads the first 552 KB of the video using an [HTTP range request](https://en.wikipedia.org/wiki/Byte_serving). We can tell this by the 206 Partial Content HTTP response code, and by digging in and looking at the request headers. However the moov
atom is not there so the browser cannot start to play the video. Next, the browser requests the final 21 KB of the video file using another range request. This does contain the moov
atom, telling the browser where the video and audio streams start. Finally, the browser makes a third and final request to get the audio/video data and can start to play the video. This has wasted over half a megabyte of bandwidth and delayed the start of the video by 210 ms! Simply because the browser couldn’t find the moov
atom.
如果將moov放到最前面，可以減少兩次請(qǐng)求，moov最重要的信息包括：stsd: 編碼器CODEC信息，（音視頻類型，寬高等），所以說(shuō)，放在前面的話，如果網(wǎng)絡(luò)很差的時(shí)候，減少兩次請(qǐng)求就比較明顯了。
至于說(shuō)MP4文件在哪里調(diào)換moov的順序，可以在寫文件的時(shí)候，也可以后臺(tái)服務(wù)器轉(zhuǎn)碼.
這部分的：參考代碼
