王 浩,韓 敏,董 杰
(1.大連理工大學(xué) 電子信息與電氣工程學(xué)部,遼寧 大連116024;2.大連工業(yè)大學(xué) 信息科學(xué)與工程學(xué)院,遼寧 大連116034)
基于Android平臺(tái)的車載視頻智能監(jiān)控系統(tǒng)的研究*
王 浩1,韓 敏1,董 杰2
(1.大連理工大學(xué) 電子信息與電氣工程學(xué)部,遼寧 大連116024;2.大連工業(yè)大學(xué) 信息科學(xué)與工程學(xué)院,遼寧 大連116034)
針對(duì)傳統(tǒng)車載視頻監(jiān)控系統(tǒng)網(wǎng)絡(luò)資源利用率低、高清實(shí)時(shí)性能較差的問題,提出了一種基于 Android平臺(tái)的車載視頻監(jiān)控解決方案,對(duì)系統(tǒng)中關(guān)鍵模塊作了重點(diǎn)研究。系統(tǒng)實(shí)現(xiàn)了 P2P和C/S混合網(wǎng)絡(luò)架構(gòu)、多線程機(jī)制、丟包和包亂序處理,從而提高了實(shí)時(shí)監(jiān)控性能。經(jīng)實(shí)驗(yàn)證明,該系統(tǒng)實(shí)現(xiàn)了針對(duì)車輛的實(shí)時(shí)高效的監(jiān)控,利于向智能交通領(lǐng)域中推廣。
P2P;心跳機(jī)制;NAT;FFmpeg;多線程
車載視頻智能監(jiān)控是智能交通領(lǐng)域的一個(gè)重要研究課題,它能方便用戶實(shí)時(shí)、直觀地監(jiān)控車輛安全情況。傳統(tǒng)的車載視頻監(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)車載視頻監(jiān)控的解決方案,但是又存在視頻畫質(zhì)不理想、整體用戶體驗(yàn)較差的問題,同時(shí)車輛的移動(dòng)性也對(duì)網(wǎng)絡(luò)資源利用率提出了更高的要求。
本文在Android平臺(tái)下提出了車載視頻智能監(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)。
本系統(tǒng)是基于 Android平臺(tái)開發(fā)的車載視頻監(jiān)控系統(tǒng)。該系統(tǒng)主要由三部分組成,即車載端、視頻傳輸網(wǎng)絡(luò)和監(jiān)控端。系統(tǒng)整體框架如圖1所示。
圖1 系統(tǒng)整體框架
車載端基于 Android平臺(tái)開發(fā),首先車載端會(huì)采集視頻數(shù)據(jù),然后對(duì)采集的數(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)對(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)成功穿透而連接失敗后,再通過中轉(zhuǎn)服務(wù)器進(jìn)行數(shù)據(jù)中轉(zhuǎn),有效節(jié)省網(wǎng)絡(luò)帶寬,提高網(wǎng)絡(luò)資源利用率;監(jiān)控端基于 Android平臺(tái)開發(fā),首先監(jiān)控端在異步線程接收到網(wǎng)絡(luò)傳來(lái)的包數(shù)據(jù),并對(duì)這些數(shù)據(jù)進(jìn)行RTP解包和 FFmpeg解碼,最后將解碼后得到的圖像通過 ImageView實(shí)時(shí)更新顯示給監(jiān)控者。
2.1 視頻車載端
2.1.1 視頻采集和編碼
視頻采集過程中,預(yù)覽圖像會(huì)占用大量?jī)?nèi)存,內(nèi)存占用過大會(huì)導(dǎo)致內(nèi)存溢出,嚴(yán)重時(shí)會(huì)造成程序崩潰,本系統(tǒng)通過 Camera.PreviewCallback的 onPreviewFrame回調(diào)函數(shù),實(shí)時(shí)截取每幀視頻流數(shù)據(jù),并以 setPreviewCallback-WithBuffer(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充分地利用了各種冗余來(lái)達(dá)到高效的數(shù)據(jù)壓縮比率,同時(shí)還具備高質(zhì)量流通的圖形,采用高度負(fù)責(zé)的算法,使其成為當(dāng)前在低碼率下壓縮比率最高的視頻編碼標(biāo)準(zhǔn)[2]。所以本系統(tǒng)通過 H. 264技術(shù)來(lái)進(jìn)行數(shù)據(jù)編碼。
2.1.2 視頻封包
數(shù)據(jù)包到達(dá)時(shí)間隨機(jī)性是視頻數(shù)據(jù)傳輸中很關(guā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ù)量,故沒必要采用組合封包模式。本系統(tǒng)將RTP包長(zhǎng)設(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)采用面向無(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 網(wǎng)絡(luò)傳輸簡(jiǎn)要工作流程圖
2.2.1 心跳機(jī)制
系統(tǒng)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)發(fā)送和接收都是通過 SOCKET來(lái)進(jìn)行,但倘若此 SOCKET是斷開狀態(tài),則在發(fā)送和接收數(shù)據(jù)時(shí)就不能保證數(shù)據(jù)能有效到達(dá),所以本系統(tǒng)通過搭建狀態(tài)服務(wù)器來(lái)管理各車載端和監(jiān)控端的在線狀態(tài)(即SOCKET連接狀態(tài))。狀態(tài)服務(wù)器會(huì)進(jìn)行如下操作:
(1)啟動(dòng)新線程 A1,監(jiān)聽端口 4112,接收車載端每隔30 s發(fā)來(lái)的心跳包,處理心跳包中的 JSON數(shù)據(jù)并更新內(nèi)存 N2中車載端的狀態(tài)。
(2)啟動(dòng)新線程 A2,監(jiān)聽端口 4113,接收監(jiān)控端每隔30 s發(fā)來(lái)的心跳包,處理心跳包中的 JSON數(shù)據(jù)并更新內(nèi)存 N1中監(jiān)控端的狀態(tài)。同步返回監(jiān)控端對(duì)應(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)控端或車載端是否已掉線,如掉線則更新對(duì)應(yīng)的內(nèi)存中的狀態(tài)。
2.2.2 NAT穿透
在實(shí)際網(wǎng)絡(luò)環(huán)境下由于 IPv4地址短缺,使得許多客戶機(jī)都是通過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穿透問題,但因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)樵诖┩高^程中,車載端兩次數(shù)據(jù)的發(fā)送間隔不會(huì)很長(zhǎng),NAT為其分配的新輸出端口號(hào)相對(duì)于其原端口號(hào)的偏移量是一個(gè)較小范圍內(nèi)的正數(shù),因此系統(tǒng)可以在監(jiān)控端執(zhí)行端口探測(cè),當(dāng)收到車載端對(duì)該 UDP報(bào)文的回復(fù)就意味著穿透成功。
在一定端口范圍內(nèi)隨機(jī)分配的情況。雖然車載端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)性。因此,可以通過研究其分布特性來(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ù)包沒有正確排序時(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包,就從鏈表尾開始搜索并插入到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ā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)換以及編解碼等功能的開源解決方案,其支持包括 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方法,這些方法能通過 Java層進(jìn)行調(diào)用,而方法中用到的函數(shù)則來(lái)自于 libffmpeg.so文件。
首先需要編輯android.mk文件,文件具體內(nèi)容如下:
成功編譯android.mk文件后需編輯com_act1_H264.c文件,此文件包含本地定義的方法,這些方法調(diào)用 ffmpeg解碼庫(kù)函數(shù),可解碼H.264格式的視頻數(shù)據(jù)。
com_act1_H264.c文件編輯成功后,就可執(zhí)行 ndkbuild語(yǔ)句進(jìn)行編譯,編譯完將生成 libffmpegutilDecode.so庫(kù)文件。
在項(xiàng)目中通過如下語(yǔ)句加載 libffmpegutilDecode.so庫(kù)文件。
libffmpegutilDecode.so庫(kù)文件載入完畢后,就能通過調(diào)用本地定義的方法解碼視頻數(shù)據(jù)。本地定義解碼函數(shù)如下所示:
在解碼成功后生成的 Bitmap需要實(shí)時(shí)顯示,所以ImageView作為圖像容器類必須進(jìn)行實(shí)時(shí)更新。如果實(shí)時(shí)更新UI界面的大量工作放在主線程進(jìn)行,可能會(huì)造成線程阻塞、視頻卡頓等問題。因此本系統(tǒng)另啟子線程來(lái)完成數(shù)據(jù)的接收和解碼等耗時(shí)操作。視頻解碼播放流程如圖3所示。
目前,上海某公司已采用此系統(tǒng)進(jìn)行試用,監(jiān)控端顯示界面如圖4所示。
圖3 視頻解碼播放流程
本系統(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í)性能需求。
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平臺(tái)的車載視頻智能監(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.
國(guó)家自然科學(xué)基金(61374154)