專利名稱：一種多通道視頻流的傳輸方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明屬于移動通信網(wǎng)絡(luò)技術(shù)領(lǐng)域，更為具體地，涉及多通道視頻流的傳輸方法及系統(tǒng)。
背景技術(shù)：
目前，隨著無線技術(shù)的不斷向前發(fā)展，無線帶寬不斷提升，人類社會已經(jīng)逐步邁入 3G、LTE高速無線網(wǎng)絡(luò)時代。在高速的無線網(wǎng)絡(luò)環(huán)境下，原有的網(wǎng)絡(luò)視頻監(jiān)控前端已經(jīng)可以通過無線網(wǎng)絡(luò)傳輸視頻流。通常，普通無線前端設(shè)備一般提供單通道數(shù)據(jù)傳輸服務(wù)，在視頻碼流一定的環(huán)境下，單通道數(shù)據(jù)傳輸服務(wù)已可以滿足需求。但是，隨著用戶對視頻的要求越來越高，用戶對視頻流的分辨率的要求也從原先的QCIF發(fā)展到現(xiàn)在的CIF、D1。為了提高無線傳輸?shù)乃俾剩?因此目前出現(xiàn)了采用雙/多通道傳輸視頻流的無線前端設(shè)備，無線雙卡/多卡設(shè)備即因此而來，例如，對于無線雙卡設(shè)備，其原理是使用兩個無線網(wǎng)絡(luò)通道同時傳輸一路視頻碼流， 以此來提高傳輸速率?？蛻舳耸盏揭曨l流之后合并成為一路有效的視頻碼流。雙卡設(shè)備具有雙通道優(yōu)勢，能夠顯著提高在目前無線環(huán)境下的傳輸速率，實驗顯示，其傳輸速率較單通道數(shù)據(jù)傳輸平均能夠提高80%的傳輸速率。在中國專利《發(fā)明名稱一種多路徑無線視頻傳輸方法和系統(tǒng)，申請(專利)號 200810020904. 5》中已經(jīng)給出一種多路徑無線視頻傳輸方法，包括多路徑視頻的發(fā)送及接收處理。但該專利并沒有給出多路徑視頻接收模塊的具體方法；并且在多通道環(huán)境下接收視頻流時，可能存在視頻源非法、視頻流無效、丟包及抖動亂序等問題，從而使得視頻流的傳輸質(zhì)量得不到保障。

發(fā)明內(nèi)容
本發(fā)明實施例的目的在于提供一種多通道視頻流的傳輸方法及系統(tǒng)，其能針對多通道視頻流在接收過程中進行視頻源合法性驗證，視頻流數(shù)據(jù)合法性驗證等等，從而可以確保在客戶端獲得的視頻流數(shù)據(jù)的可靠性及準確性。本發(fā)明實施例的目的是通過以下技術(shù)方案實現(xiàn)的—種多通道視頻流的傳輸方法，其包括A、客戶端創(chuàng)建視頻接收模塊，并分配多個數(shù)據(jù)接收通道資源；B、客戶端向服務(wù)器發(fā)送媒體協(xié)商信息以請求視頻，其中，所述媒體協(xié)商信息包括視頻源驗證信息以及數(shù)據(jù)接收通道資源信息；C、服務(wù)器接受請求并向客戶端返回應答消息；D、客戶端根據(jù)所述應答消息確認服務(wù)器接受視頻請求，并向服務(wù)器發(fā)送確認消息 ACK (Acknowledge Character，確認字符)，同時打開視頻接收模塊；E、服務(wù)器收到客戶端發(fā)送的確認消息ACK后，向客戶端發(fā)送攜帶視頻源驗證信息和媒體同步源標識(SSRC，Synchronization source)的NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換，NetworkAddress Translation)穿越包；F、客戶端收到所述NAT穿越包之后，解析其中的視頻源驗證信息并進行視頻源合法性驗證，若驗證通過，則創(chuàng)建客戶端與服務(wù)器之間的數(shù)據(jù)鏈路；G、客戶端解析NAT穿越包中的媒體同步源標識SSRC，若解析成功，則保存并向服務(wù)器發(fā)送NAT響應包；H、服務(wù)器確認收到客戶端的NAT響應包后，通過多個數(shù)據(jù)發(fā)送通道向客戶端發(fā)送攜帶了媒體同步源標識SSRC的視頻數(shù)據(jù)包，若服務(wù)器未收到NAT響應包，則拒絕向客戶端發(fā)送視頻數(shù)據(jù)包；I、客戶端依據(jù)接收到的視頻數(shù)據(jù)包中的媒體同步源標識SSRC判斷視頻數(shù)據(jù)包的有效性，若媒體同步源標識SSRC合法，則對接收的視頻數(shù)據(jù)包依據(jù)視頻合并算法進行合并處理，否則，則丟棄相應的視頻數(shù)據(jù)包。優(yōu)選地，在所述步驟B中，客戶端通過會話初始協(xié)議向服務(wù)器請求視頻。優(yōu)選地，在所述步驟I中，判斷所述媒體同步源標識是否合法的方法是，將客戶端接收到的視頻數(shù)據(jù)包中的媒體同步源標識與存儲于客戶端中的媒體同步源標識進行比較， 若兩者相同，則為合法，否則，則為非法。優(yōu)選地，在所述步驟I中，所述視頻合并算法包括如下步驟(1)客戶端創(chuàng)建多通道視頻數(shù)據(jù)包的合并轉(zhuǎn)換緩沖區(qū)；(2)客戶端將接收到的視頻數(shù)據(jù)包依照視頻數(shù)據(jù)包的序號順序放入所述合并轉(zhuǎn)換緩沖區(qū)；(3)客戶端根據(jù)丟包檢測方法，檢測視頻數(shù)據(jù)包是否存在丟包，若檢測到丟包，則對接收到的視頻數(shù)據(jù)包進行容錯處理，并進行丟包統(tǒng)計；若未檢測到丟包，則按順序?qū)?shù)據(jù)包進行視頻合并處理；(4)將合并轉(zhuǎn)換緩沖區(qū)中已處理的視頻數(shù)據(jù)包清空，用于后續(xù)客戶端接收到的視頻數(shù)據(jù)包的處理。優(yōu)選地，所述丟包檢測方法包括客戶端開啟定時器，若客戶端超過預設(shè)的閾值時間仍未收到相應的視頻數(shù)據(jù)包，則判斷視頻數(shù)據(jù)包存在丟包。優(yōu)選地，所述丟包檢測方法包括(1)設(shè)定丟包檢測半徑DS和閾值計算函數(shù)F ；(2)設(shè)定合并轉(zhuǎn)換緩沖區(qū)中已收到的最大視頻數(shù)據(jù)包的序號MAX ；(3)檢測視頻數(shù)據(jù)包的序號，若序號小于丟包閾值TS的數(shù)據(jù)包未收到，則認為發(fā)生丟包，其中，所述丟包閾值TS的計算方法為TS = F (MAX, DS)。優(yōu)選地，所述計算函數(shù)F為線性函數(shù)，其中，F(xiàn) = MAX-DS0優(yōu)選地，所述NAT穿越包為RTSP或XML格式。優(yōu)選地，所述視頻數(shù)據(jù)包為RTP數(shù)據(jù)包。一種多通道視頻流的傳輸系統(tǒng)，包括客戶端以及服務(wù)器，其中，所述客戶端包括視頻接收模塊、視頻處理模塊以及客戶端會話模塊，所述服務(wù)器包括與所述視頻接收模塊匹配的視頻發(fā)送模塊以及服務(wù)器端會話模塊，所述客戶端會話模塊用以與服務(wù)器端會話模塊完成信令的交互，并控制所述視頻接收模塊接收服務(wù)器發(fā)送的視頻數(shù)據(jù)包，所述視頻處理模塊用以對所述視頻接收模塊接收的視頻數(shù)據(jù)包進行處理，所述服務(wù)器端會話模塊還控制視頻發(fā)送模塊向所述客戶端發(fā)送視頻數(shù)據(jù)包。由上述本發(fā)明實施例的技術(shù)方案可以看出，本發(fā)明提供的多通道視頻流的傳輸方法及系統(tǒng)具有如下優(yōu)勢1、客戶端通過在視頻請求協(xié)商過程中增加視頻源驗證信息來確保視頻源的合法性；2、對客戶端通過多通道接收到的視頻數(shù)據(jù)包進行有效性驗證，從而可以有效的過濾掉無效的視頻數(shù)據(jù)包信息。鑒于以上，采用本發(fā)明實施例提供的多通道視頻流的傳輸方法及系統(tǒng)可以提高視頻數(shù)據(jù)包傳輸以及接收的可靠性。


圖1是本發(fā)明一實施例提供的多通道視頻流的傳輸方法的方法流程示意圖；圖2是本發(fā)明一實施例提供的多通道視頻流的傳輸系統(tǒng)的系統(tǒng)組網(wǎng)示意圖；圖3是本發(fā)明一實施例提供的多通道視頻流的傳輸系統(tǒng)的系統(tǒng)結(jié)構(gòu)示意圖；圖4是本發(fā)明一實施例提供的視頻數(shù)據(jù)包合并循環(huán)隊列示意圖。本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)異效果，下面將結(jié)合具體實施例以及附圖做進一步的說明。
具體實施例方式下面結(jié)合附圖和具體實施例對本發(fā)明所述技術(shù)方案作進一步的詳細描述，以使本領(lǐng)域的技術(shù)人員可以更好的理解本發(fā)明并能予以實施，但所舉實施例不作為對本發(fā)明的限定。依照本發(fā)明一實施例提供的多通道視頻流的傳輸方法，如圖1所示，其包括如下步驟A、客戶端創(chuàng)建視頻接收模塊，并分配多個數(shù)據(jù)接收通道資源；B、客戶端向服務(wù)器發(fā)送媒體協(xié)商信息以請求視頻，其中，所述媒體協(xié)商信息包括視頻源驗證信息以及數(shù)據(jù)接收通道資源信息；C、服務(wù)器接受請求并向客戶端返回應答消息；D、客戶端根據(jù)所述應答消息確認服務(wù)器接受視頻請求，并向服務(wù)器發(fā)送確認消息 ACK,同時打開視頻接收模塊；E、服務(wù)器收到客戶端發(fā)送的確認消息ACK后，向客戶端發(fā)送攜帶視頻源驗證信息和媒體同步源標識SSRC的NAT穿越包，其中，所述NAT穿越包可以為RTSP或XML格式的結(jié)構(gòu)化字符串。F、客戶端收到所述NAT穿越包之后，解析其中的視頻源驗證信息并進行視頻源合法性驗證，若驗證通過，則創(chuàng)建客戶端與服務(wù)器之間的數(shù)據(jù)鏈路，其中創(chuàng)建所述數(shù)據(jù)鏈路可確保視頻源是客戶端所要請求的視頻源對象，從而防止串流；G、客戶端解析NAT穿越包中的媒體同步源標識SSRC，若解析成功，則保存并向服務(wù)器發(fā)送NAT響應包；H、服務(wù)器確認收到客戶端的NAT響應包后，通過多個數(shù)據(jù)發(fā)送通道向客戶端發(fā)送攜帶了媒體同步源標識SSRC的視頻數(shù)據(jù)包，若服務(wù)器未收到NAT響應包，則拒絕向客戶端發(fā)送視頻數(shù)據(jù)包；I、客戶端依據(jù)接收到的視頻數(shù)據(jù)包中的媒體同步源標識SSRC判斷視頻數(shù)據(jù)包的有效性，若媒體同步源標識SSRC合法，則對接收的視頻數(shù)據(jù)包依據(jù)視頻合并算法進行合并處理，否則，則丟棄相應的視頻數(shù)據(jù)包。
具體實施方式
中，在所述步驟B中，客戶端通過會話初始協(xié)議(Session Initiation Protocol, SIP)向服務(wù)器請求視頻，其攜帶的媒體協(xié)商信息可以通過會話描述協(xié)議(Session Description Protocol, SDP)表示，其中，此處所述的媒體協(xié)商信息包括視頻源驗證信息以及分配的數(shù)據(jù)接收通道資源信息。更為具體的，所述客戶端向服務(wù)器請求視頻的方法，包括步驟如下(1)客戶端向服務(wù)器發(fā)送媒體協(xié)商信息，以描述媒體信息和客戶端信息；(2)服務(wù)器接收到客戶端發(fā)送的媒體協(xié)商信息，與自身可提供的能力相比較，若可以提供客戶端所要求的媒體，則返回服務(wù)器的媒體協(xié)商信息，并接受客戶端的本次媒體請求；若不能提供客戶端的所有要求，則返回服務(wù)器目前所能提供的所有媒體能力，由客戶端決定是否重新請求；(3)客戶端收到服務(wù)器的媒體協(xié)商信息，若客戶端媒體請求已接受，則發(fā)送確認消息；否則由客戶端決定是否修改媒體協(xié)商信息并重新請求。通過上述視頻請求流程后，視頻請求控制信令的握手交互過程已經(jīng)完成。為確保視頻數(shù)據(jù)包能夠在私網(wǎng)與公網(wǎng)之間正確的傳輸，客戶端和服務(wù)器之間需要進行NAT穿越操作，以使網(wǎng)絡(luò)鏈路正常從而傳輸視頻數(shù)據(jù)包。對于上述的視頻數(shù)據(jù)包的NAT穿越方法，包括如下步驟(1)客戶端向服務(wù)器發(fā)送NAT穿越數(shù)據(jù)；(2)服務(wù)器接收到所述NAT穿越數(shù)據(jù)，并返回NAT響應包；(3)若網(wǎng)絡(luò)環(huán)境不穩(wěn)定，則對1、2步驟定時循環(huán)處理。通過上述NAT穿越操作，視頻傳輸通道已經(jīng)建立。為確保客戶端接收的視頻數(shù)據(jù)包來自合法的視頻源，客戶端應該對接收到的視頻數(shù)據(jù)包的視頻源進行合法性驗證。其中，視頻源合法性檢測方法，包括如下步驟(1)客戶端向服務(wù)器請求視頻時，發(fā)送的媒體協(xié)商信息中添加能夠唯一描述當前視頻源的視頻源驗證信息，如視頻源信息和客戶端隨機字符串信息的唯一組合；(2)服務(wù)器接收客戶端發(fā)送的視頻源驗證信息，并保存到本地；(3)服務(wù)器發(fā)送媒體協(xié)商信息中的視頻源驗證信息到客戶端；(4)客戶端接收服務(wù)器發(fā)送的視頻源驗證信息，與本地保存的視頻源驗證信息進行比較，以確定視頻源是否合法。通過檢測視頻源的合法性仍然不能確保接收到視頻流的合法性。在視頻流多通道傳輸情況下，客戶端與服務(wù)器之間存在多通道數(shù)據(jù)傳輸，若出現(xiàn)異?？赡軙嬖趹覓焱ǖ?通道未關(guān)閉或者延遲關(guān)閉)，懸掛通道可能會導致客戶端接收到異常的視頻數(shù)據(jù)包，因此，這里可以通過RTP數(shù)據(jù)包中存在的媒體同步源標識SSRC來判斷接收到的視頻數(shù)據(jù)包是否有效。優(yōu)選地，在所述步驟I中，判斷所述媒體同步源標識是否合法的方法是，將客戶端接收到的視頻數(shù)據(jù)包中的媒體同步源標識與存儲于客戶端中的媒體同步源標識進行比較， 若兩者相同，則為合法，否則，則為非法。更為具體地，視頻數(shù)據(jù)包的有效性檢測方法，包括步驟如下(1)服務(wù)器在進行視頻源合法性檢測之后，在向客戶端發(fā)送視頻數(shù)據(jù)包即RTP數(shù)據(jù)包之前，創(chuàng)建媒體同步源標識SSRC，并保存；(2)服務(wù)器將創(chuàng)建的媒體同步源標識SSRC發(fā)送給客戶端；(3)客戶端接收媒體同步源標識SSRC并保存以作為標竿的媒體同步源標識；(4)服務(wù)器發(fā)送攜帶媒體同步源標識SSRC的RTP數(shù)據(jù)包至客戶端；(5)客戶端接收服務(wù)器發(fā)送的RTP數(shù)據(jù)包，并利用存儲的標竿的媒體同步源標識與RTP數(shù)據(jù)包中攜帶的媒體同步源標識SSRC進行合法性檢測，若兩者相同，則認為RTP數(shù)據(jù)包有效；否則，對該RTP數(shù)據(jù)包丟棄。從NAT穿越、視頻源合法性檢測和視頻數(shù)據(jù)包的有效性檢測過程來看，在本發(fā)明另一實施例中，可以將視頻源合法性檢測以及視頻數(shù)據(jù)包的有效性檢測與NAT穿越過程合并，即在NAT穿越時攜帶視頻源驗證信息，由客戶端進行視頻源合法性驗證。同時在服務(wù)器發(fā)送至客戶端的NAT穿越包中攜帶媒體同步源標識SSRC作為檢驗后續(xù)發(fā)送的視頻數(shù)據(jù)包是否有效的標竿的媒體同步源標識。優(yōu)選地，在所述步驟I中，所述視頻合并算法包括如下步驟(1)客戶端創(chuàng)建多通道視頻數(shù)據(jù)包的合并轉(zhuǎn)換緩沖區(qū)；(2)客戶端將接收到的視頻數(shù)據(jù)包依照視頻數(shù)據(jù)包的序號順序放入所述合并轉(zhuǎn)換緩沖區(qū)；(3)客戶端根據(jù)丟包檢測方法，檢測視頻數(shù)據(jù)包是否存在丟包，若檢測到丟包，則對接收到的視頻數(shù)據(jù)包進行容錯處理，并進行丟包統(tǒng)計；若未檢測到丟包，則按順序?qū)?shù)據(jù)包進行視頻合并處理；(4)將合并轉(zhuǎn)換緩沖區(qū)中已處理的視頻數(shù)據(jù)包清空，用于后續(xù)客戶端接收到的視頻數(shù)據(jù)包的處理。依據(jù)本發(fā)明一實施例提供的視頻合并算法，在本實施例中，給出一種利用循環(huán)隊列的緩沖區(qū)來實現(xiàn)多路RTP數(shù)據(jù)包的合并，參見圖4，為本發(fā)明一實施例提供的視頻數(shù)據(jù)包合并循環(huán)隊列示意圖，該循環(huán)隊列長度L與丟包檢測半徑R之間的關(guān)系為L>= R0循環(huán)隊列的節(jié)點為一個三元組<SEQ，BUF, LEN>，其中SEQ表示RTP數(shù)據(jù)包的序號，BUF表示RTP 數(shù)據(jù)包的指針，LEN表示RTP數(shù)據(jù)包的長度，其中，循環(huán)隊列的空節(jié)點值為(0，NULL，0)。基于此，本RTP數(shù)據(jù)包合并算法描述如下注意下述算法中提到的RTP數(shù)據(jù)包的包序號不循環(huán)。(1)創(chuàng)建循環(huán)隊列，隊列長度為丟包檢測半徑；(2)初始化循環(huán)隊列的首節(jié)點位置為0，并將其所有節(jié)點值初始化為空；(3)初始化最大已提交包序號為0，初始化最大已接收包序號為0 ；(4)當接收到任意通道上的RTP數(shù)據(jù)包后，進行如下處理a、若包序號小于最大已提交包序號，則直接丟棄該包；b、若包序號大于最大已接收包序號，則更新最大已接收包序號為當前包序號；C、若包序號比最大已提交包序號大1，則提交客戶端進行視頻處理，并更新最大已提交包序號；d、否則按循環(huán)隊列的數(shù)據(jù)包插入算法將RTP數(shù)據(jù)包緩存到循環(huán)隊列；(5)算法結(jié)束。上述的丟包檢測半徑，可以依照如下方法設(shè)置對于丟包檢測半徑，在雙通道交叉?zhèn)鬏數(shù)那闆r下，隊列大小理論上可設(shè)為2 ；網(wǎng)絡(luò)環(huán)境較好時可設(shè)置為4或者8 ；若不確定如何選擇，則可以進行自適應調(diào)整，如當丟包率上升時，按2的冪次函數(shù)進行擴大；當丟包率下降時，按2的冪次函數(shù)進行縮小。其中，循環(huán)隊列的數(shù)據(jù)包插入算法可以表述如下(1)計算RTP數(shù)據(jù)包的緩存位置P，其中，計算方法為緩存位置P =收到包序號-最大已提交包序號；(2)若計算的緩存位置P溢出循環(huán)隊列大小，且溢出值為N，則按照循環(huán)隊列數(shù)據(jù)包提交算法處理本次緩沖區(qū)溢出，處理完成后轉(zhuǎn)到步驟(1)；否則轉(zhuǎn)到步驟(3)；(3)若緩存位置P = 1，則將P直接提交給上層處理，并更新最大已提交RTP數(shù)據(jù)包的包序號；否則將RTP數(shù)據(jù)包緩存到循環(huán)隊列相對于首節(jié)點位置為P的節(jié)點處，并更新該節(jié)點的值為<SEQ, BUF，LEN> ；(4)算法結(jié)束。其中，上述的循環(huán)隊列數(shù)據(jù)包提交算法包括如下步驟(1)初始化已處理的RTP數(shù)據(jù)包的數(shù)量為0 ；(2)若循環(huán)隊列首節(jié)點為空節(jié)點，則將首節(jié)點設(shè)置為下一結(jié)點，將當前節(jié)點對應的 RTP數(shù)據(jù)包加入丟包統(tǒng)計，更新最大已提交RTP數(shù)據(jù)包的包序號，更新已處理RTP數(shù)據(jù)包的
數(shù)量；(3)若循環(huán)隊列首節(jié)點為有效RTP數(shù)據(jù)包，則從首節(jié)點開始，將連續(xù)的有效RTP數(shù)據(jù)包提交給上層處理并清空已提交RTP數(shù)據(jù)包所占據(jù)的節(jié)點，直到空節(jié)點時停止，并將循環(huán)隊列的首節(jié)點移到該空節(jié)點處，更新最大已提交的RTP數(shù)據(jù)包的包序號，更新已處理的 RTP數(shù)據(jù)包的數(shù)量；(4)若已處理的RTP數(shù)據(jù)包的數(shù)量小于傳入的循環(huán)隊列溢出值，則轉(zhuǎn)到步驟O)；(5)算法結(jié)束。由于循環(huán)隊列的RTP數(shù)據(jù)包的提交是通過不斷接收新的RTP數(shù)據(jù)包來驅(qū)動的，當 RTP數(shù)據(jù)包已經(jīng)全部接收完畢時，對于循環(huán)隊列中的最后幾個RTP數(shù)據(jù)包的提交處理，可以按照如下方法處理，下述處理步驟也可稱為循環(huán)隊列尾包處理(1)RTCP(BYE)觸發(fā)收到RTCP的BYE消息時，將隊列中所有數(shù)據(jù)包提交處理。(2)丟棄尾包當循環(huán)隊列大小較小時，可以丟棄這些RTP數(shù)據(jù)包而不影響視頻質(zhì)量。(3)定時觸發(fā)處理主動清空循環(huán)隊列中的RTP剩余數(shù)據(jù)包，但定時出發(fā)處理可能會影響效率。優(yōu)選地，所述丟包檢測方法包括(1)設(shè)定丟包檢測半徑DS和閾值計算函數(shù)F;(2)設(shè)定合并轉(zhuǎn)換緩沖區(qū)中已收到的最大視頻數(shù)據(jù)包的序號MAX ；(3)檢測視頻數(shù)據(jù)包的序號，若序號小于丟包閾值TS的數(shù)據(jù)包未收到，則認為發(fā)
9生丟包，其中，所述丟包閾值TS的計算方法為TS = F (MAX, DS)。優(yōu)選地，所述計算函數(shù)F為線性函數(shù)，其中，F(xiàn) = MAX-DS0如圖1以及圖2所示，圖1為本發(fā)明一實施例提供的多通道視頻流的傳輸系統(tǒng)的系統(tǒng)組網(wǎng)示意圖，圖2為本發(fā)明一實施例提供的多通道視頻流的傳輸系統(tǒng)的系統(tǒng)結(jié)構(gòu)示意圖，所述多通道視頻流的傳輸系統(tǒng)包括客戶端1以及服務(wù)器，其中，所述客戶端1包括視頻接收模塊10、視頻處理模塊11以及客戶端會話模塊12，所述服務(wù)器2包括與所述視頻接收模塊10匹配的視頻發(fā)送模塊20以及服務(wù)器端會話模塊21，所述客戶端會話模塊12用以與服務(wù)器端會話模塊21完成信令的交互，并控制所述視頻接收模塊10接收服務(wù)器2發(fā)送的視頻數(shù)據(jù)包，所述視頻處理模塊11用以對所述視頻接收模塊10接收的視頻數(shù)據(jù)包進行處理，所述服務(wù)器端會話模塊21還控制視頻發(fā)送模塊20向所述客戶端1發(fā)送視頻數(shù)據(jù)包。 其中，所述視頻發(fā)送模塊20可以通過多個數(shù)據(jù)發(fā)送通道向所述客戶端1包括的視頻接收模塊10發(fā)送視頻流，在具體的實施過程中，所述視頻發(fā)送模塊20可以提供兩路數(shù)據(jù)發(fā)送通道或者更多，其對應的硬件可以為無線雙卡設(shè)備或無線多卡設(shè)備，這里對所述設(shè)備的具體型號以及參數(shù)不做限制。繼續(xù)參照圖2和圖3，客戶端1向服務(wù)器2請求視頻可以通過會話初始協(xié)議 (Session Initiation Protocol, SIP)發(fā)起請求，其攜帶的媒體協(xié)商信息可以通過會話描述協(xié)議(Session Description Protocol, SDP)表示，其中，所述媒體協(xié)商信息包括視頻源驗證信息以及分配的數(shù)據(jù)接收通道資源信息。在媒體協(xié)商信息SDP消息中，客戶端1主動添加視頻源驗證信息。視頻源驗證信息可以表示為視頻源信息，例如視頻信息的RTSP URL,并增加客戶端1隨機字符串信息與所述視頻源信息進行唯一組合，從而以防止唯一性沖突， 若為安全考慮，還可以對驗證信息進行加密處理。視頻流合法性的驗證方法，可以通過服務(wù)器向客戶端1發(fā)送有效的RTP數(shù)據(jù)包的媒體同步源標識SSRC值作為視頻流合法性標識，后續(xù)通過所有通道接收到的RTP數(shù)據(jù)包均需要和該媒體同步源標識SSRC進行比對并判斷，若與之相同，則判斷出數(shù)據(jù)包合法，否則非法。當收到多路合法的RTP數(shù)據(jù)包后，客戶端1包括的所述視頻處理模塊對所述RTP數(shù)據(jù)包進行數(shù)據(jù)合并處理，從而完成多通道視頻流的傳輸過程。由上述本發(fā)明實施例的技術(shù)方案可以看出，本發(fā)明提供的多通道視頻流的傳輸方法及系統(tǒng)具有如下優(yōu)勢1、客戶端1通過在視頻請求協(xié)商過程中增加視頻源驗證信息來確保視頻源的合法性；2、對客戶端1通過多通道接收到的視頻數(shù)據(jù)包進行有效性驗證，從而可以有效的過濾掉無效的視頻數(shù)據(jù)包信息。鑒于以上，采用本發(fā)明實施例提供的多通道視頻流的傳輸方法及系統(tǒng)可以提高視頻數(shù)據(jù)包傳輸以及接收的可靠性。以上所述僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護范圍內(nèi)。
10
權(quán)利要求
1. 一種多通道視頻流的傳輸方法，其特征在于，包括A、客戶端創(chuàng)建視頻接收模塊，并分配多個數(shù)據(jù)接收通道資源；B、客戶端向服務(wù)器發(fā)送媒體協(xié)商信息以請求視頻，其中，所述媒體協(xié)商信息包括視頻源驗證信息以及數(shù)據(jù)接收通道資源信息；C、服務(wù)器接受請求并向客戶端返回應答消息；D、客戶端根據(jù)所述應答消息確認服務(wù)器接受視頻請求，并向服務(wù)器發(fā)送確認消息，同時打開視頻接收模塊；E、服務(wù)器收到客戶端發(fā)送的確認消息后，向客戶端發(fā)送攜帶視頻源驗證信息和媒體同步源標識的NAT穿越包；F、客戶端收到所述NAT穿越包之后，解析其中的視頻源驗證信息并進行視頻源合法性驗證，若驗證通過，則創(chuàng)建客戶端與服務(wù)器之間的數(shù)據(jù)鏈路；G、客戶端解析NAT穿越包中的媒體同步源標識，若解析成功，則保存并向服務(wù)器發(fā)送 NAT響應包；H、服務(wù)器確認收到客戶端的NAT響應包后，通過多個數(shù)據(jù)發(fā)送通道向客戶端發(fā)送攜帶了媒體同步源標識的視頻數(shù)據(jù)包，若服務(wù)器未收到NAT響應包，則拒絕向客戶端發(fā)送視頻數(shù)據(jù)包；I、客戶端依據(jù)接收到的視頻數(shù)據(jù)包中的媒體同步源標識判斷視頻數(shù)據(jù)包的有效性，若媒體同步源標識合法，則對接收的視頻數(shù)據(jù)包依據(jù)視頻合并算法進行合并處理，否則，則丟棄相應的視頻數(shù)據(jù)包。
2.如權(quán)利要求1所述的多通道視頻流的傳輸方法，其特征在于，在所述步驟B中，客戶端通過會話初始協(xié)議向服務(wù)器請求視頻。
3.如權(quán)利要求1所述的多通道視頻流的傳輸方法，其特征在于，在所述步驟I中，判斷所述媒體同步源標識是否合法的方法是，將客戶端接收到的視頻數(shù)據(jù)包中的媒體同步源標識與存儲于客戶端中的媒體同步源標識進行比較，若兩者相同，則為合法，否則，則為非法。
4.如權(quán)利要求1所述的多通道視頻流的傳輸方法，其特征在于，在所述步驟I中，所述視頻合并算法包括如下步驟(1)客戶端創(chuàng)建多通道視頻數(shù)據(jù)包的合并轉(zhuǎn)換緩沖區(qū)；(2)客戶端將接收到的視頻數(shù)據(jù)包依照視頻數(shù)據(jù)包的序號順序放入所述合并轉(zhuǎn)換緩沖區(qū)；(3)客戶端根據(jù)丟包檢測方法，檢測視頻數(shù)據(jù)包是否存在丟包，若檢測到丟包，則對接收到的視頻數(shù)據(jù)包進行容錯處理，并進行丟包統(tǒng)計；若未檢測到丟包，則按順序?qū)?shù)據(jù)包進行視頻合并處理；(4)將合并轉(zhuǎn)換緩沖區(qū)中已處理的視頻數(shù)據(jù)包清空，用于后續(xù)客戶端接收到的視頻數(shù)據(jù)包的處理。
5.如權(quán)利要求4所述的多通道視頻流的傳輸方法，其特征在于，所述丟包檢測方法包括客戶端開啟定時器，若客戶端超過預設(shè)的閾值時間仍未收到相應的視頻數(shù)據(jù)包，則判斷視頻數(shù)據(jù)包存在丟包。
6.如權(quán)利要求4所述的多通道視頻流的傳輸方法，其特征在于，所述丟包檢測方法包括(1)設(shè)定丟包檢測半徑DS和閾值計算函數(shù)F；(2)設(shè)定合并轉(zhuǎn)換緩沖區(qū)中已收到的最大視頻數(shù)據(jù)包的序號MAX；(3)檢測視頻數(shù)據(jù)包的序號，若序號小于丟包閾值TS的數(shù)據(jù)包未收到，則認為發(fā)生丟包，其中，所述丟包閾值TS的計算方法為TS = F(MAX, DS)。
7.如權(quán)利要求6所述的多通道視頻流的傳輸方法，其特征在于，所述計算函數(shù)F為線性函數(shù)，其中，F(xiàn) = MAX-DS0
8.如權(quán)利要求1所述的多通道視頻流的傳輸方法，其特征在于，所述NAT穿越包為 RTSP或XML格式。
9.如權(quán)利要求1所述的多通道視頻流的傳輸方法，其特征在于，所述視頻數(shù)據(jù)包為RTP 數(shù)據(jù)包。
10.一種多通道視頻流的傳輸系統(tǒng)，包括客戶端以及服務(wù)器，其特征在于，所述客戶端包括視頻接收模塊、視頻處理模塊以及客戶端會話模塊，所述服務(wù)器包括與所述視頻接收模塊匹配的視頻發(fā)送模塊以及服務(wù)器端會話模塊，所述客戶端會話模塊用以與服務(wù)器端會話模塊完成信令的交互，并控制所述視頻接收模塊接收服務(wù)器發(fā)送的視頻數(shù)據(jù)包，所述視頻處理模塊用以對所述視頻接收模塊接收的視頻數(shù)據(jù)包進行處理，所述服務(wù)器端會話模塊還控制視頻發(fā)送模塊向所述客戶端發(fā)送視頻數(shù)據(jù)包。
全文摘要
本發(fā)明公開了一種多通道視頻流的傳輸方法及系統(tǒng)，包括客戶端以及服務(wù)器，所述客戶端包括視頻接收模塊、視頻處理模塊以及客戶端會話模塊，所述服務(wù)器包括多個與所述視頻接收模塊匹配的視頻發(fā)送模塊以及服務(wù)器端會話模塊，所述客戶端會話模塊用以與服務(wù)器端會話模塊完成信令的交互，并控制所述視頻接收模塊接收服務(wù)器發(fā)送的視頻數(shù)據(jù)包，所述視頻處理模塊用以對所述視頻接收模塊接收的視頻數(shù)據(jù)包進行處理，所述服務(wù)器端會話模塊還控制視頻發(fā)送模塊向所述客戶端發(fā)送視頻數(shù)據(jù)包。本發(fā)明的客戶端通過在視頻請求協(xié)商過程中增加視頻源合法性驗證及視頻數(shù)據(jù)包的有效性驗證，從而可以提高視頻流傳輸?shù)恼_性和可靠性。
文檔編號H04N21/647GK102231863SQ201110148239
公開日2011年11月2日 申請日期2011年6月2日 優(yōu)先權(quán)日2011年6月2日
發(fā)明者張欣慰, 林大鐮, 謝斌 申請人:南京中興力維軟件有限公司