一種互聯網條件下基于rudp的實時視頻傳輸方法
【專利摘要】本發明公開了一種基于RUDP的實時視頻傳輸方法，采用客戶端/服務器(C/S)結構模型，該技術方案的具體步驟包括視頻數據分發、丟包檢測、接收報告、丟包恢復、接收端數據排序和解碼顯示等。本發明能夠解決互聯網條件下，因為網絡擁塞，數據包丟失等問題導致的視頻接收延遲、停頓、畫面出現馬賽克、花屏等問題。主要優點在于，無需通過額外的投入改進用戶現有的網絡條件，用戶利用現有的網絡環境能獲取更清晰更流暢的視頻通信效果。
【專利說明】一種互聯網條件下基于RUDP的實時視頻傳輸方法
【技術領域】
[0001]本發明涉及視頻傳輸領域，尤其涉及一種基于RUDP的實時視頻傳輸方法。
【背景技術】
[0002]目前，視頻通信的發展方向具有普及化、多終端、多網絡化、高清化的特點。這對視頻通信的網絡載體提出更高要求，即更高更穩定的網絡帶寬保障和多種網絡(如企業專網、ADSL、3G網路等)的高效互聯。雖然目前互聯網帶寬已經有很大改善，但仍然存在不同運營商之間互通性差，同一運營商由于地域的不同，也很難有穩定的帶寬保障。因此，如何在不穩定的互聯網帶寬條件下獲得清晰流暢而且實時的視頻通信質量，是一個相當大的技術難題。
[0003]主流的視頻通信在網絡協議層面上講，分為UDP (用戶數據報)協議和TCP (傳輸控制)協議，UDP協議傳輸的特點是數據實時到達，但不保證能傳到，網絡帶寬抖動時有可能丟失；TCP協議傳輸的特點是數據傳輸可靠，但在網絡條件下將時，有可能延遲到達，在某些情況下，會導致數據擁塞而使網絡連接斷開，并無法繼續傳輸數據。
[0004]目前，現有技術中解決以上問題主要有兩種技術方案:
[0005]一是對網絡鏈路提供QOS (服務質量)保障。無論采用哪種通信協議，視頻傳輸都是有保障的，但是整個傳輸過程都是依賴于數據鏈路中間的網關、路由等設備提供可靠服務質量。在現階段，互聯網運營商還無法為大規模用戶提供類似的服務，一般只能在專有網絡內部提供QOS服務，而且建設成本相當高，使用范圍有相當大的局限性。
[0006]二是根據網絡狀況來動態調整當前發送的數據流量。這種方案需要統計各個接收點的丟包率，再綜合調整數據發送的帶寬，但當接收點數量比較多時，由于各個接收點網絡狀況可能差別較大，有的地方帶寬好，有的地方帶寬差，如果按照某一個值去調整發送帶寬的話，則會導致帶寬好的地方本應該收到高質量視頻，調整后收到的視頻質量降低，而帶寬差的地方仍然有可能收不到流暢的視頻。另外，網絡的抖動往往具有瞬時性和間歇性，而帶寬的統計在時間上會有一定的滯后，很難保證同一時間點上調整的帶寬和用戶實際的網絡狀況一致。這種方案比較適合少量參與者的交互視頻通信，很難適應大規模的視頻會議等應用。
[0007]本發明的目的就是在最大程度上利用現有網絡帶寬條件，獲取高質量的視頻通信效果，即獲得清晰流暢的實時視頻通信效果同時，用戶也無需增加另外的投入來升級現有的網絡設備和增加互聯網接入帶寬。
【發明內容】
[0008]本發明提供一種基于RUDP (可靠的UDP傳輸協議)的實時視頻傳輸方法，米用客戶端/服務器(C/S)結構模型，具體包括以下步驟:(a)數據分發:每路視頻數據的分發，先是由發送端傳輸到分發服務器，再由分發服務器傳輸到各接收端；(b)丟包檢測:針對數據發送端，采用發送端主動檢測模式，針對接收端，則采用被動檢測模式；(C)接收報告:接收端定時(2秒)向發送端報告數據包接收情況，如恢復前的丟包率和恢復后的丟包率太高，則停止恢復，同時將這些信息反饋到客戶機UI操作界面。(d)丟包恢復:根據重傳數據包的重傳次數及丟包率進行數據重傳；(e)接收端數據排序:在接收端利用數據接收緩存對視頻幀數據進行排序，并增加相應的超時機制；(f)將已經按序接收完的視頻幀和等待超時后的視頻幀數據進行解碼器解碼顯示。
[0009]所述的數據分發包括:發送端在數據發送初期建立固定大小的發送窗口，對每個發送的數據包進行順序編號，已發送的數據包按編號從小到大緩存在發送窗口中，該緩存大小以時間為依據，緩存時間為300毫秒，新建立的數據在發送的同時添加到發送窗口隊列的最如端，而在窗口隊列中最后端保留時間超過300暈秒的數據自動丟棄。
[0010]所述的發送端主動檢測模式為:服務器作為接收端每接收10毫秒數據報告一次已接收的數據包編號，發送端再根據報告的情況，主動檢測哪些數據包丟失，并在發送窗口中查找相應編號的數據，重新發送給服務器。
[0011]所述的接收端被動檢測模式為:服務器作為發送端只是實時轉發數據包并動態滑動數據發送窗口，接收端根據已接收的數據包編號，每30毫秒檢測一次哪些數據包丟失，并將丟包信息發送給服務器，服務器被動接收丟包信息，在發送窗口中查找這些數據包編號并重新發送。
[0012]所述的丟包恢復包括:記錄每個重傳數據包的重傳次數，如果超過2次，則不再進行重傳，同時，根據接收報告，如果丟包率超過20 %，則停止丟包檢測，不再進行重傳，待丟包率小于20%，再重新開始檢測和恢復工作。
[0013]本發明所提供的視頻傳輸方法能夠解決互聯網條件下，視頻傳輸因為網絡擁塞，數據包丟失等問題導致的視頻接收延遲、停頓、畫面出現馬賽克、花屏等問題。
[0014]與現有技術相比，本發明的主要優點在于，無需通過額外的投入改進用戶現有的網絡條件，用戶利用現有的網絡環境能獲取更清晰更流暢的視頻通信效果；另外，本發明的技術方案可以讓用戶使用固定的視頻傳輸質量，無需經常調節，操作方面也更加便捷。
【專利附圖】
【附圖說明】
[0015]附圖1所示為本發明技術方案的網絡結構示意圖。
[0016]附圖2所示為本發明技術方案的發送端到數據分發服務器數據流示意圖。
[0017]附圖3所示為本發明技術方案的數據分發服務器到接收端數據流示意圖。
【具體實施方式】
[0018]本發明利用UDP傳輸協議的實時性，首先保證了視頻傳輸的實時到達，另外在通信過程中增加相應的丟包補償機制，很大程度上改善了傳輸的可靠性，業內稱此技術為RUDP(可靠的UDP傳輸協議)。目前此項技術已成功應用于自主研發的網動多媒體視頻會議系統、LiveUC云會議系統、網動遠程視頻監控系統等產品中，取得了相當好的效果；使用此項技術后，和市面上其他同類產品比較，很大程度上提高了市場競爭力。
[0019]以下結合附圖對本發明的技術方案做進一步說明。
[0020]如附圖1所示的本發明的網絡結構示意圖。本發明總體上采用客戶端/服務器(C/S)結構。具體包括以下步驟:[0021 ] 數據的分發。每路視頻數據的分發，是由發送端傳輸到分發服務器，再由分發服務器傳輸到各接收端，實現一點對多點的視頻通信功能，當然對于集群服務器結構，也會存在分發服務器將數據轉發到另外一個分發服務器再發送到客戶端的情況。
[0022]發送端在數據發送初期建立固定大小的發送窗口，對每個發送的數據包進行順序編號，已發送的數據包按編號從小到大緩存在發送窗口中，該緩存大小以時間為依據，緩存時間為300毫秒，這個也是接收端視頻延遲的最大值，新建立的數據在發送的同時添加到發送窗口隊列的最如端，而在窗口隊列中最后端保留時間超過300暈秒的數據自動丟棄。
[0023]丟包檢測。由于處理數據量大小所承擔的負荷不同，可以分為主動檢測模式和被動檢測模式，對于分發服務器，由于面對的是多路的上傳數據和更多路的數據下發，數據處理量大，所以針對數據發送端，采用發送端主動檢測模式，如附圖2所示，S卩服務器作為接收端，每接收10毫秒數據報告一次已接收的數據包編號，發送端再根據報告的情況，主動檢測哪些數據包丟失，并在發送窗口中查找相應編號的數據，重新發送給服務器。而針對接收端，則采用被動檢測模式，如附圖3所示，S卩服務器作為發送端，只是實時轉發數據包并動態滑動數據發送窗口，接收端根據已接收的數據包編號，每30毫秒檢測一次哪些數據包丟失，并將丟包信息發送給服務器，服務器被動接收丟包信息，在發送窗口中查找這些數據包編號并重新發送。
[0024]接收報告。無論是服務器作為接收端還是客戶機作為接收端，都須定時(2秒)向發送端報告數據包接收情況，如恢復前的丟包率和恢復后的丟包率，如果丟包率太高，說明網絡狀況惡化，則停止恢復，另外如果將這些信息反饋到客戶機UI操作界面，則用戶可以清楚知道當前網絡狀況，并對網絡狀況或者發送數據的帶寬作出相應調整。
[0025]丟包恢復。從以上丟包重傳機制可以看出，即使已丟失的數據包進行了重傳，也并不能保證第二次能收到，另外如果接收端丟失的數據包比例較高，如超過20%，如果將這些數據包都重新發送，則無疑會增加發送端20 %的帶寬，這樣可能會導致本身較差的接收狀況變得更加惡化，從而使得丟包率進一步上升，因此在數據恢復過程中增加了恢復策略，一方面，記錄每個重傳數據包的重傳次數，如果超過2次，則不再進行重傳，另一方面，根據接收報告，如果丟包率超過20%，則停止丟包檢測，不再進行重傳，待網絡狀況好轉后(丟包率小于20% )，可以重新開始檢測和恢復工作。
[0026]接收端數據排序。由于采用了丟包重傳機制，有可能會導致接收端完整接收視頻幀的順序發生變化，即先發送的視頻幀后接收完成，因此在接收端需要額外的數據接收緩存來針對視頻幀數據排序，并增加相應的超時機制。
[0027]解碼顯示。已經按序接收完的視頻幀和等待超時后的視頻幀數據才可以通過解碼器解碼顯不。
[0028]本發明的技術方案以UDP Socket為基礎在其上層單獨封裝了 RUDP層數據發送和接收協議，以C/C++編程語言來實現整個通信流程。
[0029]以下是以C++編程語言來實現的程序流程:
[0030]
【權利要求】
1.一種基于RUDP的實時視頻傳輸方法，采用客戶端/服務器(C/S)結構模型，其特征在于，包括以下步驟:(a)數據分發:每路視頻數據的分發，先是由發送端傳輸到分發服務器，再由分發服務器傳輸到各接收端；(b)丟包檢測:針對數據發送端，采用發送端主動檢測模式，針對接收端，則采用被動檢測模式；(C)接收報告:接收端定時(2秒)向發送端報告數據包接收情況，如恢復前的丟包率和恢復后的丟包率太高，則停止恢復，同時將這些信息反饋到客戶機Π操作界面。(d)丟包恢復:根據重傳數據包的重傳次數及丟包率進行數據重傳；(e)接收端數據排序:在接收端利用數據接收緩存對視頻幀數據進行排序，并增加相應的超時機制；(f)將已經按序接收完的視頻幀和等待超時后的視頻幀數據進行解碼器解碼顯示。
2.根據權利要求1所述的傳輸方法，其特征在于，所述的數據分發包括:發送端在數據發送初期建立固定大小的發送窗口，對每個發送的數據包進行順序編號，已發送的數據包按編號從小到大緩存在發送窗口中，該緩存大小以時間為依據，緩存時間為300毫秒，新建立的數據在發送的同時添加到發送窗口隊列的最前端，而在窗口隊列中最后端保留時間超過300毫秒的數據自動丟棄。
3.根據權利要求1所述的傳輸方法，其特征在于，所述的發送端主動檢測模式為:服務器作為接收端每接收10毫秒數據報告一次已接收的數據包編號，發送端再根據報告的情況，主動檢測哪些數據包丟失，并在發送窗口中查找相應編號的數據，重新發送給服務器。
4.根據權利要求1所述的傳輸方法，其特征在于，所述的接收端被動檢測模式為:服務器作為發送端只是實時轉發數據包并動態滑動數據發送窗口，接收端根據已接收的數據包編號，每30毫秒檢測一次哪些數據包丟失，并將丟包信息發送給服務器，服務器被動接收丟包信息，在發送窗口中查找這些數據包編號并重新發送。
5.根據權利要求1所述的傳輸方法，其特征在于，所述的丟包恢復包括:記錄每個重傳數據包的重傳次數，如果超過2次，則不再進行重傳，同時，根據接收報告，如果丟包率超過20%,則停止丟包檢測，不再進行重傳，待丟包率小于20%，再重新開始檢測和恢復工作。
【文檔編號】H04N21/647GK103780971SQ201210405900
【公開日】2014年5月7日 申請日期:2012年10月23日 優先權日:2012年10月23日
【發明者】聶維偉 申請人:北京網動網絡科技股份有限公司