使用丟包重傳的視頻信號增強方法
2023-04-28 00:23:41
專利名稱：使用丟包重傳的視頻信號增強方法
技術領域：
本發明涉及一種視頻信號增強方法，具體地說，是涉及一種基於RTP/RTCP協議、使用丟包重傳的視頻信號增強方法。
背景技術：
對於網際網路多媒體數據流的傳輸，目前公知的協議有RTP協議(實時傳輸協議)和RTCP協議(實時傳輸控制協議)。RTP協議的目的是實現多媒體數據流的同步傳輸，並提供多媒體數據流的傳輸時間信息。而RTCP協議主要提供流量控制、擁塞控制，負責當前應用進程之間的控制信息的交換與管理。在會話期間，各應用進程之間周期性地傳送RTCP包，RTCP包主要包含已發送數據包的數量、丟失數據包的數量等統計信息。通過RTCP包中的控制信息，各發送端便可以動態改變傳輸速率等參數，甚至改變有效載荷的類型。所以，RTP協議與RTCP協議配合使用，可以將有用信息即時反饋，使傳輸開銷最小化，傳輸效率最佳，且這種RTP協議與RTCP協議特別適用於網上數據的實時傳輸。
但是，在RTP協議與RTCP協議下，如果視頻數據流在傳輸過程中發生了丟包，則視頻畫面往往會出現停頓現象，致使畫面播放不連貫，且必須等到下一個關鍵幀到達客戶端後，視頻畫面才能夠繼續播放，使得觀看人員無法在第一時間看到監控畫面。
對於重要場所的視頻監控來說，視頻信息還應該進行完整保存，以備日後檢索。而這種傳輸過程中因丟包引起的視頻數據的間斷，則很可能會使視頻信息無法完整保存，這樣會給以後的信息檢索帶來不便。
發明內容
本發明的目的是提供一種使用丟包重傳的視頻信號增強方法，該方法不改變原有的RTP/RTCP協議，而是在RTP/RTCP協議的基礎上進行改進，來解決視頻信號在傳輸過程中的丟包問題，從而提高視頻信號傳輸質量。
為此，本發明採用以下技術方案一種使用丟包重傳的視頻信號增強方法，其特徵在於它包括如下步驟a)視頻信號發送端將每次產生的一個RTP數據包發送到視頻信號接收端後，將該RTP數據包放入歷史緩衝區；b)視頻信號接收端接收視頻信號發送端傳輸的RTP數據包，並判斷此次傳送的RTP數據包之前是否有丟包現象，如果判斷結果為沒有發生丟包現象，則視頻信號接收端將該RTP數據包放入RTP鍊表，並進行組幀，不向視頻信號發送端發出重傳請求，否則，視頻信號接收端將該RTP數據包放入RTP鍊表，但不進行組幀，而向視頻信號發送端發出重傳請求；c)視頻信號發送端收到視頻信號接收端發出的重傳請求後，補發所請求重傳的所有RTP數據包；d)視頻信號接收端收到補發的RTP數據包後，將RTP數據包放入RTP鍊表，並進行組幀；e)若視頻信號接收端再次收到視頻信號發送端補發的RTP數據包，則產生一個重傳失誤的報告；f)若視頻信號接收端檢測到重傳失誤的報告產生，則暫停RTP數據包的重傳，並通知上層應用程式，由上層應用程式採取措施解決各異常狀況。
在所述步驟b)中，判斷RTP數據包是否有丟包現象的方法為判斷此次收到的RTP數據包與前一次收到的RTP數據包之間的RTP序列號間隔N是否大於1，若N大於1，則發生丟包現象，且丟失RTP數據包的數量為(N-1)個。
在所述步驟f)中，上層應用程式的解決措施有兩種一種是視頻信號接收端向視頻信號發送端通過RTCP協議發出嚴重錯誤警告，視頻信號發送端收到嚴重錯誤警告後，降低視頻數據的流量，從而在數據發送源端消除網絡堵塞異常狀況。
另外一種是視頻信號接收端向客戶端發出帶寬不足的警報，從而使用戶停止RTP會話或採取其他方式來消除網絡堵塞異常狀況。
本發明適用於一視頻信號發送端到一視頻信號接收端的數據流單播方式，也適用於一視頻信號發送端到多視頻信號接收端的數據流多播方式。其中，多播方式中的丟包重傳方式採用單播方式。
本發明的優點是由於在RTP/RTCP協議的基礎上採用了丟包重傳措施來解決視頻信號傳輸過程中的丟包問題，從而實現了視頻畫面的連貫播放，消除了停頓現象，且視頻數據能夠被完整存儲。另外，通過判斷視頻信號接收端收到相同RTP數據包的數量，便可以檢測出此刻網絡堵塞程度，進而通過重傳失誤報告通知上層應用程式採取相應重傳抑制措施來解決網絡堵塞現象。
圖1是本發明的流程圖。
圖2是本發明實施例的實施流程示意圖。
具體實施例方式
參閱圖1，本發明為一種對視頻信號使用丟包重傳的增強方法，它包括如下步驟a)視頻信號發送端將每次產生的一個RTP數據包發送到視頻信號接收端後，再將該RTP數據包放入歷史緩衝區；b)視頻信號接收端接收視頻信號發送端傳輸的RTP數據包，並判斷此次傳送的RTP數據包之前是否有丟包現象，如果判斷結果為沒有發生丟包現象，則視頻信號接收端將該RTP數據包放入RTP鍊表，並進行組幀，不向視頻信號發送端發出重傳請求，否則，視頻信號接收端將該RTP數據包放入RTP鍊表，但不進行組幀，而是向視頻信號發送端發出重傳請求；c)視頻信號發送端收到視頻信號接收端發出的重傳請求後，補發所請求重傳的所有RTP數據包；d)視頻信號接收端收到補發的RTP數據包後，將RTP數據包放入RTP鍊表，並進行組幀；e)若視頻信號接收端再次收到視頻信號發送端補發過的RTP數據包，則產生一個重傳失誤的報告；f)若視頻信號接收端檢測到重傳失誤的報告產生，則暫停RTP數據包的重傳，並通知上層應用程式，由上層應用程式採取措施解決各異常狀況。
在所述步驟b)中，判斷RTP數據包是否有丟包現象的方法為判斷此次收到的RTP數據包與前一次收到的RTP數據包之間的RTP序列號間隔N是否大於1，若N大於1，則發生丟包現象，且丟失RTP數據包的數量為(N-1)個。
在所述步驟f)中，上層應用程式的解決措施有兩種一種是視頻信號接收端向視頻信號發送端通過RTCP協議發出嚴重錯誤警告，視頻信號發送端收到嚴重錯誤警告後，降低視頻數據的流量，從而在數據發送源端消除網絡堵塞異常狀況。
另外一種是視頻信號接收端向客戶端發出帶寬不足的警報，從而使用戶停止RTP會話或採取其他方式來消除網絡堵塞異常狀況。
對於步驟e)中所遇到的連續接收到兩次相同的RTP數據包現象，是由於RTP數據包錯序到達，即UDP「後發先到」，視頻信號接收端誤判丟包而要求發送端重傳RTP數據包所產生的。視頻信號接收端收到的兩個相同的RTP數據包分別為因重傳而首先接收到的RTP數據包和因先發後到緣故遲到的RTP數據包。收到兩次相同的RTP數據包的現象發生得越頻繁，就表明網絡越擁塞，因此視頻接收端檢測相同RTP數據包的收到次數可以用來衡量網絡堵塞的狀況。但這種現象一般只發生在Internet路由發生變動、網絡節點堵塞的情況下，一般來說WAN的路由結構是穩定不變的，不會發生這種現象。
當網絡處於帶寬極差，堵塞現象比較嚴重的情況下時，即使將丟失的RTP數據包重傳，也不能將重傳的RTP數據包成功地送達到視頻信號接收端。因此，當一次檢測到丟失RTP數據包的數量大於1個時，也可以不進行重傳請求，即以犧牲QoS(網絡服務質量)性能來減少數據傳輸量，從而減小RTP數據包重傳的響應時間。同樣，也可以針對RTP數據包的序列號間隔N來設置重傳門限，從而折衷QoS與RTP數據包重傳的響應時間兩個指標。
請參閱圖2所示本發明的一個應用實例。其中IP攝像機和PC為視頻監控系統中的流媒體傳輸子系統的兩個組成部分，IP攝像機是視頻信號發送端，PC是視頻信號接收端。IP攝像機到PC的視頻信號傳輸的實現步驟如下1)IP攝像機啟動，同時建立數據發送、數據接收、數據監聽、RTP歷史緩衝等單元；2)IP攝像機捕獲視頻數據；3)IP攝像機進行視頻編碼；
4)IP攝像機將編碼後的數據組裝成RTP數據包發送給PC；5)同時，IP攝像機將該RTP數據包存入RTP歷史緩衝單元中；6)PC接收RTP數據包；7)當PC連續接收RTP數據包的序列號間隔N大於1且小於6時，則認為有丟包現象，例如連續接收到的RTP數據包序列號為12及15，間隔N大於1且小於6，則認為序列號為13、14的RTP數據包丟失，且丟包數量為2；8)PC發送關於序列號為13、14的數據包的丟包信息給IP攝像機的數據監聽單元，完成丟包反饋，所發送的丟包信息主要包括最先丟失的RTP數據包的序列號和連續丟包數量兩個數據信息；9)IP攝像機收到丟包反饋的信息後，提取最先丟失的RTP數據包的序列號和連續丟包數量兩個數據信息，以進行丟包查詢，即從RTP歷史緩衝單元中提取歷史RTP數據包；10)IP攝像機將所丟失的RTP數據包重新發送給PC；11)PC接收到重傳的RTP數據包後，進行重新組幀。
在實際應用中，重傳RTP數據包到達視頻信號接收端的時間可以達到理論計算理想值。下面進行詳細闡述。
假設某一RTP數據包從視頻信號發送端發出的時刻為t1，一個RTP數據包從視頻信號發送端到視頻信號接收端的傳輸時間為T，而相鄰的兩個RTP數據包的發送間隔為dt，那麼，正常情況下視頻信號接收端收到該RTP數據包的時刻為t2，且t2＝t1+T。若該RTP數據包丟失，則視頻信號接收端在下一個RTP數據包即將發送時，才會判斷出該RTP數據包在前一時刻已經丟失，因此視頻信號接收端檢測出丟包發生的時刻為t2』，且t2』＝t1+T+dt。然後，視頻信號接收端立即發出重傳請求，重傳請求到達視頻信號發送端的時刻為t3，且t3＝t2』+T。視頻信號發送端獲得重傳請求後，從RTP歷史緩衝區中找到該RTP數據包，並進行重新發送，則重新發送的RTP數據包到達視頻信號接收端的時刻為t4，且t4＝t3+T。經換算可得t4＝t1+3T+dt(1)考慮到視頻信號發送端與接收端的軟體開銷和延時抖動的影響，式(1)修正為t4＝t1+3T+dt+S1+S2+D (2)其中，S1為視頻信號發送端的軟體開銷時間，S2為視頻信號接收端的軟體開銷時間，D為延時抖動所花費的時間。一般，D的平均值可為0。若視頻信號發送端與接收端採用高效軟體，則可將S1和S2降低到毫秒級。
當一次檢測發現丟失RTP數據包的數量N1大於1時，式(2)變為t4＝t1+3T+N1dt+S1+S2+D (3)由式(3)得出，視頻信號接收端等待重傳RTP數據包的時間t4受N1、dt的影響。實際測試表明，N1一般為1，有時為2或3，極少情況超過3，可見t4主要受dt的影響，且dt越大，影響越大。
假設視頻傳輸幀率為F fps(每秒幀數)，傳輸碼率為B kbps(每秒千比特數)，那麼每幀大小S為(F/B)bit。由於每字節為8bit，則有S＝F/(B*8)Byte。若每個RTP數據包大小為RTP_Payload Byte，每幀平均有K個RTP數據包，則K＝S/RTP_Payload個RTP數據包。經換算可得K＝F/(B*8*RTP_Payload)以H.263格式傳輸視頻為例，若幀率F為512fps，以25kbps的傳輸碼率在乙太網上傳輸，則每幀平均有K＝512000/(25*8*RTP_Payload)個RTP數據包。由於TCP/IP協議限制所傳輸的每一數據包的最大字節數為MTU(最大傳輸單位)，為了適應各種寬帶帶寬的接入，MTU取值為1492Byte。安全起見，去除RTP數據包包頭，則RTP_Payload最大為1460Byte，故計算得出K約為2。
由於幀間傳送間隔為df＝1/25秒，則RTP數據包的發送間隔dt為df/K秒，經換算可得dt＝1/(25*K)，因此dt＝0.02s，即20毫秒。
以N1為1為例，對於Intranet來說，20毫秒對式(2)的影響很大，應有t4≈t1+dt，而對於Internet來說，應有t4≈t1+3T+dt，即視頻信號發送端產生一個RTP數據包後，視頻信號接收端的等待時間需要大約dt(Intranet情形)或3T+dt(Internet情形)時間。
測試表明，在Intranet網絡環境下，dt為20毫秒，實際檢測t4平均值為22毫秒，而t4的理論值為20毫秒。在Internet網絡環境下，dt為20毫秒，若視頻信號的發送端與接收端分別在北京和上海，則T為15毫秒。假設使用ADSL傳輸視頻信號，則實測檢測的t4平均值為68毫秒，而t4的理論值為65毫秒。可見，RTP數據包重傳達到接收端的速度較快，基本達到了理論計算的理想值，能夠滿足視頻畫面連續播放的條件。
本發明適用於一視頻信號發送端到一視頻信號接收端的數據流單播方式，也適用於一視頻信號發送端到多視頻信號接收端的數據流多播方式。但需注意，在多播方式下，視頻信號發送端對每一視頻信號接收端採取一對多同時發送RTP數據包的多播方式，但對於某一視頻信號接收端RTP數據包的丟包重傳則採用單播方式，以避免重傳的RTP數據包被其它視頻信號接收端接收到，產生信號誤傳。
本發明方法不修改RTP/RTCP，只是在它的基礎上進行了增強，能以最快的反映速度有效恢復偶爾丟失的數據包，適合視頻監控這個特殊的應用環境。
權利要求
1.一種使用丟包重傳的視頻信號增強方法，其特徵在於它包括如下步驟a)視頻信號發送端將每次產生的一個RTP數據包發送到視頻信號接收端後，將該RTP數據包放入歷史緩衝區；b)視頻信號接收端接收視頻信號發送端傳輸的RTP數據包，並判斷此次傳送的RTP數據包之前是否有丟包現象，如果判斷結果為沒有發生丟包現象，則視頻信號接收端將該RTP數據包放入RTP鍊表，並進行組幀，不向視頻信號發送端發出重傳請求，否則，視頻信號接收端將該RTP數據包放入RTP鍊表，但不進行組幀，而向視頻信號發送端發出重傳請求；c)視頻信號發送端收到視頻信號接收端發出的重傳請求後，補發所請求重傳的所有RTP數據包；d)視頻信號接收端收到補發的RTP數據包後，將RTP數據包放入RTP鍊表，並進行組幀；e)若視頻信號接收端再次收到視頻信號發送端補發過的RTP數據包，則產生一個重傳失誤的報告；f)若視頻信號接收端檢測到重傳失誤的報告產生，則暫停RTP數據包的重傳，並通知上層應用程式，由上層應用程式採取措施解決各異常狀況。
2.如權利要求1所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述步驟b)中的判斷RTP數據包是否有丟包現象的方法為判斷此次收到的RTP數據包與前一次收到的RTP數據包之間的RTP序列號間隔N是否大於1，若N大於1，則發生丟包現象，且丟失RTP數據包的數量為(N-1)個。
3.如權利要求1所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述步驟f)中的上層應用程式解決措施為視頻信號接收端向視頻信號發送端通過RTCP協議發出嚴重錯誤警告，視頻信號發送端收到嚴重錯誤警告後，降低視頻數據的流量，從而在數據發送源端消除網絡堵塞異常狀況。
4.如權利要求1所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述步驟f)中的上層應用程式解決措施為視頻信號接收端向客戶端發出帶寬不足的警報，從而使用戶停止RTP會話或採取其他方式來消除網絡堵塞異常狀況。
5.如權利要求1所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述步驟適用於一視頻信號發送端到一視頻信號接收端的數據流單播方式。
6.如權利要求1所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述步驟適用於一視頻信號發送端到多視頻信號接收端的數據流多播方式。
7.如權利要求6所述的使用丟包重傳的視頻信號增強方法，其特徵在於所述多播方式中的丟包重傳方式採用單播方式。
全文摘要
本發明公開了一種對視頻信號使用丟包重傳的增強方法，包括如下步驟視頻發送端將每次產生的RTP數據包發送，並放入歷史緩衝區；接收端判斷此次接收的RTP數據包之前是否有丟包現象，若無丟包現象，則該RTP數據包放入RTP鍊表組幀，反之，向發送端發出重傳請求；發送端收到重傳請求後，補發需重傳的所有RTP數據包；接收端收到補發的RTP數據包後，將其放入RTP鍊表組幀；若接收端再次收到相同RTP數據包，則產生一重傳失誤報告；接收端檢測到該報告後，暫停重傳RTP數據包，並通知上層應用程式採取措施解決。本發明採取丟包重傳與重傳抑制措施解決了視頻信號的丟包問題，實現了畫面的連貫播放，消除了停頓現象，抑制了網絡堵塞現象，且視頻數據能夠被完整存儲。
文檔編號H04L29/06GK1917639SQ20061011280
公開日2007年2月21日 申請日期2006年9月1日 優先權日2006年9月1日
發明者華寧, 劉 東, 陸樂, 董新久, 石宇光, 陳東 申請人:北京天地互連信息技術有限公司