本發(fā)明涉及一種視頻傳輸控制技術，具體地涉及一種惡劣網絡環(huán)境下高速可靠的視頻網絡傳輸控制方法和系統(tǒng)。

背景技術：

現(xiàn)有基于MCU(Multipoint Control Unit，多點控制單元)的視頻系統(tǒng)，一般包括編碼端、MCU服務端和解碼端。其中，MCU服務端是視頻系統(tǒng)中的重要組成部分，它的作用主要是協(xié)調和控制編碼端與解碼端之間的視頻數據傳輸。視頻系統(tǒng)的一項重要功能就是實現(xiàn)視頻的實時傳輸，一般傳輸視頻數據所采用的傳輸協(xié)議是TCP(Transmission Control Protocol)協(xié)議或者UDP(User Datagram Protocol)協(xié)議。

TCP協(xié)議比較可靠，它是一種面向連接的、基于字節(jié)流的運輸層通信協(xié)議。使用TCP協(xié)議可以保證數據傳輸的可靠性，但是這種可靠性是建立在丟失數據的重傳之上。例如，發(fā)送端將一個視頻數據段發(fā)送出去的同時會啟動一個重發(fā)定時器，如果該重發(fā)定時器超過預定時間也沒有接收到接收端的確認信息，那么發(fā)射端會重傳該數據段。這樣不但增加了傳輸的數據量，而且犧牲了視頻數據傳輸的實時性，造成視頻圖像的延時。

UDP協(xié)議是OSI參考模型中一種無連接的傳輸層協(xié)議，提供面向事務的簡單不可靠信息傳送服務。傳輸數據之前源端和終端是不需要建立連接的，發(fā)送數據時也不需要確認是否正確接收。由于使用UDP協(xié)議傳輸數據具有發(fā)送效率高、實時性強的優(yōu)點，使用UDP協(xié)議進行視頻數據傳輸是目前大多數視頻系統(tǒng)選擇的方式。

但是現(xiàn)有的UDP協(xié)議無法保證數據傳輸的可靠性，一旦視頻出現(xiàn)數據包丟失，那么解碼圖像很可能出現(xiàn)質量嚴重下降，例如馬賽克的出現(xiàn)。

技術實現(xiàn)要素：

為了解決上述技術問題，本發(fā)明提供了一種視頻網絡傳輸控制方法和系統(tǒng)，其實現(xiàn)了在惡劣網絡環(huán)境下高速可靠的視頻傳輸。

為實現(xiàn)上述目的，本發(fā)明提供了一種視頻網絡傳輸控制系統(tǒng)，包括發(fā)送控制端和接收控制端，以及發(fā)送數據端和接收數據端；

所述發(fā)送控制端與接收控制端以控制通道傳輸，傳輸協(xié)議為UDP協(xié)議；

所述發(fā)送控制端，用于與接收控制端之間建立UDP協(xié)議的控制通道，包括計算RTT、調整發(fā)送頻率、丟包重傳機制；

所述接收控制端，用于響應發(fā)送控制端，與發(fā)送控制端之間建立UDP協(xié)議的控制通道，包括計算丟包率、提供數據讀出；

所述控制通道，用于在發(fā)送控制端與接收控制端之間通過UDP協(xié)議發(fā)送和響應控制消息；

所述控制消息包括協(xié)商窗口大小、發(fā)送確認包、發(fā)送心跳消息、關閉通道；

所述發(fā)送數據端與接收數據端以數據通道傳輸，傳輸協(xié)議為UDP協(xié)議；

所述數據通道，用于在發(fā)送數據端與接收數據端之間推送發(fā)送數據端已經緩存的一個或者多個視頻數據包；

所述控制通道和數據通道都采用基于UDP傳輸協(xié)議傳輸，但傳輸的內容不同，控制通道傳輸控制消息，數據通道傳輸視頻數據包。

為實現(xiàn)本發(fā)明目的，還提供一種視頻網絡傳輸控制方法，包括如下步驟：

發(fā)送控制端和接收控制端通過UDP協(xié)議握手，建立UDP傳輸通道；

將視頻數據推送到發(fā)送數據端的發(fā)送緩沖區(qū)；并由發(fā)送緩沖區(qū)通過數據通道將所述視頻數據推送出去；

接收數據端接收數據通道推送出來的視頻數據的數據包，并插入到接收緩沖區(qū)；

在視頻數據傳輸完畢后，將網絡傳輸鏈路鏈接關閉。

本發(fā)明的視頻網絡傳輸控制方法和系統(tǒng)，針對在高延遲、高抖動、高丟包率的條件下，為網絡流和大文件的快速可靠傳輸提供一種解決方法。特別是在跨海、跨運營商、長距離等條件下，網絡的抖動、延遲、丟包是不可避免的，由于TCP協(xié)議本身的限制，傳輸速度無法提高。通過單邊加速、UDT(UDP-based Data Transfer Protocol，基于UDP的數據傳輸協(xié)議)、QUIC(Quick UDP Internet Connections，快速UDP互聯(lián)網連接)等方案，可以獲得部分提升，但遠遠達不到高清碼率、大文件等的傳輸要求。本發(fā)明對惡劣網絡條件下的高速傳輸，做了針對性優(yōu)化，通過丟包快速發(fā)現(xiàn)、雙UDP可靠傳輸模式、丟包恢復方法，經檢測，其在丟包率達到30％的條件下，也可以穩(wěn)定傳輸。

附圖說明

圖1是本發(fā)明實施例的視頻網絡傳輸控制方法流程圖；

圖2是本發(fā)明實施例的視頻網絡傳輸控制系統(tǒng)示意圖。

具體實施方式

下面將參考附圖1～2對本發(fā)明中詳細的代表性實施例進行描述。

本發(fā)明實施例的視頻網絡傳輸控制系統(tǒng)，如圖1所示，具有發(fā)送控制端(Control Sender)和接收控制端(Control Recover)，以及發(fā)送數據端(Data Sender)和接收數據端(Data Recover)；

所述發(fā)送控制端與接收控制端以控制通道傳輸，傳輸協(xié)議為UDP協(xié)議；

所述發(fā)送控制端，用于與接收控制端之間建立UDP協(xié)議的控制通道，包括但不限于計算RTT(Round-Trip Time，往返時延)、調整發(fā)送頻率、丟包重傳機制等；

所述接收控制端，用于響應發(fā)送控制端，與發(fā)送控制端之間建立UDP協(xié)議的控制通道，包括但不限于計算丟包率、提供數據讀出等；

所述控制通道，用于在發(fā)送控制端與接收控制端之間通過UDP協(xié)議發(fā)送和響應控制消息；

所述控制消息包括但不限于協(xié)商窗口大小、發(fā)送確認包、發(fā)送心跳消息、關閉通道等。

所述發(fā)送數據端與接收數據端以數據通道傳輸，傳輸協(xié)議為UDP協(xié)議；

所述數據通道，用于在發(fā)送數據端與接收數據端之間推送發(fā)送數據端已經緩存的一個或者多個視頻數據包。

所述控制通道和數據通道都采用基于UDP傳輸協(xié)議傳輸，但傳輸的內容不同，控制通道傳輸控制消息，數據通道傳輸視頻數據包。

其中，發(fā)送控制端(Control Sender)與接收控制端利用UDP傳輸協(xié)議進行通信，相互發(fā)送和響應控制消息，并根據控制消息分別控制發(fā)送數據端和接收數據端。

其中，所述發(fā)送控制端控制發(fā)送數據端，計算RTT(Round-Trip Time，往返時延)、調整發(fā)送頻率、丟包重傳機制等；

所述接收控制端控制接收數據端，計算丟包率、提供數據讀出等；

所述數據發(fā)送端，包括發(fā)送緩沖區(qū)，用于對發(fā)送數據包進行列表排隊并緩存發(fā)送。

所述數據接收端，包括接收緩沖區(qū)，用于在數據接收端接收到數據包進行列表排隊并緩存。

本發(fā)明中，通過控制通道和數據通道之間分別使用UDP協(xié)議，滿足通道的可靠性，提升可靠性、及時性，使視頻傳輸獲得較好的可靠保證。

作為一種較佳的實施例，每個發(fā)送數據包不大于1k數據量，并保證在1個MTU(Maximum Transmission Unit，最大傳輸單元)范圍內；

每個發(fā)送數據包在列表中有唯一編號，易于管理；

每個發(fā)送數據包會發(fā)送三次，盡量減少丟包，在發(fā)現(xiàn)丟包較多時，則少發(fā)送，確認已經發(fā)送所丟包已經收到后，再發(fā)送新包，從而通過犧牲帶寬換取可靠性和及時性；

發(fā)送數據包雖然有編號，但接收方接收數據包并不保證順序。

下面詳細說明本發(fā)明實施例的視頻網絡傳輸控制方法，如圖2所示，包括如下步驟：

步驟S100，發(fā)送控制端(Control Sender)和接收控制端(Control Recover)通過UDP協(xié)議握手，建立UDP傳輸通道；

具體地，所述步驟S100包括如下步驟：

步驟S110，通過配置啟動參數，同步控制發(fā)送控制端和接收控制端的IP、UDP端口等信息；

步驟S120，接收控制端(Control Recover)在所述UDP端口上監(jiān)聽服務；

步驟S130，發(fā)送控制端(Control Sender)通過UDP協(xié)議，向所述UDP端口發(fā)起建立鏈接命令，二者建立傳輸通道，從而保證數據的完整性和可靠性。

步驟S140，發(fā)送控制端(Control Recover)向接收控制端(Control Sender)發(fā)送包含數據發(fā)送端的數據發(fā)送IP、UDP端口的第一握手消息；

步驟S150，接收控制端接收到第一握手消息后，向發(fā)送控制端響應包含數據接收端的數據接收IP、UDP端口的第二握手消息；

步驟S160，發(fā)送控制端(Control Sender)接收到包含數據接收端(Data Recover)的數據接收IP、UDP端口的第二握手消息，完成發(fā)送控制端和接收控制端雙方，以及數據通道的鏈接建立。

步驟S200，將視頻數據通過Send()函數推送到發(fā)送數據端的發(fā)送緩沖區(qū)；并由發(fā)送緩沖區(qū)通過數據通道將所述視頻數據推送出去；

作為一種可實施方式，所述步驟S200中，將視頻數據通過Send()函數推送到發(fā)送數據端的發(fā)送緩沖區(qū)，包括如下步驟：

步驟S210，發(fā)送控制端(Control Sender)判斷發(fā)送數據端的發(fā)送緩沖區(qū)是否緩沖數據已滿；

步驟S220，如果緩沖區(qū)的緩沖數據已滿，則返回步驟S210，重新等待第一預定時間T1后推送所述視頻數據；

步驟S230，如果緩沖區(qū)的緩沖數據足夠，則判斷本次推送的視頻數據是否允許拆分；

步驟S240，如果視頻數據不允許拆分，要么不發(fā)送，要么全部發(fā)送，則判斷緩沖區(qū)的大小是否足夠不拆分時的視頻數據緩存；如果是，則進入步驟S260；否則進入步驟S250；

步驟S250，等待預定時間T2，返回步驟S240；

步驟S260，將所述視頻數據按照預設大小計算出序列表數據包，并順序推送到發(fā)送數據端的發(fā)送緩沖區(qū)。

由于發(fā)送帶寬的限制，每次發(fā)送不能無限制發(fā)送，需要根據發(fā)送的間隔，計算每次發(fā)送的數據包數量。

作為一種可實施方式，所述步驟S200中，由發(fā)送緩沖區(qū)通過數據通道將視頻數據推送出去，包括如下步驟：

步驟S210’,根據預設的推送速率，發(fā)送控制端(Control Sender)計算出每秒推送的包數據；

較佳地，每個發(fā)送數據包不大于1k數據量，并保證在1個UDP數據包的載荷范圍內；

由于本發(fā)明實施例中，以保證不分割UDP包為準，計算出每個序列數據包大小是固定的，這樣，每秒的發(fā)送的包數量，可根據預設的發(fā)送速率計算出來。

步驟S220’,發(fā)送數據端的緩沖區(qū)在發(fā)送IP、UDP端口向數據通道中按每隔第三預設時間T3發(fā)送一個或者多個數據包到數據接收端緩沖區(qū)的IP、UDP端口；

較佳地，所述第一、第二、第三預設時間為10ms。

步驟S300，接收數據端接收數據通道推送出來的視頻數據的數據包，并插入到接收緩沖區(qū)。

作為一種可實施方式，所述步驟S300包括如下步驟：

步驟S310，通過UDP的套接字(Socket)接收到一個數據包；

步驟S320，判斷數據包的有效性；在丟包時，進入步驟S330；在數據包有效時，進入步驟S340；

作為一種可實施方式，所述數據包的有效性通過以下幾個指標判斷：1)傳輸狀態(tài)正常；2)通道標識一致；3)包標識在合理范圍內；4)所述數據包沒有接收過；

如果數據包不符合上述有效性指標中的任一項，則不具有有效性，數據包丟失。

數據通道采用UDP方式，發(fā)送數據報文，丟包、抖動是不能避免的，怎樣發(fā)現(xiàn)數據包丟失，是提升傳輸速度的關鍵。

數據包丟失，通過兩種手段發(fā)現(xiàn)：

1)比該數據包發(fā)送晚的其他數據包，都已經收到ACK(應答)其他數據包一段時間(如10ms)了，則認為該數據包已經丟失，需要重傳；

2)每個發(fā)送包都有時間戳，接收端回復ACK(應答)包時，會同時返回最新的時間戳；當發(fā)送端收到ACK包后，即可以計算應該到達接收端的數據包的RTT；如果還沒到達，則等最大抖動(Jitter)時間，若還沒收到則馬上重新發(fā)送；

通過計算RTT，在數據包發(fā)送、接收過程中，會記錄包往返時間，由于程序延遲、緩沖等影響，有一定誤差，但對于丟包的發(fā)現(xiàn)，是很重要的手段。

步驟S330，判斷有效性后，則所述數據包和序列號插入到接收緩沖區(qū)隊列，并響應發(fā)送數據端，發(fā)送數據端中的序列號減相應地減一或者多個序列號，返回步驟S310，等待接收下一個或者多個數據包；

步驟S340，判斷無效后，接收控制端重傳次數加1；當重傳次數小于4時，計算丟包率，并根據丟包率計算出新發(fā)送頻率，以及丟包序列號通過控制通道發(fā)送給發(fā)送控制端，發(fā)送控制端根據丟包序列號重新組織丟包序列表，按新發(fā)送頻率，返回步驟S310，進行丟包重傳；否則，當重傳次數大于等于4時，則表示本次傳輸失敗，直接返回失敗信息，這樣就不會浪費更多的傳輸資源，實現(xiàn)其他數據的快速傳輸；

其中，較佳地，所述新發(fā)送頻率＝原發(fā)送頻率/(1+丟包率)。

步驟S400，在視頻數據傳輸完畢后，將網絡傳輸鏈路鏈接關閉。

作為一種可實施方式，所述關閉包括但不限于主動關閉、被動關閉、異常關閉三種情況。

主動關閉：在數據傳輸完畢時，需要關閉鏈接，可由任一方發(fā)起。通過控制信道，發(fā)送關閉消息，然后進入關閉狀態(tài)。不需要收到對方確認，因為控制信道是可靠傳輸，會保證包的到達。如果包沒有到達，對方則進入異常關閉的流程。

被動關閉：收到對方發(fā)送的關閉鏈接的消息，不需要發(fā)送確認包，直接進入關閉狀態(tài)。

異常關閉：控制信道上，會定期互相發(fā)送心跳包，如果在一定時間內，沒有收到對方的心跳包，則認為鏈路出現(xiàn)問題。進入關閉狀態(tài)。

作為一種可實施方式，本發(fā)明實施例中的視頻網絡傳輸控制方法，可按以下流程方式執(zhí)行：

1)先根據當前時刻和每秒發(fā)送個數，計算本次可以發(fā)送的數據包數量；

2)從發(fā)送緩沖區(qū)頭部開始，對每一個數據包進行判別：

3)如果數據包沒有發(fā)送過，則發(fā)送；同時將可發(fā)送數據包數減少；

4)如果已經發(fā)送過，則判斷是否需要重發(fā)，根據重發(fā)觸發(fā)的條件：

重發(fā)觸發(fā)條件：A)該數據包從上次發(fā)送，到現(xiàn)在已經超出RTO(Retransmission Time-Out，超時重傳機制)。

B)比該數據包上次發(fā)送比較晚的數據包，已經收到回復確認了；否則認為該數據包丟失，需要重發(fā)。

對發(fā)送的每個數據包，更新該數據包的狀態(tài)，包括但不限于：最后一次發(fā)送時刻、該數據包的發(fā)送次數、發(fā)送計數等。

如果本次發(fā)送重傳額度(3次)完畢，則等待10ms，進入下一輪發(fā)送周期。

本發(fā)明的視頻網絡傳輸控制方法和系統(tǒng)，針對在高延遲、高抖動、高丟包率的條件下，為網絡流和大文件的快速可靠傳輸提供一種解決方法。特別是在跨海、跨運營商、長距離等條件下，網絡的抖動、延遲、丟包是不可避免的，由于TCP協(xié)議本身的限制，傳輸速度無法提高。通過單邊加速、UDT、QUIC等方案，可以獲得部分提升，但遠遠達不到高清碼率、大文件等的傳輸要求。本發(fā)明對惡劣網絡條件下的高速傳輸，做了針對性優(yōu)化，通過丟包快速發(fā)現(xiàn)、雙UDP可靠傳輸模式、丟包恢復方法，經檢測，其在丟包率達到30％的條件下，也可以穩(wěn)定傳輸。

本發(fā)明的代表性實施例參照附圖得到了詳細的描述。這些詳細的描述僅僅給本領域技術人員更進一步的相信內容，以用于實施本發(fā)明的優(yōu)選方面，并且不會對本發(fā)明的范圍進行限制。僅有權利要求用于確定本發(fā)明的保護范圍。因此，在前述詳細描述中的特征和步驟的結合不是必要的用于在最寬廣的范圍內實施本發(fā)明，并且可替換地僅對本發(fā)明的特別詳細描述的代表性實施例給出教導。此外，為了獲得本發(fā)明的附加有用實施例，在說明書中給出教導的各種不同的特征可通過多種方式結合，然而這些方式沒有特別地被列舉出來。