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

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

1 雙碼流技術(shù)的實(shí)現(xiàn)
    目前，困擾中國網(wǎng)絡(luò)視頻監(jiān)控市場發(fā)展的主要因素就是缺乏良好的網(wǎng)絡(luò)基礎(chǔ)環(huán)境，而雙碼流正是針對這一問題提出的解決方案，它是對安防行業(yè)的一次提速。
    雙碼流，即在視頻編碼端中同時(shí)存在兩種碼流。雙碼流是通過在編碼端采用兩種格式或兩個(gè)不同的分辨率分別進(jìn)行編碼來實(shí)現(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(DaVinci Multimedia Application Interface)，它是DSP提供給ARM端應(yīng)用程序的調(diào)用接口。DMAI是各種模塊集合，應(yīng)用程序可以從中選擇模塊來使用。此外DMAI提供了源碼，便于修改使用，以滿足應(yīng)用要求。DMAI里面有各種接口實(shí)現(xiàn)方式，修改DMAI接口具體實(shí)現(xiàn)使其滿足雙碼流。

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

2 多線程技術(shù)在3G無線視頻監(jiān)控中的應(yīng)用
    由于視頻圖像傳輸需要做到實(shí)時(shí)性和良好的傳輸質(zhì)量，而系統(tǒng)需求的功能又比較復(fù)雜，包括視頻數(shù)據(jù)采集、視頻編碼、RTP打包發(fā)送、視頻數(shù)據(jù)流保存等工作，而它們的流程又不是簡單的順序執(zhí)行，所以這里引入了多線程。
    本論文提出的方案中包括Capture，Video和Writer三個(gè)主要線程，分別完成原始數(shù)據(jù)YUV數(shù)據(jù)的采集、H．264數(shù)據(jù)壓縮、視頻數(shù)據(jù)的寫文件，而在視頻采集線程中加入了異常檢測模塊(該模塊利用原始數(shù)據(jù)進(jìn)行檢測異常)，在視頻數(shù)據(jù)壓縮線程中采用了雙碼流技術(shù)，并將CIF分辨率的壓縮數(shù)據(jù)進(jìn)行RTP協(xié)議封裝，在Writer線程中實(shí)現(xiàn)了以時(shí)間為文件名的保存方式并將其保存到SD卡中。在此基礎(chǔ)上實(shí)現(xiàn)設(shè)防、拆防、異常檢測、客戶端與監(jiān)控端通信，又引入了兩個(gè)線程，分別完成等待電話、客戶端與監(jiān)控端的SOCKET通信完成命令傳輸功能。整個(gè)線程結(jié)構(gòu)與通信方式如圖2所示。

    采用了pipe管道進(jìn)行線程間通信，且設(shè)置為阻塞模式，整個(gè)流程即Capture線程得到數(shù)據(jù)，將地址送給Video線程，Video線程經(jīng)過H．264視頻壓縮把DI分辨率的地址送給Writer，而CIF分辨率根據(jù)發(fā)送標(biāo)記來確定是否發(fā)送，Writer線程完成寫文件操作后，將buffer指針返回，完成一幀采集、編碼、發(fā)送、保存等工作，如此反復(fù)循環(huán)。而其他線程通信則采用全局變量來進(jìn)行傳輸標(biāo)記位，而無需使用FIFO，降低了實(shí)現(xiàn)復(fù)雜度。
[!--empirenews.page--]
3 RTP協(xié)議封裝及改進(jìn)
    本文采用RTP協(xié)議，提供了端對端傳輸服務(wù)的實(shí)時(shí)傳輸協(xié)議，用來支持在單播和多播網(wǎng)絡(luò)服務(wù)中傳輸實(shí)時(shí)數(shù)據(jù)，而實(shí)際數(shù)據(jù)的傳輸則由RTCP控制協(xié)議來監(jiān)視和控制。RTP協(xié)議一般要求與RTCP一起使用，來保證數(shù)據(jù)傳輸質(zhì)量。這種結(jié)構(gòu)在本次設(shè)計(jì)無線環(huán)境會遇到兩個(gè)問題：
    (1)如果增加RTCP，那么增加了復(fù)雜度，降低了實(shí)時(shí)性。
    (2)RTP協(xié)議沒有加密信息，容易被非授權(quán)用戶瀏覽到視頻數(shù)據(jù)。
    針對第一個(gè)問題，本文提出一個(gè)策略，即在編碼端RTP打包時(shí)，在每個(gè)NAL單元頭的前面加上4個(gè)字節(jié)的幀的長度，解碼端只要根據(jù)NAL單元的長度，即可判斷是否在傳輸中有錯(cuò)誤，如果有將該NAL單元丟棄，此時(shí)無需采用RTCP來向監(jiān)控端反饋信息，從而降低實(shí)現(xiàn)復(fù)雜度；此時(shí)雖然丟棄了一個(gè)NAL單元，但是監(jiān)控端的幀率是20幀／s，根據(jù)人眼視覺殘留的效應(yīng)，這基本上不會引起人眼的察覺。這里還要說明，當(dāng)NAL單元的幀長大于MTU時(shí)，為了避免底層驅(qū)動(dòng)將其分包，需要應(yīng)用層采用分片打包方式，而此時(shí)只需在NAL單元的第一個(gè)分包增加4個(gè)字節(jié)的幀長度信息，而無需在每個(gè)分包上都加上該字段。這樣在手機(jī)端無需返回RTCP包等反饋信息，降低了實(shí)現(xiàn)復(fù)雜度，增強(qiáng)了實(shí)時(shí)性。
    針對第二個(gè)問題，本文提出了一個(gè)簡單加密方案，具體采用的策略是在關(guān)鍵幀后加上自定義加密信息，本設(shè)計(jì)為3 b的自定義信息，在解碼端只要判斷該RTP分包是關(guān)鍵幀，去掉RTP頭，然后去掉4個(gè)字節(jié)幀長度信息，再去掉自定義3 b信息，而其他幀不做任何改變。當(dāng)解碼端收到RTP包時(shí)，對于非關(guān)鍵幀雖然能正常解包，但是它并不能獨(dú)立解碼，它必須依賴關(guān)鍵幀，因此關(guān)鍵幀加密后，只要關(guān)鍵幀不解密，其他幀都不能正常播放。這種方法無需在所有幀上都加入加密信息，只在關(guān)鍵幀RTP打包增加了幾個(gè)bit，就達(dá)到了比較好的加密效果，在應(yīng)用中要注意效率和復(fù)雜度的權(quán)衡來調(diào)整相應(yīng)方案。

4 無線視頻傳輸?shù)慕研匝芯?br />     由于本文提出的視頻監(jiān)控系統(tǒng)，需要在3G無線網(wǎng)絡(luò)中傳輸，這勢必會受到各種因素的影響，這種干擾，輕微時(shí)不會淹沒正常圖像，而嚴(yán)重時(shí)圖像就無法觀看，或者由于無法捕捉到關(guān)鍵信息而無法顯示圖像。下面首先分析這種故障產(chǎn)生的原因：
    (1)視頻編碼端本身的問題。視頻編碼端傳輸線屏蔽性能差造成信號產(chǎn)生較大衰減。此外，編碼端也可能受到輻射、設(shè)施腐化等不定因素的影響，這也會產(chǎn)生同樣的問題。
    (2)無線傳輸環(huán)境的影響。無線信道中存在著Rayleigh衰減和多用戶干擾，會在傳輸位流中產(chǎn)生突發(fā)性錯(cuò)誤(Burst Error)。但壓縮后的碼流在無線信道中傳輸仍然存在一些棘手的問題，一方面，這些壓縮后的碼流對信道比特誤碼非常敏感；另一方面，無線信道由于多徑反射和衰落引入了大量的隨機(jī)誤碼和突發(fā)誤碼，結(jié)果在解碼端將失去與編碼端的同步，同時(shí)預(yù)測編碼技術(shù)會將錯(cuò)誤擴(kuò)散到整個(gè)視頻序列中，降低了重建圖像的質(zhì)量。因此，為了實(shí)現(xiàn)良好質(zhì)量的視頻傳輸，必須結(jié)合無線信道的傳輸特性，采取一定的容錯(cuò)措施。
    基于以上方面的考慮，以及斷續(xù)無法重連的問題，本文提出一種方案，并在實(shí)踐中得到良好的驗(yàn)證，有效地解決了以上問題：即在編碼端得到編碼序列后周期性地發(fā)送兩個(gè)參數(shù)集，即序列參數(shù)集和圖像參數(shù)集，由于它們包含了解碼需要的大部分關(guān)鍵信息，包括圖像大小、量化參數(shù)、NAL單元類型等，因此即使在解碼端第一次無法與編碼端同步，也可以在后續(xù)過程中通過上述兩個(gè)參數(shù)集重新同步。未插入?yún)?shù)集之前、插入?yún)?shù)集之后的示意圖如圖3，圖4所示。

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

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

    下面是在有碼率控制且為80 Kb／s下，實(shí)驗(yàn)室有線、3G網(wǎng)絡(luò)狀況下的視頻截圖，如圖5，圖6所示。

    實(shí)驗(yàn)結(jié)果表明該監(jiān)控系統(tǒng)達(dá)到設(shè)計(jì)的主要指標(biāo)以及帶寬要求。系統(tǒng)有雙碼流產(chǎn)生，一路保存，一路CIF分辨率的數(shù)據(jù)發(fā)送并用VLC播放器接收后能實(shí)時(shí)播放，而且相比有線環(huán)境視頻質(zhì)量沒有受到很大影響，且可以實(shí)現(xiàn)隨機(jī)接入，延時(shí)2～3s。

6 結(jié)語
    基于3G標(biāo)準(zhǔn)的無線視頻監(jiān)控綜合了多門技術(shù)，主要包括視頻編解碼、3G無線網(wǎng)絡(luò)、流媒體協(xié)議等，隨著視頻監(jiān)控產(chǎn)業(yè)的發(fā)展，這些技術(shù)也隨之成為很有價(jià)值的研究課題。本文介紹了無線視頻監(jiān)控的幾個(gè)關(guān)鍵技術(shù)實(shí)現(xiàn)，并用軟件方法實(shí)現(xiàn)了視頻流實(shí)時(shí)傳輸。隨著3G網(wǎng)絡(luò)速度的提高和壓縮新技術(shù)的實(shí)現(xiàn)，可以進(jìn)一步降低延遲，得到真正的實(shí)時(shí)傳輸，為人們的生活帶來了更大的便利。