摘 要：針對(duì)傳統(tǒng)的基于PC機(jī)的視頻監(jiān)控系統(tǒng)的局限性，提出了基于DM642的新型嵌入式遠(yuǎn)程視頻監(jiān)控系統(tǒng)的設(shè)計(jì)方案與實(shí)現(xiàn)方法，介紹了整個(gè)系統(tǒng)的總體結(jié)構(gòu)，并詳細(xì)闡述了現(xiàn)場(chǎng)端嵌入式系統(tǒng)的硬件設(shè)計(jì)和監(jiān)控中心軟件的實(shí)現(xiàn)。與傳統(tǒng)的視頻監(jiān)控系統(tǒng)相比較 , 該方案具有成本低、體積小、穩(wěn)定性好、可靠度高等優(yōu)點(diǎn)。 關(guān)鍵字：視頻監(jiān)控 TMS320DM642 DirectShow以太網(wǎng) [b][align=center]Design of The Video Monitor-Control System Based on DM642 Lu Gen_feng,Luan Chun_xu,Wang Miao,Xiong Lie_bin[/align][/b] Abstract: Due to the limitation of the traditional video system based on PC, we gave the design and implementation of the new video monitor-control embedded system based on DM642 hardware platform,introduced the general framework of the system,explained detail design of local embedded hardware system and monitor center software based on MS DirectShow. The scheme features low cost, small volume and high stabilization by comparing with the traditional video system. Keywords: Video monitor DirectShow TMS320DM642 Ethernet 一 引言 　　隨著計(jì)算機(jī)網(wǎng)絡(luò)、通訊技術(shù)、嵌入式處理器的發(fā)展，基于嵌入式的遠(yuǎn)程視頻監(jiān)控系統(tǒng)應(yīng)運(yùn)而生。目前市場(chǎng)主流仍然是基于PC的視頻監(jiān)控系統(tǒng)終端，它雖然便于現(xiàn)場(chǎng)操作，但穩(wěn)定性不好，視頻前端較復(fù)雜，可靠性不高，而基于嵌入式的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)終端就能彌補(bǔ)以上的弊端，嵌入式視頻編碼器具備視頻編碼處理、網(wǎng)絡(luò)通信強(qiáng)大功能，直接支持網(wǎng)絡(luò)視頻傳輸，視頻壓縮等功能集中到一個(gè)體積很小的設(shè)備內(nèi)，直接連入局域網(wǎng)或廣域網(wǎng)，系統(tǒng)的體積小、成本低、穩(wěn)定性高、實(shí)時(shí)性好[1]，非常適合于各種監(jiān)控場(chǎng)所，具備廣闊的發(fā)展前景和市場(chǎng)空間。 　　本文提出了基于以太網(wǎng)的嵌入視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。他主要包括前端嵌入式視頻終端和遠(yuǎn)程監(jiān)控中心。選用TI公司的DSP構(gòu)建一個(gè)嵌入式視頻采集壓縮與傳輸體系，該嵌入式視頻處理平臺(tái)具備著視頻采集、編碼處理、網(wǎng)絡(luò)通信強(qiáng)大功能，支持網(wǎng)絡(luò)視頻傳輸和網(wǎng)絡(luò)管理，還具有視頻保存回放功能。視頻監(jiān)控遠(yuǎn)程終端軟件的開發(fā)采用微軟的DirectShow技術(shù)來完成，在遠(yuǎn)程監(jiān)視系統(tǒng)中，視頻的數(shù)據(jù)量非常龐大，以視頻圖像大小 352×288大小為例，如果每秒傳輸30幀真彩色視頻圖像 就需要約的55Mbps帶寬，而這在網(wǎng)絡(luò)上幾乎不可能實(shí)現(xiàn)，所以本設(shè)計(jì)還在系統(tǒng)上實(shí)現(xiàn)了視頻數(shù)據(jù)的H264的壓縮與解壓，這大大緩解了網(wǎng)絡(luò)傳輸壓力。 二 系統(tǒng)總體設(shè)計(jì)方案 　　2.1系統(tǒng)整體框架 　　本系統(tǒng)主要由前端嵌入式監(jiān)控模塊和遠(yuǎn)程PC機(jī)監(jiān)控中心組成。前端系統(tǒng)主要將現(xiàn)場(chǎng)采集的視頻數(shù)據(jù)經(jīng)過相關(guān)壓縮處理變成數(shù)字信號(hào)，然后通過以太網(wǎng)傳輸至遠(yuǎn)程視頻監(jiān)控系統(tǒng)終端，遠(yuǎn)程中心解碼播放接收到的視頻流，遠(yuǎn)程監(jiān)控端還可以通過界面控制云臺(tái)的轉(zhuǎn)動(dòng)、調(diào)整攝像頭的參數(shù)，以改變監(jiān)控區(qū)域。其系統(tǒng)框圖如圖1 [align=center] 圖1 視頻監(jiān)控系統(tǒng)整體框圖[/align] 　　2.2前端網(wǎng)絡(luò)監(jiān)控模塊硬件設(shè)計(jì) 　　前端嵌入式網(wǎng)絡(luò)監(jiān)控模塊主要采用TI推出的專門針對(duì)于視頻應(yīng)用的TMS320DM642芯片。DM642內(nèi)含6個(gè)算術(shù)邏輯單元,在每個(gè)時(shí)鐘周期內(nèi)都可執(zhí)行2個(gè)16位或4個(gè)8位的加減、比較、移動(dòng)等運(yùn)算。在600MHz的時(shí)鐘頻率下, DM642 每秒可以進(jìn)行24 億次16 位的乘累加或48 億次8 位的乘累加[4]。使得DM642在多視頻處理和圖像處理方面有著強(qiáng)大的優(yōu)勢(shì)。DM642還在C64x 的基礎(chǔ)上增加了很多外圍設(shè)備和接口。 　　系統(tǒng)的硬件框圖如圖2 ，該最小系統(tǒng)是由DM642、SDRAM（4M64b）和FLASH（4M＊8b）等組成。前端接入三路CCD攝像頭，視頻解碼芯片采用TI公司的TVP5150，DM642的視頻端（VP）通過視頻解碼芯片TVP5150能方便地實(shí)現(xiàn)和CCD攝像機(jī)的無縫連接，CCD攝像機(jī)輸出的模擬視頻信號(hào)經(jīng)TVP5150模數(shù)轉(zhuǎn)換后，形成BT.656格式的數(shù)字視頻信號(hào)，從DM642的VP口輸入;DM642通過EDMA方式從VP口將采集到的YUV格式的數(shù)字信號(hào)搬運(yùn)至系統(tǒng)存儲(chǔ)單元中，再對(duì)視頻數(shù)據(jù)用H264壓縮算法進(jìn)行壓縮處理編碼壓縮，生成的視頻碼流數(shù)據(jù)經(jīng)EMAC的MII接口到片外PHY（LXT971）芯片后，通過以太網(wǎng)傳到遠(yuǎn)程監(jiān)控中心主機(jī)，通過PC機(jī)的監(jiān)控軟件接收播放視頻數(shù)據(jù)，完成網(wǎng)絡(luò)視頻監(jiān)控的功能。 [align=center] 圖2 系統(tǒng)硬件框圖[/align] 　　2.3前端網(wǎng)絡(luò)監(jiān)控模塊軟件設(shè)計(jì) 　　DSP軟件程序采用RF-5框架來整合H264的編碼庫H264lib。在進(jìn)入DSP/BIOS的調(diào)度程序之前，程序需要初始化多個(gè)要使用的模塊。包括：（1）DM642和系統(tǒng)板的初始化;（2）RF-5模塊初始化;（3）建立捕獲通道。在完成初始化工作之后，系統(tǒng)進(jìn)入DSP/BIOS調(diào)度程序管理下的4個(gè)線程和1個(gè)通道。其中taskVideoCap， taskH264Encode和taskNetwork的優(yōu)先級(jí)為高, taskControl的優(yōu)先級(jí)最底。taskVideoCap， taskH264Encode，taskNetwork和taskControl線程是系統(tǒng)的核心線程，不斷地完成從底層視頻驅(qū)動(dòng)獲取視頻信號(hào)，將視頻信號(hào)進(jìn)行H264編碼，再通過網(wǎng)絡(luò)傳給遠(yuǎn)程用戶進(jìn)行顯示。taskVideoCap，taskH264Encode和taskNetwork線程之間通過同步通信模塊（SCOM）進(jìn)行同步和通信，taskControl線程和taskH264Encode線程之間通過郵箱（MBX）進(jìn)行通信。系統(tǒng)軟件總體流程圖如圖3 [align=center] 圖3 嵌入式系統(tǒng)軟件總體流程圖[/align] 三 遠(yuǎn)程監(jiān)控中心軟件實(shí)現(xiàn) 　　3.1DirectShow技術(shù) 　　整個(gè)系統(tǒng)以Microsoft公司的DirectShow技術(shù)為基礎(chǔ)， DirectShow屬于DirectX家族的一員，他為在Windows平臺(tái)處理各種格式的媒體文件的回放，音視頻采集等高性能要求的多媒體應(yīng)用，提供了完整的解決方案[2]。在DirectShow系統(tǒng)之上，應(yīng)用程序要按照一定的意圖建立起相應(yīng)的Filter Graph，然后通過Filter Graph Manager來控制整個(gè)的數(shù)據(jù)處理過程，DirectShow的體系結(jié)構(gòu)如圖所示。DirectShow能在Filter Graph運(yùn)行的時(shí)候接收到各種事件，并通過消息的方式發(fā)送到應(yīng)用程序。這樣，就實(shí)現(xiàn)了應(yīng)用程序與DirectShow之間的交互。 [align=center] 圖4 DirectShow的體系結(jié)構(gòu)如圖[/align] 　　Directshow是基于模塊化，每個(gè)特定的功能模塊都采取COM組件方式，稱為Filter。Directshow提供了一系列的標(biāo)準(zhǔn)的模塊可用于應(yīng)用開發(fā)，開發(fā)者也可以開發(fā)自己的功能filter來擴(kuò)展Directshow的應(yīng)用。每個(gè)filter都在FilterGraph的模型的管理下參與數(shù)據(jù)的處理，各個(gè)filter在FilterGraph中按特定的順序鏈接來完成用戶制定的功能。filter 一般分為下面幾種類型（1）源過濾器（sourcefilter）：源過濾器引入數(shù)據(jù)到過濾器圖表中，數(shù)據(jù)來源可以是文件、網(wǎng)絡(luò)、照相機(jī)等。（2）變換過濾器（transform filter）：變換過濾器的工作是獲取輸入流，處理數(shù)據(jù)，并生成輸出流。變換過濾器對(duì)數(shù)據(jù)的處理包括編解碼、格式轉(zhuǎn)換、壓縮解壓縮等。（3）提交過濾器（renderer filter）：提交過濾器在過濾器圖表里處于最后一級(jí)，它們接收數(shù)據(jù)并把數(shù)據(jù)提交給外設(shè)[2]。 　　3.2采用Directshow實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)視頻流的實(shí)時(shí)播放 　　本系統(tǒng)軟件分別對(duì)各個(gè)功能Filter進(jìn)行了開發(fā)，并將他們連接成一個(gè)完整的鏈路，如圖5 [align=center] 圖5 網(wǎng)絡(luò)播放FilterGraph[/align] 　　其中NetRecv Filter為網(wǎng)絡(luò)接收源過濾器Filter（sourcefilter），它由CBaseFilter繼承而來，CBaseFilter已經(jīng)具備了Filter的基本特征和框架，采用推模式將網(wǎng)絡(luò)接收來的數(shù)據(jù)推向下一級(jí)filter，程序?qū)ocket相關(guān)操作都放在應(yīng)用層，如socket創(chuàng)建、偵聽、連接等，到時(shí)候只要將連接好的socket句柄通過filter接口設(shè)置給NetRecv Filter，在接受filter內(nèi)部實(shí)現(xiàn)時(shí)，只需使用外部設(shè)置進(jìn)來的socket進(jìn)行數(shù)據(jù)的接受工作。 　　由于從遠(yuǎn)程嵌入式終端傳輸過來的視頻數(shù)據(jù)為H264壓縮碼流，所以要對(duì)其實(shí)現(xiàn)實(shí)時(shí)播放還需要一個(gè)transform filter 即H264解碼filter （H264 Decode Filter），它由CTransformFilter繼承而來，它主要是由T264代碼為核心的解碼filter，T264是中國(guó)的視頻編碼自由組織合力開發(fā)的264編解碼程序，他將完成從NetRecv Filter上接受H264碼流，再對(duì)其進(jìn)行解碼變成YUV視頻格式，通過輸出PIN送至render filter進(jìn)行播放。 　　整個(gè)實(shí)現(xiàn)過程如下 　�。�1）首先構(gòu)建視頻播放FilterGraph對(duì)象m_VideoGraph; 　　（2）創(chuàng)建NetRecv Filter、H264 Decode Filter和Renderer Filter，并將這三個(gè)filter加入到m_VideoGraph中; 　　（3）將負(fù)責(zé)視頻數(shù)據(jù)接收的socket設(shè)置給NetRecv Filter進(jìn)行網(wǎng)絡(luò)視頻流數(shù)據(jù)的接收工作; 　�。�4）根據(jù)第一次接受的數(shù)據(jù)格式重新設(shè)定視頻的各個(gè)參數(shù)，例如： 　　mPreferredMt.SetSubtype（&MEDIASUBTYPE_YUY2）;//設(shè)定媒體類型為YUV4：2：0格式; 　　info.AvgTimePerFrame = 400000; //幀速率為25幀/S; 　　info.bmiHeader.biWidth =n_Width;//設(shè)定圖像的寬度; 　　info.bmiHeader.biHeight = n_Height;//設(shè)定圖像的高度; 　　info.bmiHeader.biSizeImage=n_Width＊ _Height ＊2; //圖像的大小; 　　info.bmiHeader.biCompression= mmioFOURCC（‘Y‘,‘U‘,‘Y‘,‘2‘）; 　�。�5）設(shè)定完視頻格式后，通知應(yīng)用完成全部filter的連接工作，然后調(diào)用mVideoGraph->Run（）運(yùn)行。 　　（4）當(dāng)網(wǎng)絡(luò)接受到超過一定的數(shù)據(jù)量時(shí)，通知事件窗體要進(jìn)行視頻的播放。 　　3.3 網(wǎng)絡(luò)視頻傳輸策略 　　網(wǎng)絡(luò)部分采用WinSock進(jìn)行編程，socket 提供兩種不同的傳輸方式，TCP是面向連接的協(xié)議, 通過握手協(xié)議, 能夠提供可靠的數(shù)據(jù)傳輸, 但是速度慢, 系統(tǒng)負(fù)載大。UDP不提供連接, 依靠網(wǎng)絡(luò)自身來保證傳輸?shù)目煽? 不能保證圖像不丟失, 但是簡(jiǎn)單快速[3]。視頻圖像傳輸有自身的特點(diǎn)：關(guān)鍵的壓縮圖像信息（H264的壓縮信息）等一旦丟失將造成系統(tǒng)的癱瘓，其他的控制信息的部分丟失不會(huì)對(duì)系統(tǒng)產(chǎn)生太大的影響。本系統(tǒng)針對(duì)視頻圖像傳輸?shù)奶攸c(diǎn)采用如下的傳輸機(jī)制：視頻圖像傳輸方面采用TCP的連接方式，保證核心的信息實(shí)現(xiàn)無差錯(cuò)連接，而控制中心和遠(yuǎn)程終端的交互信息則采用UDP 的方式。 　　系統(tǒng)采用流式的數(shù)據(jù)接受方案，TCP和UDP傳輸包都有自己的結(jié)構(gòu)，傳輸視頻數(shù)據(jù)的TCP數(shù)據(jù)包格式如下 　　當(dāng)監(jiān)控中心接受到一個(gè)TCP包時(shí)首先判斷它的數(shù)據(jù)類型，數(shù)據(jù)類型我們這里把它定義了兩種，一種是格式數(shù)據(jù)，還有就是視頻數(shù)據(jù)。格式數(shù)據(jù)主要包含了前端系統(tǒng)的配置情況如像素設(shè)置，圖像大小，壓縮類型等，中心根據(jù)這個(gè)數(shù)據(jù)來配置自身的程序運(yùn)行狀態(tài)和運(yùn)行參數(shù)的設(shè)置。負(fù)載數(shù)據(jù)就是數(shù)據(jù)包的實(shí)體部分，包含著具體的格式數(shù)據(jù)或者具體的媒體數(shù)據(jù)，這些數(shù)據(jù)將會(huì)被做相應(yīng)的處理。最后采用CRC-16進(jìn)行校驗(yàn)。 　　UDP數(shù)據(jù)包的格式如下 　　UDP主要用來傳輸控制命令，程序首先接收命令類型例如：遠(yuǎn)程終端要求連接、遠(yuǎn)程端的系統(tǒng)配置信息、云臺(tái)控制信息等，數(shù)據(jù)參數(shù)主要是以上這些控制命令的具體控制要求如：控制云臺(tái)旋轉(zhuǎn)的具體的角度等，這樣就能夠做到現(xiàn)場(chǎng)端和遠(yuǎn)程端的信息命令的實(shí)時(shí)交互。 測(cè)試結(jié)果 　　在局域網(wǎng)環(huán)境內(nèi)，采用一路點(diǎn)對(duì)點(diǎn)的傳播方式對(duì)監(jiān)控系統(tǒng)進(jìn)行測(cè)試，設(shè)定圖像的的大小為352＊288，測(cè)試結(jié)果表明，該系統(tǒng)對(duì)平過度視頻圖像的壓縮率為100倍左右，網(wǎng)絡(luò)延時(shí)約為3s，占用的網(wǎng)絡(luò)傳輸帶寬小于2M，根據(jù)實(shí)際效果來看，該系統(tǒng)具有較為流暢的傳輸性能，實(shí)時(shí)傳輸時(shí)系統(tǒng)延遲小，能夠較好完成視頻監(jiān)控的目的，能夠滿足目前大多數(shù)視頻監(jiān)控的需要。 結(jié)論 　　本文主要給出了基于DM642的嵌入式視頻監(jiān)控前端和基于DirectShow的遠(yuǎn)程監(jiān)控中心軟件的完整實(shí)現(xiàn)方案。經(jīng)測(cè)試表明，該系統(tǒng)具有性能穩(wěn)定，占用帶寬小，易擴(kuò)展和升級(jí)，可用于環(huán)境較惡劣的監(jiān)控場(chǎng)所，有著廣闊的應(yīng)用前景。 參考文獻(xiàn) 　　【1】陳文詳，孟利民.新型嵌入式視頻監(jiān)控系統(tǒng)的設(shè)計(jì)[J].電子元器件應(yīng)用，2008第10卷2期. 　　【2】陸其明編著. DirectShow開發(fā)指南[M.]北京：清華大學(xué)出版社，2003. 　　【3】宋坤,劉銳寧，馬文強(qiáng)編著.Visual C++視頻技術(shù)方案寶典[M].北京：人民郵電出版社，2008. 　　【4】郝宏偉，王淑敏，李淵.基于DM642的嵌入式視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與優(yōu)化[J].微計(jì)算機(jī)應(yīng)用，2008第39卷3期.