張海朝， 潘永輝， 王亞濤

(河南科技大學 電子信息工程學院，河南 洛陽 471003）

0 引言

隨著Internet的迅速發(fā)展和網絡帶寬的不斷提高,基于網絡的實時視頻應用越來越多。如何保證傳輸質量是一個很關鍵的問題。當把視頻放到網絡上傳輸時，它主要包括了編碼、傳輸、解碼三部分。只有綜合考慮這三部分，才能保證視頻應用的質量。目前的圖像壓縮標準中，H.264是最新發(fā)布的視頻壓縮標準,它有著更高的壓縮比，并且具有與編碼層相對獨立的NAL(網絡層)，使得H.264具有良好的網絡“友好性”，能適應各種網絡的傳輸。但目前視頻網絡傳輸常采用UDP傳輸協(xié)議,而UDP協(xié)議缺乏端到端的擁塞控制機制。為了能和TCP數(shù)據(jù)流公平地競爭帶寬,避免引起長時間的、嚴重的網絡擁塞,視頻流應該不僅具有TCP友好性,而且擁有平滑的傳輸速率[1-2]。但是在盡力而為的網絡中,丟包能夠顯著地降低視頻的回放質量。因此,視頻傳輸還應該對丟包問題做出處理。因此,本文以H.264視頻為研究對象,結合TCP友好速率控制算法和差錯控制機制建立提出了一個集成擁塞控制的端到端視頻傳輸框架,經實驗證明,該框架在不同的網絡狀況下,均能收到較好的效果。

1 視頻傳輸框架

由于H.264壓縮編碼算法使用運動估值和運動補償技術,一旦有分組丟失存在,不僅影響當前解碼圖像,而且會影響后續(xù)解碼圖像,即誤碼擴散,而時延和時延抖動對實時視頻通信的恢復圖像質量也會造成影響。實際上,在傳輸系統(tǒng)中,若將一個端到端傳輸系統(tǒng)作為整體來考察，由各個部分共同對抗網絡傳輸差錯,以合理地滿足用戶對于視覺質量、實時性等各個不同方面的QoS要求。因此,本文在結合了容錯編碼、打包策略、擁塞控制、差錯掩蓋等算法的基礎上,提出了如圖1所示的端到端視頻傳輸框架結構。

圖1 端到端視頻傳輸框架

1.1 容錯編碼及錯誤掩蓋算法

由于H.264協(xié)議充分考慮了IP網絡的特性,并在視頻編碼層和網絡提取層中提供了多種容錯工具,以適應IP網絡盡力而為的特點,因此可減輕諸如帶寬波動、延時、丟包所帶來的不良影響[3]。為了抑制空間錯誤蔓延,一幀圖像被Slice工具將分割成局部的獨立編碼單元。同時,任意宏塊順序的引入可以使解碼端以更高概率得到丟失區(qū)域周圍的正確信息,這將有助于解碼端的錯誤掩蓋算法的應用,因此可將一部分對抗傳輸差錯的任務分至編、解碼端，而無需加以各類增加時延的強保護信道碼算法。

在解碼端,提出了一種基于緊鄰幀參考的加權邊界匹配算法來進行錯誤隱藏，本算法的前提是假設視頻圖像壓縮只采用前向運動補償預測技術，即只有I幀和P幀，每個宏塊只有一個運動矢量，在此條件下，運用改進后的算法對運動矢量做進一步優(yōu)化，從而實現(xiàn)對錯誤塊的隱藏，有效改善了傳統(tǒng)邊界匹配算法在物體邊緣處由于DCT系數(shù)劇烈變化而產生較大匹配誤差的缺陷[4]。算法主要分為兩個步驟，當發(fā)現(xiàn)某一宏塊發(fā)生錯誤時，首先確定候選運動矢量集，根據(jù)改進的邊界匹配原則得到最佳運動矢量，從而確定邊緣變化最小的宏塊。將該方法推廣到緊鄰幀參考環(huán)境下，可得到多個候選宏塊，對所有候選宏塊進行加權平均，將得到的宏塊替代受損的宏塊.在本文中，設第n幀某宏塊受損， fn表示第n幀，表示預測幀， Mn(x, y)表示當前受損宏塊，(x, y)表示該宏塊在當前 fn中的位置，宏塊Mn運動矢量為 DMn(x, y)，CMn(x, y)表示候選運動矢量集，則邊界匹配最佳運動矢量，即最小SAD的運動矢量為：

其中，Du、Dd、Dd、Dr分別代表與上邊、下邊、左邊、右邊的相鄰宏塊的像素差值的平方和，其計算方式如下:

而ωu、ωd、ωl、ωr為分別表示當前受損宏塊與鄰域宏塊各邊界匹配誤差的權重，其取值方法如下:

其中，D()表示統(tǒng)計方差，COV(.)表示協(xié)方差。

在連續(xù)宏塊丟失的情況下，受損塊的空間相鄰宏塊也將受到影響，不能提供可靠的運動矢量。這時在緊鄰幀參考環(huán)境下，參考幀中預測矢量的引入，對丟失運動矢量的正確恢復有著重要的意義。

1.2 打包策略

H.264的編碼結構在算法概念上分為兩層:視頻編碼層(VCL)和網絡適配層(NAL)，VCL提供高效率的視頻壓縮功能;NAL負責網絡的適配，及對不同的網絡要有不同的適應能力，如以恰當?shù)姆绞綄?shù)據(jù)進行打包的傳送，其碼流結構對網絡適應性強，增加了糾錯能力，能夠很好地適應IP網絡的應用。H.264標準還加強了對誤碼和丟包的處理，提高了抗誤碼能力;對不同的業(yè)務靈活采取相應的時延限制。由此可見，基于NAL的設計，H.264視頻非常適合在RTP/UDP/IP網絡上傳輸。NAL層對H.264進行RTP的打包過程是比較簡單的，它符合RFC1889中定義的通用規(guī)則。RTP凈荷包含NAL預備的編碼數(shù)據(jù)，對于RTP凈荷的頭部沒有作特殊的規(guī)定。H.264的RTP凈荷規(guī)則中的設計要求可以歸納如下:具有較低的開銷。因此MTU的大小設計在100字節(jié)到64千字節(jié)為佳;無需解開包中攜帶的比特流，就能區(qū)分該RTP包的重要性和次要性;凈荷規(guī)則在無需解開比特流的情況下，就能夠檢測出由于誤碼所造成的解碼;能夠支持NAL單元重組，在一個RTP包中傳送多個NAL單元。通過NAL單元分割和NAL單元重組來實現(xiàn)H.264基于RTP的網絡傳輸。

2 TCP友好的速率控制機制

視頻傳輸中引入TCP友好速率控制機制的主要目的是和TCP數(shù)據(jù)流公平地競爭帶寬.RFC3448中所給出的TFRC(TCP Friendly Rate Control)規(guī)定,在相同的網絡條件下,如果一個非TCP數(shù)據(jù)流的長期吞吐量沒有超過同期TCP數(shù)據(jù)流的吞吐量,則可被認為是TCP友好的。因此,速率控制機制中視頻流的發(fā)送速率的上限應該是同期TCP數(shù)據(jù)流的發(fā)送速率,即可以使用TCP速率公式來計算TCP友好的視頻流的發(fā)送速率。TCP速率公式如下:式中,S是數(shù)據(jù)包的大小。計算發(fā)送速率X,需要知道數(shù)據(jù)包的往返時間R,TCP超時重傳時間t_RTO以及丟包事件率p。通過實驗我們發(fā)現(xiàn)TFRC在調整視頻流的發(fā)送速率時波動比較大，容易造成接收端在播放視頻時產生抖動現(xiàn)象。為此我們提出一種改進的TFRC機制--延遲預警算法[5]，通過在發(fā)送端增加一個延遲預警信號來感知網絡的延遲，然后在發(fā)送速率公式中增加一個平滑因子來平滑發(fā)送速率的波動，通過仿真驗證了所提出算法的有效性。

3 實驗結果及分析

采用 H.264參考軟件 JM86實現(xiàn)算法，測試序列為Container和Foreman,采用FMO交織模式，測試幀為100幀，編碼模式IPPP，打包格式采取 RTP/IP/UDP，丟包位置隨機。IP信道誤碼測試根據(jù) ITU推薦的典型平均丟包率為 3%、5%、10%、20%的Error Pattem文件來模擬實現(xiàn)。由此得到的兩個視頻序列在時域直接替代法，邊界匹配算法以及本文算法這三種不同算法條件下的峰值信噪比。

在Container序列中，如圖2所示。

圖2 container重建峰值信噪比

隨著有視頻信號錯誤率的增加，本文算法性能有提高但不是十分顯著，而且與時域直接替代算法以及邊界匹配算法的重建圖像峰值信噪比曲線基本重合，說明對運動幅度很小的平移運動，三者性能基本相同。但是在視頻信號運動較大、背景變化和抖動明顯的Foreman序列中，得到的重建圖像峰值信噪比高出很多，而且隨著錯誤率的增加，本算法的性能優(yōu)勢越來越明顯，如圖3所示。這說明本文的改進算法不論在視頻信號運動幅度平緩還是劇烈的環(huán)境下，較之兩種傳統(tǒng)的差錯掩蓋算法在性能上均有提高，尤其在視頻信號運動較大且信號錯誤率較高的情況下性能優(yōu)勢更為明顯，能有效地抑制邊界視頻差錯的擴散，取得較好的差錯隱藏效果。

圖3 foreman重建峰值信噪比

4 結語

針對目前視頻傳輸需求的日益增大以及帶寬資源不足的現(xiàn)狀,使得視頻壓縮流在丟包網絡中的傳輸問題成為了當前的研究熱點。本文通過整個端到端系統(tǒng)中,包括編碼器、擁塞控制以及解碼器錯誤掩蓋等各個機制的協(xié)同合作,將抗差錯傳輸?shù)娜蝿辗种撩恳粋€步驟,大大提高了視頻傳輸?shù)聂敯粜浴?/p>

[1]Floyd S, Handley M, Padhye J, et al.RFC3448, Tcp Friendly Rate control[S].IETF,January 2003.http://www.ietf.org/rfc/rfc3448.txt.

[2]張軍勝,孫沛,萬毅.一種抗抖動的魯棒性速率自適應算法[J].通信技術，2008,41(09):6-8.

[3]Wenger S.H.264/AVC Over IP[J].IEEE Transactions on Circuits and Systems for Video Technology,2000,13(07):645-656.

[4]李曉,劉立柱.MPEG-2視頻解碼器中的錯誤隱藏方法研究[J].通信技術，2008，41(03):52-53.

[5]潘永輝,張海朝.延遲預警在TFRC擁塞控制中的應用[J].計算機工程，2009，35(14):114-116.