專利名稱：視頻數(shù)據(jù)的傳輸方法及其系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及計算機數(shù)據(jù)傳輸，更具體地，涉及視頻數(shù)據(jù)的傳輸方法及其 系統(tǒng)。
背景技術：
在OSI (開放系統(tǒng)互聯(lián))的七層參考架構中，TCP (傳輸控制協(xié)議)和 UDP (用戶數(shù)據(jù)報協(xié)議)都屬于第四層(傳輸層)的協(xié)議。TCP是基于連接 的、提供可靠傳輸?shù)膮f(xié)議。具體而言，TCP首先建立可靠的連接，然后進行 數(shù)據(jù)封包的傳輸，TCP數(shù)據(jù)封包中包括序號和確認，接收方接收到數(shù)據(jù)封包 后根據(jù)序號進行數(shù)據(jù)封包排序，并回送確認消息。如果接收方未接到數(shù)據(jù)封 包，或者接收到的數(shù)據(jù)封包是損壞的，發(fā)送方還可以重發(fā)該數(shù)據(jù)封包?？梢?說，TCP是同類協(xié)議中最可靠的，但是，TCP需要耗用大量的資源來維持這 種可靠性，從而降低了性能。
相反，UDP是不基于連接的、不提供可靠傳輸?shù)膮f(xié)議，不提供排序、不 提供確認與重發(fā)。UDP的優(yōu)點在于較為簡單，耗用的資源較少，性能較高； UDP的缺點在于可能存在數(shù)據(jù)封包的丟失以及順序紊亂。
組播(multicast),又稱為多播，是一種"一對多"的通訊方式，即，一 個主機可以向一個組(多播組)內的所有主機發(fā)送數(shù)據(jù)，在實際中釆用一個 組播地址表示一個多播組。組播過程可通過網絡中的交換機和路由器實現(xiàn)， 具體地，主機可以向路由器請求加入或退出某個多播組(用組播地址表示)， 對于該組播地址發(fā)出的數(shù)據(jù)，多播組內的路由器和交換機復制數(shù)據(jù)并將數(shù)據(jù) 傳輸給該組的所有主機。這樣既能一次將數(shù)據(jù)傳輸給多個有需要(加入多播組)的主機，又能保證不影響其他不需要(未加入多播組)的主機的其他通 訊。
與傳統(tǒng)的基于"一對一"的傳輸方式相比，組播能減輕服務器(發(fā)送方) 的負擔，不會給網絡造成很大的負載。但是，因為組播傳輸是"一對多"的 方式，而不同的接收方會存在不同的延遲、不同的數(shù)據(jù)封包接收順序，所以
使用TCP進行組播-傳輸是不現(xiàn)實的?，F(xiàn)有的組播都是采用UDP。
應用最為廣泛的一種組播類型是組播視頻，包括分布式顯示、視頻監(jiān)控、 視頻會議平臺等。如上所述，由于現(xiàn)有的組播視頻采用了不可靠的UDP協(xié)議， 從而不能保證數(shù)據(jù)傳輸?shù)目煽啃?，容易造成?shù)據(jù)封包的丟失，導致視頻播放 過程中出現(xiàn)畫面停頓、花屏等現(xiàn)象。

發(fā)明內容
本發(fā)明的一個發(fā)明目的是提供一種能夠保證數(shù)據(jù)傳輸?shù)目煽啃缘囊曨l數(shù) 據(jù)的傳輸方法。
為實現(xiàn)該發(fā)明目的，本發(fā)明提供的視頻數(shù)據(jù)的傳輸方法包括以下步驟 組播網關接收用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的 地址、視頻源的協(xié)i義、用戶端的協(xié)議；所述組纟番網關^f吏用所述視頻源的協(xié)議 連接所述^L頻源，^接收所述^L頻源的^L頻數(shù)據(jù)；所述組I番網關將所述^L頻數(shù) 據(jù)轉換成所述用戶端的協(xié)議的數(shù)據(jù)封包，給所述數(shù)據(jù)封包添加編號；所述組 播網關通過與所述視頻源對應的組播地址向所述用戶端發(fā)送所述數(shù)據(jù)封包， 并將所發(fā)送的所述數(shù)據(jù)封包保存到緩沖區(qū)；所述用戶端接收所述數(shù)據(jù)封包， 根據(jù)所述編號判斷是否存在數(shù)據(jù)封包丟失，如果存在，就向所述組播網關發(fā) 送丟包反饋消息，所述丟包反饋消息包括視頻源的地址、所丟失的數(shù)據(jù)封包 的編號；所述組播網關接收所述丟包反饋消息，在所述緩沖區(qū)查找與所述編 號對應的數(shù)據(jù)封包，若查找成功，就向所述用戶端重新發(fā)送所述數(shù)據(jù)封包。與現(xiàn)有的視頻數(shù)據(jù)的傳輸方法相比，本發(fā)明提供的視頻數(shù)據(jù)的傳輸方法 緩存最近發(fā)送的數(shù)據(jù)封包，并接收用戶端的丟包反饋消息，從所緩存的數(shù)據(jù) 封包中查找到所丟失的數(shù)據(jù)封包并重新向用戶端發(fā)送，有效地保證了數(shù)據(jù)傳 輸?shù)目煽啃?，避免了因為?shù)據(jù)封包丟失而出現(xiàn)畫面停頓、花屏現(xiàn)象。
優(yōu)選地，所述通過組播地址發(fā)送數(shù)據(jù)封包的步驟之前，還包括判斷是 否存在與所述視頻源對應的組播地址，若不存在，就創(chuàng)建與所述視頻源對應 的組播地址，并將所述組播地址發(fā)送給所述用戶端。
優(yōu)選地，所述用戶端通過基于連接的TCP協(xié)議發(fā)送所述丟包反饋消息， 所述組播網關通過TCP協(xié)議向所述用戶端重新發(fā)送所述tt據(jù)封包。由于TCP 是基于連接的、提供可靠傳輸?shù)膮f(xié)議，因此，該優(yōu)選方案中，能保證丟包反 饋消息、重發(fā)的數(shù)據(jù)封包的可靠傳輸。
優(yōu)選地，所述步驟還包括所述組播網關根據(jù)所述丟包反饋消息計算單 位時間內的丟包率，若所述丟包率 > 預設的最大閾值，所述組播網關就逐級 減小所述數(shù)據(jù)封包的封包時間間隔或者封包大小，直到所述丟包率 < 所述最 大閾值為止。若網絡負載過高導致丟包率超出預設閾值時，該優(yōu)選方案可通 過減少封包的時間間隔以及封包大小來降低丟包率，使丟包率滿足預設的要 求。
優(yōu)選地，所述步驟還包括若所述丟包率 < 超出預設的最小闊值，所述 組播網關就逐級增加所述數(shù)據(jù)封包的封包時間間隔或者封包大小，直到所述 丟包率>所述最小閾值為止。該優(yōu)選方案中，在網絡通信質量較高時，適當 提高封包的時間間隔和封包大小，從而提高組播效率。
相應地，本發(fā)明的另一個發(fā)明目的在于提供一種能保證數(shù)據(jù)傳輸?shù)目煽?性的視頻數(shù)據(jù)的傳輸系統(tǒng)。
為實現(xiàn)該發(fā)明目的，本發(fā)明提供的視頻數(shù)據(jù)的傳輸系統(tǒng)包括連接在視頻源(1 )與用戶端之間的組播網關，所述組播網關包括接收模塊，用于接收 所述用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的地址、視 頻源的協(xié)議、用戶端的協(xié)議，所述接收模塊還用于使用所述視頻源的協(xié)議連 接所述視頻源，接收所述視頻源的視頻數(shù)據(jù)；與所述接收模塊連接的協(xié)議轉
數(shù)據(jù)封包添加編號；與所述協(xié)議轉換模塊連接的組播模塊，用于通過與所述 視頻源對應的組播地址向所述用戶端發(fā)送所述數(shù)據(jù)封包，并將最近一個時間 段內發(fā)送的所述數(shù)據(jù)封包保存到緩沖區(qū)；與所述組播模塊連接的丟包處理模 塊，用于接收所述用戶端發(fā)送的丟包反饋消息，所述丟包反饋消息包括視頻 源的地址、所丟失的數(shù)據(jù)封包的編號，所述丟包處理模塊還用于在所述緩沖 區(qū)查找與所述編號對應的數(shù)據(jù)封包，若查找成功，就通過所述組播模塊向所 述用戶端重新發(fā)送所述數(shù)據(jù)封包。
與現(xiàn)有的視頻數(shù)據(jù)的傳輸系統(tǒng)相比，本發(fā)明提供的組播網關的組播模塊 緩存最近發(fā)送的數(shù)據(jù)封包，通過丟包處理模塊接收用戶端的丟包反饋消息并 從所緩存的數(shù)據(jù)封包中查找到所丟失的數(shù)據(jù)封包以及重新向用戶端發(fā)送，有 效地保證了數(shù)據(jù)傳輸?shù)目煽啃?，避免了因為?shù)據(jù)封包丟失而出現(xiàn)屏幕停頓、 花屏現(xiàn)象。
優(yōu)選地，所述組播模塊還用于判斷是否存在與所述視頻源對應的組播地 址，以及在不存在所述組播地址時創(chuàng)建所述組播地址，并將所述組播地址發(fā) 送給所述用戶端。
優(yōu)選地，所述用戶端通過基于連接的TCP協(xié)議發(fā)送所述丟包反饋消息， 所述組播模塊通過TCP協(xié)議向所述用戶端重新發(fā)送所述數(shù)據(jù)封包。
優(yōu)選地，所述丟包處理模塊還用于根據(jù)所述丟包反饋消息計算單位時間 內的丟包率；所述協(xié)議轉換模塊還用于在所述丟包率 > 預設的最大閾值時逐 級減小所述數(shù)據(jù)封包的封包時間間隔或者封包大小，直到所述丟包率《所述 最大閾值為止。優(yōu)選地，所述協(xié)議轉換模塊還用于在所述丟包率 < 超出預設的最小閾值 時逐級增加所述數(shù)據(jù)封包的封包時間間隔或者封包大小，直到所述丟包率> 所述最小閾值為止。


圖1是本發(fā)明提供的視頻數(shù)據(jù)的傳輸方法流程圖2是本發(fā)明提供的視頻數(shù)據(jù)的傳輸系統(tǒng)架構圖3是本發(fā)明的一個實施例采用的視頻請求消息的結構示意圖4是本發(fā)明的一個實施例中視頻數(shù)據(jù)經協(xié)議轉換模塊轉換后得到的數(shù) 據(jù)封包的結構示意圖5是本發(fā)明的 一個實施例采用的丟包反饋消息的結構示意圖6是本發(fā)明的一個實施例的視頻數(shù)據(jù)的傳輸流程。
具體實施例方式
圖l是本發(fā)明提供的視頻數(shù)據(jù)的傳輸方法流程圖。
如圖1所示，在步驟S100中，組播網關接收用戶端的視頻源請求消息， 圖3是本發(fā)明的一個實施例采用的視頻請求消息的結構示意圖。視頻源請求 消息包括視頻源的地址、連接視頻源所需要的協(xié)議、用戶端使用的協(xié)議等。 視頻源常用的協(xié)議包括TCP、 RTSP、 HTTP、 RTSP、 MMS等；而用戶端采用 的協(xié)議通常是UDP,或者其他用戶自定的可用于組播的通信協(xié)議。
接著，步驟S102中，組播網關使用對應的協(xié)議連接視頻源，接收視頻源 的視頻數(shù)據(jù)。視頻源包括但不限于遠程浮見頻文件流、本地才莫擬信號視頻源。 組播網關內置有多種連接協(xié)議以連接視頻源，或者通過插件或擴展的方式來擴展連接協(xié)議種類以連接各種類型的視頻源。步驟S104中，組播網關將視頻數(shù)據(jù)轉換成用戶端的協(xié)議的數(shù)據(jù)封包，給 數(shù)據(jù)封包添加編號，圖4是本發(fā)明的一個實施例采用的數(shù)據(jù)封包的結構示意 圖。因為在組播環(huán)境中用戶端通常采用UDP協(xié)議，所以組播網關在該步驟中 將視頻數(shù)據(jù)轉換成UDP協(xié)議格式的數(shù)據(jù)封包，數(shù)據(jù)封包中具有編號，該編號 用于后續(xù)的丟包反^t處理。步驟S106中，組播網關通過與該視頻源對應的組播地址向用戶端發(fā)送數(shù) 據(jù)封包，并將所發(fā)送的數(shù)據(jù)封包保存到緩沖區(qū)。 一般而言，緩沖區(qū)的存儲空 間是有限的，因此，在實際運行中，在緩沖區(qū)耗盡之時，會使用最新發(fā)送的 數(shù)據(jù)封包覆蓋最先保存的數(shù)據(jù)封包，即，步驟S106相當于存儲最近一個時間 段內發(fā)送的數(shù)據(jù)封包，該時間段的長短取決于緩沖區(qū)的容量、網絡質量、通 信質量要求等。 一個視頻源與一個組播地址對應， 一個組播地址與一個多播 組對應，從而實現(xiàn)了通過組播地址將一個一見頻源的數(shù)據(jù)組播給組內的各個成 員。將最近一段時間內組播的數(shù)據(jù)封包緩存到緩沖區(qū)，主要是為了在后續(xù)的 丟包處理時重發(fā)數(shù)據(jù)封包。步驟S108中，用戶端接收數(shù)據(jù)封包。接著，在步驟SllO中根據(jù)編號判 斷是否存在數(shù)據(jù)封包丟失，如果存在丟包，處理流程就進入步驟S112。步驟S112中，用戶端向組播網關發(fā)送丟包反饋消息，丟包反饋消息包括 組播信息以及所丟失的數(shù)據(jù)封包的編號等，組播信息可包括視頻源的地址、 類型等。圖5是本發(fā)明的一個實施例采用的丟包反饋消息的結構示意圖。步驟S114中，組播網關接收丟包反饋消息后，在緩沖區(qū)查找與編號對應 的數(shù)據(jù)封包，若查找成功，就向用戶端重新發(fā)送數(shù)據(jù)封包。從而完成可靠地 完成了組播，如步驟S116所述。顯然，在上述的步驟S110中，若用戶端根據(jù)編號發(fā)現(xiàn)已經接收到有關的 數(shù)據(jù)包且數(shù)據(jù)包完整，這就說明不存在丟包，流程可直接進入步驟S116。作為一種改進，在步驟S106中，組播網關通過組播地址發(fā)送數(shù)據(jù)封包的 步驟之前，還可以先判斷是否存在與視頻源對應的組播地址，若不存在，就 創(chuàng)建與視頻源對應的組播地址，并將組播地址發(fā)送給用戶端。之后，其他用 戶端對該視頻源的請求，都可以通過該組播地址來完成視頻的組播。作為一個優(yōu)選方案，用戶端通過基于連接的TCP協(xié)議發(fā)送丟包反饋消息， 組播網關通過TCP協(xié)議向用戶端重新發(fā)送數(shù)據(jù)封包。因為TCP是提供可靠傳 輸?shù)膮f(xié)議，通過TCP協(xié)議發(fā)送丟包反饋消息以及重發(fā)對應的數(shù)據(jù)包，實現(xiàn)了 可靠的傳輸。作為 一種改進，組播網關還根據(jù)丟包反饋消息計算單位時間內的丟包率 d,若丟包率d >預設的最大閾值D1，這說明網絡通信質量不夠好。為了適 當提高通信質量，減少丟包率，組播網關可逐級減小數(shù)據(jù)封包的封包時間間 隔或者封包大小，直到丟包率d(最大閾值Dl為止。本領域的技術人員應當 意識到，在碼流固定的情況下，減小數(shù)據(jù)封包的大小，數(shù)據(jù)封包的時間間隔 也會相應減小，反之，減小數(shù)據(jù)封包的時間間隔，數(shù)據(jù)封包的大小也會相應 減小。也就是說，減小數(shù)據(jù)封包的大小與減小數(shù)據(jù)封包的時間間隔，本質上 是一樣的。類似地，作為另一種改進，若丟包率d〈超出預設的最小闊值D2，這說 明組網絡通信條件良好且空閑資源充裕，為了有效地利用網絡通信資源、提 供通信效率，組播網關可逐級增加數(shù)據(jù)封包的封包時間間隔或者封包大小， 直到丟包率d》最小闊值D2為止。上述的最大閾值D1、最小閾值D2是預設 的，或者自適應的，即根據(jù)通信質量的要求、網絡通信質量等參數(shù)進行自適 應。圖2是本發(fā)明提供的視頻數(shù)據(jù)的傳輸系統(tǒng)架構圖。如圖2所示，該視頻數(shù)據(jù)的傳輸系統(tǒng)包括連接在視頻源1與用戶端3之間的組播網關2,視頻源1可以是網絡視頻源，也可以是本地模擬視頻信號如模擬電視信號等，而組播網關2包括接收模塊21、協(xié)議轉換模塊23、組插-模塊25以及丟包處理模塊 27。接收模塊21用于接收用戶端3的視頻源請求消息，圖3是本發(fā)明的一個 實施例采用的視頻源請求消息的結構示意圖。如圖3所示，視頻源請求消息 包括視頻源1的地址、視頻源1的協(xié)議、視頻源1的通道、用戶端的協(xié)議、 連接視頻源所需的用戶名與密碼等。接收模塊21接收到視頻源請求消息后， 使用視頻源的協(xié)議連接視頻源1,接收視頻源1的視頻數(shù)據(jù)。接收模塊21可 以內置常用的協(xié)議，例如兼容組播或者單播TCP協(xié)議，也可以通過外部插件 22的方式來調用協(xié)議，或者通過插件22來擴大協(xié)議種類以支持更多的協(xié)議。協(xié)議轉換模塊23與接收模塊21連接，用于將視頻數(shù)據(jù)轉換成用戶端的 協(xié)議的數(shù)據(jù)封包并給數(shù)據(jù)封包添加編號。類似地，可以通過插件24使協(xié)議轉 換模塊23支持更多的協(xié)議。圖4是本發(fā)明的一個實施例采用的數(shù)據(jù)封包的結 構示意圖，如圖4所示，該數(shù)據(jù)封包包括包類型、編號、長度以及^L頻數(shù)據(jù) 等。組播模塊25與協(xié)議轉換模塊23連接，用于通過與視頻源對應的組播地 址向用戶端發(fā)送數(shù)據(jù)封包，并將所發(fā)送的數(shù)據(jù)封包保存到緩沖區(qū)26。如上所 述，由于緩沖區(qū)26的存儲空間是有限的，在存儲空間耗盡時，就需要覆蓋最 先保存的數(shù)據(jù)封包，即，本質上是緩存了最近一個時間段內發(fā)送的數(shù)據(jù)封包。用戶端3接收到上述數(shù)據(jù)封包之后，根據(jù)編號判斷是否存在數(shù)據(jù)包丟失， 如果存在丟包，就發(fā)送丟包反饋消息。而與組播4莫塊25連接的丟包處理模塊 27可用于接收用戶端3發(fā)送的丟包反饋消息。圖5是本發(fā)明的一個實施例釆 用的丟包反饋消息的結構示意圖，如圖5所示，丟包反^f消息包括^L頻源的 地址、組播信息(視頻源IP地址、端口等)、所丟失的數(shù)據(jù)封包的編號等。組 播模塊25接收到丟包反饋消息后，在緩沖區(qū)查找與編號對應的數(shù)據(jù)封包，若查找成功，就通過組播才莫塊25向用戶端重新發(fā)送數(shù)據(jù)封包。作為一種改進，組播模塊25還用于判斷是否存在與視頻源對應的組播地 址，以及在不存在組播地址時創(chuàng)建組播地址，并將組播地址發(fā)送給用戶端3 。類似地，用戶端3通過基于連接的TCP協(xié)議發(fā)送丟包反饋消息，組播模 塊25通過TCP協(xié)議向用戶端重新發(fā)送數(shù)據(jù)封包。類似地，丟包處理模塊27還用于根據(jù)丟包反饋消息計算單位時間內的丟 包率d;協(xié)議轉換模塊23還用于在丟包率d >預設的最大閾值Dl時逐級減 小數(shù)據(jù)封包的封包時間間隔或者封包大小，直到丟包率<最大闊值為止。協(xié) 議轉換模塊23還用于在丟包率d <超出預設的最小閾值D2時逐級增加數(shù)據(jù) 封包的封包時間間隔或者封包大小，直到丟包率d》最小閾值D2為止。作為一種替換組播系統(tǒng)，可以通過接收模塊21接收進入組播網關2的數(shù) 據(jù)，包括來自視頻源1的視頻數(shù)據(jù)、來自用戶端3的視頻源請求消息、丟包 反饋消息，然后，再將不同的數(shù)據(jù)轉交給不同的功能模塊進行處理。在這種 方案中，接收模塊21接收到用戶端3的數(shù)據(jù)之后，首先判斷數(shù)據(jù)類型。如圖 3、圖5所示，可通過"包類型"字段來標識消息的類型，例如，包類型為0 表示視頻源請求消息，包類型為1表示丟包反饋消息。圖6為該替換的組播 系統(tǒng)的流程圖。如圖6所示，步驟S300中，接收用戶端3發(fā)送的消息。接著，步驟S301 中，判斷所接收的消息的類型，若為視頻源請求消息就進入步驟S302。步驟S302中，接收模塊21匹配視頻源的連接協(xié)議，若匹配失敗，就意 味著接收模塊21不支持所請求的視頻源，流程進入步驟S307通過用戶端3 連接失??；若匹配成功，流程進入步驟S303。步驟S303中，接收模塊21連接視頻源1,若連接失敗，流程同樣進入上述步驟S307;若連接成功，就接收視頻數(shù)據(jù)，流程進入步驟S304。步驟S304中，協(xié)議轉換模塊23轉換視頻數(shù)據(jù)，具體地，根據(jù)用戶端3 的協(xié)議轉換視頻數(shù)據(jù)的封裝格式，然后在步驟S305中通過組播模塊25將封 裝后的數(shù)據(jù)封包組播給用戶端3 。在上述的步驟S300中，若所接收的消息為丟包反饋消息，則流程進入步 驟S306進行丟包反饋處理，在步驟S306中，丟包處理模塊27根據(jù)丟包的編 號在緩沖區(qū)查詢對應的數(shù)據(jù)封包，若查找成功，流程進入步驟S308將丟失的 數(shù)據(jù)封包重發(fā)給用戶端3;否則，流程進入步驟S309通知用戶處理，丟包處 理失敗。以上所述的本發(fā)明實施方式，并不構成對本發(fā)明保護范圍的限定。任何 在本發(fā)明的精神和原則之內所作的修改、等同替換和改進等，均應包含在本 發(fā)明的權利要求保護范圍之內。
權利要求
1、一種視頻數(shù)據(jù)的傳輸方法，其特征在于，包括以下步驟組播網關接收用戶端的視頻源請求消息，所述視頻源請求消息包括視頻源的地址、視頻源的協(xié)議、用戶端的協(xié)議；所述組播網關使用所述視頻源的協(xié)議連接所述視頻源，接收所述視頻源的視頻數(shù)據(jù)；所述組播網關將所述視頻數(shù)據(jù)轉換成所述用戶端的協(xié)議的數(shù)據(jù)封包，給所述數(shù)據(jù)封包添加編號；所述組播網關通過與所述視頻源對應的組播地址向所述用戶端發(fā)送所述數(shù)據(jù)封包，并將所發(fā)送的所述數(shù)據(jù)封包保存到緩沖區(qū)；所述用戶端接收所述數(shù)據(jù)封包，根據(jù)所述編號判斷是否存在數(shù)據(jù)封包丟失，如果存在，就向所述組播網關發(fā)送丟包反饋消息，所述丟包反饋消息包括所丟失的數(shù)據(jù)封包的編號；所述組播網關接收所述丟包反饋消息，在所述緩沖區(qū)查找與所述編號對應的數(shù)據(jù)封包，若查找成功，就向所述用戶端重新發(fā)送所述數(shù)據(jù)封包。
2、 根據(jù)權利要求1所述的視頻數(shù)據(jù)的傳輸方法，其特征在于，所述通過 組播地址發(fā)送數(shù)據(jù)封包的步驟之前，還包括判斷是否存在與所述視頻源對 應的組播地址，若不存在，就創(chuàng)建與所述視頻源對應的組播地址，并將所述 組播地址發(fā)送給所述用戶端。
3、 根據(jù)權利要求1或2所述的視頻數(shù)據(jù)的傳輸方法，其特征在于，所述 用戶端通過基于連接的TCP協(xié)議發(fā)送所述丟包反饋消息，所述組播網關通過 TCP協(xié)議向所述用戶端重新發(fā)送所述數(shù)據(jù)封包。
4、 根據(jù)權利要求3所述的視頻數(shù)據(jù)的傳輸方法，其特征在于，所述步驟 還包括所述組播網關根據(jù)所述丟包反饋消息計算單位時間內的丟包率，若 所述丟包率 > 預設的最大閾值，所述組播網關就減小所述數(shù)據(jù)封包的封包大 小，直到所述丟包率<所述最大閾值為止。
5、 根據(jù)權利要求4所述的視頻數(shù)據(jù)的傳輸方法，其特征在于，所述步驟 還包括若所述丟包率 <超出預設的最小閾值，所述組播網關就增加所述數(shù) 據(jù)封包的封包大小，直到所述丟包率>所述最小閾值為止。
6、 一種視頻數(shù)據(jù)的傳輸系統(tǒng)，包括連接在一見頻源(1)與用戶端(3)之 間的組播網關(2),其特征在于，所述組播網關(2)包括接收模塊(21),用于接收所述用戶端(3)的視頻源請求消息，所述視 頻源請求消息包括視頻源(1)的地址、視頻源的協(xié)議、用戶端的協(xié)議；所述 接收模塊(21)還用于使用所述視頻源的協(xié)議連接所述視頻源(1),接收所 述視頻源(1 )的一見頻數(shù)據(jù)；與所述接收模塊(21)連接的協(xié)議轉換模塊(23),用于將所述視頻數(shù)據(jù) 轉換成所述用戶端的協(xié)議的數(shù)據(jù)封包并給所述數(shù)據(jù)封包添加編號；與所述協(xié)議轉換模塊(23)連接的組播模塊(25)，用于通過與所述視頻 源對應的組播地址向所述用戶端發(fā)送所述數(shù)據(jù)封包，并將所發(fā)送的所述數(shù)據(jù) 封包保存到緩沖區(qū)；與所述組播模塊(25)連接的丟包處理模塊(27),用于接收所述用戶端 (3 )發(fā)送的丟包反饋消息，所述丟包反饋消息包括所丟失的數(shù)據(jù)封包的編號； 所述丟包處理模塊(27)還用于在所述緩沖區(qū)查找與所述編號對應的數(shù)據(jù)封 包，若查找成功，就通過所述組播模塊(25)向所述用戶端重新發(fā)送所述數(shù) 據(jù)封包。
7、 根據(jù)權利要求6所述的視頻數(shù)據(jù)的傳輸系統(tǒng)，其特征在于，所述組播 模塊(25)還用于判斷是否存在與所述視頻源對應的組播地址，以及在不存 在所述組播地址時創(chuàng)建所述組播地址，并將所述組播地址發(fā)送給所述用戶端(3)。
8、 根據(jù)權利要求6或7所述的視頻數(shù)據(jù)的傳輸系統(tǒng)，其特征在于，所述 用戶端(3 )通過基于連接的TCP協(xié)議發(fā)送所述丟包反饋消息，所述組播模塊(25 )通過TCP協(xié)議向所述用戶端重新發(fā)送所述數(shù)據(jù)封包。
9、 根據(jù)權利要求8所述的視頻數(shù)據(jù)的傳輸系統(tǒng)，其特征在于所述丟包 處理模塊(27)還用于根據(jù)所述丟包反饋消息計算單位時間內的丟包率；所 述協(xié)議轉換模塊(23)還用于在所述丟包率 > 預設的最大閾值時減小所述數(shù) 據(jù)封包的封包大小，直到所述丟包率<所述最大閾值為止。
10、 根據(jù)權利要求9所述的視頻數(shù)據(jù)的傳輸系統(tǒng)，其特征在于所述協(xié) 議轉換模塊(23)還用于在所述丟包率 < 超出預設的最小闊值時增加所述數(shù) 據(jù)封包的封包大小，直到所述丟包率>所述最小閾值為止。
全文摘要
本發(fā)明提供一種視頻數(shù)據(jù)的傳輸方法和系統(tǒng)。所述系統(tǒng)包括連接在視頻源、用戶端之間的組播網關。所述方法包括組播網關接收用戶端的視頻源請求消息，使用視頻源的協(xié)議連接視頻源，接收視頻數(shù)據(jù)并將其轉換成用戶端的協(xié)議的數(shù)據(jù)封包，給數(shù)據(jù)封包添加編號，通過與視頻源對應的組播地址向用戶端發(fā)送數(shù)據(jù)封包，并將最近一個時間段內發(fā)送的數(shù)據(jù)封包保存到緩沖區(qū)；用戶端接收數(shù)據(jù)封包后判斷是否存在丟包，如果存在丟包就發(fā)送丟包反饋消息；組播網關在緩沖區(qū)查找與該編號對應的數(shù)據(jù)封包，若查找成功，就向用戶端重新發(fā)送數(shù)據(jù)封包。本發(fā)明將最近發(fā)送的數(shù)據(jù)封包保存到緩沖區(qū)，在丟包時從緩沖區(qū)查找所丟失的數(shù)據(jù)封包并重發(fā)，保證了數(shù)據(jù)傳輸?shù)目煽啃浴?br> 文檔編號H04L1/16GK101304302SQ200810028638
公開日2008年11月12日 申請日期2008年6月6日 優(yōu)先權日2008年6月6日
發(fā)明者劉先材, 偉 歐, 濤 王, 白昀斌, 谷新征 申請人:廣東威創(chuàng)視訊科技股份有限公司