基于流媒體通信技術的視頻監控設計

王軍

【摘要】視頻監控系統的應用軟件能力上應支持多任務并發處理，如監視、錄像、回訪、備份、報警、控制、遠程連接等的多任務處理能力；本課題主要是開發這樣一個軟件環境，使客戶端完成現場圖像接收，用戶登錄管理，優先權的分配，控制信號的協調，圖像的實時監控，錄像的存儲、檢索、回放、備份、恢復等。本文主要探討了基于流媒體通信技術的視頻監控設計。

【關鍵詞】視頻監控；流媒體；通信技術

一、研究的內容

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

視頻監控系統的應用軟件能力上應支持多任務并發處理，如監視、錄像、回訪、備份、報警、控制、遠程連接等的多任務處理能力；本課題主要是開發這樣一個軟件環境，使客戶端完成現場圖像接收，用戶登錄管理，優先權的分配，控制信號的協調，圖像的實時監控，錄像的存儲、檢索、回放、備份、恢復等。本文具體工作如下：

1、實現服務器端與客戶端的數據通訊功能；

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

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

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

5、設置用戶權限功能。

二、視頻監控系統設計方案

1、數字視頻監控系統框架設計

按照C/S模式設計，視頻監控系統分為服務端和客戶端，服務端采集數據，經過處理后通過IP網絡傳輸至客戶端，客戶端接收處理后進行播放。具體結構如圖3.2所示。

服務端分為視頻采集預覽、壓縮編碼和網絡發送模塊三部分，相應地，客戶端分為網絡接收模塊、視頻解碼和視頻播放三部分。各部分的具體功能如下：

（1）視頻采集預覽：該模塊對監控現場進行實時圖像采集，并在服務端的PC機上實時預覽。

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

（3）網絡發送：該模塊實現三個功能，首先采取RTP協議將上一級生成的比特流包裝為RTP包，其次通過IP網絡發送，同時通過RTCP協議實現網絡QoS監控。

（4）網絡接收：該模塊負責接收服務端發送的RTP包，解析包數據，并且與服務端的發送模塊配合完成RTCP監控。

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

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

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

在IP網絡上的進行視頻數據傳送需要遵循一定的傳輸協議，由于視頻實時傳輸本身的特點和要求，傳統的網絡協議如TCP、UDP等無法勝任此項工作，于是國際標準化組織IETF制定了面向實時流媒體的RTP協議，提供了上述打包分組功能，并且滿足視頻流實時傳輸的要求。因此一般的視頻傳輸應用系統中，一般是基于RTP協議實現視頻流的傳輸和控制，本文也采用該協議。

2、數字視頻監控系統的功能模型建立

現場監控主機完成對監控硬件設備的操作，實現對視頻數據回放和存儲等功能。此外還可向遠端的中心監控主機及其他的遠程終端發送視頻信息并驗證該用戶的權限。圖3.3為現場監控主機功能模型。

本文中使用視頻服務器來代替現場監控主機，與現場監控主機一樣，該視頻服務器實現對音、視頻數據壓縮并把數據保存在內置的硬盤上，并可通過網絡把數據傳輸到中心監控主機和視頻監控主服務器上進行解碼和顯示。

基于視頻服務器的數字視頻監控系統由以下幾部分組成：

（1）視頻服務器

視頻服務器集視/音頻壓縮、報警開關輸入/輸出、網絡傳輸于一體，完成監控系統中的數據采集、壓縮和傳輸等工作。視頻服務器的功能模型如圖3.4所示。

（2）中心監控主機

中心監控土機是本地或者遠端的分監控中心，是局域網中的監控主機，主要實現視頻數據實時解壓回放、視頻圖像處理、視頻數據存儲管理、實時報警處理和對攝像頭的控制等，如圖3.5所示：

（3）監控主服務器

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

3、視頻監控局域網

整個監控系統可以通過專用視頻傳輸網絡及企業內部己存的局域網進行連接。具體網絡結構會影響視頻傳輸采用的傳輸協議，它取決于企業現有網絡的狀況。

三、客戶端設計

1、數字視頻監控系統視頻播放器的實現

（1）DirectShow軟件開發相關技術

①COM編程基礎

DirectX采用了COM標準。而DirectShow是一套完全基于COM的應用系統。DirectShow應用程序實際上是一種COM組件的客戶程序，只是COM組件的“使用”問題。這些問題包括如何創建COM組件、如何得到組件對象上的接口以及調用接口方法、如何管理組件對象（即需要熟悉COM的引用計數制）等。

COM本身只是一種規范，而不是實現。但是當使用C++來實現時，COM組件就是一個C++類，而接口都是純虛類。

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

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

②COM組件的實現方式

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

2、DirectShow應用程序開發步驟

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

l、建一個Filter Graph Manager實例；

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

3、應用程序對Filter Graph進行控制，響應事件通知。

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

3、視頻監控系統客戶端播放器的實現

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

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

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

4、數字視頻監控系統客戶端的實現

數字視頻監控系統客戶端的實現原理：

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

因為音視頻數據是大量的、連續的、需要可靠傳輸的，因此這些數據的傳輸可以選用TCP協議。而通信雙方的控制命令數據量很小，而且重要性也不是很強，因此可以選用UDP協議。為了讓在Socket上傳輸的數據簡單或者說提高Socket傳輸的效率，該程序將音頻和視頻數據的傳輸分離，分別為它們創建一條Socket連接。而在單個Socket上，可以同時進行數據的發送和接收。

作為Filter開發的一條基本原則，Filter實現的功能應該力求單一。因此該程序將Socket相關的操作都放在應用程序層之上，而僅將完成連接的Socket句柄通過Filter的公共接口設置給Net Sender和Net Receiver。這兩個Filter在內部實現時，只須使用外部設置進來的Socket進行數據的發送和接收就可以了，而不用去管Socket的創建、連接等一系列繁瑣的交互過程。

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

四、結論

近幾年，隨著遠程監控系統的廣泛應用，本文設計了一個基于Web服務器的遠程監控系統，首先介紹了聯系網頁操作和程序應用的CGI技術原理，并且用圖表解釋了Boa移植等概念。最后，配置和建立控制網頁的完成了基于Web服務器的遠程監控系統的設計。