0 引言

    車(chē)載視頻智能監(jiān)控是智能交通領(lǐng)域的一個(gè)重要研究課題,，它能方便用戶實(shí)時(shí)、直觀地監(jiān)控車(chē)輛安全情況,。傳統(tǒng)的車(chē)載視頻監(jiān)控系統(tǒng)一般采用固定的PC監(jiān)控方式，因而需要在指定的地點(diǎn),，并且在有專用網(wǎng)絡(luò)設(shè)備支持的情況下才能對(duì)目標(biāo)現(xiàn)場(chǎng)進(jìn)行監(jiān)控,，這大大限制了監(jiān)控系統(tǒng)的應(yīng)用范圍和靈活性^[1],。近些年隨著移動(dòng)互聯(lián)網(wǎng)的普及，市面上也出現(xiàn)了移動(dòng)車(chē)載視頻監(jiān)控的解決方案,，但是又存在視頻畫(huà)質(zhì)不理想,、整體用戶體驗(yàn)較差的問(wèn)題，同時(shí)車(chē)輛的移動(dòng)性也對(duì)網(wǎng)絡(luò)資源利用率提出了更高的要求,。

    本文在Android平臺(tái)下提出了車(chē)載視頻智能監(jiān)控的解決方案,。利用該方案，通過(guò)實(shí)現(xiàn)NAT穿透和P2P,、C/S混合網(wǎng)絡(luò)架構(gòu),，提高了網(wǎng)絡(luò)健壯性和資源利用率；通過(guò)設(shè)置緩沖區(qū)和調(diào)用FFmpeg多媒體解碼框架,，提高了高清實(shí)時(shí)監(jiān)控性能,。實(shí)踐表明該方案能適應(yīng)不同網(wǎng)絡(luò)條件，滿足了實(shí)際項(xiàng)目播放需求,，具有良好的用戶體驗(yàn),。

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

    本系統(tǒng)是基于Android平臺(tái)開(kāi)發(fā)的車(chē)載視頻監(jiān)控系統(tǒng)。該系統(tǒng)主要由三部分組成,，即車(chē)載端,、視頻傳輸網(wǎng)絡(luò)和監(jiān)控端。系統(tǒng)整體框架如圖1所示,。

    車(chē)載端基于Android平臺(tái)開(kāi)發(fā),，首先車(chē)載端會(huì)采集視頻數(shù)據(jù)，然后對(duì)采集的數(shù)據(jù)進(jìn)行H.264編碼和實(shí)時(shí)傳輸協(xié)議（Real-time Transport Protocol,，RTP）封包處理,，最后將處理后的視頻數(shù)據(jù)通過(guò)網(wǎng)絡(luò)傳輸?shù)奖O(jiān)控端；視頻傳輸網(wǎng)絡(luò)基于點(diǎn)對(duì)點(diǎn)網(wǎng)絡(luò)（peer-to-peer,，P2P）和客戶機(jī),、服務(wù)器結(jié)構(gòu)（Client/Server，C/S）的混合網(wǎng)絡(luò)架構(gòu),，其傳輸方式會(huì)優(yōu)先選擇P2P連接,，當(dāng)P2P連接無(wú)法對(duì)網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）成功穿透而連接失敗后,，再通過(guò)中轉(zhuǎn)服務(wù)器進(jìn)行數(shù)據(jù)中轉(zhuǎn),，有效節(jié)省網(wǎng)絡(luò)帶寬，提高網(wǎng)絡(luò)資源利用率,；監(jiān)控端基于Android平臺(tái)開(kāi)發(fā),，首先監(jiān)控端在異步線程接收到網(wǎng)絡(luò)傳來(lái)的包數(shù)據(jù)，并對(duì)這些數(shù)據(jù)進(jìn)行RTP解包和FFmpeg解碼,，最后將解碼后得到的圖像通過(guò)ImageView實(shí)時(shí)更新顯示給監(jiān)控者,。

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

2.1 視頻車(chē)載端

2.1.1 視頻采集和編碼

    視頻采集過(guò)程中,，預(yù)覽圖像會(huì)占用大量?jī)?nèi)存，內(nèi)存占用過(guò)大會(huì)導(dǎo)致內(nèi)存溢出,，嚴(yán)重時(shí)會(huì)造成程序崩潰,，本系統(tǒng)通過(guò)Camera.PreviewCallback的onPreviewFrame回調(diào)函數(shù)，實(shí)時(shí)截取每幀視頻流數(shù)據(jù),，并以setPreviewCallbackWithBuffer(Camera.PreviewCallback)的方式使用上述回調(diào),，提供一個(gè)字節(jié)數(shù)組作為緩沖區(qū)，用于保存預(yù)覽圖像數(shù)據(jù),，以有效管理預(yù)覽圖像時(shí)內(nèi)存的分配和銷毀,。

    移動(dòng)網(wǎng)絡(luò)的帶寬有限，為了呈現(xiàn)高質(zhì)量的監(jiān)控畫(huà)面,，需要實(shí)現(xiàn)高編碼壓縮比,。H.264充分地利用了各種冗余來(lái)達(dá)到高效的數(shù)據(jù)壓縮比率，同時(shí)還具備高質(zhì)量流通的圖形,，采用高度負(fù)責(zé)的算法,，使其成為當(dāng)前在低碼率下壓縮比率最高的視頻編碼標(biāo)準(zhǔn)^[2]。所以本系統(tǒng)通過(guò)H.264技術(shù)來(lái)進(jìn)行數(shù)據(jù)編碼,。

2.1.2 視頻封包

    數(shù)據(jù)包到達(dá)時(shí)間隨機(jī)性是視頻數(shù)據(jù)傳輸中很關(guān)鍵的問(wèn)題,，本系統(tǒng)采用RTP^[3]協(xié)議來(lái)負(fù)責(zé)視頻數(shù)據(jù)封包，利用數(shù)據(jù)包的時(shí)間戳,、發(fā)送序號(hào)等字段來(lái)控制數(shù)據(jù)流的傳輸,。

    但如果RTP包大于最大傳輸單元(Maximum Transmission Unit，MTU),，會(huì)導(dǎo)致底層協(xié)議任意拆包,，這會(huì)使RTP包被分割后丟失的可能性增大，以致影響接收端數(shù)據(jù)的恢復(fù),，因而一般采用對(duì)網(wǎng)絡(luò)抽象層(Network Abstract Layer,，NAL)單元進(jìn)行分類處理，共有單一NAL單元模式,、組合封包模式和分片封包模式3種封包策略,。

    本系統(tǒng)因不存在音頻數(shù)據(jù)，而H.264 NAL單元都含有較大數(shù)據(jù)量,，故沒(méi)必要采用組合封包模式,。本系統(tǒng)將RTP包長(zhǎng)設(shè)定為1 024 B，將超過(guò)1 024 B的NAL單元采用分片封包模式,，不超過(guò)的采用單一NAL單元模式,。

2.2 視頻傳輸網(wǎng)絡(luò)

    視頻傳輸網(wǎng)絡(luò)在監(jiān)控系統(tǒng)中占有至關(guān)重要的地位，視頻數(shù)據(jù)傳輸質(zhì)量的好壞直接影響了監(jiān)控系統(tǒng)的使用效果。本系統(tǒng)采用面向無(wú)連接的用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol,，UDP）來(lái)負(fù)責(zé)視頻傳輸工作,，并在傳統(tǒng)C/S模式的基礎(chǔ)上混合P2P傳輸技術(shù)，減少網(wǎng)絡(luò)帶寬的消耗,，提高網(wǎng)絡(luò)資源利用率。網(wǎng)絡(luò)傳輸?shù)暮?jiǎn)要工作流程如圖2所示,。

2.2.1 心跳機(jī)制

    系統(tǒng)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)發(fā)送和接收都是通過(guò)SOCKET來(lái)進(jìn)行,，但倘若此SOCKET是斷開(kāi)狀態(tài)，則在發(fā)送和接收數(shù)據(jù)時(shí)就不能保證數(shù)據(jù)能有效到達(dá),，所以本系統(tǒng)通過(guò)搭建狀態(tài)服務(wù)器來(lái)管理各車(chē)載端和監(jiān)控端的在線狀態(tài)(即SOCKET連接狀態(tài)),。狀態(tài)服務(wù)器會(huì)進(jìn)行如下操作：

    (1)啟動(dòng)新線程A1，監(jiān)聽(tīng)端口4112,，接收車(chē)載端每隔30 s發(fā)來(lái)的心跳包,，處理心跳包中的JSON數(shù)據(jù)并更新內(nèi)存N2中車(chē)載端的狀態(tài)。

    (2)啟動(dòng)新線程A2,，監(jiān)聽(tīng)端口4113,，接收監(jiān)控端每隔30 s發(fā)來(lái)的心跳包，處理心跳包中的JSON數(shù)據(jù)并更新內(nèi)存N1中監(jiān)控端的狀態(tài),。同步返回監(jiān)控端對(duì)應(yīng)的車(chē)載端的JSON格式的數(shù)據(jù)集合,，以便監(jiān)控端在界面上更新車(chē)載端的狀態(tài)顯示。

    (3)啟動(dòng)新線程A3,，每隔60 s執(zhí)行一次,，循環(huán)N1中的監(jiān)控端和N2中的車(chē)載端，根據(jù)時(shí)間戳判斷監(jiān)控端或車(chē)載端是否已掉線,，如掉線則更新對(duì)應(yīng)的內(nèi)存中的狀態(tài),。

2.2.2 NAT穿透

    在實(shí)際網(wǎng)絡(luò)環(huán)境下由于IPv4地址短缺，使得許多客戶機(jī)都是通過(guò)NAT技術(shù)來(lái)共用一個(gè)公網(wǎng)IP地址^[4],。NAT隱藏了參與構(gòu)建P2P網(wǎng)絡(luò)的大量用戶節(jié)點(diǎn),，使得NAT穿透往往是制約P2P成功連接的關(guān)鍵。

    NAT^[5]可分成圓錐型NAT和對(duì)稱型NAT兩種類型,。對(duì)于圓錐型NAT,，本系統(tǒng)采用UDP對(duì)NAT的簡(jiǎn)單穿越（simple traversal of UDP through NAT，STUN）方式能很好地解決UDP穿透問(wèn)題,，但因STUN方式對(duì)于對(duì)稱型 NAT不能提供有效的外部IP地址和端口號(hào),，所以無(wú)法成功穿透。

    針對(duì)無(wú)法穿透對(duì)稱型NAT的缺陷,，本系統(tǒng)采用基于端口預(yù)測(cè)的方法來(lái)解決,，能夠在較多的場(chǎng)合盡可能地建立P2P連接。本系統(tǒng)對(duì)項(xiàng)目中存在的對(duì)稱型 NAT網(wǎng)絡(luò)環(huán)境進(jìn)行分析發(fā)現(xiàn)，對(duì)稱型 NAT對(duì)于從內(nèi)部網(wǎng)絡(luò)依次接收到的新連接,，分配的輸出端口大致有兩種情況：

　　依照空閑端口按序連續(xù)分配的情況,。因?yàn)樵诖┩高^(guò)程中，車(chē)載端兩次數(shù)據(jù)的發(fā)送間隔不會(huì)很長(zhǎng),，NAT為其分配的新輸出端口號(hào)相對(duì)于其原端口號(hào)的偏移量是一個(gè)較小范圍內(nèi)的正數(shù),，因此系統(tǒng)可以在監(jiān)控端執(zhí)行端口探測(cè)，當(dāng)收到車(chē)載端對(duì)該UDP報(bào)文的回復(fù)就意味著穿透成功,。

    在一定端口范圍內(nèi)隨機(jī)分配的情況,。雖然車(chē)載端NAT兩次輸出端口號(hào)間的偏移量具有隨機(jī)性，并且不同的設(shè)備和網(wǎng)絡(luò)環(huán)境也會(huì)產(chǎn)生較大的區(qū)別,，但實(shí)際上每次分配的端口號(hào)之間都會(huì)具有一定的函數(shù)關(guān)系或統(tǒng)計(jì)上的關(guān)聯(lián)性,。因此，可以通過(guò)研究其分布特性來(lái)預(yù)測(cè),，實(shí)施試探性穿透,。

2.3 視頻監(jiān)控端

2.3.1 視頻解包

    由于網(wǎng)絡(luò)傳輸時(shí)受到MTU的限制，因此視頻數(shù)據(jù)在發(fā)送時(shí)被分割成一個(gè)個(gè)獨(dú)立的數(shù)據(jù)包進(jìn)行傳輸,。監(jiān)控端收到這些數(shù)據(jù)包后,，必須按一定規(guī)則將這些包重新組合還原，然后才能進(jìn)行解碼播放,。但當(dāng)網(wǎng)絡(luò)傳輸不穩(wěn)定時(shí),，系統(tǒng)易出現(xiàn)包亂序和丟包現(xiàn)象。

    對(duì)于包亂序處理,，當(dāng)監(jiān)控端收到的RTP數(shù)據(jù)包沒(méi)有正確排序時(shí),，本系統(tǒng)就需要按照包序列號(hào)進(jìn)行重排。本系統(tǒng)在內(nèi)存中建立雙向鏈表來(lái)充當(dāng)緩沖區(qū),，當(dāng)接收到數(shù)據(jù)包后就按包頭的序列號(hào)插入至對(duì)應(yīng)位置,。比如，接收到一個(gè)序列號(hào)SN=3的RTP包,，就從鏈表尾開(kāi)始搜索并插入到2,、4節(jié)點(diǎn)中間。本系統(tǒng)緩沖區(qū)的最大長(zhǎng)度設(shè)置為30時(shí),，能起到較好的緩沖效果,，同時(shí)也能避免對(duì)設(shè)備內(nèi)存造成較大負(fù)擔(dān)。

    對(duì)于丟包處理,，在H.264編碼標(biāo)準(zhǔn)中,，共定義了I幀、P幀,、B幀3種幀,。I幀為關(guān)鍵幀，存放完整的數(shù)據(jù)；而P,、B幀是輔助幀,，存放運(yùn)動(dòng)矢量或邊緣信息，需要對(duì)關(guān)鍵幀進(jìn)行參考,。所以,，本系統(tǒng)在數(shù)據(jù)傳輸過(guò)程中，如關(guān)鍵幀數(shù)據(jù)丟失,，對(duì)其他的P幀和B幀數(shù)據(jù)都會(huì)造成影響,，因此必須將關(guān)鍵幀連同其他相關(guān)幀全部舍棄。如果輔助幀數(shù)據(jù)丟失,，只會(huì)對(duì)當(dāng)前幀數(shù)據(jù)產(chǎn)生影響，則只需將當(dāng)前幀直接舍棄,。

2.3.2 視頻解碼和播放

    Android自帶的Media Player支持的媒體格式僅局限于OpenCore中所支持的媒體格式,。FFmpeg是一種包含音視頻錄制、轉(zhuǎn)換以及編解碼等功能的開(kāi)源解決方案,，其支持包括H.264在內(nèi)的多種編碼格式的編解碼,，具有較高的執(zhí)行效率。

    系統(tǒng)采用交叉編譯的方式將FFmpeg引入到Android中來(lái)實(shí)現(xiàn)H.264解碼,，F(xiàn)Fmpeg編譯模塊編譯生成libffmpeg.so文件之后,，供Android系統(tǒng)的Java本地接口（Java Native Interface，JNI）層調(diào)用,。

    libffmpeg.so文件的調(diào)用較為復(fù)雜,，本系統(tǒng)采用重新編譯生成一個(gè)so文件進(jìn)行調(diào)用。這個(gè)so文件包含的是jni方法,，這些方法能通過(guò)Java層進(jìn)行調(diào)用,，而方法中用到的函數(shù)則來(lái)自于libffmpeg.so文件。

    首先需要編輯android.mk文件,，文件具體內(nèi)容如下：

    LOCAL_PATH:=$(call my-dir)

    include $(CLEAR_VARS)

    LOCAL_LDLIBS := -lffmpeg-llog

    LOCAL_MODULE := ffmpegutilDecode

    #LOCAL_SHARED_LIBRARIES := ffmpeg

    LOCAL_SRC_FILES := com_act1_H264.c

    LOCAL_C_INCLUDES:=/cygdrive/d/android/android-ndk-r8b/ffmpeg/jni/include $(BUILD_SHARED_LIBRARY)

    成功編譯android.mk文件后需編輯com_act1_H264.c文件,，此文件包含本地定義的方法，這些方法調(diào)用ffmpeg解碼庫(kù)函數(shù),，可解碼H.264格式的視頻數(shù)據(jù),。

　　com_act1_H264.c文件編輯成功后，就可執(zhí)行ndk-build語(yǔ)句進(jìn)行編譯,，編譯完將生成libffmpegutilDecode.so庫(kù)文件,。

    在項(xiàng)目中通過(guò)如下語(yǔ)句加載libffmpegutilDecode.so庫(kù)文件。

    static{

        System.loadLibrary("ffmpegutilDecode");

    }

    libffmpegutilDecode.so庫(kù)文件載入完畢后,，就能通過(guò)調(diào)用本地定義的方法解碼視頻數(shù)據(jù),。本地定義解碼函數(shù)如下所示：

    public native boolean InitCodec(Surface surface);

    public native byte[] FFInputFrame(byte[] data,int len);

    public native void DeleteCodec();

    public native void SetBitmap(Bitmap bitmap,byte[]data,int len);

    在解碼成功后生成的Bitmap需要實(shí)時(shí)顯示，所以ImageView作為圖像容器類必須進(jìn)行實(shí)時(shí)更新。如果實(shí)時(shí)更新UI界面的大量工作放在主線程進(jìn)行,，可能會(huì)造成線程阻塞,、視頻卡頓等問(wèn)題。因此本系統(tǒng)另啟子線程來(lái)完成數(shù)據(jù)的接收和解碼等耗時(shí)操作,。視頻解碼播放流程如圖3所示,。

    目前，上海某公司已采用此系統(tǒng)進(jìn)行試用,，監(jiān)控端顯示界面如圖4所示,。

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

    本系統(tǒng)針對(duì)100M帶寬WiFi、4G,、3G這3種不同網(wǎng)絡(luò)條件進(jìn)行了系統(tǒng)性能的綜合測(cè)試,，監(jiān)控端視頻圖像分辨率為640×480，每種網(wǎng)絡(luò)條件分別測(cè)試20次,，計(jì)算平均值,。以Android監(jiān)控端統(tǒng)計(jì)的網(wǎng)絡(luò)時(shí)延、抖動(dòng),、丟包率和整體P2P連通率作為系統(tǒng)性能的考量依據(jù),。WiFi、4G,、3G下系統(tǒng)測(cè)試結(jié)果如表1所示,。

    從表1可以看出，該系統(tǒng)在3種網(wǎng)絡(luò)條件下都能實(shí)現(xiàn)較低的時(shí)延,、抖動(dòng),、丟包率和較高P2P連通率，能滿足監(jiān)控的高清實(shí)時(shí)性能需求,。

4 結(jié)論

    移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來(lái)為車(chē)載視頻智能監(jiān)控系統(tǒng)在智能交通領(lǐng)域的發(fā)展升級(jí)帶來(lái)了新的機(jī)遇,。針對(duì)傳統(tǒng)車(chē)載監(jiān)控系統(tǒng)存在的高清實(shí)時(shí)性能較差、網(wǎng)絡(luò)資源利用率低的問(wèn)題,，本文提出一種基于Android平臺(tái)的車(chē)載視頻智能監(jiān)控解決方案,，采用P2P和C/S混合網(wǎng)絡(luò)架構(gòu)，并利用多線程分別解決視頻的接收,、解碼,，通過(guò)緩沖機(jī)制解決視頻卡頓問(wèn)題。經(jīng)過(guò)實(shí)驗(yàn)測(cè)試驗(yàn)證,，本系統(tǒng)能適應(yīng)不同網(wǎng)絡(luò)條件,，能實(shí)現(xiàn)以較滿意的網(wǎng)絡(luò)資源利用率和視頻監(jiān)控質(zhì)量對(duì)車(chē)輛進(jìn)行實(shí)時(shí)監(jiān)控。

參考文獻(xiàn)

[1] 李佳毅,，徐曉輝,，蘇彥莽,，等．基于Android平臺(tái)的智能溫室視頻無(wú)線監(jiān)控系統(tǒng)[J]．農(nóng)機(jī)化研究，2013,，35(8)：188-191.

[2] 羅歡,，謝云，李丕杉．基于Android智能電視的視頻監(jiān)控的設(shè)計(jì)[J]．電視技術(shù),，2013(22)：85-87.

[3] PERKINS C.Rtp：Audio and video for the internet[M].Addison-Wesley Professional,，2003.

[4] SRISURENSH P，NETWORKS J,，EGEVANG K.Traditional IP network address translator(traditional NAT),，RFC 3022[Z].IETF，2001.

[5] EGEVANG K,，F(xiàn)RANCIS P.The IP network address translator(NAT),，RFC1631[Z].IETF，1996.