1. 概覽
常用的一些Box
mdhd 存放視頻流創建時間，長度等信息
avc1 視頻寬高、extionsion中有sps、pps信息（關於avcC和esds）
esds：aac音頻頭信息、視頻vos、vo頭信息（參考）
stts：定義每個sample時長（+參考）
stsc：sample-chunk映射表
stsz：指定了每個sample的size
stco、co64：Chunk位置偏移表，指定了每個chunk在文件中的位置（參考）
elst：使某個track的時間戳產生偏移。較少見，參考
mp4a：另有mp4v，不同的mp4分支。
主流編碼器的比較
以下是一個典型的mp4格式的文件。后面將逐行分析格式規范。
2. 詳解
下面的內容翻譯自 ISO_IEC_14496-12。
2.1 Box的概念
Box以一個header開頭，它提供了 size 和 type。ftpy Box Header 支持壓縮或擴展大小（32或64位，可變）以及壓縮、擴展類型（32位或完整的通用唯一標識符，即UUID）。標准的Box都使用緊湊型（32位），大多數Box都使用緊湊型（32位）大小。通常只有媒體數據框需要64位大小。
大小是整個Box的大小（包括size、type、header）、字段和所有包含的框。這有助於文件的一般解析。
語法：
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; } }
size：整型，為整個Box的大小（包含子Box），如果size是1，則使用largesize表示更大的范圍（8字節），如果size是0則此Box作為文件中最后一個Box，范圍直至文件末尾（only used for a Media Data Box）。
type：用來標識Box的類型，標准Box使用四個可打印字節表示，以便於識別。用戶擴展使用擴展類型，在本例中，類型字段設置為“UUID”：
aligned(8) class FullBox(unsigned int(32) boxtype, unsigned int(8) v, bit(24) f)
extends Box(boxtype) { unsigned int(8) version = v; bit(24) flags = f; }
應忽略和跳過未識別類型的Box。許多對象還包含 version number 和 flag 字段。
這兩個字段的語義是：version是一個整數，指定此格式的框的版本。flag 是 flags 的映射。應忽略和跳過未識別版本的Box。
2.2 ftyp
全稱File Type Box，該Box必須位於文件開頭（如果有的話）。為了兼容早期的規范，沒有寫入ftyp Box的文件應該被視為包含 Major_brand='mp41', minor_version=0 和單向兼容版本 mp41。
按照本規范的這一部分構建的媒體文件可能與多個詳細 spec 兼容，因此不可能總是針對文件使用單一的 type 或 brand。這意味着文件擴展名和多用途Internet郵件擴展名（MIME）type 的實用性有所降低。
此 Box 必須盡早放置在文件中（例如，在任何強制性簽名之后，但在任何重要的可變大小的Box（如Movie Box、Media Box 或 Free Space）之前。它標識哪種 spec 是解析該文件的“最佳方式”，以及該 spec 的次要版本；以及該文件所遵循的一組其他 spec。實現此格式的讀取器應嘗試讀取標記為與讀取器實現的任何規范兼容的文件。因此，規范中的任何不兼容更改都應注冊新的 “brand” 標識符，以標識符合新的 spec 的文件。（每種視頻文件的Box都有自己的規范、版本號，要在ftyp里面標識才能被解復用器正確解讀）。
次版本僅供參考。它不適用於兼容品牌，也不能用於確定文件是否符合標准。它可以更精確地識別主要規范，以便檢查、調試或改進解碼。文件通常在外部標識（例如，使用文件擴展名或MIME類型），以標識“最佳方式”（主要brand），或作者認為能夠提供最大兼容性的brand。（每個廠商有自己的brand-品牌，對於用戶來說只有Major_brand才是有意義的，minor_version的意義不大）。
本規范本節未定義任何 brand。但是下文第6.3節中有關於符合整個文件的 brand 的 spec 規范，而不僅僅是本節。本規范中定義的所有文件格式 brand 均包含在附錄E中，並概述了其所需的功能。
語法：
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 }
此 Box 標識此文件符合的規范。每個 brand 都是一個可打印的四字符代碼，在ISO注冊，用於識別精確的spec。
major_brand：主要品牌–是品牌標識；
minor_brand：是主要品牌的次要版本的信息，整數；
compatible_brands：是一個列表，在Box的最后，是一個brand。
下面，可見前32字節（0X20）是該Box的全部信息：
注意：文件通常是自包含的，不引用其它文件中的媒體。
2.3 流媒體
當准備流式傳輸時，文件必須包含信息，以便在發送信息的過程中指導流式服務器。此外，如果將這些指令和媒體數據交錯，以便在提供演示文稿時避免過度查找，這是很有幫助的。同樣重要的是，原始媒體數據應完好無損地保留，以便文件可以被驗證、重新編輯或以其他方式重新使用。最后，如果可以為多個協議准備一個單獨的文件，那么這很有幫助，因此不同的服務器可以在不同的協議上使用它。
2.4 本地展示
“本地”查看演示文稿（即直接從文件中查看，而不是通過流式互連）是一個重要的應用場景；在分發演示文稿時（例如在CD或DVD ROM上）、在開發過程中以及在流式服務器上驗證內容時使用。必須支持這種本地查看，並提供完全隨機訪問。如果演示文稿是在CD或DVD ROM上，交錯（interleave）是很重要的，因為查找可能很慢。
2.5 流式傳輸
當服務器從文件操作以生成流時，生成的流必須符合所用協議的規范，並且不應在文件本身中包含文件格式信息的蹤跡。服務器需要能夠隨機訪問演示文稿。通過引用來自多個演示文稿中的相同媒體數據來重新使用服務器內容（例如，摘錄-excerpts）是有用的；如果媒體數據可以在只讀媒體（例如CD）上，並且在准備流式處理時不進行復制，而只是進行擴充，則它還可以幫助流式處理。
下圖顯示了為通過多路復用協議進行流式傳輸而准備的演示文稿，只需要一個提示軌跡（ hint track）：
注意：hint trak 也是一種 trak，記錄前一個audio、video。
3. 設計原則
文件結構是面向對象的；文件可以很簡單地分解為組成對象，對象的結構直接從它們的類型中推斷出來。
媒體數據不受文件格式的“框架”約束；提供媒體數據單元大小、類型和位置的文件格式聲明在物理上與媒體數據不相鄰。這使得可以將媒體數據子集化，並在其自然狀態下使用它，而不需要復制它來為幀留出空間。元數據用於通過引用而不是通過包含來描述媒體數據。
類似地，特定流協議的協議信息不受媒體數據的“框架”（framed）約束；協議頭在物理上與媒體數據不相鄰。相反，可以通過引用包含媒體數據。這使得在自然狀態下表示媒體數據成為可能，而不傾向於任何一種協議。它還使得同一組媒體數據可以用於本地表示和多個協議。
協議信息的構建方式使得流媒體服務器只需要知道協議及其發送方式；協議信息抽象了媒體的知識，因此服務器在很大程度上是媒體類型不可知的。類似地，媒體數據以不知道協議的方式存儲，使媒體工具不受協議影響。（總的來講，也就是協議和數據分離）。
文件格式不要求單個演示文稿位於單個文件中。這將啟用內容的 sub-setting 和 re-use。與 no-framing 方法相結合時，還可以將媒體數據包含在未按本規范格式化的文件中（例如，僅包含媒體數據而不包含聲明性信息的“原始”文件，或已在媒體或計算機行業使用的文件格式）。（no framed -> non-framing）。
文件格式基於一組常見的設計和一組豐富的可能的結構和用法。相同的格式適用於所有用途；不需要翻譯。但是，當以特定方式使用時（例如，用於本地呈現），文件可能需要以特定方式進行結構化以獲得最佳使用方式（例如，數據的時間順序）。本規范未定義規范性結構規則，除非使用限制性外形。（這里就講的大概就是復用，解復用的概念）。
4.0 文件結構
演示文稿可能包含在多個文件中。一個文件包含整個演示文稿的元數據，並按照此規范進行格式化。此文件還可能包含所有媒體數據，因此演示文稿是自包含的。其他文件（如果使用）不需要格式化為本規范；它們用於包含媒體數據，也可能包含未使用的媒體數據或其他信息。本規范僅涉及表示文件的結構。媒體數據文件的格式僅受本規范的約束，因為媒體文件中的媒體數據必須能夠通過此處定義的元數據進行描述。
這些其他文件可以是ISO文件、圖像文件或其他格式。只有媒體數據本身，如JPEG 2000圖像，存儲在這些其他文件中；所有定時和幀（位置和大小）信息都在ISO基本媒體文件中，因此輔助文件基本上是自由格式的。
如果一個ISO文件包含提示磁道，則引用生成提示的媒體數據的媒體磁道應保留在該文件中，即使其中的數據不是由提示磁道直接引用的；刪除所有提示磁道后，整個未提示的表示應保留在文件中。請注意，媒體磁道可能會引用外部文件以獲取其媒體數據。
附件A提供了一個信息豐富的介紹，可能對初次閱讀者有所幫助。
總之：大概只有在CD/DVD種才會用到外部數據。
4.1 對象結構
文件是按對象序列結構的；其中一些對象可能包含其他對象。文件中的對象序列應正好包含一個表示元數據包裝器（電影盒）。它通常靠近文件的開頭或結尾，以便於查找。在這個級別上找到的其他對象可能是文件類型框、可用空間框、電影片段、元數據或媒體數據框。
4.2 元數據和媒體數據
元數據包含在元數據包裝器（電影盒）中；媒體數據包含在同一文件中、媒體數據框中或其他文件中。媒體數據由圖像或音頻數據組成；媒體數據對象或媒體數據文件可能包含其他未引用的信息。
4.3 track 標識符
ISO文件中使用的磁道標識符在該文件中是唯一的；任何兩個磁道不得使用相同的標識符。
存儲在電影標題框的next_track_ID中的next track identifier值通常包含一個大於文件中找到的最大track identifier值的值。這使得在大多數情況下都可以輕松生成軌跡標識符。但是，如果這個值等於1（32位無符號maxint），則需要進一步搜索未使用的磁道標識符。
4.4 元數據結構（對象）
a. Box
此處未定義的類型字段被保留。私有擴展應通過“uuid”類型實現。此外，在本規范的未來版本中，為了避免與使用此格式的早期預標准版本的現有內容發生沖突，以下類型不會也不會使用，或僅在其現有意義上使用：
clip, crgn, matt, kmat, pnot, ctab, load, imap;
這些軌跡參考類型（在軌跡參考框的參考類型中找到）：tmcd, chap, sync, scpt, ssrc.
b. 數據類型和字段
在本規范的許多框中，有兩種變體形式：版本0使用32位字段，版本1使用64位大小的相同字段。一般來說，如果可以使用版本0 的Box（32位字段大小），則應該使用；版本1 Box應僅在需要其允許的64位字段大小時使用。如果計數器的值都是大的，那么就不能將它們的值以最大值的形式存儲。
為了方便創建內容，文件中存儲了創建和修改時間。這些數字可以是32位或64位數字，從1904年1月1日午夜開始計算秒數，這是閏年計算的一個方便日期。在2040年之前，32位就足夠了。這些時間應以協調世界時（UTC）表示，因此如果顯示，可能需要調整到本地時間。
定點數是一個整數除以2的適當冪得到的有符號或無符號值。例如，一個30.2的定點數是由一個32位整數除以4形成的。
在使用此規范的規范中，Box 說明中顯示為“模板”的字段是可選的。如果該字段在另一個規范中使用，則該使用必須與此處的定義一致，並且該規范必須定義該使用是可選的還是強制的。類似地，在本規范的早期版本中使用了標記為“預定義”的字段。對於這兩種類型的字段，如果規范中沒有使用此類字段，則應將其設置為指定的默認值。如果不使用該字段，則在復制框時必須不檢查該字段，並且在讀取時忽略該字段。
出現在標題中的矩陣值指定視頻圖像的顯示轉換。並非所有派生規范都使用矩陣；如果不使用，則應將其設置為單位矩陣。如果使用矩陣，則使用矩陣將點（p，q）轉換為（p'，q'），如下所示：
坐標{p，q}位於解壓縮幀上，{p'，q'}位於渲染輸出。因此，例如，矩陣{2,0,0,0,2,0,0,0,1}正好使圖像的像素維數加倍。矩陣變換后的坐標不是以任何方式規范化的，而是代表實際的樣本位置。因此{x，y}可以被視為圖像的平移向量。
坐標原點位於左上角，X值向右增加，Y值向下增加。{p，q}和{p'，q'}分別作為相對於原始圖像左上角的絕對像素位置（在縮放到由軌跡標頭的寬度和高度確定的大小之后）和變換（渲染）表面。
每個音軌使用其指定的矩陣組成一個整體圖像；然后根據MovieHeaderBox中電影級別的矩陣對其進行變換和組合。例如，是否將生成的圖像“剪裁”以將沒有顯示的像素消除到窗口內的垂直矩形區域，這取決於應用程序。因此，例如，如果只顯示一個視頻軌跡，並且它具有{20,30}的平移，並且在MovieHeaderBox中有一個單位矩陣，則應用程序可以選擇不顯示圖像和原點之間的空“L”形區域。
矩陣中的所有值存儲為16.16個定點值，u、v和w除外，它們存儲為2.30個定點值。
矩陣中的值按{a，b，u，c，d，v，x，y，w}順序存儲。
4.5 Box Order（P26）
下表提供了正常封裝結構的總體視圖。
該表顯示了可能出現在最左邊列的頂層的那些框；縮進用於顯示可能的限制。因此，例如，在音軌盒（trak）中找到了音軌標題框（tkhd），而trak在電影盒（moov）中找到。並非所有的框都需要在所有文件中使用；強制框用星號（*）標記。請參閱各個方框的說明，了解如果不存在可選框，則必須假設的內容。
用戶數據對象只能放在電影或音軌盒中，使用擴展類型的對象可以放在各種各樣的容器中，而不僅僅是頂層。
為了提高文件的互操作性和實用性，對於文件盒的順序，應遵循以下規則和指南：
1） 文件類型框“ftyp”應出現在任何可變長度框（如電影、可用空間、媒體數據）之前。如果需要，只有固定大小的框（如文件簽名）可以放在它前面。
2） 強烈建議首先將所有標題框放在其容器中：這些框是電影標題、曲目標題、媒體標題以及媒體信息框中的特定媒體標題（例如視頻媒體標題）。
3） 任何電影片段盒應按順序排列（見第8.8.5款）。
4） 建議示例表框中的框按以下順序排列：示例說明、采樣時間、采樣到塊、采樣大小、塊偏移量。
5） 強烈建議軌跡參考框和編輯列表（如果有的話）應該在媒體框之前，處理程序引用框應該在媒體信息框之前，數據信息框應該在示例表框之前。6） 建議將用戶數據框放在其容器的最后一個位置，即“電影盒”或“軌跡盒”。
7） 建議將電影片段隨機訪問框（如果存在）放在文件的最后一個。
8） 建議盡可能早地將漸進式下載信息框放在文件中，以獲得最大的效用。
4.3 URI作為類型指示符
當URI用作類型指示符時（例如在示例條目中或用於非定時元數據），URI必須是絕對的，而不是相對的，並且數據的格式和含義必須由相關的URI定義。這種標識可以是分層的，因為URI的初始子字符串可以標識數據的整體性質或族（例如。骨灰盒：舊的：標識元數據由ISO標准對象標識符標記）。
URI應該是，但不是必須是可引用的。它可能是由讀取器與它所知道和識別的一組URI類型進行比較的字符串。uri為類型標識符提供了一個大的非沖突的非注冊空間。
如果URI包含域名（例如，它是一個URL），那么它還應該包含mmyyyy格式的月份日期。該日期必須接近定義擴展的時間，並且URI是在該日期以域名所有者授權的方式定義的，這必須是真的。（這避免了域名更改所有權時出現的問題）。
5. Brand ID
適用於文件格式的brand定義見附錄E。