基于Android的移動(dòng)終端流媒體系統(tǒng)的研究

羅其朝，李太君，李延龍

(海南大學(xué)信息科學(xué)技術(shù)學(xué)院，海南?？?70228)

自從Google公司在2007年11月5日推出了基于Linux內(nèi)核的開(kāi)源操作系統(tǒng)Android以來(lái)，Android憑借其良好的用戶體驗(yàn)、低廉的成本和較高的開(kāi)放性吸引著越來(lái)越多的終端廠商.Android具有以下優(yōu)點(diǎn):1)開(kāi)源軟件眾多;2)操作方式新穎，可玩性高;3)不斷地創(chuàng)新，并將其他系統(tǒng)遠(yuǎn)拋于后面;4)價(jià)格低廉，更適合工薪階層.

隨著無(wú)線通信技術(shù)和多媒體技術(shù)的迅速發(fā)展，全球移動(dòng)終端用戶數(shù)越來(lái)越龐大，特別是第3代移動(dòng)通信技術(shù)(3G)在我國(guó)的不斷演進(jìn)與實(shí)現(xiàn)以及第4代移動(dòng)通信的商業(yè)式運(yùn)營(yíng)的今天，通過(guò)移動(dòng)通信網(wǎng)絡(luò)為移動(dòng)終端提供流媒體服務(wù)的業(yè)務(wù)也在迅速發(fā)展，更充足的帶寬給移動(dòng)流媒體技術(shù)的發(fā)展帶來(lái)了廣闊的前景，為豐富無(wú)線流媒體業(yè)務(wù)帶來(lái)了新的契機(jī).因此，移動(dòng)流媒體服務(wù)具有巨大的市場(chǎng)潛力，并成為移動(dòng)業(yè)務(wù)研究的熱點(diǎn)之一.近幾年，由于Android的興起，使得基于Android的技術(shù)開(kāi)發(fā)的需求日益增加，然而Android系統(tǒng)卻一直沒(méi)有高效的流媒體解碼模塊.而H.264作為高效的流媒體編解碼標(biāo)準(zhǔn)應(yīng)用于各類(lèi)的流媒體系統(tǒng)，取得了很好的實(shí)際效果.正是在這樣的背景下，筆者將高效的解碼模塊H.264移植到Android平臺(tái)的移動(dòng)終端，使其實(shí)現(xiàn)了對(duì)H.264的解碼播放，獲得了更高效的Android移動(dòng)終端的流媒體系統(tǒng).

1 Android移動(dòng)終端的流媒體系統(tǒng)設(shè)計(jì)

1.1 移動(dòng)終端的流媒體系統(tǒng)結(jié)構(gòu)設(shè)計(jì) 將整個(gè)系統(tǒng)分為3個(gè)部分:流媒體源采集與制作、無(wú)線通信網(wǎng)絡(luò)傳輸、Android移動(dòng)終端解碼播放，系統(tǒng)結(jié)構(gòu)如圖1所示.前端主要使用3種方式來(lái)獲取流媒體源信息，使用實(shí)時(shí)采集設(shè)備對(duì)流媒體源信息進(jìn)行實(shí)時(shí)的采集;從存儲(chǔ)磁盤(pán)中獲取相應(yīng)的流媒體源信息;對(duì)其他的媒體素材進(jìn)行轉(zhuǎn)碼得到流媒體源信息.

1.2 流媒體的無(wú)線通信網(wǎng)絡(luò)傳輸 流媒體的無(wú)線通信網(wǎng)絡(luò)傳輸過(guò)程中所需的主要協(xié)議在TCP/IP協(xié)議棧［1］中的位置如圖2所示.

圖1 移動(dòng)終端的流媒體應(yīng)用系統(tǒng)結(jié)構(gòu)設(shè)計(jì)圖

圖2 流媒體協(xié)議在TCP/IP協(xié)議棧中的位置

Android支持RTSP/RTP的直播方案，在流式傳輸?shù)膶?shí)現(xiàn)方案中，協(xié)議的使用決定了數(shù)據(jù)是否能有效、可靠的傳輸.本系統(tǒng)主要協(xié)議的使用過(guò)程為:Android移動(dòng)終端采用了應(yīng)用層協(xié)議RTSP向流媒體服務(wù)器請(qǐng)求流媒體數(shù)據(jù);流媒體服務(wù)器接收到移動(dòng)終端的數(shù)據(jù)請(qǐng)求后，對(duì)相應(yīng)的流媒體源進(jìn)行數(shù)據(jù)的采集并制作成流媒體數(shù)據(jù)，再經(jīng)傳輸層處理成RTP數(shù)據(jù)包，然后該數(shù)據(jù)包經(jīng)過(guò)傳輸層RTP/UDP協(xié)議、網(wǎng)絡(luò)層IP協(xié)議以及WLAN等無(wú)線協(xié)議發(fā)送給Android移動(dòng)終端.實(shí)時(shí)傳輸?shù)木W(wǎng)絡(luò)協(xié)議RTP(Real-time Transport Protocol)是用于Internet/Intranet針對(duì)多媒體數(shù)據(jù)流的一種傳輸協(xié)議.RTP協(xié)議本身包括2個(gè)部分:RTP數(shù)據(jù)傳輸協(xié)議和RTP傳輸控制協(xié)議，即RTCP(RTP Control Protocol).RTCP為RTP提供了可靠與有效的保障機(jī)制，確保了數(shù)據(jù)傳輸?shù)挠行耘c可靠性［2］.

2 Android移動(dòng)終端的解碼技術(shù)

Android的多媒體框架在2.2版本之前是Open Core.Open Core系統(tǒng)提供的解碼格式較少，Open Core支持的音頻格式有:3GPP(.3gp)，MPEG-4(.mp4，.m4a)，mp3，Type 0 and 1(.mid，.xmf，.mxmf)，RTTTL/RTX(.rtttl，.rtx)，OTA(.ota)，Melody(.imy)，Ogg(.ogg)，WAVE(.wav);支持的視頻格式只有 2 種:3gp和mp4，并沒(méi)有對(duì)H.264的解碼.在2.3版本之后是Stagefright，也沒(méi)有對(duì)H.264的解碼.Android幾個(gè)版本的推出都缺乏對(duì)流媒體的解碼，所以，要基于Android系統(tǒng)來(lái)開(kāi)發(fā)移動(dòng)終端的流媒體系統(tǒng)，就需要將相應(yīng)的流媒體解碼模塊移植到Android系統(tǒng).

面對(duì)復(fù)雜的無(wú)線傳輸環(huán)境，編碼方式對(duì)移動(dòng)終端的接收至關(guān)重要.H.264是由ITU和ISO/IEC聯(lián)合制定的.在不同的測(cè)試速率下，H.264的峰值信噪比(PSNR)比MPEG-4平均要高2 dB，比H.263平均要高3 dB［3］.其擁有的高效壓縮比以及所提供的網(wǎng)絡(luò)適應(yīng)機(jī)制在很大程度上適應(yīng)了無(wú)線通信條件下帶寬窄以及網(wǎng)絡(luò)狀況不穩(wěn)定等情況.使用H.264編碼標(biāo)準(zhǔn)進(jìn)行編碼的流媒體數(shù)據(jù)能很好地適應(yīng)在無(wú)線通信網(wǎng)絡(luò)下的傳輸［4］，H.264也因此成為在無(wú)線通信環(huán)境下流媒體傳輸優(yōu)先考慮的視頻壓縮標(biāo)準(zhǔn).

3 Android移動(dòng)終端H.264解碼播放的實(shí)現(xiàn)

3.1 H.264解碼原理 H.264標(biāo)準(zhǔn)編解碼流程主要包括著5個(gè)部分:幀間和幀內(nèi)預(yù)測(cè)、變換和反變換、量化和反量化、環(huán)路濾波以及熵編碼.其利用到的技術(shù)有:運(yùn)動(dòng)預(yù)測(cè)技術(shù)，能使時(shí)間冗余達(dá)到最小;幀內(nèi)預(yù)測(cè)編碼模式技術(shù)，能使空間冗余達(dá)到最小;將運(yùn)動(dòng)預(yù)測(cè)與幀內(nèi)編碼的技術(shù)變換到頻域中，減少了因壓縮而出現(xiàn)的錯(cuò)誤;熵編碼，可以用來(lái)減小數(shù)字表示的信號(hào)冗余度的可變字長(zhǎng)無(wú)損編碼方法.

流媒體是一種流式傳輸?shù)募夹g(shù)，是將所接收到的數(shù)據(jù)的開(kāi)始部分存入內(nèi)存，對(duì)數(shù)據(jù)包進(jìn)行緩存，到一定的存儲(chǔ)量時(shí)使視頻正確輸出，實(shí)現(xiàn)邊下載邊播放，這種流式技術(shù)大大縮短了啟動(dòng)時(shí)延，大量降低了對(duì)系統(tǒng)緩存容量的要求，并減少了客戶端用戶的等待時(shí)間.經(jīng)過(guò)無(wú)線網(wǎng)絡(luò)的傳輸并正確接收后，流媒體信息面對(duì)的問(wèn)題就是對(duì)這些數(shù)據(jù)進(jìn)行解碼播放，對(duì)H.264的解碼，是從NAL接收到的前端流媒體服務(wù)器進(jìn)行壓縮處理過(guò)的數(shù)據(jù)流中進(jìn)行熵解碼，并在重排序后獲得一系列量化系數(shù)，然后通過(guò)反量化以及反變換獲得殘差的數(shù)據(jù)模塊.而同時(shí)解碼器使用解碼的頭信息創(chuàng)建預(yù)測(cè)的數(shù)據(jù)模塊，殘差的數(shù)據(jù)模塊與預(yù)測(cè)的數(shù)據(jù)模塊相加后所得到的數(shù)據(jù)經(jīng)過(guò)濾波后就得到視頻數(shù)據(jù)，實(shí)現(xiàn)了對(duì)H.264的解碼［5］.如圖3所示，解碼圖像還原顯示是將視頻數(shù)據(jù)轉(zhuǎn)化成RGB數(shù)據(jù)顯示在屏幕上［6］.

圖3 H.264的解碼器功能框圖

3.2 H.264移植到Android的實(shí)現(xiàn) 實(shí)現(xiàn)基于FFmpeg的全功能的播放器比較容易，并且成本比較低，本文的解碼器參考開(kāi)源項(xiàng)目FFmpeg，選擇移植FFmpeg到Android平臺(tái)，雖然軟解碼的速度會(huì)比硬解碼的速度慢，但是隨著手機(jī)硬件的飛速發(fā)展，軟解碼完全能滿足實(shí)際要求.將FFmpeg移植到Android平臺(tái)上，可實(shí)現(xiàn)本文的Android終端的H.264解碼部分.

JNI(Java Native Interface)是Java本地接口，通過(guò)它提供了若干的API，實(shí)現(xiàn)了將C庫(kù)與Java進(jìn)行銜接.解碼程序通過(guò)JNI把對(duì)H.264解碼的C語(yǔ)言庫(kù)與Java進(jìn)行銜接.移植的步驟如下:1.用Android ndk框架對(duì)FFmpeg源碼編譯成后綴為so的類(lèi)庫(kù)，該動(dòng)態(tài)鏈接庫(kù)文件就是FFmpeg框架.該so庫(kù)進(jìn)行JNI調(diào)用，可以由Java層調(diào)用的，而這些jni方法里用到的函數(shù)就是來(lái)自該so類(lèi)庫(kù);2.使用jni方式撰寫(xiě)C代碼，其中需要包含相應(yīng)的FFmpeg頭文件;3.撰寫(xiě)相應(yīng)的Android.mk文件，里面指定需要編譯的C代碼以及需要鏈接的動(dòng)態(tài)庫(kù);4.執(zhí)行ndk-build生成相應(yīng)的jni庫(kù);5.創(chuàng)建Android Java程序，代碼中LoadLibrary相應(yīng)FFmpeg庫(kù)以及剛才生成的jni庫(kù).值得注意的是Android ndk的Makefile文件，即Android.mk文件語(yǔ)法和普通的Makefile文件有很多不同之處，所以在跨平臺(tái)編譯FFmpeg源碼時(shí)一定不能還使用原來(lái)的Makefile文件.所以，想要移植就必須將FFmpeg里的Makefile文件全部替換為ndk中的Android.mk文件.移植到Android平臺(tái)最終為本文中播放器的解碼模塊，將解碼后的視頻數(shù)據(jù)用Bitmap顯示，Draw到Surface-View的方法顯示到手機(jī)屏上.移動(dòng)終端(手機(jī)或PDA掌上電腦)，其中央處理器的速度和PC相比，其運(yùn)算速度相對(duì)比較慢，在短時(shí)間內(nèi)不可能得到很快提升.所以，移動(dòng)終端的流媒體應(yīng)用程序的編解碼必須嚴(yán)格地規(guī)范［7］，最基本的要求就是做到程序代碼合理科學(xué).

4 實(shí)驗(yàn)與分析

本文中Android移動(dòng)終端的H.264解碼器的模擬所用的工具為:

1)Android SDK為Android-sdk_r18-Windows版;

2)IDE 開(kāi)發(fā)環(huán)境是 Eclipse 3.7IDE for Java Developers版，ADT 為18.0.0版;

3)PC主機(jī)開(kāi)發(fā)環(huán)境是Windows XP，酷睿雙核T6570，內(nèi)存為2G.

實(shí)驗(yàn)測(cè)試采用了4個(gè)QCIF格式的標(biāo)準(zhǔn)序列:Foreman，Mother＆Daughter，Claire和Grandma，序列都經(jīng)過(guò) H.264開(kāi)源編碼器JM10.1的Baseline編碼，將4個(gè)測(cè)試文件在Android上進(jìn)行解碼.解碼得到的效果如圖4所示.

在Android1.6模擬器上顯示了移植的H.264解碼器對(duì)測(cè)試文件的解碼效果，從測(cè)試結(jié)果可看出，對(duì)QCIF格式的標(biāo)準(zhǔn)序列的H.264碼流解碼后，播放的畫(huà)面流暢、平穩(wěn)，播放速度達(dá)到18～35 fps.在無(wú)線通信網(wǎng)絡(luò)帶寬不足的情況下，H.264能夠提供比H.263，MPEG-4等更好的播放效果.在無(wú)線通信網(wǎng)絡(luò)狀況好的情況下，H.264的流媒體解碼播放基本滿足了實(shí)時(shí)性的要求.

圖4 解碼效果圖

5 小結(jié)

隨著無(wú)線通信網(wǎng)絡(luò)的快速發(fā)展，基于Android移動(dòng)終端的流媒體系統(tǒng)的應(yīng)用將有廣闊的發(fā)展前景.本文基于Android平臺(tái)的特點(diǎn)，設(shè)計(jì)并介紹了應(yīng)用于Android移動(dòng)終端的流媒體系統(tǒng).并將高效的H.264解碼標(biāo)準(zhǔn)實(shí)際移植到Android平臺(tái)，同時(shí)作為該系統(tǒng)中移動(dòng)終端播放的解碼模塊.實(shí)驗(yàn)效果表明，本文所介紹的應(yīng)用系統(tǒng)完全能適用于實(shí)際的Android移動(dòng)終端流媒體應(yīng)用.

［1］王亞琴，董彥榮，薄靜儀.流媒體傳輸協(xié)議及應(yīng)用［J］.辦公自動(dòng)化，2009(24):36－38.

［2］吳海軍.淺談流媒體的傳輸技術(shù)［J］.科技信息，2011(14):239－240.

［3］WIEGAND T，SULLIVAN G J.Overview of the H.264/AVC video coding standard［J］.IEEE Transactions，2003，7(13):560－576.

［4］劉易，李太君.3G移動(dòng)終端流媒體播放技術(shù)的研究［J］.通信技術(shù)，2011，44(3):123－124.

［5］畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)H.264/AVC［M］.北京:人民郵電出版社，2005:245－257.

［6］寇毅，朱志祥.基于H.264標(biāo)準(zhǔn)的視頻編解碼器軟終端的一種實(shí)現(xiàn)［J］.西安郵電學(xué)院學(xué)報(bào)，2006，11(5):47－51.

［7］龔琪琳.基于H.264協(xié)議的手機(jī)實(shí)時(shí)視頻播放的研究［J］.計(jì)算機(jī)與現(xiàn)代化，2010(1):90－91.