專利名稱：使用丟包重傳的視頻信號增強(qiáng)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種視頻信號增強(qiáng)方法，具體地說，是涉及一種基于RTP/RTCP協(xié)議、使用丟包重傳的視頻信號增強(qiáng)方法。
背景技術(shù)：
對于因特網(wǎng)多媒體數(shù)據(jù)流的傳輸，目前公知的協(xié)議有RTP協(xié)議(實(shí)時(shí)傳輸協(xié)議)和RTCP協(xié)議(實(shí)時(shí)傳輸控制協(xié)議)。RTP協(xié)議的目的是實(shí)現(xiàn)多媒體數(shù)據(jù)流的同步傳輸，并提供多媒體數(shù)據(jù)流的傳輸時(shí)間信息。而RTCP協(xié)議主要提供流量控制、擁塞控制，負(fù)責(zé)當(dāng)前應(yīng)用進(jìn)程之間的控制信息的交換與管理。在會話期間，各應(yīng)用進(jìn)程之間周期性地傳送RTCP包，RTCP包主要包含已發(fā)送數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)信息。通過RTCP包中的控制信息，各發(fā)送端便可以動(dòng)態(tài)改變傳輸速率等參數(shù)，甚至改變有效載荷的類型。所以，RTP協(xié)議與RTCP協(xié)議配合使用，可以將有用信息即時(shí)反饋，使傳輸開銷最小化，傳輸效率最佳，且這種RTP協(xié)議與RTCP協(xié)議特別適用于網(wǎng)上數(shù)據(jù)的實(shí)時(shí)傳輸。
但是，在RTP協(xié)議與RTCP協(xié)議下，如果視頻數(shù)據(jù)流在傳輸過程中發(fā)生了丟包，則視頻畫面往往會出現(xiàn)停頓現(xiàn)象，致使畫面播放不連貫，且必須等到下一個(gè)關(guān)鍵幀到達(dá)客戶端后，視頻畫面才能夠繼續(xù)播放，使得觀看人員無法在第一時(shí)間看到監(jiān)控畫面。
對于重要場所的視頻監(jiān)控來說，視頻信息還應(yīng)該進(jìn)行完整保存，以備日后檢索。而這種傳輸過程中因丟包引起的視頻數(shù)據(jù)的間斷，則很可能會使視頻信息無法完整保存，這樣會給以后的信息檢索帶來不便。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種使用丟包重傳的視頻信號增強(qiáng)方法，該方法不改變原有的RTP/RTCP協(xié)議，而是在RTP/RTCP協(xié)議的基礎(chǔ)上進(jìn)行改進(jìn)，來解決視頻信號在傳輸過程中的丟包問題，從而提高視頻信號傳輸質(zhì)量。
為此，本發(fā)明采用以下技術(shù)方案一種使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于它包括如下步驟a)視頻信號發(fā)送端將每次產(chǎn)生的一個(gè)RTP數(shù)據(jù)包發(fā)送到視頻信號接收端后，將該RTP數(shù)據(jù)包放入歷史緩沖區(qū)；b)視頻信號接收端接收視頻信號發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包，并判斷此次傳送的RTP數(shù)據(jù)包之前是否有丟包現(xiàn)象，如果判斷結(jié)果為沒有發(fā)生丟包現(xiàn)象，則視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀，不向視頻信號發(fā)送端發(fā)出重傳請求，否則，視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，但不進(jìn)行組幀，而向視頻信號發(fā)送端發(fā)出重傳請求；c)視頻信號發(fā)送端收到視頻信號接收端發(fā)出的重傳請求后，補(bǔ)發(fā)所請求重傳的所有RTP數(shù)據(jù)包；d)視頻信號接收端收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀；e)若視頻信號接收端再次收到視頻信號發(fā)送端補(bǔ)發(fā)的RTP數(shù)據(jù)包，則產(chǎn)生一個(gè)重傳失誤的報(bào)告；f)若視頻信號接收端檢測到重傳失誤的報(bào)告產(chǎn)生，則暫停RTP數(shù)據(jù)包的重傳，并通知上層應(yīng)用程序，由上層應(yīng)用程序采取措施解決各異常狀況。
在所述步驟b)中，判斷RTP數(shù)據(jù)包是否有丟包現(xiàn)象的方法為判斷此次收到的RTP數(shù)據(jù)包與前一次收到的RTP數(shù)據(jù)包之間的RTP序列號間隔N是否大于1，若N大于1，則發(fā)生丟包現(xiàn)象，且丟失RTP數(shù)據(jù)包的數(shù)量為(N-1)個(gè)。
在所述步驟f)中，上層應(yīng)用程序的解決措施有兩種一種是視頻信號接收端向視頻信號發(fā)送端通過RTCP協(xié)議發(fā)出嚴(yán)重錯(cuò)誤警告，視頻信號發(fā)送端收到嚴(yán)重錯(cuò)誤警告后，降低視頻數(shù)據(jù)的流量，從而在數(shù)據(jù)發(fā)送源端消除網(wǎng)絡(luò)堵塞異常狀況。
另外一種是視頻信號接收端向客戶端發(fā)出帶寬不足的警報(bào)，從而使用戶停止RTP會話或采取其他方式來消除網(wǎng)絡(luò)堵塞異常狀況。
本發(fā)明適用于一視頻信號發(fā)送端到一視頻信號接收端的數(shù)據(jù)流單播方式，也適用于一視頻信號發(fā)送端到多視頻信號接收端的數(shù)據(jù)流多播方式。其中，多播方式中的丟包重傳方式采用單播方式。
本發(fā)明的優(yōu)點(diǎn)是由于在RTP/RTCP協(xié)議的基礎(chǔ)上采用了丟包重傳措施來解決視頻信號傳輸過程中的丟包問題，從而實(shí)現(xiàn)了視頻畫面的連貫播放，消除了停頓現(xiàn)象，且視頻數(shù)據(jù)能夠被完整存儲。另外，通過判斷視頻信號接收端收到相同RTP數(shù)據(jù)包的數(shù)量，便可以檢測出此刻網(wǎng)絡(luò)堵塞程度，進(jìn)而通過重傳失誤報(bào)告通知上層應(yīng)用程序采取相應(yīng)重傳抑制措施來解決網(wǎng)絡(luò)堵塞現(xiàn)象。


圖1是本發(fā)明的流程圖。
圖2是本發(fā)明實(shí)施例的實(shí)施流程示意圖。
具體實(shí)施例方式
參閱圖1，本發(fā)明為一種對視頻信號使用丟包重傳的增強(qiáng)方法，它包括如下步驟a)視頻信號發(fā)送端將每次產(chǎn)生的一個(gè)RTP數(shù)據(jù)包發(fā)送到視頻信號接收端后，再將該RTP數(shù)據(jù)包放入歷史緩沖區(qū)；b)視頻信號接收端接收視頻信號發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包，并判斷此次傳送的RTP數(shù)據(jù)包之前是否有丟包現(xiàn)象，如果判斷結(jié)果為沒有發(fā)生丟包現(xiàn)象，則視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀，不向視頻信號發(fā)送端發(fā)出重傳請求，否則，視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，但不進(jìn)行組幀，而是向視頻信號發(fā)送端發(fā)出重傳請求；c)視頻信號發(fā)送端收到視頻信號接收端發(fā)出的重傳請求后，補(bǔ)發(fā)所請求重傳的所有RTP數(shù)據(jù)包；d)視頻信號接收端收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀；e)若視頻信號接收端再次收到視頻信號發(fā)送端補(bǔ)發(fā)過的RTP數(shù)據(jù)包，則產(chǎn)生一個(gè)重傳失誤的報(bào)告；f)若視頻信號接收端檢測到重傳失誤的報(bào)告產(chǎn)生，則暫停RTP數(shù)據(jù)包的重傳，并通知上層應(yīng)用程序，由上層應(yīng)用程序采取措施解決各異常狀況。
在所述步驟b)中，判斷RTP數(shù)據(jù)包是否有丟包現(xiàn)象的方法為判斷此次收到的RTP數(shù)據(jù)包與前一次收到的RTP數(shù)據(jù)包之間的RTP序列號間隔N是否大于1，若N大于1，則發(fā)生丟包現(xiàn)象，且丟失RTP數(shù)據(jù)包的數(shù)量為(N-1)個(gè)。
在所述步驟f)中，上層應(yīng)用程序的解決措施有兩種一種是視頻信號接收端向視頻信號發(fā)送端通過RTCP協(xié)議發(fā)出嚴(yán)重錯(cuò)誤警告，視頻信號發(fā)送端收到嚴(yán)重錯(cuò)誤警告后，降低視頻數(shù)據(jù)的流量，從而在數(shù)據(jù)發(fā)送源端消除網(wǎng)絡(luò)堵塞異常狀況。
另外一種是視頻信號接收端向客戶端發(fā)出帶寬不足的警報(bào)，從而使用戶停止RTP會話或采取其他方式來消除網(wǎng)絡(luò)堵塞異常狀況。
對于步驟e)中所遇到的連續(xù)接收到兩次相同的RTP數(shù)據(jù)包現(xiàn)象，是由于RTP數(shù)據(jù)包錯(cuò)序到達(dá)，即UDP“后發(fā)先到”，視頻信號接收端誤判丟包而要求發(fā)送端重傳RTP數(shù)據(jù)包所產(chǎn)生的。視頻信號接收端收到的兩個(gè)相同的RTP數(shù)據(jù)包分別為因重傳而首先接收到的RTP數(shù)據(jù)包和因先發(fā)后到緣故遲到的RTP數(shù)據(jù)包。收到兩次相同的RTP數(shù)據(jù)包的現(xiàn)象發(fā)生得越頻繁，就表明網(wǎng)絡(luò)越擁塞，因此視頻接收端檢測相同RTP數(shù)據(jù)包的收到次數(shù)可以用來衡量網(wǎng)絡(luò)堵塞的狀況。但這種現(xiàn)象一般只發(fā)生在Internet路由發(fā)生變動(dòng)、網(wǎng)絡(luò)節(jié)點(diǎn)堵塞的情況下，一般來說WAN的路由結(jié)構(gòu)是穩(wěn)定不變的，不會發(fā)生這種現(xiàn)象。
當(dāng)網(wǎng)絡(luò)處于帶寬極差，堵塞現(xiàn)象比較嚴(yán)重的情況下時(shí)，即使將丟失的RTP數(shù)據(jù)包重傳，也不能將重傳的RTP數(shù)據(jù)包成功地送達(dá)到視頻信號接收端。因此，當(dāng)一次檢測到丟失RTP數(shù)據(jù)包的數(shù)量大于1個(gè)時(shí)，也可以不進(jìn)行重傳請求，即以犧牲QoS(網(wǎng)絡(luò)服務(wù)質(zhì)量)性能來減少數(shù)據(jù)傳輸量，從而減小RTP數(shù)據(jù)包重傳的響應(yīng)時(shí)間。同樣，也可以針對RTP數(shù)據(jù)包的序列號間隔N來設(shè)置重傳門限，從而折衷QoS與RTP數(shù)據(jù)包重傳的響應(yīng)時(shí)間兩個(gè)指標(biāo)。
請參閱圖2所示本發(fā)明的一個(gè)應(yīng)用實(shí)例。其中IP攝像機(jī)和PC為視頻監(jiān)控系統(tǒng)中的流媒體傳輸子系統(tǒng)的兩個(gè)組成部分，IP攝像機(jī)是視頻信號發(fā)送端，PC是視頻信號接收端。IP攝像機(jī)到PC的視頻信號傳輸?shù)膶?shí)現(xiàn)步驟如下1)IP攝像機(jī)啟動(dòng)，同時(shí)建立數(shù)據(jù)發(fā)送、數(shù)據(jù)接收、數(shù)據(jù)監(jiān)聽、RTP歷史緩沖等單元；2)IP攝像機(jī)捕獲視頻數(shù)據(jù)；3)IP攝像機(jī)進(jìn)行視頻編碼；
4)IP攝像機(jī)將編碼后的數(shù)據(jù)組裝成RTP數(shù)據(jù)包發(fā)送給PC；5)同時(shí)，IP攝像機(jī)將該RTP數(shù)據(jù)包存入RTP歷史緩沖單元中；6)PC接收RTP數(shù)據(jù)包；7)當(dāng)PC連續(xù)接收RTP數(shù)據(jù)包的序列號間隔N大于1且小于6時(shí)，則認(rèn)為有丟包現(xiàn)象，例如連續(xù)接收到的RTP數(shù)據(jù)包序列號為12及15，間隔N大于1且小于6，則認(rèn)為序列號為13、14的RTP數(shù)據(jù)包丟失，且丟包數(shù)量為2；8)PC發(fā)送關(guān)于序列號為13、14的數(shù)據(jù)包的丟包信息給IP攝像機(jī)的數(shù)據(jù)監(jiān)聽單元，完成丟包反饋，所發(fā)送的丟包信息主要包括最先丟失的RTP數(shù)據(jù)包的序列號和連續(xù)丟包數(shù)量兩個(gè)數(shù)據(jù)信息；9)IP攝像機(jī)收到丟包反饋的信息后，提取最先丟失的RTP數(shù)據(jù)包的序列號和連續(xù)丟包數(shù)量兩個(gè)數(shù)據(jù)信息，以進(jìn)行丟包查詢，即從RTP歷史緩沖單元中提取歷史RTP數(shù)據(jù)包；10)IP攝像機(jī)將所丟失的RTP數(shù)據(jù)包重新發(fā)送給PC；11)PC接收到重傳的RTP數(shù)據(jù)包后，進(jìn)行重新組幀。
在實(shí)際應(yīng)用中，重傳RTP數(shù)據(jù)包到達(dá)視頻信號接收端的時(shí)間可以達(dá)到理論計(jì)算理想值。下面進(jìn)行詳細(xì)闡述。
假設(shè)某一RTP數(shù)據(jù)包從視頻信號發(fā)送端發(fā)出的時(shí)刻為t1，一個(gè)RTP數(shù)據(jù)包從視頻信號發(fā)送端到視頻信號接收端的傳輸時(shí)間為T，而相鄰的兩個(gè)RTP數(shù)據(jù)包的發(fā)送間隔為dt，那么，正常情況下視頻信號接收端收到該RTP數(shù)據(jù)包的時(shí)刻為t2，且t2＝t1+T。若該RTP數(shù)據(jù)包丟失，則視頻信號接收端在下一個(gè)RTP數(shù)據(jù)包即將發(fā)送時(shí)，才會判斷出該RTP數(shù)據(jù)包在前一時(shí)刻已經(jīng)丟失，因此視頻信號接收端檢測出丟包發(fā)生的時(shí)刻為t2’，且t2’＝t1+T+dt。然后，視頻信號接收端立即發(fā)出重傳請求，重傳請求到達(dá)視頻信號發(fā)送端的時(shí)刻為t3，且t3＝t2’+T。視頻信號發(fā)送端獲得重傳請求后，從RTP歷史緩沖區(qū)中找到該RTP數(shù)據(jù)包，并進(jìn)行重新發(fā)送，則重新發(fā)送的RTP數(shù)據(jù)包到達(dá)視頻信號接收端的時(shí)刻為t4，且t4＝t3+T。經(jīng)換算可得t4＝t1+3T+dt(1)考慮到視頻信號發(fā)送端與接收端的軟件開銷和延時(shí)抖動(dòng)的影響，式(1)修正為t4＝t1+3T+dt+S1+S2+D (2)其中，S1為視頻信號發(fā)送端的軟件開銷時(shí)間，S2為視頻信號接收端的軟件開銷時(shí)間，D為延時(shí)抖動(dòng)所花費(fèi)的時(shí)間。一般，D的平均值可為0。若視頻信號發(fā)送端與接收端采用高效軟件，則可將S1和S2降低到毫秒級。
當(dāng)一次檢測發(fā)現(xiàn)丟失RTP數(shù)據(jù)包的數(shù)量N1大于1時(shí)，式(2)變?yōu)閠4＝t1+3T+N1dt+S1+S2+D (3)由式(3)得出，視頻信號接收端等待重傳RTP數(shù)據(jù)包的時(shí)間t4受N1、dt的影響。實(shí)際測試表明，N1一般為1，有時(shí)為2或3，極少情況超過3，可見t4主要受dt的影響，且dt越大，影響越大。
假設(shè)視頻傳輸幀率為F fps(每秒幀數(shù))，傳輸碼率為B kbps(每秒千比特?cái)?shù))，那么每幀大小S為(F/B)bit。由于每字節(jié)為8bit，則有S＝F/(B*8)Byte。若每個(gè)RTP數(shù)據(jù)包大小為RTP_Payload Byte，每幀平均有K個(gè)RTP數(shù)據(jù)包，則K＝S/RTP_Payload個(gè)RTP數(shù)據(jù)包。經(jīng)換算可得K＝F/(B*8*RTP_Payload)以H.263格式傳輸視頻為例，若幀率F為512fps，以25kbps的傳輸碼率在以太網(wǎng)上傳輸，則每幀平均有K＝512000/(25*8*RTP_Payload)個(gè)RTP數(shù)據(jù)包。由于TCP/IP協(xié)議限制所傳輸?shù)拿恳粩?shù)據(jù)包的最大字節(jié)數(shù)為MTU(最大傳輸單位)，為了適應(yīng)各種寬帶帶寬的接入，MTU取值為1492Byte。安全起見，去除RTP數(shù)據(jù)包包頭，則RTP_Payload最大為1460Byte，故計(jì)算得出K約為2。
由于幀間傳送間隔為df＝1/25秒，則RTP數(shù)據(jù)包的發(fā)送間隔dt為df/K秒，經(jīng)換算可得dt＝1/(25*K)，因此dt＝0.02s，即20毫秒。
以N1為1為例，對于Intranet來說，20毫秒對式(2)的影響很大，應(yīng)有t4≈t1+dt，而對于Internet來說，應(yīng)有t4≈t1+3T+dt，即視頻信號發(fā)送端產(chǎn)生一個(gè)RTP數(shù)據(jù)包后，視頻信號接收端的等待時(shí)間需要大約dt(Intranet情形)或3T+dt(Internet情形)時(shí)間。
測試表明，在Intranet網(wǎng)絡(luò)環(huán)境下，dt為20毫秒，實(shí)際檢測t4平均值為22毫秒，而t4的理論值為20毫秒。在Internet網(wǎng)絡(luò)環(huán)境下，dt為20毫秒，若視頻信號的發(fā)送端與接收端分別在北京和上海，則T為15毫秒。假設(shè)使用ADSL傳輸視頻信號，則實(shí)測檢測的t4平均值為68毫秒，而t4的理論值為65毫秒。可見，RTP數(shù)據(jù)包重傳達(dá)到接收端的速度較快，基本達(dá)到了理論計(jì)算的理想值，能夠滿足視頻畫面連續(xù)播放的條件。
本發(fā)明適用于一視頻信號發(fā)送端到一視頻信號接收端的數(shù)據(jù)流單播方式，也適用于一視頻信號發(fā)送端到多視頻信號接收端的數(shù)據(jù)流多播方式。但需注意，在多播方式下，視頻信號發(fā)送端對每一視頻信號接收端采取一對多同時(shí)發(fā)送RTP數(shù)據(jù)包的多播方式，但對于某一視頻信號接收端RTP數(shù)據(jù)包的丟包重傳則采用單播方式，以避免重傳的RTP數(shù)據(jù)包被其它視頻信號接收端接收到，產(chǎn)生信號誤傳。
本發(fā)明方法不修改RTP/RTCP，只是在它的基礎(chǔ)上進(jìn)行了增強(qiáng)，能以最快的反映速度有效恢復(fù)偶爾丟失的數(shù)據(jù)包，適合視頻監(jiān)控這個(gè)特殊的應(yīng)用環(huán)境。
權(quán)利要求
1.一種使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于它包括如下步驟a)視頻信號發(fā)送端將每次產(chǎn)生的一個(gè)RTP數(shù)據(jù)包發(fā)送到視頻信號接收端后，將該RTP數(shù)據(jù)包放入歷史緩沖區(qū)；b)視頻信號接收端接收視頻信號發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包，并判斷此次傳送的RTP數(shù)據(jù)包之前是否有丟包現(xiàn)象，如果判斷結(jié)果為沒有發(fā)生丟包現(xiàn)象，則視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀，不向視頻信號發(fā)送端發(fā)出重傳請求，否則，視頻信號接收端將該RTP數(shù)據(jù)包放入RTP鏈表，但不進(jìn)行組幀，而向視頻信號發(fā)送端發(fā)出重傳請求；c)視頻信號發(fā)送端收到視頻信號接收端發(fā)出的重傳請求后，補(bǔ)發(fā)所請求重傳的所有RTP數(shù)據(jù)包；d)視頻信號接收端收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將RTP數(shù)據(jù)包放入RTP鏈表，并進(jìn)行組幀；e)若視頻信號接收端再次收到視頻信號發(fā)送端補(bǔ)發(fā)過的RTP數(shù)據(jù)包，則產(chǎn)生一個(gè)重傳失誤的報(bào)告；f)若視頻信號接收端檢測到重傳失誤的報(bào)告產(chǎn)生，則暫停RTP數(shù)據(jù)包的重傳，并通知上層應(yīng)用程序，由上層應(yīng)用程序采取措施解決各異常狀況。
2.如權(quán)利要求1所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述步驟b)中的判斷RTP數(shù)據(jù)包是否有丟包現(xiàn)象的方法為判斷此次收到的RTP數(shù)據(jù)包與前一次收到的RTP數(shù)據(jù)包之間的RTP序列號間隔N是否大于1，若N大于1，則發(fā)生丟包現(xiàn)象，且丟失RTP數(shù)據(jù)包的數(shù)量為(N-1)個(gè)。
3.如權(quán)利要求1所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述步驟f)中的上層應(yīng)用程序解決措施為視頻信號接收端向視頻信號發(fā)送端通過RTCP協(xié)議發(fā)出嚴(yán)重錯(cuò)誤警告，視頻信號發(fā)送端收到嚴(yán)重錯(cuò)誤警告后，降低視頻數(shù)據(jù)的流量，從而在數(shù)據(jù)發(fā)送源端消除網(wǎng)絡(luò)堵塞異常狀況。
4.如權(quán)利要求1所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述步驟f)中的上層應(yīng)用程序解決措施為視頻信號接收端向客戶端發(fā)出帶寬不足的警報(bào)，從而使用戶停止RTP會話或采取其他方式來消除網(wǎng)絡(luò)堵塞異常狀況。
5.如權(quán)利要求1所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述步驟適用于一視頻信號發(fā)送端到一視頻信號接收端的數(shù)據(jù)流單播方式。
6.如權(quán)利要求1所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述步驟適用于一視頻信號發(fā)送端到多視頻信號接收端的數(shù)據(jù)流多播方式。
7.如權(quán)利要求6所述的使用丟包重傳的視頻信號增強(qiáng)方法，其特征在于所述多播方式中的丟包重傳方式采用單播方式。
全文摘要
本發(fā)明公開了一種對視頻信號使用丟包重傳的增強(qiáng)方法，包括如下步驟視頻發(fā)送端將每次產(chǎn)生的RTP數(shù)據(jù)包發(fā)送，并放入歷史緩沖區(qū)；接收端判斷此次接收的RTP數(shù)據(jù)包之前是否有丟包現(xiàn)象，若無丟包現(xiàn)象，則該RTP數(shù)據(jù)包放入RTP鏈表組幀，反之，向發(fā)送端發(fā)出重傳請求；發(fā)送端收到重傳請求后，補(bǔ)發(fā)需重傳的所有RTP數(shù)據(jù)包；接收端收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將其放入RTP鏈表組幀；若接收端再次收到相同RTP數(shù)據(jù)包，則產(chǎn)生一重傳失誤報(bào)告；接收端檢測到該報(bào)告后，暫停重傳RTP數(shù)據(jù)包，并通知上層應(yīng)用程序采取措施解決。本發(fā)明采取丟包重傳與重傳抑制措施解決了視頻信號的丟包問題，實(shí)現(xiàn)了畫面的連貫播放，消除了停頓現(xiàn)象，抑制了網(wǎng)絡(luò)堵塞現(xiàn)象，且視頻數(shù)據(jù)能夠被完整存儲。
文檔編號H04L29/06GK1917639SQ20061011280
公開日2007年2月21日 申請日期2006年9月1日 優(yōu)先權(quán)日2006年9月1日
發(fā)明者華寧, 劉 東, 陸樂, 董新久, 石宇光, 陳東 申請人:北京天地互連信息技術(shù)有限公司