RTCP對媒體流的作用.doc_第1頁
RTCP對媒體流的作用.doc_第2頁
RTCP對媒體流的作用.doc_第3頁
RTCP對媒體流的作用.doc_第4頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

你可能用過VOD,印象最深的可能不是點播的樂趣,而是差勁的影音質(zhì)量,這里有片源的問題,也有影音制作、傳輸?shù)确矫娴膯栴}。新的流媒體應(yīng)用要求互聯(lián)網(wǎng)提供有服務(wù)質(zhì)量保證(QoS)的傳輸,在現(xiàn)有的網(wǎng)絡(luò)狀況下,為人們提供更高級的視聽享受。未來,流媒體的一個主要研究方向就是讓 RTCP協(xié)議作為RTP協(xié)議的一個重要補充,配合傳輸層協(xié)議,保證了流媒體的實時性特征,滿足了用戶在IP網(wǎng)上對QoS的需求。RTCP以反饋機制實現(xiàn)對媒體服務(wù)的QoS控制,充分利用現(xiàn)有的網(wǎng)絡(luò)資源,具有造價低、效果好的優(yōu)點,是當(dāng)前流媒體研究的一個熱點。 新的流媒體應(yīng)用要求互聯(lián)網(wǎng)提供有服務(wù)質(zhì)量(QoS)保證的傳輸,在現(xiàn)有網(wǎng)絡(luò)狀況下,能為人們帶來更高級的視聽享受?;ヂ?lián)網(wǎng)是一個基于包交換的通信網(wǎng),初期的設(shè)計目標(biāo)是要解決網(wǎng)絡(luò)的連通性和高可靠性,并沒有對實時性進行較多的考慮。為了在包交換網(wǎng)絡(luò)上提供有服務(wù)質(zhì)量保證的傳輸,必須解決預(yù)留資源、分類信息、時間同步等問題?;贗P的實時協(xié)議就是針對不同的側(cè)重點,對原有的協(xié)議族進行改造,來滿足實時通信的要求。這些協(xié)議主要分布在兩層:網(wǎng)絡(luò)層和傳輸層,屬于網(wǎng)絡(luò)層的有RSVP、DiffServ,屬于傳輸層的有RTP、RTCP、RTSP等。 RTP協(xié)議是互聯(lián)網(wǎng)上廣泛應(yīng)用的流媒體傳輸協(xié)議。通常運行于RTP/UDP模式下,而UDP協(xié)議本身不提供任何傳輸可靠性保證,傳輸層的控制功能主要由它的控制部分RTCP協(xié)議來實現(xiàn)。RTCP協(xié)議是RTP協(xié)議的控制部分。RTP用來傳遞實時多媒體數(shù)據(jù)信息,除了攜帶多媒體數(shù)據(jù)外,它還給出了所攜帶負(fù)載的時間戳、順序號等信息。為了可靠、高效地傳送實時數(shù)據(jù),RTP和RTCP必須配合使用。RTCP依靠反饋機制根據(jù)已經(jīng)發(fā)送的數(shù)據(jù)報文對帶寬進行調(diào)整、優(yōu)化,從而實現(xiàn)對流媒體服務(wù)的QoS控制。RTCP反饋可以直接作用于編碼、發(fā)送、甚至協(xié)議選擇環(huán)節(jié)。 作用于直播編碼 RTCP監(jiān)視RTP傳輸?shù)姆?wù)質(zhì)量,定期將RTCP報文發(fā)送給流媒體服務(wù)器。RTCP報文包括已發(fā)送數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的數(shù)量等統(tǒng)計資料,直播服務(wù)器可以利用這些信息動態(tài)地改變編碼質(zhì)量。 例如,對MPEG-4編碼來說,如果接收報告(RR)報文傳送丟包率大于20%,則改變了編碼碼率。這項應(yīng)用需要建立在多碼率應(yīng)用基礎(chǔ)之上才能收到更好的使用效果。 MPEG在視頻編碼壓縮上采取用三種類型的圖像:幀內(nèi)圖(Inta Picture,I)、預(yù)測圖(Predicted Pictures,P)和差補圖,即雙向預(yù)測圖(Bidirectional Prediction,B)。I幀可提供隨機存取的存放位置,但壓縮比不大;P幀可以由I幀或前面的P幀進行預(yù)測,壓縮比大于I幀;B幀是通過先前和后繼的信息進行預(yù)測,因此壓縮效果最顯著。 一個視頻流序列沿時間軸方向的順序排列如: I B B P B B P B B I B B P B B P. 如此的序列受兩個參數(shù)M和N約束。M為相鄰的I幀與P幀和相鄰的兩個P幀間的距離,上面的序列M為3;N為相鄰的I幀的距離,上面序列N為9。 根據(jù)MPEG-4碼流的特點,設(shè)計RTCP反饋直接作用于編碼參數(shù)M、N的調(diào)節(jié)。從直觀上來看,就是在改變編碼的碼率。 圖1給出了流媒體直播系統(tǒng)結(jié)構(gòu)圖。 在播放進行中動態(tài)地實現(xiàn)調(diào)整編碼碼率需要實現(xiàn)單文件多碼率技術(shù)。在現(xiàn)有的Linux流媒體服務(wù)器中,采用單服務(wù)器多編碼器的技術(shù)實現(xiàn)分級的多碼率服務(wù)。RTCP反饋實際作用于編碼器的選擇。在服務(wù)啟動之前,服務(wù)器給客戶端發(fā)送測試包,通過客戶端的RTCP反饋RR報文,選擇適合客戶端網(wǎng)絡(luò)狀況的編碼器。 服務(wù)建立之后,在數(shù)據(jù)傳送過程中還不能實現(xiàn)不同編碼器之間的切換。這時候RTCP的統(tǒng)計報文通過有效調(diào)節(jié)傳輸速率控制流媒體服務(wù)的QoS。 作用于數(shù)據(jù)發(fā)送環(huán)節(jié) 對于點播服務(wù)器來說,大量視頻數(shù)據(jù)已經(jīng)完成編碼。RTCP反饋信息就可以改變數(shù)據(jù)發(fā)送速率,或?qū)γ襟w數(shù)據(jù)進行選擇性丟棄。 圖2顯示的是流媒體點播系統(tǒng)框架示意圖。當(dāng)RR報文傳送丟包率、接收包總數(shù)等統(tǒng)計信息超過臨界值,如丟包率超過20%,則改變發(fā)包速率。正常情況下,傳送一個700Kbps左右的媒體文件,服務(wù)器每秒傳送大于700個左右IP報文。一旦解析發(fā)現(xiàn)接收端丟包現(xiàn)象嚴(yán)重(超過20%),則發(fā)包速率降低。設(shè)定接收端緩沖2秒數(shù)據(jù),當(dāng)(oldrate - newrate) * time 2 秒,則播放出現(xiàn)不連續(xù),甚至停止。調(diào)整發(fā)包速率的方法雖然在一定程度上能夠緩解暫時的網(wǎng)絡(luò)擁塞造成的影響,但是卻不能從本質(zhì)上減輕網(wǎng)絡(luò)負(fù)載,緩解擁塞狀況。更為有效的辦法是在服務(wù)器端就對數(shù)據(jù)包進行有選擇性的丟棄。 用MPEG-4壓縮多媒體數(shù)據(jù), I幀數(shù)據(jù)相對獨立,是解碼時必須的數(shù)據(jù),因此應(yīng)盡量保留;P幀需要與相鄰的I幀配合,進行運動圖像恢復(fù),重要程度僅次于I幀;P幀的每幀數(shù)據(jù)量最少,一般可為I幀的1/10,但是壓縮的多媒體數(shù)據(jù)中大量的都是P幀,因此它的總數(shù)據(jù)量并不少。包含P幀的IP數(shù)據(jù)報文相對較小,更容易在網(wǎng)絡(luò)上造成擁塞。因此當(dāng)監(jiān)測到丟包率升高時,服務(wù)器按照一定規(guī)則丟棄一些P幀。這樣發(fā)送到網(wǎng)絡(luò)上的P幀會大大減少,有效地緩解了網(wǎng)絡(luò)負(fù)荷。對于按服務(wù)流量進行計費的用戶來說,用這種方法可使服務(wù)質(zhì)量和流量能基本一致,是一種比較合理的做法。 作用于傳輸協(xié)議協(xié)商 1. 協(xié)商策略 RTP協(xié)議有與具體的承載網(wǎng)絡(luò)分離的特點。因此在理論上底層傳輸協(xié)議既可以用TCP協(xié)議,也可以用UDP協(xié)議。TCP/IP網(wǎng)絡(luò)傳輸結(jié)構(gòu)無疑是目前最成熟、最可靠、應(yīng)用最廣泛的傳輸方式,但在目前的流媒體應(yīng)用中,幾乎所有的應(yīng)用在網(wǎng)絡(luò)傳輸層都使用RTP/UDP。 UDP協(xié)議有傳輸效率高的特點。這是因為UDP不需要建立連接,啟動時間短,傳輸時延短。同時UDP協(xié)議也有它無法克服的弊端:首先是可靠性無法保障;其次,RTCP報文的傳輸雖然與RTP使用不同的端口,但是RTCP的反饋數(shù)據(jù)報文本身基于UDP,其反饋速度直接受到網(wǎng)絡(luò)環(huán)境的影響,其反饋控制效果不理想;最后,RTCP協(xié)議本身比較新,擁塞控制算法不是很完善。 TCP協(xié)議相對比較成熟,在擁塞控制、網(wǎng)絡(luò)安全方面有較大優(yōu)勢。但是與UDP協(xié)議相比,它的效率相對比較低,啟動時間長,實現(xiàn)起來也更復(fù)雜。 TCP協(xié)議是基于連接的傳輸協(xié)議,網(wǎng)絡(luò)開銷大,因此可以在網(wǎng)絡(luò)狀況較好的情況下選用。相反,在網(wǎng)絡(luò)條件不是很好的情況下,如帶寬較窄,發(fā)生擁塞,就可以選用相對比較簡潔的UDP協(xié)議。協(xié)商協(xié)議過程如圖3所示。 2.具體實現(xiàn) 在服務(wù)建立之前,首先由服務(wù)器發(fā)送測試數(shù)據(jù),如碼率3Mbps。由于RTCP協(xié)議專用于用戶規(guī)模很小的情況下,發(fā)送RTCP報文間隔至少為5秒,第一個RTCP包發(fā)送間隔為1/2最小間隔,即2.5秒。這是一個用戶無法接受的啟動時間,因此需要對RTCP協(xié)議進行相應(yīng)的修改。 TCP協(xié)議的超時定時器一般設(shè)為200ms,而這也是一個用戶所能接受的延遲。以3Mbps碼率發(fā)送測試數(shù)據(jù)200ms,當(dāng)發(fā)送測試數(shù)據(jù)結(jié)束時,接收端立即發(fā)送包含統(tǒng)計信息的RR報文給服務(wù)器。當(dāng)丟包超過某個閾值時,服務(wù)器還是選用傳統(tǒng)的UDP協(xié)議進行傳輸。否則,選用TCP協(xié)議進行傳輸。 3. 解決的問題 要實現(xiàn)RTP/TCP傳輸模式,必須解決以下問題:如何將獨立的RTP數(shù)據(jù)報文完整地傳送到客戶端,原因是與UDP相比,TCP傳輸機制以數(shù)據(jù)流的格式傳輸,數(shù)據(jù)報文無邊界,如果不加以控制,以恒定的長度從TCP協(xié)議棧收取RTP數(shù)據(jù)報文,肯定無法得到獨立的RTP數(shù)據(jù)報文并產(chǎn)生報文丟失。 將TCP數(shù)據(jù)流分段的方法有許多,為了盡量提高傳輸效率,這里采用修改上層RTP協(xié)議的方法來實現(xiàn)TCP數(shù)據(jù)報文的分段和拼裝,如圖4所示。 在TCP承載RTP協(xié)議的情況下,所有的數(shù)據(jù)報文以流的方式順序地發(fā)送,在客戶端也依次順序被接收。因此RTP報文頭的Sequence Number 數(shù)據(jù)項就失去了原來設(shè)計的意義。改造RTP協(xié)議的報文頭,在Sequence Number數(shù)據(jù)項的位置寫入數(shù)據(jù)包的尺寸。這樣就可以先接收RTP包頭,然后根據(jù)解析出來的包長度再接收RTP數(shù)據(jù)部分。 實現(xiàn)拼裝的工作主要在客戶端,接收RTP數(shù)據(jù)后,如果檢測到所接收數(shù)據(jù)比實際RTP數(shù)據(jù)報文長度小,客戶端將繼續(xù)循環(huán)接收所缺少長度的數(shù)據(jù)報文,進行拼接,直至接收到完整的RTP數(shù)據(jù)報文后,再對報文進行分析和解碼。這一過程得以實現(xiàn)的前提是TCP的可靠傳輸機制。 在RTP/TCP模式下,傳輸控制功能主要由TCP協(xié)議完成,RTCP協(xié)議本身的許多冗余功能應(yīng)該刪除。 在RTP/UDP傳輸模式下,RTCP數(shù)據(jù)控制報文約占報文總數(shù)量的5%,而發(fā)送報告(SR)和接收報告(RR)數(shù)據(jù)報文占所有RTCP數(shù)據(jù)控制報文總量的99%。因此,在RTP/TCP傳輸模式下,由于RTCP只保留了很少的控制功能,將繼續(xù)使用UDP協(xié)議作為底層傳輸協(xié)議,其報文數(shù)量不會對網(wǎng)絡(luò)負(fù)載造成影響。 測試結(jié)果 測試環(huán)境為目前正在開發(fā)的Linux流媒體服務(wù)器系統(tǒng),服務(wù)器片源為基于MPEG-4編碼的可流化視頻文件。服務(wù)器端采用Linux操作系統(tǒng)和10M/100M自適應(yīng)網(wǎng)卡;客戶端采用Windows 2000 Professional操作系統(tǒng)和10M/100M自適應(yīng)網(wǎng)卡。 作用于直播編碼系統(tǒng) 真正意義上的平滑碼率調(diào)節(jié)需要在單文件多碼率壓縮的基礎(chǔ)上實現(xiàn)。現(xiàn)有系統(tǒng)采用多編碼器實現(xiàn)分級多碼率服務(wù)。RTCP的反饋作用實際應(yīng)用于編碼器的選擇,在局域網(wǎng)中試驗運行,可以充分利用帶寬資源,并能保證較高的服務(wù)質(zhì)量。 作用于點播系統(tǒng)發(fā)包環(huán)節(jié) 因為發(fā)生網(wǎng)絡(luò)擁塞一般為暫時網(wǎng)絡(luò)行為,采用降低發(fā)包速率的方法,在局域網(wǎng)環(huán)境下試驗運行,基本能夠滿足QoS的要求,圖像流暢。采用根據(jù)不同的數(shù)據(jù)類型進行選擇性丟棄的方法,算法比較復(fù)雜,服務(wù)器負(fù)荷較重,在傳送高碼率媒體數(shù)據(jù)時性能優(yōu)于調(diào)整發(fā)包率的方法。

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論