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

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

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

 

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

1.1 MP4 到底是個啥？

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

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

大家可能會有點(diǎn)懵逼，看不懂。其實(shí)這個規(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)對其進(jìn)行了詳細(xì)的描述（這個介紹是基于 QuickTime 播放器支持的 mp4 文件來介紹的，quciktime 播放器對 mp4 的要求有些許不同，但是差別不大，我們可以忽略）:

Movie Atom^[2]

我們不追究太多細(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ù)并且放入渲染器中進(jìn)行渲染。

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

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

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

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

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

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

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

 

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

 

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