MPEG-DASH白皮書初版翻譯

注：英語太爛基礎太差，本翻譯文檔僅供本中本身參考。並且包含一大堆本身YY的意譯。

編號：ISO/IEC JTC1/SC29/WG11 W13533

時間：2012年4月

標題：MPEG-DASH標準白皮書

在線觀看奧運會，把最愛的電視節目插曲下到遊戲機上，或在手機上瀏覽24小時不間斷的新聞頻道，以上這些應用場景都滲透到了咱們的平常生活中。據統計，在過去的2008年奧運期間，NBC一共大約傳輸了3.4PB的視頻內容[1]。但相較其巨大的潛在市場，網絡流媒體仍處於發展初期。致使這種狀況的緣由之一就是目前各個商業平臺的封閉性：每一家都有本身的音視頻格式、流協議以及播放形式。也就是說，不一樣設備和服務器供應商之間根本沒有互通。有研究代表，不久後的未來，視頻將佔據網絡流量的絕大部分[2]。而在不一樣設備和服務器供應商之間造成統一標準，基於這樣的兼容性，臺式機/電視機/筆記本/機頂盒/遊戲機/平板電腦以及手機上能夠實現一個大規模的內容和服務生態圈，將大力推動視頻行業的發展。MPEG-DASH就是爲此而誕生。

1、爲什麼使用HTTP流?

20世紀90年代開始，視頻內容的網絡傳輸逐步興起，實時傳輸和大規模的數據逐漸成爲主要的技術瓶頸。IETF發佈的RTP協議(Real-time Transport Protocol)定義了超低延時前提下的網絡傳輸音視頻包格式。RTP在組建IP網絡(managed IP networks)中有良好的表現。可是，目前網絡應用已經基本轉移到CDN上，CDN大多數都不支持RTP流；此外，RTP包很容易被防火牆攔截；另外，RTP流要求服務端與每個客戶端都保持獨立的長鏈接，這對服務端負載形成巨大的壓力。

隨着網絡帶寬的增長以及萬維網的迅猛擴展，使用很小的封裝包來傳輸音視頻數據逐漸變得不那麼重要了。當前使用HTTP協議能夠很是高效地傳輸大分片（相對於小封裝包而已）的多媒體內容。HTTP流有許多的優點：1)在目前網絡結構下的高效性，好比CDN的邊緣節點緩存減小了遠程傳輸；2)HTTP能有效避開防火牆的阻攔，由於幾乎全部的防火牆都支持HTTP穿透；3)HTTP服務端技術已經徹底商業化，用來支持百萬級的直播用戶是很是高效和有價值的；4)HTTP流傳輸時，客戶端無需與服務端維持一個長鏈接，所以服務端只要使用CDN的標準http技術管理便可，無需浪費大量額外資源用於保證大量流客戶端的鏈接。

綜上所述，商業應用部署時一般選用HTTP流這一途徑。好比Apple公司的HLS協議(HTTP Live Streaming)[3]、Microsoft公司的MSS協議(Microsoft's Smooth Streaming)[4]、Adobe公司的HDS協議(HTTP Dynamic Streaming)[5]均基於HTTP傳輸。不過，這些協議的定義、描述和包結構都各不相同，客戶端必須針對不一樣協議作特有的兼容性支持，才能正常接收數據。統一的http流媒體傳輸標準能夠在全部規範化的客戶端和服務端之間傳輸流數據，這將實現不一樣供應商之間客戶端和服務端的互通。

基於市場的發展和行業要求，2009年4月MPEG開始徵集HTTP流媒體標準的提案。截至2009年7月，當MPEG開始評估提交的技術時，一共收到了15份完整的提案。在隨後的兩年中，在大量專家參與下，經過與其餘標準組織（例如3GPP[6])的合做，MPEG完成了該規範的制定。該標準最終版的核心部分，ISO/IEC 23009-1，即MPEG-DASH協議(MPEG Dynamic Adaptive Streaming)於2012年4月發佈[7]。

2、碼率自適應的簡單例子

圖一中給出了按需動態切換碼流的簡單示例。在這個圖片中，媒體流包含了音頻和視頻部分。視頻源被編碼爲三種碼率供選擇：5M/2M/200Kbps，此外還提供了僅包含I幀的低幀率碼流用於特殊場景下的播放。對應的音頻內容有兩種語言版本供選擇：音頻流1爲英文杜比聲，編碼爲環繞音、AAC 128K和48Kbps兩種碼率；音頻2則是原始的法語版，編碼爲AAC 128K和48Kbps兩種碼率。

圖1、動態碼率自適應的簡單示例，編號圓圈表示客戶端執行切換動做時間點

假設客戶端啓動播放時請求了最高碼率(5M)的視頻流及英文版128K音頻流（因爲客戶端不支持環繞聲音頻播放）。傳輸了音視頻的第一個分片後，經過對有效帶寬的監控，客戶端察覺到實際可用帶寬低於5Mbps。因而，在下個可用的切換點（編號2），客戶端將視頻流切換爲2Mbps，即下個分配請求中等質量的視頻流，同時保持128Kbps的音頻流傳輸。客戶端繼續監控可用網絡帶寬，意識到帶寬進一步下降到2Mbps如下了，爲了保持播放的流暢性，它將視頻流和音頻流分別降到500Kbps和48Kbps（編號3）。客戶端繼續以上述碼率播放，直到帶寬增長時，纔將視頻流碼率提高到2Mbps（編號4）。過了會兒，用戶決定暫停和倒帶，這時客戶端開始從特殊場景模式下載並倒序播放視頻數據，同時將音頻靜音（編號5）。用戶在本身指望的時間點（編號6）點擊播放原始法語流，這時客戶端切換爲5Mbps的高清晰度視頻流傳輸，以及128Kbps的法語音頻流傳輸。

以上示例或許是流媒體傳輸中動態碼率切換最爲簡單的狀況。更進階的使用包括在不一樣攝像視角、3D流媒體內容、帶字幕或說明的視頻流、動態廣告插入、低延遲直播流、混合流和備播流等碼流之間的切換。

3、MPEG-DASH標準涵蓋範圍

圖二簡單說明了HTTP服務端和DASH客戶端之間的流媒體傳輸方案。在該圖中，HTTP服務器獲取並存儲了多媒體內容，並使用HTTP協議來傳輸。服務端包含兩部份內容：1)MPD文件(Media Presentation Description)，列舉了可用分片的清單、可供切換的不一樣碼率、URL地址及其餘特徵；2)分片文件，以塊、單一文件或多文件形式存儲了實際的多媒體碼流。

圖2、MPEG-DASH標準範圍。紅色塊中格式和功能在標準中定義，客戶端控制模塊和播放器不在標準範圍內

DASH客戶端首先下載MPD文件來啓動播放。MPD文件可使用HTTP、郵件、U盤、廣播或其餘途徑來傳輸。MPD解析完成後，DASH客戶端獲取到了媒體內容時長、可用性、媒體類型、分辨率、最小和最大帶寬以及可供選擇的各類碼流、可訪問性功能及所需的數字版權證書(DRM)、網絡中各媒體組件所處位置及其特徵。使用以上信息，DASH客戶端能夠選擇合適的碼流，開始經過HTTP GET請求獲取分片數據。

客戶端適當緩衝必定量數據來適應網絡抖動，不斷地下載後續分片而且監控帶寬的波動。基於這個結果，客戶端在不一樣備選碼流（碼率更高或更低）中切換並下載分片數據，用以保證帶寬波動下足夠的緩衝。

MPEG-DASH規範只定義了MPD和分片格式。MPD文件的傳輸、分片文件及媒體編碼格式、客戶端下載方式、碼率切換裝置、媒體數據的播放都不在MPEG-DASH標準的涵蓋範圍內。

4、MPD文件

動態HTTP流傳輸要求服務端提供多媒體內容的不一樣碼率方案供選擇。此外，多媒體內容可能包含若干媒體組件（如音頻、視頻、文本等），每種組件均可以具有不一樣的特徵。在MPEG-DASH標準中，這些特徵在MPD中以XML形式描述。

圖3、MPD分層數據模型 圖三是MPD分層數據模型的演示。MPD由一個或多個以時間軸劃分的區段(Period)構成。每一個Period都定義了開始時間及時長，由一個或多個自適應子集(AS)組成。AS指出了所對應的（一個或多個）媒體內容，及其不一樣編碼方案信息。好比，某個AS能夠包含某媒體內容中視頻部分的不一樣碼率信息，另外一個AS則包含該媒體內容中音頻部分的不一樣碼率信息（好比較低質量的立體聲和較高質量的環繞聲）。一般狀況下，一個AS會包含多個表述(Representation)。

表述是指某個媒體組件的可選編碼方案，以碼率、分辨率、信道或其餘特徵區別於其餘表述。每一個表述由一個或多個分片(Segment)組成。分片就是媒體流基於時間軸的分塊。分片都帶有特定的URI（即服務器上的可尋址地址），使用HTTP GET請求（能夠指定字節範圍）便可下載媒體數據。

DASH客戶端首先解析MPD中的XML文檔來使用以上數據模型。而後，根據MPD中的描述性元素、客戶端支持的功能以及用戶的決定來挑選本身將使用的一組表述。接着，客戶端構建出時間軸，請求對應的多媒體分片數據來開始本次播放。表述中給出的分片信息，使得對應分片的HTTP URL及字節範圍能正確構建和請求。在直播場景下，MPD中還會描述出使用該分片文件的起始時間、臨近媒體數據開始時間，以及分片的固定或可變時長。

4、分片文件格式

用戶能夠將多媒體內容當作一組分片文件來訪問。DASH客戶端發起完整或部分的HTTP GET請求時，所收到響應的實體主體就是一個分片。媒體組件會被編碼並劃分爲多個分片。其中，第一個分片通常包含DASH客戶端解碼器初始化所需信息，它不包含任何實際的媒體數據。流數據則會被劃分爲一個或多個連續的媒體分片。每一個媒體分片有獨一無二的URL（有時候會附帶有字節範圍）、索引、顯式或隱式的開始時間及時長。每一個分片至少包含一個流接入點(Stream Access Point)，能夠僅基於當前數據開始流媒體解碼，這實現了該媒體流在本分片位置的隨機接入或切換。

MPEG-DASH規範經過使用分片索引框(segment index box)[8]，標識所包含的子分片，來實現分片內各部分的並行下載。該索引框記錄了各子分片的時長和字節偏移，用於標識子分片及流接入點。DASH客戶端可使用索引信息，經過部分的HTTP GET請求獲取子分片數據。索引框能夠是單一的，位於該分片開始位置，也能夠是多個，存在於分片內各處。索引信息的分佈能夠是多元化的，例如分層結構、菊花鏈或混合結構。這避免了因在分片頭部添加很是大的索引框形成的較大初始延遲。

MPEG-DASH基於ISO的MP4[9]和MPEG-2的TS[10]文件分別進行了封裝格式的定義。它未指定具體的編碼標準，且支持單一碼流或碼流複用。

5、多DRM（數字版權管理）及通用加密

在MPEG-DASH中，每一個AS能夠擁有一個或多個DRM來對內容進行保護，客戶端解析出至少一個DRM後即可以傳輸和解碼數據。

爲實現MPEG-DASH標準化，MPEG還提出一個通用加密標準（即ISO/IEC 23001-7），定義了媒體內容通用加密方案的信令。基於此標準，數據在完成一次加密後傳輸到各個支持不一樣DRM證書的客戶端，客戶端經過解析MPD文件中的信令，使用各自的DRM系統來獲取特定的解密密鑰，而後從同一服務器傳輸獲得通用加密後的媒體內容。

6、其餘功能點

MPEG-DASH標準包含了多種豐富的功能，好比：

• 1).多路可供切換的流：MPD文件爲DASH客戶端提供了足夠信息，便於在不一樣流之間進行選擇和切換，好比切換不一樣語種的音頻流、不一樣視角的視頻流、不一樣語種的字幕文件，或同一攝像機不一樣碼率之間的動態切換。
• 2).動態廣告插入：不管點播仍是直播場景，廣告都能以區段的形式插入原有區段或分片之間。
• 3).簡化描述文件：分片的URL可使用模板來標識，這使得MPD文件很是簡潔。
• 4).模塊化描述文件：MPD文件能夠劃分爲多個部分，其中一些元素能夠從外部引用到，這一特色實現了MPD分段下載的可行性。
• 5).分片時長可變：分片的時長能夠變化。直播場景下，當前分片中能夠帶有下一分片的時長信息。
• 6).多URL支持：同一內容在不一樣服務器或CDN上具有各不相同的URL，客戶端能夠選擇其中任意一個來最大化利用當前網絡帶寬。
• 7).直播場景的時鐘偏移控制：每一個分片中均可以包含UTC時間，用來保證客戶端對時鐘偏移的控制。
• 8).可伸縮視頻編碼(SVC)和多視圖視頻編碼(MVC)支持：MPD文件能夠爲表述之間的解碼依賴關係提供足夠的信息，用於保證諸如SVC和MVC多層編碼的正常使用。
• 9).描述符的靈活性：用於對內容分級、組件構成、可訪問性、視角、幀封裝和音軌屬性等進行描述。
• 10).可根據內容製做者的要求，將AS進行分組。
• 11).會話質量評估：對於通訊會話有明肯定義的質量指標，便於客戶端測量評估並上報。

7、MPEG-DASH附加部分

目前，MPEG委員會正在開發三個新的模塊，將用來增長到ISO/IEC 23009-1標準的核心部分中。如下模塊是該規範核心部分的支持或擴展：

• 1).ISO/IEC 29002-2（卷2）："Conformance and reference software"規定了用於實現ISO/IEC 23009全部其餘部分規範性條款所需的一致性和參考軟件。
• 2).ISO/IEC 29002-3（卷3）："Implementation Guidelines"給出了使用該標準及達到最佳體驗的指導信息。它爲點播、直播、特殊模式、廣告插入場景下製做和發佈MPEG-DASH內容提供了指導。它還提供了客戶端實現指南，包括MPD文件檢索、碼率自適應、流切換、拖拽和特殊模式播放。此外，卷3還描述了直播服務部署時的DASH時序模型構建。
• 3).ISO/IEC 29002-4（卷3）："Segment encryption and authentication"定義了MPEG-DASH分片的加密和驗證方法。此部分容許忽略分片內具體格式和內容，將整個分片進行加密和驗證。該規範還擴展了MPD文件，用於標識加密和驗證信息。

ISO/IEC 23009-1的更改和修正也在進行中，該規範獲得了進一步明肯定義，而且增長了一些關鍵功能。

8、後續工做

該規範定義了五個特定的配置條款，各自對應不一樣類型的應用。每種配置都有不一樣的限制條件，其所約定的MPD和分片文件格式構成了整個規範的一個子集。所以，對應某一配置的DASH客戶端僅需實現該配置（而不是整個規範）要求的功能。某些配置專門用於兼容已有內容，這爲現存的非標準遷移到標準方案提供了可行性。

其餘一些標準組織和機構也在與MPEG合做，實現本身標準中對MPEG-DASH的應用。與此同時，業界在提供MPEG-DASH解決方案上反應迅速，一些DASH相關開源項目正在開發中。將來幾年將是行業（即內容服務提供商、平臺提供商、軟件供應商、CDN供應商和設備製造商）採用該標準構建網絡多媒體生態圈的關鍵時機。

9、引用

• [1] Miller, P., SVP/GM Digital Media at NBC Sports, keynote, blogs.msdn.com/b/tims/arch…, March 2009.
• [2] Cisco Networks, 「Cisco’s Visual Networking Index Global IP Traffic Forecast 2010-2015,」 www.cisco.com/en/US/netso…, June 2011.
• [3] Pantos, R. and May, E. W., 「HTTP Live Streaming」, Informational Internet Draft, tools.ietf.org/html/draft-…, March 2011.
• [4] Microsoft, 「IIS Smooth Streaming Transport Protocol,」 www.iis.net/community/f…, September 2009.
• [5] Adobe, 「Adobe HTTP Dynamic Streaming,」 www.adobe.com/products/ht….
• [6] 3GPP TS 26.247: "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP".
• [7] ISO/IEC 23009-1:2012, 「Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats」, April 2012.
• [8] ISO/IEC 14496-12:2008/DAM 3, 「Information technology – Coding of audio-visual objects – Part 12: ISO base media file format – Amendment 3: DASH support and RTP reception hint track processing」, January 2011.
• [9] ISO/IEC 14496-12, 「Information technology – Coding of audio-visual objects – Part 12: ISO base media file format」, 2008.
• [10] ITU-T Rec. H.222.0 | ISO/IEC 13818-1, 「Information technology – Generic coding of moving pictures and associated audio information: Systems」.