作者：趙明忠，尹亞蘭，曹可勁

監(jiān)控系統(tǒng)被廣泛應(yīng)用于保安、生產(chǎn)管理等需要無人值守的場(chǎng)合。雖然基于閉路電視的模擬監(jiān)控系統(tǒng)已經(jīng)發(fā)展得非常成熟，但當(dāng)前興起的數(shù)字視頻監(jiān)控系統(tǒng)與之相比，有許多優(yōu)點(diǎn)。數(shù)字視頻監(jiān)控系統(tǒng)的智能性和可靠性高，能提供遠(yuǎn)程訪問能力，視頻資料管理保存方便，而且可以開發(fā)升級(jí)。本文介紹了一種基于IP網(wǎng)絡(luò)的數(shù)字視頻監(jiān)控系統(tǒng)的設(shè)計(jì)實(shí)現(xiàn)方案，他從采集、傳輸?shù)浇K端控制實(shí)現(xiàn)了全過程數(shù)字化。 l 系統(tǒng)需要解決的問題

1．1 數(shù)字音視頻壓縮標(biāo)準(zhǔn)以及壓縮方式的選擇

現(xiàn)有的壓縮算法有H．263系列，M-JPEG，MPEG-1 VCD壓縮標(biāo)準(zhǔn)，MPEG-2 DVD壓縮標(biāo)準(zhǔn)，WAVELET小波變換，MPEG-4標(biāo)準(zhǔn)。這些算法各有優(yōu)缺點(diǎn)，也決定了其應(yīng)用于不同行業(yè)的適用性，H．263適合用于可視電話及視頻會(huì)議等對(duì)圖像大小和質(zhì)量要求不是很高的應(yīng)用領(lǐng)域；MJPEG，MPEG-1，MPEG-2由于實(shí)時(shí)性差以及數(shù)據(jù)量大的缺點(diǎn)不適合網(wǎng)絡(luò)傳輸；MPEG-4視頻壓縮技術(shù)的出現(xiàn)引發(fā)了壓縮領(lǐng)域的一場(chǎng)革命，他基本上克服了其他壓縮算法的缺點(diǎn)，利用很窄的帶寬，通過幀重建技術(shù)壓縮和傳輸資料，以求以最少的數(shù)據(jù)獲得最佳的圖像質(zhì)量。MPEG-4試圖達(dá)到2個(gè)目標(biāo)：

（1）低比特率下的多媒體通信；

（2）是多工業(yè)的多媒體通信的綜合。

據(jù)此目標(biāo)，MPEG-4引入AV對(duì)象（Audio／Visaul Objects），使得更多的交互操作成為可能。盡管MPEG-4并不是專為視頻監(jiān)控壓縮領(lǐng)域而設(shè)計(jì)的，但同樣也適合CIF（352×288）或者更高清晰度（768×576）情況下的視頻壓縮。

實(shí)現(xiàn)壓縮算法的方式有2種，軟件壓縮和硬件壓縮，其中硬件壓縮實(shí)時(shí)性好，性能可靠，市場(chǎng)上也存在專用的MPEG-4壓縮芯片或板卡。

為了達(dá)到實(shí)時(shí)性的要求，本系統(tǒng)采用MPEG-4壓縮算法的硬件壓縮方式。

1．2 信道環(huán)境以及實(shí)時(shí)性的考慮

目前可供選擇的信道有PSTN，N-ISDN，以太網(wǎng)等。而監(jiān)控系統(tǒng)大多數(shù)的應(yīng)用場(chǎng)合是在一個(gè)相對(duì)較小的地域內(nèi)進(jìn)行視頻監(jiān)控，因而可以使用已經(jīng)廣泛使用的以太網(wǎng)作為數(shù)字硬盤錄像系統(tǒng)視頻傳輸?shù)男诺?。目?00BASE-T以太網(wǎng)的帶寬已經(jīng)達(dá)到100Mb／s，可以滿足數(shù)字硬盤錄像系統(tǒng)提供高質(zhì)量清晰圖像、多路視頻同時(shí)傳輸?shù)囊?。因此本文選用100BASE-T以太網(wǎng)作為主要傳輸信道。

本文的任務(wù)主要是圍繞以太網(wǎng)來解決數(shù)字視頻的實(shí)時(shí)傳輸和組播問題。考慮在某些應(yīng)用場(chǎng)合需要遠(yuǎn)距離傳送視頻碼流，為此在設(shè)計(jì)網(wǎng)絡(luò)傳輸系統(tǒng)時(shí)就充分考慮了信道帶寬的限制，引人碼流和幀率動(dòng)態(tài)可調(diào)機(jī)制，較好地滿足了遠(yuǎn)程監(jiān)控場(chǎng)合對(duì)圖像質(zhì)量和圖像連續(xù)性的要求。

為了達(dá)到實(shí)時(shí)性，不光音視頻采集部分要實(shí)現(xiàn)實(shí)時(shí)性，傳輸部分也要達(dá)到實(shí)時(shí)要求，根據(jù)試驗(yàn)，采用MPEG-4要達(dá)到25幀／s，需要256kb／s的帶寬，可見100Mb／s的以太網(wǎng)可以滿足多路傳輸要求。

1．3 網(wǎng)絡(luò)協(xié)議和傳輸機(jī)制的控制

ISO組織制訂的OSI網(wǎng)絡(luò)參考模型中，運(yùn)輸層建立在IP層之上，包含2種傳輸協(xié)議：一種是傳輸控制協(xié)議TCP，他是面向連接的網(wǎng)絡(luò)協(xié)議；另一種是用戶數(shù)據(jù)報(bào)協(xié)議UDP，他是無連接的。其中TCP不適合實(shí)時(shí)傳輸音視頻資料，常用的是基于UDP的RTP協(xié)議。

由于UDP沒有差錯(cuò)控制，屬于不可靠的分組遞交，為了實(shí)現(xiàn)可靠交付和流量控制，IETF（因特網(wǎng)工程部）提出了RTP和RTCP兩個(gè)協(xié)議。所有的實(shí)時(shí)媒體資料都使用RTP進(jìn)行傳輸，RTCP提供接收方向發(fā)送方反饋信息的功能。他們都是基于UDP的。

2 系統(tǒng)設(shè)計(jì)

2．1 數(shù)字監(jiān)控系統(tǒng)網(wǎng)絡(luò)傳輸?shù)墓δ茉O(shè)計(jì)

系統(tǒng)原理框圖如圖l所示。

他由9個(gè)模塊組成，音視頻采集和壓縮處理由視頻采集卡硬件完成，采集卡通過附帶的SDK函數(shù)接口和網(wǎng)絡(luò)傳輸模塊之間通信，當(dāng)視頻采集卡完成視頻捕捉和壓縮處理后，RTP協(xié)議封裝模塊對(duì)數(shù)據(jù)塊進(jìn)行封裝和排序，然后交給UDP網(wǎng)絡(luò)傳輸模塊在IP網(wǎng)絡(luò)上傳輸；對(duì)于接收端所做的工作和發(fā)送端基本類似，只是負(fù)責(zé)把網(wǎng)絡(luò)傳輸過來的音視頻資料包重組和譯碼回放出來。

2．2 系統(tǒng)硬件構(gòu)成

圖2所示是整個(gè)系統(tǒng)的硬件組成，包括攝像頭、前端采集計(jì)算機(jī)和中心服務(wù)器3個(gè)主要部分，前端采集計(jì)算機(jī)中裝有視頻采集卡，根據(jù)采集卡的路數(shù)多少可以配備相應(yīng)數(shù)量的攝像頭。

2．3 軟件設(shè)計(jì)

系統(tǒng)工作為C／S方式，包括3個(gè)部分：采集、傳輸、服務(wù)器顯示和控制。

音視頻采集的軟件開發(fā)是在采集卡廠商提供一個(gè)SDK軟件包的基礎(chǔ)上進(jìn)行的。由于視頻資料包和碼流的大小會(huì)影響到視頻在網(wǎng)絡(luò)中傳輸?shù)膶?shí)時(shí)性和視頻在接收端回放時(shí)抖動(dòng)的程度，因此該音視頻資料包大小和碼流設(shè)置應(yīng)該是傳輸時(shí)的實(shí)時(shí)性和與回放時(shí)的抖動(dòng)情況的折衷。

發(fā)送端的取流、封裝和發(fā)送過程采用了32位操作系統(tǒng)搶先式多線程任務(wù)機(jī)制以解決CPU并行效率低等問題，整體上分為三緩沖區(qū)多線程結(jié)構(gòu)，即采用取流緩沖區(qū)、封裝緩沖區(qū)和發(fā)送緩沖區(qū)等3個(gè)緩沖區(qū)，分配了取流封裝線程、內(nèi)存切換線程、視頻圖像發(fā)送線程和程序主線程等4個(gè)線程，利用了取流緩沖區(qū)空、取流緩沖區(qū)滿、封裝緩沖區(qū)空、封裝緩沖區(qū)滿、發(fā)送緩沖區(qū)空、發(fā)送緩沖區(qū)滿及允許發(fā)送等7個(gè)事件，提高了視頻圖像傳輸?shù)男省?/p>

在使用RTP協(xié)議對(duì)視音頻復(fù)合流進(jìn)行封裝時(shí)，通行的做法是：在Windows操作系統(tǒng)中裝載RTP協(xié)議的動(dòng)態(tài)鏈接庫（DLL），然后將發(fā)送端的視頻編碼器輸出的數(shù)據(jù)流進(jìn)行相應(yīng)的成幀算法，形成適合于RTP協(xié)議格式的視頻流封裝，遞交給RTP協(xié)議分組處理模塊，加上此協(xié)議的分組報(bào)文頭，并根據(jù)當(dāng)前的采樣時(shí)鐘打上時(shí)間戳，標(biāo)記順序號(hào)，并給定幀頻、分辨率、相應(yīng)的壓縮格式等參數(shù)，經(jīng)多目地址傳輸來完成。在接收端，當(dāng)實(shí)時(shí)視頻資料到達(dá)后，去掉該層協(xié)議的頭標(biāo)，根據(jù)套接字應(yīng)用的埠號(hào)向上層遞交。RTP分組模塊處理遞交的資料分組，根據(jù)其會(huì)話標(biāo)識(shí)和序列號(hào)進(jìn)行鑒別，將有效的分組傳遞給相應(yīng)的譯碼緩沖區(qū)，實(shí)現(xiàn)視頻流內(nèi)部的同步。

為了避免引起廣播風(fēng)暴，采用了在PC平臺(tái)上實(shí)現(xiàn)IP組播，為此量身定制了一個(gè)基于微軟基本類庫MFC的IP組播類CMulticastSocket。IP組播類CMulticastSocket是在異步Socket類CAnsycsocket的基礎(chǔ)上派生出來的，分組中的每一個(gè)成員都可以動(dòng)態(tài)地加入和退出；組中的某個(gè)成員發(fā)出的信息，分組中其他所有的授權(quán)成員都能收到，他是UDP Sockets的一個(gè)分支。

由于數(shù)字硬盤錄像系統(tǒng)（DVR）還需要給客戶端提供網(wǎng)絡(luò)控制功能和傳送系統(tǒng)信息，在具體的網(wǎng)絡(luò)編程應(yīng)用中，采取UDP Socket和TCP Socket并存的編程機(jī)制。

3 性能指標(biāo)

本系統(tǒng)性能指標(biāo)如下：

支持100Base-T以太網(wǎng)環(huán)境下的8路CIF格式的視頻同時(shí)傳送；

支持50個(gè)遠(yuǎn)程客戶端同時(shí)訪問；

在客戶端，網(wǎng)絡(luò)視音頻傳輸?shù)难訒r(shí)低于1 000ms，且無明顯抖動(dòng)，客戶端重建的每路視頻的幀率大于25幀／s； 支持PSTN線路條件下的一路QCIF格式的視頻傳送，客戶端重建的視頻幀率大于5幀／s；

支持報(bào)警回傳，電話線自動(dòng)報(bào)警，對(duì)報(bào)警事件自動(dòng)錄像。

4 結(jié) 語

本文介紹的基于IP網(wǎng)絡(luò)的采用通用計(jì)算機(jī)結(jié)合視頻采集卡的音視頻監(jiān)控系統(tǒng)，已成功應(yīng)用于某大型倉庫的無人看護(hù)，使用情況表明其性能良好。今后，隨著相關(guān)技術(shù)的發(fā)展，基于IP網(wǎng)絡(luò)的功能更強(qiáng)大和體積更小巧的嵌入式數(shù)字監(jiān)控系統(tǒng)將得到越來越廣泛的應(yīng)用。

責(zé)任編輯：gt