王曉西，駱新全

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

1 引言

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

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

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

2.1 實(shí)時(shí)視頻傳輸模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 擁塞控制算法改進(jìn)

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

設(shè)返回的RTCP包包含丟包率為Ploss，它是發(fā)送端接收到兩次RTCP包的時(shí)間間隔內(nèi)所檢測(cè)到的丟包情況;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ā)生擁塞時(shí)，發(fā)送速率乘性減小，迅速降低對(duì)所需帶寬的要求;當(dāng)網(wǎng)絡(luò)空閑時(shí)，線性增加發(fā)送速率，提高發(fā)送的效率。但由于只有網(wǎng)絡(luò)空閑和網(wǎng)絡(luò)擁塞兩種狀態(tài)，發(fā)送端的發(fā)送速度總是在不斷變化，使得其抖動(dòng)性很強(qiáng)，這不適合實(shí)時(shí)傳送數(shù)據(jù)。針對(duì)此文獻(xiàn)［5］和文獻(xiàn)［6］提出如下改進(jìn):

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

其中，a(0＜a＜1)為平滑系數(shù)，Pnew為最新一次的丟包。這樣，通過調(diào)整參數(shù)a的值就能夠有效的更改最新丟包對(duì)最終丟包的權(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)后，會(huì)很好的改觀發(fā)送端發(fā)送速率抖動(dòng)問題，不會(huì)因?yàn)榫W(wǎng)絡(luò)中一點(diǎn)點(diǎn)的變化，而引起發(fā)送端巨大的調(diào)整。但由于受到接收端發(fā)送RTCP數(shù)據(jù)包有較長(zhǎng)時(shí)間間隔的局限性，在兩次RTCP包中間，發(fā)送端會(huì)按照某種方式不停的更改發(fā)送速率，就有可能在第二次判定丟包時(shí)再次發(fā)現(xiàn)發(fā)送速率不合適，又需要對(duì)發(fā)送速率進(jìn)行調(diào)整。同時(shí)，根據(jù)RFC3550標(biāo)準(zhǔn)，不能過分減小RTCP包發(fā)送間隔，因?yàn)樗鼤?huì)占用整個(gè)網(wǎng)絡(luò)的帶寬，不利于RTP數(shù)據(jù)的傳輸。所以針對(duì)于此，本文在前人的基礎(chǔ)上進(jìn)行改進(jìn)，提出一種帶有記憶性質(zhì)的控制算法。

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

R=R;

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

4 總結(jié)

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

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

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

［3］魏聰穎，牛建偉，吉海星，等.基于實(shí)時(shí)流媒體傳輸系統(tǒng)的H.264組包算法研究［J］.計(jì)算機(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視頻流式傳輸擁塞控制研究與實(shí)現(xiàn)［D］.國(guó)防科技大學(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.