基于A(yíng)ndroid平臺的可視對講系統設計

　　Android是Google公司推出的基于Linux的開(kāi)源手機操作系統，由于代碼開(kāi)源，受到很多手機廠(chǎng)家的青睞?？梢晫χv系統在Android操作系統未出現之前，軟件研發(fā)一般采用底層語(yǔ)言，容易出現功能單一、產(chǎn)品升級困難等情況，要在對講系統中開(kāi)發(fā)出具有3D圖形效果的界面更是難上加難。鑒于此，本文利用Android平臺的可移植性、代碼開(kāi)源等優(yōu)勢，結合JNI、NDK技術(shù)，提出了基于A(yíng)ndroid平臺的可視對講系統的設計方案并加以實(shí)現。

　　JNI[1](Java Native Interface)是Java本地調用接口，它使得運行于A(yíng)ndroid平臺的Java程序可以使用C、C++甚至匯編語(yǔ)言編寫(xiě)的動(dòng)態(tài)鏈接庫。在需要頻繁訪(fǎng)問(wèn)內存或復雜計算的情況下，使用C動(dòng)態(tài)鏈接庫比在A(yíng)ndroid平臺上使用Java語(yǔ)言實(shí)現相同功能更具有效率[2]。NDK[3](Native Development Kit)提供了一系列的工具，可以生成ARM二進(jìn)制碼的動(dòng)態(tài)庫，并且能自動(dòng)地將生成的動(dòng)態(tài)庫和Java應用程序一起打包成Android系統可以直接安裝的apk安裝包，即NDK可以將包含JNI接口函數的C源程序文件編譯生成動(dòng)態(tài)庫，供Android應用程序調用，提高了對現有代碼的重用性，而加快了開(kāi)發(fā)進(jìn)度。

　　本文提出一種可視對講系統設計方案，對講雙方為門(mén)口機和室內機，并將設計方案在i.MX51硬件平臺進(jìn)行實(shí)現。門(mén)口機進(jìn)行音視頻的采集、編碼、傳輸及音頻解碼、播放;室內機采用Android平臺，但考慮用戶(hù)室內信息的保密性，室內機沒(méi)有視頻采集功能，室內機只進(jìn)行音視頻的解碼、播放以及音頻的采集、編碼、傳輸。

　　1 可視對講系統設計

　　1.1 通信流程設計

　　數據包傳輸協(xié)議使用面向無(wú)連接、資源消耗小、處理速度快的UDP協(xié)議。尋址完成建立UDP直連后，門(mén)口機首先對視頻進(jìn)行編碼傳輸，直到被叫方按下接聽(tīng)鍵后，門(mén)口機才對音頻數據進(jìn)行傳輸。為了保證通話(huà)一直在線(xiàn)，室內機每隔一定的時(shí)間向門(mén)口機發(fā)送通話(huà)在線(xiàn)詢(xún)問(wèn)，如果收到在線(xiàn)確認應答則保持通話(huà)狀態(tài)，否則就結束通話(huà)?？梢晫χv系統通信流程如圖1所示。

　　表2中：包頭為對講數據包的標示符，命令類(lèi)型、操作類(lèi)型說(shuō)明詳見(jiàn)表3，時(shí)間戳主要是用于音視頻的同步，數據類(lèi)型分為音頻和視頻兩種，幀序號為0~65 535。如果沒(méi)有進(jìn)行數據包分段，則總包數與當前包數均為1。音視頻數據從第41位開(kāi)始算起，音視頻數據長(cháng)度由數據包格式中的數據長(cháng)度所指定。

　　根據系統通信流程圖1、結合數據包格式，本對講系統參數如表3所示。其中命令類(lèi)型、操作類(lèi)型分別與表2數據包格式相對應。

　　1.5 音視頻編解碼選擇

　　系統音頻編碼選用G.711編碼[4]。G.711是一種由國際電信聯(lián)盟訂定的音頻編解碼方式，擁有一倍的壓縮率，是語(yǔ)音通信中最常用的編解碼方式之一。采樣和量化是音頻編程及聲音數字化的兩個(gè)關(guān)鍵步驟，本系統使用的音頻采樣頻率為8 kHz、量化位數為16 bit、單聲道。

　　FFmpeg是用于音頻和視頻開(kāi)源方案，由于它的開(kāi)源和免費以及跨平臺的特點(diǎn)，受到開(kāi)發(fā)商的青睞。FFmpeg支持包括xvid等在內的多達90種解碼器，由C語(yǔ)言實(shí)現，不僅可以應用于PC軟件平臺，也可以用于嵌入式設備。本系統中視頻選用xvid編解碼器，視頻格式為MPEG-4。(xvid是一個(gè)開(kāi)放源代碼的MPEG-4視頻編解碼器)視頻標準采用NTSC制，視頻尺寸為352×240，幀頻為30 F/s;使用NDK提供的交叉編譯工具將包含JNI接口函數的音視頻編解碼源文件統一編譯成為動(dòng)態(tài)鏈接庫，供Android平臺調用。

　　2 系統實(shí)現

　　2.1 系統軟硬件平臺

　　系統硬件平臺為i.MX51 EVK。i.MX51 EVK是由Freescale公司自主研發(fā)的，中央處理器基于A(yíng)RM Cortex A8核心的i.MX51處理器;主頻可擴展到1 GHz;處理器內部集成了DDR/DDR2內存控制器、OpenGL/OpenVG圖形核心、ATA控制器、以太網(wǎng)控制器等，支持720 p高清視頻播放;指令緩存和數據緩存為32 KB，二級緩存為256 KB;其容量指標是之前ARM11產(chǎn)品的2倍，可大大提高CPU的處理能力。同時(shí)處理器內部還集成了矢量運算的浮點(diǎn)運算及信號處理加速器，為多媒體信息娛樂(lè )終端提供了強大的處理核心支持[5]。

　　系統軟件平臺采用Linux操作系統、eclipse集成開(kāi)發(fā)環(huán)境。Android SDK[6]版本為2.2，Android NDK版本為android-ndk-r6。使用串口進(jìn)行調試。

　　2.2 Android平臺在i.MX51 EVK上的移植

　　系統采用4 GB的SD卡存放引導程序、內核、根文件系統等鏡像。引導程序采用U-Boot，Linux內核版本為2.6.31。移植流程：Android源碼可以從http：//source.android.com獲取到，編譯好U-Boot、Linux內核、根文件系統以及Android系統鏡像[7]后，設置i.MX51板上的S1 Boot Switch模式為1100000001，使用ATK工具進(jìn)行鏡像的下載。下載后系統鏡像在SD卡上分布圖如圖3所示。

　　圖3中，MBR主要存儲SD卡的分區信息表，起始地址為0 KB。引導程序、內核、根文件系統的起始地址分別為1 KB、1 MB、4 MB。System和Recovery分別各占一個(gè)分區，System為Android操作系統的鏡像文件所占分區，Recovery分區主要是用來(lái)備份和還原系統。

　　2.3 音視頻編解碼實(shí)現

　　2.3.1 音頻編解碼實(shí)現

　　音頻編碼與解碼的區別僅在于調用的C庫函數不一樣，音頻編解碼調用的C庫函數分別為G711Encoder、G711Decoder(本文以解碼為例)。音頻解碼具體流程如下：

　　(1)音頻Java本地調用函數

　　在使用音頻解碼的類(lèi)中編寫(xiě)Java本地調用函數：

　　public native void G711Decoder(byte[]pcm，byte[]code，int size，int lawflag);

　　(2)生成頭文件

　　C庫與Java間需要一個(gè)后綴為“.h”的頭文件來(lái)銜接，這個(gè)頭文件通過(guò)javah命令生成，javah工具包含在JDK中。JDK是Java的核心，包含Java運行環(huán)境、Java工具、Java基礎類(lèi)庫。

　　(3)JNI接口函數

　　JNI接口函數編寫(xiě)在C語(yǔ)言文件中，與音視頻解碼源碼一起打包生成動(dòng)態(tài)鏈接庫。在接口函數中聲明4個(gè)無(wú)符號指針變量：decode指向待解碼的數據、depcm指向解碼后的數據、enpcm指向待編碼的數據、encode指向編碼后的數據。解碼代碼如下：

　　void Java_com_qsa_play_G711Decoder

　　(JNIEnv*env，jobject this，jbyteArray pcm，jbyteArray code，jint size，jint lawflag)

　　{

　　depcm=(unsigned char*)(*env)->

　　GetByteArrayElements(env，pcm，0);

　　decode=(unsigned char*)(*env)->

　　GetByteArrayElements(env，code，0);

　　G711Decoder(depcm，decode，size，lawflag);

　　(*env)->ReleaseByteArrayElements(env， pcm，

　　(jbyte)depcm，0);

　　(*env)->ReleaseByteArrayElements(env，code，(jbyte)

　　decode，0);

　　}

　　其中，depcm=(unsigned char*)(*env)->GetByteArrayElements(env，pcm，0)用來(lái)獲取Java層傳遞的待解碼字節數組的首地址，G711Decoder()函數實(shí)現音頻解碼，(*env)->ReleaseByteArrayElements(env，pcm， (jbyte)depcm，0)釋放傳遞的數組成員，進(jìn)行資源回收。

　　(4)使用NDK中ndk-build命令編譯生成動(dòng)態(tài)鏈接庫

　　ndk-build命令是ndk命令工具集中的一個(gè)命令，與Linux下shell編程中的make命令相似，它會(huì )查找文件夾中的后綴為“.mk”的Makefile文件，根據該文件的依賴(lài)文件，將源文件編譯成動(dòng)態(tài)鏈接庫。

　　2.3.2 視頻編解碼實(shí)現

　　視頻的編解碼流程與音頻編解碼流程基本相似，視頻編解碼調用的C庫函數分別為avcodec_encode_video、avcodec_decode_video2。限于篇幅，在此重點(diǎn)介紹Android平臺視頻的解碼及顯示。

　　在解碼視頻數據前，要先做一系列的準備工作：

　　(1)給出主要的數據結構

　　static AVPacket avpkt;

　　static AVFrame*picture;

　　static AVFrame*pFrameRGB;

　　static AVCodec*codec;

　　static AVCodecContext*c= NULL;

　　static struct SwsContext*img_convert_ctx;

　　AndroidBitmapInfo info;

　　void*pixels;

　　(2)初始化流程

　?、僮越獯a器

　　avcodec_init();

　　av_register_all();

　?、诔跏蓟疉VPacket、AVCodecContext、AVFrame

　　av_init_packet(&avpkt);

　　c=avcodec_alloc_context();

　　picture=avcodec_alloc_frame();

　　其中，AVFrame是數據流在編解碼過(guò)程中用來(lái)保存數據緩存的對象，從數據流中讀取到的數據首先保存到AVPacket中。一個(gè)AVPacket最多只包含一個(gè)AVFrame，而一個(gè)AVFrame可以包含好幾個(gè)AVPacket。AVCodecContext用于動(dòng)態(tài)記錄一個(gè)解碼器的上下文信息。

　?、墼O置視頻解碼器

　　codec=avcodec_find_decoder(MPEG-4);

　　avcodec_open(c，codec);

　?、芤曨l解碼流程

　　視頻解碼流程如圖4所示。圖4中，AndroidBitmap_getinfo用于獲取Android平臺Bitmap對象的大小，AndroidBitmap_ lockpixels函數是對Bitmap進(jìn)行加鎖、互斥使用資源。如果AVPacket包中存在未解碼完的數據，則調用函數avcodec_decode_ video2進(jìn)行解碼;若解碼出一幀后需要調用函數sws_scale進(jìn)行格式轉換。視頻數據解碼完后顏色空間為YUV，需轉換成RGB顏色空間。最后調用fill_bitmap函數進(jìn)行數據填充及進(jìn)行Bitmap的解鎖和資源的釋放。

　　視頻顯示采用Android平臺的ImageView控件進(jìn)行顯示。解碼線(xiàn)程接收到視頻數據后，通過(guò)JNI調用，調用動(dòng)態(tài)庫中的視頻解碼接口函數進(jìn)行解碼，每解碼完一幀后通過(guò)消息通知主線(xiàn)程進(jìn)行顯示圖像的更新，這樣就達到了視頻數據動(dòng)態(tài)顯示的效果。

　　3 實(shí)現效果

　　Android平臺在i.MX51 EVK平臺上移植成功后，串口中Android 操作系統啟動(dòng)信息如圖5所示。 從圖中的啟動(dòng)信息可以看出，Android平臺移植成功，啟動(dòng)信息也包含有CPU信息、內核版本、大小、加載地址、Android文件系統版本等信息。

　　該軟件開(kāi)發(fā)完成后，在A(yíng)ndroid工程的bin下生成apk文件，并復制apk文件到SD卡中，在A(yíng)ndroid系統中安裝該軟件，使用門(mén)口機進(jìn)行撥號，編碼后的音視頻數據通過(guò)網(wǎng)線(xiàn)進(jìn)行傳輸。

　　本文將Android手機操作系統應用于i.MX51 EVK平臺，并在該平臺上提出了可視對講的設計方案，分別進(jìn)行了通信流程、應用協(xié)議、功能模塊等設計，最后實(shí)現了系統的設計方案。但由于視頻是使用軟件解碼，運行效率有待提高，且語(yǔ)音對講部分回聲消除存在問(wèn)題，有待進(jìn)一步研究。