注意：當一個RTP負載攜帶了多個VOP時，第一個VOP后的VOP時間戳在解碼時通過計算得到。
該操作僅當RTP包標志位為1且RTP負載開始符合起始碼時才是必須的。 (見3.1節時間戳和標志
位)
   (5) 建議一個視頻包組成一個RTP包進行發送。視頻包的大小應該按如下方式來決定，即，結
果RTP包大大小不得超過路徑MTU的大小。
   注意：規則(5)不適用于以下場合，編碼器配置禁止視頻包（通過將VOL頭中的
resync_marker_disable設置為1），或者編碼工具不支持視頻包。在此情況下，一個VOP可能得
經過在任意字節位置進行分片后才能發送。
   視頻包從VOP頭或視頻包頭開始，后面緊接著是motion_shape_texture()，以 
next_resync_marker()或next_start_code()結束。
3.3 MPEG-4視覺碼流組包示例
   Figure 2所示為按照3.2描述標準產生的RTP包的例子。
   (a)例表示包含了配置信息的MPEG-4視覺碼流中第一個RTP包或隨機訪問點。根據規則 (1)，
視覺對象序列頭應位于RTP負載的開始處，視覺對象頭和視頻對象層頭(VO header, VOL header)
之前。3.2中定義的分片規則保證了從visual_object_sequence_start_code開始的配置信息通常
都位于RTP負載的開始位置，RTP接收端可通過檢查RTP負載的頭32位字段是否是
visual_object_sequence_start_code來檢測隨機訪問點。
   (b)是另一個包含配置信息的RTP包例子。它同(1)的區別為該RTP包在VOP中的配置信息后還包
含有視頻包。由于配置信息長度很短（一般為數十字節），一個RTP包如果僅含有配置信息會造
成系統開銷的上升，因此配置信息和其后的GOV和/或(部分)VOP可以打包到同一個RTP包中，如此
例中所示。
   (c)是RTP包中包含了Group_of_VideoObjectPlane(GOV)的例子。根據規則(1)，GOV位于RTP
負載的開始位置。一個僅有GOV字段的RTP包大小只有7個字節，這是對RTP/IP頭開銷的極大浪費。
因此后續的VOP(或部分地)可以如本例所示打到同一個RTP包中。
   (d)例中，一個視頻包被打包到一個RTP包中。當網絡中包丟失率很高時推薦采用該方法。甚
至當包含有VOP頭的RTP包被丟棄時其它RTP包還可通過使用視頻包頭中的HEC信息進行解碼。無需
任何額外的RTP頭字段。
   (e)例為多個視頻包打在一個RTP包中的情況。 在底層網絡速率很低時這種組包方式可高效地
節約RTP/IP頭開銷。不過，由于一個RTP包的丟失會導致將多個視頻包同時丟失，這種方法會降
低丟包恢復率。一個RTP包中理想的視頻包數目和RTP包長度可通過丟包率和底層網絡傳輸的比特
率來決定。
   (f)示例為在VOL頭中將resync_marker_disable設置為1從而禁止使用視頻包。在此情況下，
一個VOP可按照任意字節位置分為多個RTP包。比如將一個VOP按照固定長度進行分片。這種編碼
配置方法和RTP分片可應用于能提供極低錯誤率保證的網絡。另一方面，由于它的丟包恢復率很
差，建議不要在error-prone環境中使用。
Figure 3 所示為按3.2規則建立的RTP包。
按照(a)中將一個頭分片到多個RTP包不僅造成RTP/IP頭開銷增加，也導致了錯誤恢復能力
的下降。因此在規則(3)中禁止這樣做。
當將多個視頻包串聯到一個RTP包中時，VOP頭或video_packet_header()不應放到RTP負載
的中間。基于錯誤恢復的目的，(b)中的組包方法違反了規則(2)。比較該例同圖2中的例6，盡管
兩者都是把兩個視頻包映射到兩個RTP包中，其丟包恢復率卻不一樣。即是說，假設第二個RTP
包丟失了，圖3例(b)中兩個視頻包都將丟失，而在圖2例(d)中僅丟失視頻包2。
    +------+------+------+------+
(a) | RTP  |  VS  |  VO  | VOL  |
    |header|header|header|header|
    +------+------+------+------+

    +------+------+------+------+------------+
(b) | RTP  |  VS  |  VO  | VOL  |Video Packet|
    |header|header|header|header|            |
    +------+------+------+------+------------+

    +------+-----+------------------+
(c) | RTP  | GOV |Video Object Plane|
    |header|     |                  |
    +------+-----+------------------+

    +------+------+------------+  +------+------+------------+
(d) | RTP  | VOP  |Video Packet|  | RTP  |  VP  |Video Packet|
    |header|header|    (1)     |  |header|header|    (2)     |
    +------+------+------------+  +------+------+------------+

    +------+------+------------+------+------------+------+------------+
(e) | RTP  |  VP  |Video Packet|  VP  |Video Packet|  VP  |Video Packet|
    |header|header|     (1)    |header|    (2)     |header|    (3)     |
    +------+------+------------+------+------------+------+------------+

    +------+------+------------+  +------+------------+
(f) | RTP  | VOP  |VOP fragment|  | RTP  |VOP fragment|
    |header|header|    (1)     |  |header|    (2)     | ___
    +------+------+------------+  +------+------------+

     圖2 – RTP組包的MPEG-4視覺碼流示例
    +------+-------------+  +------+------------+------------+
(a) | RTP  |First half of|  | RTP  |Last half of|Video Packet|
    |header|  VP header  |  |header|  VP header |            |
    +------+-------------+  +------+------------+------------+

    +------+------+----------+  +------+---------+------+------------+
(b) | RTP  | VOP  |First half|  | RTP  |Last half|  VP  |Video Packet|
    |header|header| of VP(1) |  |header| of VP(1)|header|    (2)     |
    +------+------+----------+  +------+---------+------+------------+

   圖3 – 禁止RTP組包的MPEG-4視覺碼流示例

4. MPEG-4音頻碼流的RTP組包
本節規定了MPEG-4音頻碼流的RTP組包規則。MPEG-4音頻流必須通過LATM工具進行格式化，
然后基于LATM的流將按照下面三節的描述映射到RTP包上。
4.1 RTP包格式
基于LATM的流由一個包含了一個或多個音頻幀的audioMuxElements序列組成。一個完整或
部分完整的audioMuxElement可直接映射到一個RTP負載上，無需刪除任何audioMuxElement語法
元素 (見圖4)。每個audioMuxElement的第一個字節應該位于RTP包第一個負載所在的位置。
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                                                               |RTP
:                 audioMuxElement (byte aligned)                :Payload
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             圖4 – 一個MPEG-4音頻RTP包
為了對audioMuxElement進行解碼，必需得在其后通過帶外方法指明muxConfigPresent。當
SDP用于此指示時，MIME參數"cpresent“就對應了muxConfigPresent信息。(見5.3節).
muxConfigPresent: 如果該值為1(帶內模式)，audioMuxElement應包括一個指示位
"useSameStreamMux"并且可能包括一個音頻壓縮配置信息"StreamMuxConfig"。
UseSameStreamMux位表示是否前一幀中的StreamMuxConfig元素也應用于本幀。如果
useSameStreamMux位指示要使用前一幀的StreamMuxConfig，而前一幀已經丟失，則將無法對當
前幀進行解碼。因此，在帶內模式下，StreamMuxConfig元素應根據網絡條件重復傳輸。相反，
如果muxConfigPresent設為0(帶外模式)，StreamMuxConfig元素需要通過帶外方式傳輸。如果是
SDP，則要使用MIME參數"config" (見5.3節).
4.2 MPEG-4音頻中RTP頭字段的使用
   負載類型(PT): 為這種新的包格式分配RTP負載類型超出了本文的范疇，不在此贅述。特
定類型應用程序的RTP框架應該負責為編碼分配負載類型，如若不能則應該通過帶外信令協
議（如，H.245,SIP等）在動態范圍內選擇一個負載類型。在為可伸縮流動態分配RTP負載類
型時，應該為每一層分配不同的值。這些值應按層依賴關系的強弱順序進行分配，最基本的
層擁有最小的值。
   標志位(M): 標志位指出了audioMuxElement范圍。置為1說明RTP包包含有完整的   
audioMuxElement或audioMuxElement分片的最后一片。
   時間戳: 時間戳表示RTP包中第一個音頻幀的采樣時間。從安全角度出發，建議時間戳從一個
隨機值開始。除非指定使用帶外方式，時間戳的分辨率設為缺省值90KHz。
   順序號: 為了更加安全，順序號應從一個隨機初始化值開始，每發送一個RTP數據包加1。
   其它頭字段的使用遵照RFC 1889 [8]。
4.3 MPEG-4音頻碼流分片
	建議每個RTP包中只放一個audioMuxElement。如果audioMuxElement的大小保持得足夠小，
使得RTP包的大小不超過路徑MTU的大小，則沒有問題。否則就得將audioMuxElement分片到多個
包中。
5. MPEG-4視聽流MIME類型注冊
   接下來的幾節描述了MPEG-4視聽流的MIME類型注冊。MPEG-4視覺流的MIME類型注冊和SDP使用
在5.1和5.2節中描述，而MPEG-4音頻流的MIME類型注冊和SDP用法在5.3和5.4中描述。
5.1 MPEG-4視覺MIME類型注冊
   MIME媒體類型名: video
   MIME子類型名: MP4V-ES
   必需的參數: none
   可選參數:
      rate(速率): 該參數僅用于RTP傳輸。表示RTP頭時間戳字段的分辨率。如果未指定該參數
則使用缺省值90000(90KHz)。
      profile-level-id(框架級別ID): 一個表示Table G-1 of ISO/IEC 14496-2 [2][4]定義
的MPEG-4視覺框架和級別值的十進制數 (profile_and_level_indication)。該參數可用于性能
交換或事務建立過程中以表示MPEG-4視覺框架和MPEG-4視覺編碼器能達到的級別組合。如未指定
該參數，則采用缺省值1。
      Config(配置): 該參數用于表示相應MPEG-4視覺流的配置。不應用于表示性能交換過程中
的編碼能力。它是一個16進制形式的8位字節串，可表示ISO/IEC14496-2 [2][4][9]6.2.1小節中
定義的MPEG-4視覺配置信息。該配置信息可按照MSB（最高有效位）優先原則直接映射到8位字節
串。配置信息的第一位應位于第一個8位組的MSB。該參數表示的配置信息應和相應的MPEG-4視覺
流的配置信息相同，除了first_half_vbv_occupancy和latter_half_vbv_occupancy，如果存在，
那么它在MPEG-4視覺流內重復的配置信息方面有所不同。(見ISO/IEC14496-2的6.2.1小節“開始
編碼”).
      關于該參數的用法示例如下:
        -  MPEG-4 Visual Simple Profile/Level 1:
            Content-type: video/mp4v-es; profile-level-id=1
        -  MPEG-4 Visual Core Profile/Level 2:
            Content-type: video/mp4v-es; profile-level-id=34
        -  MPEG-4 Visual Advanced Real Time Simple Profile/Level 1:
            Content-type: video/mp4v-es; profile-level-id=145
   已發行規范:
      MPEG-4視覺流規范參見ISO/IEC 14469-2 [2][4][9]。RTP負載格式在RFC 3016中描述。
   編碼考慮:
      視頻位流必須參照MPEG-4視覺規范(ISO/IEC 14496-2)產生。一個視頻位流是二進制數據，
必須編碼為可按非二進制傳輸(對于Email，Base64編碼就已經足夠了)。該類型也定義為通過RTP
傳輸。RTP包必須遵照RFG 3016定義的MPEG-4視覺RTP負載格式進行組包。
   安全性考慮:
      參見RFC 3016第6節。
   互操作考慮:
      MPEG-4視覺為視覺對象編碼提供了大量豐富的工具集。為了高效地實現標準，也為特定的
應用提供了MPEG-4視覺工具子集。這些子集稱做'Profiles',限制了實現一個編碼器所需要的工
具集的大小。為了控制計算復雜性，每個Profile分為若干級別。Profile@Level組合如下:
?	一個編解碼器開發者，負責實現所需的標準子集，維護和相同組合內其它MPEG-4設備
的相互作用。
?	檢查MPEG-4設備是否符合標準 ('一致性測試')。
      視覺流應同參數"profile-level-id"中規定的MPEG-4視覺Profile@Level兼容。
      發送方與接收方的互操作性，通過在MIME內容中指定參數"profile-level-id"，或者通過
協調性能交換/聲明過程將該參數設為相同值來實現。
   使用該媒體類型的應用:
      視聽流和會議工具，Internet消息和電子郵件應用。
   附帶信息: 無
   聯系人及其郵件地址：
      RFC 3016作者(見第8節)。