寬帶網絡mpeg4的性能分析與應用

隨著互聯網的快速發展，網絡基礎設施得到了充分發展，寬網絡用戶也在迅速增長。他們為網絡媒體應用提供了強大的市場動力。視頻點播(VideoOnDemand,VOD)則是網絡流媒體應用的主要模式之一。MPEG-4是MPEG提出的一個基于對象的音頻、視頻壓縮編碼標準,它正在不斷地走向成熟,逐步成為音/視頻應用中不可或缺的一個基礎標準。MPEG-4具有的高壓縮率、強交互能力和靈活可分級能力使之在網絡流媒體特別是視頻點播中具有廣闊的應用前景。MEPG-4的RTP(Real-timeTransportProtocol)封裝技術則是這些應用的基石。1層組幀rtp由IETF定義的RTP是一種用于Internet上針對多媒體數據流的傳輸協議。RTP并不作為一個獨立的網絡層來實現,它采用應用層組幀的理念,作為應用程序代碼的一部分,針對一個具體媒體的應用需要額外的文檔定義封裝規則。RTP本身并不能為數據包提供可靠的傳輸機制,也不提供流量控制或擁塞控制,它依靠RTCP(Real-timeTransportControlProtocol)來提供這些服務。RTP和RTCP的配合使用使得它們能以有效的反饋和最小的開銷達到傳輸效率最佳化,因而特別適合網絡流媒體的應用。1.1mpeg-4封裝層次實現基于MPEG-4的網絡流媒體系統的關鍵是如何將MPEG-4的媒體數據封裝成RTP包。MPEG-4擁有一個開放體系結構,完整的體系結構里包含了基本流層、同步(SyncLayer,SL)層和傳輸復合(FlexMux)層等。在互聯網上既可實現簡化的MPEG-4體系結構,也可實現完整的MPEG-4體系結構。MPEG-4的RTP封裝,對應MPEG-4體系結構的層次,封裝的層次越高,其所需要的附加載荷就越多,相應的解包和封包的復雜度就越大;封裝的層次越高,對媒體的感知能力就越低,對于媒體的差錯處理能力越低。但封裝的層次越高,其支持的MPEG-4的特性就越多。以下是現有的幾種封裝方案。(1)視頻封裝單元描述將MPEG-4的音/視頻數據直接分布并映射到RTP包里的方法。對于視頻,該封裝規則以視頻對象平面(VideoObjectPlane,VOP)作為封裝的基本單元;對于音頻,該標準采用了低耗MPEG-4音頻復合傳輸(Low-overheadMPEG-4AudioTransportMultiplex,LATM)來管理音頻數據序列。(2)mpeg-4中的時間信息它也是針對基本流數據封裝定義的方案,該草案以訪問單元(AccssUnit,AU)為封裝的基本單元,訪問單元是MPEG-4中擁有時間信息的最小邏輯單元。該草案主要定義了如何將幾個訪問單元串聯封裝到一個RTP包里及如何實現訪問單元的交叉存放的方法。(3)隨機訪問單元它是以simple-05為基礎的,定義了RTP封裝基本流數據的方案。支持訪問單元的串聯、分割和交叉存放,支持系統流的隨機訪問。該標準定義了RTP包的格式、MPEG-4流傳輸的模型和訪問單元交叉存放的方法。以上基本流層封裝的方案都是媒體感知的,可以根據網絡狀況來調節媒體的封裝甚至媒體的壓縮方式;通過交叉存放還有利于基本流的錯誤隱藏;其需要的附加信息最小,解包和封包的復雜度最小。缺點是:如果基本流很多的話,還會導致流會話管理的復雜化。(4)同步層流封裝壓包它定義了RTP傳輸同步流的方案。其基本封裝單元是同步層包。由于RTP協議和MPEG-4的同步層都具有同步功能,而且RTP的同步功能通過復制了一些由同步層包頭提供的信息來實現,所以將同步層包頭部與RTP包頭部間冗余的信息去掉,將剩余的信息分成載荷頭部域和保留同步層頭部域兩部分填充到RTP包的頭部。一個或者多個同步層包封裝到一個RTP包里,不會發生同步包分割的情況。同步層流封裝方案可以支持處理復雜的交互場景的應用和包括圖像、音頻、視頻等多種對象的應用,也支持需要數字權力管理的應用,還可以與MPEG的其他標準(如MPEG-7/21)結合以支持需要內容管理的應用。缺點是:沒有解決對象多的時候流通道過多的問題;由于是媒體不感知型,所以對流的差錯處理能力較弱。(5)傳輸封裝方案它定義了RTP傳輸MPEG-4復合流的方案。其封裝的基本單元是復合包。一個或者多個完整的MPEG-4復合包直接映射到RTP包里,而傳輸封裝方案既可以處理復雜場景和多種對象的應用環境,也可以將多個流復合成一個流或者若干個流,減少流會話管理開銷。缺點是:封裝所需的附加信息較多,封包和解包的復雜度較大,服務端的復雜度較大,流的差錯處理能力較弱。1.2流封裝方案設計對于如電影等數據,一般來說流的數量較少,通常只有一個視頻流、一個音頻流和一個對象描述流、一個場景描述流,而且兩個系統流的信息很少。采用基于RFC3640的基本流封裝方案,既可以減少開銷,也可以提供差錯處理能力。對于系統流信息,通過帶外方式也就是由SDP來提供。在具體的實現中,針對視頻和音頻的特性進行了如下改進和簡化:①采用了解碼時間戳(DecodeTimeStamp,DTS)而不是合成時間戳(ComposeTimeStamp,CTS)作為RTP時間戳,因為合成時間戳在MP4文件格式里并不是必須的;②對大的訪問單元的分割做了一定的設計,以減少包丟失的影響;③對串聯訪問單元所需的附加載荷進行了簡化。1.2.1視頻監控的rtp封裝視頻幀一般都比較大,這里把用訪問單元組織的視頻數據直接當成RTP載荷封裝到RTP包里,不考慮幾個訪問單元串聯封裝的情況。也就是說,一個RTP包載荷要么是一個訪問單元,要么是一個訪問單元片斷。RTP頭部域中的填充位P和擴展位X都應該置為0;它的標志位M在當載荷為完整的訪問單元或者一個訪問單元分割之后的最后一個片斷時置為1,否則置為0;它的時間戳采用載荷內第一個訪問單元的解碼時間戳再加上一個隨機數的初始值;其余的RTP頭部各項的含義參照RFC1889的規定。MPEG-4視頻的RTP封裝格式如圖1所示。對于視頻流,有些訪問單元(一般為包含I幀數據的訪問單元)大于Path-MTU,封裝大于Path-MTU的數據到一個RTP包里會導致下層的分包,不利于RTP處理,所以必須將大的訪問單元分割到不同的RTP包里,但是已有的標準和草案都沒有提出如何有效地分割這些大的訪問單元。為了減少RTP包之間的依賴,避免一個RTP包的丟失導致相鄰順序多個RTP包不可用,當需要對大的訪問單元進行分割的時候,采用同步字作為割點。分割后,一個RTP包載荷必須是完整的一個或者多個由同步字邏輯劃分的單元,這樣當有RTP包丟失的情況下,其余RTP包內的同步字所屬的數據還可以單獨解碼;在沒有同步字的編碼文件里,采用宏塊作為分割點,這樣單個RTP包丟失只是丟失視頻文件的一部分宏塊,其余RTP包里的宏塊仍可以解碼。1.2.2length的使用對音頻來說,因為音頻幀一般比較小,如果采用64kbits的AAC編碼,每個音頻幀平均只有200字節,有必要將幾個音頻幀的訪問單元串聯起來封裝到一個RTP包里。為了減少復雜度,不考慮將訪問單元分割封裝到不同的RTP包里的情況,也就是說RTP包載荷為完整的訪問單元,沒有任何一個RTP包的載荷是訪問單元片斷。具體的封裝格式如圖2所示。RTP頭部的格式同圖1的RTPHeader域,其中標志位始終置為1,其余字段的含義與視頻封裝相同。AUDataSection是按字節對齊的完整音頻訪問單元數據。AUHeaderSection包含一個AUHeaderLength,至少一個AU-herader和填充位(可選)。AUHeaderLength為兩個字節,指示包括填充位在內的以bit為單位的長度。填充位是為了字節對齊,最多七位。每個AUHeader域都與AUData域里的一個訪問單元相對應,順序也對應。其中:AU-size,對應訪問單元的以字節為單位的大小。AU-Index/AU-Index-delta,AU-Index指示對應訪問單元的系列號。訪問單元的系列號按解碼順序依次加1。AU-Index只有在第一個AU-header里出現,后續的AU-header里只有AU-Index-delta。AU-Index-delta指示了相關的訪問單元的Index與前一個訪問單元的Index之間的差值。如果訪問單元是按照解碼順序存放的,那么該項填0。DTS-flag,DTS-delta,DTS-flag用來指示是否接下來有DTS-flag域,在第一個AU-header里該位一定置為0(因為該訪問單元的解碼時間戳在RTP頭部信息的時間戳里),后邊的AU-header里該位可以置為1。DTS-delta表明其對應的訪問單元與RTP頭部的時間戳之間的差值。CTS-flag,CTS-delta,CTS-flag用來指示是否接下來有CTS-flag域。CTS-delta指明了該訪問單元的合成時間戳和解碼時間戳之間的差值。合成時間戳和解碼時間戳要有相同的時間戳單位。RAP-flag,指示一個訪問單元是否是隨機訪問單元,是則置為1。AUHeader域的各項中,AU-size和AU-Index/AU-Index-delta項是必須的,其余各項都是可選的,當串聯的訪問單元的持續時間有不相同的時候必須要指定解碼時間戳項,當有訪問單元的合成時間戳和解碼時間戳的差值不同的時候必須要指定合成時間戳項。CTS-flag,DTS-flag和RAP-flag是否存在(如果存在則占一位),其余各項占多少位都通過帶外方式(SDP)給出。2rfc3013封裝規則MPEG-4的RTP封裝技術可以應用到網絡實時傳輸和視頻點播中,但是已有的系統大都采用的是RFC3016定義的封裝規則。這個封裝規則在音頻封裝時采用了LATM管理音頻數據,它沒有提供對系統流數據封裝的支持,隨著MPEG-4的發展,LATM的作用正逐漸被標準的RTP協議封裝規則所替代。2.1視頻解碼模塊我們研究的原型系統是一個分布式視頻點播系統,系統邏輯上劃分成節目中心和播放中心,節目中心保存所有節目,播放中心保存部分熱播節目,用戶的點播請求將主要集中在播放中心,從而提高了系統的可擴展性,同時降低了主干網絡的帶寬需求。播放中心的邏輯結構如圖3所示,它支持MP4文件格式,可以響應用戶對MP4文件的點播、暫停、拖動、關閉等請求。其中RTSP(Real-StreamingProtocol,實時流協議)是由IETF定義的一個應用層協議,主要用于建立及控制一個或幾個實時數據流的傳輸。2.2rtpstep封裝RTSP會話負責為每個用戶點播建立一個會話,同時負責處理用戶的各種操作請求。每個會話對應于一個用戶的一次點播行為,也對應一個MP4文件,但是該文件可能包含若干個流(音/視頻)。MP4文件分為兩個部分:元數據(Meta-data)和媒體數據(Media-data)。其中媒體數據存放的是所有的音/視頻數據和系統流數據,元數據是對媒體數據的描述。MP4文件解析模塊負責解析MP4文件的元數據域,組合出對該文件的SDP描述,得到文件所包含的流的個數及其信息用于創建相應的流源。RTPStream對應MP4文件中的一個音頻流或者一個視頻流,也是一個分層視頻中的一層。RTPStream模塊負責調度從流源中取得媒體數據,然后經RTP封裝后發送到客戶端,并進行初步的流量控制。流源模塊負責從文件中讀取媒體數據,并按照RTP的封裝要求組織數據;負責在用戶拖動的時候尋找到與播放時間對應的文件位置。RTP封裝模塊負責按照RTP規范和之前描述的MPEG-4數據的RTP封裝方案將媒體數據封裝成RTP包并將其發送到客戶端。RTCP處理模塊負責處理RTCP信息。客戶端采用了QuickTime6.0。2.3rtp封裝文件特征(1)客戶端發送一個DISCRIBE請求給RTSPSession。(2)服務器端RTSPSession接到請求后建立一個會話,同時建立一個關聯的MP4文件解析對象。(3)解析相應的MP4文件,得到該文件的SDP描述、流信息。(4)RTSPSession將取得的SDP描述反饋給客戶端。(5)客戶端接收到SDP信息后,根據SDP信息發送一個或者多個SETUP請求。(6)RTSPSession根據SETUP請求的信息創建相應的RTPStream對象和流源對象,并反饋客戶端請求處理的情況。(7)客戶端在所有流請求建立后發送一個PLAY請求。