基于XScaIe處理器的視頻通信系統(tǒng)
關(guān)鍵詞 Xscale H.263 視頻編碼優(yōu)化PXA255
引 言
隨著后PC時代的到來及Internet網(wǎng)絡(luò)的飛速發(fā)展,人們已經(jīng)不滿足于被局限在PC平臺上的視頻通信,可以隨時隨地通過無線網(wǎng)絡(luò)進(jìn)行視頻通信的移動設(shè)備有著很大的社會需求。眾所周知,視頻是一種流特性業(yè)務(wù),數(shù)據(jù)量很大;另外實時視頻通信要求對視頻圖像進(jìn)行高效率、高比例的壓縮,計算復(fù)雜度非常高。如果直接采用現(xiàn)有的Pc上的算法,嵌入式設(shè)備有限的電池能源和運(yùn)算能力難以滿足進(jìn)行實時視頻通信的需求,因此需要依據(jù)嵌入式設(shè)備的特點對算法進(jìn)行改進(jìn)和優(yōu)化,從而降低運(yùn)算的復(fù)雜度。基于xscale處理器的視頻通信原型系統(tǒng),初步滿足了移動視頻通信的要求,本文將具體介紹該系統(tǒng)的實現(xiàn)、優(yōu)化方法和實驗結(jié)果。
1 系統(tǒng)配置
硬件方面,本系統(tǒng)采用Intel公司的sitsang Board(基于XScale PXA255處理器)作為硬件平臺,使用以O(shè)V51l為接口芯片的USB Camera作為圖像采集設(shè)備,Symbol公司的Spectrum24 WiFi CF Card作為無線網(wǎng)絡(luò)傳輸設(shè)備。系統(tǒng)的砸件結(jié)構(gòu)框圖如圖l所示。
軟件方面,操作系統(tǒng)采用Linux-2.4.19-rmk7版本的嵌入式Linux內(nèi)核,圖形界面環(huán)境采用MiniGUI1.3.3.網(wǎng)絡(luò)傳輸協(xié)議采用802.11b。
2 系統(tǒng)軟件設(shè)計
2.1 功能模塊設(shè)計
本系統(tǒng)終端需要具備以下功能:根據(jù)用戶需求,①只顯示本地圖像;②只顯示遠(yuǎn)程圖像;③同時顯示本地圖像和遠(yuǎn)程圖像。為實現(xiàn)功能選擇的任意性,對系統(tǒng)軟件進(jìn)行了模塊化設(shè)計,軟件模塊框圖如圖2所示。
①圖像采集模塊。調(diào)用Vide04Linux模塊的API函數(shù)進(jìn)行編寫,為系統(tǒng)采集YUV格式的本地實時圖像數(shù)據(jù)。
②圖像顯示模塊?;贛iniGUI 1.3.3圖形庫編寫.并采用MiniGUI中的YUVOverlav技術(shù)直接對YUV圖像數(shù)據(jù)進(jìn)行顯示。
③圖像編碼模塊。采用H.263編碼標(biāo)準(zhǔn),對本地圖像數(shù)據(jù)進(jìn)行壓縮編碼。
④圖像解碼模塊。采用H.263解碼標(biāo)準(zhǔn),對遠(yuǎn)程圖像數(shù)據(jù)進(jìn)行解碼。該模塊與圖像解碼模塊共同構(gòu)成本系統(tǒng)的核心。
⑤無線網(wǎng)絡(luò)通信模塊。采用802.11b協(xié)議,引入了RTP協(xié)議的打包機(jī)制,實現(xiàn)了基于UDP傳輸機(jī)制的發(fā)送模塊和接收模塊。
2.2軟件設(shè)計流程
系統(tǒng)中本地顯示、遠(yuǎn)程顯示、發(fā)送和接收需要并發(fā)執(zhí)行,故系統(tǒng)采用多線程編程技術(shù)。本系統(tǒng)共創(chuàng)建采集、顯示、編碼、解碼、發(fā)送和接收6個線程,如圖3所示。其中,合理有效的線程間的通信與互斥機(jī)制是保證程序能夠順利高效執(zhí)行的關(guān)鍵。
3 系統(tǒng)性能優(yōu)化
嵌入式設(shè)備計算能力受限問題以及功耗問題的存在,使得在嵌入式設(shè)備上實現(xiàn)實時視頻通信更具挑戰(zhàn)性。這就需要依據(jù)嵌入式設(shè)備的特點,充分利用計算資源,設(shè)計更合理的軟件架構(gòu),并采用計算復(fù)雜度更小的算法對系統(tǒng)進(jìn)行優(yōu)化。下面具體介紹本系統(tǒng)中的優(yōu)化策略。
3.1 軟件框架級優(yōu)化
在多線程機(jī)制中,各個線程之間通過“時間片”機(jī)制分時復(fù)用CPU資源。如果不進(jìn)行優(yōu)化,則無法保證得到時間片的線程處于有效執(zhí)行狀態(tài),而需要CPU資源的線程能很快得到時間片。
本系統(tǒng)中6個線程之間存在明顯的依賴性。若編碼線程不完成,則發(fā)送線程不會有數(shù)據(jù)源,若線程切換時間片為200 ms,則在發(fā)送線程的200 ms中,CPU一直處于空轉(zhuǎn)狀態(tài)。因此對整個系統(tǒng)而言,如果不加任何優(yōu)化處理.CPU只有30%左右的時間處于有效執(zhí)行狀態(tài)。本系統(tǒng)的優(yōu)化策略采用系統(tǒng)調(diào)用usleep()函數(shù)使處于無效狀態(tài)的線程盡快釋放CPU資源,實現(xiàn)方法如下:
while(1){
if(該線程標(biāo)志位被觸發(fā)){
……
usleeD(1000)
}
通過在代碼的適當(dāng)位置插入usleep()函數(shù)調(diào)用,CPU的利用率從30%左右提高到了96%以上,從而大大提高了計算資源的有效利用率,提高了整個系統(tǒng)的性能。
3.2算法級優(yōu)化
本系統(tǒng)的核心部分由編碼模塊和解碼模塊構(gòu)成。其中編碼模塊的復(fù)雜度要遠(yuǎn)大于解碼模塊的復(fù)雜度,成為整個系統(tǒng)的瓶頸。本文主要介紹編碼模塊的優(yōu)化策略。
本系統(tǒng)采用tmn-1.7作為編碼模塊的藍(lán)本。tmn-1.7遵循標(biāo)準(zhǔn)的H.263編解碼標(biāo)準(zhǔn),所以并沒有考慮嵌入式設(shè)備的運(yùn)算特性。其中對本系統(tǒng)影響最明顯的是離散余弦變換算法(DCT)以及運(yùn)動補(bǔ)償算法(ME)。下面針對這兩個算法提出優(yōu)化方法。
3.2.1離散余弦變換算法
DCT算法把圖像由像素域轉(zhuǎn)換到頻率域后,圖像的大部分能量集中到直流系數(shù)分量以及低頻交流系數(shù)分量上,從而更有利于去除空間冗余信息。
DCT變換的原理是:通過線性變換x=Hx將N維向量x變換為變換系數(shù)向量x,其中變換核H為:
其中變換核中的元素H(k,n)是無理數(shù)。這對大多數(shù)沒有浮點協(xié)處理器的嵌入式設(shè)備實現(xiàn)實時視頻通信是很大的瓶頸,因此提出將浮點數(shù)DCT變換算法改寫成整數(shù)DCT變換算法的方案。
為實現(xiàn)這一方案,最關(guān)鍵的問題就是生成一個滿足變換核的正交性要求,并且只包含整數(shù)系數(shù)的變換矩陣。其基本思路是將無理數(shù)擴(kuò)大再取整,即:
Q(k,n)=round(aH(k,n)) (2)
下面依據(jù)本系統(tǒng)所采用的方法,介紹整數(shù)DCT算法。
首先,介紹本系統(tǒng)該算法中的數(shù)據(jù)表示:
int*dataptr――指向臨時存放DCT系數(shù)的內(nèi)存空間指針:
int*blkptr――指向存放原始塊數(shù)據(jù)的內(nèi)存空間指針;
int*coeffptr――指向存放最終DCT系數(shù)的內(nèi)存空間指針。
然后,對相關(guān)系數(shù)以及常數(shù)進(jìn)行放縮。在對88的塊進(jìn)行DCT變換時,采用先進(jìn)行行變換,再進(jìn)行列變換的方法。下面以獲取一個DCT系數(shù)的過程為例說明。
#define CONST__BlTS 13
#deflne PASS BITS 2
#define F1x_0_541196100 ((int) 4433) /*O.541196100
CONST_BITS*/
到此行變換結(jié)束。結(jié)合公式(1)可以看出,經(jīng)過行變換后比原始的DcT變換放大22倍;同理,再經(jīng)過列變換后,系數(shù)又增大2、/2倍,即經(jīng)過行列變換后共放大到8倍。在算法最后,將按比例還原:
block[i]=(short int)(data[i]>>3);
再通過zigzag掃描矩陣,將系數(shù)填充到coeff矩陣中:
*(coeff+zigzag[i][j])=*(bLock+i*8+j);
在整數(shù)DCT算法中,通過比例放縮消除了浮點數(shù)運(yùn)算,并且大多數(shù)乘除運(yùn)算均采用移位方式處理,更符合CPU的運(yùn)算特點,從而大幅度提高了運(yùn)算效率和壓縮速度。
3.2.2 運(yùn)動補(bǔ)償算法
運(yùn)動補(bǔ)償算法用于去除相鄰圖像之間的時間冗余信息。該算法中,最佳匹配塊搜索算法運(yùn)算量占絕大部分。tmn-1.7編碼器采用螺旋式全搜索算法,雖然準(zhǔn)確度較高,但速度很慢。為了適應(yīng)實時視頻通信以及嵌入式設(shè)備運(yùn)算能力較低的要求,本系統(tǒng)采用二維對數(shù)下降法。
二維對數(shù)下降法的原理是,通過快速搜索跟蹤最小MAD點,如圖4所示。以運(yùn)動矢量(O,O)點為起始點,以十字形分布的5個點構(gòu)成每次搜索的點群。如果最小MAD點出現(xiàn)在十字點群的邊緣,則下次搜索以該點為中心,步長不變;如果最小MAD點出現(xiàn)在十字點群的中心,則下次搜索仍以該點為中心,但步長減半;如果新的十字形搜索中心出現(xiàn)在搜索窗邊緣,則步長減半。如此循環(huán),直到步長為1,則最小MAD點即為最佳匹配點。
本系統(tǒng)中對二維對數(shù)下降法的實現(xiàn)如下:
whlie(步長step>=1){
for(當(dāng)前搜索十字點群中的每個點){
sad=SAD_Macroblock(當(dāng)前搜索塊的指針);/*獲得SAD值*/if(sadMin_FRAME){/*如果小于當(dāng)前最小SAD值,記錄當(dāng)前信
息*/
}
}
if(最小MAD點是當(dāng)前搜索中心){
step=stet)/2;//更新搜索步徑
}
}
該算法大幅度減少了運(yùn)動搜索的搜索次數(shù),從而大大降低了運(yùn)算量,提高了幀問編碼的速率。
4 系統(tǒng)性能分析
下面對實時采集的QCIF圖像序列進(jìn)行測試和分析。測試環(huán)境為Intel Sitsang硬件平臺。此硬件平臺采用PXA255處理器,主頻400 MHz;64 MB SDRAM;操作系統(tǒng)采用Embeded Linux一2.4.19-rmk7。
實時視頻通信系統(tǒng)主要性能指標(biāo)為幀率、圖像壓縮比和信噪比。影響這三個因素的主要模塊為采集、編碼、解碼以及接收和發(fā)送模塊。以下針對各模塊進(jìn)行性能分析。
4.1模塊性能分析
(1)采集模塊
Sitsang板上的USB接口為USBl.1類型。由表1可知,采集數(shù)據(jù)的速率基本達(dá)到了USBI.1協(xié)議的12 Mbps傳輸能力的上限,因此,采集圖像的速度完全取決于圖像格式及圖像大小。為了保證圖像實時性,采用YUV420176144方案。
(2)編碼模塊
編碼模塊經(jīng)過改寫和優(yōu)化,編碼速度得到很大提高,基本可以滿足實時視頻傳輸?shù)乃俣纫螅唧w數(shù)據(jù)如表2所列。在當(dāng)前壓縮速率的情況下,還能夠獲得理想的壓縮比和信噪比,從而保證實時視頻通信的質(zhì)量,如表3所列。
(3)解碼模塊
經(jīng)過對原有程序的裁減和改寫,解碼速度可以達(dá)到84 fps。
(4)發(fā)送與接收模塊
本系統(tǒng)采用WiFi CF Card作為網(wǎng)絡(luò)傳輸設(shè)備,采用802.11b協(xié)議,引入了RTP協(xié)議的打包機(jī)制,實現(xiàn)了基于UDP傳輸機(jī)制的發(fā)送模塊和接收模塊。802.11b帶寬達(dá)11Mbps,在表3的壓縮比情況下,可傳輸幀率>1000fps,完全滿足實時視頻傳輸?shù)囊蟆?BR>
4.2系統(tǒng)性能分析
經(jīng)過模塊優(yōu)化和系統(tǒng)整合,原型系統(tǒng)在Sitsang板上同時顯示本地圖像和遠(yuǎn)程圖像可達(dá)8幀/s,基本達(dá)到了實時視頻要求。因為在系統(tǒng)框架設(shè)計中采用了采集線程一本地顯示線程一編碼線程發(fā)送線程互相抑制的機(jī)制,從而基本實現(xiàn)了本地端圖像和遠(yuǎn)程端圖像的同步。
結(jié)語
本文所設(shè)計的“基于嵌入式設(shè)備的視頻通信原型系統(tǒng)”雖然只是一個雛形,但卻完全實現(xiàn)了實時視頻通信的功能,并為在嵌入式設(shè)備上實現(xiàn)實時視頻通信提供了可行的框架和思路。該系統(tǒng)具有良好的可擴(kuò)展性,為在嵌入式設(shè)備上實現(xiàn)視頻會議以及可視電話系統(tǒng)提供了有價值的參考。
評論