王曉西，駱新全

(1.中國傳媒大學(xué)新媒體研究院，北京100024;2.中國傳媒大學(xué)信息工程學(xué)院，北京100024)

1 引言

流媒體［1］［2］(Streaming Media)就是指在 Internet/Intranet上使用流式傳輸技術(shù)的連續(xù)時基媒體(如音頻、視頻或其它媒體文件)。本文旨在研究其中H.264編碼標準格式下視頻流的實時傳輸。實時傳輸協(xié)議(RTP，Real-time Transport Protocol)是在Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。制定RTP協(xié)議是為了完成實時傳輸數(shù)據(jù)，并提供帶有實時特性的端對端數(shù)據(jù)傳輸服務(wù)。但RTP只完成數(shù)據(jù)傳輸?shù)墓δ?，并不對任何媒體提供機制來確保質(zhì)量。所以，監(jiān)控服務(wù)質(zhì)量的任務(wù)就需要由實時傳輸控制協(xié)議(RTCP，Real-time Transport Control Protocol)來完成。本文就是采用RTP+RTCP的協(xié)議架構(gòu)來實現(xiàn)整體H.264視頻傳輸?shù)摹?/p>

前人已對實時流媒體傳輸做出過探索，如文獻［3］中就有提到針對H.264視頻流的組包方法，文獻［4］中將 AIMD(Additive Increase Multiplicative Decrease)算法引入到流媒體傳輸控制算法中。文獻［3］中提及的組包方式參考的是 RFC3894［8］標準，但沒有特別做自適應(yīng)組包處理，本文針對此處進行一些改進。文獻［5］［6］中在文獻［4］基礎(chǔ)上對 AIMD 標準算法進行了改進，在網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)空閑兩種狀態(tài)中加入一種網(wǎng)絡(luò)負載適中的狀態(tài)，并引入了平滑量，進一步縮短了實時傳輸處于擁塞下的時間。但由于RTCP包受到網(wǎng)絡(luò)帶寬的限制，需要有一定時間間隔才能發(fā)送，本文在此基礎(chǔ)上進一步改進，動態(tài)改變加性因子，進一步減小傳輸抖動的可能。

2 RTP數(shù)據(jù)組包實現(xiàn)

2.1 實時視頻傳輸模型

典型的實時傳輸模型由發(fā)送端和接收端兩部分組成，發(fā)送端與接收端可以分屬于不同的硬件平臺，傳輸模型如下圖1所示。傳輸發(fā)送端首先由攝像頭實時采集畫面，按照某種格式進行壓縮，本文采用H.264編碼標準，再將壓縮后的數(shù)據(jù)存進buffer中，最后調(diào)用RTP協(xié)議對buffer中的數(shù)據(jù)進行組包封裝，傳送至網(wǎng)絡(luò)中。同時，發(fā)送端還要對接收端傳遞過來的RTCP數(shù)據(jù)包進行分析，適時調(diào)整編碼碼率、發(fā)送速率及組包方式。在傳輸接收端，首先將接收到的RTP包進行整合形成可以解碼的一幀數(shù)據(jù)，最后調(diào)用播放器播放。在接收RTP數(shù)據(jù)包的同時，每隔固定的時間間隔回傳一次RTCP包，報告此時的網(wǎng)絡(luò)狀態(tài)。

本文不對發(fā)送端采集編碼及接收端解碼播放深入研究，而側(cè)重于對視頻媒體的傳輸控制及組包封裝。

圖1 典型H.264視頻流傳輸框圖

RFC3550［9］參考標準對 RTP格式做出了明確規(guī)定:RTP數(shù)據(jù)包由RTP包頭和負載兩部分組成，要求整個RTP包容量小于最大傳輸單元(MTU，Maximum Transmission Unit)，雖未對負載做出格式要求，但對RTP包頭的格式做出明確定義。H.264碼流組包的組包策略與RTP格式無太多關(guān)系，故不在此做過多論述，具體格式詳見文獻［9］。

2.2 自適應(yīng)RTP組包策略

H.264的編碼結(jié)構(gòu)在算法概念上分為兩層:視頻編碼層(VCL，Vedio Coding Layer)和網(wǎng)絡(luò)提取層(NAL，Network Abstraction Layer)。由于本文的工作重點放在了視頻流的傳輸上面，與視頻編碼關(guān)系不大，故不在此過多講述VCL層，而重點分析針對網(wǎng)絡(luò)提取層NAL而進行的組包策略。NAL層在語法概念上細分到最后是由一個個NALU(NAL Unit)單元組成的。RFC3984對H.264組包有如下幾種策略:

(1)單個NAL單元包:荷載中只包含一個NAL單元。

(2)聚合包:本類型用于聚合多個NAL單元到單個RTP荷載中。

(3)分片單元:用于分片單個NAL單元到多個RTP包。

在NALU的幀頭部分通過特定編碼方式加以區(qū)分是以上那種類型包，由于在實際的視頻流中，除了特定的參數(shù)集(pps(圖像參數(shù)集)、sps(序列參數(shù)集))以外，NALU都比較大，所以需要對其進行分片處理。文獻［7］中使用特定長度對其切割，具有簡單易行的特點，但這樣簡單分割會對整個幀的結(jié)構(gòu)進行破壞，文獻［3］中提及對于較大的NALU按GOP方式分割，但是這樣分割容易造成前幾個包載荷極滿，最后一個包載荷很少，在網(wǎng)絡(luò)帶寬壓力大的時候，丟包會造成解碼圖像出現(xiàn)較大面積馬賽克。對此本文提出一種綜合的組包算法。

首先通過RTCP回傳的數(shù)據(jù)進行分析，判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)，按網(wǎng)絡(luò)優(yōu)差分兩種策略:

(1)當(dāng)網(wǎng)絡(luò)良好時，判斷當(dāng)前要發(fā)送的NALU與下一個NALU的大小，如果兩個加起來也能夠通過一個RTP進行發(fā)送，則進行聚合包發(fā)送，但最多只能是兩個NALU，因為過多的綁定在一起，如若丟包，則解碼端會有馬賽克;如果兩個之和大于RTP的最大載荷，則分開單獨發(fā)送。若一個NALU不能由一個RTP包發(fā)送，則需要進行分片處理，但這里與文獻［3］不同，而是采用平均分片方式，即接下來幾個RTP包平均分攤NALU載荷，同時為了增加每個包的丟包魯棒性，要在每個RTP中復(fù)制圖像的參數(shù)集。除了兩個完整NALU單元可進行聚合分包外，其他數(shù)據(jù)包不允許同放在一個RTP包中。

(2)當(dāng)網(wǎng)絡(luò)壓力較大時，丟包率會增加，此時不允許任何NALU進行聚合分包，無論是否當(dāng)前與下一個NALU之和比一個RTP負載小，都必須分開組包，以確保解碼的有效性。

通過上述自適應(yīng)網(wǎng)絡(luò)的組包算法，既能夠充分利用當(dāng)前的網(wǎng)絡(luò)狀態(tài)，減少RTP包的數(shù)量，又能夠在網(wǎng)絡(luò)壓力較大時，減少丟包對解碼的影響，較前面文獻中組包算法有明顯優(yōu)勢。

3 擁塞控制算法改進

在實時傳輸系統(tǒng)中，RCTP協(xié)議的反饋機制被廣泛應(yīng)用。接收端周期性的向發(fā)送端發(fā)送數(shù)據(jù)包，該數(shù)據(jù)包包含丟包和分組延時抖動等重要信息。發(fā)送端可根據(jù)接收到的信息，分析當(dāng)前的網(wǎng)絡(luò)狀態(tài)，從而制定出相應(yīng)的組包和擁塞控制策略。目前基于探測性擁塞控制算法中最常用是AIMD算法，文獻［4］對其描述如下:

設(shè)返回的RTCP包包含丟包率為Ploss，它是發(fā)送端接收到兩次RTCP包的時間間隔內(nèi)所檢測到的丟包情況;IR:發(fā)送端的初試速率;MinR:最小速率;MaxR:最大速率;α:加性因子;β:乘性減小因子;Pmax最大丟包率。

根據(jù)接收到的RTCP包，輸出碼率R的調(diào)整規(guī)則是:

if(Ploss＜ =Pmax) //網(wǎng)絡(luò)空閑

R=min{(? +R)，MaxR};

else //網(wǎng)絡(luò)過載

R=max{(β*R)，MinR};

發(fā)送端根據(jù)接收端反饋的網(wǎng)絡(luò)狀態(tài)的參數(shù)，適當(dāng)?shù)恼{(diào)整發(fā)送速率。當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時，發(fā)送速率乘性減小，迅速降低對所需帶寬的要求;當(dāng)網(wǎng)絡(luò)空閑時，線性增加發(fā)送速率，提高發(fā)送的效率。但由于只有網(wǎng)絡(luò)空閑和網(wǎng)絡(luò)擁塞兩種狀態(tài)，發(fā)送端的發(fā)送速度總是在不斷變化，使得其抖動性很強，這不適合實時傳送數(shù)據(jù)。針對此文獻［5］和文獻［6］提出如下改進:

對丟包設(shè)置上下限:λmax、λmin，當(dāng)當(dāng)前的丟包超過了丟包上限值，乘性減小發(fā)送包速率，滿足當(dāng)前帶寬需求;當(dāng)當(dāng)前丟包低于丟包下限值，加性增加發(fā)送包速率，以提高發(fā)送效率;若丟包處于兩者之間時，不對發(fā)送速率做任何更改，設(shè)為網(wǎng)絡(luò)適中狀態(tài)。同時對丟包做平滑低通處理，令Ploss=(1-a)Ploss+aPnew

其中，a(0＜a＜1)為平滑系數(shù)，Pnew為最新一次的丟包。這樣，通過調(diào)整參數(shù)a的值就能夠有效的更改最新丟包對最終丟包的權(quán)重。具體規(guī)則如下:

if(Ploss＜λmin) //網(wǎng)絡(luò)空閑

R={min(R+ α)，Max R};

elseif(Ploss＞λmax) //網(wǎng)絡(luò)過載

R={min(R* β)，Min R};

else //網(wǎng)絡(luò)適中

R=R;

通過加入網(wǎng)絡(luò)適中狀態(tài)后，會很好的改觀發(fā)送端發(fā)送速率抖動問題，不會因為網(wǎng)絡(luò)中一點點的變化，而引起發(fā)送端巨大的調(diào)整。但由于受到接收端發(fā)送RTCP數(shù)據(jù)包有較長時間間隔的局限性，在兩次RTCP包中間，發(fā)送端會按照某種方式不停的更改發(fā)送速率，就有可能在第二次判定丟包時再次發(fā)現(xiàn)發(fā)送速率不合適，又需要對發(fā)送速率進行調(diào)整。同時，根據(jù)RFC3550標準，不能過分減小RTCP包發(fā)送間隔，因為它會占用整個網(wǎng)絡(luò)的帶寬，不利于RTP數(shù)據(jù)的傳輸。所以針對于此，本文在前人的基礎(chǔ)上進行改進，提出一種帶有記憶性質(zhì)的控制算法。

假設(shè)某一個時刻，網(wǎng)絡(luò)出現(xiàn)擁塞現(xiàn)象，記錄下此時發(fā)送端發(fā)送速率R0。在以后的系統(tǒng)運行中，如果網(wǎng)絡(luò)空閑并且發(fā)送速率遠小于R0，則以較快的速率增加發(fā)送速率;當(dāng)發(fā)送速率增加到快接近R0時，降低增加的速度，這樣會有效的降低網(wǎng)絡(luò)抖動的可能。具體描述如下:

R=R;

由上式可知，當(dāng)網(wǎng)絡(luò)處于空閑狀態(tài)，并且當(dāng)前傳輸速率與記憶中擁塞速率差距較大時會以一個常數(shù)線性增加，當(dāng)增加至快要接近記憶擁塞速率時會按比例減小增加加性因子，保證整個網(wǎng)絡(luò)狀態(tài)不至于跳動很厲害。這樣，當(dāng)前的網(wǎng)絡(luò)狀態(tài)處于空閑時，有控制的更改加性因子會進一步降低RTP數(shù)據(jù)包抖動的可能性。

4 總結(jié)

RTP/RTCP協(xié)議非常適合用于實時流媒體傳輸，其中RTP協(xié)議承擔(dān)對媒體數(shù)據(jù)的傳輸工作，RTCP協(xié)議則用來保證傳輸?shù)馁|(zhì)量。本文首先分析了RTP組包特點及標準組包方式，在此基礎(chǔ)上提出自適應(yīng)網(wǎng)絡(luò)的組包方式，再引入對AIMD算法的優(yōu)化，提出一種更能有效降低RTP數(shù)據(jù)包發(fā)送速率抖動的方法，提高了傳輸?shù)钠椒€(wěn)性。

［1］宋巖.流媒體技術(shù)及其應(yīng)用［J］.西安文理學(xué)院學(xué)報(自然科學(xué)版)，2007(10):90-92.

［2］胡書衛(wèi).H.264流媒體無線傳輸研究實現(xiàn)及其在嵌入式視頻監(jiān)控中的應(yīng)用［D］.上海:上海大學(xué)，2009.

［3］魏聰穎，牛建偉，吉海星，等.基于實時流媒體傳輸系統(tǒng)的H.264組包算法研究［J］.計算機科學(xué)，2007，34(8).

［4］Da peng Wu，Yiwei Thomas Hou，Wenwu Zhu，etal.On End-to-End Architecture for Transporting MPEG-4 Video over the Internet［J］.IEEE Trans on Circuits and Systems for Video Technology，2000，10(6).

［5］唐成.基于RTP的MPEG-4視頻傳輸研究［D］.西安建筑科技大學(xué)碩士學(xué)位論文，2004.

［6］董振亞.MPEG-4視頻流式傳輸擁塞控制研究與實現(xiàn)［D］.國防科技大學(xué)碩士學(xué)位論文，2003.

［7］Martini M G，Mazzotti M，Chiani M.Fixed-packet-Iength Transcoding for Error ResiIient Video Transmission over WCDMA Radio Links［C］.In:Proc.of Packet Video 2003，Nantes，ApriI 2003

［8］Wenger S，et al.RTP Payload Format for H.264 Video［S］.RFC3984，2005.

［9］Schulzrinne H，Casner S，F(xiàn)rederick R.RTP:A Transport Protocol for Real-Time Applications［S］.RFC3550，2003.