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