亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        一種流媒體傳輸方法研究

        2013-09-20 05:31:22王曉西駱新全
        關(guān)鍵詞:空閑接收端數(shù)據(jù)包

        王曉西,駱新全

        (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.

        猜你喜歡
        空閑接收端數(shù)據(jù)包
        恩賜
        詩選刊(2023年7期)2023-07-21 07:03:38
        基于擾動觀察法的光通信接收端優(yōu)化策略
        頂管接收端脫殼及混凝土澆筑關(guān)鍵技術(shù)
        一種設(shè)置在密閉結(jié)構(gòu)中的無線電能傳輸系統(tǒng)
        新能源科技(2021年6期)2021-04-02 22:43:34
        基于多接收線圈的無線電能傳輸系統(tǒng)優(yōu)化研究
        “鳥”字謎
        小讀者之友(2019年9期)2019-09-10 07:22:44
        SmartSniff
        彪悍的“寵”生,不需要解釋
        WLAN和LTE交通規(guī)則
        CHIP新電腦(2016年3期)2016-03-10 14:09:48
        基于Libpcap的網(wǎng)絡(luò)數(shù)據(jù)包捕獲器的設(shè)計與實現(xiàn)
        97女厕偷拍一区二区三区| 精品少妇一区二区三区视频| 国产欧美日韩综合一区二区三区| 女女同性av一区二区三区免费看 | 免费一区二区三区视频狠狠| 蜜桃成人精品一区二区三区| av大全亚洲一区二区三区| 四虎影视永久在线观看| 欧美深夜福利网站在线观看| 色综久久综合桃花网国产精品| 性av一区二区三区免费| 琪琪的色原网站| 久久精品国产亚洲AⅤ无码| 国产精品一级黄色大片| 精品日韩一级免费视频| 中国农村妇女hdxxxx| 国产极品美女高潮抽搐免费网站| av网站在线观看二区| 亚洲综合国产成人丁香五月激情 | 成人无码h真人在线网站| 久久夜色精品国产亚洲av老牛 | 无限看片在线版免费视频大全| 97碰碰碰人妻视频无码| 日韩精品视频高清在线| 成人综合网站| 国产精品女视频一区二区| av网站免费在线不卡| 真人做爰试看120秒| 日韩电影一区二区三区| 国内视频一区| 青青草视频是针对华人| 日韩精品内射视频免费观看| 欧美在线a| 国产精品视频白浆免费看| 亚洲夜夜性无码| 亚洲欧洲精品成人久久曰影片| 香蕉久久夜色精品国产| 极品粉嫩小仙女高潮喷水操av| 精品国产一区av天美传媒| 国产va精品免费观看| 亚洲美女主播内射在线|