周晶晶 ，舒 翔 ，龍 濤 ，桂良啟

（1.武漢軍械士官學(xué)校 火控雷達(dá)教研室，湖北 武漢 430074；2.華中科技大學(xué) 電子與信息工程系，湖北 武漢 430074）

終端平臺(tái)的智能化和3G網(wǎng)絡(luò)的覆蓋帶來了移動(dòng)互聯(lián)網(wǎng)時(shí)代，這對(duì)當(dāng)今不斷壯大的物聯(lián)網(wǎng)帶來了很多的便利。比如對(duì)物流車輛進(jìn)行隨時(shí)、隨地、隨身的視頻監(jiān)控，相比傳統(tǒng)的PC機(jī)監(jiān)控更加方便和高效。在移動(dòng)終端上進(jìn)行視頻監(jiān)控系統(tǒng)的開發(fā)，由于其硬件資源和網(wǎng)絡(luò)環(huán)境的限制，開發(fā)難度遠(yuǎn)大于PC機(jī)，并且對(duì)移動(dòng)終端和網(wǎng)絡(luò)都有很高的要求。本文通過分析流媒體服務(wù)器的特點(diǎn)，在服務(wù)器上實(shí)現(xiàn)了一個(gè)雙緩沖機(jī)制來達(dá)到實(shí)時(shí)發(fā)布流媒體的要求，通過服務(wù)器多線程的方式實(shí)現(xiàn)邊采集邊傳輸并實(shí)時(shí)的發(fā)布。

本文采用Android操作系統(tǒng)作為終端視頻采集的平臺(tái)，借助Android系統(tǒng)平臺(tái)開發(fā)的優(yōu)點(diǎn)，可以很好地進(jìn)行推廣及后期應(yīng)用。此外，為了保證數(shù)據(jù)傳輸?shù)馁|(zhì)量，本文通過在Android中移植X264開源庫(kù)來實(shí)現(xiàn)流媒體視頻的編碼，并通過雙緩沖文件優(yōu)化流媒體傳輸機(jī)制以實(shí)現(xiàn)實(shí)時(shí)視頻和移動(dòng)監(jiān)控的融合。

1 系統(tǒng)分析與設(shè)計(jì)

1.1 系統(tǒng)總體架構(gòu)設(shè)計(jì)

系統(tǒng)由視頻移動(dòng)終端、流媒體服務(wù)器、視頻監(jiān)控端3部分組成，系統(tǒng)組成框圖如圖1所示。

其中，視頻移動(dòng)終端通過Anrdoid平臺(tái)提供的api實(shí)時(shí)獲取攝像頭捕獲的視頻流，并通過JNI的方式調(diào)用底層的native代碼以完成H.264的編碼工作，之后通過socket傳輸?shù)揭曨l監(jiān)控服務(wù)器。

視頻監(jiān)控服務(wù)器包括應(yīng)用服務(wù)器和流媒體服務(wù)器兩部分。其中應(yīng)用服務(wù)器作為整個(gè)系統(tǒng)的服務(wù)端，用于處理視頻監(jiān)控端的視頻請(qǐng)求以及接收視頻移動(dòng)終端發(fā)來的實(shí)時(shí)視頻流數(shù)據(jù)。流媒體服務(wù)器則用于將應(yīng)用服務(wù)器接收的視頻流數(shù)據(jù)封裝成流媒體格式并實(shí)時(shí)發(fā)布。

視頻監(jiān)控端采用Android平臺(tái)構(gòu)建，可以通過RTSP和HTTP兩種協(xié)議訪問流媒體服務(wù)器以獲得觀看實(shí)時(shí)視頻的效果。

1.2 視頻采集和編碼

本系統(tǒng)采集的實(shí)時(shí)視頻來源于Android系統(tǒng)支持的攝像頭?？紤]到無線網(wǎng)絡(luò)帶寬的限制，本系統(tǒng)采用H.264標(biāo)準(zhǔn)進(jìn)行壓縮編碼。由于H.264編碼對(duì)硬件要求較高，編碼的速度會(huì)受到一定的影響，這樣采集到的視頻可能不夠連貫。本系統(tǒng)采用多線程加緩沖隊(duì)列的方法進(jìn)行采集和編碼。視頻采集線程將捕獲的每一幀數(shù)據(jù)放入一個(gè)緩沖隊(duì)列中，視頻編碼線程從隊(duì)列中獲取視頻幀集合來完成編碼和傳輸?shù)墓ぷ?。具體流程圖如圖2所示。

圖2 視頻采集編碼流程圖

其中視頻采集線程的偽代碼如下：

視頻編碼線程的偽代碼如下：

1.3 H.264視頻流傳輸控制模型

H.264的定義由視頻編碼層 （VCL）和網(wǎng)絡(luò)提取層（NAL）兩部分組成。其中VCL作為H.264的核心算法引擎對(duì)視頻數(shù)據(jù)進(jìn)行壓縮編碼和解碼；NAL層則根據(jù)不同的網(wǎng)絡(luò)把數(shù)據(jù)打包成相應(yīng)的格式并通過網(wǎng)絡(luò)傳送出去。為了保證較低的延時(shí)，需要將H.264視頻流數(shù)據(jù)打包成RTP包，并加上時(shí)間戳和序列號(hào)等信息，然后通過UDP傳輸?shù)椒?wù)器。RTP的打包模式有3種：?jiǎn)蜰AL單元模式、非交錯(cuò)模式和交錯(cuò)模式。本文根據(jù)系統(tǒng)的要求，采用非交錯(cuò)模式按照編碼的視頻流順序進(jìn)行組包，適用于延時(shí)較低的實(shí)時(shí)系統(tǒng)。

由于H.264編碼對(duì)CPU消耗較大，如果放在java層則會(huì)大幅度影響系統(tǒng)性能。本系統(tǒng)將H.264編碼模塊放在 native層，用 C/C++實(shí)現(xiàn)，通過 jni調(diào)用編碼接口，然后通過RTP傳輸。

1.4 服務(wù)器設(shè)計(jì)

服務(wù)器端采用雙緩沖文件實(shí)現(xiàn)流媒體的生成和發(fā)布。傳統(tǒng)的實(shí)時(shí)視頻監(jiān)控一般采用socket連接實(shí)現(xiàn)邊傳輸邊播放視頻，視頻數(shù)據(jù)并不會(huì)被緩存，并且如果要有新的客戶端加入監(jiān)控，則必須要新建一個(gè)socket連接。本系統(tǒng)通過加入流媒體服務(wù)器作為視頻中轉(zhuǎn)，很好地解決了這一問題。由于流媒體服務(wù)器發(fā)布實(shí)時(shí)流媒體需要實(shí)時(shí)的視頻源，本系統(tǒng)的應(yīng)用服務(wù)器將接收的實(shí)時(shí)視頻流數(shù)據(jù)寫入一個(gè)緩沖文件作為流媒體服務(wù)器的視頻源，此緩沖文件通過linux命名管道實(shí)現(xiàn)。此外，流媒體服務(wù)器發(fā)布流媒體也需要一個(gè)緩沖文件，用于存放被編碼成流媒體格式后的視頻流數(shù)據(jù)，以供客戶端調(diào)用。服務(wù)器的工作流程圖如圖3所示。

圖3 服務(wù)器工作流程圖

2 系統(tǒng)實(shí)現(xiàn)

2.1 Android Camera視頻采集

為了實(shí)時(shí)捕獲Android攝像頭的畫面，需要用到Android Camera。Android Camera包含取景和拍照兩個(gè)功能，它實(shí)際上是建立在C/S架構(gòu)上的。Camera運(yùn)行的時(shí)候，可以大致分成服務(wù)器和客戶端兩個(gè)部分，他們分別運(yùn)行在兩個(gè)不同的進(jìn)程中，通過Binder機(jī)制來完成進(jìn)程間通信。這種Android特有的Binder機(jī)制可以保證客戶端和服務(wù)器獨(dú)立的變化，客戶端調(diào)用接口AIDL定義的接口，功能則在服務(wù)器中實(shí)現(xiàn)，并且進(jìn)程間通信的部分對(duì)上層程序不可見。

具體實(shí)現(xiàn)中，通過Android Framework提供的android.hardware.Camera類來完成和CameraService服務(wù)端通信。由于需要對(duì)采集到的每一幀畫面進(jìn)行壓縮編碼處理，可以通過調(diào)用Camera對(duì)象的setPreviewCallback函數(shù)來設(shè)置一個(gè)回調(diào)對(duì)象，此回調(diào)對(duì)象中的onPreviewFrame函數(shù)可用于完成對(duì)當(dāng)前幀的捕獲，這樣就可以在此函數(shù)中對(duì)采集到的視頻進(jìn)行編碼的處理了。

2.2 JNI調(diào)用 X264庫(kù)

考慮到無線網(wǎng)絡(luò)環(huán)境的不穩(wěn)定性和帶寬有限的問題。本文對(duì)采集到的視頻進(jìn)行H.264標(biāo)準(zhǔn)的高效壓縮編碼。H.264是目前一個(gè)廣泛使用的具有高壓縮比的視頻編碼格式，具有較高的視頻壓縮性能，適合用窄帶傳輸，適用于移動(dòng)互聯(lián)網(wǎng)和流媒體播放。本文采用X264開源庫(kù)來對(duì)實(shí)時(shí)視頻進(jìn)行壓縮編碼。首先需要在Android操作系統(tǒng)上移植X264庫(kù)。

由于X264是用C語言寫的一個(gè)開源庫(kù)，為了能夠被Android平臺(tái)使用，需要用到NDK工具對(duì)其進(jìn)行編譯。NDK是用來編譯本地代碼的工具，作為Android SDK的一個(gè)補(bǔ)充，用于將原生的C/C++代碼集成到應(yīng)用中，并通過JNI的方式被上層java程序調(diào)用。本文采用JNI方式調(diào)用X264庫(kù)的步驟如下所示。

（1）JNI接口設(shè)計(jì)

設(shè)計(jì)調(diào)用本地代碼的函數(shù)接口。本文需要對(duì)采集的視頻進(jìn)行H.264編碼，編碼部分需要定義3個(gè)接口。分別如下：

其中native關(guān)鍵表明這3個(gè)函數(shù)來自于native代碼。CompressBegin接口是編碼初始化接口，通過傳遞視頻畫面的寬和高來對(duì)H.264編碼器進(jìn)行初始化設(shè)定；CompressBuffer接口是編碼接口，通過傳遞encoder編碼器結(jié)構(gòu)和視頻流字節(jié)數(shù)組來對(duì)當(dāng)前幀的視頻流數(shù)據(jù)進(jìn)行H.264編碼，編碼后的結(jié)果存儲(chǔ)在out數(shù)組中；CompressEnd接口用于釋放編碼資源。

（2）實(shí)現(xiàn)本地方法

JNI接口設(shè)計(jì)完畢之后，需要用C語言實(shí)現(xiàn)接口。創(chuàng)建一個(gè)H264Android.c的文件，用來實(shí)現(xiàn)第一步中定義的3個(gè)接口。

（3）生成動(dòng)態(tài)鏈接庫(kù)

實(shí)現(xiàn)JNI接口之后，需要生成.so的動(dòng)態(tài)鏈接庫(kù)以供java程序調(diào)用。為了生成動(dòng)態(tài)鏈接庫(kù)，需要編寫Android.mk文件并通過NDK工具對(duì)本地代碼進(jìn)行交叉編譯。交叉編譯時(shí)需要針對(duì)X264庫(kù)編寫相應(yīng)的Android.mk文件，核心內(nèi)容如下所示：

其中，LOCAL_C_INCLUDES標(biāo)明了編譯需要的外部頭文件路徑；LOCAL_MODULE標(biāo)明了當(dāng)前生成模塊名稱；LOCAL_SRC_FILES標(biāo)明了編譯需要用到的源文件；LOCAL_LDFLAGS標(biāo)明了編譯需要用到的外部靜態(tài)庫(kù)；LOCAL_LDLIBS標(biāo)明了引用的外部庫(kù)文件。

通過引用X264的靜態(tài)庫(kù)，即可將X264編譯到native代碼中，并被上層java程序調(diào)用。編譯成功之后，會(huì)在Android項(xiàng)目的根目錄下的libs文件夾中形成一個(gè)libH264Android.so的動(dòng)態(tài)鏈接庫(kù)，編譯完成。

（4）Java程序調(diào)用本地代碼

Android中的Java程序可以通過 System.loadLibrary（"H264Android"）函數(shù)調(diào)用第 3步中生成 libH264Android.so動(dòng)態(tài)鏈接庫(kù)。并使用聲明的native方法來完成視頻編碼的功能。

2.3 視頻傳輸?shù)膶?shí)現(xiàn)

視頻傳輸通過TCP和UDP兩種方式配合實(shí)現(xiàn)。為了保證視頻采集終端和服務(wù)器之間有可靠的通信機(jī)制，采用TCP連接來進(jìn)行控制信息的傳輸，當(dāng)視頻終端收到有效的傳輸視頻的控制信息之后，采用UDP連接發(fā)送實(shí)時(shí)的視頻流到服務(wù)器。服務(wù)器視頻接收線程會(huì)將收到的有效視頻數(shù)據(jù)寫入到一個(gè)緩沖文件Camera.h264中，此文件被作為流媒體服務(wù)器的視頻源。

2.4 FFmpeg流媒體服務(wù)器架設(shè)

服務(wù)器端采用FFmpeg作為流媒體服務(wù)器。FFmpeg是一個(gè)開源免費(fèi)跨平臺(tái)的視頻和音頻流方案，屬于自由軟件，采用LGPL或GPL許可證。FFmpeg既可以對(duì)視頻進(jìn)行編解碼，也可以搭建基于http和rtsp協(xié)議的流媒體服務(wù)器。

本系統(tǒng)服務(wù)器利用Camera.h264緩沖文件作為FFmpeg的視頻源進(jìn)行流媒體的發(fā)布。由于ffmpeg發(fā)布流媒體需要用到其中的FFserver組件，ffserver組件的啟動(dòng)需要編寫相應(yīng)的ffserver.conf配置文件，主要配置如下所示：

其中，Port指定了流媒體服務(wù)器綁定的端口。＜Feed feed1.ffm＞標(biāo)簽定義了流媒體服務(wù)器運(yùn)行所需要的一個(gè)緩沖文件，大小為200 KB。＜Stream camera.asf＞標(biāo)簽定義了流媒體服務(wù)器輸出的視頻格式以及視頻相關(guān)的參數(shù)。如本系統(tǒng)輸出的流媒體格式為.asf格式。

在ffserver啟動(dòng)時(shí)，會(huì)根據(jù)ffserver.conf文件中的配置新建一個(gè)feed1.ffm緩沖文件。此緩沖文件用于存放來自視頻源文件的實(shí)時(shí)視頻流。FFmpeg會(huì)根據(jù)配置文件中的視頻輸出格式將視頻源中的文件進(jìn)行轉(zhuǎn)換，轉(zhuǎn)換之后的數(shù)據(jù)會(huì)寫入feed1.ffm文件中。本系統(tǒng)中，feed1.ffm文件大小被限制在200 KB，當(dāng)200 KB的空間被用完后，新數(shù)據(jù)會(huì)從文件的開頭進(jìn)行寫入。這樣可以保證當(dāng)有新的客戶端加入監(jiān)控時(shí)，觀看到的是最新的視頻。

3 系統(tǒng)測(cè)試

為了驗(yàn)證H.264視頻在無線網(wǎng)絡(luò)中的傳輸性能，本系統(tǒng)選取了2臺(tái)Android 2.3系統(tǒng)的手機(jī)進(jìn)行測(cè)試。測(cè)試環(huán)境如下：

視頻終端：Google Nexus S

CPU主頻：1 GHz

內(nèi)存：512 MB

操作系統(tǒng)：Android 2.3

服務(wù)器采用Ubuntu10.04搭建。

表1對(duì)雙緩沖和無緩沖的流媒體傳輸機(jī)制進(jìn)行了測(cè)試和對(duì)比，顯示了隨著分辨率和每秒傳輸幀數(shù)/（F/S）的變化導(dǎo)致的丟包率和延時(shí)的變化。

經(jīng)過測(cè)試，在采用了雙緩沖機(jī)制發(fā)布流媒體之后，客戶端能夠以更小的延時(shí)播放流媒體服務(wù)器發(fā)布的H.264視頻流。由于丟包率主要取決于傳輸帶寬，改變傳輸模式對(duì)丟包率的提升并不是很大。

在高速移動(dòng)互聯(lián)網(wǎng)的環(huán)境下進(jìn)行視頻監(jiān)控成為了物聯(lián)網(wǎng)行業(yè)一個(gè)比較熱門的應(yīng)用。本文在流媒體服務(wù)器的搭建上采用雙緩沖文件技術(shù)，有效地保證了視頻源的實(shí)時(shí)性，降低了網(wǎng)絡(luò)傳輸?shù)难訒r(shí)。此外，考慮到無線網(wǎng)絡(luò)環(huán)境中視頻數(shù)據(jù)傳輸?shù)睦щy，本文采用H.264標(biāo)準(zhǔn)對(duì)實(shí)時(shí)視頻進(jìn)行壓縮編碼，有效地提高了帶寬利用率。由于本文傳輸視頻數(shù)據(jù)采用的RTP組包模式[5]并沒有考慮到實(shí)際的應(yīng)用背景，會(huì)產(chǎn)生一定程度的數(shù)據(jù)丟包，因此只是和應(yīng)用與對(duì)實(shí)時(shí)畫面要求不高的場(chǎng)景，比如物聯(lián)網(wǎng)物流行業(yè)等，如果要實(shí)時(shí)傳輸更清晰的視頻數(shù)據(jù)，則需要采用良好的失序和擁塞處理技術(shù)，并重寫RTP的組包算法，這樣可以保證視頻數(shù)據(jù)的穩(wěn)定性和完整性，這也是今后要研究和改進(jìn)的方向。

表1 雙緩沖傳輸模式和無緩沖傳輸模式的測(cè)試結(jié)果比較

[1]SCHULZRINNE H，CASNER S.RTP： A Transport Protocol for Real-Time Application[M].RFC3550，2003.

[2]WENGER S，HANNUKSEL M M.RTP Payload Format for H.264 Video[M].RFC3984，2005.

[3]王立青.基于X264和流媒體的嵌入式視頻監(jiān)控系統(tǒng)[J].計(jì)算機(jī)安全，2010（7）：13-15.

[4]任嚴(yán).基于 FFMPEG的視頻轉(zhuǎn)換與發(fā)布系統(tǒng)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2007，28（20）：4962-4967.

[5]魏聰穎.基于實(shí)時(shí)流媒體傳輸系統(tǒng)的H.264組包算法研究[J].計(jì)算機(jī)科學(xué)，2007，34（8）：41-44.