摘要:文章主要對數字視頻監控系統中的軟件設計方案進行了分析,并提出了解決方案。
關鍵詞:數字視頻監控;軟件設計;C/S模型
我國視頻監控行業最初是由閉路電視監控逐漸發展起來的,已近二十年的歷史,但總的來講,由于起步晚,技術較落后,使該行業中的我國企業既有廣闊的發展空間,又面臨著來自國外大企業的強大挑戰。就目前先進的數字視頻監控系統而言,在視頻壓縮、分析、傳輸、存儲和分級控制等方面仍有待提高和完善。本文主要對數字視頻監控系統中的軟件設計方案進行了分析,并提出了解決方案。
一、系統軟件結構特點
(一)系統模塊化,具有較好的擴展性、可重用性和可維護性
系統按照功能劃分模塊,模塊之間具有相對的獨立性。可以通過增加或替換模塊,對系統進行擴展;另外,利用關鍵模塊可以開發新的視頻應用系統,避免了重復開發的麻煩,使系統具有良好的可重用性。
(二)集中管理,具有較高的可靠性、統一性和安全性
設置管理服務器對所有成員進行集中式管理:組成員加入或退出監控組的行為必需通過組管理服務器進行認證或登記。采取集中式管理有利于提高系統的統一性、可靠性和安全性。
(三)提供靈活監控方式
授權用戶可隨時隨地加入監控系統進行實時監控,增加了用戶進行監控的靈活性。
二、系統軟件的C/S模型
隨著計算機和網絡技術的發展,很多數據處理系統都采用開放系統結構的客戶機-服務器(Client/Server)模型,即客戶機向服務器提出請求,服務器對請求做相應的處理并執行被請求的任務,然后將結果返回給客戶機。
基于以上的分析,監控軟件的設計采用了客戶機一服務器模型。如圖1所示,在服務器端對請求做出回應并執行相應的任務,如給客戶端發送組播地址、視音頻圖像、控制指令等。客戶機向服務器發送請求,并接收視音頻圖像,譯碼播放及一定權限下的控制指令。服務器則根據要求向當前設備狀態發出控制指令,從而實現遠程監控。

三、系統軟件模塊
本系統主要由視音頻數據處理模塊、視音頻錄像播放模塊、云鏡控制模塊、系統參數設置模塊、視音頻數據發送模塊、視音頻數據接收模塊六個部分組成。如圖2所示。其中,前五個模塊運行于監控服務器端,視音頻數據接收模塊運行于遠程客戶端,另外,遠程客戶端也有負責視音頻播放的模塊,但同服務器端的視音頻數據處理模塊實現方式差不多,所以不再贅述。各模塊的主要功能見圖2:

視音頻數據處理模塊該模塊主要通過視音頻壓縮卡廠商提供的SDK開發包,完成對視音頻信號進行實時采集、動態存儲、實時播放等處理工作;視音頻錄像播放模塊該模塊主要對存儲在硬盤上的視音頻檔進行按條件查詢播放;云鏡控制模塊該模塊負責根據譯碼器協議及命令碼,通過串口通信控制云臺的轉動、鏡頭的焦距和光圈的調整等;系統參數設置模塊該模塊主要對系統的一些參數進行設置,如增加用戶、刪除用戶、存儲設置、視頻采集參數設置等;視音頻數據發送模塊該模塊負責將視音頻數據流實時的以組播的方式發送給遠程監控端;視音頻數據接收模塊該模塊運行于遠程客戶端,負責接收監控服務器發送來的視音頻數據流。
四、系統軟件主要功能模塊實現
(一)視頻采集模塊
視頻采集模塊將視頻采集卡采集到的視頻圖像置入內存,系統讀取內存中的視頻圖像后才能作后續處理.圖像采集時以幀方式采集,在內存中以場方式存儲。
由于采集卡在不斷地向采集緩沖區寫入數據,讀取視頻數據時需要涉及到臨界區訪問的問題.系統首先要查詢哪塊采集緩沖區已就緒,然后鎖定要采集的采集緩沖區,接著讀取視頻資料,最后對視頻數據進行顯示,或者交給壓縮模塊處理。
在視頻服務器中,一個服務器需要同時連接多個攝像頭,因此視頻信號的采集、處理應該同步執行。本系統使用了多線程技術,分別為每一路視頻信號的處理啟動單獨的線程。此外,考慮到監控系統實時性要求較高,本系統以多媒體定時器方式啟動線程,多媒體定時器可以精確到毫秒級。以下是啟動函數及其參數介紹:
MMRESULT timeSetEvent(UINT uDeiay,UINT uResolution,LPTIMECALL-BACK IpTimeProc,DWORD-PTR dwUser,DINT fuEvent)
uDelay:以毫秒指定事件的周期.
uResolution:以毫秒指定延遲的精度,數值越小,定時器越精確,在Windows中缺省值為lms.
IpTimeProc:回調函數,為用戶自定義函數(本例中應為視頻圖像處理函數)。
dwUser:用戶參數.
fuEvent:指定定時器事件類型. TIME_ ONESHOT:執行一次.TIME _ PERIODIC:周期性執行(顯然本例中應取后者)
(二)視頻處理模塊
對視頻信號壓縮,我們采用MPEG-4標準,視頻信號的回放,運用DirectDraw技術直接寫屏,以滿足25f/s的視頻回放要求。
以下是視頻信號壓縮一幀圖像的函數,nID為采集設備編號,pBuf In為采集到的圖像數據,PBufOut為壓縮后的圖像數據,pOutSize為壓縮后的圖像大小,pKeyFrame表明當前圖像是否為關鍵幀。
BOOL C_CompressFrame ( int nID, char * pBufIn,char * * pBufOut, unsigned int * pOutSize,
BOOL * pKeyFrame)
{
SCompressInfo * pCmprssInfo=&g_-CmprssInfo[nID];
* pBufOut=(char*)ICSeqCompress-Frame( &pCmprssInfo?>cv , 0 , pBufIn,
pKeyFrame, ( long*)pOutSize );
return TRUE
}
(三)網絡傳輸模塊
在網絡通信中能否恰當地使用協議對整個系統而言非常關鍵。本系統采用TCP/IP來完成網絡通信和數據傳輸。TCP具有保證數據包發送到所需目標系統并按恰當順序發送與重新裝配數據的能力如果數據包有問題,TCP就要確保重新發送出現傳輸問題的數據。因此,TCP為了確保數據的正確接收,要產生額外的網絡信息量并降低整個網絡的性能。用戶數據包協議(UDP)與TCP類似,但UDP能夠不用校驗或不要求應答數據包的發送,因此UDP主要應用在對網絡延遲敏感但可承受數據損失,以及一對多等場合考慮到視頻信號的傳送和控制信號的傳送對數據可靠性的要求不同。數據量不同,我們用UDP實現視頻數據傳送,用TCP實現控制信號傳送。當然,使用UDP協議在網絡流量大的情況下會對圖像質量產生一定的影響。
下面為本模塊使用的用于網絡監聽的CListeningSockct對象。
class CListeningSocket:public Csocket
}
//對象屬性
public:
//對象方法
public:
CListeningSocket(CMainFrame } pMainFrame
virtual一CListeningSocket();
//重載
public:
CMainFrame * m_pMainFrame; //虛函數重載
//{{AFX_VIRTUAL(CListeningSocket)
public:
virtual void OnAccept(int nErrorCode);
//}}AFX_VIRTUAL
//產生消息映像
//{{AFX_MSG(CListeningSocket)
//可以在此增減成員函數
//}}AFX_MSG
//具體實現
protected:
};
該對象每當監聽到一個連接請求時,即建立一個新的CSocket與其通信,并將其連到鏈表上,原對象本身繼續保持監聽。具體實現過程如下:
void CListeningSocket::OnAccept(int nErrorCode)
{
// TODO:Add your specialized code here and/or call the base class
CSockct:OnAcccpt( nErrorCode );
CCIientSocket*pSocket=new CClientSocket(m_pMainFrame);
if ( pSocket==NULL)
return;
if(m_pMainFrame->m_ListeningSocket->Accept(* pSocket))
{m_pMainFrame->m_ConnectionList. Add
Tail( pSocket );
}
else
delete pSocket;
文章提出了本數字視頻監控系統中軟件設計的C/S模型,根據模型具體劃分系統模塊,分析介紹系統主要模塊的設計思想并對軟件開發過程中的問題提出了解決方法。
參考文獻:
1、韋錦山.網絡視頻監控系統的新發展.通訊世界[J].2002(5):65-68.
2、劉富強.數字視頻監控系統開發及應用[M].機械工業出版社,2003.
3、余兆明,李曉飛等.“MPEG標準及其應用”[M].北京郵電大學出版社,2002.
(作者單位:武漢理工大學)