專利名稱：基于實時傳輸協(xié)議和傳輸控制協(xié)議的流媒體傳輸實現(xiàn)方法
技術領域：
本發(fā)明屬于計算機多媒體技術領域，特別涉及流媒體傳輸方法。
流媒體技術的流式傳輸方式，實現(xiàn)了聲音、影像或動畫等多媒體由音視頻服務器向用戶計算機的連續(xù)、實時傳送，用戶不必等到整個文件全部下載完畢，而只需經(jīng)過幾秒或十數(shù)秒的啟動延時即可進行觀看。流媒體技術不僅使啟動延時成十倍、百倍地縮短，而且不需要太大的緩存容量，節(jié)省用戶資源。流媒體適用于各種網(wǎng)絡帶寬環(huán)境(14.4Kbps-10Mbps)，因此，流媒體在互聯(lián)網(wǎng)上的應用也十分廣泛，如多媒體新聞發(fā)布、在線直播、網(wǎng)絡視頻廣告、電子商務、視頻點播、遠程教育、網(wǎng)絡電臺、實時視頻會議等。在寬帶環(huán)境下，流媒體不僅可以進行單向流式傳輸，還能夠提供以互動技術為基礎的交互網(wǎng)絡服務，如互動游戲、三維動畫、互動培訓等等?；ヂ?lián)網(wǎng)技術的發(fā)展決定了流媒體市場的廣闊前景，目前，流媒體技術的應用正處于高速持續(xù)增長時期。
實時傳輸協(xié)議RTP(Real time Transport Protocol)是最典型、最廣泛的服務于流媒體數(shù)據(jù)傳輸?shù)囊环N網(wǎng)絡傳輸層協(xié)議，它包括兩部分RTP數(shù)據(jù)傳輸協(xié)議和RTCP傳輸控制協(xié)議。RTP協(xié)議本身主要是為流媒體提供時間信息和實現(xiàn)流同步，但是，并不能實現(xiàn)完整的網(wǎng)絡數(shù)據(jù)傳輸功能。通常情況下，RTP配合底層用戶數(shù)據(jù)報協(xié)議(UDP協(xié)議)完成數(shù)據(jù)傳輸。
RTP/UDP模式的主要優(yōu)勢在于傳輸延遲時間較短，音視頻流能夠較好的匹配。同時，UDP傳輸?shù)牟豢煽啃灾饕揽繉崟r傳輸控制協(xié)議RTCP服務來彌補。RTCP周期的傳送RTCP數(shù)據(jù)報文，監(jiān)視RTP傳輸?shù)姆召|(zhì)量。在RTCP報文中，含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，服務器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型，實現(xiàn)流量控制和擁塞控制服務。
RTP/UDP傳輸模式存在以下不足之處首先，UDP協(xié)議本身不提供任何傳輸可靠性保證，傳輸層的可靠性完全依靠RTCP協(xié)議，RTCP協(xié)議為松散控制方式，數(shù)據(jù)發(fā)送方只能依靠反饋機制根據(jù)已經(jīng)發(fā)送的數(shù)據(jù)報文對帶寬進行調(diào)整、優(yōu)化，不能真正解決不可靠性，不能確保每一個數(shù)據(jù)報文的傳送。
其次，RTCP報文的傳輸雖然與RTP使用不同的端口，但是RTCP的反饋數(shù)據(jù)報文本身基于UDP，其反饋速度直接受到網(wǎng)絡環(huán)境的影響，其反饋控制效果不理想。
最后，RTCP協(xié)議本身比較新，其擁塞控制算法與TCP相比，還有很大差距。因此，在龐大的音視頻數(shù)據(jù)傳輸過程中，流媒體傳輸?shù)目煽啃耘c基于TCP傳輸協(xié)議的其它應用相比，還有很大差距。
本發(fā)明提出的一種基于實時傳輸協(xié)議(RTP)和傳輸控制協(xié)議(TCP)的流媒體傳輸實現(xiàn)方法，包括以下步驟1)流媒體發(fā)送端對TCP協(xié)議進行配置，關閉Nagle算法，使TCP數(shù)據(jù)報文嚴格按照順序發(fā)送；2)刪除RTP協(xié)議中的實時傳輸控制協(xié)議(RTCP)的傳輸控制功能，以使在流媒體發(fā)送端和接收端禁止相互傳送發(fā)送報告SR和接收報告RR；3)重新定義RTP協(xié)議數(shù)據(jù)報文頭部參數(shù)，修改序列號(Sequence Number)參數(shù)空間內(nèi)容，使其負載內(nèi)容由序列號改為數(shù)據(jù)報文長度(Length)；4)流媒體發(fā)送端按照修改后的RTP數(shù)據(jù)報文頭部格式發(fā)送流媒體數(shù)據(jù)報文；5)流媒體接收端根據(jù)RTP數(shù)據(jù)報文頭部參數(shù)提供的數(shù)據(jù)報文長度對TCP報文中的RTP報文進行分段接收；6)流媒體接收端根據(jù)RTP數(shù)據(jù)報文頭部參數(shù)提供的數(shù)據(jù)報文長度，對接收到的不完整的RTP報文進行拼裝，以形成完整的RTP數(shù)據(jù)報文；7)流媒體接收端按順序?qū)ν暾腞TP報文中的數(shù)據(jù)進行解碼。
所說的對接收到的不完整的RTP報文進行拼裝的方法可為如果檢測到所接收數(shù)據(jù)比實際RTP數(shù)據(jù)報文長度小，將繼續(xù)循環(huán)接收所缺少長度的數(shù)據(jù)報文，直至檢測到所接收數(shù)據(jù)與實際RTP數(shù)據(jù)報文長度相等，進行拼接，即為完整的RTP數(shù)據(jù)報文。
本發(fā)明的工作原理TCP/IP網(wǎng)絡傳輸結(jié)構(gòu)是目前最成熟，最可靠，應用最廣泛的傳輸方式，本發(fā)明在RTP/TCP模式下，使用TCP協(xié)議負載RTP數(shù)據(jù)報文，流媒體的傳輸可靠性完全交給底層的TCP協(xié)議來實現(xiàn)，TCP協(xié)議是目前應用最廣，最成熟的傳輸層協(xié)議。TCP協(xié)議采用基于窗口的(window-based)端到端(end-to-end)的算法提供可靠的擁塞控制機制，其算法也比較成熟，主要有兩種Tahoe和Reno，分別對通過重復應答所判斷出的丟包現(xiàn)象進行不同的處理，后來隨著網(wǎng)絡技術的發(fā)展在Reno算法的基礎上出現(xiàn)了New-Reno算法和Sack算法。這些算法都在特定的環(huán)境中有效的保證傳輸?shù)目煽啃浴?br> 要實現(xiàn)RTP/TCP傳輸模式，必須解決以下問題如何將獨立的RTP數(shù)據(jù)報文完整地傳送到接收端，原因是TCP傳輸機制以數(shù)據(jù)流的格式傳輸，數(shù)據(jù)報文無邊界，如果不加以控制，無法得到獨立的RTP數(shù)據(jù)報文，并產(chǎn)生嚴重的報文丟失。
本發(fā)明采用修改上層RTP協(xié)議的方法來實現(xiàn)TCP數(shù)據(jù)報文的分段和拼裝。
1.RTP數(shù)據(jù)報文的分段為了將RTP數(shù)據(jù)報文分段，必須在RTP報文頭部增加包含RTP數(shù)據(jù)報文長度的參數(shù)，本發(fā)明利用RTP原報文頭部的參數(shù)序列號(Sequence Number)傳輸RTP報文長度信息。原因如下使用TCP負載RTP數(shù)據(jù)報文后，發(fā)送端將按照數(shù)據(jù)報文的順序依次發(fā)送，在接收端，RTP數(shù)據(jù)報文將被逐一進行確認，并按照發(fā)送的順序依次被接收，因此，RTP/TCP傳輸模式下，RTP數(shù)據(jù)報文的傳輸是嚴格有序的。RTP協(xié)議規(guī)定，RTP報文頭部參數(shù)序列號(Sequence Number)用于數(shù)據(jù)報文的重新排序，原因是在RTP/UDP模式下，UDP協(xié)議無法按照順序依次傳送報文。因此，在RTP/TCP模式下，RTP報文頭部參數(shù)序列號(SequenceNumber)已經(jīng)失去意義，因此可以修改Sequence Number參數(shù)內(nèi)容，用Sequence Number參數(shù)負載RTP數(shù)據(jù)報文的長度，實現(xiàn)報文分段。此外，Sequence Number參數(shù)在RTP報文頭部占用兩個字節(jié)空間，足以用于傳輸RTP數(shù)據(jù)報文的長度。
2.RTP數(shù)據(jù)報文的拼裝使用TCP報文負載RTP數(shù)據(jù)報文所面臨的第二個問題是RTP數(shù)據(jù)報文的拼裝，拼裝的目的是根據(jù)RTP數(shù)據(jù)報文的長度參數(shù)，把接收到的不完整的RTP數(shù)據(jù)報文進行拼裝，保證每一個RTP數(shù)據(jù)報文的完整性。
在對RTP報文進行分段后，接收端根據(jù)RTP報文頭部參數(shù)的RTP長度從TCP協(xié)議棧讀取數(shù)據(jù)，但是接收函數(shù)并不能保證讀取的數(shù)據(jù)報文長度一定是參數(shù)規(guī)定的所需長度，例如報文分段或緩沖區(qū)溢出都可能導致RTP數(shù)據(jù)報文不完整。如果TCP協(xié)議棧中的RTP數(shù)據(jù)不完整，接收函數(shù)所接收到的數(shù)據(jù)報文實際長度將小于RTP數(shù)據(jù)報文長度，對這樣的報文如果不進行拼裝，將導致上層音視頻解碼錯誤，甚至接收端的崩潰。
實現(xiàn)拼裝的工作主要在流媒體接收端，接收端如果檢測到所接收數(shù)據(jù)比實際RTP數(shù)據(jù)報文長度小，將繼續(xù)循環(huán)接收所缺少長度的數(shù)據(jù)報文，進行拼接，直至接收到完整的RTP數(shù)據(jù)報文，這一過程得以實現(xiàn)的前提是TCP的可靠傳輸機制。
3.刪除RTCP多余的傳輸控制功能在RTP/TCP模式下，傳輸控制功能主要由TCP協(xié)議完成，RTP中的RTCP協(xié)議本身的許多冗余功能應該刪除。RTCP數(shù)據(jù)報文分為5種(1)SR發(fā)送報告，當前活動發(fā)送者發(fā)送、接收統(tǒng)計。(2)RR接收報告，非活動發(fā)送者接收統(tǒng)計。(3)SDES源描述項，包括CNAME。(4)BYE表示結(jié)束。(5)APP應用特定函數(shù)。RTCP執(zhí)行四大功能提供數(shù)據(jù)發(fā)布的質(zhì)量反饋，發(fā)送帶有稱作規(guī)范名字的RTP源持久傳輸層標識，提供用于控制RTCP包數(shù)量的數(shù)量用語和傳送最小連接控制信息。
使用TCP協(xié)議實現(xiàn)控制功能后，RTCP協(xié)議的最主要功能提供數(shù)據(jù)發(fā)布的質(zhì)量反饋已經(jīng)沒有意義，必須進行刪除，因此，發(fā)送端和接收端的發(fā)送報告SR和接收報告RR將被刪除。
在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)絡負載造成影響。
4.TCP協(xié)議中Nagle算法的關閉TCP協(xié)議中的Nagle算法規(guī)定一個啟發(fā)式的避免發(fā)送特別小的IP報文的算法。Nagle算法通過將未確認的數(shù)據(jù)存入緩沖區(qū)直到蓄足一個包一起發(fā)送的方法，來減少主機發(fā)送的零碎小數(shù)據(jù)報文的數(shù)目。對于流媒體應用來說，接收端必須按照多媒體數(shù)據(jù)的順序依次播放，因此，這種算法將降低系統(tǒng)性能。Nagle算法的超時定時器為200ms，在接收端，由于播放程序?qū)CP數(shù)據(jù)，即RTP數(shù)據(jù)報文的需求是實時的，因此接收程序很有可能在200ms的時間內(nèi)清空接收緩沖區(qū)。導致播放不連續(xù)，甚至接收數(shù)據(jù)報文的不完整。因此，在數(shù)據(jù)傳送之前，應當將Nagle算法關閉。
本發(fā)明的特點及效果本發(fā)明對RTP實時傳輸協(xié)議進行修改，將RTP數(shù)據(jù)報文頭部參數(shù)進行修改，用序列號(Sequence Number)參數(shù)空間存儲RTP報文長度信息，實現(xiàn)RTP數(shù)據(jù)報文的分段，并配合底層的TCP協(xié)議，實現(xiàn)流媒體數(shù)據(jù)的可靠傳輸。同時，為了保證傳輸效率，對RTCP和TCP協(xié)議進行了優(yōu)化配置。
使用本發(fā)明的RTP/TCP傳輸模式進行流媒體傳輸，與傳統(tǒng)的RTP/UDP傳輸模式相比，在傳輸?shù)目煽啃苑矫嬗泻艽髢?yōu)勢。
2)修改發(fā)送端和接收端RTCP傳輸控制協(xié)議，將負載、處理發(fā)送報告SR和接收報告RR的功能刪除。
3)流媒體發(fā)送端對RTP報文頭部參數(shù)序列號(Sequence Number)內(nèi)容進行修改，使其負載內(nèi)容由序列號改為數(shù)據(jù)報文長度Length。
4)流媒體發(fā)送端按照修改后的RTP數(shù)據(jù)報文頭部格式發(fā)送數(shù)據(jù)報文。
5)媒體接收端根據(jù)RTP報文頭部參數(shù)提供的數(shù)據(jù)報文長度(Length)對RTP數(shù)據(jù)報文進行分段接收。
6)流媒體接收端根據(jù)RTP報文頭部參數(shù)提供的數(shù)據(jù)報文長度，對接收到的RTP報文進行檢驗，如果檢測到所接收數(shù)據(jù)比實際RTP數(shù)據(jù)報文長度小，將繼續(xù)循環(huán)接收所缺少長度的數(shù)據(jù)報文，直至檢測到所接收數(shù)據(jù)與實際RTP數(shù)據(jù)報文長度相等，進行拼接，即為完整的RTP數(shù)據(jù)報文。
7)流媒體接收端順序?qū)ν暾腞TP報文數(shù)據(jù)進行解碼。3.運行結(jié)果本實施例在局域網(wǎng)環(huán)境中用視頻點播的方式分別對RTP/TCP流媒體傳輸模式進行了運行，監(jiān)視服務器發(fā)送狀況，播放效果和傳輸層三方面的情況。
視頻點播碼率為512kbps的MPEG4流媒體文件，接收端播放畫面流暢，圖像清晰。視頻點播碼率為1100kbps的MPEG4流媒體文件，接收端在整個播放過程中圖像流暢，清晰，接收端的跟蹤數(shù)據(jù)顯示，沒有任何報文丟失現(xiàn)象，也沒有因為TCP傳輸效率和控制機制導致的圖像停頓、跳動現(xiàn)象，服務器端的跟蹤數(shù)據(jù)顯示，流媒體數(shù)據(jù)并沒有連續(xù)發(fā)送，而是在TCP控制機制的作用下發(fā)送速率有較大波動，甚至短時間的停頓，保證了傳輸?shù)目煽啃浴?br> 本實施例環(huán)境服務器端的硬件配置及操作系統(tǒng)CPUIntel PIII 1GHz內(nèi)存128M網(wǎng)卡10M/100M自適應操作系統(tǒng)RedHat7.1 Linux Server接收端的配置及操作系統(tǒng)CPUIntel PIII 800MHz內(nèi)存128M網(wǎng)卡10M/100M自適應操作系統(tǒng)Windows2000 Professional軟件環(huán)境實現(xiàn)本實施例方法的服務器和接收端的Linux流媒體視頻服務器系統(tǒng)軟件，提供RTP/TCP和RTP/UDP兩種流媒體傳輸模式。為了保證兩種傳輸模式的可比較性，兩種傳輸模式軟件僅傳輸層實現(xiàn)方式有所不同。服務器片源為基于MPEG4編碼的可流化視頻文件，碼率范圍為110Kpbs-1100Kpbs。
本實施例實現(xiàn)了流媒體傳輸層RTP/TCP模式的設計，證明了RTP/TCP傳輸模式在流媒體傳輸可靠性方面的優(yōu)勢。
權(quán)利要求
1.一種基于實時傳輸協(xié)議(RTP)和傳輸控制協(xié)議(TCP)的流媒體傳輸實現(xiàn)方法，包括以下步驟1)流媒體發(fā)送端對TCP協(xié)議進行配置，關閉Nagle算法，使TCP數(shù)據(jù)報文嚴格按照順序發(fā)送；2)刪除RTP協(xié)議中的實時傳輸控制協(xié)議的傳輸控制功能，以使在流媒體發(fā)送端和接收端禁止相互傳送發(fā)送報告和接收報告；3)重新定義RTP協(xié)議數(shù)據(jù)報文頭部參數(shù)，修改序列號參數(shù)空間內(nèi)容，使其負載內(nèi)容由序列號改為數(shù)據(jù)報文長度；4)流媒體發(fā)送端按照修改后的RTP數(shù)據(jù)報文頭部格式發(fā)送流媒體數(shù)據(jù)報文；5)流媒體接收端根據(jù)RTP數(shù)據(jù)報文頭部參數(shù)提供的數(shù)據(jù)報文長度對TCP報文中的RTP報文進行分段接收；6)流媒體接收端根據(jù)RTP數(shù)據(jù)報文頭部參數(shù)提供的數(shù)據(jù)報文長度，對接收到的不完整的RTP報文進行拼裝，以形成完整的RTP數(shù)據(jù)報文；7)流媒體接收端按順序?qū)ν暾腞TP報文中的數(shù)據(jù)進行解碼。
2.如權(quán)利要求1所述的基于實時傳輸協(xié)議和傳輸控制協(xié)議的流媒體傳輸實現(xiàn)方法，其特征在于，所說的對接收到的不完整的RTP報文進行拼裝的方法為如果檢測到所接收數(shù)據(jù)比實際RTP數(shù)據(jù)報文長度小，將繼續(xù)循環(huán)接收所缺少長度的數(shù)據(jù)報文，直至檢測到所接收數(shù)據(jù)與實際RTP數(shù)據(jù)報文長度相等，進行拼接，即為完整的RTP數(shù)據(jù)報文。
全文摘要
本發(fā)明屬于計算機多媒體技術領域，涉及基于實時傳輸協(xié)議和傳輸控制協(xié)議的流媒體傳輸實現(xiàn)方法，包括流媒體發(fā)送端關閉Nagle算法，刪除RTP協(xié)議中的實時傳輸控制協(xié)議的傳輸控制功能，修改序列號參數(shù)空間內(nèi)容，使其負載內(nèi)容由序列號改為數(shù)據(jù)報文長度；發(fā)送端按照修改后的RTP數(shù)據(jù)報文頭部格式發(fā)送流媒體數(shù)據(jù)報文；接收端根據(jù)RTP數(shù)據(jù)報文頭部參數(shù)提供的數(shù)據(jù)報文長度對TCP報文中的RTP報文進行分段接收；對接收到的不完整的RTP報文進行拼裝，并按順序?qū)ν暾腞TP報文中的數(shù)據(jù)進行解碼。本發(fā)明可提高流媒體傳輸?shù)目煽啃浴?br> 文檔編號H04L29/06GK1402492SQ02129258
公開日2003年3月12日 申請日期2002年9月29日 優(yōu)先權(quán)日2002年9月29日
發(fā)明者趙勇, 曾珂, 戴瓊海 申請人:清華大學