基于RTP/UDP/IP的端到端H.263實時視頻傳輸系統研究

馮毅 天津市信息中心

基于RTP/UDP/IP的端到端H.263實時視頻傳輸系統研究

馮毅 天津市信息中心

本文討論并實現了無線局域網上一種基于RTP/UDP/IP的端到端H.263實時視頻傳輸系統。實驗證明這個傳輸方案可獲得較好的性能。擁塞控制是為了防止或者減少網絡丟包，但是實際上丟包是不可避免的，因此接收端的誤碼掩蓋是必需的。可以進一步考慮增加系統的差錯控制機制和接收方的誤碼掩蓋，或采用各種具有抗誤碼性能、適合網絡傳輸的編碼方法，如H.264、多描述編碼等，從而可以實現更好的無線視頻服務。

無線局域網；FGS編碼技術；實時傳輸

1.實時視頻傳輸系統

無線局域網中的實時視頻傳輸同樣依靠TCP/IP協議棧， 但是底層通過無線802.1 1b協議來實現通信。采取客戶機/服務器模式，服務器、客戶機分別是連接在以太網上的TMl300同視頻編碼板和無線鏈路接入以太網的PC JOE，基于RTP/UDP/IP協議的H.263實時視頻傳輸系統如圖1所示。

圖1 無線局域網中H.263實時視頻傳輸系統

原始采集視頻流經H.263碼率可調編碼器壓縮編碼后，分別被封裝上RTP報頭、UDP報頭和IP報頭，然后IP數據包通過WLAN 向接收端發送。接收端收到IP數據包后按相反的順序將RTP報頭和視頻數據提取出來，根據RTP報頭中的數據包序列號將視頻數據順序放入緩存供給解碼端解碼輸出。因為UDP傳輸協議不保證數據的順序傳輸，發送端先發出的數據包，在接收端可能后收到。對于這種情況，如果序列號為SN 的RTP包在序列號為SN+3的RTP包到達之時接收端仍未收到，則認為序列號為SN的RTP包已經丟失。

客戶機/接收端在RTP數據包分析的同時，提取出QoS參數，如RTP包時間戳(times tamp)、序列號和往返時間RTT (round—trip time)等，然后計算丟包率、丟失事件率P 和接收碼率X_reev等QoS信息，形成RTCP控制包(接收報告RR)反饋到服務器。服務器接收到這些RTCP反饋控制包后，根據反饋包中的QoS數據P值來調節源編碼器的編碼速率形成自適應的碼率以實現擁塞控制，如果P過大，表明丟包嚴重.則要降低發送速率從而減少丟包率達到較好的圖像質量。

2. H.263視頻流的RTP 封裝

H.263標準規定了分層的視頻數據結構， 從頂層到底層依次是：圖像幀、塊組、宏塊、塊。除了塊層以外，每個結構都包含一個頭部分，保存相關的標記、指示位等重要信息，以利于解碼重建。其中塊是空域、頻域變換的基本單位，而塊組是最小的同步單位。一旦在碼流中任何塊的解碼失敗，將會導致整個塊組無法解碼成功，從下一個塊組開始才能正確解碼。

RTP對H.263視頻流數據的封裝有兩種方式：一種考慮是把視頻流作為一般數據信息，不考慮具體數據格式(無論是音頻、視頻)，以固定長度截斷對編碼存儲緩沖區的數據進行RTP封裝：另一種考慮是根據H.263編碼視頻流的壓縮特點對數據進行封裝，數據打包長度在某個規定值以內視編碼具體情況而定。對于第一種方法而言，由于網絡的丟包是隨機的，將會導致丟失的包中含有較多個數的塊組GOB或恰好丟失I幀數據，以致接收的圖像質量大大下降。

在對H.263視頻流進行封裝傳輸時，選擇第二種方法。同時采用RFC2190l[1]，對H.263視頻流以GOB為單位進行打包。對視頻數據的打包在編碼過程中完成。由于H.263編碼是以GOB為同步單位，這種方法有利于解碼同步。一般來說每個包長100～300字節。當以第二種方法打包時，包比較小就意味著RTP頭占了一個較大的開銷。因此，考慮以多個G0B封裝，且每個包中GOB的個數是可控的，這樣也就克服了第一種方法中存在的缺陷。提取頭字節中某些重要比特形成payload header載荷頭置于RTP 固定頭之后(如圖2所示)，并對一些重要信息采用重復傳送的方式，這樣有助于接收端在前面有包丟失的情況下實時解碼。

圖2 對H.263視頻流的RTP封裝

圖2對H.263視頻流的RTP封裝采用上述二層RTP封裝方法，GOB頭和幀起始碼比較容易識別，有利于解碼器重同步。如果發生丟包，在解碼端還可以運用空間補償和時間補償等差錯掩蓋方法彌補丟包的損失。

3. RTCP反饋碼率控制算法TFRC

為了進行網絡擁塞控制.就需要知道網絡的當前或最近的狀態.如阻塞狀況、丟包率、可用的帶寬和傳輸時延等參數。利用這些參數可幫助控制過程進行決策和某些參數估計。這里采用具有TCP友好性的帶寬估算方法。保持數據流TCP友好性的目的是保證在UDP上傳輸視頻數據時，不要太過擠壓，同時在傳輸的TCP數據流，使網絡的吞吐量接近一般的TCP吞吐量，而不致使網絡產生嚴重的擁塞。友好碼率控制算法TFRC是一種基于公式的TCP擁塞控制算法。可控制發送端碼率，以使得整個視頻傳輸系統既能充分利用網絡帶寬又不引起網絡擁塞，從而減少時延、降低丟包率。算法中采用下面TCP吞吐量方程：

表一

式中： 為計算得到的發送速率；s為包大小MTU；R為往返時間RTT，RTO為重傳超時時間， 一般取RTO =4×R；b在TCP沒有延遲確認機制的情況下取值為l；p為丟失事件率(在0～1.0之間)，其中丟失事件的定義是在一個擁塞中的一個或多個分組丟失或者是被標記的分組丟失[2]，丟失事件率為丟失事件的數量占所傳輸的分組數量的百分比。

TFRC算法模型如圖3所示， 框圖中的發送端主要解決RTT和碼率增/減策略； 接收端主要完成丟失事件率p的估計和接收比特率的統計TFRC碼率控制算法過程如下：

圖3 TFRC算法控制模型

1)接收端測量計算丟失事件率P，向發送端反饋信息；

2)發送端利用反饋信息完成往返時間RTT的計算；

3)將計算出的p和RTT代入TCP吞吐量方程中計算得到發送速率X；

4)根據計算得到的速率調整發送端的速率。

此算法中關鍵是RTT和P的獲取，具體獲取算法參考RFC3448[3]。算法中參數的反饋都是依靠RTCP通信來完成的，通過定義RTCP控制包中的接收報告塊RR(Receive Report)的結構變量，進行賦值通信，從而反饋到發送端進行碼率調整。發送端根據由丟失事件率P 和R1Tr計算出的速率 進行碼流速率適配，碼流速率調整主要是通過速率修正機制， 即通過調整編碼的量化步長QP來達到目的。量化步長增大，速率降低；量化步長減小，速率增加。因此如果計算得到的速率X 比當前發送速率大，則說明帶寬還比較充裕，可以減小量化步長使發送速率調整到值，同樣，如果比當前速率小，則說明可能發生擁塞，需要增大量化步長使發送速率降低，降低了發送速率，減少了數據占用帶寬，從而改善網絡狀況。在調整時應該通過統計數學建模來得到確切的調節方式，這里采用只對幀間量化步長作調整的方法。

4.實驗測試

在圖2中， 服務器采用TM1300專用芯片進行編碼，并與以太網相連接，客戶機采用以無線鏈路接入以太網的PC機顯示圖像， 運用上述傳輸控制方案，在無線局域網上傳輸視頻，測得發送速率和丟包率(每隔2 min測試)如表一所示。

由表中可見，在該無線局域網中以上述實時傳輸系統中打包方案傳送視頻， 并通過RTCP反饋進行自適應的碼率控制，檢測結果還是不錯的。采用了擁塞控制以后，改善了圖像傳輸質量。

[1]Handley M， Floyd S， Padhye J， et a1.TCP Friendly Rate Control(TFRC)Protocol Sqecification.RFC 34 8，January 2003.1—24

[2]王文義，李尊鋒，周兵.局域網環境下視頻實時傳輸系統的軟件實現方法研究.計算機工程與應用.2010.1

[3]魯宏偉.基于UDP傳輸協議的包丟失和失序處理.計算機工程與應用.2009.2

10.3969/j.issn.1001-8972.2011.15.043