移動流媒體技術及其應用發展方向

原文地址: http://www.cnblogs.com/frankboy/archive/2005/12/13/296429.html

　一、 現狀分析

在手機增值業務市場，簡訊、彩信、彩e等雖然有了互動、24小時不間斷等不同於傳統媒體的特點，但傳輸的主要是靜態為主的影像和文字內容，影響了其媒體作用的充分發揮。隨著終端使用者需求的提升，如何更好地融合聲音、文字、影像，支援多媒體功能，既發揮簡訊方便、快捷的優點，又可以彌補簡訊形式單調的不足，真正使移動使用者”振聾發聵”，進入一個有聲有色、逼真形象的美麗世界成為移動運營商普遍關心的話題。 

流媒體（Streaming Media）的出現改變了這種狀況。它不需要下載整個檔案就可以在向播放器傳輸的過程中一邊下載一邊播放，實現了在網上點播或觀看電影、電視的夢想。現在，以”流”的形式進行數字媒體的傳送，使人們一定的頻寬環境下就可以線上欣賞到連續不斷的高品質音訊和視訊節目。在網際網路大發展的時代，流媒體技術的產生和發展必然會給我們的日常生活和工作帶來深遠的影響。專家預言，流媒體將成為未來因特網上應用的主流，實現溝通和傳播的多向性使傳播不再受時間和空間的限制。
所謂流媒體是指使用者通過網路或者特定數字通道邊下載邊播放多媒體資料的一種工作方式。流媒體應用的一個最大的好處是使用者不需要花費很長時間將多媒體資料全部下載到本地後才能播放，而僅需將起始幾秒的資料先下載到本地的緩衝區中就可以開始播放，後面收到的資料會源源不斷輸入到該緩衝區，從而維持播放的連續性，因此流媒體播放器通常只是在開始時有一些時延。流媒體系統要比下載播放系統複雜得多，所以需要將多媒體的編解碼和傳輸技術很好地結合在一起，才能確保使用者在複雜的網路環境下也能得到較穩定的播放質量。
多媒體資料在傳輸前必須要先經過編碼器有效地壓縮成碼流，以減少對網路資源的佔用率。目前常用的視訊編碼器有MPEG-2、MPEG-4、H.261、H.263、H.264、Window Media視訊編碼器和Real System視訊編碼器等；編碼器有MP3、MPEG AAC、Window Media 音訊編碼器和AMR等；影像編碼器有JPEG和JPEG2000等。多媒體編碼器所生成的碼流只包含了解碼該碼流所必需的資訊，它不包含媒體間的同步、隨機訪問等系統資訊，因此編碼後的多媒體資料還要被組織成為具有特定系統格式的多媒體檔案用於流媒體傳輸或者是存入磁碟中，目前常用的檔案格式有MPEG-2系統，MP4，微軟公司的ASF，Real的檔案格式，QuickTime的檔案格式以及用於3G無線服務的3GPP和3GPP2等等。 
當流媒體在實時應用中（如現場流媒體廣播），根據當前的網路狀況和使用者的終端引數，多媒體資料是一邊被編碼一邊被流媒體伺服器傳輸給使用者。而在其他的非實時應用中，多媒體資料可以被事先編碼生成多媒體檔案，儲存在磁碟陣列中。當提供多媒體服務時，流媒體伺服器直接讀取這些檔案傳輸給使用者，這樣服務方式對裝置的要求較低。目前許多流媒體服務屬於後一種方式，這樣就要求流媒體伺服器具有一定的機制來適應網路狀況和使用者裝置。 
目前碼流自適應這一模組主要採用的方法有：將多媒體檔案中的視訊碼流轉換為一個特定位元速率和影像尺寸的碼流；或者把同一段視訊內容編碼生成多個具有不同位元速率和影像尺寸的碼流，然後自適應選擇一個最合適的碼流傳輸給使用者。生成的碼流還需要進一步打包成為特定網路傳輸協議的資料包用於網路傳輸，由於現在許多網路並不能保證傳輸的資料能夠及時並完全正確地被使用者收到，傳輸的資料包可能需要加前向糾錯編碼（FEC）來保護，經過這些處理後多媒體資料就可以通過網路傳輸給使用者，目前常用的傳輸協議有RTP/RTCP、HTTP和MMS。 
使用者收到傳輸的資料後，如果存在丟包或者是位元出錯，錯誤恢復處理會根據附加的糾錯資料來恢復傳輸錯誤。如果還不能恢復傳輸錯誤，使用者端可以向伺服器發出重傳請求，在解碼開始前重新傳輸丟失的包。恢復後的多媒體資料將由解碼器解碼得到重構的多媒體資料，由於容錯保護和資料重傳可能不能恢復所有的錯誤資料，錯誤掩藏模組可以利用重構的多媒體資料的相關性來掩蓋這些錯誤，最後這些資料就播放給使用者。
通常流媒體系統中的伺服器和使用者間並不是單向通訊，如前面提到的重傳請求。事實上，使用者端會傳遞給伺服器許多反饋資訊，如終端裝置的能力和網路連線速度會傳給伺服器的碼流自適應模組來調整碼流，在實時應用中這些資訊還可能傳給編碼器；使用者端的丟包率、資料包收到的時間資訊和使用者緩衝區狀態等資訊也會傳遞給伺服器來估計當前的網路狀況，從而控制碼流的自適應和資料的傳送策略。從上面的描述來看，實際上流媒體系統在多媒體資訊處理中是一個非常複雜的系統，目前市面上主要的產品有微軟公司的Windows Media， Real公司的Real System和蘋果公司的QuickTime，其中Windows Media系統的市場佔有率最大。 

二、流媒體的關鍵技術

實現流媒體的關鍵技術是流式傳輸。流式傳輸的定義很廣泛，主要是指通過網路傳送媒體（如視訊、音訊）的技術總稱。
流式傳輸分為順序流式傳輸和實時流式傳輸：
順序流式傳輸採用順序下載方式，在下載檔案的同時使用者可觀看線上節目，在給定時刻，使用者只能觀看已下載的那部分，而不能跳到還未下載的部分，這種方式不像實時流式傳輸那樣，可以在傳輸期間根據使用者連線的速度進行調整。順序流式傳輸不適合長片段和有隨機訪問要求的視訊節目，如講座、演說和演示等，它也不支援現場廣播。嚴格地說，它是一種點播技術。
實時流式傳輸可保證媒體訊號頻寬與網路連線匹配，可實時觀看節目。實時流與HTTP流式傳輸不同，它需要專用的流媒體伺服器與傳輸協議。實時流式傳輸總是實時傳送，特別適合現場事件，也支援隨機訪問，使用者可對觀看內容進行快進或後退。理論上，實時流一經播放就不可停止，但可進行週期暫停。
流式傳輸模式一般會使用RTP/UDP、RTSP/TCP兩種通訊協議與A/V（Audio/Video）Server建立聯絡，將伺服器的輸出重定向到一個執行A/V Player程式所在客戶機的目的地址。如圖1所示，流式傳輸系統一般都要配置一套專用的伺服器和播放器。

1、實時傳輸協議RTP、RTCP
RTP（Real-time Transport Protocol）是在Internet上針對多媒體資料流的一種傳輸協議，工作於一對一或一對多的傳輸情況，可提供時間資訊和實現流同步。RTP通常使用UDP來傳送資料，也可在TCP或ATM協議之上工作。當應用程式開始一個RTP會話時，會使用到兩個埠，一個給RTP，一個給RTCP。RTP本身並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，而是依靠RTCP提供這些服務。通常RTP演算法並不作為一個獨立的網路層來實現，而是作為應用程式程式碼的一部分。
RTCP（Real-time Transport Control Protocol）與RTP共同提供流量控制和擁塞控制服務。在RTP會話期間，參與者週期性地傳送RTCP包，這些包中含有已傳送資料包的數量、丟失資料包的數量等統計資料，伺服器可根據這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。RTP與RTCP的配合使用可有效地進行反饋，從而減小開銷，提高傳輸效率，非常適合傳送網上的實時資料。

2、實時流協議RTSP
實時流協議RTSP（Real-time Streaming Protocol）是由RealNetworks、Netscape共同提出的一種協議，它定義瞭如何使一對多應用程式有效地通過IP網路傳送多媒體資料。RTSP在體系結構上位於RTP、RTCP之上，它使用TCP或RTP完成資料傳輸。與HTTP相比，RTP傳送的是多媒體資料，而HTTP傳送HTML。在使用RTSP時，客戶機和伺服器均可發出請求，也就是說RTSP可雙向服務，而HTTP的請求是由客戶機發出，伺服器進行響應。

3、資源預訂協議RSVP
音視訊資料流對網路的延時比資料業務更敏感，如何在網路中傳輸高質量的音視訊資訊，除了頻寬要求之外，還需其它條件。RSVP（Resource Reservation Protocol）是一種正在開發的Internet資源預訂協議，它通過採取預留一部分網路資源（頻寬）的措施，在一定程度上為流媒體傳輸提供QoS。某些試驗性系統，如網路視訊會議工具vic就整合了RSVP。
3GPP UMTS視訊媒體編解碼技術規範是ITU-T H.263 profile 0 level 10，也是PSS必須使用的視訊解碼器。此外，PSS還應該支援H.263 Profile 3 Level 10解碼器和MPEG-4 Visual Simple Profile Level 0解碼器，在實際應用中，兩個視訊解碼器可選。最近提出的H.264標準也引起了業界的廣泛興趣，3GPP PSS R6也在積極考慮將其納入規範。

移動流媒體播放器：
移動流媒體終端播放器都採用H264視訊壓縮演算法進行優化加速，以適宜無線傳輸的低頻寬編碼 (15-25 kpbs) 可以傳輸更好質量的影像，或者用更少的頻寬傳輸相同質量的視訊。有這些技術的大廠家，如微軟， REAL ，處於市場的原因，僅開發在特別視訊手機上的應用，所以對於應用開發商來說，需要將播放器在各個移動終端上面做相應的移植工作。主要平臺有：
Pocket PC平臺
Dopod 686/696
Lenovo ET180/560
Daxian CU928/Eten P300B
Symbian平臺
Nokia 7650/6600/3650/7610/Nokia6260/6630/7610/6620/3620/3660/3600/3650/N-Gage/
索愛 P802/P908
Simens sx1/Sendo x
Panasonic X700/
Samsung SGH-D710
Linux平臺
Motorola A760
Smartphone平臺
Dopod515/535 
Moto8380/8390

三、移動流媒體的主要應用
（1）資訊服務 
包括財經資訊、新聞和即時體育播報、天氣資訊等服務。使用者只須通過簡單的接入門戶站點即可獲取大量資訊，也可以通過訂閱的方式使用資訊推送服務。資訊的內容可以以流媒體的方式提供。 
（2）娛樂服務 
包括卡通、音訊、視訊以及電視節目的精彩片段下載播放和線上播放。還可以提供移動遊戲、用手機看電視等服務。 
（3）通訊服務 
包括含有流媒體內容的彩信、視訊電話／會議等，使人們的溝通更加方便，更為豐富多彩。 
（4）監控服務 
主要包括交通監控和家庭監控。交通監控使交通部門能夠實時察看高速公路和主要道路的交通狀況，可檢視指定道路區間的路況，並可在途中通過定位服務來檢查各路段的交通情況。家庭監控可以實時監視家庭和辦公室的情況。只需安裝基於Web的數字視訊相機，並連線到Internet上就可以通過移動終端或PC監視家庭或辦公室。 
（5）定位服務 
可用來提供地圖和嚮導服務，並且可以預覽風景名勝、預定飯店和電影票等。未來幾年，移動流媒體業務將得到很大的發展，將會隨著網路和終端的不斷髮展而逐步實現。

四、移動流媒體的發展與限制

移動流媒體業務的開展給移動增值服務帶來了新的希望，2.5G、3G以及超3G無線網路的發展也使得流媒體技術可以被用到無線終端裝置上，目前中國聯通公司提供CDMA 1x，使用者網路頻寬最多可以達到100kbit/s，這已經足夠提供QCIF大小的流媒體服務；而且隨著3G無線網路的應用，使用者的網路頻寬可以達到384kbit/s。另一方面，手機裝置運算能力越來越強，儲存空間越來越大，不用說SMART Phone和Pocket PC等高階手機，就是一般的中檔手機，如Nokia 6610，也能實現基本的H.264的軟體解碼。 
面向無線網路的流媒體應用對當前的編碼和傳輸技術提出了更大的挑戰，首先，相對於有線網路而言，無線網路狀況更不穩定，除去網路流量所造成的傳輸速率的波動外，手持裝置的移動速度和所在位置也會嚴重地影響到傳輸速率，因此高效的可自適應的編碼技術至關重要。其次，無線通道的環境也要比有線通道惡劣的多，資料的誤位元速率也要高許多，而高壓縮的碼流對傳輸錯誤非常敏感，還會造成錯誤向後面的影像擴散，因此無線流媒體在信源和通道編碼上需要很好的容錯技術。在移動流媒體業務的發展過程中，存在如下問題： 
（1） 無線網路頻寬窄，干擾嚴重
CDMA1X與GPRS分別作為當前中國聯通與中國移動的主流2.5G無線網路技術，網路傳輸頻寬較之以前有了很大的提高,但仍然十分有限。CDMA1X在理論峰值情況下下載傳輸速率達到144kbps，但實際情況下，穩定的傳輸速率通常在70kbps左右。GRPS在理論上可以達到115kbps，但實際情況下，穩定的傳輸速率通常在20kbps左右。並且隨著使用使用者的增加，網路的效能將會進一步下降。另外無線網路的干擾嚴重，導致網路傳輸的誤碼的可能性大大增加。
（2） 移動終端處理能力低，記憶體容量小 
雖然目前國內市場上基於ARM9或是與此同等能力的晶片的高階手機已經越來越多，但由於手機中低端使用者基數龐大而帶來的巨大的市場商機，使得各個終端廠家對中低端使用者尤為重視。因此目前佔市場份額最多的、主流的手機仍然採用的是ARM7系列的晶片，處理能力在幾十個MIPS左右。 
目前移動終端的記憶體容量通常也比較有限。市場上主流的BREW手機預留給應用程式的動態記憶體通常在700KB左右；基於J2ME的手機預留給應用程式的動態分配的記憶體通常在64KB或128KB；基於Symbian/Linux/Windows Mobile等高階手機預留給應用程式的動態分配的記憶體在1-4MB左右。
（3） 終端系統平臺、LCD多樣化 
相對於PC的平臺而言，移動終端的系統平臺多樣化更加明顯，常見的系統平臺有Symbian、Linux、Windows Mobile、Palm OS以及一些私有平臺。移動終端系統多樣化在很長的一段時間內將會繼續存在。為了提供一個統一的手機應用程式執行環境，J2ME與BREW應運而生。但不同的廠家對J2ME與BREW的支援通常都存在差異。平臺的多樣化加上LCD大小不一，使得實現適應多種移動終端的應用程式難度非常大。
（4） 移動終端的電池能源有限
儘管手機裝置的運算能力越來越強，但是由於它是由電池供電的，因此編解碼處理不能太複雜，並且最好能夠根據使用者裝置的電池來調整流媒體的接收和處理，能源管理技術也是移動流媒體的一個研究熱點。

本文轉自peterzb部落格園部落格，原文連結：http://www.cnblogs.com/peterzb/archive/2009/05/16/1458454.html，如需轉載請自行聯絡原作者。