基于Android平臺的車載視頻智能監(jiān)控系統(tǒng)的研究*

王 浩，韓 敏，董 杰

(1.大連理工大學(xué) 電子信息與電氣工程學(xué)部，遼寧 大連116024；2.大連工業(yè)大學(xué) 信息科學(xué)與工程學(xué)院，遼寧 大連116034）

基于Android平臺的車載視頻智能監(jiān)控系統(tǒng)的研究*

王 浩1，韓 敏1，董 杰2

(1.大連理工大學(xué) 電子信息與電氣工程學(xué)部，遼寧 大連116024；2.大連工業(yè)大學(xué) 信息科學(xué)與工程學(xué)院，遼寧 大連116034）

針對傳統(tǒng)車載視頻監(jiān)控系統(tǒng)網(wǎng)絡(luò)資源利用率低、高清實時性能較差的問題，提出了一種基于 Android平臺的車載視頻監(jiān)控解決方案，對系統(tǒng)中關(guān)鍵模塊作了重點研究。系統(tǒng)實現(xiàn)了 P2P和C/S混合網(wǎng)絡(luò)架構(gòu)、多線程機(jī)制、丟包和包亂序處理,從而提高了實時監(jiān)控性能。經(jīng)實驗證明，該系統(tǒng)實現(xiàn)了針對車輛的實時高效的監(jiān)控，利于向智能交通領(lǐng)域中推廣。

P2P；心跳機(jī)制；NAT；FFmpeg；多線程

0 引言

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

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

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

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

圖1 系統(tǒng)整體框架

車載端基于 Android平臺開發(fā)，首先車載端會采集視頻數(shù)據(jù)，然后對采集的數(shù)據(jù)進(jìn)行 H.264編碼和實時傳輸協(xié)議（Real-time Transport Protocol，RTP）封包處理，最后將處理后的視頻數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)奖O(jiān)控端；視頻傳輸網(wǎng)絡(luò)基于點對點網(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實時更新顯示給監(jiān)控者。

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

2.1 視頻車載端

2.1.1 視頻采集和編碼

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

移動網(wǎng)絡(luò)的帶寬有限，為了呈現(xiàn)高質(zhì)量的監(jiān)控畫面，需要實現(xiàn)高編碼壓縮比。H.264充分地利用了各種冗余來達(dá)到高效的數(shù)據(jù)壓縮比率，同時還具備高質(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á)時間隨機(jī)性是視頻數(shù)據(jù)傳輸中很關(guān)鍵的問題，本系統(tǒng)采用 RTP[3]協(xié)議來負(fù)責(zé)視頻數(shù)據(jù)封包，利用數(shù)據(jù)包的時間戳、發(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ù)報協(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 網(wǎng)絡(luò)傳輸簡要工作流程圖

2.2.1 心跳機(jī)制

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

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

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

2.2.2 NAT穿透

在實際網(wǎng)絡(luò)環(huán)境下由于 IPv4地址短缺，使得許多客戶機(jī)都是通過NAT技術(shù)來共用一個公網(wǎng)IP地址[4]。NAT隱藏了參與構(gòu)建 P2P網(wǎng)絡(luò)的大量用戶節(jié)點，使得 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)對項目中存在的對稱型 NAT網(wǎng)絡(luò)環(huán)境進(jìn)行分析發(fā)現(xiàn)，對稱型 NAT對于從內(nèi)部網(wǎng)絡(luò)依次接收到的新連接，分配的輸出端口大致有兩種情況：

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

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

2.3 視頻監(jiān)控端

2.3.1 視頻解包

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

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

對于丟包處理，在 H.264編碼標(biāo)準(zhǔn)中，共定義了 I幀、P幀、B幀 3種幀。I幀為關(guān)鍵幀，存放完整的數(shù)據(jù)；而 P、B幀是輔助幀，存放運動矢量或邊緣信息，需要對關(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中來實現(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)采用重新編譯生成一個 so文件進(jìn)行調(diào)用。這個 so文件包含的是jni方法，這些方法能通過 Java層進(jìn)行調(diào)用，而方法中用到的函數(shù)則來自于 libffmpeg.so文件。

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

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

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

在項目中通過如下語句加載 libffmpegutilDecode.so庫文件。

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

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

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

圖3 視頻解碼播放流程

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次，計算平均值。以 Android監(jiān)控端統(tǒng)計的網(wǎng)絡(luò)時延、抖動、丟包率和整體 P2P連通率作為系統(tǒng)性能的考量依據(jù)。WiFi、4G、3G下系統(tǒng)測試結(jié)果如表1所示。

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

Research of vehicle intelligent video surveillance system based on Android platform

Wang Hao1，Han Min1，Dong Jie2
(1.Faculty of Electronic Information and Electrical Engineering，Dalian University of Technology，Dalian116024，China；2.School of Information Science and Engineering，Dalian Polytechnic University，Dalian116034，China)

Forsolving the problemsoflow network utilization and poorrealtime performance in traditionalvehicle video surveillance,this paper proposes the solution of vehicle video surveillance based on Android platform,key modules of this system are researched in detail.P2P and C/S mixed architecture,multi-thread mechanism,processing of package loss and reordering are used to improve the real-time monitoring performance.The experimental results show the system can real-time and efficiently monitor the vehicles,which conducive to expand to the intelligent transportation.

P2P；heartbeat mechanism；NAT；FFmpeg；multithread

TP277

：ADOI：10.16157/j.issn.0258-7998.2016.06.033

王浩，韓敏，董杰.基于 Android平臺的車載視頻智能監(jiān)控系統(tǒng)的研究[J].電子技術(shù)應(yīng)用，2016，42(6)：121-123，127.

英文引用格式：Wang Hao，Han Min，Dong Jie.Research of vehicle intelligent video surveillance system based on Android platform[J]. Application of Electronic Technique，2016，42(6)：121-123，127.

國家自然科學(xué)基金（61374154）