摘 要：描述了基于3G標(biāo)準(zhǔn)的無線視頻監(jiān)控系統(tǒng)關(guān)鍵技術(shù)的研究與實現(xiàn)方案，主要包括基于H.264的雙碼流模塊、多線程、RTP打包等，它不僅具有傳統(tǒng)監(jiān)控系統(tǒng)穩(wěn)定性高、實時性好、免布線等優(yōu)點，而且用戶可以隨時隨地通過3G網(wǎng)絡(luò)進行視頻監(jiān)控和視頻圖像錄制。測試結(jié)果表明，各模塊都達到預(yù)期指標(biāo)，3G無線環(huán)境下可進行實時視頻瀏覽，視頻質(zhì)量與有線局域網(wǎng)相比相差不大。

關(guān)鍵詞：視頻監(jiān)控; 3G網(wǎng)絡(luò); 雙碼流; RTP

中圖分類號：TN29-34文獻標(biāo)識碼：A文章編號：1004-373X(2011)19-0055-03

Research and Implementation of the Key Technology of

Video Surveillance System Based on 3G Standard

WANG Yong-gang， ZHANG Jian-wu

(Dept. of Communication Engineering， Hangzhou Dianzi University， Hangzhou 310018， China)

Abstract： The research and design solution of the key technology of the wireless video surveillance based on the 3G standard are described， which includes H.264-based dual-stream module，multi-thread and RTP. The surveillance system has high stable and good real-time performance， and the users can perform the video monitoring and video recording through 3G network at anytime and anywhere. The testing result indicates that the modules meet the anticipated target， which can perform real-time view by video under the 3G environment. This system can achieve the real-time monitoring， and the video quality is not worse than that in LAN.

Keywords： video surveillance; 3G network; dual-stream; RTP

0 引 言

經(jīng)過多年的發(fā)展，視頻監(jiān)控技術(shù)已由早期模擬設(shè)備為主的第一代視頻監(jiān)控系統(tǒng)發(fā)展到目前的數(shù)字視頻監(jiān)控［1］，人們已不再滿足于傳統(tǒng)的監(jiān)控系統(tǒng)。隨著3G技術(shù)難點的突破以及3G網(wǎng)絡(luò)的發(fā)展，使3G無線視頻監(jiān)控［2］的實現(xiàn)成為了可能。在此背景下提出了一個基于3G標(biāo)準(zhǔn)的無線視頻監(jiān)控系統(tǒng)的設(shè)計方案并實現(xiàn)了基本功能，本文著重介紹該系統(tǒng)關(guān)鍵技術(shù)的實現(xiàn)方法，包括雙碼流模塊、多線程通信、RTP封裝及改進，最后討論了無線網(wǎng)絡(luò)視頻傳輸健壯性的問題以及解決方案。

1 雙碼流技術(shù)的實現(xiàn)

目前，困擾中國網(wǎng)絡(luò)視頻監(jiān)控市場發(fā)展的主要因素就是缺乏良好的網(wǎng)絡(luò)基礎(chǔ)環(huán)境，而雙碼流正是針對這一問題提出的解決方案，它是對安防行業(yè)的一次提速。

雙碼流，即在視頻編碼端中同時存在兩種碼流。雙碼流是通過在編碼端采用兩種格式或兩個不同的分辨率分別進行編碼來實現(xiàn)的。該監(jiān)控系統(tǒng)基于DM365硬件開發(fā)平臺，由于DM365開發(fā)板屬于DAVINCI系列，必須深入研究DM365應(yīng)用層調(diào)用具體算法的結(jié)構(gòu)，如圖1所示。由圖中可知，應(yīng)用層調(diào)用的接口是DMAI［3］(DaVinci Multimedia Application Interface)，它是DSP提供給ARM端應(yīng)用程序的調(diào)用接口。DMAI是各種模塊集合，應(yīng)用程序可以從中選擇模塊來使用。此外DMAI提供了源碼，便于修改使用，以滿足應(yīng)用要求。DMAI里面有各種接口實現(xiàn)方式，修改DMAI接口具體實現(xiàn)使其滿足雙碼流。

首先將DM365中兩個編碼通道全部使能，保證了開發(fā)板對雙碼流的支持，然后，在應(yīng)用程序中采集兩路的數(shù)據(jù)，分別調(diào)用DMAI中的編碼函數(shù)Venc1_create，進而對兩路數(shù)據(jù)進行兩次編碼，這樣就得到兩路不同分辨率大小的編碼數(shù)據(jù)流。本文實現(xiàn)了一路D1，一路是CIF大小(用于傳輸)的碼流，并且都達到20幀的速率，可以保證視頻流質(zhì)量。它在現(xiàn)有網(wǎng)絡(luò)瓶頸下兼顧了圖像質(zhì)量和傳輸實時性，可以突破網(wǎng)絡(luò)瓶頸，根據(jù)網(wǎng)絡(luò)帶寬靈活選擇碼流格式，達到本地高清存儲，同時保證一定遠程監(jiān)控質(zhì)量的低碼流網(wǎng)絡(luò)傳輸。

圖1 應(yīng)用層調(diào)用具體算法2 多線程技術(shù)在3G無線視頻監(jiān)控中的應(yīng)用

由于視頻圖像傳輸需要做到實時性和良好的傳輸質(zhì)量，而系統(tǒng)需求的功能又比較復(fù)雜，包括視頻數(shù)據(jù)采集、視頻編碼、RTP打包發(fā)送、視頻數(shù)據(jù)流保存等工作，而它們的流程又不是簡單的順序執(zhí)行，所以這里引入了多線程［4］。

本論文提出的方案中包括Capture，Video和Writer三個主要線程，分別完成原始數(shù)據(jù)YUV數(shù)據(jù)的采集、H.264［5］數(shù)據(jù)壓縮、視頻數(shù)據(jù)的寫文件，而在視頻采集線程中加入了異常檢測模塊(該模塊利用原始數(shù)據(jù)進行檢測異常)，在視頻數(shù)據(jù)壓縮線程中采用了雙碼流技術(shù)，并將CIF分辨率的壓縮數(shù)據(jù)進行RTP協(xié)議封裝，在Writer線程中實現(xiàn)了以時間為文件名的保存方式并將其保存到SD卡中。在此基礎(chǔ)上實現(xiàn)設(shè)防、拆防、異常檢測、客戶端與監(jiān)控端通信，又引入了兩個線程，分別完成等待電話、客戶端與監(jiān)控端的SOCKET通信完成命令傳輸功能。整個線程結(jié)構(gòu)與通信方式如圖2所示。

圖2 線程結(jié)構(gòu)與通信方式采用了pipe管道進行線程間通信，且設(shè)置為阻塞模式，整個流程即Capture線程得到數(shù)據(jù)，將地址送給Video線程，Video線程經(jīng)過H.264視頻壓縮把DI分辨率的地址送給Writer，而CIF分辨率根據(jù)發(fā)送標(biāo)記來確定是否發(fā)送，Writer線程完成寫文件操作后，將buffer指針返回，完成一幀采集、編碼、發(fā)送、保存等工作，如此反復(fù)循環(huán)。而其他線程通信則采用全局變量來進行傳輸標(biāo)記位，而無需使用FIFO，降低了實現(xiàn)復(fù)雜度。

3 RTP協(xié)議封裝及改進

本文采用RTP協(xié)議［6-7］，提供了端對端傳輸服務(wù)的實時傳輸協(xié)議，用來支持在單播和多播網(wǎng)絡(luò)服務(wù)中傳輸實時數(shù)據(jù)，而實際數(shù)據(jù)的傳輸則由RTCP控制協(xié)議來監(jiān)視和控制。RTP協(xié)議一般要求與RTCP［8］一起使用，來保證數(shù)據(jù)傳輸質(zhì)量。這種結(jié)構(gòu)在本次設(shè)計無線環(huán)境會遇到兩個問題：

(1) 如果增加RTCP，那么增加了復(fù)雜度，降低了實時性。

(2) RTP協(xié)議沒有加密信息，容易被非授權(quán)用戶瀏覽到視頻數(shù)據(jù)。

針對第一個問題，本文提出一個策略，即在編碼端RTP打包時，在每個NAL單元頭的前面加上4個字節(jié)的幀的長度，解碼端只要根據(jù)NAL單元的長度，即可判斷是否在傳輸中有錯誤，如果有將該NAL單元丟棄，此時無需采用RTCP來向監(jiān)控端反饋信息，從而降低實現(xiàn)復(fù)雜度；此時雖然丟棄了一個NAL單元，但是監(jiān)控端的幀率是20幀/s，根據(jù)人眼視覺殘留的效應(yīng)，這基本上不會引起人眼的察覺。這里還要說明，當(dāng)NAL單元的幀長大于MTU時，為了避免底層驅(qū)動將其分包，需要應(yīng)用層采用分片打包［9-10］方式，而此時只需在NAL單元的第一個分包增加4個字節(jié)的幀長度信息，而無需在每個分包上都加上該字段。這樣在手機端無需返回RTCP包等反饋信息，降低了實現(xiàn)復(fù)雜度，增強了實時性。

針對第二個問題，本文提出了一個簡單加密方案，具體采用的策略是在關(guān)鍵幀后加上自定義加密信息，本設(shè)計為3 b的自定義信息，在解碼端只要判斷該RTP分包是關(guān)鍵幀，去掉RTP頭，然后去掉4個字節(jié)幀長度信息，再去掉自定義3 b信息，而其他幀不做任何改變。當(dāng)解碼端收到RTP包時，對于非關(guān)鍵幀雖然能正常解包，但是它并不能獨立解碼，它必須依賴關(guān)鍵幀，因此關(guān)鍵幀加密后，只要關(guān)鍵幀不解密，其他幀都不能正常播放。這種方法無需在所有幀上都加入加密信息，只在關(guān)鍵幀RTP打包增加了幾個bit，就達到了比較好的加密效果，在應(yīng)用中要注意效率和復(fù)雜度的權(quán)衡來調(diào)整相應(yīng)方案。

4 無線視頻傳輸?shù)慕研匝芯?/p>

由于本文提出的視頻監(jiān)控系統(tǒng)，需要在3G無線網(wǎng)絡(luò)中傳輸，這勢必會受到各種因素的影響，這種干擾，輕微時不會淹沒正常圖像，而嚴(yán)重時圖像就無法觀看，或者由于無法捕捉到關(guān)鍵信息而無法顯示圖像。下面首先分析這種故障產(chǎn)生的原因：

(1) 視頻編碼端本身的問題。視頻編碼端傳輸線屏蔽性能差造成信號產(chǎn)生較大衰減。此外，編碼端也可能受到輻射、設(shè)施腐化等不定因素的影響，這也會產(chǎn)生同樣的問題。

(2) 無線傳輸環(huán)境的影響。無線信道中存在著Rayleigh衰減和多用戶干擾，會在傳輸位流中產(chǎn)生突發(fā)性錯誤(Burst Error)。但壓縮后的碼流在無線信道中傳輸仍然存在一些棘手的問題，一方面，這些壓縮后的碼流對信道比特誤碼非常敏感；另一方面，無線信道由于多徑反射和衰落引入了大量的隨機誤碼和突發(fā)誤碼，結(jié)果在解碼端將失去與編碼端的同步，同時預(yù)測編碼技術(shù)會將錯誤擴散到整個視頻序列中，降低了重建圖像的質(zhì)量。因此，為了實現(xiàn)良好質(zhì)量的視頻傳輸，必須結(jié)合無線信道的傳輸特性，采取一定的容錯措施［5］。

基于以上方面的考慮，以及斷續(xù)無法重連的問題，本文提出一種方案，并在實踐中得到良好的驗證，有效地解決了以上問題：即在編碼端得到編碼序列后周期性地發(fā)送兩個參數(shù)集，即序列參數(shù)集和圖像參數(shù)集，由于它們包含了解碼需要的大部分關(guān)鍵信息，包括圖像大小、量化參數(shù)、NAL單元類型等，因此即使在解碼端第一次無法與編碼端同步，也可以在后續(xù)過程中通過上述兩個參數(shù)集重新同步。未插入?yún)?shù)集之前、插入?yún)?shù)集之后的示意圖如圖3，圖4所示。

圖3 原始關(guān)鍵幀和非關(guān)鍵幀布局示意圖

圖4 周期性插入NAL單元后序列圖本文的具體方案是在編碼端周期性地發(fā)送上面的兩個序列集，會遇到一個問題，即發(fā)送間隔設(shè)置，這里提出H.264中一個重要概念I(lǐng)DR幀，由于編碼器算法是隔30幀編碼一個IDR幀，那么可以在這一個IDR幀之前加入上述兩個參數(shù)集，當(dāng)然也可以設(shè)置間隔為60，90幀，但這會引入更大延時，由于監(jiān)控產(chǎn)品嚴(yán)格的實時性要求，所以本文選定了隔30幀周期性發(fā)送，那么實際的關(guān)鍵幀間隔則變?yōu)?2幀。同時可以調(diào)整RTP協(xié)議里面的時間戳字段，使其配合關(guān)鍵幀間隔的變化。

5 測試結(jié)果

下面是對有線局域網(wǎng)和3G網(wǎng)絡(luò)分別在有碼率控制和無碼率控制的條件下得出的測試結(jié)果，如表1所示。