淺談HTTP Adaptive Streaming技術及其前景
關鍵詞：OTT 流媒體 HTTP Adaptive Streaming
本文已發表於《世界寬帶網絡》2011.6 第18卷第5期 總200期
HTTP Adaptive Streaming（以下簡稱“HAS”）技術結合了傳統的流媒體技術和HTTP漸進式下載播放的特點，以HTTP的方式向用戶傳送媒體內容，該技術的採用可以大大提升用戶的媒體播放體驗，同時該技術降低了頭端服務器的技術複雜度。基於HTTP的傳送方式提升了媒體內容在網絡設備中的穿透能力，該技術目前已成爲流媒體視頻行業發展的趨勢。
一、傳統流媒體技術
近些年，互聯網視頻迅猛發展，視頻內容的流量已佔到了整個互聯網流量的一半。談到互聯網視頻就不得不提到流媒體技術，正是流媒體技術的不斷髮展促進了目前互聯網視頻的迅猛發展。
傳統的媒體內容分發技術主要有兩大類，一類是以RTSP/RTP(Real Time Streaming Protocol/Real Time Transfer Protocol)爲代表的面向連接的流媒體技術，另一類則是目前主流視頻網站採用的無連接的HTTP漸進式下載。
1.RTSP/RTP的流媒體方案
RTSP是一種傳統的流媒體控制協議，其具有狀態性的特點意味着從一個客戶端開始連接至服務端一直到連接中斷的整個過程，服務端會一直監聽客戶端的狀態。客戶端通過RTSP協議向服務器傳達控制命令，如播放、暫停或中斷等。
RTP/RTCP(Real Time Transfer Control Protocol)是端對端基於組播的應用層協議。其中，RTP用於數據傳輸，RTCP用於統計、管理和控制RTP傳輸，兩者協同工作，能夠顯著提高網絡實時數據的傳輸效率。
基於此架構的流媒體技術方案，服務端和客戶端之間建立連接之後，服務器開始持續不斷地發送媒體數據包，媒體數據包採用RTP進行封裝，客戶端控制信息通過RTSP信息包以UDP或TCP的方式傳送。
另外，類似的流媒體協議還包括了Adobe的RTMP(Real Time Messaging Protocol)以及Real公司的RTSP over RDT(Real Data Transport Protocol)，本文就不在此對這些流媒體協議逐一進行介紹了。
2.HTTP漸進式下載
HTTP漸進式下載技術與有狀態的RTSP/RTP技術相比，採用了無狀態的HTTP協議。當HTTP客戶端向前端請求數據時，服務端將請求的數據下發給客戶端，但是服務端並不會記錄客戶端的狀態，每次HTTP請求都是一個一次性獨立的會話。
漸進式下載的功能目前主流的終端播放器均支持，如Adobe的Flash、微軟的Silverlight以及Windows Media Player。所謂的漸進式下載，即終端播放器可以在整個媒體文件被下載完成之前即可開始媒體的播放，客戶端及服務端如果均支持HTTP1.1，終端還可從沒下載完成的部分中任意選取一個時間點開始播放。
目前，主流的視頻網站均採用了HTTP漸進式下載的方式來實現流媒體的分發，如優酷網、土豆網等等。
3.方案對比
作爲最簡單和原始的流媒體解決方案，HTTP漸進式下載尤其顯著的優點在於它僅需要維護一個標準的Web服務器，其安裝和維護的工作量和複雜性比起專門的流媒體服務器來說要簡單和容易得多。
然而，其缺點和不足也很明顯。首先是帶寬容易浪費。當一個用戶在開始下載觀看一個內容之後選擇停止觀看，那麼已經下載完成的內容則是對帶寬資源的一種浪費。其次，基於HTTP的漸進式下載僅僅適用於點播內容，而不支持直播內容。最後，此方式缺乏靈活的會話控制功能和智能的流量調節機制。
而基於RTSP/RTP的流媒體系統專門針對大規模流媒體直播和點播等應用而設計，需要專門的流媒體服務器支持，與HTTP漸進下載相比主要具有如下優勢。
-
流媒體播放的實時性。與漸進下載客戶端需要先緩衝一定數量媒體數據才能開始播放不同，基於RTSP/RTP的流媒體客戶端幾乎在接收到第一幀媒體數據的同時就可以啓動播放。
-
支持進度條搜索、快進、快退等高級VCR控制功能。
-
平滑、流暢的音視頻播放體驗。在基於RTSP的流媒體會話期間，客戶端與服務器之間始終保持會話聯繫，服務器能夠對來自客戶端的反饋信息動態做出響應。當因網絡擁塞等原因導致可用帶寬不足時，服務器可通過適當降低幀率等方式來智能調整發送速率。
-
支持大規模用戶擴展。普通的Web服務器主要針對大量小的HTML文件下載而進行優化，在傳輸大容量媒體文件方面缺少性能優勢。而專業的流媒體服務器在大容量媒體文件硬盤讀取、內存緩衝和網絡發送等方面進行了優化，可支持大規模用戶接入。
-
內容版權保護。在漸進下載模式中，下載後的文件緩存在客戶端硬盤的臨時目錄中，用戶可將其拷貝至其他位置供以後再次播放。而在基於RTSP/RTP的流媒體系統中，客戶端只在內存中維持一個較小的解碼緩衝區，播放後的媒體數據隨時清除，用戶不容易截取和拷貝。此外還可利用DRM等版權保護系統進行加密處理。
儘管如此，基於RTSP/RTP的流媒體系統在實際的應用部署中仍然遇到了不少問題，主要體現在：
-
與Web服務器相比，流媒體服務器的安裝、配置和維護都較爲複雜，特別是對於已經建有CDN(內容分發網絡)等基礎設施的運營商來說，重新安裝配置支持RTSP/RTP的流媒體服務器工作量很大；
-
RTSP/RTP協議棧的邏輯實現較爲複雜，與HTTP相比支持RTSP/RTP的客戶端軟硬件實現難度較大，特別是對於嵌入式終端來說；
-
RTSP協議使用的網絡端口號(554)可能被部分用戶網絡中的防火牆和NAT等封堵，導致無法使用。雖然有些流媒體服務器可通過隧道方式將RTSP配置在HTTP的80端口上承載，但實際部署起來並不是特別方便。
二、HTTP碼率自適應
上一節中我們談到了基於RTSP/RTP的流媒體技術以及基於HTTP的漸進式下載，但是我們可以清楚看到兩種方案均存在着各自的缺點。
這時HAS技術應運而生，它融合了傳統RTSP/RTP流媒體技術以及基於HTTP漸進式下載技術的優點，具有高效、可擴展以及兼容性強的特點。圖2爲HAS技術的實現原理。
HAS技術是一種混合的媒體分發方式，給用戶的體驗是流的方式，但是實際上與HTTP漸進式下載方式一樣採用HTTP協議完成了內容的下載分發，但這些媒體內容都被切割成了一系列的媒體分塊進行傳輸。
HAS技術的一個關鍵就是媒體數據的切割分塊，每個分塊的時間長度相同，一般爲2～10秒。在視頻編碼層，這意味着每個分塊都由若干個完整的視頻GOP組成(每個分塊都有一個關鍵I幀)，以此保證每個分塊都與過去及將來的媒體分塊無關聯。
如圖3所示，媒體分塊存儲在HTTP Web服務器中，客戶端以線性的方式向Web服務器請求媒體分塊，並以傳統的HTTP方式進行媒體分塊的下載，當媒體分塊下載至客戶端時，客戶端按照順序播放這一系列媒體分塊。因爲這些媒體分塊按照約定的規則進行編碼，各個媒體分塊之間沒有內容的重疊或不連續，對於用戶來說，則看到了一個無縫平滑的播放效果。
若一份內容在編碼輸出時已提供了多種碼率，則內容切片模塊會將其切割成多種碼率的媒體分塊。因爲Web服務器傳輸數據是儘可能地利用網絡帶寬來進行內容的下載，沒有流量的控制機制，客戶端可以很容易地檢測到Web服務器到客戶端的可用網絡帶寬，從而決定下載更大或更小的媒體分塊，實現碼率的自適應。
從圖4我們可以看出，HAS的關鍵技術主要由兩大部分，一是內容的準備，包括了支持多屏的轉碼平臺以及媒體的分割切片模塊，其次是內容的分發，包括了基於HTTP的內容源服務器以及面向終端的內容分發網絡，完成併發流數量的放大功能。
三、HAS技術特點分析
1.採用HAS的優勢
HAS與其他基於HTTP傳輸媒體的方式一樣，和傳統的流媒體分發技術相比，具有以下優勢：
-
Web服務器更容易部署，因爲HAS技術採用了通用的HTTP協議，傳統的HTTP緩存/代理、防火牆等網絡設備可以完美兼容；
-
提供了更好的兼容性和到達率，可根據最後接入網的帶寬大小動態地調整碼率，實現內容的分發；
-
對於用戶來說體驗更好，且不需要業務提供者去考慮收看用戶的帶寬。
HAS除了上述優勢之外，還有以前任何技術均不具備的特點，具體如下：
-
用戶等待的時間更短，可以快速實現播放——客戶端初始化默認選擇低碼率，開始播放後逐步向高碼率進行切換，因此，其服務質量是在可用帶寬範圍之內不斷被進行調整和優化；
-
不需要大的緩存，不間斷地播放，沒有抖動的平滑視頻播放體驗；
-
基於網絡狀況和CPU解碼能力的無縫碼率切換；
-
客戶端不需要下載超過它實際消耗的內容。
綜上所述，相對於傳統的流媒體技術，它能夠提供更好的服務質量，因爲它可以使用整個可用的帶寬，而非自適應流技術則是強制客戶端選擇一個低於可用帶寬的固定比特率。可以預見，HAS技術在不久的將來將得到廣泛的部署及應用。
2.需要面對的問題
上一節我們談到了HAS的優勢及技術實現原理，似乎HAS的實現非常簡單，首先在內容準備上提供多個碼率的媒體文件，並提供一個索引文件，其中記錄了各個碼率文件的關係及特性，接下來終端根據初始的帶寬情況選擇一個碼率的媒體文件進行順序播放，期間根據網絡情況以及CPU的負載調整碼率。
但是HAS技術方案具體部署實施時有許多問題需要去明確，如果這些問題沒有得到很好的解決，則無法提供最佳的用戶體驗。
-
採用幾個碼流？
-
碼流的分辨率？
-
關鍵幀間隔？
-
VBR or CBR？
-
音頻參數的設置？
四、HAS企業方案及技術標準
目前，HAS技術的實現方式從標準的類型來看主要有兩大類：一類是企業方案，即提供了整體的技術解決方案，如Apple Live Streaming技術、Microsoft Smooth Streaming技術、Adobe Dynamic Streaming技術；一類則是一些國際標準組制定的技術標準，如OIPF的HTTP Adaptive Streaming、MPEG的DASH(Dynamic Adaptive Streaming over HTTP)、IETF的草案（由Apple公司提議的草案）。
1.OIPF
OPEN IPTV Forum在其定義的OIPF技術規範中對碼率自適應技術進行了界定，規範中對如何實現HTTP碼流自適應的理論進行了細化及擴展，明確瞭如何使用及使用的範圍。該標準以3GPP的Adaptive HTTP Streaming技術規範爲基礎進行相關的擴展，增加了對MEPG-2 TS格式的支持。
OIPF的碼率自適應標準中對終端下載的索引文件進行了定義，OIPF中將索引文件命名爲MPD(Media Present Description)文件，採用XML格式進行組織。
同時OIPF標準規定了媒體的封裝格式爲TS和MP4，並且對分片的一些細節進行了界定，如同一內容的不同碼率的文件必須使用同樣的媒體封裝格式，但是編碼的Profile可以不同。
該標準對直播應用場景以及快進、快退、定位等操作均進行了定義。
2.MPEG
近來，MPEG標準發佈了一項關於HTTP Streaming的標準DASH，見圖5。
DASH標準對目前出現的HAS技術框架進行了總結歸納，對背景、目的以及使用場景進行了介紹。該標準中定義了一系列的使用場景，如3D Video、互動3D、動態碼率自適應、Peer-2-Peer以及多畫面電視，同時還對如何與內容保護技術結合進行了定義。
DASH標準的制定主要爲了解決以下問題：
-
更爲有效地將MPEG的媒體通過HTTP協議，以自適應、漸進式、下載或流的方式進行內容分發；
-
支持直播業務；
-
更爲有效地利用傳統的基於HTTP的CDN網絡、代理Server或防火牆等網絡基礎部件；
-
支持與內容保護系統的結合，完成對內容的保護。
總的來說，DASH對採用HTTP傳輸MPEG媒體涉及到的各方面提出了一系列的技術要求，包括了媒體內容格式、傳輸方式、MPD文件、業務控制、自適應以及媒體保護等。
3.Apple HTTP Live Streaming（IETF）
HTTP Live Streaming是Apple公司的HAS整體解決方案，該方案設計的目標主要是通過普通的Web服務器將直播內容或點播內容推送至Apple的終端設備，如iPhone、iPad以及蘋果的臺式機。Apple公司的技術規範現已提交至IETF組織討論，目前還在標準的草案階段。
HTTP Live Streaming由三部分組成：服務器組件、分發組件和客戶端。首先，編碼器接收音視頻輸入，並採用H.264編碼技術，輸出MPEG-2 TS流，然後利用切片軟件按設定的時間間隔對TS碼流進行切割並保存爲一個個TS文件。這些TS文件部署在Web服務器上，切片軟件同時還創建了包含這些TS文件相關信息的索引文件。索引文件的URL在Web服務器上發佈，客戶端讀取索引文件，然後按順序向服務器請求媒體文件並無停頓地顯示它們。一個簡單的HTTP Live媒體流配置如圖6所示。
在蘋果的動態碼率自適應體系中，索引文件被保存爲.M3U8文件，這是保存MP3播放列表的.M3U格式的一種擴展。HTTP Live Streaming支持實時廣播會話和視頻點播會話兩種應用場景。
對於實時會話來說，當新的媒體文件被創建時，索引文件也會隨之更新，舊的索引文件通常會被刪除。更新的索引文件會在連續流中顯示一個移動的窗口，這種類型的會話適合連續的直播內容。對於視頻點播會話，媒體文件在整個會話週期內都是固定不變的。索引文件是靜態的，只需在媒體開始播放前獲取一次，其包含了所有媒體文件的完整列表。
目前，HTTP Live Streaming沒有考慮對DRM的完整支持，但它支持內容的加密，通過16位密鑰的AES-128加密算法對內容加密，HTTP Live Streaming中僅對如何通過URI獲取密鑰進行了粗略的定義。
4.Microsoft Smooth Streaming
Smooth Streaming是微軟提供的一套HAS解決方案，基於Microsoft的頭端Web服務IIS 7以及其終端的Silverlight技術。微軟的Smooth Streaming選擇了MPEG-4格式爲媒體封裝格式，Smooth Streaming將每個分片都用MPEG-4封裝成一個MPEG-4的Fragment，但是存儲爲一個完整連續的MP4文件，事實上媒體僅僅是做了虛擬的分片。當終端的播放URL的請求上來時，頭端服務器需要準確地分析URL請求，並將其轉化爲精準的偏離量，從而找到對應的媒體數據塊分發給終端。
之所以選擇MP4作爲媒體文件格式，主要是因爲MP4相比於ASF是一個輕量級的容器，更容易使用.NET進行管理和控制，同時MP4是基於廣泛應用的ISO Base Media文件格式規範，最重要的一點是MP4設計之初就考慮支持在一個文件內實現媒體內容負荷的分片。微軟Smooth Streaming存儲媒體格式、傳輸媒體格式分別見圖7、圖8所示。
從圖8我們可以很清楚地看出，Smooth Streaming採用的是一種虛擬切片的技術，微軟的HTTP碼率自適應技術並沒有真實地將媒體文件進行切片，每個碼率對應的內容存儲成了一個完整長度的文件，在實際播放過程中，根據終端的請求將每個Fragment獨立分發給終端。
Smooth Streaming終端基於Silverlight進行實現，Silverlight可完成MPEG-4文件格式的解析、HTTP下載以及碼率的切換。同時微軟將這些功能以.NET代碼的形式提供給開發者調用，開發者可對播放器的效果進行優化及調整。播放器的開發工作中最爲複雜的模塊是碼率的切換模塊，何時切換以及如何切換是此模塊的核心功能，也是技術難點，如果想給用戶最佳的體驗，必須考慮以下問題。
-
當用戶有足夠的帶寬但是CPU解碼能力不足時該如何處理？
-
當視頻播放被用戶暫停或隱藏在背後時該如何處理？
-
當最佳的視頻質量的分辨率超出了屏幕本身的分辨率時該如何處理？
-
下載播發的Buffer窗口該設置爲多大？
-
當在播放過程中需要插入新的媒體內容如插播一段廣告時該如何保證無縫的切換？
5.Adobe HTTP Dynamic Streaming
Adobe公司的傳統流媒體解決方案RTMP+FLV的組合，在互聯網視頻行業得到了廣泛的應用。針對動態碼率自適應的需求，Adobe公司首先在其傳統的解決方案上實現了碼率自適應，但隨後不久Adobe公司也推出了基於HTTP的碼率自適應解決方案HTTP Dynamic Streaming，見圖9。
Adobe HTTP Dynamic Streaming包含了多個部件來完成內容的準備工作，並通過HTTP將內容傳送給終端的Flash Player。
內容準備模塊包括了面向VOD和麪向Live直播的模塊，VOD打包模塊將媒體文件分片，並以F4F的格式存儲，Live直播打包模塊將直播流實時地寫入到F4F文件當中。
HTTP源模塊是標準的Web Server，存儲了F4F文件和媒體對應的F4M格式的索引文件，索引文件中包含了編碼、分辨率以及碼率等參數信息。
6.分析及小結
通過研究各種標準組提出的技術規範以及微軟、蘋果等公司的企業技術方案，我們可以看出基於HTTP的碼率自適應的實現原理是類似的，主要的區別在於媒體文件格式以及索引文件格式的不同，如表所示。 在這裏我們談了許多HAS的優勢，但是目前的技術體系還有許多方面有待完善及改進。
首先，上述技術體系都是基於Client驅動的模式，依靠Client對網絡狀況及其自身硬件平臺的能力情況進行判斷，通過解析索引描述文件，最終從頭端Server中以主動“拉取”的形式獲取內容。在直播應用中，終端是需要頻繁不斷地更新描述文件來獲取新的內容的相關信息。如採用Server驅動的模式，則不需要對描述文件進行頻繁地更新，Server不斷獲取到最新的內容，並且連續不斷地以“推送”的方式向終端發送媒體數據，比較適應於對實時性要求較高的直播應用。
其次，上述HAS技術體系缺乏質量的監測與控制機制。例如，當一個用戶在觀看直播頻道時進行頻道切換，當前時間的GOP以及播放器需要的初始化信息需要儘快傳送到終端進行播放，但是目前的HAS技術體系中沒有對重要的HTTP包進行加速傳輸的機制。
五、展望未來
隨着互聯網技術的快速推進，利用互聯網傳輸渠道提供視頻服務已成爲趨勢。傳統的廣電運營商、新興的視頻網站、互聯網巨頭、彩電廠商以及消費電子類設備商紛紛涌入。所有的參與者都在積極打造各自的新媒體服務平臺，以OTT的形式將內容分發至電視屏、PC屏以及手機屏。
HAS技術的出現爲面向多終端的新媒體服務平臺的建設提供了一個極佳的解決方案，可以預見HAS技術將有着極爲廣闊的發展空間，在三網融合的進程中起到關鍵的作用。
轉自：
