MPEG-4流的RTP負載格式.docVIP

MPEG-4流的RTP負載格式1. 介紹本文描述的RTP負載格式規(guī)定了如何對MPEG-4音頻流35和MPEG-4視覺流24進行分片并直接映射到RTP包中。通過定義這些RTP負載格式，應用在不使用MPEG-4系統(tǒng)同步和流管理功能的情況下也能直接傳輸MPEG-4音頻/視覺流。本文的RTP負載格式可應用于那些本身有流管理功能且不需要MPEG-4系統(tǒng)中類似功能的系統(tǒng)。例如H.323終端，其MPEG-4音/視頻流的管理就不通過MPEG-4系統(tǒng)對象描述符進行管理，而是使用了H.245。流直接映射到RTP包中，并沒有使用MPEG-4系統(tǒng)同步層。其它例子包括SIP和RTSP，它們使用了MIME和SDP。本文所述之RTP負載格式定義了MIME類型和SDP的用法，直接規(guī)定了不使用MPEG-4系統(tǒng)時的音/視覺流屬性（如，媒體類型，打包格式和編碼配置）。這樣做明顯的優(yōu)點在于可以象對付那些非MPEG-4編碼格式一樣，采用一種通用的方法來對這些MPEG-4音頻/視覺RTP負載格式進行處理。而缺點在于同基于MPEG-4系統(tǒng)環(huán)境的互操作可能會比較困難，其它負載格式則更適用于這些應用。在此情況下，RTP包頭的語義必須定義的非常清晰，其中包括MPEG-4音/視頻數(shù)據元素的關系。此外，為了增強錯誤恢復能力，在MPEG-4視頻流內部提供錯誤恢復工具，最好能為MPEG-4視頻流定義好RTP包的分片規(guī)則。1.1 MPEG-4視覺RTP負載格式MPEG-4視覺是一種視覺編碼標準，它具有如下新特征：高編碼效率；高錯誤恢復性；基于多樣的，任意形的對象編碼；等等2。其速率范圍介于數(shù)Kbps到幾Mbps。并且它能適應從無差錯網絡到高錯誤率的移動網絡等多種網絡類型。針對本文中定義的MPEG-4視覺碼流的分片規(guī)則我們應當注意到，由于MPEG-4視覺將用于多種網絡類型，因此在分片方面不應有太多的限制。諸如“單個視頻包需映射到單個RTP包”這樣的分片規(guī)則是不合理的。另一方面，大意，對未知媒體分片也可能導致錯誤恢復率和帶寬利用率的下降。本文描述的分片規(guī)則十分靈活，但在應用MPEG-4視覺錯誤恢復功能時為了避免無意義的分片也要定義一個最小的規(guī)則集。分片規(guī)則建議不要在一個RTP包中映射多個VOP，這樣可以保證RTP時間戳能唯一地表示VOP分幀時間。而相反地，由于MPEG-4視頻可以產生非常小的VOP，如一個只包含VOP頭的空VOP (vop_coded=0)或者一個僅有少量碼塊的任意形VOP。為了減低開銷，分片規(guī)則應允許將多個VOP連接到一個RTP包中。（參見3.2節(jié)分片規(guī)則(4)和3.1節(jié)標志位和時間戳）在H.261或MPEG-1/2等視頻編碼工具中往往通過所定義的額外媒體RTP包頭來幫助在包丟失時恢復損壞的圖片包頭，而MPEG-4視覺已經為此提供了錯誤恢復功能，它們可用于RTP/IP網絡，也可用于其它網絡（H.223/Mobile,MPEG-2/TS等）。因此，無需在MPEG-4視覺RTP負載格式中定義額外的RTP包頭。1.2 MPEG-4音頻RTP負載格式MPEG-4音頻是一種集成了多種類型音頻編碼工具的新型音頻標準。LATM(低負擔MPEG-4音頻傳輸復用)通過相當小的耗費來管理音頻數(shù)據序列。對那些僅有音頻的應用，不使用MPEG-4系統(tǒng)而采用直接將基于LATM的MPEG-4音頻碼流映射到RTP包的方式是很值得的。LATM有如下幾項復用特性： - 在音頻數(shù)據中攜帶配置信息， - 將多個音頻幀連接到一個音頻流中， - 多對象（程序）復用 - 可伸縮層的復用，在RTP傳輸中不需要最后兩項性質。因此，基于本文規(guī)定的RTP組包原則的應用程序不能使用這兩個性質。由于LATM是為自然音頻編碼工具所開發(fā)，而非為合成工具開發(fā)，要用其來傳輸結構化音頻(SA)數(shù)據和文語轉換接口(TTSI)數(shù)據是很困難的。所以不能通過本文檔的RTP組包方法傳輸SA數(shù)據和TTSI數(shù)據。為了傳輸可伸縮流，每層的音頻數(shù)據都應當打包到不同的RTP包，如此才可保證在IP層對不同層有不同的處理，比如通過一些區(qū)分服務。另一方面，可伸縮流的所有配置數(shù)據都包含于一個LATM配置數(shù)據SteamMuxConfig中，并且每一層共享該 StreamMuxConfig。層與其配置數(shù)據的映射是通過音頻數(shù)據附帶的LATM頭信息來完成的。為了表示可縮放流的依賴信息，還針對負載類型(PT)值(見4.2節(jié))的動態(tài)分配規(guī)則使用了一種限制措施。對于MPEG-4音頻編碼工具而言，如果負載為單個音頻幀，則包的丟失不會影響鄰近包的解碼。這同樣也適用于其它音頻編碼器。因此MPEG-4音頻不需要附加的用于錯誤恢復的媒體特定頭?？刹捎靡呀洿嬖诘囊恍㏑TP保護機制來提高錯誤恢復率，如通用前向糾錯(RFC 2733)和冗余音頻數(shù)據(RFC 2198)。2. MPEG-4視覺碼流的RTP組包本節(jié)規(guī)定了MPEG-4視覺內容的RTP組包規(guī)則。一個MPEG-4視覺碼流可直接映射到RTP包而不需要增加額外的頭字段或者刪除任何視覺語法元素。為了將基本流的配置信息在相同的RTP端口上傳送，必須使用合并配置/基本流模式。（參見ISO/IEC 14496-2294中6.2.1開始編碼）配置信息可以通過帶外方式規(guī)定。對于H.323終端，必須使用H.245碼點decoderConfigurationInformation。如果系統(tǒng)使用MIME內容類型和SDP參數(shù)，如SIP和RTSP，則必須用可選參數(shù)config來規(guī)定配置信息。當使用了短視頻頭模式時，應該H.263的RTP負載格式（建議使用RFC2429定義的格式，但也可使用RFC2190格式以實現(xiàn)同舊系統(tǒng)的兼容性）。2.1 MPEG-4視覺中RTP頭字段的使用負載類型(PT): 為新的包格式分配RTP負載類型超出了本文的范疇，不在此贅述。特定類型應用程序的RTP框架應該負責負載類型的分配，如若不能則應該通過帶外信令協(xié)議（如，H.245,SIP等）在動態(tài)范圍內選擇一個負載類型。擴展位(Extension-X bit): 由使用的RTP框架定義。序列號（Sequence Number）: 為了安全從一個隨機初始化值開始，每發(fā)送一個RTP數(shù)據包加1。標志位（Marker-M） bit: 標志位設為1標志這是VOP的最后一個（或僅有一個）RTP包。若一個RTP包中攜帶有多個VOP則標志位也設為1。時間戳（Timestamp）: 時間戳表示RTP包中的VOP采樣時間。為了安全，加上了一個隨機常數(shù)偏移。- 當一個RTP包攜帶多個VOP時，時間戳表示其中最早的一個VOP的時間。其它VOP的時間戳信息通過VOP頭的時間戳字段可得（modulo_time_base和vop_time_increment）。- 如果RTP包只含有配置信息或Group_of_VideoObjectPlane()字段，使用編碼隊列中下一個VOP的時間戳。- 如果RTP包僅含有visual_object_sequence_end_code信息，使用編碼隊列中前一個VOP的時間戳。除非由帶外方式規(guī)定，時間戳分辨率設為缺省值90KHz。其它頭字段的使用見RFC 1889 8。2.2 MPEG-4視覺碼流分片使用合并配置/基本流模式，經過分片的MPEG-4視覺碼流直接映射到RTP負載而不用增加任何額外頭字段或者刪除視覺語法元素。分片時可應用如下規(guī)則。下文中，頭（Header）可能表示如下信息：- 配置信息（視覺對象序列頭，視覺對象頭和視頻對象層頭）- visual_object_sequence_end_code- 基本流的進入點函數(shù)頭（Group_of_VideoObjectPlane(), video_plane_with_short_header(), MeshObject()或FaceObject()- 視頻包頭 (video_packet_header()，next_resync_marker()除外)- gob_layer()頭配置信息和進入點函數(shù)的定義參見ISO/IEC 14496-2 294的6.2.1 開始編碼(1) 配置信息和Group_of_VideoObjectPlane()字段應位于RTP負載的開始位置或在語法上的上層函數(shù)頭之后。(2) 如果RTP負載中存在一個或多個頭，則RTP負載應從語法上的最高函數(shù)頭開始。注意: visual_object_sequence_end_code作為最低函數(shù)。(3) 一個頭不應分到多個RTP包中。(4) 不同的VOP應該分片為不同的RTP包，一個RTP包只包括與唯一VOP的時間相關的數(shù)據（在RTP包頭的時間戳字段中指出）。例外情況是如果VOP很小，則單個RTP包攜帶多個按解碼順序連續(xù)的VOP。注意：當一個RTP負載攜帶了多個VOP時，第一個VOP后的VOP時間戳在解碼時通過計算得到。該操作僅當RTP包標志位為1且RTP負載開始符合起始碼時才是必須的。 (見3.1節(jié)時間戳和標志位)(5) 建議一個視頻包組成一個RTP包進行發(fā)送。視頻包的大小應該按如下方式來決定，即，結果RTP包的大小不得超過路徑MTU的大小。注意：規(guī)則(5)不適用于以下場合，編碼器配置禁止視頻包（通過將VOL頭中的resync_marker_disable設置為1），或者編碼工具不支持視頻包。在此情況下，一個VOP可能得經過在任意字節(jié)位置進行分片后才能發(fā)送。視頻包從VOP頭或視頻包頭開始，后面緊接著是motion_shape_texture()，以next_resync_marker()或next_start_code()結束。2.3 MPEG-4視覺碼流組包示例Figure 2所示為按照2.2描述標準產生的RTP包的例子。(a)例表示包含了配置信息的MPEG-4視覺碼流中第一個RTP包或隨機訪問點。根據規(guī)則 (1)，視覺對象序列頭應位于RTP負載的開始處，視覺對象頭和視頻對象層頭(VO header, VOL header)之前。3.2中定義的分片規(guī)則保證了從visual_object_sequence_start_code開始的配置信息通常都位于RTP負載的開始位置，RTP接收端可通過檢查RTP負載的頭32位字段是否是visual_object_sequence_start_code來檢測隨機訪問點。(b)是另一個包含配置信息的RTP包例子。它同(1)的區(qū)別為該RTP包在VOP中的配置信息后還包含有視頻包。由于配置信息長度很短（一般為數(shù)十字節(jié)），一個RTP包如果僅含有配置信息會造成系統(tǒng)開銷的上升，因此配置信息和其后的GOV和/或(部分)VOP可以打包到同一個RTP包中，如此例中所示。(c)是RTP包中包含了Group_of_VideoObjectPlane(GOV)的例子。根據規(guī)則(1)，GOV位于RTP負載的開始位置。一個僅有GOV字段的RTP包大小只有7個字節(jié)，這是對RTP/IP頭開銷的極大浪費。因此后續(xù)的VOP(或部分地)可以如本例所示打到同一個RTP包中。(d)例中，一個視頻包被打包到一個RTP包中。當網絡中包丟失率很高時推薦采用該方法。甚至當包含有VOP頭的RTP包被丟棄時其它RTP包還可通過使用視頻包頭中的HEC信息進行解碼。無需任何額外的RTP頭字段。(e)例為多個視頻包打在一個RTP包中的情況。 在底層網絡速率很低時這種組包方式可高效地節(jié)約RTP/IP頭開銷。不過，由于一個RTP包的丟失會導致將多個視頻包同時丟失，這種方法會降低丟包恢復率。一個RTP包中理想的視頻包數(shù)目和RTP包長度可通過丟包率和底層網絡傳輸?shù)谋忍芈蕘頉Q定。(f)示例為在VOL頭中將resync_marker_disable設置為1從而禁止使用視頻包。在此情況下，一個VOP可按照任意字節(jié)位置分為多個RTP包。比如將一個VOP按照固定長度進行分片。這種編碼配置方法和RTP分片可應用于能提供極低錯誤率保證的網絡。另一方面，由于它的丟包恢復率很差，建議不要在error-prone環(huán)境中使用。Figure 3 所示為按3.2規(guī)則建立的RTP包。按照(a)中將一個頭分片到多個RTP包不僅造成RTP/IP頭開銷增加，也導致了錯誤恢復能力的下降。因此在規(guī)則(3)中禁止這樣做。當將多個視頻包串聯(lián)到一個RTP包中時，VOP頭或video_packet_header()不應放到RTP負載的中間。基于錯誤恢復的目的，(b)中的組包方法違反了規(guī)則(2)。比較該例同圖2中的例6，盡管兩者都是把兩個視頻包映射到兩個RTP包中，其丟包恢復率卻不一樣。即是說，假設第二個RTP包丟失了，圖3例(b)中兩個視頻包都將丟失，而在圖2例(d)中僅丟失視頻包2。3. MPEG-4音頻碼流的RTP組包本節(jié)規(guī)定了MPEG-4音頻碼流的RTP組包規(guī)則。MPEG-4音頻流必須通過LATM工具進行格式化，然后基于LATM的流將按照下面三節(jié)的描述映射到RTP包上。3.1 RTP包格式基于LATM的流由一個包含了一個或多個音頻幀的audioMuxElements序列組成。一個完整或部分完整的audioMuxElement可直接映射到一個RTP負載上，無需刪除任何audioMuxElement語法元素 (見圖4)。每個audioMuxElement的第一個字節(jié)應該位于RTP包第一個負載所在的位置。為了對audioMuxElement進行解碼，必需得在其后通過帶外方法指明muxConfigPresent。當SDP用于此指示時，MIME參數(shù)cpresent“就對應了muxConfigPresent信息。muxConfigPresent: 如果該值為1(帶內模式)，audioMuxElement應包括一個指示位useSameStreamMux并且可能包括一個音頻壓縮配置信息StreamMuxConfig。UseSameStreamMux位表示是否前一幀中的StreamMuxConfig元素也應用于本幀。如果useSameStreamMux位指示要使用前一幀的StreamMuxConfig，而前一幀已經丟失，則將無法對當前幀進行解碼。因此，在帶內模式下，StreamMuxConfig元