文獻標識碼： A
DOI：10.16157/j.issn.0258-7998.2016.06.033
中文引用格式： 王浩，韓敏，董杰. 基于Android平臺的車載視頻智能監控系統的研究[J].電子技術應用，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.
0 引言
車載視頻智能監控是智能交通領域的一個重要研究課題，它能方便用戶實時、直觀地監控車輛安全情況。傳統的車載視頻監控系統一般采用固定的PC監控方式，因而需要在指定的地點，并且在有專用網絡設備支持的情況下才能對目標現場進行監控，這大大限制了監控系統的應用范圍和靈活性[1]。近些年隨著移動互聯網的普及，市面上也出現了移動車載視頻監控的解決方案，但是又存在視頻畫質不理想、整體用戶體驗較差的問題，同時車輛的移動性也對網絡資源利用率提出了更高的要求。
本文在Android平臺下提出了車載視頻智能監控的解決方案。利用該方案，通過實現NAT穿透和P2P、C/S混合網絡架構，提高了網絡健壯性和資源利用率；通過設置緩沖區和調用FFmpeg多媒體解碼框架，提高了高清實時監控性能。實踐表明該方案能適應不同網絡條件，滿足了實際項目播放需求，具有良好的用戶體驗。
1 系統整體結構
本系統是基于Android平臺開發的車載視頻監控系統。該系統主要由三部分組成，即車載端、視頻傳輸網絡和監控端。系統整體框架如圖1所示。
車載端基于Android平臺開發，首先車載端會采集視頻數據，然后對采集的數據進行H.264編碼和實時傳輸協議（Real-time Transport Protocol，RTP）封包處理，最后將處理后的視頻數據通過網絡傳輸到監控端；視頻傳輸網絡基于點對點網絡（peer-to-peer，P2P）和客戶機、服務器結構（Client/Server，C/S）的混合網絡架構，其傳輸方式會優先選擇P2P連接，當P2P連接無法對網絡地址轉換（Network Address Translation，NAT）成功穿透而連接失敗后，再通過中轉服務器進行數據中轉，有效節省網絡帶寬，提高網絡資源利用率；監控端基于Android平臺開發，首先監控端在異步線程接收到網絡傳來的包數據，并對這些數據進行RTP解包和FFmpeg解碼，最后將解碼后得到的圖像通過ImageView實時更新顯示給監控者。
2 系統實現原理
2.1 視頻車載端
2.1.1 視頻采集和編碼
視頻采集過程中，預覽圖像會占用大量內存，內存占用過大會導致內存溢出，嚴重時會造成程序崩潰，本系統通過Camera.PreviewCallback的onPreviewFrame回調函數，實時截取每幀視頻流數據，并以setPreviewCallbackWithBuffer(Camera.PreviewCallback)的方式使用上述回調，提供一個字節數組作為緩沖區，用于保存預覽圖像數據，以有效管理預覽圖像時內存的分配和銷毀。
移動網絡的帶寬有限，為了呈現高質量的監控畫面，需要實現高編碼壓縮比。H.264充分地利用了各種冗余來達到高效的數據壓縮比率，同時還具備高質量流通的圖形，采用高度負責的算法，使其成為當前在低碼率下壓縮比率最高的視頻編碼標準[2]。所以本系統通過H.264技術來進行數據編碼。
2.1.2 視頻封包
數據包到達時間隨機性是視頻數據傳輸中很關鍵的問題，本系統采用RTP[3]協議來負責視頻數據封包，利用數據包的時間戳、發送序號等字段來控制數據流的傳輸。
但如果RTP包大于最大傳輸單元(Maximum Transmission Unit，MTU)，會導致底層協議任意拆包，這會使RTP包被分割后丟失的可能性增大，以致影響接收端數據的恢復，因而一般采用對網絡抽象層(Network Abstract Layer，NAL)單元進行分類處理，共有單一NAL單元模式、組合封包模式和分片封包模式3種封包策略。
本系統因不存在音頻數據，而H.264 NAL單元都含有較大數據量，故沒必要采用組合封包模式。本系統將RTP包長設定為1 024 B，將超過1 024 B的NAL單元采用分片封包模式，不超過的采用單一NAL單元模式。
2.2 視頻傳輸網絡
視頻傳輸網絡在監控系統中占有至關重要的地位，視頻數據傳輸質量的好壞直接影響了監控系統的使用效果。本系統采用面向無連接的用戶數據報協議（User Datagram Protocol，UDP）來負責視頻傳輸工作，并在傳統C/S模式的基礎上混合P2P傳輸技術，減少網絡帶寬的消耗，提高網絡資源利用率。網絡傳輸的簡要工作流程如圖2所示。
2.2.1 心跳機制
系統網絡傳輸的數據發送和接收都是通過SOCKET來進行，但倘若此SOCKET是斷開狀態，則在發送和接收數據時就不能保證數據能有效到達，所以本系統通過搭建狀態服務器來管理各車載端和監控端的在線狀態(即SOCKET連接狀態)。狀態服務器會進行如下操作：
(1)啟動新線程A1，監聽端口4112，接收車載端每隔30 s發來的心跳包，處理心跳包中的JSON數據并更新內存N2中車載端的狀態。
(2)啟動新線程A2，監聽端口4113，接收監控端每隔30 s發來的心跳包，處理心跳包中的JSON數據并更新內存N1中監控端的狀態。同步返回監控端對應的車載端的JSON格式的數據集合，以便監控端在界面上更新車載端的狀態顯示。
(3)啟動新線程A3，每隔60 s執行一次，循環N1中的監控端和N2中的車載端，根據時間戳判斷監控端或車載端是否已掉線，如掉線則更新對應的內存中的狀態。
2.2.2 NAT穿透
在實際網絡環境下由于IPv4地址短缺，使得許多客戶機都是通過NAT技術來共用一個公網IP地址[4]。NAT隱藏了參與構建P2P網絡的大量用戶節點，使得NAT穿透往往是制約P2P成功連接的關鍵。
NAT[5]可分成圓錐型NAT和對稱型NAT兩種類型。對于圓錐型NAT，本系統采用UDP對NAT的簡單穿越（simple traversal of UDP through NAT，STUN）方式能很好地解決UDP穿透問題，但因STUN方式對于對稱型 NAT不能提供有效的外部IP地址和端口號，所以無法成功穿透。
針對無法穿透對稱型NAT的缺陷，本系統采用基于端口預測的方法來解決，能夠在較多的場合盡可能地建立P2P連接。本系統對項目中存在的對稱型 NAT網絡環境進行分析發現，對稱型 NAT對于從內部網絡依次接收到的新連接，分配的輸出端口大致有兩種情況：
依照空閑端口按序連續分配的情況。因為在穿透過程中，車載端兩次數據的發送間隔不會很長，NAT為其分配的新輸出端口號相對于其原端口號的偏移量是一個較小范圍內的正數，因此系統可以在監控端執行端口探測，當收到車載端對該UDP報文的回復就意味著穿透成功。
在一定端口范圍內隨機分配的情況。雖然車載端NAT兩次輸出端口號間的偏移量具有隨機性，并且不同的設備和網絡環境也會產生較大的區別，但實際上每次分配的端口號之間都會具有一定的函數關系或統計上的關聯性。因此，可以通過研究其分布特性來預測，實施試探性穿透。
2.3 視頻監控端
2.3.1 視頻解包
由于網絡傳輸時受到MTU的限制，因此視頻數據在發送時被分割成一個個獨立的數據包進行傳輸。監控端收到這些數據包后，必須按一定規則將這些包重新組合還原，然后才能進行解碼播放。但當網絡傳輸不穩定時，系統易出現包亂序和丟包現象。
對于包亂序處理，當監控端收到的RTP數據包沒有正確排序時，本系統就需要按照包序列號進行重排。本系統在內存中建立雙向鏈表來充當緩沖區，當接收到數據包后就按包頭的序列號插入至對應位置。比如，接收到一個序列號SN=3的RTP包，就從鏈表尾開始搜索并插入到2、4節點中間。本系統緩沖區的最大長度設置為30時，能起到較好的緩沖效果，同時也能避免對設備內存造成較大負擔。
對于丟包處理，在H.264編碼標準中，共定義了I幀、P幀、B幀3種幀。I幀為關鍵幀，存放完整的數據；而P、B幀是輔助幀，存放運動矢量或邊緣信息，需要對關鍵幀進行參考。所以，本系統在數據傳輸過程中，如關鍵幀數據丟失，對其他的P幀和B幀數據都會造成影響，因此必須將關鍵幀連同其他相關幀全部舍棄。如果輔助幀數據丟失，只會對當前幀數據產生影響，則只需將當前幀直接舍棄。
2.3.2 視頻解碼和播放
Android自帶的Media Player支持的媒體格式僅局限于OpenCore中所支持的媒體格式。FFmpeg是一種包含音視頻錄制、轉換以及編解碼等功能的開源解決方案，其支持包括H.264在內的多種編碼格式的編解碼，具有較高的執行效率。
系統采用交叉編譯的方式將FFmpeg引入到Android中來實現H.264解碼，FFmpeg編譯模塊編譯生成libffmpeg.so文件之后，供Android系統的Java本地接口（Java Native Interface，JNI）層調用。
libffmpeg.so文件的調用較為復雜，本系統采用重新編譯生成一個so文件進行調用。這個so文件包含的是jni方法，這些方法能通過Java層進行調用，而方法中用到的函數則來自于libffmpeg.so文件。
首先需要編輯android.mk文件，文件具體內容如下：
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文件，此文件包含本地定義的方法，這些方法調用ffmpeg解碼庫函數，可解碼H.264格式的視頻數據。
com_act1_H264.c文件編輯成功后，就可執行ndk-build語句進行編譯，編譯完將生成libffmpegutilDecode.so庫文件。
在項目中通過如下語句加載libffmpegutilDecode.so庫文件。
static{
System.loadLibrary("ffmpegutilDecode");
}
libffmpegutilDecode.so庫文件載入完畢后，就能通過調用本地定義的方法解碼視頻數據。本地定義解碼函數如下所示：
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需要實時顯示，所以ImageView作為圖像容器類必須進行實時更新。如果實時更新UI界面的大量工作放在主線程進行，可能會造成線程阻塞、視頻卡頓等問題。因此本系統另啟子線程來完成數據的接收和解碼等耗時操作。視頻解碼播放流程如圖3所示。
目前，上海某公司已采用此系統進行試用，監控端顯示界面如圖4所示。
3 系統性能測試
本系統針對100M帶寬WiFi、4G、3G這3種不同網絡條件進行了系統性能的綜合測試，監控端視頻圖像分辨率為640×480，每種網絡條件分別測試20次，計算平均值。以Android監控端統計的網絡時延、抖動、丟包率和整體P2P連通率作為系統性能的考量依據。WiFi、4G、3G下系統測試結果如表1所示。
從表1可以看出，該系統在3種網絡條件下都能實現較低的時延、抖動、丟包率和較高P2P連通率，能滿足監控的高清實時性能需求。
4 結論
移動互聯網時代的到來為車載視頻智能監控系統在智能交通領域的發展升級帶來了新的機遇。針對傳統車載監控系統存在的高清實時性能較差、網絡資源利用率低的問題，本文提出一種基于Android平臺的車載視頻智能監控解決方案，采用P2P和C/S混合網絡架構，并利用多線程分別解決視頻的接收、解碼，通過緩沖機制解決視頻卡頓問題。經過實驗測試驗證，本系統能適應不同網絡條件，能實現以較滿意的網絡資源利用率和視頻監控質量對車輛進行實時監控。
參考文獻
[1] 李佳毅，徐曉輝，蘇彥莽，等．基于Android平臺的智能溫室視頻無線監控系統[J]．農機化研究，2013，35(8)：188-191.
[2] 羅歡，謝云，李丕杉．基于Android智能電視的視頻監控的設計[J]．電視技術，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，FRANCIS P.The IP network address translator(NAT)，RFC1631[Z].IETF，1996.