ios流媒體直播整個架構介紹（HLS、RTSP）

一、HTTP（WebService）

基於HTTP的漸進下載Progressive Download流媒體播放僅是在完全下載後再播放模式基礎上做了一些小的改進。與下載播放模式中必須等待整個檔案下載完畢後才能開始播放不同，漸進下載用戶端在開始播放之前僅需等待一段較短的時間用於下載和緩衝該媒體檔案最前面的一部分資料，之後便可以一邊下載一邊播放。在正式開始播放之前的這一小段緩衝應使得後續即使在網路較為擁塞的情況下媒體資料也能夠得以不間斷地連續播放，通常需要幾十秒甚至上百秒的時間。在這種模式下，用戶端以自己以及Web伺服器和網路所能允許的最大速度儘可能快地從伺服器索取資料，而不考慮當前所播放壓縮碼流的實際碼率參數。只有滿足特定封裝條件的媒體檔案格式才支援這種類型的漸進下載播放，例如用於初始化解碼器的編碼參數必須放置在媒體檔案的起始部位，音視頻資料完全按照時間順序進行交織等。

漸進下載流媒體播放採用標準HTTP協議來在Web伺服器和用戶端之間遞送媒體資料，而HTTP又承載於TCP之上。TCP最初是為非即時性資料轉送而設計的，其最佳化目標在於在保證整個網路總的穩定性和高輸送量的前提下，最大化資料轉送速率。為達到這個目的，TCP採用了一種稱之為慢啟動的演算法，它首先以一個較低的速率來發送資料，然後再逐漸提高這個速率，直到接收到來自目的方的分組丟失反饋報告。此時TCP認為它已達到最高頻寬節流設定或者網路中出現了擁塞，於是重新開始以一個較低速率來發送資料，然後逐漸提高，這個過程不斷地重複下去。TCP通過重傳丟失的分組來達到可靠傳輸的目的。然而，對於流媒體資料來說，TCP 無法保證所有重傳的資料能在它們預定的播放時刻之前按時到達用戶端。當這種情況出現時，用戶端不能跳過這些丟失或遲到的資料直接播放時間上靠後的媒體資料，而必須停下來等待，從而導致播放器畫面停頓和斷斷續續的現象發生。在漸進下載播放模式中，用戶端需要在硬碟上緩衝所有前面已經下載的媒體資料，對本機存放區空間的需求較大。播放過程中使用者只能在前面已經下載媒體資料的時間範圍內進行進度條搜尋和快進、快退等操作，而無法在整個媒體檔案時間範圍內執行這些操作。

嚴格意義上，基於HTTP的VOD不算是真的流媒體，英文稱為“progressive downloading”或者“pseudo streaming”，為什麼這樣呢。因為HTTP缺乏流媒體基本的流控，由此基於HTTP協議很難實現媒體播放的快進，快退，暫停。那麼，通常的媒體播 放器又是如何利用HTTP來實現這樣的功能呢。

我們都知道，不管媒體檔案有多大，HTTP都只是視它為一個HTTP的元素，可以只需要發送一個HTTP請求，WEB Server就會源源不斷地將媒體流推送給用戶端，而不管用戶端是否接受，這就是HTTP協議本身沒有流控的原因，那這樣會帶來什麼後果呢。

如果伺服器的推流速度和用戶端同步， 那麼基本不會出現什麼大問題；如果小於用戶端的接收流的速度，那麼播放就會一卡一卡的；如果大於或者遠大於用戶端的接收速度，那又會是怎麼樣的結果呢。很 不幸，在我們所有的ISTV項目中，只要是基於HTTP的VOD，都無一例外是第三種情況。因為我們VOD是基於區域網路的，大家都知道，區域網路的頻寬資源 是很豐富的，伺服器的推流的速度肯定大於播放器的播放速度，那麼在這麼速度極端不協調的情況下，伺服器的推流速度究竟由誰來限制呢。

答案是：TCP協議棧。我們的VOD點播是基於TCP的HTTP協議。TCP是安全的，可靠的，包肯定不會丟，伺服器檢測到用戶端的接收緩衝區滿了，就會減小發送資料滑動視窗的大小。所以HTTP的流控是通過TCP協議棧來調節的，不是HTTP本身。試想，這樣對伺服器造成的壓力有多大!

下面就分析基於HTTP協議如何?SEEK，PAUSE等操作
1.SEEK（快進和快退）
先關閉之前的tcp串連，重新串連，發送http請求，該請求帶了媒體的位移位置。由此可見，每一次的快進和快退，都等於是重新開始播放，只是每次開始播放的位置不一樣。
2.PAUSE
該操作就更有意思了，用戶端暫停了播放，也就是不從緩衝區讀取資料了，但是伺服器不知道用戶端停止了播放，依然不停地發送資料給用戶端，直到用戶端的接收 緩衝區已滿，然後伺服器的資料發送不出去了，理論上是伺服器端的滑動視窗的大小估計就是0了，然後協議棧還在不停在嘗試發送資料，因為是基於tcp，這些 資料還不能丟。nnd，這種方式實現暫停，協議棧都哭了。很不幸，MPLAYER就是這麼乾的。所以暫停時間長了，就容易出現問題。
雖然HTTP沒有PAUSE的支援，但是針對PAUSE是可以最佳化的，最佳化的方法是，將媒體檔案分區，分區的大小以稍小於TCP協議棧的緩衝區大小為宜。 HTTP請求一次只請求一個分區的大小，暫停播放後，就不在發送分區請求了。這樣可以保證讓伺服器啟動並執行時間長一些，播放器暫停理論上可以無限長了。 二、HTTP Live Streaming

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，為iOS裝置（如iPhone、iPad）提供音ApsaraVideo for Live和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不同在於，它的分段非常小。要實現HLS點播，重點在於對媒體檔案分段，目前有不少開源工具可以使用，這裡我就不再討論，只談HLS直播技術。一個典型的HTTP Live Streaming流媒體系統由內容準備、內容分發和用戶端軟體三部分組成，如圖所示。

1. 內容準備

內容準備部分負責將輸入的音視頻媒體內容轉換成為適合於內容分發組件進行遞送的格式。對於ApsaraVideo for Live，編碼器首先將攝像機即時採集的音視頻資料壓縮編碼為符合特定標準的音視頻基本流(目前蘋果的系統僅支援H.264視頻和AAC音頻)，然後再複用和封裝成為符合MPEG-2系統層標準的傳輸串流(TS)格式進行輸出。流分割器(Stream Segmenter)負責將編碼器輸出的MPEG-2 TS流分割為一系列連續的、長度均等的小TS檔案(尾碼名為.ts)，並依次發送至內容分發組件中的

Web伺服器進行儲存。與此同時，為了跟蹤播放過程中媒體檔案的可用性和當前位置，流分割器還需建立一個含有指向這些小TS檔案指標的索引檔案，同樣放置於Web伺服器之中。這個索引檔案可以看作是一個連續媒體流中的播放清單滑動視窗，每當流分割器產生一個新的TS檔案時，這個索引檔案的內容也被更新，新的檔案URI(統一資源定位器)加入到滑動視窗的末尾，老的檔案URI則被移去，這樣索引檔案中將始終包含最新的固定數量的x個分段，如圖所示。流分割器還可以對其產生的每個小TS檔案進行加密，並產生相應的密鑰檔案。

之所以採用MPEG-2 TS格式來對編碼後的媒體流進行統一封裝，是因為它能夠將音視頻媒體流嚴格按時序進行交織複用，任意截取和分段後，每一個分段都可能不依賴於之前的分段而獨立進行解碼和播放。為此，TS檔案中必須僅包含一個MPEG-2節目，在每個檔案的開頭應包含一個節目關聯表(PAT)和一個節目映射表(PMT)，包含視頻的檔案中還必須含有至少一個主要畫面格和其他足夠資訊(如序列頭)用以完成解碼器的初始化。索引檔案採用擴充的M3U播放清單格式，尾碼
名為.m3u8。M3U播放清單是一個由若干文本行組成的文字檔，其中每一行要麼是一個URI，一個空行，或者是一個以注釋符“#”起始的行。每個URI行指向一個分段的媒體檔案，或者一個衍生的索引(播放清單)檔案。除了以“#EXT”起始的行是標籤行外，其他以“#”起始的行是注釋，應予忽略。下面是一個簡單的.m3u8索引檔案例子，其所表示的媒體流由3個未加密的長度為10秒的TS檔案組成。

#EXTM3U#EXT-X-MEDIA-SEQUENCE:0#EXT-X-TARGETDURATION:10#EXTINF:10,http://media.example.com/segment1.ts#EXTINF:10,http://media.example.com/segment2.ts#EXTINF:10,http://media.example.com/segment3.ts#EXT-X-ENDLIST

對 於 視 頻 點 播 ( V O D ) ， 文 件 分 割 器 ( F i l e Segmenter)首先將預編碼儲存的媒體檔案轉碼為MPEG-2 TS格式檔案(已經封裝為TS格式的檔案則忽略這一步)，然後再將該TS檔案分割成一系列長度均等的小TS檔案。檔案分割器同樣也產生一個含有指向這些小檔案指標的索引檔案。與直播型會話不同的是，這裡的索引檔案是一個不隨時間而更新的靜態檔案，其中包含一個節目從頭到尾所有分段檔案的URI列表，並以#EXT-X-ENDLIST標籤結尾。可以通過下述方法將一個直播事件轉換成VOD節目源供以後點播：在伺服器上不刪除已經到期的分段媒體檔案，同時在索引檔案中也不刪除這些檔案所對應的URI索引項目，在直播結束的時候將#EXT-X-ENDLIST標籤添加至索引檔案的末尾。 2. 內容分發

內容分發系統用於通過HTTP協議將分割後的小媒體檔案及其索引檔案遞送至用戶端播放器，它既可以是一個普通的Web伺服器，也可以是一個Web緩衝系統。幾乎不需要對Web伺服器做任何特殊的配置，以及增加其他定製的模組。推薦的配置僅限於對.m3u8檔案和.ts檔案的MIME類型關聯，如表所示。

由於索引檔案需要頻繁更新和下載，因此在Web cache的配置中有必要對.m3u8檔案的TTL(time-to-live)值進行微調以保證用戶端每次請求該檔案時都能夠下載到它的最新版本。 3. 用戶端軟體

通常情況下，用戶端軟體通過訪問Web網頁中的URL連結來擷取和下載一個流媒體會話的索引檔案。這個索引檔案進一步指定了伺服器上當前可用的TS格式媒體檔案、解密密鑰和其他替換流的位置。對於選定的媒體流，用戶端依次下載索引檔案中列出的每一個可用媒體檔案。當這些媒體檔案緩衝夠一定數量後，用戶端將它們按順序重新拼裝成一個連貫的TS流，然後發送至播放器進行解碼和呈現。對於加密的媒體檔案，用戶端還負責根據索引檔案的指引來擷取解密密鑰，提供使用者認證介面，並按需進行解密。對於ApsaraVideo for VOD，上述過程不斷持續下去，直到用戶端碰到索引檔案中的#EXT-X-ENDLIST標籤。對於ApsaraVideo for Live，索引檔案中不存在#EXT-X-ENDLIST標籤，用戶端將周期性地向Web伺服器重新請求擷取該索引檔案的更新版本，然後在這個更新版的索引檔案中尋找新的媒體檔案和解密密鑰，並將它們的
URI添加至下載隊列的末尾。需要注意HTTP Live Streaming並不是一個真正即時的流媒體系統，這是因為對應於媒體分段的大小和期間有一定潛在的時間延遲。在用戶端中，至少在一個分段媒體檔案被完全下載之後才能夠開始播放，而
通常要求下載完成兩個分段媒體檔案之後才開始播放以保證不同分段音視頻之間的無縫串連。此外，在用戶端開始下載之前，必須等待伺服器端的編碼器和流分割器至少產生一個TS檔案，這也會帶來潛在的時延。在推薦配置下，HTTP Live Streaming系統的典型時延約在30s左右。 4. 網路自適應的流間切換和故障保護

在基於HTTP Live Streaming的流媒體系統中，伺服器可以為同一節目源準備多份以不同碼率和品質編碼的替換流，並為每個替換流都產生一個衍生的索引檔案。在主索引檔案中通過包含一系列指向其他衍生索引檔案的URI指標來找到相應的替換流，如圖所示。

在移動互連網環境下，由於網路覆蓋面的不同和訊號強弱的變化，移動終端可能隨時在不同的無線接入網路(例如3G，EDGE，GPRS和WiFi等)之間進行切換。此時用戶端軟體可根據網路和頻寬的變化情況隨時切換
到不同衍生索引檔案所指向的替換流進行下載，從而自適應地為使用者提供相應網路條件下接近最優的音視頻QoS體驗。上述替換流和衍生索引檔案機制除了可以用於基於頻寬波動的動態流間切換外，還可以用於伺服器的故障保護。為此目的，首先在一台伺服器上按照正常流程產生一個媒體流或者多個替換流，以及對應的索引檔案，然後再在另一台伺服器上產生一套並行的備份媒體流和索引檔案。接下來將指向備份流的索引加入到主索引檔案之中，使得其中針對每個頻寬值都對應有一個主媒體流和一個備份媒體流。例如，假定主伺服器和備份伺服器分別為ALPHA和BETA，則主索引檔案中的內容可能如下所示：

#EXTM3U#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000http://ALPHA.example.com/lo/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000http://BETA.example.com/lo/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000http://ALPHA.example.com/md/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000http://BETA.example.com/md/prog_index.m3u8

在上述例子中，當用戶端串連主伺服器ALPHA失敗時，它將試圖串連備份伺服器BETA，從中擷取最高頻寬值替換流所對應的衍生索引檔案，並進一步根據該索引檔案下載相應的替換媒體流檔案。

　 相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不同在於，直播用戶端擷取到的，並不是一個完整的資料流。HLS協議在伺服器端將直播資料流儲存為連續的、很短時間長度的媒體檔案（MPEG-TS格式），而用戶端則不斷的下載並播放這些小檔案，因為伺服器端總是會將最新的直播資料產生新的小檔案，這樣用戶端只要不停的按順序播放從伺服器擷取到的檔案，就實現了直播。由此可見，基本上可以認為，HLS是以點播的技術方式來實現直播。由於資料通過HTTP協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段檔案的時間長度很短，用戶端可以很快的選擇和切換碼率，以適應不同頻寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議。
　根據以上的瞭解要實現HTTP Live Streaming直播，需要研究並實現以下技術關鍵點

1.採集視頻源和音頻源的資料
2.對未經處理資料進行H264編碼和AAC編碼
3.視頻和音頻資料封裝為MPEG-TS包
4.HLS分段建置原則及m3u8索引檔案
5.HTTP傳輸協議 三、RTSP (Real Time Streaming Protocol)

上述基於漸進下載的流媒體播放僅能支援點播而不能支援直播，媒體流資料到達用戶端的速率無法精確控制，用戶端仍需維持一個與伺服器上媒體檔案同樣大小的緩衝儲存空間，在開始播放之前需要等待一段較長的緩衝時間從而導致即時性較差，播放過程中由於網路頻寬的波動或分組丟失可能會導致畫面停頓或斷續等待，不支援全時間範圍的搜尋、快進、快退等VCR操作。為克服這些問題，需要引入專門的流媒體伺服器以及相應的即時資料流媒體傳輸和控制協議來進行支援。RTSP/RTP是目前業界最為流行和廣為採用的即時資料流媒體協議。它實際上由一組在IETF中標準化的協議所組成，包括RTSP(即時資料流媒體會話協議)， SDP(會話描述協議)，RTP(即時傳輸協議)，以及針對不同編解碼標準的RTP淨載格式等，共同協作來構成一個流媒體協議棧，如圖所示。基於該協議棧的擴充已被ISMA(互連網流媒體聯盟)和3GPP(第三代夥伴計劃)等組織採納成為互連網和3G移動互連網的流媒體標準。

RTSP是用來建立和控制一個或多個時間同步的連續音視頻媒體流的會話協議。通過在客戶機和伺服器之間傳遞RTSP會話命令，可以完成諸如請求播放、開始、暫停、尋找、快進和快退等VCR控制操作。雖然RTSP會話通常承載於可靠的TCP串連之上，但也可以使用UDP等無連線協定來傳送RTSP會話命令。在RTSP協議中起關鍵作用的命令主要包括下面幾個：

1) SETUP：使伺服器分配媒體流資源，並啟動一個RTSP會話。
2) PLAY和RECORD：在SETUP所啟動會話並分配資源的某個流上開始資料轉送。
3) PAUSE：暫時中止一個流的資料轉送而不釋放伺服器資源。
4) TEARDOWN：釋放伺服器上的流資源，結束RTSP會話。

SDP協議用來描述多媒體會話。SDP協議的主要作用在於公告一個多媒體會話中所有媒體流的相關描述資訊，以使得接收者能夠感知這些描述資訊並根據這些描述參與到這個會話中來。SDP會話描述資訊通常是通過RTSP命令互動來進行傳遞的，其中攜帶的媒體類資訊主要包括：

1) 媒體的類型(視頻，音頻等)。
2) 傳輸協議(RTP/UDP/IP，RTP/TCP/IP等)。
3) 媒體編碼格式(H.264視頻，AVS視頻等)。
4) 流媒體伺服器接收媒體流的IP地址和連接埠號碼。

RTP又稱為即時傳輸協議，用於實際承載媒體資料並為具有即時特性的媒體資料互動提供端到端的傳輸服務，例如淨載類型識別、序號、時間戳記和傳輸監控等。應用程式通常選擇在UDP之上來運行RTP協議，以便利用UDP的複用和校正和等功能，並提高網路傳輸的有效輸送量。然而RTP仍可選擇與其它網路傳輸協議(例如TCP)一塊使用。一個RTP分組由RTP頭和RTP淨載(payload)兩部分組成。上層應用程式主要通過RTP頭中的序號欄位(sequence number)和時間戳記(timestamp)欄位來實施其所承載媒體流資料的同步定時播放和QoS控制。RTP淨載部分實際承載用戶端所需要的音視頻媒體資料。針對不同的音視頻編碼通訊協定可能需要定義不同的RTP淨載格式，例如H.264的RTP淨載格式標準和AVS視頻的RTP淨載格式標準。流媒體伺服器和用戶端播放器依照這些淨載格式標準來進行媒體資料流的RTP打包和分拆重組工作。RTSP/RTP流媒體協議棧的使用需要專門的流媒體伺服器進行參與。與漸進下載中媒體資料的被動突發遞送不同，在有流媒體伺服器參與的媒體分發過程中，媒體資料是以與壓縮的音視頻媒體碼率相匹配的速率主動和智能地發送的。在整個媒體遞送過程中，伺服器與用戶端緊密聯絡，並能夠對來自用戶端的反饋資訊做出響應。RTP是真正的即時傳輸協議，用戶端僅需要維持一個很小的解碼緩衝區用於緩衝視頻解碼所需的少數參考幀資料，從而大大縮短了起始播放時延，通常可控制在1秒之內。使用UDP來承載RTP資料包可提高媒體資料轉送的即時性和輸送量。當因為網路擁塞而發生RTP丟包時，伺服器可以根據媒體編碼特性智能地進行選擇性重傳，故意丟棄一些不重要的資料包；用戶端也可以不必等待未按時到達的資料而繼續向前播放，從而保證媒體播放的流暢性。

RTSP（Real Time Streaming Protocol），即時資料流傳輸協議，是TCP/IP協議體系中的一個應用程式層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協議定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料。類似HTTP協議的流量控制協議。它們都使用純文字來發送資訊，而且rtsp協議的文法也和HTTP類似，和HTTP協議相比RTSP協議所不同的地方是，RTSP協議是有狀態的協議，而HTTP是無狀態的協議。RTSP通過維護一個session來維護其狀態的轉換。RTSP協議的預設連接埠是554，預設的承載協議為TCP。

目前對於RTSP在IOS用戶端播放技術還是以FFMPEG+貼圖的方式為主。 四、架構：

出於便於管理和擴充，頻寬節流設定和多使用者並發的考慮，商用方案都會採用流媒體伺服器+WEB伺服器+代理服務器+手機用戶端的方案，其中： 流媒體伺服器(streaming server)負責採集視頻源並壓縮編碼並隨時等待來自用戶端的rtsp串連請求； WEB伺服器(web server)便於發布和管理視頻資訊； 代理服務器(transmission server）是可選的，用於把來自client的RTSP請求轉寄給server,並把伺服器端的即時資料流轉給client，這樣的好處是在相同頻寬下支援更多的使用者同時觀看； 手機用戶端(client)可以用手機內建的播放器（如nokia上的realplayer)或者自己開發的獨立播放器，前者的好處是降低使用者使用門檻，便於大規模應用；後者方便擴充和定製，滿足更多的功能。

streaming server是整個方案的核心，目前主流的流媒體伺服器解決方案如下： helix server :藉助Real公司的強大實力，這是目前最流行的方案， 可以支援所有音視頻格式，效能穩定，是唯一可以橫跨 Windows Mac 及 Linux， Solaris ，HP/UX 使用者流媒體服務的平台，支援在手機內建播放器播放。helix server免費的版本只支援1M流量，企業版很貴。當然你要就是另外一回事了 darwin server: 這是apple公司推出的開源的流媒體解決方案，支援格式沒helix那麼多，但由於是開源的免費的，對於開發人員有很大的開發空間。 live555 media server:效能穩定,但支援格式比較少(只有mp3,amr,aac,mpeg4 es等幾種流)，很少獨立使用而一般作為系統的一部分。 Windows Media Server：僅限微軟平台，就不考慮了。

手機端架構流程如下：
手機用戶端與伺服器端的傳輸協議目前常用有HTTP,RTSP兩種：
早期的手機電視多用的HTTP，HTTP的優點有不用特殊的伺服器軟體，有IIS即可，不用考慮防火牆NAT，但HTTP不支援即時資料流，也會浪費頻寬；
RTSP則是當前流媒體傳輸的主流標準，連微軟都拋棄了MMS而轉而支援RTSP， RTSP可以支援用戶端暫停回放停止等操作，基本不用考慮音視頻同步問題（因為音頻視頻分別從不同RTP PORT讀入緩衝）。值得說明的是，RTSP成功後，就開始RTP傳輸，分為RTP OVER TCP和RTP OVER UDP，前者保證每個資料包都能收到，如果沒收到就重傳，而且不用考慮防火牆NAT；後者只保證盡最大努力的傳輸，不會重傳丟幀，即時性好，要解決防火牆NAT問題。如果對幀率要求比較高的手機電視，推薦採用UDP傳輸，因為延遲較大的重傳資料對使用者是沒有意義的，寧可丟棄。

網路部分可採用強大的開源庫live555實現RTSP/RTP協議，其效能穩定而且支援大多數音視頻格式的傳輸。(當然ffmpeg也實現了網路傳輸部分,經過改動後也能用）對live555經過裁剪後移植到symbian和windows mobile，這部分工作在symbian真機調試比較費時。

視頻解碼部分當然還是採用ffmpeg,移植了mpeg4 sp/h.264解碼器，在沒有任何最佳化的情況下可支援32K,CIF,5-10fps的效果，對於一般的流媒體應用足夠了。以後還要經過演算法和彙編最佳化。解碼後還需要經過yuv2rgb和scale，需要注意的是ffmpeg的解碼有消隱區的說法，即qcif的映像其linesize不是176而是192，如果你發現解碼後映像呈綠色，需用img_convert()轉一下(目的格式也是PIX_FMT_YUV420P)。symbian上用DSA直接寫屏就行。windows mobile上可以用sdl.

音頻解碼主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge頻寬支援的音頻（aac效果比amrnb好),AMRWB是3G後的音頻格式。在ffmpeg 0.5 release中已經支援amrnb/wb的fixed point解碼，很強大。 五、分析與比較

作為最簡單和原始的流媒體解決方案，HTTP漸進下載唯一顯著的優點在於它僅需要維護一個標準的Web伺服器，而這樣的伺服器基礎設施在互連網中已經普遍存在，其安裝和維護的工作量和複雜性比起專門的流媒體伺服器來說要簡單和容易得多。然而其缺點和不足卻也很多，首先是僅適用於點播而不支援直播，其次是缺乏靈活的會話控制功能和智能的流量調節機制，再次是用戶端需要硬碟空間以緩衝整個檔案而不適合於嵌入式裝置等。基於RTSP/RTP的流媒體系統專門針對大規模流媒體直播和點播等應用而設計，需要專門的流媒體伺服器支援，與HTTP漸進下載相比主要具有如下優勢：

流媒體播放的即時性。與漸進下載用戶端需要先緩衝一定數量媒體資料才能開始播放不同，基於RTSP/RTP的流媒體用戶端幾乎在接收到第一幀媒體資料的同時就可以啟動播放。

支援進度條搜尋、快進、快退等進階VCR控制功能。

平滑、流暢的音視頻播放體驗。在基於RTSP的流媒體會話期間，用戶端與伺服器之間始終保持會話聯絡，伺服器能夠對來自用戶端的反饋資訊動態做出響應。當因網路擁塞等原因導致可用頻寬不足時，伺服器可通過適當降低幀率等方式來智能調整發送速率。此外，UDP傳輸協議的使用使得用戶端在檢測到有丟包發生時，可選擇讓伺服器僅選擇性地重傳部分重要的資料(如主要畫面格)，而忽略其他優先順序較低的資料，從而保證在網路不好的情況下用戶端也仍能連續、流暢地進行播放。

支援大規模使用者擴充。普通的Web伺服器主要針對大量小的HTML檔案下載而進行最佳化，在傳輸大容量媒體檔案方面缺少效能優勢。而專業的流媒體伺服器在大容量媒體檔案硬碟讀取、記憶體緩衝和網路發送等方面進行了最佳化，可支援大規模使用者接入。 支援網路層多播。網路層多播允許單一媒體流共用網路路徑，同時發送到多個用戶端，可大大縮減網路頻寬需求。只有藉助專門的流媒體伺服器才能實現這一功能。 內容著作權保護。在漸進下載模式中，下載後的檔案快取在用戶端硬碟的臨時目錄中，使用者可將其拷貝至其他位置供以後再次播放。而在基於RTSP/RTP的流媒體系統中，用戶端只在記憶體中維持一個較小的解碼緩衝區，播放後的媒體資料隨時清除，使用者不容易截取和拷貝。

此外還可利用DRM等著作權保護系統進行加密處理。儘管如此，基於RTSP/RTP的流媒體系統在實際的應用部署特別是移動互連網應用中仍然遇到了不少問題，主要體現在：

與Web伺服器相比，流媒體伺服器的安裝、配置和維護都較為複雜，特別是對於已經建有CDN(內容分髮網絡)等基礎設施的電訊廠商來說，重新安裝配置支援RTSP/RTP的流媒體伺服器工作量很大。

RTSP/RTP協議棧的邏輯實現較為複雜，與HTTP相比支援RTSP/RTP的用戶端軟硬體實現難度較大，特別是對於嵌入式終端來說。

RTSP協議使用的網路連接埠號碼(554)可能被部分使用者網路中的防火牆和NAT等封堵，導致無法使用。雖然有些流媒體伺服器可通過隧道方式將RTSP配置在HTTP的80連接埠上承載，但實際部署起來並不是特別方便。

蘋果公司的HTTP Live Streaming正是為瞭解決這些問題應運而生的，其主要特點是：放棄專門的流媒體伺服器，而返回到使用標準的Web伺服器來遞送媒體資料；將容量巨大的連續媒體資料進行分段，分割為數量眾多的小檔案進行傳遞，迎合了Web伺服器的檔案傳輸特性；採用了一個不斷更新的輕量級索引檔案來控制分割後小媒體檔案的下載和播放，可同時支援直播和點播，以及VCR類會話控制操作。HTTP協議的使用降低了HTTP Live Streaming系統的部署難度，同時也簡化了用戶端(特別是嵌入式移動終端)軟體的開發複雜度。此外，檔案分割和索引檔案的引入也使得頻寬自適應的流間切換、伺服器故障保護和媒體加密等變得更加方便。與RTSP/RTP相比，HTTP Live Streaming的最大缺點在於它並非一個真正的即時資料流媒體系統，在伺服器和用戶端都存在一定的起始延遲。而且目前主要面向移動多媒體應用，推薦支援的最高視頻碼率僅為800 Kbps，對於更高碼率特別是高清視頻的支援程度尚需進一步的探究和驗證。歸納起來，上述三種流媒體協議的綜合比較見表所示。

HTTP漸進下載、RTSP/RTP和HTTP Live Streaming等三種流媒體協議，對各自的基本方法和特點進行了介紹，特別是對HTTP Live Streaming協議進行了較為詳細的描述，並在此基礎上對三種流媒體協議進行了對比分析。總體來說，
HTTP漸進下載系統部署起來最為簡單，但僅適用於較小規模的短ApsaraVideo for VOD應用；
基於RTSP/RTP的協議棧適合於大規模可擴充的互動式即時資料流媒體應用，但需要專門流媒體伺服器的支援，安裝和維護起來都較為複雜；
HTTP Live Streaming可直接部署於目前擁有廣泛運營基礎的Web伺服器網路環境，不需要對網路基礎設施進行升級改造，特別適合於對即時性要求不是太高的消費級移動互連網流媒體應用。

文／RiderOnTheWheel（簡書作者）
原文連結：http://www.jianshu.com/p/5b0fa403b3ce
著作權歸作者所有，轉載請聯絡作者獲得授權，並標註“簡書作者”。