專利名稱：視頻數據的傳輸方法及其系統的制作方法
技術領域：
本發明涉及計算機數據傳輸，更具體地，涉及視頻數據的傳輸方法及其 系統。
背景技術：
在OSI (開放系統互聯)的七層參考架構中，TCP (傳輸控制協議)和 UDP (用戶數據報協議)都屬于第四層(傳輸層)的協議。TCP是基于連接 的、提供可靠傳輸的協議。具體而言，TCP首先建立可靠的連接，然后進行 數據封包的傳輸，TCP數據封包中包括序號和確認，接收方接收到數據封包 后根據序號進行數據封包排序，并回送確認消息。如果接收方未接到數據封 包，或者接收到的數據封包是損壞的，發送方還可以重發該數據封包。可以 說，TCP是同類協議中最可靠的，但是，TCP需要耗用大量的資源來維持這 種可靠性，從而降低了性能。
相反，UDP是不基于連接的、不提供可靠傳輸的協議，不提供排序、不 提供確認與重發。UDP的優點在于較為簡單，耗用的資源較少，性能較高； UDP的缺點在于可能存在數據封包的丟失以及順序紊亂。
組播(multicast),又稱為多播，是一種"一對多"的通訊方式，即，一 個主機可以向一個組(多播組)內的所有主機發送數據，在實際中釆用一個 組播地址表示一個多播組。組播過程可通過網絡中的交換機和路由器實現， 具體地，主機可以向路由器請求加入或退出某個多播組(用組播地址表示)， 對于該組播地址發出的數據，多播組內的路由器和交換機復制數據并將數據 傳輸給該組的所有主機。這樣既能一次將數據傳輸給多個有需要(加入多播組)的主機，又能保證不影響其他不需要(未加入多播組)的主機的其他通 訊。
與傳統的基于"一對一"的傳輸方式相比，組播能減輕服務器(發送方) 的負擔，不會給網絡造成很大的負載。但是，因為組播傳輸是"一對多"的 方式，而不同的接收方會存在不同的延遲、不同的數據封包接收順序，所以
使用TCP進行組播-傳輸是不現實的。現有的組播都是采用UDP。
應用最為廣泛的一種組播類型是組播視頻，包括分布式顯示、視頻監控、 視頻會議平臺等。如上所述，由于現有的組播視頻采用了不可靠的UDP協議， 從而不能保證數據傳輸的可靠性，容易造成數據封包的丟失，導致視頻播放 過程中出現畫面停頓、花屏等現象。
發明內容
本發明的一個發明目的是提供一種能夠保證數據傳輸的可靠性的視頻數 據的傳輸方法。
為實現該發明目的，本發明提供的視頻數據的傳輸方法包括以下步驟 組播網關接收用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的 地址、視頻源的協i義、用戶端的協議；所述組纟番網關^f吏用所述視頻源的協議 連接所述^L頻源，^接收所述^L頻源的^L頻數據；所述組I番網關將所述^L頻數 據轉換成所述用戶端的協議的數據封包，給所述數據封包添加編號；所述組 播網關通過與所述視頻源對應的組播地址向所述用戶端發送所述數據封包， 并將所發送的所述數據封包保存到緩沖區；所述用戶端接收所述數據封包， 根據所述編號判斷是否存在數據封包丟失，如果存在，就向所述組播網關發 送丟包反饋消息，所述丟包反饋消息包括視頻源的地址、所丟失的數據封包 的編號；所述組播網關接收所述丟包反饋消息，在所述緩沖區查找與所述編 號對應的數據封包，若查找成功，就向所述用戶端重新發送所述數據封包。與現有的視頻數據的傳輸方法相比，本發明提供的視頻數據的傳輸方法 緩存最近發送的數據封包，并接收用戶端的丟包反饋消息，從所緩存的數據 封包中查找到所丟失的數據封包并重新向用戶端發送，有效地保證了數據傳 輸的可靠性，避免了因為數據封包丟失而出現畫面停頓、花屏現象。
優選地，所述通過組播地址發送數據封包的步驟之前，還包括判斷是 否存在與所述視頻源對應的組播地址，若不存在，就創建與所述視頻源對應 的組播地址，并將所述組播地址發送給所述用戶端。
優選地，所述用戶端通過基于連接的TCP協議發送所述丟包反饋消息， 所述組播網關通過TCP協議向所述用戶端重新發送所述tt據封包。由于TCP 是基于連接的、提供可靠傳輸的協議，因此，該優選方案中，能保證丟包反 饋消息、重發的數據封包的可靠傳輸。
優選地，所述步驟還包括所述組播網關根據所述丟包反饋消息計算單 位時間內的丟包率，若所述丟包率 > 預設的最大閾值，所述組播網關就逐級 減小所述數據封包的封包時間間隔或者封包大小，直到所述丟包率 < 所述最 大閾值為止。若網絡負載過高導致丟包率超出預設閾值時，該優選方案可通 過減少封包的時間間隔以及封包大小來降低丟包率，使丟包率滿足預設的要 求。
優選地，所述步驟還包括若所述丟包率 < 超出預設的最小闊值，所述 組播網關就逐級增加所述數據封包的封包時間間隔或者封包大小，直到所述 丟包率>所述最小閾值為止。該優選方案中，在網絡通信質量較高時，適當 提高封包的時間間隔和封包大小，從而提高組播效率。
相應地，本發明的另一個發明目的在于提供一種能保證數據傳輸的可靠 性的視頻數據的傳輸系統。
為實現該發明目的，本發明提供的視頻數據的傳輸系統包括連接在視頻源(1 )與用戶端之間的組播網關，所述組播網關包括接收模塊，用于接收 所述用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的地址、視 頻源的協議、用戶端的協議，所述接收模塊還用于使用所述視頻源的協議連 接所述視頻源，接收所述視頻源的視頻數據；與所述接收模塊連接的協議轉
數據封包添加編號；與所述協議轉換模塊連接的組播模塊，用于通過與所述 視頻源對應的組播地址向所述用戶端發送所述數據封包，并將最近一個時間 段內發送的所述數據封包保存到緩沖區；與所述組播模塊連接的丟包處理模 塊，用于接收所述用戶端發送的丟包反饋消息，所述丟包反饋消息包括視頻 源的地址、所丟失的數據封包的編號，所述丟包處理模塊還用于在所述緩沖 區查找與所述編號對應的數據封包，若查找成功，就通過所述組播模塊向所 述用戶端重新發送所述數據封包。
與現有的視頻數據的傳輸系統相比，本發明提供的組播網關的組播模塊 緩存最近發送的數據封包，通過丟包處理模塊接收用戶端的丟包反饋消息并 從所緩存的數據封包中查找到所丟失的數據封包以及重新向用戶端發送，有 效地保證了數據傳輸的可靠性，避免了因為數據封包丟失而出現屏幕停頓、 花屏現象。
優選地，所述組播模塊還用于判斷是否存在與所述視頻源對應的組播地 址，以及在不存在所述組播地址時創建所述組播地址，并將所述組播地址發 送給所述用戶端。
優選地，所述用戶端通過基于連接的TCP協議發送所述丟包反饋消息， 所述組播模塊通過TCP協議向所述用戶端重新發送所述數據封包。
優選地，所述丟包處理模塊還用于根據所述丟包反饋消息計算單位時間 內的丟包率；所述協議轉換模塊還用于在所述丟包率 > 預設的最大閾值時逐 級減小所述數據封包的封包時間間隔或者封包大小，直到所述丟包率《所述 最大閾值為止。優選地，所述協議轉換模塊還用于在所述丟包率 < 超出預設的最小閾值 時逐級增加所述數據封包的封包時間間隔或者封包大小，直到所述丟包率> 所述最小閾值為止。
圖1是本發明提供的視頻數據的傳輸方法流程圖2是本發明提供的視頻數據的傳輸系統架構圖3是本發明的一個實施例采用的視頻請求消息的結構示意圖4是本發明的一個實施例中視頻數據經協議轉換模塊轉換后得到的數 據封包的結構示意圖5是本發明的 一個實施例采用的丟包反饋消息的結構示意圖6是本發明的一個實施例的視頻數據的傳輸流程。
具體實施例方式
圖l是本發明提供的視頻數據的傳輸方法流程圖。
如圖1所示，在步驟S100中，組播網關接收用戶端的視頻源請求消息， 圖3是本發明的一個實施例采用的視頻請求消息的結構示意圖。視頻源請求 消息包括視頻源的地址、連接視頻源所需要的協議、用戶端使用的協議等。 視頻源常用的協議包括TCP、 RTSP、 HTTP、 RTSP、 MMS等；而用戶端采用 的協議通常是UDP,或者其他用戶自定的可用于組播的通信協議。
接著，步驟S102中，組播網關使用對應的協議連接視頻源，接收視頻源 的視頻數據。視頻源包括但不限于遠程浮見頻文件流、本地才莫擬信號視頻源。 組播網關內置有多種連接協議以連接視頻源，或者通過插件或擴展的方式來擴展連接協議種類以連接各種類型的視頻源。步驟S104中，組播網關將視頻數據轉換成用戶端的協議的數據封包，給 數據封包添加編號，圖4是本發明的一個實施例采用的數據封包的結構示意 圖。因為在組播環境中用戶端通常采用UDP協議，所以組播網關在該步驟中 將視頻數據轉換成UDP協議格式的數據封包，數據封包中具有編號，該編號 用于后續的丟包反^t處理。步驟S106中，組播網關通過與該視頻源對應的組播地址向用戶端發送數 據封包，并將所發送的數據封包保存到緩沖區。 一般而言，緩沖區的存儲空 間是有限的，因此，在實際運行中，在緩沖區耗盡之時，會使用最新發送的 數據封包覆蓋最先保存的數據封包，即，步驟S106相當于存儲最近一個時間 段內發送的數據封包，該時間段的長短取決于緩沖區的容量、網絡質量、通 信質量要求等。 一個視頻源與一個組播地址對應， 一個組播地址與一個多播 組對應，從而實現了通過組播地址將一個一見頻源的數據組播給組內的各個成 員。將最近一段時間內組播的數據封包緩存到緩沖區，主要是為了在后續的 丟包處理時重發數據封包。步驟S108中，用戶端接收數據封包。接著，在步驟SllO中根據編號判 斷是否存在數據封包丟失，如果存在丟包，處理流程就進入步驟S112。步驟S112中，用戶端向組播網關發送丟包反饋消息，丟包反饋消息包括 組播信息以及所丟失的數據封包的編號等，組播信息可包括視頻源的地址、 類型等。圖5是本發明的一個實施例采用的丟包反饋消息的結構示意圖。步驟S114中，組播網關接收丟包反饋消息后，在緩沖區查找與編號對應 的數據封包，若查找成功，就向用戶端重新發送數據封包。從而完成可靠地 完成了組播，如步驟S116所述。顯然，在上述的步驟S110中，若用戶端根據編號發現已經接收到有關的 數據包且數據包完整，這就說明不存在丟包，流程可直接進入步驟S116。作為一種改進，在步驟S106中，組播網關通過組播地址發送數據封包的 步驟之前，還可以先判斷是否存在與視頻源對應的組播地址，若不存在，就 創建與視頻源對應的組播地址，并將組播地址發送給用戶端。之后，其他用 戶端對該視頻源的請求，都可以通過該組播地址來完成視頻的組播。作為一個優選方案，用戶端通過基于連接的TCP協議發送丟包反饋消息， 組播網關通過TCP協議向用戶端重新發送數據封包。因為TCP是提供可靠傳 輸的協議，通過TCP協議發送丟包反饋消息以及重發對應的數據包，實現了 可靠的傳輸。作為 一種改進，組播網關還根據丟包反饋消息計算單位時間內的丟包率 d,若丟包率d >預設的最大閾值D1，這說明網絡通信質量不夠好。為了適 當提高通信質量，減少丟包率，組播網關可逐級減小數據封包的封包時間間 隔或者封包大小，直到丟包率d(最大閾值Dl為止。本領域的技術人員應當 意識到，在碼流固定的情況下，減小數據封包的大小，數據封包的時間間隔 也會相應減小，反之，減小數據封包的時間間隔，數據封包的大小也會相應 減小。也就是說，減小數據封包的大小與減小數據封包的時間間隔，本質上 是一樣的。類似地，作為另一種改進，若丟包率d〈超出預設的最小闊值D2，這說 明組網絡通信條件良好且空閑資源充裕，為了有效地利用網絡通信資源、提 供通信效率，組播網關可逐級增加數據封包的封包時間間隔或者封包大小， 直到丟包率d》最小闊值D2為止。上述的最大閾值D1、最小閾值D2是預設 的，或者自適應的，即根據通信質量的要求、網絡通信質量等參數進行自適 應。圖2是本發明提供的視頻數據的傳輸系統架構圖。如圖2所示，該視頻數據的傳輸系統包括連接在視頻源1與用戶端3之間的組播網關2,視頻源1可以是網絡視頻源，也可以是本地模擬視頻信號如模擬電視信號等，而組播網關2包括接收模塊21、協議轉換模塊23、組插-模塊25以及丟包處理模塊 27。接收模塊21用于接收用戶端3的視頻源請求消息，圖3是本發明的一個 實施例采用的視頻源請求消息的結構示意圖。如圖3所示，視頻源請求消息 包括視頻源1的地址、視頻源1的協議、視頻源1的通道、用戶端的協議、 連接視頻源所需的用戶名與密碼等。接收模塊21接收到視頻源請求消息后， 使用視頻源的協議連接視頻源1,接收視頻源1的視頻數據。接收模塊21可 以內置常用的協議，例如兼容組播或者單播TCP協議，也可以通過外部插件 22的方式來調用協議，或者通過插件22來擴大協議種類以支持更多的協議。協議轉換模塊23與接收模塊21連接，用于將視頻數據轉換成用戶端的 協議的數據封包并給數據封包添加編號。類似地，可以通過插件24使協議轉 換模塊23支持更多的協議。圖4是本發明的一個實施例采用的數據封包的結 構示意圖，如圖4所示，該數據封包包括包類型、編號、長度以及^L頻數據 等。組播模塊25與協議轉換模塊23連接，用于通過與視頻源對應的組播地 址向用戶端發送數據封包，并將所發送的數據封包保存到緩沖區26。如上所 述，由于緩沖區26的存儲空間是有限的，在存儲空間耗盡時，就需要覆蓋最 先保存的數據封包，即，本質上是緩存了最近一個時間段內發送的數據封包。用戶端3接收到上述數據封包之后，根據編號判斷是否存在數據包丟失， 如果存在丟包，就發送丟包反饋消息。而與組播4莫塊25連接的丟包處理模塊 27可用于接收用戶端3發送的丟包反饋消息。圖5是本發明的一個實施例釆 用的丟包反饋消息的結構示意圖，如圖5所示，丟包反^f消息包括^L頻源的 地址、組播信息(視頻源IP地址、端口等)、所丟失的數據封包的編號等。組 播模塊25接收到丟包反饋消息后，在緩沖區查找與編號對應的數據封包，若查找成功，就通過組播才莫塊25向用戶端重新發送數據封包。作為一種改進，組播模塊25還用于判斷是否存在與視頻源對應的組播地 址，以及在不存在組播地址時創建組播地址，并將組播地址發送給用戶端3 。類似地，用戶端3通過基于連接的TCP協議發送丟包反饋消息，組播模 塊25通過TCP協議向用戶端重新發送數據封包。類似地，丟包處理模塊27還用于根據丟包反饋消息計算單位時間內的丟 包率d;協議轉換模塊23還用于在丟包率d >預設的最大閾值Dl時逐級減 小數據封包的封包時間間隔或者封包大小，直到丟包率<最大闊值為止。協 議轉換模塊23還用于在丟包率d <超出預設的最小閾值D2時逐級增加數據 封包的封包時間間隔或者封包大小，直到丟包率d》最小閾值D2為止。作為一種替換組播系統，可以通過接收模塊21接收進入組播網關2的數 據，包括來自視頻源1的視頻數據、來自用戶端3的視頻源請求消息、丟包 反饋消息，然后，再將不同的數據轉交給不同的功能模塊進行處理。在這種 方案中，接收模塊21接收到用戶端3的數據之后，首先判斷數據類型。如圖 3、圖5所示，可通過"包類型"字段來標識消息的類型，例如，包類型為0 表示視頻源請求消息，包類型為1表示丟包反饋消息。圖6為該替換的組播 系統的流程圖。如圖6所示，步驟S300中，接收用戶端3發送的消息。接著，步驟S301 中，判斷所接收的消息的類型，若為視頻源請求消息就進入步驟S302。步驟S302中，接收模塊21匹配視頻源的連接協議，若匹配失敗，就意 味著接收模塊21不支持所請求的視頻源，流程進入步驟S307通過用戶端3 連接失敗；若匹配成功，流程進入步驟S303。步驟S303中，接收模塊21連接視頻源1,若連接失敗，流程同樣進入上述步驟S307;若連接成功，就接收視頻數據，流程進入步驟S304。步驟S304中，協議轉換模塊23轉換視頻數據，具體地，根據用戶端3 的協議轉換視頻數據的封裝格式，然后在步驟S305中通過組播模塊25將封 裝后的數據封包組播給用戶端3 。在上述的步驟S300中，若所接收的消息為丟包反饋消息，則流程進入步 驟S306進行丟包反饋處理，在步驟S306中，丟包處理模塊27根據丟包的編 號在緩沖區查詢對應的數據封包，若查找成功，流程進入步驟S308將丟失的 數據封包重發給用戶端3;否則，流程進入步驟S309通知用戶處理，丟包處 理失敗。以上所述的本發明實施方式，并不構成對本發明保護范圍的限定。任何 在本發明的精神和原則之內所作的修改、等同替換和改進等，均應包含在本 發明的權利要求保護范圍之內。
權利要求
1、一種視頻數據的傳輸方法，其特征在于，包括以下步驟組播網關接收用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的地址、視頻源的協議、用戶端的協議；所述組播網關使用所述視頻源的協議連接所述視頻源，接收所述視頻源的視頻數據；所述組播網關將所述視頻數據轉換成所述用戶端的協議的數據封包，給所述數據封包添加編號；所述組播網關通過與所述視頻源對應的組播地址向所述用戶端發送所述數據封包，并將所發送的所述數據封包保存到緩沖區；所述用戶端接收所述數據封包，根據所述編號判斷是否存在數據封包丟失，如果存在，就向所述組播網關發送丟包反饋消息，所述丟包反饋消息包括所丟失的數據封包的編號；所述組播網關接收所述丟包反饋消息，在所述緩沖區查找與所述編號對應的數據封包，若查找成功，就向所述用戶端重新發送所述數據封包。
2、 根據權利要求1所述的視頻數據的傳輸方法，其特征在于，所述通過 組播地址發送數據封包的步驟之前，還包括判斷是否存在與所述視頻源對 應的組播地址，若不存在，就創建與所述視頻源對應的組播地址，并將所述 組播地址發送給所述用戶端。
3、 根據權利要求1或2所述的視頻數據的傳輸方法，其特征在于，所述 用戶端通過基于連接的TCP協議發送所述丟包反饋消息，所述組播網關通過 TCP協議向所述用戶端重新發送所述數據封包。
4、 根據權利要求3所述的視頻數據的傳輸方法，其特征在于，所述步驟 還包括所述組播網關根據所述丟包反饋消息計算單位時間內的丟包率，若 所述丟包率 > 預設的最大閾值，所述組播網關就減小所述數據封包的封包大 小，直到所述丟包率<所述最大閾值為止。
5、 根據權利要求4所述的視頻數據的傳輸方法，其特征在于，所述步驟 還包括若所述丟包率 <超出預設的最小閾值，所述組播網關就增加所述數 據封包的封包大小，直到所述丟包率>所述最小閾值為止。
6、 一種視頻數據的傳輸系統，包括連接在一見頻源(1)與用戶端(3)之 間的組播網關(2),其特征在于，所述組播網關(2)包括接收模塊(21),用于接收所述用戶端(3)的視頻源請求消息，所述視 頻源請求消息包括視頻源(1)的地址、視頻源的協議、用戶端的協議；所述 接收模塊(21)還用于使用所述視頻源的協議連接所述視頻源(1),接收所 述視頻源(1 )的一見頻數據；與所述接收模塊(21)連接的協議轉換模塊(23),用于將所述視頻數據 轉換成所述用戶端的協議的數據封包并給所述數據封包添加編號；與所述協議轉換模塊(23)連接的組播模塊(25)，用于通過與所述視頻 源對應的組播地址向所述用戶端發送所述數據封包，并將所發送的所述數據 封包保存到緩沖區；與所述組播模塊(25)連接的丟包處理模塊(27),用于接收所述用戶端 (3 )發送的丟包反饋消息，所述丟包反饋消息包括所丟失的數據封包的編號； 所述丟包處理模塊(27)還用于在所述緩沖區查找與所述編號對應的數據封 包，若查找成功，就通過所述組播模塊(25)向所述用戶端重新發送所述數 據封包。
7、 根據權利要求6所述的視頻數據的傳輸系統，其特征在于，所述組播 模塊(25)還用于判斷是否存在與所述視頻源對應的組播地址，以及在不存 在所述組播地址時創建所述組播地址，并將所述組播地址發送給所述用戶端(3)。
8、 根據權利要求6或7所述的視頻數據的傳輸系統，其特征在于，所述 用戶端(3 )通過基于連接的TCP協議發送所述丟包反饋消息，所述組播模塊(25 )通過TCP協議向所述用戶端重新發送所述數據封包。
9、 根據權利要求8所述的視頻數據的傳輸系統，其特征在于所述丟包 處理模塊(27)還用于根據所述丟包反饋消息計算單位時間內的丟包率；所 述協議轉換模塊(23)還用于在所述丟包率 > 預設的最大閾值時減小所述數 據封包的封包大小，直到所述丟包率<所述最大閾值為止。
10、 根據權利要求9所述的視頻數據的傳輸系統，其特征在于所述協 議轉換模塊(23)還用于在所述丟包率 < 超出預設的最小闊值時增加所述數 據封包的封包大小，直到所述丟包率>所述最小閾值為止。
全文摘要
本發明提供一種視頻數據的傳輸方法和系統。所述系統包括連接在視頻源、用戶端之間的組播網關。所述方法包括組播網關接收用戶端的視頻源請求消息，使用視頻源的協議連接視頻源，接收視頻數據并將其轉換成用戶端的協議的數據封包，給數據封包添加編號，通過與視頻源對應的組播地址向用戶端發送數據封包，并將最近一個時間段內發送的數據封包保存到緩沖區；用戶端接收數據封包后判斷是否存在丟包，如果存在丟包就發送丟包反饋消息；組播網關在緩沖區查找與該編號對應的數據封包，若查找成功，就向用戶端重新發送數據封包。本發明將最近發送的數據封包保存到緩沖區，在丟包時從緩沖區查找所丟失的數據封包并重發，保證了數據傳輸的可靠性。
文檔編號H04L1/16GK101304302SQ200810028638
公開日2008年11月12日 申請日期2008年6月6日 優先權日2008年6月6日
發明者劉先材, 偉 歐, 濤 王, 白昀斌, 谷新征 申請人:廣東威創視訊科技股份有限公司