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

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

現(xiàn)有的壓縮算法有H．263系列，M-JPEG，MPEG-1 VCD壓縮標準，MPEG-2 DVD壓縮標準，WAVELET小波變換，MPEG-4標準。這些算法各有優(yōu)缺點，也決定了其應用于不同行業(yè)的適用性，H．263適合用于可視電話及視頻會議等對圖像大小和質(zhì)量要求不是很高的應用領(lǐng)域；MJPEG，MPEG-1，MPEG-2由于實時性差以及數(shù)據(jù)量大的缺點不適合網(wǎng)絡傳輸；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)域而設計的，但同樣也適合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ù)的應用場合是在一個相對較小的地域內(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ù)囊?。因此本文選用100BASE-T以太網(wǎng)作為主要傳輸信道。

本文的任務主要是圍繞以太網(wǎng)來解決數(shù)字視頻的實時傳輸和組播問題。考慮在某些應用場合需要遠距離傳送視頻碼流，為此在設計網(wǎng)絡傳輸系統(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)絡協(xié)議和傳輸機制的控制

ISO組織制訂的OSI網(wǎng)絡參考模型中，運輸層建立在IP層之上，包含2種傳輸協(xié)議：一種是傳輸控制協(xié)議TCP，他是面向連接的網(wǎng)絡協(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)設計

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

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

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

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

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

2．3 軟件設計

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

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

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

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

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

3 性能指標

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