基于Android平臺(tái)的實(shí)時(shí)監(jiān)控系統(tǒng)客戶端設(shè)計(jì)

趙紅超，李 琦，韓 瑾，李 鼎

(河北工業(yè)大學(xué) 電子信息工程學(xué)院，天津 300401)

基于Android平臺(tái)的實(shí)時(shí)監(jiān)控系統(tǒng)客戶端設(shè)計(jì)

趙紅超，李 琦，韓 瑾，李 鼎

(河北工業(yè)大學(xué) 電子信息工程學(xué)院，天津 300401)

提出了一種基于Android手機(jī)平臺(tái)的遠(yuǎn)程監(jiān)控系統(tǒng)客戶端的設(shè)計(jì)方案。對(duì)系統(tǒng)中的各個(gè)模塊做了詳細(xì)地研究，并針對(duì)Android平臺(tái)設(shè)計(jì)了基于FFmpeg的解碼方案。系統(tǒng)采用P2P技術(shù)、多線程機(jī)制，并對(duì)數(shù)據(jù)做了緩存處理，從而實(shí)現(xiàn)了實(shí)時(shí)的監(jiān)視與控制性能。采用OpenGL ES渲染技術(shù)，大大提高了繪圖效率。

實(shí)時(shí)監(jiān)控；H.264；FFmpeg；AAC；GLSurfaceView；OpenGL；多線程

隨著4G時(shí)代的到來(lái)，移動(dòng)終端設(shè)備的高速智能化發(fā)展，各類智能手機(jī)操作系統(tǒng)性能不斷提高。由Google開(kāi)發(fā)的Android操作系統(tǒng)基于開(kāi)源Linux系統(tǒng)實(shí)現(xiàn)，其中底層采用C語(yǔ)言設(shè)計(jì)，而應(yīng)用層采用簡(jiǎn)便的Java語(yǔ)言進(jìn)行開(kāi)發(fā)[1]。其免費(fèi)開(kāi)源特性促進(jìn)了智能手機(jī)以及平板電腦的快速發(fā)展[2]，也為無(wú)線視頻監(jiān)控提供了很好的軟、硬件平臺(tái)。

視頻監(jiān)控具有悠久的發(fā)展歷史，在安防領(lǐng)域擁有重要角色，對(duì)人身安全和家庭財(cái)產(chǎn)安全的保護(hù)起到了關(guān)鍵的作用[3]。近年來(lái)，隨著網(wǎng)絡(luò)技術(shù)的快速發(fā)展[4]，以網(wǎng)絡(luò)、移動(dòng)通信技術(shù)為平臺(tái)的移動(dòng)視頻監(jiān)控，已經(jīng)越來(lái)越成熟，應(yīng)用范圍也越來(lái)越廣闊。移動(dòng)實(shí)時(shí)視頻監(jiān)控不受空間上的制約，實(shí)現(xiàn)了遠(yuǎn)程實(shí)時(shí)監(jiān)控。隨著“Any Time，Any Where，Any Device”等目標(biāo)[5]的提出，舊式的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)已經(jīng)滿足不了公民對(duì)生活質(zhì)量日益增長(zhǎng)的需求。基于Android平臺(tái)的移動(dòng)實(shí)時(shí)視頻監(jiān)控使這個(gè)問(wèn)題得到了解決，這項(xiàng)應(yīng)用在安防領(lǐng)域得到推廣后，很快將會(huì)在人民大眾家庭中得到普及。

本文在Android平臺(tái)下提出了實(shí)時(shí)監(jiān)控客戶端的設(shè)計(jì)與實(shí)現(xiàn)方法。通過(guò)Google提供的NDK開(kāi)發(fā)工具編譯生成可供Java調(diào)用的動(dòng)態(tài)鏈接庫(kù)，利用JNI機(jī)制實(shí)現(xiàn)Java與C的交互和相互調(diào)用，從而實(shí)現(xiàn)高效的系統(tǒng)性能。通過(guò)調(diào)用開(kāi)源的功能強(qiáng)大的FFmpeg多媒體編解碼框架[6]以及OpenGL ES圖像庫(kù)來(lái)對(duì)媒體數(shù)據(jù)進(jìn)行解碼和播放，實(shí)現(xiàn)了實(shí)時(shí)高清的監(jiān)控系統(tǒng)性能。

1 系統(tǒng)結(jié)構(gòu)

1.1 系統(tǒng)設(shè)計(jì)

本系統(tǒng)采用P2P技術(shù)，與傳統(tǒng)的客戶端——服務(wù)器模式不同，在P2P工作方式中每個(gè)客戶終端既是客戶機(jī)又是服務(wù)器。因此本系統(tǒng)不單單具有普通的客戶端監(jiān)視功能，還有對(duì)設(shè)備的控制功能，從而真正實(shí)現(xiàn)了實(shí)時(shí)的監(jiān)視與控制。本系統(tǒng)有兩個(gè)角色，分別是Client與Server。在Client模式下，手機(jī)作為Client來(lái)實(shí)時(shí)接收和顯示媒體數(shù)據(jù)，完成監(jiān)視視頻畫面、音頻播放、拍照及錄像功能；在Server模式下，手機(jī)又可以充當(dāng)Server角色來(lái)實(shí)現(xiàn)對(duì)設(shè)備的控制功能，包括視頻畫質(zhì)控制、燈的開(kāi)關(guān)控制、報(bào)警開(kāi)關(guān)控制、對(duì)攝像頭的方向調(diào)整控制以及與設(shè)備的對(duì)講。總體功能框架如圖1所示。

圖1 系統(tǒng)功能框架

1.2 系統(tǒng)Client模式

本視頻監(jiān)控系統(tǒng)的Client模式整體分為4個(gè)模塊，分別是數(shù)據(jù)接收模塊、數(shù)據(jù)解碼模塊、數(shù)據(jù)播放模塊和數(shù)據(jù)存儲(chǔ)模塊。接收模塊主要是利用LinkedList對(duì)音視頻數(shù)據(jù)進(jìn)行接收與緩存，解碼模塊負(fù)責(zé)對(duì)接收到的多媒體數(shù)據(jù)進(jìn)行相應(yīng)的解碼，數(shù)據(jù)播放模塊則根據(jù)一定的同步原則進(jìn)行音視頻的同步播放，存儲(chǔ)模塊即對(duì)拍照所獲圖片與錄像所得視頻進(jìn)行保存。系統(tǒng)Client模式流程如圖2所示。

圖2 系統(tǒng)Client模式流程

Android中的一個(gè)應(yīng)用程序?qū)?yīng)著一個(gè)進(jìn)程，一個(gè)進(jìn)程中有一個(gè)主線程(UI Thread)，主要負(fù)責(zé)UI界面的渲染、更新和控件間的交互，所以在主線程中執(zhí)行任務(wù)所需時(shí)間越短越好，為了避免阻塞，主線程應(yīng)將耗時(shí)較長(zhǎng)的事件交由子線程來(lái)處理。

由于對(duì)媒體數(shù)據(jù)的接收和解碼以及播放都是非常耗時(shí)的復(fù)雜和持續(xù)過(guò)程，若其中有一個(gè)過(guò)程阻塞就會(huì)影響整體程序的運(yùn)行，從而導(dǎo)致視頻卡頓不連續(xù)的現(xiàn)象，所以本系統(tǒng)使用多線程來(lái)并行處理對(duì)數(shù)據(jù)的接收、解碼和播放。本系統(tǒng)中共有6個(gè)子線程在同時(shí)工作，包括視頻接收子線程VideoThread、視頻解碼子線程VideoDecodeThread、視頻渲染子線程RenderThread、音頻接收子線程AudioThread、音頻解碼子線程AudioDecodeThread以及音頻播放子線程AudioWriteThread，從而使對(duì)音視頻數(shù)據(jù)的接收、解碼與播放分別處于不同的子線程，并將結(jié)果交由主線程來(lái)處理，有效地解決了主線程阻塞問(wèn)題。

1.2.1 數(shù)據(jù)接收模塊

數(shù)據(jù)接收模塊主要與遠(yuǎn)程服務(wù)會(huì)話，然后根據(jù)會(huì)話結(jié)果接收遠(yuǎn)程攝像頭所監(jiān)控的視頻數(shù)據(jù)。由于受到網(wǎng)絡(luò)不穩(wěn)定性的影響，到達(dá)客戶端的數(shù)據(jù)包會(huì)出現(xiàn)抖動(dòng)或時(shí)延，為了避免這種現(xiàn)象的發(fā)生，接收模塊采用緩沖機(jī)制。首先為了能夠完成保存每一幀數(shù)據(jù)和信息，創(chuàng)建VideoData類和AudioData類，其中VideoData類中保存著編碼類型、幀數(shù)據(jù)、幀類型、幀大小、時(shí)間戳和幀編號(hào)，同樣AudioData類中保存著編碼類型、幀數(shù)據(jù)、幀大小、時(shí)間戳和幀編號(hào)；然后利用Java中的LinkedList對(duì)數(shù)據(jù)進(jìn)行緩沖，緩沖示意圖如圖3所示。

圖3 緩沖示意圖

LinkedList是Java中的雙向列表，是基于鏈表的數(shù)據(jù)結(jié)構(gòu)。LinkedList列表中的每個(gè)節(jié)點(diǎn)都包含了對(duì)前一個(gè)和后一個(gè)元素的引用，可以被當(dāng)作堆棧、隊(duì)列或雙端隊(duì)列進(jìn)行操作，以方便在內(nèi)存區(qū)域的隊(duì)尾插入(add)數(shù)據(jù)以及在隊(duì)頭進(jìn)行讀取刪除(remove)數(shù)據(jù)。本系統(tǒng)中的緩沖機(jī)制即利用LinkedList的size()方法進(jìn)行實(shí)時(shí)觀測(cè)緩沖區(qū)中的數(shù)據(jù)長(zhǎng)度，當(dāng)緩沖區(qū)的數(shù)據(jù)達(dá)到所設(shè)定的值時(shí)，人為進(jìn)行remove操作，經(jīng)實(shí)驗(yàn)測(cè)試當(dāng)緩沖區(qū)最大長(zhǎng)度設(shè)為10幀的時(shí)候既能起到緩沖的效果又不至于給手機(jī)內(nèi)存造成太大負(fù)擔(dān)。

1.2.2 數(shù)據(jù)解碼模塊

Android自帶的Media Player支持的媒體格式僅局限于OpenCore中所支持的媒體格式。FFmpeg是一種包含音視頻錄制、轉(zhuǎn)換以及編解碼等功能的開(kāi)源解決方案，其支持包括H.264在內(nèi)的多種編碼格式的編解碼，具有較高的執(zhí)行效率。Android平臺(tái)的應(yīng)用程序是由Java來(lái)實(shí)現(xiàn)的運(yùn)行效率較慢，為了滿足速度的要求，本系統(tǒng)在C層采用FFmpeg開(kāi)源方案對(duì)H.264視頻和AAC音頻進(jìn)行解碼。

1.2.3 數(shù)據(jù)播放模塊

播放媒體數(shù)據(jù)就是對(duì)視頻畫面的渲染和音頻數(shù)據(jù)的播放。為了提高畫面渲染效率，本系統(tǒng)使用OpenGL ES來(lái)渲染實(shí)時(shí)視頻圖像。OpenGL ES是為了充分利用硬件加速，專門針對(duì)手機(jī)、PDA和游戲主機(jī)等嵌入式設(shè)備而設(shè)計(jì)的，適合復(fù)雜的、圖形密集的程序。

Android中使用GLSurfaceView來(lái)顯示OpenGL視圖，該類繼承SurfaceView并包含了一個(gè)專門用于渲染3D的接口Renderer，主要通過(guò)實(shí)現(xiàn)onSurfaceCreated、onSurfaceChanged及onDrawFrame等函數(shù)來(lái)完成圖像渲染。

1.2.4 數(shù)據(jù)存儲(chǔ)模塊

在視頻監(jiān)控過(guò)程中有時(shí)會(huì)檢測(cè)到異常情況，而為了現(xiàn)實(shí)生活中的現(xiàn)取留證有時(shí)需要拍照或者錄像功能，從而保存數(shù)據(jù)以待以后查詢調(diào)取。因本系統(tǒng)是實(shí)時(shí)監(jiān)控系統(tǒng)，若像普通視頻監(jiān)控系統(tǒng)一樣將數(shù)據(jù)保存到本地，當(dāng)長(zhǎng)時(shí)間錄制視頻時(shí)則需要很大的內(nèi)存空間，從而給設(shè)備帶來(lái)很大的內(nèi)存負(fù)擔(dān)。為此，本系統(tǒng)的解決方法是將拍照和錄像后得到的媒體數(shù)據(jù)保存到云上，而在手機(jī)上保存的僅是在云上的鏈接地址，當(dāng)用戶想要查看時(shí)則可直接從云上調(diào)取數(shù)據(jù)并進(jìn)行播放。

該模塊以保存存儲(chǔ)路徑來(lái)代替?zhèn)鹘y(tǒng)的本地保存數(shù)據(jù)，能夠給用戶設(shè)備節(jié)省很多內(nèi)存，從而解決了因占用內(nèi)存過(guò)多導(dǎo)致設(shè)備性能差的問(wèn)題。但是存在的缺點(diǎn)是如果用戶想翻看錄制的視頻或者是所拍的照片則都必須連接網(wǎng)絡(luò)，不過(guò)這比起占用內(nèi)存來(lái)說(shuō)是可以接受的。

1.3 系統(tǒng)Server模式

本視頻監(jiān)控系統(tǒng)的Server模式即客戶端給設(shè)備發(fā)送控制命令或音頻數(shù)據(jù)，從而控制設(shè)備進(jìn)行相應(yīng)的操作以及與設(shè)備進(jìn)行對(duì)講。

系統(tǒng)中燈的設(shè)置是為了方便用戶在晚上或者光線不好的情況下對(duì)所關(guān)心區(qū)域進(jìn)行監(jiān)控；遠(yuǎn)程控制警報(bào)的開(kāi)關(guān)能夠很好地避免因誤判而造成的長(zhǎng)時(shí)間擾民的警報(bào)聲；視頻質(zhì)量的選擇能夠避免在網(wǎng)絡(luò)狀況不佳的狀態(tài)下因進(jìn)行高質(zhì)量的傳輸而造成視頻的卡頓；云臺(tái)控制攝像頭的轉(zhuǎn)動(dòng)能夠方便用戶查看所監(jiān)控區(qū)域每個(gè)方向的狀況。綜上所述本系統(tǒng)的Server模式的設(shè)計(jì)給用戶帶來(lái)了很大的便利，使用戶不僅僅是被動(dòng)地接收和顯示數(shù)據(jù)，還可以操作控制設(shè)備，方便地控制設(shè)備監(jiān)測(cè)用戶所想要看到的區(qū)域。

2 FFmpeg音視頻解碼

Android應(yīng)用層程序是由Java高級(jí)語(yǔ)言來(lái)實(shí)現(xiàn)的，每個(gè)應(yīng)用程序都對(duì)應(yīng)存在著一個(gè)獨(dú)立的駐留在一個(gè)由Linux內(nèi)核管理的進(jìn)程中的Dalvik虛擬機(jī)實(shí)例。Dalvik虛擬機(jī)支持Java Native Interface編程方式，JNI即連接Java與C或C++之間通信的橋梁，Android應(yīng)用層可以通過(guò)JNI實(shí)現(xiàn)Java與C的交互。Java與C/C++之間的通信實(shí)質(zhì)上最終是通過(guò)生成庫(kù)來(lái)實(shí)現(xiàn)的，所以要想調(diào)用Native方法就要利用NDK來(lái)編譯C文件并生成相應(yīng)的動(dòng)態(tài)鏈接庫(kù)[7]。

Android NDK與Linux系統(tǒng)有一定的差異，在跨平臺(tái)編譯FFmpeg源代碼時(shí)不能采用原有makefile文件，而要通過(guò)編寫Android.mk文件來(lái)指定所要編譯生成的so庫(kù)名、引用的頭文件目錄、需要編譯的.c或.cpp文件以及.a靜態(tài)庫(kù)文件等，通過(guò)編寫Application.mk來(lái)描述在應(yīng)用程序中所需要的靜態(tài)庫(kù)或動(dòng)態(tài)庫(kù)。

2.1 音視頻解碼

FFmpeg擁有龐大的功能體系，在解碼方面其包含多種格式解碼器，所以利用FFmpeg能夠解碼多種格式的媒體數(shù)據(jù)，并且在解碼后可以對(duì)媒體數(shù)據(jù)進(jìn)行相應(yīng)的轉(zhuǎn)碼，從而得到想要的數(shù)據(jù)格式，故而可以靈活方便地對(duì)多媒體進(jìn)行解碼。解碼主要流程如圖4所示。

圖4 視頻解碼流程

由于本系統(tǒng)是實(shí)時(shí)的，所以要不斷接收媒體數(shù)據(jù)并對(duì)其進(jìn)行解碼，所以將整個(gè)解碼流程封裝成3個(gè)接口，分別是初始化init、解碼decode和關(guān)閉close。這樣系統(tǒng)只需在開(kāi)始和結(jié)束時(shí)分別執(zhí)行一次init和close，中間循環(huán)調(diào)用decode來(lái)解碼，避免了因頻繁初始化和開(kāi)啟釋放內(nèi)存空間帶來(lái)的不必要操作，提高代碼執(zhí)行效率。

具體工作流程是：首先在init中，要用av_register_all來(lái)注冊(cè)所有容器格式和CODEC，以備后面進(jìn)行相應(yīng)的調(diào)用，然后要用av_init_packet來(lái)使用默認(rèn)值初始化AVPacket，其中AVPacket是存儲(chǔ)壓縮編碼數(shù)據(jù)相關(guān)信息的結(jié)構(gòu)體，調(diào)用avcodec_find_decoder來(lái)查找特定的解碼器，并調(diào)用avcodec_open來(lái)打開(kāi)該解碼器，并用av_frame_alloc來(lái)為解碼幀分配內(nèi)存空間。然后在decode中要利用avcodec_decode_video2和avcodec_decode_audio4分別進(jìn)行解碼視頻和音頻數(shù)據(jù)，并將結(jié)果返回。最后在close中要調(diào)用av_free_packet和av_free來(lái)分別釋放AVPacket與AVFrame對(duì)象，并關(guān)閉初始化時(shí)所開(kāi)辟的內(nèi)存。

2.2 視頻轉(zhuǎn)碼

調(diào)用avcodec_decode_video2解碼出的視頻數(shù)據(jù)格式是YUV420P，而Android中不支持直接渲染YUV數(shù)據(jù)，故需要將解碼后的YUV420P格式數(shù)據(jù)轉(zhuǎn)碼成在Android中可渲染的RGB格式。

調(diào)用FFmpeg中的函數(shù)可以很容易地將視頻轉(zhuǎn)換成某一格式，而Android中的Bitmap配置中支持的ARGB_8888數(shù)據(jù)格式在pixmft.h中并沒(méi)有定義，所以要想渲染ARGB_8888格式的數(shù)據(jù)則需要自己研究轉(zhuǎn)碼方法。本文采用的方法是先將byte類型RGB數(shù)據(jù)當(dāng)作無(wú)符號(hào)數(shù)轉(zhuǎn)換成int類型RGB數(shù)據(jù)，再按位操作轉(zhuǎn)換成ARGB數(shù)據(jù)，按位操作大大提高了計(jì)算效率，從而節(jié)省解碼時(shí)間。其中涉及到的數(shù)學(xué)轉(zhuǎn)換公式為

R=Y+(360(V-128))>>8

(1)

G=Y-(88(U-128)>>8)

(2)

B=Y+(455(U-128))>>8

(3)

3 音視頻同步

對(duì)媒體數(shù)據(jù)的播放最關(guān)鍵的就是音視頻的同步問(wèn)題，而解決同步問(wèn)題的最好方法就是時(shí)間戳，在生成媒體數(shù)據(jù)時(shí)給其分別添加時(shí)間戳，播放時(shí)將音視頻數(shù)據(jù)都參考某一特定的時(shí)間來(lái)播放。音視頻基于時(shí)間戳的同步有三種方案，第一種是以外部時(shí)鐘為參考，第二種是以音頻時(shí)間戳為參考，第三種是以視頻時(shí)間戳為參考。以外部時(shí)鐘為參考需要設(shè)立一個(gè)滿足要求的外部時(shí)鐘比較浪費(fèi)資源，故不采納。由于人對(duì)影像的敏感度比對(duì)聲音的敏感度要高，所以本文采用第二種方案，以音頻時(shí)間為參考，將視頻同步于音頻。

本系統(tǒng)中的音頻播放是需要用戶控制的，當(dāng)用戶按下音頻按鈕，該客戶端將給設(shè)備發(fā)送音頻請(qǐng)求指令。當(dāng)系統(tǒng)接收到音頻數(shù)據(jù)并解碼完成等待播放時(shí)，要將該AudioData對(duì)象的時(shí)間戳apts與此時(shí)將要播放的VideoData對(duì)象時(shí)間戳vpts作對(duì)比，vpts大于apts則將當(dāng)前AudioData對(duì)象丟棄，否則正常播放。

4 媒體播放

視頻渲染采用GLSuerfaceView渲染器進(jìn)行，通過(guò)實(shí)現(xiàn)GLSurfaceView中Renderer接口中的3個(gè)方法onSurfaceCreated、onSurfaceChanged、onDrawFrame來(lái)完成持續(xù)渲染。onDrawFrame在渲染的過(guò)程中起主要作用，系統(tǒng)每一次重畫GLSurfaceView都要調(diào)用onDrawFrame方法并在其中綁定紋理，使用這個(gè)方法去作為主要的繪制和重新繪制graphic對(duì)象的執(zhí)行點(diǎn)。傳統(tǒng)的ImageView渲染方法只能在UI主線程操作，會(huì)經(jīng)常造成UI線程的阻塞，而GLSuerfaceView則是直接在子線程進(jìn)行渲染，不用回到主線程，從而提高了系統(tǒng)性能。

由于MediaPlayer只能播放文件流，而監(jiān)控系統(tǒng)是實(shí)時(shí)的，所以音頻播放采用的是AudioTrack，其中的play()與write()方法均調(diào)用由C編寫的Native方法，大大提高了執(zhí)行效率。

通過(guò)實(shí)際測(cè)試，本系統(tǒng)有效地解決了視頻延遲等問(wèn)題，達(dá)到了實(shí)時(shí)監(jiān)控的要求。圖5為實(shí)時(shí)監(jiān)控系統(tǒng)界面圖。

5 結(jié)束語(yǔ)

隨著生活質(zhì)量的提高，實(shí)時(shí)監(jiān)控越來(lái)越受大眾歡迎，同時(shí)對(duì)監(jiān)控系統(tǒng)的性能要求也越來(lái)越高，流暢清晰的畫面也是必須實(shí)現(xiàn)的功能。本文采用GLSuerfaceView來(lái)對(duì)視頻畫面進(jìn)行渲染，采用AudioTrack來(lái)完成聲音的播放，并利用多線程分別處理音視頻的接收、解碼和播放，通過(guò)緩沖機(jī)制有效地解決了視頻延遲卡頓現(xiàn)象，達(dá)到了實(shí)時(shí)性的要求。

[1] 李向軍，張小菲，王書陣.一種基于Android平臺(tái)的移動(dòng)終端多媒體播放器的擴(kuò)展設(shè)計(jì)[J].微電子學(xué)與計(jì)算機(jī)，2014，31(2)：118-121.

圖5 實(shí)時(shí)監(jiān)控系統(tǒng)界面(截圖)

[2] 胡顧飛，湯文兵，朱成亮.基于Android平臺(tái)的紋理映射分析與實(shí)現(xiàn)[J].中國(guó)新技術(shù)新產(chǎn)品，2011(12)：33.

[3] 王咸鋒，林華.手機(jī)遠(yuǎn)程視頻實(shí)時(shí)監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].微計(jì)算機(jī)信息，2007，23(34)：111-112.

[4] 郝明磊.基于Android實(shí)時(shí)視頻監(jiān)控客戶端設(shè)計(jì)與實(shí)現(xiàn)[D].寧波：寧波大學(xué)，2014.

[5] 楊明極，畢晶.基于Android視頻客戶端的設(shè)計(jì)[J].電視技術(shù)，2012，36(3)：43-47.

[6] 馬洪堂.基于FFmpeg的視頻轉(zhuǎn)換系統(tǒng)的模塊研究[J].電腦知識(shí)與技術(shù)，2009(5)：3545-3546.

[7] 李煒?shù)h，于鴻洋.基于Android的視頻軟硬解碼及渲染的對(duì)比研究與實(shí)現(xiàn)[J].電視技術(shù)，2014，38(9)：67-70.

[8] 劉云粼，王樹(shù)東.基于SSE2的YUV與RGB色彩空間轉(zhuǎn)換[J].中國(guó)圖象圖形學(xué)報(bào)，2010，15(1)45-49.

趙紅超(1989— )，女，碩士生，主研嵌入式系統(tǒng)開(kāi)發(fā)、視頻處理；

李 琦(1974— )，教授，碩士生導(dǎo)師，主要研究方向?yàn)闊o(wú)線通信、嵌入式系統(tǒng)；

韓 瑾(1991— )，女，碩士生，主研無(wú)線網(wǎng)絡(luò)技術(shù)；

李 鼎(1987— )，碩士生，主研無(wú)線通信與網(wǎng)絡(luò)。

責(zé)任編輯：許 盈

Design of Real-time Monitoring System Client Based on Android Platform

ZHAO Hongchao, LI Qi, HAN Jin, LI Ding

(School of Electronic and Information Engineering, Hebei University of Technology, Tianjin 300401,China)

A design scheme of remote monitoring system client based on Android mobile platform is proposed in order to realize mobile real-time monitoring system. Every module of this system is researched in detail, and the decoding scheme based on FFmpeg is designed on Android platform. The P2P technology, multi-thread mechanism and data processing cache are used to realize the real-time performance. The efficiency of drawing image is improved greatly by OpenGL ES rendering technique.

real-time monitoring; H.264; FFmpeg; AAC; GLSurfaceView; OpenGL; multithread

河北省自然科學(xué)基金項(xiàng)目(F2012202116)

TN919.85

A

10.16280/j.videoe.2015.20.026

2015-05-08

【本文獻(xiàn)信息】趙紅超，李琦，韓瑾，等.基于Android平臺(tái)的實(shí)時(shí)監(jiān)控系統(tǒng)客戶端設(shè)計(jì)[J].電視技術(shù),2015，39(20).