一、HTTP（WebService）

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

漸進下載流媒體播放采用標準HTTP協(xié)議來在Web服務器和客戶端之間遞送媒體數據，而HTTP又承載于TCP之上。TCP最初是為非實時性數據傳輸而設計的，其優(yōu)化目標在于在保證整個網絡總的穩(wěn)定性和高吞吐量的前提下，最大化數據傳輸速率。為達到這個目的，TCP采用了一種稱之為慢啟動的算法，它首先以一個較低的速率來發(fā)送數據，然后再逐漸提高這個速率，直到接收到來自目的方的分組丟失反饋報告。此時TCP認為它已達到最高帶寬限制或者網絡中出現了擁塞，于是重新開始以一個較低速率來發(fā)送數據，然后逐漸提高，這個過程不斷地重復下去。TCP通過重傳丟失的分組來達到可靠傳輸的目的。然而，對于流媒體數據來說，TCP 無法保證所有重傳的數據能在它們預定的播放時刻之前按時到達客戶端。當這種情況出現時，客戶端不能跳過這些丟失或遲到的數據直接播放時間上靠后的媒體數據，而必須停下來等待，從而導致播放器畫面停頓和斷斷續(xù)續(xù)的現象發(fā)生。在漸進下載播放模式中，客戶端需要在硬盤上緩存所有前面已經下載的媒體數據，對本地存儲空間的需求較大。播放過程中用戶只能在前面已經下載媒體數據的時間范圍內進行進度條搜索和快進、快退等操作，而無法在整個媒體文件時間范圍內執(zhí)行這些操作。

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

我們都知道，不管媒體文件有多大，HTTP都只是視它為一個HTTP的元素，可以只需要發(fā)送一個HTTP請求，WEB Server就會源源不斷地將媒體流推送給客戶端，而不管客戶端是否接受，這就是HTTP協(xié)議本身沒有流控的原因，那這樣會帶來什么后果呢？

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

答案是：TCP協(xié)議棧。我們的VOD點播是基于TCP的HTTP協(xié)議。TCP是安全的，可靠的，包肯定不會丟，服務器檢測到客戶端的接收緩沖區(qū)滿了，就會減小發(fā)送數據滑動窗口的大小。所以HTTP的流控是通過TCP協(xié)議棧來調節(jié)的，不是HTTP本身。試想，這樣對服務器造成的壓力有多大!

下面就分析基于HTTP協(xié)議如何實現SEEK，PAUSE等操作
1.SEEK（快進和快退）
先關閉之前的tcp連接，重新連接，發(fā)送http請求，該請求帶了媒體的偏移位置。由此可見，每一次的快進和快退，都等于是重新開始播放，只是每次開始播放的位置不一樣。
2.PAUSE
該操作就更有意思了，客戶端暫停了播放，也就是不從緩沖區(qū)讀取數據了，但是服務器不知道客戶端停止了播放，依然不停地發(fā)送數據給客戶端，直到客戶端的接收 緩沖區(qū)已滿，然后服務器的數據發(fā)送不出去了，理論上是服務器端的滑動窗口的大小估計就是0了，然后協(xié)議棧還在不停在嘗試發(fā)送數據，因為是基于tcp，這些 數據還不能丟。nnd，這種方式實現暫停，協(xié)議棧都哭了。很不幸，MPLAYER就是這么干的。所以暫停的時間長了，就容易出現問題。
雖然HTTP沒有PAUSE的支持，但是針對PAUSE是可以優(yōu)化的，優(yōu)化的方法是，將媒體文件分片，分片的大小以稍小于TCP協(xié)議棧的緩沖區(qū)大小為宜。 HTTP請求一次只請求一個分片的大小，暫停播放后，就不在發(fā)送分片請求了。這樣可以保證讓服務器運行的時間長一些，播放器暫停理論上可以無限長了。

二、HTTP Live Streaming

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

1. 內容準備

內容準備部分負責將輸入的音視頻媒體內容轉換成為適合于內容分發(fā)組件進行遞送的格式。對于視頻直播，編碼器首先將攝像機實時采集的音視頻數據壓縮編碼為符合特定標準的音視頻基本流(目前蘋果的系統(tǒng)僅支持H.264視頻和AAC音頻)，然后再復用和封裝成為符合MPEG-2系統(tǒng)層標準的傳輸流(TS)格式進行輸出。流分割器(Stream Segmenter)負責將編碼器輸出的MPEG-2 TS流分割為一系列連續(xù)的、長度均等的小TS文件(后綴名為.ts)，并依次發(fā)送至內容分發(fā)組件中的

Web服務器進行存儲。與此同時，為了跟蹤播放過程中媒體文件的可用性和當前位置，流分割器還需創(chuàng)建一個含有指向這些小TS文件指針的索引文件，同樣放置于Web服務器之中。這個索引文件可以看作是一個連續(xù)媒體流中的播放列表滑動窗口，每當流分割器生成一個新的TS文件時，這個索引文件的內容也被更新，新的文件URI(統(tǒng)一資源定位符)加入到滑動窗口的末尾，老的文件URI則被移去，這樣索引文件中將始終包含最新的固定數量的x個分段，如圖所示。流分割器還可以對其生成的每個小TS文件進行加密，并生成相應的密鑰文件。

之所以采用MPEG-2 TS格式來對編碼后的媒體流進行統(tǒng)一封裝，是因為它能夠將音視頻媒體流嚴格按時序進行交織復用，任意截取和分段后，每一個分段都可能不依賴于之前的分段而獨立進行解碼和播放。為此，TS文件中必須僅包含一個MPEG-2節(jié)目，在每個文件的開頭應包含一個節(jié)目關聯(lián)表(PAT)和一個節(jié)目映射表(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文件。文件分割器同樣也生成一個含有指向這些小文件指針的索引文件。與直播型會話不同的是，這里的索引文件是一個不隨時間而更新的靜態(tài)文件，其中包含一個節(jié)目從頭到尾所有分段文件的URI列表，并以#EXT-X-ENDLIST標簽結尾?？梢酝ㄟ^下述方法將一個直播事件轉換成VOD節(jié)目源供以后點播：在服務器上不刪除已經過期的分段媒體文件，同時在索引文件中也不刪除這些文件所對應的URI索引項，在直播結束的時候將#EXT-X-ENDLIST標簽添加至索引文件的末尾。

2. 內容分發(fā)

內容分發(fā)系統(tǒng)用于通過HTTP協(xié)議將分割后的小媒體文件及其索引文件遞送至客戶端播放器，它既可以是一個普通的Web服務器，也可以是一個Web緩存系統(tǒng)。幾乎不需要對Web服務器做任何特殊的配置，以及增加其他定制的模塊。推薦的配置僅限于對.m3u8文件和.ts文件的MIME類型關聯(lián)，如表所示。

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

3. 客戶端軟件

通常情況下，客戶端軟件通過訪問Web網頁中的URL鏈接來獲取和下載一個流媒體會話的索引文件。這個索引文件進一步指定了服務器上當前可用的TS格式媒體文件、解密密鑰和其他替換流的位置。對于選定的媒體流，客戶端依次下載索引文件中列出的每一個可用媒體文件。當這些媒體文件緩沖夠一定數量后，客戶端將它們按順序重新拼裝成一個連貫的TS流，然后發(fā)送至播放器進行解碼和呈現。對于加密的媒體文件，客戶端還負責根據索引文件的指引來獲取解密密鑰，提供用戶認證接口，并按需進行解密。對于視頻點播，上述過程不斷持續(xù)下去，直到客戶端碰到索引文件中的#EXT-X-ENDLIST標簽。對于視頻直播，索引文件中不存在#EXT-X-ENDLIST標簽，客戶端將周期性地向Web服務器重新請求獲取該索引文件的更新版本，然后在這個更新版的索引文件中查找新的媒體文件和解密密鑰，并將它們的
URI添加至下載隊列的末尾。需要注意HTTP Live Streaming并不是一個真正實時的流媒體系統(tǒng)，這是因為對應于媒體分段的大小和持續(xù)時間有一定潛在的時間延遲。在客戶端中，至少在一個分段媒體文件被完全下載之后才能夠開始播放，而
通常要求下載完成兩個分段媒體文件之后才開始播放以保證不同分段音視頻之間的無縫連接。此外，在客戶端開始下載之前，必須等待服務器端的編碼器和流分割器至少生成一個TS文件，這也會帶來潛在的時延。在推薦配置下，HTTP Live Streaming系統(tǒng)的典型時延約在30s左右。

4. 網絡自適應的流間切換和故障保護

在基于HTTP Live Streaming的流媒體系統(tǒng)中，服務器可以為同一節(jié)目源準備多份以不同碼率和質量編碼的替換流，并為每個替換流都生成一個衍生的索引文件。在主索引文件中通過包含一系列指向其他衍生索引文件的URI指針來找到相應的替換流，如圖所示。

在移動互聯(lián)網環(huán)境下，由于網絡覆蓋面的不同和信號強弱的變化，移動終端可能隨時在不同的無線接入網絡(例如3G，EDGE，GPRS和WiFi等)之間進行切換。此時客戶端軟件可根據網絡和帶寬的變化情況隨時切換
到不同衍生索引文件所指向的替換流進行下載，從而自適應地為用戶提供相應網絡條件下接近最優(yōu)的音視頻QoS體驗。上述替換流和衍生索引文件機制除了可以用于基于帶寬波動的動態(tài)流間切換外，還可以用于服務器的故障保護。為此目的，首先在一臺服務器上按照正常流程生成一個媒體流或者多個替換流，以及對應的索引文件，然后再在另一臺服務器上生成一套并行的備份媒體流和索引文件。接下來將指向備份流的索引加入到主索引文件之中，使得其中針對每個帶寬值都對應有一個主媒體流和一個備份媒體流。例如，假定主服務器和備份服務器分別為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，從中獲取最高帶寬值替換流所對應的衍生索引文件，并進一步根據該索引文件下載相應的替換媒體流文件。

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

1.采集視頻源和音頻源的數據
2.對原始數據進行H264編碼和AAC編碼
3.視頻和音頻數據封裝為MPEG-TS包
4.HLS分段生成策略及m3u8索引文件
5.HTTP傳輸協(xié)議

三、RTSP (Real Time Streaming Protocol)

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

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

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

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

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

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

RTSP（Real Time Streaming Protocol），實時流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個應用層協(xié)議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協(xié)議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。類似HTTP協(xié)議的流控制協(xié)議。它們都使用純文本來發(fā)送信息，而且rtsp協(xié)議的語法也和HTTP類似，和HTTP協(xié)議相比RTSP協(xié)議所不同的地方是，RTSP協(xié)議是有狀態(tài)的協(xié)議，而HTTP是無狀態(tài)的協(xié)議。RTSP通過維護一個session來維護其狀態(tài)的轉換。RTSP協(xié)議的默認端口是554，默認的承載協(xié)議為TCP。

目前對于RTSP在IOS客戶端播放技術還是以FFMPEG+貼圖的方式為主。

四、架構：

出于便于管理和擴展，帶寬限制和多用戶并發(fā)的考慮，商用方案都會采用流媒體服務器+WEB服務器+中轉服務器+手機客戶端的方案，其中：

• 流媒體服務器(streaming server)負責采集視頻源并壓縮編碼并隨時等待來自客戶端的rtsp連接請求；
• WEB服務器(web server)便于發(fā)布和管理視頻信息；
• 中轉服務器(transmission server）是可選的，用于把來自client的RTSP請求轉發(fā)給server,并把服務器端的實時流轉給client，這樣的好處是在相同帶寬下支持更多的用戶同時觀看；
• 手機客戶端(client)可以用手機內置的播放器（如nokia上的realplayer)或者自己開發(fā)的獨立播放器，前者的好處是降低用戶使用門檻，便于大規(guī)模應用；后者方便擴展和定制，滿足更多的功能。

streaming server是整個方案的核心，目前主流的流媒體服務器解決方案如下：

1. helix server :借助Real公司的強大實力，這是目前最流行的方案， 可以支持所有音視頻格式，性能穩(wěn)定，是唯一可以橫跨 Windows Mac 及 Linux， Solaris ，HP/UX 使用者流媒體服務的平臺，支持在手機自帶播放器播放。helix server免費的版本只支持1M流量，企業(yè)版很貴。當然你要就是另外一回事了
2. darwin server: 這是apple公司推出的開源的流媒體解決方案，支持格式沒helix那么多，但由于是開源的免費的，對于開發(fā)者有很大的開發(fā)空間。
3. live555 media server:性能穩(wěn)定,但支持格式比較少(只有mp3,amr,aac,mpeg4 es等幾種流)，很少獨立使用而一般作為系統(tǒng)的一部分。
4. Windows Media Server：僅限微軟平臺，就不考慮了。

手機端框架流程如下：
手機客戶端與服務器端的傳輸協(xié)議目前常用有HTTP,RTSP兩種：
早期的手機電視多用的HTTP，HTTP的優(yōu)點有不用特殊的服務器軟件，有IIS即可，不用考慮防火墻NAT，但HTTP不支持實時流，也會浪費帶寬；
RTSP則是當前流媒體傳輸的主流標準，連微軟都拋棄了MMS而轉而支持RTSP， RTSP可以支持客戶端暫?；胤磐Ｖ沟炔僮?，基本不用考慮音視頻同步問題（因為音頻視頻分別從不同RTP PORT讀入緩沖）。值得說明的是，RTSP成功后，就開始RTP傳輸，分為RTP OVER TCP和RTP OVER UDP，前者保證每個數據包都能收到，如果沒收到就重傳，而且不用考慮防火墻NAT；后者只保證盡最大努力的傳輸，不會重傳丟幀，實時性好，要解決防火墻NAT問題。如果對幀率要求比較高的手機電視，推薦采用UDP傳輸，因為延遲較大的重傳數據對用戶是沒有意義的，寧可丟棄。

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

視頻解碼部分當然還是采用ffmpeg,移植了mpeg4 sp/h.264解碼器，在沒有任何優(yōu)化的情況下可支持32K,CIF,5-10fps的效果，對于一般的流媒體應用足夠了。以后還要經過算法和匯編優(yōu)化。解碼后還需要經過yuv2rgb和scale，需要注意的是ffmpeg的解碼有消隱區(qū)的說法，即qcif的圖像其linesize不是176而是192，如果你發(fā)現解碼后圖像呈綠色，需用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漸進下載唯一顯著的優(yōu)點在于它僅需要維護一個標準的Web服務器，而這樣的服務器基礎設施在互聯(lián)網中已經普遍存在，其安裝和維護的工作量和復雜性比起專門的流媒體服務器來說要簡單和容易得多。然而其缺點和不足卻也很多，首先是僅適用于點播而不支持直播，其次是缺乏靈活的會話控制功能和智能的流量調節(jié)機制，再次是客戶端需要硬盤空間以緩存整個文件而不適合于嵌入式設備等。基于RTSP/RTP的流媒體系統(tǒng)專門針對大規(guī)模流媒體直播和點播等應用而設計，需要專門的流媒體服務器支持，與HTTP漸進下載相比主要具有如下優(yōu)勢：

1. 流媒體播放的實時性。與漸進下載客戶端需要先緩沖一定數量媒體數據才能開始播放不同，基于RTSP/RTP的流媒體客戶端幾乎在接收到第一幀媒體數據的同時就可以啟動播放。

2. 支持進度條搜索、快進、快退等高級VCR控制功能。

3. 平滑、流暢的音視頻播放體驗。在基于RTSP的流媒體會話期間，客戶端與服務器之間始終保持會話聯(lián)系，服務器能夠對來自客戶端的反饋信息動態(tài)做出響應。當因網絡擁塞等原因導致可用帶寬不足時，服務器可通過適當降低幀率等方式來智能調整發(fā)送速率。此外，UDP傳輸協(xié)議的使用使得客戶端在檢測到有丟包發(fā)生時，可選擇讓服務器僅選擇性地重傳部分重要的數據(如關鍵幀)，而忽略其他優(yōu)先級較低的數據，從而保證在網絡不好的情況下客戶端也仍能連續(xù)、流暢地進行播放。

4. 支持大規(guī)模用戶擴展。普通的Web服務器主要針對大量小的HTML文件下載而進行優(yōu)化，在傳輸大容量媒體文件方面缺少性能優(yōu)勢。而專業(yè)的流媒體服務器在大容量媒體文件硬盤讀取、內存緩沖和網絡發(fā)送等方面進行了優(yōu)化，可支持大規(guī)模用戶接入。

5. 支持網絡層多播。網絡層多播允許單一媒體流共享網絡路徑，同時發(fā)送到多個客戶端，可大大縮減網絡帶寬需求。只有借助專門的流媒體服務器才能實現這一功能。
6. 內容版權保護。在漸進下載模式中，下載后的文件緩存在客戶端硬盤的臨時目錄中，用戶可將其拷貝至其他位置供以后再次播放。而在基于RTSP/RTP的流媒體系統(tǒng)中，客戶端只在內存中維持一個較小的解碼緩沖區(qū)，播放后的媒體數據隨時清除，用戶不容易截取和拷貝。

此外還可利用DRM等版權保護系統(tǒng)進行加密處理。盡管如此，基于RTSP/RTP的流媒體系統(tǒng)在實際的應用部署特別是移動互聯(lián)網應用中仍然遇到了不少問題，主要體現在：

1. 與Web服務器相比，流媒體服務器的安裝、配置和維護都較為復雜，特別是對于已經建有CDN(內容分發(fā)網絡)等基礎設施的運營商來說，重新安裝配置支持RTSP/RTP的流媒體服務器工作量很大。

2. RTSP/RTP協(xié)議棧的邏輯實現較為復雜，與HTTP相比支持RTSP/RTP的客戶端軟硬件實現難度較大，特別是對于嵌入式終端來說。

3. RTSP協(xié)議使用的網絡端口號(554)可能被部分用戶網絡中的防火墻和NAT等封堵，導致無法使用。雖然有些流媒體服務器可通過隧道方式將RTSP配置在HTTP的80端口上承載，但實際部署起來并不是特別方便。

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

HTTP漸進下載、RTSP/RTP和HTTP Live Streaming等三種流媒體協(xié)議，對各自的基本方法和特點進行了介紹，特別是對HTTP Live Streaming協(xié)議進行了較為詳細的描述，并在此基礎上對三種流媒體協(xié)議進行了對比分析。總體來說，
HTTP漸進下載系統(tǒng)部署起來最為簡單，但僅適用于較小規(guī)模的短視頻點播應用；
基于RTSP/RTP的協(xié)議棧適合于大規(guī)?？蓴U展的交互式實時流媒體應用，但需要專門流媒體服務器的支持，安裝和維護起來都較為復雜；
HTTP Live Streaming可直接部署于目前擁有廣泛運營基礎的Web服務器網絡環(huán)境，不需要對網絡基礎設施進行升級改造，特別適合于對實時性要求不是太高的消費級移動互聯(lián)網流媒體應用。