摘? 要: 一種在可移植H.323的視頻會議系統內,基于H.263的純軟件的視頻壓縮、RTP封裝方案,經測試可在較低的運算量下實現實時、穩定的視頻通信。

　　關鍵詞: H.263協議? 視頻編碼? 運動估計? RTP封裝

?

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

1?問題的提出

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

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

2?視頻壓縮和傳輸的實現

2.1 運動估計與搜索算法

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

　　(1)螺旋算法

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

?

　　(2)4步搜索算法

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

?

　?、僖灾行钠鹗键c為中心,以步長為2的8個點為搜索窗(5×5),找出9個點中絕對誤差和最小的點。如果這個最小誤差點是搜索窗的中心點或者到達搜索區域邊界,則轉到第③步。

　　②以①中找到的最小誤差點為中心點,步長為2的8個點為搜索窗(5×5),找出9個點中絕對誤差和最小的點(如果當前中心點為前一窗的四頂點之一,則當前窗與前一窗中有4個點重合,只需再計算5次絕對誤差和;同理,如果中心點是前一窗邊界中點,則只需再計算3次絕對誤差和)。如果該最小誤差點是搜索窗中心點或者到達搜索區域邊界,則轉到第③步;否則,重復本步驟。

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

　　(3)預測搜索算法

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

?

　?、僖灾行钠鹗键c為中心,步長為1的搜索窗(3×3)計算9個點對應的絕對誤差和,找出誤差最小的點,如果該最小誤差點為搜索窗的中心點,則轉到第③步。

　?、谌∫缘冖俨街蝎@得的最小誤差點為中心,搜索步長為1的搜索窗,計算9個點對應的絕對誤差和,找出誤差最小的點,如果當前最小誤差點為搜索窗的中心點或者達到了搜索區域的邊界,則轉到第③步;否則,重復本步驟。

　?、垡缘冖诓街蝎@得的最小誤差點為基礎,進行半象素精度的全搜索,得到最終的運動矢量,結束搜索過程。

2.2 H.263碼流的RTP封裝

　　RFC2190描述了關于H.263視頻流的RTP封裝規范,它規定了H.263視頻流在進行網絡傳輸前RTP封裝的3種模式:A模式、B模式和C模式。

　　(1)A模式

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

?

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

　　(2)B模式

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

?

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

　　(3)C模式

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

?

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

3? 實現方案選擇及結果

3.1 運動估計與搜索算法的實現及選擇

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

3.2 RTP封裝模式的使用

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

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

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

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

3.3 實驗環境及測試結果

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

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

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

4? 結? 論

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

?

參考文獻

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? 駱立俊,鄒采榮,高西奇等.視頻編碼中的塊運動估計算法分析.廣播與電視技術,1997;(10)