摘? 要: 一種在可移植H.323的視頻會議系統(tǒng)內(nèi),基于H.263的純軟件的視頻壓縮、RTP封裝方案,經(jīng)測試可在較低的運算量下實現(xiàn)實時、穩(wěn)定的視頻通信。

　　關(guān)鍵詞: H.263協(xié)議? 視頻編碼? 運動估計? RTP封裝

?

　　國際電信聯(lián)盟(ITU)制定的H.323協(xié)議提供了一種在分組網(wǎng)上進(jìn)行音視頻通信的系統(tǒng)框架,具有良好的應(yīng)用前景。在H.323框架中,H.225協(xié)議負(fù)責(zé)呼叫接續(xù)控制,H.245負(fù)責(zé)媒體信道的控制管理,視頻編碼使用H.261和H.263協(xié)議,RTP協(xié)議對媒體數(shù)據(jù)流進(jìn)行封裝。其中,視頻壓縮將占用大量計算時間和系統(tǒng)功耗。小型設(shè)備中的嵌入式應(yīng)用對運算量和功耗都有嚴(yán)格限定,因此需要降低視頻編碼過程的計算量和實現(xiàn)復(fù)雜度,并保證一定的主觀視覺效果。此外,嵌入式應(yīng)用應(yīng)具有良好的可移植性。本文描述了一個基于H.263協(xié)議的視頻壓縮傳輸方案,其目標(biāo)是可移植性、低運算量和良好容錯性。

1?問題的提出

　　基于H.263的視頻壓縮中,運動估計與搜索利用相鄰二幀圖像之間的時間冗余,在前一幀圖像中搜索當(dāng)前幀的最佳匹配位置,然后進(jìn)行預(yù)測編碼,通過壓縮幀間冗余達(dá)到對視頻數(shù)據(jù)的壓縮。為此,需要確定搜索路徑和匹配準(zhǔn)則。前者通過使用快速搜索算法降低運算復(fù)雜度,后者通過快速匹配算法保證一定的誤差精度。運動估計與搜索過程占用大部分的編碼時間,因此需要一種快速搜索的運動估計算法,同時要保證一定的信噪比和主觀視覺效果。

　　在H.323系統(tǒng)中,視頻數(shù)據(jù)流使用實時傳輸協(xié)議RTP進(jìn)行封裝,然后利用UDP通道傳輸。丟包和錯序不可避免。因此,RTP封裝必須提供相應(yīng)的冗余信息,在接收端采取相應(yīng)的措施進(jìn)行出錯處理,以保證通信的實時性和可靠性。

2?視頻壓縮和傳輸?shù)膶崿F(xiàn)

2.1 運動估計與搜索算法

　　視頻壓縮的流程主要包括離散余弦變換、運動估計與搜索、編碼控制、量化編碼和碼流復(fù)用。其中運動估計與搜索算法決定了壓縮的復(fù)雜性和質(zhì)量。3種運動估計搜索算法:螺旋算法(Spiral Algorithm)、4步搜索算法(4SS Algorithm)和預(yù)測搜索算法(PSA Algorithm)。對這3種算法進(jìn)行比較,匹配準(zhǔn)則均采用絕對誤差和(MAE)。

　　(1)螺旋算法

　　螺旋算法的搜索路徑如圖1所示。以黑點為中心起始點,進(jìn)行環(huán)形搜索。每條新路徑起始點位于前一路徑起始點的左上角。當(dāng)進(jìn)行某個路徑的搜索時,如果當(dāng)前搜索點到達(dá)搜索區(qū)域邊界,則本次搜索結(jié)束。圖中,第1條搜索路徑為虛線路徑,第2條路徑為實線路徑。

?

　　(2)4步搜索算法

　　4步搜索算法的搜索路徑如圖2所示。黑點為中心起始點,點內(nèi)數(shù)字代表所在搜索路徑序號,搜索的步驟和過程如下。

?

　　①以中心起始點為中心,以步長為2的8個點為搜索窗(5×5),找出9個點中絕對誤差和最小的點。如果這個最小誤差點是搜索窗的中心點或者到達(dá)搜索區(qū)域邊界,則轉(zhuǎn)到第③步。

　?、谝寓僦姓业降淖钚≌`差點為中心點,步長為2的8個點為搜索窗(5×5),找出9個點中絕對誤差和最小的點(如果當(dāng)前中心點為前一窗的四頂點之一,則當(dāng)前窗與前一窗中有4個點重合,只需再計算5次絕對誤差和;同理,如果中心點是前一窗邊界中點,則只需再計算3次絕對誤差和)。如果該最小誤差點是搜索窗中心點或者到達(dá)搜索區(qū)域邊界,則轉(zhuǎn)到第③步;否則,重復(fù)本步驟。

　?、垡寓谥姓业降淖钚≌`差點為中心,步長為1的8個點為搜索窗(3×3),找出9個點中絕對誤差和最小的點。以該點為基礎(chǔ)進(jìn)行一次半象素精度的運動估計,得到最終的運動矢量,結(jié)束搜索過程。

　　(3)預(yù)測搜索算法

　　預(yù)測搜索算法中參考矢量的相對位置如圖3所示,其搜索窗中心點的一種可能路徑如圖4所示。預(yù)測搜索算法主要包括2個步驟,即確定搜索起始點和按路徑進(jìn)行搜索。確定搜索起始點的方法是:假設(shè)當(dāng)前宏塊在當(dāng)前幀內(nèi)的坐標(biāo)值為(x,y),找出在前一幀內(nèi)位于(x,y)處的宏塊(假設(shè)為圖3中序號為0的點),然后將位于該宏塊左方、上方和右上方的3個宏塊(圖3中序號為1、2、3的點)所對應(yīng)的運動矢量求和并乘以1/3(按運動矢量的垂直分量和水平分量分別進(jìn)行加權(quán)),獲得一個加權(quán)運動矢量v;在當(dāng)前幀內(nèi),以(x,y)為基礎(chǔ),偏移該加權(quán)運動矢量v,獲得一個新的位置,即為對應(yīng)當(dāng)前宏塊的運動估計搜索起始點的位置。確定搜索路徑的過程如下(假設(shè)圖4中序號為0的點為前一步驟中確定的搜索起始點)。

?

　　①以中心起始點為中心,步長為1的搜索窗(3×3)計算9個點對應(yīng)的絕對誤差和,找出誤差最小的點,如果該最小誤差點為搜索窗的中心點,則轉(zhuǎn)到第③步。

　　②取以第①步中獲得的最小誤差點為中心,搜索步長為1的搜索窗,計算9個點對應(yīng)的絕對誤差和,找出誤差最小的點,如果當(dāng)前最小誤差點為搜索窗的中心點或者達(dá)到了搜索區(qū)域的邊界,則轉(zhuǎn)到第③步;否則,重復(fù)本步驟。

　　③以第②步中獲得的最小誤差點為基礎(chǔ),進(jìn)行半象素精度的全搜索,得到最終的運動矢量,結(jié)束搜索過程。

2.2 H.263碼流的RTP封裝

　　RFC2190描述了關(guān)于H.263視頻流的RTP封裝規(guī)范,它規(guī)定了H.263視頻流在進(jìn)行網(wǎng)絡(luò)傳輸前RTP封裝的3種模式:A模式、B模式和C模式。

　　(1)A模式

　　在A模式中,視頻流以塊組(GOB)為單位進(jìn)行封裝,總是以幀開始碼或者塊組(無論該塊組是否有塊組頭部)開始的,但是并不需要包含整數(shù)個塊組。模式A的載荷頭共4個字節(jié)。封裝格式如圖5所示(圖中數(shù)字表示比特位序號)。

?

　　其中,F字段和P字段的不同組合表示不同的封裝模式;SBIT、EBIT分別表示視頻數(shù)據(jù)首部和尾部的填充位數(shù);I、U、S和A分別表示H.263的4種可選增強模式。這些載荷頭字段與H.263視頻流中的相應(yīng)字段是冗余的。

　　(2)B模式

　　在B模式中,視頻流在宏塊(MB)邊界進(jìn)行分段封裝,該模式只在未選PB幀模式時使用。使用B模式,主要是考慮在塊組數(shù)據(jù)較大的情況下,為避免底層網(wǎng)絡(luò)分片,以及配合完成A模式封裝的需要。模式B的載荷頭共8個字節(jié)。具體封裝格式如圖6所示。

?

　　其中,QUANT為本RTP包中第1個宏塊所用的量化參數(shù);GOBN和MBA分別為第1個宏塊所在的塊組號和宏塊地址;HMV1和VMV1字段分別表示第1個宏塊的運動矢量的水平和垂直分量的預(yù)測值(在高級預(yù)測模式下,為該宏塊中第1個塊的運動矢量的水平和垂直分量的預(yù)測值);HMV2和VMV2字段僅在高級預(yù)測模式中出現(xiàn),表示宏塊中第3個塊的運動矢量的水平和垂直分量的預(yù)測值;其余字段與A模式的同名字段意義相同。

　　(3)C模式

　　C模式與B模式類似,C模式只在選用PB幀模式時使用,載荷頭共12個字節(jié)。具體封裝格式如圖7所示。

?

　　C模式中的各個字段的意義與A模式和B模式中的同名字段相同。

3? 實現(xiàn)方案選擇及結(jié)果

3.1 運動估計與搜索算法的實現(xiàn)及選擇

　　本系統(tǒng)在編碼器中實現(xiàn)了螺旋搜索算法、4步搜索算法和預(yù)測搜索算法,采用QCIF格式測試序列“Mother and Daughter”、“Grandma”、“Salesman”和自行錄制的“Sample”,記錄了平均每宏塊搜索次數(shù),以及亮度Y分量平均壓縮信噪比,分別如表1和表2所示。

3.2 RTP封裝模式的使用

　　進(jìn)行RTP封裝的目的是提供一定的冗余信息,在發(fā)生傳輸錯誤(丟包、數(shù)據(jù)出錯)時,能夠限制錯誤蔓延、提高視頻通信的容錯性和健壯性。

　　為了減小運算復(fù)雜度,不選用PB幀模式,因而不用模式C。H.263協(xié)議中規(guī)定塊組頭是可選的,而視頻流中的最小同步單位是塊組。為了能在丟包的情況下快速重同步,選擇為每個塊組均加上塊組頭。

????按照RFC2190的規(guī)定:如果當(dāng)前宏塊所在的塊組存在塊組頭,則其運動矢量的預(yù)測編碼可參考前一塊組的運動矢量;否則只參考本塊組的運動矢量。因此,同一塊組的宏塊應(yīng)盡量在同一個RTP包內(nèi),否則在丟包的情況下可能無法正確恢復(fù)已接收的宏塊的運動矢量。一種簡單的方案是:假定當(dāng)前塊組無塊組頭,對當(dāng)前宏塊進(jìn)行編碼時,如果該宏塊不能放入當(dāng)前RTP包(可能RTP包已滿),且該宏塊為某塊組的第1個宏塊,則對該宏塊重新編碼,并且加上塊組頭。實驗證明,該方案沒有明顯增強傳輸?shù)慕研?但卻增加了實現(xiàn)復(fù)雜度。

　　綜上所述,選擇模式A進(jìn)行RTP封裝。在編碼端,開辟1KB的RTP緩沖區(qū)。在每個塊組編碼完畢之后,如果有足夠的剩余空間,則將該塊組放入當(dāng)前RTP包內(nèi);否則,立即發(fā)送當(dāng)前RTP包,重新申請一個RTP緩沖區(qū),將當(dāng)前塊組放入新的RTP包。如果當(dāng)前塊組是某幀的最后一個塊組,則放入RTP緩沖區(qū)之后立即發(fā)送(RFC2190中規(guī)定一個RTP包內(nèi)不能包含不同幀的數(shù)據(jù))。在解碼端,根據(jù)RTP頭部的序號進(jìn)行排序和解封裝過程,然后搜索幀/塊組開始碼進(jìn)行同步,并解壓縮。在解碼過程中出錯時,丟棄收到的數(shù)據(jù),用前一幀相應(yīng)的數(shù)據(jù)填充出錯的部分進(jìn)行差錯掩蓋,并重新搜索幀/塊組開始碼進(jìn)行重同步。

3.3 實驗環(huán)境及測試結(jié)果

　　整個H.323協(xié)議棧測試運行的平臺是PⅢ800MHz PC機和Windows2000操作系統(tǒng),以及一套公共服務(wù)函數(shù)。這套公共服務(wù)函數(shù)提供一個抽象操作系統(tǒng)所必需的功能,并具有可移植性,相當(dāng)于協(xié)議棧與具體操作系統(tǒng)之間的適配層。協(xié)議棧運行在這套公共服務(wù)函數(shù)模擬的多線程實時操作系統(tǒng)之上,并調(diào)用其API函數(shù)(這些API函數(shù)獨立于特定的軟/硬件環(huán)境)。因此協(xié)議棧也是可移植的,以便將來移植到小型終端的嵌入式系統(tǒng)中。視頻壓縮和解壓縮作為2個獨立線程屬于協(xié)議棧的一部分,并與其他相關(guān)線程(如采集)通信,整個協(xié)議棧的可用內(nèi)存空間為1MB。

　　在測試中,采用QCIF格式的視頻源,輸出速率為64Kbps。采用螺旋算法的壓縮過程P幀平均編碼時間在600ms以上,協(xié)議棧CPU占用率約為60%。由于運算量大而明顯地影響了協(xié)議棧內(nèi)其他線程的運行和通信,不符合系統(tǒng)對視頻壓縮的低運算量和實時性的要求。采用4步搜索算法的壓縮過程P幀平均編碼時間約為39ms,CPU占用率約為20%。通過對I幀和P幀的合理選擇,能有效縮減整個視頻壓縮的平均時間,并達(dá)到穩(wěn)定的運行效果。采用預(yù)測搜索算法的壓縮過程P幀平均編碼時間約為42ms,CPU占用率約為25%,但在測試過程中其峰值大約為70ms,穩(wěn)定性不如4步搜索算法。綜上所述,協(xié)議棧的視頻壓縮中的運動估計過程最終采用4步搜索算法。

　　為了測試容錯性能,在編碼端每20個RTP包主動丟棄1個,雖然解碼的圖像出現(xiàn)短暫的畫面模糊和圖像錯位,但在2～3秒內(nèi)基本恢復(fù)正常。在編碼端主動使部分RTP包序號亂序,解壓縮端也同樣出現(xiàn)圖像錯位,但是經(jīng)過差錯掩蓋,可在2～3秒內(nèi)恢復(fù)正常的解碼過程。由此證明在解碼部分采用的丟包處理和差錯掩蓋等措施是有效的。

4? 結(jié)? 論

　　本文針對小型設(shè)備的嵌入式系統(tǒng)中基于H.323視頻通信的應(yīng)用,提出并實現(xiàn)了一種基于H.263純軟件實現(xiàn)的、可移植的、基于IP網(wǎng)絡(luò)的視頻壓縮、解壓縮和傳輸方案,在低運算量和傳輸不可靠的環(huán)境下實現(xiàn)了實時、穩(wěn)定的視頻通信。經(jīng)過實驗測試,該方案適用于具有較強處理能力的小型嵌入式系統(tǒng)。

?

參考文獻(xiàn)

1? Draft Recommendation H.263 Video Coding for Low?BitRate Communication.ITU-T Recommendation

H.263,1996

2? RTP Payload Format for H.263 Video Streams.RFC 2190,1997

3? 駱立俊,鄒采榮,高西奇等.視頻編碼中的塊運動估計算法分析.廣播與電視技術(shù),1997;(10)