RTCP對媒體流的作用.doc

你可能用過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ā)包率的方法。