王軍

【摘要】視頻監(jiān)控系統(tǒng)的應(yīng)用軟件能力上應(yīng)支持多任務(wù)并發(fā)處理，如監(jiān)視、錄像、回訪、備份、報警、控制、遠(yuǎn)程連接等的多任務(wù)處理能力；本課題主要是開發(fā)這樣一個軟件環(huán)境，使客戶端完成現(xiàn)場圖像接收，用戶登錄管理，優(yōu)先權(quán)的分配，控制信號的協(xié)調(diào)，圖像的實時監(jiān)控，錄像的存儲、檢索、回放、備份、恢復(fù)等。本文主要探討了基于流媒體通信技術(shù)的視頻監(jiān)控設(shè)計。

【關(guān)鍵詞】視頻監(jiān)控；流媒體；通信技術(shù)

一、研究的內(nèi)容

本系統(tǒng)采用流行的分布式C/S架構(gòu)對系統(tǒng)進行設(shè)計，在基于微機平臺的數(shù)字監(jiān)控系統(tǒng)（DVR）的基礎(chǔ)上添加網(wǎng)絡(luò)監(jiān)控功能，所有被采集的圖像集中到中心的圖像監(jiān)控服務(wù)器統(tǒng)一存儲和管理，系統(tǒng)采用MPEG-4對視頻信號進行編譯碼，通過TCP/IP技術(shù)、RTP/RTCP實時傳送視頻監(jiān)控流，使用者通過一個或多個圖像監(jiān)控客戶端進行全面監(jiān)控。

視頻監(jiān)控系統(tǒng)的應(yīng)用軟件能力上應(yīng)支持多任務(wù)并發(fā)處理，如監(jiān)視、錄像、回訪、備份、報警、控制、遠(yuǎn)程連接等的多任務(wù)處理能力；本課題主要是開發(fā)這樣一個軟件環(huán)境，使客戶端完成現(xiàn)場圖像接收，用戶登錄管理，優(yōu)先權(quán)的分配，控制信號的協(xié)調(diào)，圖像的實時監(jiān)控，錄像的存儲、檢索、回放、備份、恢復(fù)等。本文具體工作如下：

1、實現(xiàn)服務(wù)器端與客戶端的數(shù)據(jù)通訊功能；

2、將通訊模塊獲得的MPEG-4碼進行解碼；

3、把解碼器的輸出結(jié)果顯示到屏幕中某個窗口；

4、實現(xiàn)對所有監(jiān)控點進行遠(yuǎn)程硬盤錄像存儲且對某一時間、地點的錄像資料可進行檢索和回放；

5、設(shè)置用戶權(quán)限功能。

二、視頻監(jiān)控系統(tǒng)設(shè)計方案

1、數(shù)字視頻監(jiān)控系統(tǒng)框架設(shè)計

按照C/S模式設(shè)計，視頻監(jiān)控系統(tǒng)分為服務(wù)端和客戶端，服務(wù)端采集數(shù)據(jù)，經(jīng)過處理后通過IP網(wǎng)絡(luò)傳輸至客戶端，客戶端接收處理后進行播放。具體結(jié)構(gòu)如圖3.2所示。

服務(wù)端分為視頻采集預(yù)覽、壓縮編碼和網(wǎng)絡(luò)發(fā)送模塊三部分，相應(yīng)地，客戶端分為網(wǎng)絡(luò)接收模塊、視頻解碼和視頻播放三部分。各部分的具體功能如下：

（1）視頻采集預(yù)覽：該模塊對監(jiān)控現(xiàn)場進行實時圖像采集，并在服務(wù)端的PC機上實時預(yù)覽。

（2）壓縮編碼：采用H.264編碼器，將實時視頻圖像壓縮編碼為H.264格式的比特流。

（3）網(wǎng)絡(luò)發(fā)送：該模塊實現(xiàn)三個功能，首先采取RTP協(xié)議將上一級生成的比特流包裝為RTP包，其次通過IP網(wǎng)絡(luò)發(fā)送，同時通過RTCP協(xié)議實現(xiàn)網(wǎng)絡(luò)QoS監(jiān)控。

（4）網(wǎng)絡(luò)接收：該模塊負(fù)責(zé)接收服務(wù)端發(fā)送的RTP包，解析包數(shù)據(jù)，并且與服務(wù)端的發(fā)送模塊配合完成RTCP監(jiān)控。

（5）視頻解碼：采用H.264解碼器，將上一級生成的比特流數(shù)據(jù)解碼生成幀圖像。

（6）視頻播放：在客戶端的PC機上播放實時視頻流。

各個模塊相互配合，完成端到端的實時視頻流傳輸回放，視頻數(shù)據(jù)發(fā)送和接收具體過程如下：服務(wù)端先啟動，并一直處于監(jiān)聽狀態(tài)，當(dāng)客戶端要請求數(shù)據(jù)時，它向服務(wù)端的IP地址和端口發(fā)出連接請求，服務(wù)端收到后，同意建立連接，則向客戶端發(fā)送視頻數(shù)據(jù)。

在IP網(wǎng)絡(luò)上的進行視頻數(shù)據(jù)傳送需要遵循一定的傳輸協(xié)議，由于視頻實時傳輸本身的特點和要求，傳統(tǒng)的網(wǎng)絡(luò)協(xié)議如TCP、UDP等無法勝任此項工作，于是國際標(biāo)準(zhǔn)化組織IETF制定了面向?qū)崟r流媒體的RTP協(xié)議，提供了上述打包分組功能，并且滿足視頻流實時傳輸?shù)囊?。因此一般的視頻傳輸應(yīng)用系統(tǒng)中，一般是基于RTP協(xié)議實現(xiàn)視頻流的傳輸和控制，本文也采用該協(xié)議。

2、數(shù)字視頻監(jiān)控系統(tǒng)的功能模型建立

現(xiàn)場監(jiān)控主機完成對監(jiān)控硬件設(shè)備的操作，實現(xiàn)對視頻數(shù)據(jù)回放和存儲等功能。此外還可向遠(yuǎn)端的中心監(jiān)控主機及其他的遠(yuǎn)程終端發(fā)送視頻信息并驗證該用戶的權(quán)限。圖3.3為現(xiàn)場監(jiān)控主機功能模型。

本文中使用視頻服務(wù)器來代替現(xiàn)場監(jiān)控主機，與現(xiàn)場監(jiān)控主機一樣，該視頻服務(wù)器實現(xiàn)對音、視頻數(shù)據(jù)壓縮并把數(shù)據(jù)保存在內(nèi)置的硬盤上，并可通過網(wǎng)絡(luò)把數(shù)據(jù)傳輸?shù)街行谋O(jiān)控主機和視頻監(jiān)控主服務(wù)器上進行解碼和顯示。

基于視頻服務(wù)器的數(shù)字視頻監(jiān)控系統(tǒng)由以下幾部分組成：

（1）視頻服務(wù)器

視頻服務(wù)器集視/音頻壓縮、報警開關(guān)輸入/輸出、網(wǎng)絡(luò)傳輸于一體，完成監(jiān)控系統(tǒng)中的數(shù)據(jù)采集、壓縮和傳輸?shù)裙ぷ鳌Ｒ曨l服務(wù)器的功能模型如圖3.4所示。

（2）中心監(jiān)控主機

中心監(jiān)控土機是本地或者遠(yuǎn)端的分監(jiān)控中心，是局域網(wǎng)中的監(jiān)控主機，主要實現(xiàn)視頻數(shù)據(jù)實時解壓回放、視頻圖像處理、視頻數(shù)據(jù)存儲管理、實時報警處理和對攝像頭的控制等，如圖3.5所示：

（3）監(jiān)控主服務(wù)器

監(jiān)控主服務(wù)器是整個監(jiān)控系統(tǒng)的總控中心，擁有最高的中心監(jiān)控主機和現(xiàn)場視頻服務(wù)器的訪問權(quán)限。監(jiān)控主服務(wù)器能對任意一路視頻信號進行實時監(jiān)控并能控制每個攝像頭的動作。監(jiān)控主服務(wù)器的主要功能與中心監(jiān)控主機相同，但增加了與Internet連接的功能，可實現(xiàn)監(jiān)控系統(tǒng)的Internet訪問。監(jiān)控主服務(wù)器的功能模型如圖3.6所示。

3、視頻監(jiān)控局域網(wǎng)

整個監(jiān)控系統(tǒng)可以通過專用視頻傳輸網(wǎng)絡(luò)及企業(yè)內(nèi)部己存的局域網(wǎng)進行連接。具體網(wǎng)絡(luò)結(jié)構(gòu)會影響視頻傳輸采用的傳輸協(xié)議，它取決于企業(yè)現(xiàn)有網(wǎng)絡(luò)的狀況。

三、客戶端設(shè)計

1、數(shù)字視頻監(jiān)控系統(tǒng)視頻播放器的實現(xiàn)

（1）DirectShow軟件開發(fā)相關(guān)技術(shù)

①COM編程基礎(chǔ)

DirectX采用了COM標(biāo)準(zhǔn)。而DirectShow是一套完全基于COM的應(yīng)用系統(tǒng)。DirectShow應(yīng)用程序?qū)嶋H上是一種COM組件的客戶程序，只是COM組件的“使用”問題。這些問題包括如何創(chuàng)建COM組件、如何得到組件對象上的接口以及調(diào)用接口方法、如何管理組件對象（即需要熟悉COM的引用計數(shù)制）等。

COM本身只是一種規(guī)范，而不是實現(xiàn)。但是當(dāng)使用C++來實現(xiàn)時，COM組件就是一個C++類，而接口都是純虛類。

COM規(guī)范規(guī)定，任何組件或接口都必須從IUnknown接口中繼承而來。IUnknown定義了三個重要函數(shù)，分別是QueryInterface、AddRef和Release。其中，QueryInterface負(fù)責(zé)組件對象上的接口查詢，AddRef用于增加引用計數(shù)，Release用于減少引用計數(shù)。引用計數(shù)是COM中的一個非常重要的概念，它很好的解決了組件對象的生命周期問題，即COM組件到底什么時候被銷毀，以及由誰來銷毀的問題。

除了IUnknown接口外，還有另外一個重要的接口，即IClassFactory。COM組件實際上是一個C++類，對于組件的外部使用者來說，這個類名一般不可知，那么如何創(chuàng)建這個類得實例？由誰來創(chuàng)建？COM規(guī)范規(guī)定，它實現(xiàn)了IClassFactory接口。在IClassFactory的接口函數(shù)CreateInstance中，才能使用new操作生成一個COM組件類對象實例。

②COM組件的實現(xiàn)方式

客戶程序和組件程序運行在同一進程空間中的組件程序稱為進程內(nèi)組件?？蛻舫绦蚺c組件程序建立起通信關(guān)系后，客戶程序得到的接口直接指向組件程序中的接口的vtable，客戶代碼可以直接調(diào)用組件的成員函數(shù)。動態(tài)連接庫（DLL）是進程內(nèi)組件的一種實現(xiàn)方式。組件程序的這種調(diào)用方式效率非常高，所以應(yīng)用非常廣泛。組件程序在調(diào)用時有白己的進程空間，客戶程序和組件程序運行在不同的進程空間的程序稱為進程外組件。在windows平臺上，一般用EXE程序模塊來實現(xiàn)進程外組件程序?？蛻舫绦蚝徒M件程序進程間的通信必須跨進程。在COM技術(shù)中客戶程序與組件程序有兩種方式通信方式，當(dāng)組件程序和客戶程序在同一機器上時采用本地過程調(diào)用，當(dāng)組件程序和客戶程序不在同一機器上時采用遠(yuǎn)程過程調(diào)用方法。進程外的組件運行效率比進程內(nèi)組件效率要低，但跨進程的調(diào)用為客戶程序帶來安全性，組件程序的錯誤不會是客戶程序崩潰。

2、DirectShow應(yīng)用程序開發(fā)步驟

DirectShow是基于COM技術(shù)的多媒體開發(fā)結(jié)構(gòu)體系，因此了解和掌握COM組件技術(shù)對理解DirectShow體系結(jié)構(gòu)和掌握軟件開發(fā)方法都著極其重要的意義。DirectShow應(yīng)用程序開發(fā)又有其自身的特點和方法。典型的DirectShow應(yīng)用程序開發(fā)通常遵循以下幾個步驟：

l、建一個Filter Graph Manager實例；

2、利用Filter Graph Manager組建Filter Graph；

3、應(yīng)用程序?qū)ilter Graph進行控制，響應(yīng)事件通知。

Filter Graph Manager是DirectShow的一個對象，可以通過CoCreatehistanee函數(shù)創(chuàng)建該對象的實例，利用該實例，我們可以構(gòu)建和控制FilterGraph；并能對FilterGraph進行同步、事件通知處理等其它控制。圖4.1為一個播放器的播放鏈路（Filter Graph）的構(gòu)建：

3、視頻監(jiān)控系統(tǒng)客戶端播放器的實現(xiàn)

客戶端軟件能實現(xiàn)視頻、音頻流的實時播放?？蛻舳塑浖肧ocket接收傳過來的視/音頻數(shù)據(jù)，放到VideoSource這個緩沖區(qū)里，然后通過解析函數(shù)，解析出視頻流和音頻流。視頻流與音頻流不同的地方在于幀的類型，我們就通過幀的類型的不同來判斷是視頻流還是音頻流，若為視頻流則進緩沖區(qū)，然后進一步處理，若為音頻流則直接解碼播放。

視頻的播放是客戶端的重要功能?？蛻舳塑浖谠O(shè)計中采用了多線程編程方式，主要包括接收線程、解碼線程、顯示線程。客戶端播放顯示功能的實現(xiàn)可以用圖4.2所示的流程圖來表示：

其中數(shù)據(jù)解壓組件就是一個解碼器它包含了三個組件：數(shù)據(jù)分離器（DataSplitter）、音頻解碼器（AudioDecomp）和視頻解碼器（VideoDecomp）。運用包容技術(shù)把它們組合到一起。圖4.3是解碼器（Decompressor）組件的數(shù)據(jù)流程圖：

4、數(shù)字視頻監(jiān)控系統(tǒng)客戶端的實現(xiàn)

數(shù)字視頻監(jiān)控系統(tǒng)客戶端的實現(xiàn)原理：

從DirectShow的角度來看，該程序的實現(xiàn)類似于圖4.4和圖4.5的Filter Graph：前者負(fù)責(zé)將本地采集到的音視頻數(shù)據(jù)使用Socket傳輸給遠(yuǎn)程端；而后者使用Socket接收遠(yuǎn)程端發(fā)送過來的音視頻數(shù)據(jù)，然后在本地播放。

因為音視頻數(shù)據(jù)是大量的、連續(xù)的、需要可靠傳輸?shù)模虼诉@些數(shù)據(jù)的傳輸可以選用TCP協(xié)議。而通信雙方的控制命令數(shù)據(jù)量很小，而且重要性也不是很強，因此可以選用UDP協(xié)議。為了讓在Socket上傳輸?shù)臄?shù)據(jù)簡單或者說提高Socket傳輸?shù)男?，該程序?qū)⒁纛l和視頻數(shù)據(jù)的傳輸分離，分別為它們創(chuàng)建一條Socket連接。而在單個Socket上，可以同時進行數(shù)據(jù)的發(fā)送和接收。

作為Filter開發(fā)的一條基本原則，F(xiàn)ilter實現(xiàn)的功能應(yīng)該力求單一。因此該程序?qū)ocket相關(guān)的操作都放在應(yīng)用程序?qū)又?，而僅將完成連接的Socket句柄通過Filter的公共接口設(shè)置給Net Sender和Net Receiver。這兩個Filter在內(nèi)部實現(xiàn)時，只須使用外部設(shè)置進來的Socket進行數(shù)據(jù)的發(fā)送和接收就可以了，而不用去管Socket的創(chuàng)建、連接等一系列繁瑣的交互過程。

當(dāng)通信雙方的Socket連接建立起來以后，構(gòu)建圖4.4的Filter Graph是沒有任何問題的。而此時構(gòu)建圖4.5的Filter Graph卻不能完全成功（可以將Filter加入到Filter Graph中但不能完成連接），因為Net Receiver不知道將要接收到何種格式的數(shù)據(jù)?？墒荖et Sender知道（通過這個Filter與Capture Filter連接用的媒體類型可以知道）。于是，當(dāng)構(gòu)建圖4.4所示的Filter Graph后，應(yīng)該馬上將它運行起來，然后在Net Sender接收到Capture Filter發(fā)送出來的第一個Sample時，首先將數(shù)據(jù)格式發(fā)送給遠(yuǎn)程端；遠(yuǎn)程端在接收到這個數(shù)據(jù)格式之后就可以重構(gòu)一個DirectShow中使用的媒體類型，然后通知應(yīng)用程序完成Filter之間的連接。此時，運行圖4.5的Filter Graph就能播放遠(yuǎn)程端的音視頻數(shù)據(jù)了。

四、結(jié)論

近幾年，隨著遠(yuǎn)程監(jiān)控系統(tǒng)的廣泛應(yīng)用，本文設(shè)計了一個基于Web服務(wù)器的遠(yuǎn)程監(jiān)控系統(tǒng)，首先介紹了聯(lián)系網(wǎng)頁操作和程序應(yīng)用的CGI技術(shù)原理，并且用圖表解釋了Boa移植等概念。最后，配置和建立控制網(wǎng)頁的完成了基于Web服務(wù)器的遠(yuǎn)程監(jiān)控系統(tǒng)的設(shè)計。