攝像機傳送來的視頻信號數(shù)字化后，經(jīng)過壓縮，通過RS-232/RS485將數(shù)據(jù)送到內(nèi)置的Web服務器，嵌入式Linux系統(tǒng)的10/100M以太網(wǎng)口實現(xiàn)接入Internet網(wǎng)絡，將現(xiàn)場信號送到客戶端" title="客戶端">客戶端。整個系統(tǒng)的核心是嵌入式Linux系統(tǒng)。監(jiān)控系統(tǒng)啟動后，嵌入式Linux系統(tǒng)啟動Web Server服務程序，接收授權(quán)客戶端瀏覽器的請求，Web Server將根據(jù)通信協(xié)議完成相應的監(jiān)測。
2 系統(tǒng)實現(xiàn)
2.1 硬件平臺設計
　　本系統(tǒng)以公開的嵌入式Linux源代碼為基礎(chǔ)，根據(jù)設計的嵌入式目標板編寫相應的Bootloader程序，然后裁剪出合適的內(nèi)核和文件系統(tǒng)。目標平臺CPU采用Motorola公司生產(chǎn)的ColdFire嵌入式處理器MFC5272。 MFC5272采用ColdFire V2可變長RISC處理器核心和DigitalDNA技術(shù)，在66MHz時鐘下能夠達到63Dhrystone2.1MIPS的優(yōu)良處理能力。內(nèi)部SIM(System Integrated Module)單元集成了豐富的通用模塊，只需很少的外圍芯片就可以實現(xiàn)兩個RS-232串行口和一個USB Slave接口。MFC5272還內(nèi)嵌一個FEC(快速以太網(wǎng)控制器)，片外擴展一片LXT971，方便地實現(xiàn)了一個100/10 Base T的以太網(wǎng)接口。能夠與常用的外圍設備(如SDRAM、ISDN收發(fā)器)實現(xiàn)無縫連接，從而簡化了外圍電路的設計，降低了產(chǎn)品成本、體積和功耗。
2.2 軟件設計與實現(xiàn)
　　視頻監(jiān)控系統(tǒng)軟件結(jié)構(gòu)采用的是瀏覽器/服務器(B/S)網(wǎng)絡模型，即由客戶端通過Web向服務器提出請求，服務器對請求做出確認響應并執(zhí)行相應的任務(如向客戶端發(fā)送組播地址、圖像格式、壓縮格式等)，建立連接后就可以在客戶端監(jiān)控被控點，從而實現(xiàn)遠程網(wǎng)絡監(jiān)控。服務器(Web Server)端即現(xiàn)場監(jiān)控點的軟件結(jié)構(gòu)包括采集模塊、壓縮編碼模塊、網(wǎng)絡通信模塊、控制模塊等，如圖2所示。

2.2.1 視頻采集模塊設計
　　由于攝像機得到的是模擬的視頻信號，不能直接為計算機使用，因此要使視頻在網(wǎng)上傳輸，必須首先對其數(shù)字化。本系統(tǒng)選用的視頻采集卡為Conexant公司的Bt848卡，該卡不需要任何本地緩存來存儲視頻像素數(shù)據(jù)，還能夠充分利用基于PCI總線系統(tǒng)的高帶寬和固有的多媒體功能，并且能夠與其他多媒體設備實現(xiàn)互操作。在整個系統(tǒng)中由于視頻采集的速度通常高于應用軟件取得數(shù)據(jù)并進行處理的速度，因此為了保證視頻數(shù)據(jù)的連續(xù)性，采用了三緩存結(jié)構(gòu)，緩存A是Bt848視頻采集的目標地址，在RISC指令的直接控制下，采集的數(shù)據(jù)都先存放在這個緩存中；B和C組成乒乓式結(jié)構(gòu)循環(huán)往復使用，當某一幀數(shù)據(jù)采集完畢后，產(chǎn)生中斷，在中斷服務程序中將緩存A的數(shù)據(jù)復制到緩存B(或C)中，然后采集下一幀，當下一幀數(shù)據(jù)采集完后，再將緩存A中的數(shù)據(jù)復制到緩存C(或B)中，當應用程序需要數(shù)據(jù)時就從緩存B或C中讀取最新的一幀圖像。緩存B和C交替使用，能夠保證應用程序從緩存讀數(shù)據(jù)的操作和驅(qū)動程序向緩存寫數(shù)據(jù)的操作不會發(fā)生沖突，避免了數(shù)據(jù)的損壞和遲延。
2.2.2 視頻壓縮編碼的設計
　　本設計選用了基于對象的MPEG-4視頻編碼技術(shù)，首先對輸入的任意形狀的VOP序列，用基于塊的混合編碼技術(shù)編碼。處理順序是先幀內(nèi)VOP，后幀間VOP和雙向預測VOP。在對VOP的形狀信息編碼之后，取得任意形狀VOP的采樣，每個VOP用宏塊" title="宏塊">宏塊柵格劃分成不相交的宏塊，每個宏塊含有四個8×8的像素塊，以進行運動估計和補償及紋理編碼。已編碼的VOP幀保存在VOP幀存儲器中。運動向量在當前VOP幀和已編碼VOP幀之間計算。對將被編碼的塊或宏塊，計算其運動補償預測誤差。運動補償預測后的I-VOP及誤差用8×8塊DCT編碼，并進行DCT系數(shù)的量化，然后是行程編碼和熵編碼。最后，形狀、運動和紋理信息復合成VOL位流輸出。這種編碼方法可以允許用戶修改、增加或重定位一個視頻場景中的對象，甚至可以轉(zhuǎn)換場景中對象的行為。對于不同的帶寬和計算復雜性需求，不必針對每種情況分別編碼，可以使用同一個視頻位流，而采用不同的參數(shù)以選擇不同的層以獲得靈活性。在出現(xiàn)網(wǎng)絡擁塞、丟包等現(xiàn)象時仍能提供連貫性較好的視頻圖像。視頻壓縮編碼進程將編碼后的的視頻存放到已編碼視頻緩沖隊列中，同時激活或等待直播進程和存儲管理進程的相應處理。
2.2.3 網(wǎng)絡通信模塊設計
　　網(wǎng)絡通信模塊是系統(tǒng)的主體部分，它包含三個數(shù)據(jù)通道：監(jiān)聽通道、控制通道和視頻數(shù)據(jù)通道。監(jiān)聽通道用來傳輸控制前端設備的命令數(shù)據(jù)；視頻數(shù)據(jù)通道用來傳輸各個組的視頻數(shù)據(jù)。三個通道采用不同的通信端口，所以各個通道傳輸數(shù)據(jù)彼此獨立。網(wǎng)絡通信模塊設計開發(fā)是通過網(wǎng)絡編程接口(Windows Socket，簡稱Winsock)來實現(xiàn)的。按照系統(tǒng)瀏覽器/服務器的網(wǎng)絡傳輸模型，在服務器端建立了以SOCKET為類型的監(jiān)聽套接字" title="套接字">套接字、控制套接字；在客戶端建立了SOCKET類型的請求套接字、控制套接字，這些都是采用TCP協(xié)議封裝傳輸數(shù)據(jù)的。
　　另外，在服務器和客戶機兩端都用到了一個組播類(CMulticast)，它是專門為視頻傳輸而封裝的類，由CObject派生而來，其中定義了以SOCKET類型的收發(fā)視頻數(shù)據(jù)的套接字和組套接字，從而實現(xiàn)了用組播通信方式來傳輸UDP協(xié)議封裝的視頻數(shù)據(jù)包。系統(tǒng)中IP網(wǎng)絡數(shù)據(jù)通信流程如圖3所示。