l 系統(tǒng)需要解決的問題

1．1 數(shù)字音視頻壓縮標準以及壓縮方式的選擇

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

(1)低比特率下的多媒體通信；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2．3 軟件設(shè)計

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

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

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

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

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

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

3 性能指標

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