馮毅 天津市信息中心

基于RTP/UDP/IP的端到端H.263實(shí)時(shí)視頻傳輸系統(tǒng)研究

馮毅 天津市信息中心

本文討論并實(shí)現(xiàn)了無(wú)線(xiàn)局域網(wǎng)上一種基于RTP/UDP/IP的端到端H.263實(shí)時(shí)視頻傳輸系統(tǒng)。實(shí)驗(yàn)證明這個(gè)傳輸方案可獲得較好的性能。擁塞控制是為了防止或者減少網(wǎng)絡(luò)丟包，但是實(shí)際上丟包是不可避免的，因此接收端的誤碼掩蓋是必需的?？梢赃M(jìn)一步考慮增加系統(tǒng)的差錯(cuò)控制機(jī)制和接收方的誤碼掩蓋，或采用各種具有抗誤碼性能、適合網(wǎng)絡(luò)傳輸?shù)木幋a方法，如H.264、多描述編碼等，從而可以實(shí)現(xiàn)更好的無(wú)線(xiàn)視頻服務(wù)。

無(wú)線(xiàn)局域網(wǎng)；FGS編碼技術(shù)；實(shí)時(shí)傳輸

1.實(shí)時(shí)視頻傳輸系統(tǒng)

無(wú)線(xiàn)局域網(wǎng)中的實(shí)時(shí)視頻傳輸同樣依靠TCP/IP協(xié)議棧， 但是底層通過(guò)無(wú)線(xiàn)802.1 1b協(xié)議來(lái)實(shí)現(xiàn)通信。采取客戶(hù)機(jī)/服務(wù)器模式，服務(wù)器、客戶(hù)機(jī)分別是連接在以太網(wǎng)上的TMl300同視頻編碼板和無(wú)線(xiàn)鏈路接入以太網(wǎng)的PC JOE，基于RTP/UDP/IP協(xié)議的H.263實(shí)時(shí)視頻傳輸系統(tǒng)如圖1所示。

圖1 無(wú)線(xiàn)局域網(wǎng)中H.263實(shí)時(shí)視頻傳輸系統(tǒng)

原始采集視頻流經(jīng)H.263碼率可調(diào)編碼器壓縮編碼后，分別被封裝上RTP報(bào)頭、UDP報(bào)頭和IP報(bào)頭，然后IP數(shù)據(jù)包通過(guò)WLAN 向接收端發(fā)送。接收端收到IP數(shù)據(jù)包后按相反的順序?qū)TP報(bào)頭和視頻數(shù)據(jù)提取出來(lái)，根據(jù)RTP報(bào)頭中的數(shù)據(jù)包序列號(hào)將視頻數(shù)據(jù)順序放入緩存供給解碼端解碼輸出。因?yàn)閁DP傳輸協(xié)議不保證數(shù)據(jù)的順序傳輸，發(fā)送端先發(fā)出的數(shù)據(jù)包，在接收端可能后收到。對(duì)于這種情況，如果序列號(hào)為SN 的RTP包在序列號(hào)為SN+3的RTP包到達(dá)之時(shí)接收端仍未收到，則認(rèn)為序列號(hào)為SN的RTP包已經(jīng)丟失。

客戶(hù)機(jī)/接收端在RTP數(shù)據(jù)包分析的同時(shí)，提取出QoS參數(shù)，如RTP包時(shí)間戳(times tamp)、序列號(hào)和往返時(shí)間RTT (round—trip time)等，然后計(jì)算丟包率、丟失事件率P 和接收碼率X_reev等QoS信息，形成RTCP控制包(接收?qǐng)?bào)告RR)反饋到服務(wù)器。服務(wù)器接收到這些RTCP反饋控制包后，根據(jù)反饋包中的QoS數(shù)據(jù)P值來(lái)調(diào)節(jié)源編碼器的編碼速率形成自適應(yīng)的碼率以實(shí)現(xiàn)擁塞控制，如果P過(guò)大，表明丟包嚴(yán)重.則要降低發(fā)送速率從而減少丟包率達(dá)到較好的圖像質(zhì)量。

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

H.263標(biāo)準(zhǔn)規(guī)定了分層的視頻數(shù)據(jù)結(jié)構(gòu)， 從頂層到底層依次是：圖像幀、塊組、宏塊、塊。除了塊層以外，每個(gè)結(jié)構(gòu)都包含一個(gè)頭部分，保存相關(guān)的標(biāo)記、指示位等重要信息，以利于解碼重建。其中塊是空域、頻域變換的基本單位，而塊組是最小的同步單位。一旦在碼流中任何塊的解碼失敗，將會(huì)導(dǎo)致整個(gè)塊組無(wú)法解碼成功，從下一個(gè)塊組開(kāi)始才能正確解碼。

RTP對(duì)H.263視頻流數(shù)據(jù)的封裝有兩種方式：一種考慮是把視頻流作為一般數(shù)據(jù)信息，不考慮具體數(shù)據(jù)格式(無(wú)論是音頻、視頻)，以固定長(zhǎng)度截?cái)鄬?duì)編碼存儲(chǔ)緩沖區(qū)的數(shù)據(jù)進(jìn)行RTP封裝：另一種考慮是根據(jù)H.263編碼視頻流的壓縮特點(diǎn)對(duì)數(shù)據(jù)進(jìn)行封裝，數(shù)據(jù)打包長(zhǎng)度在某個(gè)規(guī)定值以?xún)?nèi)視編碼具體情況而定。對(duì)于第一種方法而言，由于網(wǎng)絡(luò)的丟包是隨機(jī)的，將會(huì)導(dǎo)致丟失的包中含有較多個(gè)數(shù)的塊組GOB或恰好丟失I幀數(shù)據(jù)，以致接收的圖像質(zhì)量大大下降。

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

圖2 對(duì)H.263視頻流的RTP封裝

圖2對(duì)H.263視頻流的RTP封裝采用上述二層RTP封裝方法，GOB頭和幀起始碼比較容易識(shí)別，有利于解碼器重同步。如果發(fā)生丟包，在解碼端還可以運(yùn)用空間補(bǔ)償和時(shí)間補(bǔ)償?shù)炔铄e(cuò)掩蓋方法彌補(bǔ)丟包的損失。

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

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

表一

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

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

圖3 TFRC算法控制模型

1)接收端測(cè)量計(jì)算丟失事件率P，向發(fā)送端反饋信息；

2)發(fā)送端利用反饋信息完成往返時(shí)間RTT的計(jì)算；

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

4)根據(jù)計(jì)算得到的速率調(diào)整發(fā)送端的速率。

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

4.實(shí)驗(yàn)測(cè)試

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

由表中可見(jiàn)，在該無(wú)線(xiàn)局域網(wǎng)中以上述實(shí)時(shí)傳輸系統(tǒng)中打包方案?jìng)魉鸵曨l， 并通過(guò)RTCP反饋進(jìn)行自適應(yīng)的碼率控制，檢測(cè)結(jié)果還是不錯(cuò)的。采用了擁塞控制以后，改善了圖像傳輸質(zhì)量。

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

[2]王文義，李尊鋒，周兵.局域網(wǎng)環(huán)境下視頻實(shí)時(shí)傳輸系統(tǒng)的軟件實(shí)現(xiàn)方法研究.計(jì)算機(jī)工程與應(yīng)用.2010.1

[3]魯宏偉.基于UDP傳輸協(xié)議的包丟失和失序處理.計(jì)算機(jī)工程與應(yīng)用.2009.2

10.3969/j.issn.1001-8972.2011.15.043