專利名稱::視頻數(shù)據(jù)的實時傳輸方法
技術(shù)領(lǐng)域:
:本發(fā)明涉及+某體數(shù)據(jù)傳輸方法,特別涉及H.264視頻數(shù)據(jù)的實時傳輸方法。
背景技術(shù):
:隨著計算機互聯(lián)網(wǎng)(Internet)和移動通信網(wǎng)絡(luò)的飛速發(fā)展,流媒體技術(shù)的應(yīng)用越來越廣泛,從網(wǎng)絡(luò)電視、網(wǎng)絡(luò)電影到網(wǎng)絡(luò)遠程教學和安全監(jiān)控系統(tǒng)以及在線提供媒體服務(wù)的新聞或媒體網(wǎng)站都應(yīng)用了流媒體技術(shù)。流媒體是以流式(Streaming)傳輸音視頻數(shù)據(jù),流式傳輸又分為順序流(ProgressiveStreaming)與實時流(RealtimeStreaming)兩種傳輸方式,其中實時流式傳輸特別適合現(xiàn)場事件,因而在網(wǎng)絡(luò)電^見和安全監(jiān)控系統(tǒng)業(yè)務(wù)中廣泛應(yīng)用。隨著第三代通信系統(tǒng)(3rdGeneration,簡稱"3G")的研究深入和基于網(wǎng)際協(xié)議(InternetProtocol,簡稱"IP")的網(wǎng)絡(luò)迅速發(fā)展,視頻通信已經(jīng)成為通信的主要業(yè)務(wù)之一。雙方或多方的^L頻通信業(yè)務(wù),如可視電話、;f見頻會議、移動終端視頻服務(wù)等,對媒體數(shù)據(jù)傳輸?shù)姆?wù)質(zhì)量提出更高的要求,不僅要求數(shù)據(jù)傳輸實時性更好,同時也要求數(shù)據(jù)壓縮編碼效率更高。鑒于媒體通信的需求現(xiàn)狀,國際電信聯(lián)盟標準部(InternationalTelecommunicationUnionTelecommunicationStandardizationSector,筒稱"ITU-T")繼制定了H.261、H.263、H263+等視頻壓縮標準之后,于2003年正式發(fā)布了H.264標準。這是ITU-T和國際標準化組織(InternationalStandardizationOrganization,簡稱"ISO")的運動專家組(MovingPictureExpertsGro叩,簡稱"MPEG")—起聯(lián)合制定的適應(yīng)新階段網(wǎng)絡(luò)媒體傳輸及通訊需求的高效壓縮編碼標準。它同時也是MPEG-4第IO部分的主要內(nèi)容。H.264能夠更加有效地提高視頻編碼效率和對網(wǎng)絡(luò)的適配性,因此,H.264已經(jīng)逐漸成為當前多i某體通信中的主流標準。如前所迷多媒體通信不僅要求高效的媒體壓縮編碼標準算法,同時也要求媒體數(shù)據(jù)傳輸?shù)膶崟r性。當前多媒體數(shù)據(jù)流均采用實時傳輸協(xié)議(Real-timeTransportProtocol,簡稱"RTP")及其控制協(xié)議(Real-timeTransportControlProtocol,簡稱"RTCP")。其中,RTP是針對Internet上多媒體數(shù)據(jù)流動的一個傳輸協(xié)議,由互聯(lián)網(wǎng)工程任務(wù)組(InternetEngineeringTaskForce,簡稱"正TF")發(fā)布。正TF針對H.264標準制定了RTP凈載荷(Payload)的打包方法,即RFC3984:RTPPayloadforH.264Video。該標準目前是H.264視頻流在IP網(wǎng)絡(luò)上傳輸?shù)闹饕獦藴省.264和以往其他視頻壓縮編碼協(xié)議不同的關(guān)鍵地方在于H.264定義了一個新層面,稱為網(wǎng)絡(luò)抽象層(NetworkAbstractLayer,簡稱"NAL")。的技術(shù)方案,該方案在RTP協(xié)議(RFC3550)基礎(chǔ)上,將NAL層數(shù)據(jù)封裝在RTP靜栽荷中進行承載,將視頻碼流按照定義的規(guī)則和結(jié)構(gòu),分割成一連串的NAL數(shù)據(jù)單元(NALUnits,簡稱"NALU")。在RFC3984中詳細定義了RTP凈荷對于NALU的封裝格式。首先介紹RFC3550中對RTP頭的定義,如圖1所示,其中version(V):版本信息,目前版本為2;padding(P):填充標識,P如果置位,則表示數(shù)據(jù)包末尾包含一個或多個填充字節(jié);extension(X):擴展標識,X如果置位,則表示RTP頭后添加一個可變長的擴展;CSRCcount(CC):貢獻源資源數(shù)目,標明RTP頭中附帶的CSRC標識符個數(shù);marker(M):標記域,該標記的意義對于不同的有效負荷類型有不同的意義;payloadtype(PT):載荷類型,由RTP會話雙方協(xié)商約定;sequencenumber:RTP包序號;Timestamp:RTP時戳;SSRC:同步資源標識域,由RTP會話雙方約定采用的32位標識;CSRClist:貢獻源資源列表,可根據(jù)需要為0-15項,每項各占32位。RFC3984中對SingleNALunit載荷格式的定義,如圖2所示。一個SingleNALunit封裝的RTP包,如圖3所示。目前,安裝在手機或公共汽車等可移動設(shè)備上的媒體播放終端通過網(wǎng)絡(luò)側(cè)設(shè)備接收上述I1264視頻編碼格式的視頻節(jié)目時,若網(wǎng)絡(luò)帶寬充足,網(wǎng)絡(luò)側(cè)設(shè)備可以正常工作,如圖4所示。但媒體播放終端由于受到移動服務(wù)網(wǎng)絡(luò)帶寬和覆蓋狀況的特殊限制,不能總是獲得一個穩(wěn)定充足的節(jié)目服務(wù)帶寬,例如在網(wǎng)絡(luò)覆蓋不理想的區(qū)域或高樓大廈過于密集的地方,移動網(wǎng)絡(luò)將不能提供理想的網(wǎng)絡(luò)服務(wù)帶寬,此時將導致視頻數(shù)據(jù)在傳輸中出現(xiàn)隨機丟失,節(jié)目播放出現(xiàn)馬賽克或花屏的現(xiàn)象,從而導致觀看效果惡化,服務(wù)質(zhì)量降低,如圖5所示。因此,需要提出一種保證服務(wù)質(zhì)量的H.264媒體數(shù)據(jù)實時傳輸?shù)姆椒ā?br/>發(fā)明內(nèi)容本發(fā)明所要解決的技術(shù)問題是,提供一種視頻數(shù)據(jù)的實時傳輸方法,以提高RTP協(xié)議承載H.264多媒體視頻數(shù)據(jù)的服務(wù)質(zhì)量。為解決上述問題,本發(fā)明公開了一種視頻數(shù)據(jù)的實時傳輸方法,包括構(gòu)造RTP數(shù)據(jù)包時,判斷當前RTP數(shù)據(jù)包是否攜帶參考幀數(shù)據(jù),如果是,則在所述RTP數(shù)據(jù)包的頭域中添加有效的參考幀信息,所述有效的參考幀信息用于表示該RTP數(shù)據(jù)包中攜帶了參考幀數(shù)據(jù);當目的移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,々某體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備僅向下發(fā)送攜帶有效參考幀信息的RTP數(shù)據(jù)包。進一步地,上述方法中,所述i某體服務(wù)器判斷所述移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,將攜帶有效參考幀信息的RTP數(shù)據(jù)包直4妄進一步地,上述方法中,所述中間網(wǎng)絡(luò)傳輸設(shè)備收到所述RTP數(shù)據(jù)包后,判斷如果所述移動終端當前所處網(wǎng)絡(luò)月l務(wù)帶寬小于服務(wù)帶寬門限時,將攜帶有效參考幀信息的RTP數(shù)據(jù)包發(fā)送到所述移動終端。其中,所述有效的參考幀信息還包含了表示所述RTP數(shù)據(jù)包攜帶的是否為完整的參考幀數(shù)據(jù)的信息。當所述有效的參考幀信息包含了表示RTP數(shù)據(jù)包攜帶的不是完整的參考幀數(shù)據(jù)時,所述有效的參考幀信息還包含了表示所述RTP數(shù)據(jù)包攜帶的是頭部、中部或者尾部參考幀數(shù)據(jù)的信息。進一步地,上述方法中,若判斷當前RTP數(shù)據(jù)包中沒有攜帶參考幀數(shù)據(jù)時,在所述RTP數(shù)據(jù)包的頭域中添加無效的參考幀信息,所述無效的參考幀信息用于表示該RTP數(shù)據(jù)包沒有攜帶參考幀數(shù)據(jù)。其中,當移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,媒體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備將所述攜帶無效參考幀信息的RTP數(shù)據(jù)包丟棄或者緩存。所述參考幀信息添加在所述RTP數(shù)據(jù)包頭域的擴展字段。本發(fā)明技術(shù)方案使得節(jié)目能夠正常播放的最低帶寬需求得以有效降低,從而將減少々某體數(shù)據(jù)在傳輸中隨機地丟失,解決視頻播放馬賽克與花屏的問題。圖1是RFC3550中定義的RTP標準頭域的示意圖2是RFC3984中定義的SingleNALunit栽荷格式示意圖3是根據(jù)RFC3984中定義的SingleNALunitRTP封裝格式示意圖4是移動網(wǎng)絡(luò)服務(wù)帶寬充足,移動終端正常服務(wù)的示意圖5是目前通常情況下,移動網(wǎng)絡(luò)服務(wù)帶寬不足,服務(wù)質(zhì)量降低的示意圖6是本實施例中一個包含有完整H.264參考幀的RTP擴展域格式;圖7是本實施例中一個包含有H.264參考幀頭部的RTP擴展域格式。具體實施例方式本發(fā)明的主要構(gòu)思是,在10^擴展頭域中增加11264的參考幀信息,這樣,當移動終端所處地域網(wǎng)絡(luò)服務(wù)帶寬不理想時,々某體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備(如網(wǎng)關(guān)、路由器等)根據(jù)RTP包擴展頭域中的H.264參考幀信息,僅對包含有H.264參考幀的媒體數(shù)據(jù)進行發(fā)送或傳輸,這樣可以保證重要數(shù)據(jù)在傳輸過程中的優(yōu)先性,即優(yōu)先保證對H.264參考幀數(shù)據(jù)的傳輸,從而為提高RTP協(xié)議承載H.264多媒體視頻數(shù)據(jù)的服務(wù)質(zhì)量提供高效可靠的依據(jù)。其中,參考幀是指包含以靜態(tài)圖片、形狀等圖像關(guān)鍵信息為主的一種完整可單獨解碼的的幀,參考幀可作為其他預(yù)測類型幀的參考。下面結(jié)合附圖及具體實施方式對本發(fā)明技術(shù)方案作進一步詳細說明。在H.264多媒體數(shù)據(jù)實時傳輸中,媒體服務(wù)器與中間網(wǎng)絡(luò)傳輸設(shè)備事先協(xié)商RTP頭域中用于描述H.264參考幀信息的擴展字段的定義,本實施例中,H.264RTP頭域中擴展字段的定義如表1所示,具體傳輸過程為步驟101:在對RTP視頻數(shù)據(jù)進行打包的過程中,構(gòu)造RTP數(shù)據(jù)包頭域,其中對RTP數(shù)據(jù)包頭域中擴展標識位extension(X)置位,即表示在此RTP頭域后添加有一個RTP頭域的擴展字段;步驟102:判斷該RTP數(shù)據(jù)包中攜帶部分或者全部參考幀數(shù)據(jù)后,按照表1中的格式生成RTP頭域的擴展字段,該擴展字段用于描述RTP數(shù)據(jù)包中參考幀信息,即該RTP數(shù)據(jù)包中是否存在參考幀數(shù)據(jù),當該RTP數(shù)據(jù)包中存在有參考幀數(shù)據(jù)時,該擴展字段進一步表明該RTP數(shù)據(jù)包中參考幀數(shù)據(jù)的具體信息,如位置以及參考幀數(shù)據(jù)是否完整等;表1為H.264RTP數(shù)據(jù)包頭域中擴展字段語法表<table>tableseeoriginaldocumentpage8</column></row><table><table>tableseeoriginaldocumentpage9</column></row><table>其中,defined—by_profile,用于表示本擴展字段是否采用表1所定義的方式,在本實施例中,采用表1所定義的方式時,defined—by_profile固定為0x5A58;Length,用于表示headerextension(RTP頭域擴展)的長度,本實施例中headerextension的長度為1個32位雙字;M,用于表明本擴展字l炎的標識,本實施例中,Id值為3;Len,用于表明隨后的H.264視頻標示擴展長度,即Ijframe—indicator和Reserved的長度總和,本實施例中Len值為2;I一frame一indicator:用于表明該RTP數(shù)據(jù)包中是否有參考幀數(shù)據(jù),所述參考幀即為I幀(Iframe,關(guān)鍵幀),當RTP數(shù)據(jù)包中有參考幀數(shù)據(jù)時,I—frame—indicator還用于表明該RTP數(shù)據(jù)包中所包含的參考幀數(shù)據(jù)的具體信息,如位置以及參考幀數(shù)據(jù)是否完整等;在本實施例中,I_frame_indicator為OxO表示當前RTP包不含參考幀數(shù)據(jù);0x1表示當前RTP包為參考幀首數(shù)據(jù)包;0x2表示當前RTP包為參考幀中間數(shù)據(jù)包;0x4表示當前RTP包為參考幀尾數(shù)據(jù)包;0x7表示當前RTP包為完整參考幀。Reserved:用于表示保留字段,本實施例中填充為O。步驟103:根據(jù)已構(gòu)造的RTP數(shù)據(jù)包頭域,以及H.264RTP載荷,生成RTP數(shù)據(jù)包,媒體服務(wù)器將該數(shù)據(jù)包括發(fā)送到中間網(wǎng)絡(luò)傳輸設(shè)備。中間網(wǎng)絡(luò)傳輸設(shè)備收到上述RTP數(shù)據(jù)包,進行如下處理步驟201:中間網(wǎng)絡(luò)傳輸設(shè)備判斷移動終端當前所處地域網(wǎng)絡(luò)服務(wù)帶寬是否理想,即移動終端當前所處地域網(wǎng)絡(luò)服務(wù)帶寬是否小于服務(wù)帶寬門限(可以是正常傳輸時所需要的最小帶寬),如果是,進入步驟202,否則將收到的數(shù)據(jù)包發(fā)送到移動終端;步驟202:中間網(wǎng)絡(luò)傳輸設(shè)備從收到的RTP數(shù)據(jù)包頭域的擴展字段中讀取參考幀信息,若參考幀信息有效則表明該RTP數(shù)據(jù)包中存在部分或者全部參考幀數(shù)據(jù),中間網(wǎng)絡(luò)傳輸設(shè)備將該RTP數(shù)據(jù)包發(fā)送到移動終端,若參考幀信息無效表明該RTP數(shù)據(jù)包未包括任何參考幀數(shù)據(jù),中間網(wǎng)絡(luò)傳輸設(shè)備將該RTP數(shù)據(jù)包丟棄或者緩存。上述流程中,生成的RTP數(shù)據(jù)包中可以攜帶整個參考幀數(shù)據(jù),也可以僅攜帶參考幀開頭部分;當101>數(shù)據(jù)包中包含完整的圧264視頻參考幀的數(shù)據(jù)時,視頻數(shù)據(jù)包頭域中擴展字段的內(nèi)容如圖4所示;當RTP數(shù)據(jù)包中僅包含H.264視頻參考幀的開頭部分時,RTP數(shù)據(jù)包頭域中擴展字段內(nèi)容如圖5所示。本實施例中,基于或參考RFC3550構(gòu)造RTP數(shù)據(jù)包頭域,在其它實施例中,也可以基于或者參考其它規(guī)范,如RFC3984,構(gòu)造RTP數(shù)據(jù)包頭域。在上述實施例中,生成RTP數(shù)據(jù)包后,媒體服務(wù)器先判斷移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬是否小于服務(wù)帶寬門限,如果是,則僅將攜帶有效參考幀信息的RTP數(shù)據(jù)包通過中間網(wǎng)絡(luò)傳輸設(shè)備發(fā)送到移動終端;當然在其它實施例中,媒體服務(wù)器也可以省略中間網(wǎng)絡(luò)傳輸設(shè)備轉(zhuǎn)發(fā)RTP數(shù)據(jù)包的過程,此時,生成RTP數(shù)據(jù)包后,若i某體服務(wù)器判斷移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限,則i某體服務(wù)器僅將攜帶有效參考幀信息的RTP數(shù)據(jù)包直接發(fā)送到移動終端。從上述實施例可以看出,本發(fā)明技術(shù)方案在帶寬服務(wù)不理想的情況下,保證重要數(shù)據(jù)在傳輸過程中的優(yōu)先性,即優(yōu)先保證對H.264參考幀數(shù)據(jù)的傳輸,從而為提高RTP協(xié)議承載H.264多媒體視頻數(shù)據(jù)的服務(wù)質(zhì)量提供高效可靠的依據(jù)。本發(fā)明還可有其他多種實例中,在不背離本發(fā)明的精神及其實質(zhì)的情況下,本領(lǐng)域的技術(shù)人員可根據(jù)本發(fā)明作出相應(yīng)的改變和變形,但這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護范圍之內(nèi)。權(quán)利要求1、一種視頻數(shù)據(jù)的實時傳輸方法,其特征在于,構(gòu)造實時傳輸協(xié)議RTP數(shù)據(jù)包時,判斷當前RTP數(shù)據(jù)包是否攜帶參考幀數(shù)據(jù),如果是,則在所述RTP數(shù)據(jù)包的頭域中添加有效的參考幀信息,所述有效的參考幀信息用于表示該RTP數(shù)據(jù)包中攜帶了參考幀數(shù)據(jù);當目的移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,媒體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備僅向下發(fā)送攜帶有效參考幀信息的RTP數(shù)據(jù)包。2、如權(quán)利要求l所述的方法,其特征在于,所述媒體服務(wù)器判斷所述移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,將攜帶有效參考幀信息的RTP數(shù)據(jù)包直接發(fā)送給所述移動終端或者通過所述中間網(wǎng)絡(luò)傳輸設(shè)備轉(zhuǎn)發(fā)給所述移動終端。3、如權(quán)利要求l所述的方法,其特征在于,所述中間網(wǎng)絡(luò)傳輸4殳備收到所述RTP數(shù)據(jù)包后,判斷如果所述移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,將攜帶有效參考幀信息的RTP數(shù)據(jù)包發(fā)送到所述移動終端。4、如權(quán)利要求2或3所述的方法,其特征在于,所述有效的參考幀信息還包含了表示所述RTP數(shù)據(jù)包攜帶的是否為完整的參考幀數(shù)據(jù)的信息。5、如權(quán)利要求4所述的方法,其特征在于,當所述有效的參考幀信息包含了表示RTP數(shù)據(jù)包攜帶的不是完整的參考幀數(shù)據(jù)時,所述有效的參考幀信息還包含了表示所述RTP數(shù)據(jù)包攜帶的是頭部、中部或者尾部參考幀數(shù)據(jù)的信息。6、如權(quán)利要求l所述的方法,其特征在于,若判斷當前RTP數(shù)據(jù)包中沒有攜帶參考幀數(shù)據(jù)時,在所述RTP數(shù)據(jù)包的頭域中添加無效的參考幀信息,所述無效的參考幀信息用于表示該RTP數(shù)據(jù)包沒有攜帶參考幀數(shù)據(jù)。7、如權(quán)利要求6所述的方法,其特征在于,當移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,媒體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備將所述攜帶無效參考幀信息的RTP數(shù)據(jù)包丟棄或者緩存。8、如權(quán)利要求l、2、3、5、6或7中任一權(quán)利要求所述的方法,其特征在于,所述參考幀信息添加在所述RTP數(shù)據(jù)包頭域的擴展字段。全文摘要本發(fā)明涉及媒體數(shù)據(jù)傳輸方法,特別一種視頻數(shù)據(jù)的實時傳輸方法。本發(fā)明方法,構(gòu)造RTP數(shù)據(jù)包時,判斷當前RTP數(shù)據(jù)包是否攜帶參考幀數(shù)據(jù),如果是,則在所述RTP數(shù)據(jù)包的頭域中添加有效的參考幀信息,所述有效的參考幀信息用于表示該RTP數(shù)據(jù)包中攜帶了參考幀數(shù)據(jù);當目的移動終端當前所處網(wǎng)絡(luò)服務(wù)帶寬小于服務(wù)帶寬門限時,媒體服務(wù)器或者中間網(wǎng)絡(luò)傳輸設(shè)備僅向下發(fā)送攜帶有效參考幀信息的RTP數(shù)據(jù)包。本發(fā)明技術(shù)方案使得節(jié)目能夠正常播放的最低帶寬需求得以有效降低,從而將減少媒體數(shù)據(jù)在傳輸中隨機地丟失,解決視頻播放馬賽克與花屏的問題。文檔編號H04N7/24GK101646074SQ20081014448公開日2010年2月10日申請日期2008年8月5日優(yōu)先權(quán)日2008年8月5日發(fā)明者盧王飛申請人:中興通訊股份有限公司