蔣 維，孟利民

(浙江工業(yè)大學(xué)信息工程學(xué)院，浙江杭州310023)

0 引言

視頻監(jiān)控系統(tǒng)發(fā)展了短短20余年時(shí)間，發(fā)生了翻天覆地變化。從最早模擬監(jiān)控到前些年火熱數(shù)字監(jiān)控，再到現(xiàn)在方興未艾的網(wǎng)絡(luò)視頻監(jiān)控。視頻監(jiān)控系統(tǒng)發(fā)展劃分為第一代模擬視頻監(jiān)控系統(tǒng)(CCTV)，到第二代基于“PC+多媒體卡”的數(shù)字視頻監(jiān)控系統(tǒng)(DVR)，到第三代完全基于IP網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)(IPVS)［1］。傳統(tǒng)的有線(xiàn)網(wǎng)絡(luò)監(jiān)控由于網(wǎng)線(xiàn)的限制，一旦設(shè)施鋪設(shè)完成，就很難再進(jìn)行改動(dòng)，而且不利于緊急情況下的快速鋪設(shè)。3G網(wǎng)絡(luò)的普及使得這種情況得到了解決。在監(jiān)控設(shè)備上搭載3G上網(wǎng)設(shè)備，設(shè)備就能在任何具有3G信號(hào)的場(chǎng)所擺放安裝。但是，由于3G網(wǎng)絡(luò)的帶寬問(wèn)題一直沒(méi)有解決，平均下載速率在100kB/s左右。TD-SCDMA平均下載速度僅為77kB/s，與標(biāo)稱(chēng)值358kB/s相去甚遠(yuǎn)［2］。傳輸一路CIF格式的視頻數(shù)據(jù)流平均每小時(shí)容量在180 250MB之間，通常情況下取值200MB，也就是56kB/s，再加上一些RTP包頭、TCP包頭以及各類(lèi)控制信息，其值已經(jīng)達(dá)到了3G網(wǎng)絡(luò)的平均下載速率，任何的網(wǎng)絡(luò)帶寬波動(dòng)都會(huì)造成實(shí)時(shí)視頻數(shù)據(jù)的馬賽克現(xiàn)象，這是使用者所不愿意看到的。因此，采用算法減小CIF格式的數(shù)據(jù)也就成為了必然。

1 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的總體框架

本移動(dòng)視頻監(jiān)控系統(tǒng)主要由帶3G無(wú)線(xiàn)傳輸模塊的網(wǎng)絡(luò)攝像機(jī)、集群媒體處理服務(wù)器、基于PC的客戶(hù)端、3G智能手機(jī)組成。視頻通過(guò)網(wǎng)絡(luò)攝像機(jī)實(shí)時(shí)采集和壓縮，然后將實(shí)時(shí)視頻數(shù)據(jù)通過(guò)3G無(wú)線(xiàn)傳輸模塊傳輸至集群媒體處理服務(wù)器，然后再轉(zhuǎn)發(fā)給基于PC的客戶(hù)端或3G智能手機(jī)當(dāng)中，經(jīng)過(guò)對(duì)壓縮數(shù)據(jù)的解碼還原成原始的數(shù)字多媒體數(shù)據(jù)，在客戶(hù)端進(jìn)行實(shí)時(shí)回放。同時(shí)客戶(hù)端還可以存儲(chǔ)視頻數(shù)據(jù)，以便以后檢索和回放，達(dá)到視頻監(jiān)控的目的［3］。其基本框架如圖1所示:

(1)帶3G無(wú)線(xiàn)傳輸模塊的網(wǎng)絡(luò)攝像機(jī)是一個(gè)基于linux的嵌入式雙核實(shí)時(shí)處理系統(tǒng)。該系統(tǒng)主要負(fù)責(zé)把攝像機(jī)采集到的模擬視頻信號(hào)進(jìn)行量化、壓縮編碼，然后打包成適合3G無(wú)線(xiàn)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包傳輸至集群媒體處理服務(wù)器當(dāng)中。同時(shí)該系統(tǒng)接收客戶(hù)端的控制并執(zhí)行該控制命令。因?yàn)橐苿?dòng)視頻監(jiān)控系統(tǒng)對(duì)視頻的實(shí)時(shí)性要求較高，但是無(wú)線(xiàn)網(wǎng)絡(luò)相比有線(xiàn)網(wǎng)絡(luò)其傳輸速率具有不穩(wěn)定性。因此要求視頻采集芯片能改變其采集幀率以適應(yīng)碼率的要求;

圖1 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)總體設(shè)計(jì)框架

(2)集群媒體處理服務(wù)器是一個(gè)linux服務(wù)器系統(tǒng)，該系統(tǒng)主要負(fù)責(zé)網(wǎng)絡(luò)攝像機(jī)的設(shè)備管理、用戶(hù)客戶(hù)端的管理、實(shí)時(shí)流媒體的轉(zhuǎn)發(fā)等功能。任何網(wǎng)絡(luò)攝像機(jī)啟動(dòng)之后都需要向服務(wù)器進(jìn)行設(shè)備注冊(cè)，這樣客戶(hù)端就可以根據(jù)服務(wù)器上的網(wǎng)絡(luò)攝像機(jī)信息進(jìn)行設(shè)備訪(fǎng)問(wèn)。同時(shí)客戶(hù)端登錄之后，服務(wù)器都要對(duì)其用戶(hù)權(quán)限進(jìn)行鑒別，根據(jù)其用戶(hù)權(quán)限開(kāi)通不同的服務(wù)。服務(wù)器要保證多媒體信息實(shí)時(shí)轉(zhuǎn)發(fā)到客戶(hù)端當(dāng)中，所以對(duì)服務(wù)器的實(shí)時(shí)性和穩(wěn)定性要求都比較高;

(3)PC的客戶(hù)端是一個(gè)基于Windows的客戶(hù)端處理軟件，主要負(fù)責(zé)視頻的實(shí)時(shí)回放，監(jiān)控視頻的存儲(chǔ)，監(jiān)控系統(tǒng)和客戶(hù)的交互等功能。因?yàn)樵摽蛻?hù)端處理軟件是一個(gè)多畫(huà)面的視頻監(jiān)控軟件，需要支持多路的視頻解碼播放，因此需要較高的CPU、內(nèi)存和快速的解碼算法［4］。

2 硬件系統(tǒng)結(jié)構(gòu)圖

設(shè)備端的硬件結(jié)構(gòu)主要由兩個(gè)部分組成:

(1)TW2835主要負(fù)責(zé)4路視頻數(shù)據(jù)從模擬信號(hào)到數(shù)字信號(hào)的轉(zhuǎn)換，同時(shí)將該數(shù)字信號(hào)處理之后，使得4路CIF大小的視頻數(shù)據(jù)組合成為1路D1大小的視頻數(shù)據(jù);

圖2 設(shè)備硬件框架

(2)GM8180芯片主要負(fù)責(zé)同時(shí)捕捉兩路D1大小的視頻流，將其壓縮成為H.264標(biāo)準(zhǔn)大小的視頻數(shù)據(jù)。同時(shí)具有將GPS信息疊加到視頻圖像，以及3G網(wǎng)絡(luò)傳輸和本地存儲(chǔ)的功能。設(shè)備端的硬件框架如圖2所示。

該系統(tǒng)使用TW2835+GM8180兩塊主要芯片來(lái)實(shí)現(xiàn)視頻數(shù)據(jù)的實(shí)時(shí)采集，壓縮編碼和傳輸。其中TW2835是視頻數(shù)據(jù)輸入、輸出的場(chǎng)所，GM8180則是捕獲BT656數(shù)據(jù)之后，將其編碼壓縮成為H.264視頻數(shù)據(jù)的場(chǎng)所。

3 視頻數(shù)據(jù)的抽取

3.1 數(shù)據(jù)格式的介紹

經(jīng)過(guò)攝像頭采集后的數(shù)據(jù)，在內(nèi)存中是以4:2:0的YUV數(shù)據(jù)格式存放的，其數(shù)據(jù)格式不同于往常的YUV420。

3.1.1 Y 分量數(shù)據(jù)

Y數(shù)據(jù)以16×16的塊存放，從指針ptr到ptr+16×16為第一個(gè)塊內(nèi)象素的Y分量，依次類(lèi)推到720×576。如圖3所示。

3.1.2 UV 分量數(shù)據(jù)

UV數(shù)據(jù)以8×8數(shù)據(jù)塊交叉排列，如圖4所示。

圖3 Y數(shù)據(jù)分量

圖4 UV數(shù)據(jù)分量

圖5 抽取前視頻的位置

3.2 數(shù)據(jù)的抽取

從tw2835中可以獲得4路的完整數(shù)據(jù)，抽取前各路視頻的位置如圖5所示。其中II III IV 3路視頻數(shù)據(jù)大小為360×288，可以直接壓縮成CIF數(shù)據(jù)保存到本地硬盤(pán)。由于tw2835中最小的視頻數(shù)據(jù)大小為360×144，為了獲取QCIF大小的數(shù)據(jù)，需要將第一路獲取的視頻數(shù)據(jù)變換成180×144格式大小。

3.2.1 Y 分量的抽取

由于象素間的關(guān)聯(lián)性和數(shù)據(jù)排列的格式?jīng)Q定，需要在第一個(gè)16×16數(shù)據(jù)塊第一行的16個(gè)點(diǎn)中取8個(gè)點(diǎn)作為新數(shù)據(jù)的前8個(gè)點(diǎn)，然后在第二個(gè)16×16數(shù)據(jù)塊第一行的16個(gè)點(diǎn)中取8個(gè)點(diǎn)作為新數(shù)據(jù)的后8個(gè)點(diǎn)，然后是第一個(gè)數(shù)據(jù)塊的第二行和第二個(gè)數(shù)據(jù)塊的第二行。依次類(lèi)推，總的來(lái)說(shuō)就是用第一和第二個(gè)數(shù)據(jù)塊抽取新數(shù)據(jù)的第一個(gè)數(shù)據(jù)塊。抽取完成之后將數(shù)據(jù)填回I1路數(shù)據(jù)中，該過(guò)程的流程圖如圖6所示。

圖6 Y分量抽取流程圖

3.2.2 UV 分量的抽取

UV分量的抽取和Y分量類(lèi)似，但要注意的是第一個(gè)U分量需要在第一個(gè)U數(shù)據(jù)塊和第二個(gè)U數(shù)據(jù)塊中抽取，V分量同理。抽取完成之后將數(shù)據(jù)填回I1路數(shù)據(jù)中。

視頻數(shù)據(jù)處理完成之后，各路視頻數(shù)據(jù)的位置如圖7所示。

圖7 抽取后視頻的位置

4 實(shí)驗(yàn)結(jié)果

通過(guò)對(duì)3G網(wǎng)絡(luò)性能的分析得知該網(wǎng)絡(luò)能夠順利地傳輸QCIF格式大小的H.264視頻數(shù)據(jù)。針對(duì)該實(shí)際情況，本文設(shè)計(jì)了基于3G網(wǎng)絡(luò)傳輸?shù)腍.264視頻監(jiān)控系統(tǒng)總體構(gòu)架及系統(tǒng)結(jié)構(gòu)，采用特定的算法，使用TW2835以及GM8180芯片將一路CIF數(shù)據(jù)抽取成QCIF大小的數(shù)據(jù)進(jìn)行3G上傳，其余3路的CIF視頻數(shù)據(jù)進(jìn)行本地存儲(chǔ)。實(shí)驗(yàn)表明，抽取為QCIF后的RTP數(shù)據(jù)包經(jīng)過(guò)3G網(wǎng)絡(luò)傳輸?shù)膩G包率為8%，而未經(jīng)抽取的CIF格式數(shù)據(jù)經(jīng)過(guò)相同3G網(wǎng)絡(luò)傳輸?shù)膩G包率為15%，在丟包率上QoS性能提升明顯。本方案通過(guò)犧牲圖像質(zhì)量為代價(jià)(從CIF降到QCIF)，降低了圖像傳輸過(guò)程中的丟包現(xiàn)象，從而保證了圖像的流暢性。接收后的RTP數(shù)據(jù)通過(guò)客戶(hù)端進(jìn)行播放，QCIF格式數(shù)據(jù)經(jīng)過(guò)網(wǎng)絡(luò)傳輸后播放結(jié)果如圖8所示，該視頻圖像清晰度尚可，且能流暢播放，幾乎沒(méi)有出現(xiàn)馬賽克和停頓的現(xiàn)象。

圖8 實(shí)驗(yàn)結(jié)果

5 結(jié)束語(yǔ)

后續(xù)的工作是在當(dāng)前研究的基礎(chǔ)上，加上視頻差錯(cuò)恢復(fù)技術(shù)，在低碼流的情況下恢復(fù)出高質(zhì)量的圖像，使得該系統(tǒng)能夠傳輸CIF格式的視頻流數(shù)據(jù)。

［1］ 呂金剛，楊建全，文代明，等.智能視頻監(jiān)控技術(shù)的應(yīng)用與發(fā)展［J］.通信電源技術(shù)，2006，23(5):62－67.

［2］ ugmbbc.TD 平均下載速度77KB/s與理論值相去甚遠(yuǎn)［EB/OL］.http://www.cnbeta.com/articles/81328.htm，2009－04－08.

［3］ 郝繼輝.網(wǎng)絡(luò)視頻監(jiān)控技術(shù)的發(fā)展和展望［J］.中國(guó)科技信息，2007，(7):97－99.

［4］ 張翔，張寧.基于IP視頻監(jiān)控應(yīng)用的H.264視頻壓縮［J］.工業(yè)控制計(jì)算機(jī)，2003，16(12):28－30.

［5］ 李海昕.IP視頻監(jiān)控城市公共安全的“火眼金睛”［J］.中國(guó)安防，2009，(1):126－131.