劉 誠(chéng)，段紅光，巴 義

（重慶郵電大學(xué) 移動(dòng)通信重點(diǎn)實(shí)驗(yàn)室，重慶 400065）

視頻監(jiān)控以其方便、直觀、信息內(nèi)容豐富而廣泛應(yīng)用于民用安全、城市交通等各個(gè)領(lǐng)域。移動(dòng)視頻監(jiān)控是視頻監(jiān)控在移動(dòng)網(wǎng)絡(luò)和移動(dòng)終端上的應(yīng)用，有廣闊的應(yīng)用前景，與傳統(tǒng)網(wǎng)絡(luò)視頻監(jiān)控相比，具有使用方便、網(wǎng)絡(luò)覆蓋面廣、實(shí)時(shí)性高等優(yōu)點(diǎn)[1]。

移動(dòng)視頻監(jiān)控技術(shù)對(duì)網(wǎng)絡(luò)帶寬、實(shí)時(shí)性等方面有嚴(yán)格的要求，由于目前移動(dòng)網(wǎng)絡(luò)還不完善、移動(dòng)終端性能還需要提升，在實(shí)際的應(yīng)用中上述性能要求還不能完全得到滿足，因此，對(duì)移動(dòng)視頻監(jiān)控客戶端進(jìn)行研究和設(shè)計(jì)就顯得非常重要。由于視頻監(jiān)控應(yīng)用數(shù)據(jù)量大、視頻解碼算法復(fù)雜，加之移動(dòng)終端在處理能力、內(nèi)存容量等方面又受到極大限制，因而在移動(dòng)終端上觀看視頻經(jīng)常會(huì)出現(xiàn)畫面模糊、停頓等問(wèn)題。為解決這些問(wèn)題，有必要對(duì)移動(dòng)流媒體傳輸技術(shù)和視頻解碼技術(shù)這兩項(xiàng)關(guān)鍵技術(shù)進(jìn)行研究，本文正是在此基礎(chǔ)上，設(shè)計(jì)并實(shí)現(xiàn)一個(gè)移動(dòng)視頻監(jiān)控系統(tǒng)客戶端，從而為用戶提供穩(wěn)定、流暢的視頻監(jiān)控服務(wù)。

1 系統(tǒng)設(shè)計(jì)方案

本文借鑒傳統(tǒng)的C/S設(shè)計(jì)模式，提出了一種更輕巧、簡(jiǎn)便的系統(tǒng)設(shè)計(jì)方案，如圖1所示。

該設(shè)計(jì)方案有效結(jié)合了嵌入式技術(shù)與流媒體技術(shù)，向開(kāi)發(fā)板中移植流媒體服務(wù)器和Web服務(wù)器，從而將采集端和服務(wù)端所有工作都集中在ARM開(kāi)發(fā)板上。而在客戶端，可以通過(guò)Android手機(jī)播放實(shí)時(shí)視頻的方式對(duì)交通情況進(jìn)行實(shí)時(shí)監(jiān)控。該系統(tǒng)運(yùn)行穩(wěn)定，成本低廉，具有理論的可行性和實(shí)際的可用性。本文側(cè)重對(duì)客戶端進(jìn)行研究和設(shè)計(jì)。

2 關(guān)鍵技術(shù)研究

2.1 移動(dòng)流媒體傳輸

移動(dòng)互聯(lián)網(wǎng)目前應(yīng)用最廣泛的3種流媒體協(xié)議為:HTTP漸進(jìn)下載流媒體協(xié)議，基于RTSP/RTP的實(shí)時(shí)流媒體協(xié)議棧，以及HTTP Live Streaming協(xié)議[2]。移動(dòng)流媒體所需的緩存小，對(duì)實(shí)時(shí)性要求很高，HTTP漸進(jìn)下載和HTTP LIVE STREAMING均不能很好的滿足這些要求?；赗TSP的協(xié)議棧的實(shí)時(shí)性，控制傳輸流的能力以及對(duì)網(wǎng)絡(luò)帶寬的自適應(yīng)能力都很強(qiáng)，因而能在較大程度上提高流媒體播放的質(zhì)量。除此之外，RTSP還能提供用于音視頻流的VCR遠(yuǎn)程控制功能。

移動(dòng)視頻監(jiān)控系統(tǒng)屬于低延遲實(shí)時(shí)流媒體系統(tǒng)，因此本文決定采用RTSP協(xié)議棧對(duì)客戶端進(jìn)行設(shè)計(jì)。RTSP協(xié)議棧如圖2所示。

2.2 視頻解碼

Android自帶的Media Player支持的媒體格式僅局限于OpenCore中所支持的媒體格式。FFmpeg是一個(gè)開(kāi)源免費(fèi)解決方案，能夠提供錄制、轉(zhuǎn)換、音/視頻編解碼等功能。其中的FFmpeg libavcodec是一個(gè)音/視頻編解碼類庫(kù)，能支持MPEG，MPEG-4等29多種編碼格式以及AVI，MPEG等90多種解碼格式。由于FFmpeg在軟件結(jié)構(gòu)設(shè)計(jì)上，將應(yīng)用層和編解碼實(shí)現(xiàn)層分離開(kāi)來(lái)，同時(shí)在編解碼實(shí)現(xiàn)層中又分別處理文件解析和視頻流編解碼這兩個(gè)過(guò)程[3]，因此向FFmpeg中添加格式就非常方便，具有良好的可擴(kuò)充性。另外，F(xiàn)Fmpeg還能夠很好地解決Android平臺(tái)直播的問(wèn)題。因此，本文將FFmpeg作為解碼方案移植到Android平臺(tái)上。

3 客戶端設(shè)計(jì)

客戶端主要完成如下功能:1）實(shí)現(xiàn)監(jiān)控視頻的播放/暫停；2）獲取服務(wù)端發(fā)送的視頻數(shù)據(jù)，并通過(guò)RTCP協(xié)議實(shí)時(shí)反饋RTP接收情況；3）實(shí)現(xiàn)遠(yuǎn)程控制云臺(tái)的轉(zhuǎn)動(dòng)。根據(jù)上述功能需求，將整個(gè)客戶端設(shè)計(jì)分成四大模塊[4]，即主控制模塊、RTP數(shù)據(jù)傳輸模塊、視頻解碼模塊以及UI模塊?？蛻舳塑浖軜?gòu)如圖3所示。

3.1 主控制模塊

主控制模塊是客戶端軟件的核心模塊，主要負(fù)責(zé)各模塊間的控制與通信。主模塊包括地址解析模塊、播放會(huì)話控制模塊等幾個(gè)子模塊。

3.1.1 媒體流解析控制

實(shí)時(shí)媒體流是基于RTP和RTCP的傳輸流，其解析控制流程比較復(fù)雜。首先地址解析模塊對(duì)從UI模塊發(fā)送來(lái)的文件路徑進(jìn)行解析，解析成功后，地址解析模塊會(huì)根據(jù)文件路徑判斷媒體流類型，如果是實(shí)時(shí)媒體流，則調(diào)用協(xié)議棧線程訪問(wèn)播放會(huì)話控制模塊。其中的子模塊SDP解析模塊會(huì)將URL根據(jù)SDP協(xié)議封裝成RTSP可以識(shí)別的格式，并發(fā)送給RTSP協(xié)議模塊。RTSP協(xié)議模塊根據(jù)TCP/IP協(xié)議向遠(yuǎn)程流媒體服務(wù)器發(fā)送URL查詢請(qǐng)求。最終地址解析模塊將服務(wù)器反饋的查詢結(jié)果發(fā)送到UI模塊。UI模塊根據(jù)查詢結(jié)果，進(jìn)行相應(yīng)的操作，如果查詢結(jié)果為同意訪問(wèn)，則UI模塊開(kāi)始執(zhí)行實(shí)時(shí)媒體流所支持的一些VCR功能。

3.1.2 RTCP協(xié)議模塊

該模塊實(shí)現(xiàn)并封裝了RTCP協(xié)議，主要用來(lái)配合RTP數(shù)據(jù)的傳輸。在整個(gè)RTP數(shù)據(jù)傳輸過(guò)程中，RTCP模塊會(huì)周期性地向遠(yuǎn)程流媒體服務(wù)器發(fā)送RTCP報(bào)文包，這些報(bào)文包包含了已發(fā)送以及已丟失的RTP數(shù)據(jù)包的數(shù)目等信息。這樣，遠(yuǎn)程流媒體服務(wù)器就可以根據(jù)這些信息動(dòng)態(tài)改變傳輸速率，從而為媒體視頻的播放提供QoS保證。

3.1.3 云臺(tái)控制模塊

云臺(tái)控制模塊的作用是控制云臺(tái)的轉(zhuǎn)動(dòng)方向，并對(duì)鏡頭進(jìn)行變焦、聚焦和光圈控制，從而做到多角度更全面的監(jiān)控[5]。

使用HTTP/TCP協(xié)議作為客戶端和服務(wù)器端之間的通信協(xié)議，保證了控制信號(hào)的可靠性。使用PELCO-D作為云臺(tái)控制協(xié)議，作為服務(wù)器和云臺(tái)解碼器之間的溝通協(xié)議。PELCO-D協(xié)議包括PTZ命令和擴(kuò)展命令，本文主要使用PTZ命令實(shí)現(xiàn)轉(zhuǎn)動(dòng)控制。該模塊的主要工作是根據(jù)PELCO-D協(xié)議把用戶UI操作封裝成數(shù)據(jù)包，然后利用TCP協(xié)議傳輸至Web服務(wù)器。

3.2 RTP數(shù)據(jù)傳輸模塊

RTP數(shù)據(jù)包包含了序列號(hào)、時(shí)間戳等信息，這些信息主要用于RTP數(shù)據(jù)包的同步處理。視頻數(shù)據(jù)在遠(yuǎn)程流媒體服務(wù)器端被分割成一個(gè)個(gè)RTP數(shù)據(jù)包，然后通過(guò)RTP/UDP/IP發(fā)送到客戶端，客戶端根據(jù)包頭中的信息，對(duì)數(shù)據(jù)包重新排序并丟棄重復(fù)的數(shù)據(jù)包。根據(jù)對(duì)RTP數(shù)據(jù)包處理過(guò)程，本文將RTP數(shù)據(jù)傳輸模塊劃分成3個(gè)子模塊，即RTP數(shù)據(jù)接收模塊、RTP包失序處理模塊、RTP包重組幀模塊。

3.2.1 RTP數(shù)據(jù)接收模塊

該模塊用于接收UDP協(xié)議模塊發(fā)送來(lái)的數(shù)據(jù)包并轉(zhuǎn)發(fā)出去。接收數(shù)據(jù)包之前，先查詢數(shù)據(jù)包的相關(guān)信息，例如包的類型、格式、大小等。該模塊只接收RTP數(shù)據(jù)包和RTCP報(bào)文包，其他類型的包丟棄。

3.2.2 RTP包失序處理模塊

在數(shù)據(jù)傳輸過(guò)程中，網(wǎng)絡(luò)延遲和抖動(dòng)等因素會(huì)導(dǎo)致數(shù)據(jù)包的到達(dá)順序發(fā)生混亂，因而必須對(duì)這些RTP數(shù)據(jù)包重新排序。在模塊中設(shè)置一個(gè)排序緩沖區(qū)，RTP數(shù)據(jù)包先進(jìn)入排序緩沖區(qū)，然后再進(jìn)行重新排序。

3.2.3 RTP包重組幀模塊

在網(wǎng)絡(luò)傳輸中，一幀視頻數(shù)據(jù)無(wú)法打包進(jìn)單個(gè)UDP報(bào)文，必須拆分并裝到幾個(gè)序列號(hào)連續(xù)、具有相同時(shí)間戳的RTP包中。已到達(dá)的RTP包先進(jìn)入一段緩沖隊(duì)列，后到的RTP包根據(jù)序列號(hào)插入到隊(duì)列中對(duì)應(yīng)的位置。RTP包重組幀模塊負(fù)責(zé)將緩沖隊(duì)列中具有相同時(shí)間戳的RTP包取出，并組合成一個(gè)完整的視頻幀，送到視頻解碼模塊中。

3.3 視頻解碼模塊

FFmpeg解決了Android OpenCore對(duì)播放格式支持的不足，同時(shí)能夠很好地解決Android平臺(tái)直播的問(wèn)題，所以本文將FFmpeg作為解碼方案移植到Android平臺(tái)上。

3.3.1 視頻解碼流程

FFmpeg提供了一系列多媒體數(shù)據(jù)處理函數(shù)[6]，利用這些函數(shù)可以完成視頻解碼。FFmpeg解碼流程如圖4所示。

圖3 FFmpeg解碼流程

av_register_all():完成FFmpeg系統(tǒng)支持的解碼格式注冊(cè)。av_find_stream_info():從文件中提取流信息。avcodec_find_decoder():尋找視頻流的解碼器。avcodec_open():打開(kāi)解碼器。avcodec_alloc_frame():為解出的每幀視頻分配一個(gè)緩存。av_get_frame():從待解碼緩沖區(qū)中提取一幀數(shù)據(jù)。avcodec_decode_video():以av_get_frame()的一幀數(shù)據(jù)為參數(shù)并將該幀數(shù)據(jù)解碼。av_set_frame():將解碼后的一幀數(shù)據(jù)封裝后，放入待播放緩沖區(qū)。av_has_next_frame():判斷帶解碼緩沖區(qū)是否還有數(shù)據(jù)幀，若有跳回av_get_frame()繼續(xù)往下執(zhí)行，若無(wú)則調(diào)用avcodec_close()，釋放解碼器，整個(gè)解碼流程結(jié)束。

3.3.2 FFmpeg到Android平臺(tái)的移植

FFmpeg代碼的開(kāi)發(fā)是基于Linux操作系統(tǒng)的，而Android終端受到處理能力和內(nèi)存容量等諸多限制，因此在移植時(shí)對(duì)FFmpeg代碼進(jìn)行修剪及優(yōu)化是十分必要的。修剪及優(yōu)化工作主要從以下3個(gè)方面進(jìn)行:1）只保留和文件解封裝和視頻解碼相關(guān)的代碼；2）修改configure文件，選擇適當(dāng)?shù)膬?yōu)化參數(shù)，將需要的文件封裝格式及其解碼格式編譯到鏈接庫(kù)；3）減少全局變量的使用、注意程序中字節(jié)對(duì)齊、不同類型間強(qiáng)制轉(zhuǎn)換、內(nèi)存分配等問(wèn)題。

Android的SDK基于Java實(shí)現(xiàn)，而FFmpeg是由C語(yǔ)言編寫完成的。利用NDK能夠幫助開(kāi)發(fā)者快速開(kāi)發(fā)C或C++的動(dòng)態(tài)庫(kù)[7]，并能自動(dòng)將.so文件和Java應(yīng)用一起打包成apk。移植時(shí)需要根據(jù)NDK中的Android.mk語(yǔ)法修改FFmpeg中自帶的makefile，然后使用NDK中的交叉編譯器進(jìn)行編譯。

3.4 UI模塊

該模塊實(shí)現(xiàn)了用戶交互與圖像顯示功能，將解碼輸出的YUV數(shù)據(jù)轉(zhuǎn)換成RGB數(shù)據(jù)，然后在屏幕上繪制出Bitmap圖片。除顯示圖片之外，還實(shí)現(xiàn)了一些額外功能，例如圖片縮放、云臺(tái)控制以及圖像抓拍等。本客戶端的界面是基于Android的GUI系統(tǒng)設(shè)計(jì)的，包括登錄界面和監(jiān)控界面?；贏ndroid平臺(tái)的手機(jī)是沒(méi)有外設(shè)按鍵的，針對(duì)云臺(tái)控制、圖像抓拍等功能，本文采用軟鍵盤的控制方法。在客戶端播放監(jiān)控視頻時(shí)，可以通過(guò)點(diǎn)擊MENU鍵調(diào)出隱藏式選單，如圖5所示。

4 客戶端功能測(cè)試

在WiFi環(huán)境下，使用Android SDK 2.3模擬器進(jìn)行功能測(cè)試。按照?qǐng)D6所示，完成登陸界面的配置，經(jīng)服務(wù)器驗(yàn)證通過(guò)后便出現(xiàn)監(jiān)控界面，如圖7所示。經(jīng)分析，用戶驗(yàn)證登陸、WiFi無(wú)線網(wǎng)絡(luò)遠(yuǎn)程監(jiān)控等功能均滿足預(yù)期設(shè)計(jì)。

5 小結(jié)

本文在對(duì)移動(dòng)流媒體傳輸、視頻解碼這兩個(gè)關(guān)鍵技術(shù)研究的基礎(chǔ)上，設(shè)計(jì)了一個(gè)基于Android平臺(tái)的視頻監(jiān)控客戶端，能夠較好地提供遠(yuǎn)程監(jiān)控服務(wù)，同時(shí)給基于其他平臺(tái)的監(jiān)控客戶端研究與設(shè)計(jì)提供重要的參考價(jià)值。因此該客戶端具有一定的實(shí)際意義和商業(yè)價(jià)值。

[1]賀禮，唐倫，陳前斌，等.移動(dòng)視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].電視技術(shù)，2007，31（6）:59-62.

[2]霍龍社，甘震.移動(dòng)流媒體協(xié)議綜述[J].信息通信技術(shù)，2010（4）:6-10.

[3]劉潔彬，宋茂強(qiáng).基于Android平臺(tái)的流媒體播放器的設(shè)計(jì)[EB/OL].[2012-06-20].http://wenku.baidu.com/view/b0051b00a6c30c2259019 e1f.html.

[4]閆卓.基于展訊TD_SCDMA平臺(tái)的手機(jī)流媒體播放軟件的設(shè)計(jì)與實(shí)現(xiàn)[D].西安:西安電子科技大學(xué)，2011.

[5]潘國(guó)輝.安防天下:智能網(wǎng)絡(luò)視頻監(jiān)控技術(shù)詳解與實(shí)踐[M].北京:清華大學(xué)出版社，2010.

[6]胡成，任平安，李文莉.基于Android系統(tǒng)的FFmpeg多媒體同步傳輸算法研究[J].計(jì)算機(jī)技術(shù)與發(fā)展，2011，21（10）:85-88.

[7]井洪亮.基于Android的H.264/AVC解碼器的設(shè)計(jì)與實(shí)現(xiàn)[D].哈爾濱:哈爾濱工業(yè)大學(xué)，2010.