MPEG-4的rtp協議封裝
英文原版 RFC 3016：http://www.rfc-editor.org/rfc/rfc3016.txt
中文翻譯：
組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者： 李超（licc_li ，licc_li@sina.com）
譯文發布時間：2001-4-26
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




Network Working Group Y. Kikuchi
Request for Comments: 3016 Toshiba
Category: Standards Track T. Nomura
NEC
S. Fukunaga
Oki
Y. Matsui
Matsushita
H. Kimata
NTT
November 2000

用于MPEG-4視聽流的RTP負載格式
（RRC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams）


本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以
得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化程度
和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
本文描述了在不使用MPEG-4系統的情況下攜帶MPEG-4音頻和視覺碼流的RTP負載格式。為了能
直接將MPEG-4音頻/視覺碼流映射到RTP包上，它提供了RTP包頭字段的使用規范和分片規則。同
時文檔中還規定了MIME類型注冊和會話描述協議(SDP)的使用。
目錄
本備忘錄的狀態 1
版權聲明 1
摘要 1
1. 介紹 2
1.1 MPEG-4視覺RTP負載格式 3
1.2 MPEG-4音頻RTP負載格式 3
2. 要求的術語 4
3. MPEG-4視覺碼流的RTP組包 4
3.1 MPEG-4視覺中RTP頭字段的使用 4
3.2 MPEG-4視覺碼流分片 5
3.3 MPEG-4視覺碼流組包示例 6
4. MPEG-4音頻碼流的RTP組包 7
4.1 RTP包格式 7
4.2 MPEG-4音頻中RTP頭字段的使用 8
4.3 MPEG-4音頻碼流分片 9
5. MPEG-4視聽流MIME類型注冊 9
5.1 MPEG-4視覺MIME類型注冊 9
5.2 MPEG-4視覺中SDP的用法 10
5.3 MPEG-4音頻MIME類型登記 11
5.4 SDP usage of MPEG-4 Audio 12
6. 安全性考慮 13
7. 參考文獻 13
8. 作者地址 13
9. 版權聲明 14
致謝 14

1. 介紹
本文描述的RTP負載格式規定了如何對MPEG-4音頻流[3][5]和MPEG-4視覺流[2][4]進行分
片并直接映射到RTP包中。
通過定義這些RTP負載格式，應用在不使用MPEG-4系統同步和流管理功能的情況下也能直接
傳輸MPEG-4音頻/視覺流。本文的RTP負載格式可應用于那些本身有流管理功能且不需要MPEG-4
系統中類似功能的系統。例如H.323終端，其MPEG-4音/視頻流的管理就不通過MPEG-4系統對象描
述符進行管理，而是使用了H.245。流直接映射到RTP包中，并沒有使用MPEG-4系統同步層。其它
例子包括SIP和RTSP，它們使用了MIME和SDP。本文所述之RTP負載格式定義了MIME類型和SDP的用
法，直接規定了不使用MPEG-4系統時的音/視覺流屬性（如，媒體類型，打包格式和編碼配置）。
這樣做明顯的優點在于可以象對付那些非MPEG-4編碼格式一樣，采用一種通用的方法來對這些
MPEG-4音頻/視覺RTP負載格式進行處理。而缺點在于同基于MPEG-4系統環境的互操作可能會比較
困難，其它負載格式則更適用于這些應用。
在此情況下，RTP包頭的語義必須定義的非常清晰，其中包括MPEG-4音/視頻數據元素的關
系。此外，為了增強錯誤恢復能力，在MPEG-4視頻流內部提供錯誤恢復工具，最好能為MPEG-4
視頻流定義好RTP包的分片規則。
1.1 MPEG-4視覺RTP負載格式
MPEG-4視覺是一種視覺編碼標準，它具有如下新特征：高編碼效率；高錯誤恢復性；基于
多樣的，任意形的對象編碼；等等[2]。其速率范圍介于數Kbps到幾Mbps。并且它能適應從無差
錯網絡到高錯誤率的移動網絡等多種網絡類型。
針對本文中定義的MPEG-4視覺碼流的分片規則我們應當注意到，由于MPEG-4視覺將用于多
種網絡類型，因此在分片方面不應有太多的限制。諸如“單個視頻包需映射到單個RTP包”這樣
的分片規則是不合理的。另一方面，大意，以及未知媒體分片也可能導致錯誤恢復率和帶寬利用
率的下降。本文描述的分片規則十分靈活，但在應用MPEG-4視覺錯誤恢復功能時為了避免無意義
的分片也要定義一個最小的規則集。
分片規則建議不要在一個RTP包中映射多個VOP，這樣可以保證RTP時間戳能唯一地表示VOP
分幀時間。而相反地，由于MPEG-4視頻可以產生非常小的VOP，如一個只包含VOP頭的空VOP
(vop_coded=0)或者一個僅有少量碼塊的任意形VOP。為了減低開銷，分片規則應允許將多個VOP
連接到一個RTP包中。（參見3.2節分片規則(4)和3.1節標志位和時間戳）
在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音頻傳
輸復用)通過相當小的耗費來管理音頻數據序列。對那些僅有音頻的應用，不使用MPEG-4系統而
采用直接將基于LATM的MPEG-4音頻碼流映射到RTP包的方式是很值得的。
LATM有如下幾項復用特性：
- 在音頻數據中攜帶配置信息，
- 將多個音頻幀連接到一個音頻流中，
- 多對象（程序）復用
- 可伸縮層的復用，
在RTP傳輸中不需要最后兩項性質。因此，基于本文規定的RTP組包原則的應用程序不能使
用這兩個性質。由于LATM是為自然音頻編碼工具所開發，而非為合成工具開發，要用其來傳輸結
構化音頻(SA)數據和文語轉換接口(TTSI)數據是很困難的。所以不能通過本文檔的RTP組包方法
傳輸SA數據和TTSI數據。
為了傳輸可伸縮流，每層的音頻數據都應當打包到不同的RTP包，如此才可保證在IP層對不
同層有不同的處理，比如通過一些區分服務。另一方面，可伸縮流的所有配置數據都包含于一個
LATM配置數據"SteamMuxConfig"中，并且每一層共享該 StreamMuxConfig。層與其配置數據的映
射是通過音頻數據附帶的LATM頭信息來完成的。為了表示可縮放流的依賴信息，還針對負載類型
(PT)值(見4.2節)的動態分配規則使用了一種限制措施。
對于MPEG-4音頻編碼工具而言，如果負載為單個音頻幀，則包的丟失不會影響鄰近包的解
碼。這同樣也適用于其它音頻編碼器。因此MPEG-4音頻不需要附加的用于錯誤恢復的媒體特定頭。
可采用已經存在的一些RTP保護機制來提高錯誤恢復率，如通用前向糾錯(RFC 2733)和冗余音頻
數據(RFC 2198)。
2. 要求的術語
本文中的關鍵字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，
“建議”，“或許”，“可選的”在 RFC 2119 中解釋。
3. MPEG-4視覺碼流的RTP組包
本節規定了MPEG-4視覺內容的RTP組包規則。一個MPEG-4視覺碼流可直接映射到RTP包而不
需要增加額外的頭字段或者刪除任何視覺語法元素。為了將基本流的配置信息在相同的RTP端口
上傳送，必須使用合并配置/基本流模式。（參見ISO/IEC 14496-2[2][9][4]中6.2.1"開始編碼"）
配置信息可以通過帶外方式規定。對于H.323終端，必須使用H.245碼
點"decoderConfigurationInformation"。如果系統使用MIME內容類型和SDP參數，如SIP和RTSP，
則必須用可選參數"config"來規定配置信息（參見5.1和5.2）。
當使用了短視頻頭模式時，應該H.263的RTP負載格式（建議使用RFC2429定義的格式，但也
可使用RFC2190格式以實現同舊系統的兼容性）。
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
| MPEG-4 Visual stream (byte aligned) | Pay-
| | load
| - - - - - - - - - - - - - - - -
| :...OPTIONAL RTP padding |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Figure 1 – 一個MPEG-4視覺流的RTP包
3.1 MPEG-4視覺中RTP頭字段的使用
負載類型(PT): 為新的包格式分配RTP負載類型超出了本文的范疇，不在此贅述。特定類
型應用程序的RTP框架應該負責負載類型的分配，如若不能則應該通過帶外信令協議（如，
H.245,SIP等）在動態范圍內選擇一個負載類型。
擴展位(Extension-X bit): 由使用的RTP框架定義。
序列號（Sequence Number）: 為了安全從一個隨機初始化值開始，每發送一個RTP數據包加1。
標志位（Marker-M） bit: 標志位設為1標志這是VOP的最后一個（或僅有一個）RTP包。若一
個RTP包中攜帶有多個VOP則標志位也設為1。
時間戳（Timestamp）: 時間戳表示RTP包中的VOP采樣時間。為了安全，加上了一個隨機常數
偏移。
- 當一個RTP包攜帶多個VOP時，時間戳表示其中最早的一個VOP的時間。其它VOP的時間戳信
息通過VOP頭的時間戳字段可得（modulo_time_base和vop_time_increment）。
- 如果RTP包只含有配置信息或Group_of_VideoObjectPlane()字段，使用編碼隊列中下一個
VOP的時間戳。
- 如果RTP包僅含有visual_object_sequence_end_code信息，使用編碼隊列中前一個VOP
的時間戳。
除非由帶外方式規定，時間戳分辨率設為缺省值90KHz。
其它頭字段的使用見RFC 1889 [8]。
3.2 MPEG-4視覺碼流分片
使用合并配置/基本流模式，經過分片的MPEG-4視覺碼流直接映射到RTP負載而不用增加任何
額外頭字段或者刪除視覺語法元素。分片時可應用如下規則。
下文中，頭（Header）可能表示如下信息：
- 配置信息（視覺對象序列頭，視覺對象頭和視頻對象層頭）
- visual_object_sequence_end_code
- 基本流的進入點函數頭（Group_of_VideoObjectPlane(),
video_plane_with_short_header(), MeshObject()或FaceObject())
- 視頻包頭 (video_packet_header()，next_resync_marker()除外)
- gob_layer()頭
配置信息和進入點函數的定義參見ISO/IEC 14496-2 [2][9][4]的6.2.1 "開始編碼"
(1) 配置信息和Group_of_VideoObjectPlane()字段應位于RTP負載的開始位置或在語法上的
上層函數頭之后。
(2) 如果RTP負載中存在一個或多個頭，則RTP負載應從語法上的最高函數頭開始。
注意: visual_object_sequence_end_code作為最低函數。
(3) 一個頭不應分到多個RTP包中。
(4) 不同的VOP應該分片為不同的RTP包，一個RTP包只包括與唯一VOP的時間相關的數據（在
RTP包頭的時間戳字段中指出）。例外情況是如果VOP很小，則單個RTP包攜帶多個按解碼順序連
續的VOP。
注意：當一個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) | RTP | VS | VO | VOL |
|header|header|header|header|
------ ------ ------ ------
(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 | VS | VO | VOL |Video Packet|
|header|header|header|header| |
------ ------ ------ ------ ------------

(b)是另一個包含配置信息的RTP包例子。它同(1)的區別為該RTP包在VOP中的配置信息后還包
含有視頻包。由于配置信息長度很短（一般為數十字節），一個RTP包如果僅含有配置信息會造
成系統開銷的上升，因此配置信息和其后的GOV和/或(部分)VOP可以打包到同一個RTP包中，如此
例中所示。

------ ----- ------------------
(c) | RTP | GOV |Video Object Plane|
|header| | |
------ ----- ------------------
(c)是RTP包中包含了Group_of_VideoObjectPlane(GOV)的例子。根據規則(1)，GOV位于RTP
負載的開始位置。一個僅有GOV字段的RTP包大小只有7個字節，這是對RTP/IP頭開銷的極大浪費。
因此后續的VOP(或部分地)可以如本例所示打到同一個RTP包中。

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

(d)例中，一個視頻包被打包到一個RTP包中。當網絡中包丟失率很高時推薦采用該方法。甚
至當包含有VOP頭的RTP包被丟棄時其它RTP包還可通過使用視頻包頭中的HEC信息進行解碼。無需
任何額外的RTP頭字段。

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

(e)例為多個視頻包打在一個RTP包中的情況。 在底層網絡速率很低時這種組包方式可高效地
節約RTP/IP頭開銷。不過，由于一個RTP包的丟失會導致將多個視頻包同時丟失，這種方法會降
低丟包恢復率。一個RTP包中理想的視頻包數目和RTP包長度可通過丟包率和底層網絡傳輸的比特
率來決定。

------ ------ ------------ ------ ------------
(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視覺碼流示例

(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。

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節)。
預期用法: COMMON
作者或修訂者:
RFC 3016作者(見第8節)。
5.2 MPEG-4視覺中SDP的用法
MIME媒體類型video/MP4V-ES串可映射到SDP(RFC 2327)，如下：
* MIME類型(video)加入SDP "m="作為媒體名。
* MIME子類型加入SDP "a=rtpmap"作為編碼名。
* 可選參數"rate"加入"a=rtpmap"作為時鐘速率
* 可選參數"profile-level-id"和"config"加入"a=fmtp"行分別表示編碼器能力和配
置。這些參數以分號分隔，按照“參數=值”的成對形式表示為MIME媒體類型串。
下面是SDP中的媒體表示示例:
Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id"且"config"存在于
"a=fmtp"行:
* m=video 49170/2 RTP/AVP 98
* a=rtpmap:98 MP4V-ES/90000
* a=fmtp:98
profile-level-id=1;config=000001B001000001B5090000010000000120008440FA282C
2090A21F
Core Profile/Level 2, rate=90000(90kHz), "profile-level-id"存在于"a=fmtp"行:
* m=video 49170/2 RTP/AVP 98
* a=rtpmap:98 MP4V-ES/90000
* a=fmtp:98 profile-level-id=34
Advance Real Time Simple Profile/Level 1, rate=90000(90kHz),"profile-level-id"存在于
"a=fmtp"行:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=145
5.3 MPEG-4音頻MIME類型登記
MIME媒體類型名: audio
MIME子類型名: MP4A-LATM
必需參數:
速率: 速率參數表示RTP時間戳的時鐘速率。缺省值為90000。僅當該值設置為與音頻
采樣頻率（每秒鐘采樣數）相同值時也可指定其它非缺省速率。
可選參數:
profile-level-id: 一個十進制形式的MPEG-4音頻框架級別表示值，定義于
ISO/IEC 14496-1 ([6]及其修訂版本)。該參數表示解碼器可以使用哪個MPEG-4音頻工
具子集。如果沒有在性能交換或者事務建立過程中指定該參數，則使用缺省值30（自然
音頻Profile/Level 1）
object: 一個十進制形式的MPEG-4音頻對象類型值，定義于ISO/IEC 14496-3 [5]。
該參數指定了編碼器使用的工具。可用該參數來限制性能于規定的"profile-level-id"
之下。
bitrate: 音頻數據流的數據傳輸率。
cpresent: 一個布爾值參數，表示音頻負載配置數據是否已經復用到一個RTP負載
中（參見4.1）。0表示尚未復用，1表示已經復用。該參數的缺省值為1。
config: 一個16進制形式的8位字節串，可表示ISO/IEC 14496-3 [5] (參見4.1)
定義的MPEG-4音頻負載配置數據"StreamMuxConfig"。該配置信息可按照MSB（最高有效
位）優先原則直接映射到8位字節串。配置數據的第一位應位于第一個8位組的MSB。在
最后一個8位組中,如果需要，應該在配置數據后跟隨填充0。
ptime: 推薦的包持續時間，單位毫秒。
已發行規范:
本文描述了負載格式規范。
編碼規范遵照ISO/IEC 14496-3 [3][5]。
編碼考慮:
該類型僅定義為用于通過RTP進行傳輸。
安全性考慮:
參見RFC 3016第6節。
互操作性考慮:
MPEG-4音頻提供了大量而豐富的工具用于音頻對象編碼。為了更高效地實現標準，還
提供了MPEG-4音頻工具子集（類似于5.1中的MPEG-4視覺）。音頻流工具應同
"profile-level-id"參數指定的Profile@Level一致。發送方與接收方之間的互操作性可通
過在MIME內容中指定參數"profile-level-id"，或在協商性能交換過程中，設置該參數為相
同值來實現。此外參數"object"可用于在性能交換中將能力限制于指定的Profile@Level級
別范圍內。
使用該媒體類型的應用:
視聽流與會議工具。
附加信息: 無
聯系人:
參見RFC 3016第8節.
預期用法: COMMON
作者/修訂者:
參見RFC 3016第8節.
5.4 SDP usage of MPEG-4 Audio
MIME媒體類型audio/MP4A-LATM串可以映射到SDP（RFC 2327）的字段上, 如下:
* MIME類型(audio)加入SDP"m="中作為媒體名。
* MIME子類型(MP4A-LATM)加入SDP"a=rtpmap"作為編碼名稱
* 必需參數"rate"加入"a=rtpmap"的作為時鐘速率。
* 可選參數"ptime"加入SDP "a=ptime"屬性
* 可選參數"profile-level-id"加入"a=fmtp"行表示編碼器能力。參數"object"
加入"a=fmtp" 屬性，負載格式相關參數"bitrate", "cpresent"和 "config"
加入"a=fmtp"行。這些參數以分號分隔，按照“參數=值”的成對形式表示MIME
媒體類型串。
下面是SDP中媒體表示的例子：
對于6 kb/s的CELP碼流 (音頻采樣頻率為8 kHz),
* m=audio 49230 RTP/AVP 96
* a=rtpmap:96 MP4A-LATM/8000
* a=fmtp:96 profile-level-id=9; object=8; cpresent=0;
config=9128B1071070
* a=ptime:20
對于64 kb/s的AAC LC立體聲碼流(音頻采樣頻率為24 kHz),
* m=audio 49230 RTP/AVP 96
* a=rtpmap:96 MP4A-LATM/24000
* a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
* config=9122620000
在上面兩個例子中，音頻配置數據僅通過SDP進行了描述，并沒有復用到RTP負載中去。
此外，"時鐘速率（clock rate）"也設置為音頻采樣速率。
如果時鐘速率設置為缺省值，并且必須要取得音頻采樣速率，則可通過解析參數"config"
來實現。舉例如下：
* m=audio 49230 RTP/AVP 96
* a=rtpmap:96 MP4A-LATM/90000
* a=fmtp:96 object=8; cpresent=0; config=9128B1071070
下例顯示RTP負載中的音頻配置數據。
* m=audio 49230 RTP/AVP 96
* a=rtpmap:96 MP4A-LATM/90000
* a=fmtp:96 object=2; cpresent=1
6. 安全性考慮
本規范中描述的RTP包負載格式從屬于RTP規范[8]中討論的安全性考慮。這意味著媒體
流的機密性要通過加密來實現。由于負載格式中數據壓縮是端到端的，加密也可在壓縮數據
上進行，兩種操作間并無矛盾。
完整的MPEG-4系統允許傳輸各種類型的數據，包括Java小程序（MPEG-J）和腳本。本負
載格式限定為音頻和視頻流，因而不能用于傳輸這些活動內容。
7. 參考文獻
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-
visual objects - Part2: Visual".
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-
visual objects - Part3: Audio".
4 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding
of audio-visual objects - Part 2: Visual, Amendment 1: Visual
extensions".
5 ISO/IEC 14496-3:1999/Amd.1:2000, "Information technology - Coding
of audio-visual objects - Part3: Audio, Amendment 1: Audio
extensions".
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-
visual objects - Part1: Systems".
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A
Transport Protocol for Real Time Applications", RFC 1889, January
1996.
9 ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding
of audio-visual objects - Part2: Visual, Technical corrigendum 1".
8. 作者地址
Yoshihiro Kikuchi
Toshiba corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
EMail: yoshihiro.kikuchi@toshiba.co.jp
Yoshinori Matsui
Matsushita Electric Industrial Co., LTD.
1006, Kadoma, Kadoma-shi, Osaka, Japan
EMail: matsui@drl.mei.co.jp
Toshiyuki Nomura
NEC Corporation
4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
EMail: t-nomura@ccm.cl.nec.co.jp
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
EMail: fukunaga444@oki.co.jp
Hideaki Kimata
Nippon Telegraph and Telephone Corporation
1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
EMail: kimata@nttvdt.hil.ntt.co.jp
9. 版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
致謝
Funding for the RFC Editor function is currently provided by the
Internet Society.
RRC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
用于MPEG-4視聽流的RTP負載格式