引言
目前，嵌入式視頻監(jiān)控系統(tǒng)已成為國(guó)內(nèi)外視頻監(jiān)控系統(tǒng)應(yīng)用的主流，但是在 IPv4平臺(tái)下存在地址不足、不能合理分配帶寬、安全性能及移動(dòng)性能差等諸多問(wèn)題，而新一代 IPv6協(xié)議不僅能很好的解決以上問(wèn)題，而且還具有可以提高視頻傳輸速度和傳輸質(zhì)量等多方而的優(yōu)點(diǎn)。如何使嵌入式視頻監(jiān)控系統(tǒng)與 IPv6技術(shù)相結(jié)合是當(dāng)前監(jiān)控系統(tǒng)研究的一個(gè)重要方向。
1 視頻監(jiān)控系統(tǒng)總體設(shè)計(jì)
2 1系統(tǒng)結(jié)構(gòu)

系統(tǒng)總體結(jié)構(gòu)如圖 1所示。攝像頭和視頻服務(wù)器組合在一起稱為視頻服務(wù)端或網(wǎng)絡(luò)攝像機(jī)，每個(gè)視頻服務(wù)端分配一個(gè)獨(dú)立 IPv6后通過(guò)雙絞線接入網(wǎng)絡(luò)，客戶端通過(guò) IP網(wǎng)絡(luò)直接訪問(wèn)和控制視頻服務(wù)端。攝像頭和麥克風(fēng)將采集的模擬音視頻信號(hào)送入內(nèi)部嵌入式 Linux操作系統(tǒng)的視頻服務(wù)器，并通過(guò)雙絞線接入網(wǎng)絡(luò)。模擬信號(hào)被送入編碼器編碼成 MPEG-4的視頻流和 ADPCM的音頻流，從編碼器出來(lái)的音視頻流再被分為兩路，一路送入本地的視頻監(jiān)視器，另一路通過(guò)網(wǎng)絡(luò)發(fā)送到客戶端?？蛻舳税逊?wù)器端傳來(lái)音視頻數(shù)據(jù)分為兩路，一路進(jìn)行客戶端存儲(chǔ)，另一路啟動(dòng) irectShow流水線，將視頻信號(hào)和音頻信號(hào)分離，分別送入各自的解碼器(視頻信號(hào)采用 MPEG-4解碼器解碼)。最后，解碼后的音視頻信號(hào)被送入對(duì)應(yīng)的設(shè)備進(jìn)行實(shí)時(shí)預(yù)覽。

500)this.style.width=500;" border="0" />

1.2系統(tǒng)設(shè)計(jì)思路
系統(tǒng)工作需要硬件和軟件協(xié)調(diào)土作共同實(shí)現(xiàn)。攝像頭采集視頻、麥克風(fēng)采集音頻，由服務(wù)器端采集卡完成音視頻的采集和壓縮，通過(guò)調(diào)用驅(qū)動(dòng)程序讀取采集和壓縮后的音視頻數(shù)據(jù)到緩存。緩存區(qū)中的音視頻數(shù)據(jù)發(fā)送傳輸都由服務(wù)器端軟件實(shí)現(xiàn)。
服務(wù)器端軟件讀出緩沖區(qū)的數(shù)據(jù)，啟動(dòng)發(fā)送模塊，發(fā)送時(shí)采用 RTP協(xié)議打包，模塊讀取緩沖區(qū)中的視頻流是以一幀為最小單位，由于按一幀打包時(shí)數(shù)據(jù)長(zhǎng)度比較大小適合在網(wǎng)絡(luò)中傳輸，所以需要在打包前將幀分割成幾段以適合網(wǎng)絡(luò)傳輸。按照 RTP協(xié)議打包好的數(shù)據(jù)，通過(guò) UDP傳輸?shù)娇蛻舳?，如果是單用戶采用單播，如果是多用戶則采用多播。
客戶端采用 B/S模式接收服務(wù)器發(fā)送的音視頻流，并解碼播放。 B/S模式下，播放視頻在 IE中實(shí)現(xiàn)，具體的實(shí)現(xiàn)需要 ActiveX控件支持，由控件嵌入到 WEB中實(shí)現(xiàn)，這樣客戶端只需要通過(guò)瀏覽器就可以觀看現(xiàn)場(chǎng)視頻。服務(wù)器采集音視頻流并壓縮，通過(guò)網(wǎng)絡(luò)發(fā)送到客戶端，客戶端解碼還原出清晰的圖像是視頻監(jiān)控的基本功能。 [!--empirenews.page--]
2. 視頻監(jiān)控硬件原理及設(shè)計(jì)
本系統(tǒng)是在 GX-ARM9-S3C2410核心模塊上進(jìn)行開發(fā)。該嵌入式監(jiān)控視頻服務(wù)器的設(shè)計(jì)主要是指根據(jù)系統(tǒng)要求實(shí)現(xiàn)的功能，選定主控制芯片和專用音視頻壓縮芯片，并確定其外圍電路，實(shí)現(xiàn)聲音圖像采集、壓縮、輸出等功能。由于作者主要完成系統(tǒng)的軟件部分，這里只對(duì)硬件部分做簡(jiǎn)要介紹。硬件模塊結(jié)構(gòu)設(shè)計(jì)如圖 4.2所示:
 

500)this.style.width=500;" border="0" />
2.1音視頻壓縮 /解壓縮模塊
該模塊的質(zhì)量直接關(guān)系到系統(tǒng)的圖像和聲音以及傳輸質(zhì)量，是系統(tǒng)硬件的重要部件之一。因此模塊選用了 VW2010，它是 VWEB公司開發(fā)的實(shí)時(shí) MPEG4音視頻壓縮 /解壓縮芯片((Encoder/Decoder)，該芯片內(nèi)集成有 3個(gè)信號(hào)處理 /控制單元，包括一個(gè)視頻編碼 (壓縮)器、一個(gè)視頻解碼 (解壓)器和一個(gè)片內(nèi) CPU(內(nèi)部擴(kuò)展一個(gè)音頻編碼 DSP C Digital Signal Processors、一個(gè)音頻解碼 DSP、一個(gè)多路復(fù)合單元和一個(gè)多路解復(fù)合單元 ):具有可編程、高性能和低功耗等特點(diǎn)。
2.2音視頻采集、 A/D模塊

該模塊將攝像頭采集到的模擬視頻信號(hào)發(fā)送到模塊中的視頻 A/D轉(zhuǎn)換芯片進(jìn)行視頻數(shù)字化處理，同時(shí)將麥克風(fēng)采集到的模擬音頻送入音頻 A/D轉(zhuǎn)換芯片進(jìn)行音頻數(shù)字化處理。采用 Philips的 SAA7115H,它是 9bit視頻 A/D轉(zhuǎn)換器，支持 NTSC/PAL/SECAM制式，輸出數(shù)字的視頻信號(hào)符合 ITU601和 ITU-8656標(biāo)準(zhǔn)。系統(tǒng)的音頻模塊主要是以一塊音頻 A/D轉(zhuǎn)換芯片 PCM 1800以及與之配套的模擬音頻輸入輸出電路構(gòu)成。 PCM 1800芯片最高采樣率可達(dá)到 96KHz，可以滿足絕大多數(shù)語(yǔ)音應(yīng)用的要求。該芯片的數(shù)字音頻輸入輸出接口采用 I2S模式，直接和 VW210芯片連接。
2.3網(wǎng)絡(luò)傳輸模塊
模塊選用的網(wǎng)絡(luò)接口芯片是 Realte公司的 RTL8201BL。它是具有 lOM/100Mps自適應(yīng)功能的以太網(wǎng)收發(fā)控制器，是目前應(yīng)用最為廣泛的一種網(wǎng)絡(luò)接口芯片。系統(tǒng)將壓縮后的音視頻數(shù)據(jù)打包，通過(guò)網(wǎng)絡(luò)接口發(fā)送到網(wǎng)絡(luò)中，其電路圖如圖 3所示。

500)this.style.width=500;" border="0" />[!--empirenews.page--]

3. 軟件總體結(jié)構(gòu)與設(shè)計(jì)
系統(tǒng)軟件設(shè)計(jì)包括服務(wù)器端和客戶端軟件設(shè)計(jì)。服務(wù)器端軟件主要實(shí)現(xiàn)采集音視頻、壓縮編碼、打包發(fā)送到網(wǎng)絡(luò)?？蛻舳塑浖饕獙?shí)現(xiàn)接受服務(wù)器發(fā)送過(guò)來(lái)的音視頻壓縮包，然后對(duì)數(shù)據(jù)拼接解碼、播放，如圖 4所示。
 

500)this.style.width=500;" border="0" />

3.1MPEG-4視頻流的 RTP組包處理
要通過(guò) RTP傳輸 MPEG-4視頻流，需要對(duì)其進(jìn)行打包 (Packetization)處理。加上時(shí)間、同步等信息。MPEG-4對(duì)每個(gè) voP (voP是 VO在某一時(shí)刻的對(duì)象，即某一幀 vo)獨(dú)立進(jìn)行編 / 解碼。因此以 VOP為單位進(jìn)行打包，既提高了效率又充分利用了 MPEG-4的編碼特性。為了不造成 IP碎片，包長(zhǎng)還須有一個(gè)限制，就是不能超過(guò)該網(wǎng)絡(luò)路徑的 MTU(Maxium Transit Unit)。考慮到傳輸?shù)母咝院蛠G包的魯棒性，我們?nèi)“L(zhǎng)為當(dāng)前 VOP大小與路徑 MTU值的較小值，采用如下組包機(jī)制:
1 VOP能放入單個(gè) RTP包，就把此 VOP單獨(dú)放入一個(gè) RTP包中；
2 VOP分段，放入多個(gè) RTP包，此時(shí)須把 VOP頭部信息復(fù)制到每個(gè) RTP包，以去除包間的相關(guān)性，達(dá)到丟包的魯棒性 :為減小包數(shù)，降低開銷，一包中能放入多少宏塊就盡可能多地放入多少宏塊，但即使最后一個(gè)包中仍有剩余空間，也小能把另一 VOP中的宏塊放入此包中，算法流程如圖 5所示。

500)this.style.width=500;" border="0" />

[!--empirenews.page--]

3.2服務(wù)器端視頻發(fā)送和客戶端視頻接收
在基于DirectShow的視頻發(fā)送端中，其過(guò)濾器圖分別由 Video Capture Filter,Video Codec和 RTP Video Renderer Filter按順序連接成一條“流水線”協(xié)同工作，他們分別完成源過(guò)濾器、轉(zhuǎn)換過(guò)濾器和呈現(xiàn)過(guò)濾器的工作。 Video Capture Filter負(fù)責(zé)視頻數(shù)據(jù)采集， Video Codec負(fù)責(zé)視頻數(shù)據(jù)的壓縮，最后由 RTP Video RendererFilter將壓縮的視頻數(shù)據(jù)封裝 RTP包發(fā)送到網(wǎng)絡(luò)上。過(guò)濾器之間的數(shù)據(jù)發(fā)送采用推模式。
 

500)this.style.width=500;" border="0" />
視頻發(fā)送實(shí)現(xiàn)過(guò)程如下：
1)初始化 coM組件，初始化 DirectShow，包括建立 GraphManager接口、建立 GraphBuilder接口(它的 CLSID為 CLSID_ FilterGraph)、建立 BasicFilter接口，并將 VWSource Filter (VW210),   Sputter Filter(音視頻分離過(guò)濾器)、Codec Fil-ter(TopStepdVideo)和 RTPVren}lter (RTP傳輸呈現(xiàn)過(guò)濾器)加到 GraphBuilder。
2)通過(guò)系統(tǒng)設(shè)各列舉接口找到系統(tǒng)中默認(rèn)的視頻捕獲設(shè)備，并添加到 GraphBuilder中，查詢 GraphBuilder獲得媒體事件接口和媒體控制接口，連接各個(gè)過(guò)濾器，設(shè)置 RTP Vrenflter參數(shù)。
3)通過(guò) GraphManager的控制接口，運(yùn)行過(guò)濾器圖，捕獲并發(fā)送圖象。
4)等待運(yùn)行結(jié)束消息，釋放各個(gè)接口，關(guān)閉 COM組件。視頻發(fā)送實(shí)現(xiàn)過(guò)程中圖像傳輸?shù)膶?shí)現(xiàn)最為關(guān)健，當(dāng)視頻發(fā)送端響應(yīng)網(wǎng)絡(luò)客戶端發(fā)出的視頻數(shù)據(jù)請(qǐng)求后，馬上啟動(dòng)視頻數(shù)據(jù)發(fā)送線程，開始采集 MPEG視頻數(shù)據(jù)并源源不斷地寫入到發(fā)送緩沖區(qū)中。它的實(shí)現(xiàn)原理是:位于源過(guò)濾器 VWSource Filter(VW210卡)將從攝像頭獲取的模擬視頻圖像首先進(jìn)行A/D轉(zhuǎn)換，然后將采集到的視頻數(shù)據(jù)交給下游的 MPEG Stream Spatter filter，由它對(duì)獲得的數(shù)據(jù)進(jìn)行解析后轉(zhuǎn)交給其下游的變換過(guò)濾器 Video Coder filter進(jìn)行 MPEG編碼，然后將編碼后的 MPEG視頻數(shù)據(jù)寫入發(fā)送緩沖區(qū)，這部分都由 VW210卡完成。如果選擇本地存盤則過(guò)濾器圖連接到此結(jié)束，將視頻數(shù)據(jù)直接寫入磁盤。視頻接收端程序流程如下圖 7所示：

500)this.style.width=500;" border="0" />

4結(jié)論
本文創(chuàng)新點(diǎn)：本視頻監(jiān)控系統(tǒng)是基于 ARM嵌入式核心處理器的硬件平臺(tái)，其中嵌入式系統(tǒng)中移植 TCP/IPv6協(xié)議，在原有 MPEG4視頻編碼基礎(chǔ)上采用了新的運(yùn)動(dòng)估計(jì)優(yōu)先估計(jì)矢量分布概率算法進(jìn)行優(yōu)化，同時(shí)對(duì)視頻傳輸算法也作了相應(yīng)的改進(jìn)。系統(tǒng)結(jié)合了流媒體技術(shù)，IPv6技術(shù)，嵌入式技術(shù)等優(yōu)點(diǎn)，實(shí)驗(yàn)證明該系統(tǒng)視頻監(jiān)控方而取得了良好效果。