上一期文章我分享了一些視頻播放里面的術(shù)語和基本概念。這一篇文章我會主要介紹容器(container format file)格式文件的細(xì)節(jié)，以最常見的MP4文件入手。然后會簡短的介紹一個標(biāo)準(zhǔn)的播放器的啟動，解析，播放流程。本篇還是以基礎(chǔ)知識為主，雖然很枯燥，但是對視頻開發(fā)的學(xué)習(xí)有非常大的好處，我自己個人的感受就是，如果在很多專有名字，概念都不熟悉的情況下，想要去閱讀播放器源碼會是相當(dāng)困難的事情。比如Exoplayer，谷歌的分包策略就是根據(jù)播放器的組件來分包。如果不熟悉播放器的基礎(chǔ)構(gòu)建的話，連哪個部分的代碼在哪個包都不知道。希望大家如果真的想進階的話還是耐心的理解好每個基礎(chǔ)概念。

1. Mp4格式文件的構(gòu)成
2. Mp4頭文件的構(gòu)成
3. 標(biāo)準(zhǔn)播放器的啟動流程
4. 在線視頻播放的技術(shù)基礎(chǔ)(online video streaming)

1. Mp4格式文件的構(gòu)成

在上期我們大概介紹了Mp4文件的結(jié)構(gòu)

但是這樣抽象的介紹可能還是比較難理解，我們深入一些。

1.1 MP4到底是個啥？

通俗的說，MP4其實是一種格式的規(guī)范，這個規(guī)范是被ISO機構(gòu)認(rèn)證的，也就是說，只要你通過Codec生成了一個mp4文件，那么這個文件的格式必須是按照ISO機構(gòu)的規(guī)矩來。。。。既然是規(guī)范，那么我們看看到底ISO對mp4做了什么規(guī)范:

請大家打開鏈接->ISO的mp4文件規(guī)范

大家可能會有點懵逼，看不懂。其實這個規(guī)范很好理解，它定義了一個MP4文件里面，哪些數(shù)據(jù)應(yīng)該放在什么位置(以字節(jié)為單位)，哪些數(shù)據(jù)的長度是多少。我截取了一段:

大家看，上面這一段規(guī)范定義了ftyp這個頭文件header所在的位置和長度(以字節(jié)為單位)。
至于這些頭文件是有什么用，我在上一篇文章大概提到過，他們屬于meta data的一部分。在本章我會更詳細(xì)的介紹。

所以說，任何容器，包括mp4都是類似的結(jié)構(gòu)化文件，只不過不同的格式文件ISO對其有嚴(yán)格的要求，數(shù)據(jù)的擺放順序，排列等等不同而已。有興趣的同學(xué)可以對比一下rmvb，mp4，mkv這些格式的要求有什么不同，優(yōu)劣勢各是什么。

2.Mp4頭文件的構(gòu)成

關(guān)于mp4文件的頭文件格式（meta data），蘋果官網(wǎng)對其進行了詳細(xì)的描述（這個介紹是基于QuickTime播放器支持的mp4文件來介紹的，quciktime播放器對mp4的要求有些許不同，但是差別不大，我們可以忽略）:

Movie Atom

我們不追究太多細(xì)節(jié)，有興趣的同學(xué)可以自己查看，我們專注于一些基礎(chǔ)的信息。

首先，在Meta Data里面，每一個Header，頭文件，我們都叫他們Atom Header(不知道咋翻譯)。Atom Header分為Leaf Atom 和 Container Atom。前者代表一個連接著字符串信息的頭文件，后者是一個包含了若干個子Atom的頭文件，他們互相之間是有層級關(guān)系的(參考上圖)。每次播放器獲取了movie atom之后(moov)，會根據(jù)層級關(guān)系，向下，或者向下讀取相關(guān)的其他信息。每一個頭文件都會對它的子頭文件保存位置的引用，所以只要根據(jù)mp4文件的規(guī)范獲取了最頂級的頭文件moov,就可以順勢往下讀取其他頭文件了。

我們來看看mp4的頭文件結(jié)構(gòu)

看起來很復(fù)雜，但是對于一個播放器來說，很多信息都不是必須。我們需要知道的最重要的信息是采樣索引表(Sample Table Atoms).對應(yīng)圖中“**stbl **”這個atom header。這個索引表保存了mp4文件所有的采樣(sample)與視頻時間的對應(yīng)關(guān)系(一般以微秒為單位)，還有包括每個采樣的大小，在mp4文件中的起始位置(以自己為單位)。

3.標(biāo)準(zhǔn)播放器的啟動流程

那么既然我們已經(jīng)知道一個容器文件的格式規(guī)范了，播放器就可以通過解析容器的頭文件來控制播放(playback)了。

3.1 播放器

通常播放器由三個部分構(gòu)成

1. 讀取器(Extractor)
2. 渲染器(TrackRenderer)
3. 加載控制器(Load Controller)
4. 數(shù)據(jù)源(Source)

讀取器負(fù)責(zé)從source文件讀取數(shù)據(jù)，加載控制器負(fù)責(zé)控制讀取數(shù)據(jù)的策略(比如說在線視頻播放的時候緩沖策略)，渲染器負(fù)責(zé)接收讀取器讀取的數(shù)據(jù)，并渲染到屏幕上。

3.2 播放器的播放過程

在播放器可以把數(shù)據(jù)提交給渲染器之前，播放器需要把必需的頭文件全部解析并存入內(nèi)存，比如之前說的采樣索引表。一般播放器在解析完畢后，會構(gòu)建三個個表，一個存放時間對應(yīng)采樣索引，一個存放采樣索引對應(yīng)在mp4文件中的起始位置(以字節(jié)為單位),一個存放采樣索引對應(yīng)大小(以字節(jié)為單位)。以下圖為例

假設(shè)播放器需要從第1微秒開始播放，那么需要把第1微秒的數(shù)據(jù)放入渲染器。所以會查找下面這三個表。

通過表1，我們知道該微秒對應(yīng)第1個采樣（sample），從第一個和第二個表我們知道，第1個采樣的數(shù)據(jù)范圍(在mp4文件內(nèi))是從第0字節(jié)到300（0+300）字節(jié)，那么播放器就會去讀取這個范圍的數(shù)據(jù)并且放入渲染器中進行渲染。

同時，加載器會基于當(dāng)前已經(jīng)緩存的數(shù)據(jù)，決定是否還需要不停的讀取數(shù)據(jù)進入內(nèi)存。一般來說每個播放器都有默認(rèn)的緩存值，也會有一個基準(zhǔn)線，只有當(dāng)緩存足夠數(shù)據(jù)才能放進渲染器進行渲染。

最后同理，當(dāng)我們拖動滑動控制器(SeekBar)想快進的時候，我們和第一步一樣，通過我們想滑動的時間獲取采樣的索引，再重新開始讀取數(shù)據(jù)。

綜上所述，播放器在正式播放視頻文件之前，必須要把頭文件全部讀取并解析(這會是一段非常耗時的程序)，這也是在線視頻播放的等待時間的瓶頸。在接下來的章節(jié)我會介紹自適應(yīng)視頻播放(Adaptive Streaming)，這個技術(shù)的發(fā)明使得了分段式mp4文件(Fragmented Mp4)技術(shù)得以誕生，大大的減少了在線視頻播放的等待時間。

4.在線視頻播放的技術(shù)基礎(chǔ)(online video streaming)

在線視頻的播放其實和播放本地視頻的局別就是Extractor讀取的Source，數(shù)據(jù)源不一樣，在線播放需要下載數(shù)據(jù)到內(nèi)存，再交由Extractor讀取分析。但是既然是在線視頻播放，我們肯定不能把整個容器文件下載到內(nèi)存或者硬盤再開始解析播放。我們希望能控制下載的進度，比如我當(dāng)前在看第10s的視頻內(nèi)容，所以我只想緩存/下載視頻內(nèi)容到第20s的位置。

我們俗稱的漸進式下載(Progressive Downloading)就解決了這一難題。

說的好像是很嚇人的黑科技啊?。。?！

其實就是HTTP1.1協(xié)議支持的分段式下載而已。。。。。

在HTTP請求里面假如一個叫RANGE的header，放入起始字節(jié)和結(jié)束字節(jié)，就可以只下載對應(yīng)部分的數(shù)據(jù)，這一header的支持也是各種下載軟件實現(xiàn)斷點下載的基礎(chǔ)。每次斷網(wǎng)的時候記錄下來已經(jīng)下載的數(shù)據(jù)的字節(jié)數(shù)，下次再下載的時候從字節(jié)數(shù)+1處重新下載并且寫入原有文件就可以了。

分割線

所以這次分享就結(jié)束啦，下一期分享我會開始進入正題，在安卓平臺里面，對視頻播放的支持，像api啊等等，以及其變遷歷史。

周末愉快！