RTCP對媒體流的作用

《RTCP對媒體流的作用》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、你可能用過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)前流媒體研究的一個熱點。新的流

2、媒體應(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

3、協(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é)

4、。作用于直播編碼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)圖（IntaPicture，I）、預(yù)測圖（PredictedPictures，P）和差補圖，即雙向預(yù)測圖（Bidi

5、rectionalPrediction，B）。I幀可提供隨機存取的存放位置，但壓縮比不大；P幀可以由I幀或前面的P幀進行預(yù)測，壓縮比大于I幀；B幀是通過先前和后繼的信息進行預(yù)測，因此壓縮效果最顯著。一個視頻流序列沿時間軸方向的順序排列如：IBBPBBPBBIBBPBBP......如此的序列受兩個參數(shù)M和N約束。M為相鄰的I幀與P幀和相鄰的兩個P幀間的距離，上面的序列M為3；N為相鄰的I幀的距離，上面序列N為9。根據(jù)MPEG-4碼流的特點，設(shè)計RTCP反饋直接作用于編碼參數(shù)M、N的調(diào)節(jié)。從直觀上來看，就是在改變

6、編碼的碼率。圖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)完

7、成編碼。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ò)擁

8、塞造成的影響，但是卻不能從本質(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ù)