0 引言

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

    本文在Android平臺下提出了車載視頻智能監(jiān)控的解決方案。利用該方案，通過實(shí)現(xiàn)NAT穿透和P2P、C/S混合網(wǎng)絡(luò)架構(gòu)，提高了網(wǎng)絡(luò)健壯性和資源利用率；通過設(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平臺開發(fā)的車載視頻監(jiān)控系統(tǒng)。該系統(tǒng)主要由三部分組成，即車載端、視頻傳輸網(wǎng)絡(luò)和監(jiān)控端。系統(tǒng)整體框架如圖1所示。

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

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

2.1 視頻車載端

2.1.1 視頻采集和編碼

    視頻采集過程中，預(yù)覽圖像會占用大量內(nèi)存，內(nèi)存占用過大會導(dǎo)致內(nèi)存溢出，嚴(yán)重時(shí)會造成程序崩潰，本系統(tǒng)通過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)控畫面，需要實(shí)現(xiàn)高編碼壓縮比。H.264充分地利用了各種冗余來達(dá)到高效的數(shù)據(jù)壓縮比率，同時(shí)還具備高質(zhì)量流通的圖形，采用高度負(fù)責(zé)的算法，使其成為當(dāng)前在低碼率下壓縮比率最高的視頻編碼標(biāo)準(zhǔn)^[2]。所以本系統(tǒng)通過H.264技術(shù)來進(jìn)行數(shù)據(jù)編碼。

2.1.2 視頻封包

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

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

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

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

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

2.2.1 心跳機(jī)制

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

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

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

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

2.2.2 NAT穿透

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

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

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

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

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

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

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

2.3.2 視頻解碼和播放

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

    系統(tǒng)采用交叉編譯的方式將FFmpeg引入到Android中來實(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方法，這些方法能通過Java層進(jìn)行調(diào)用，而方法中用到的函數(shù)則來自于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解碼庫函數(shù)，可解碼H.264格式的視頻數(shù)據(jù)。

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

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

    static{

        System.loadLibrary("ffmpegutilDecode");

    }

    libffmpegutilDecode.so庫文件載入完畢后，就能通過調(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)行，可能會造成線程阻塞、視頻卡頓等問題。因此本系統(tǒng)另啟子線程來完成數(shù)據(jù)的接收和解碼等耗時(shí)操作。視頻解碼播放流程如圖3所示。

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

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

    本系統(tǒng)針對100M帶寬WiFi、4G、3G這3種不同網(wǎng)絡(luò)條件進(jìn)行了系統(tǒng)性能的綜合測試，監(jiān)控端視頻圖像分辨率為640×480，每種網(wǎng)絡(luò)條件分別測試20次，計(jì)算平均值。以Android監(jiān)控端統(tǒng)計(jì)的網(wǎng)絡(luò)時(shí)延、抖動(dòng)、丟包率和整體P2P連通率作為系統(tǒng)性能的考量依據(jù)。WiFi、4G、3G下系統(tǒng)測試結(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í)代的到來為車載視頻智能監(jiān)控系統(tǒng)在智能交通領(lǐng)域的發(fā)展升級帶來了新的機(jī)遇。針對傳統(tǒng)車載監(jiān)控系統(tǒng)存在的高清實(shí)時(shí)性能較差、網(wǎng)絡(luò)資源利用率低的問題，本文提出一種基于Android平臺的車載視頻智能監(jiān)控解決方案，采用P2P和C/S混合網(wǎng)絡(luò)架構(gòu)，并利用多線程分別解決視頻的接收、解碼，通過緩沖機(jī)制解決視頻卡頓問題。經(jīng)過實(shí)驗(yàn)測試驗(yàn)證，本系統(tǒng)能適應(yīng)不同網(wǎng)絡(luò)條件，能實(shí)現(xiàn)以較滿意的網(wǎng)絡(luò)資源利用率和視頻監(jiān)控質(zhì)量對車輛進(jìn)行實(shí)時(shí)監(jiān)控。

參考文獻(xiàn)

[1] 李佳毅，徐曉輝，蘇彥莽，等．基于Android平臺的智能溫室視頻無線監(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.