组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：&nbsp;李超（licc_li&nbsp;，licc_li@sina.com）<br />
译文发布时间：2001-4-26<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Kikuchi<br />
Request&nbsp;for&nbsp;Comments:&nbsp;3016&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Toshiba<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T.&nbsp;Nomura<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NEC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Fukunaga<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Oki<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Matsui<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Matsushita<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H.&nbsp;Kimata<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NTT<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;November&nbsp;2000<br />
<br />
用于MPEG-4视听流的RTP负载格式<br />
（RRC3016&nbsp;RTP&nbsp;Payload&nbsp;Format&nbsp;for&nbsp;MPEG-4&nbsp;Audio/Visual&nbsp;Streams）<br />
<br />
<br />
本备忘录的状态<br />
&nbsp;&nbsp;本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以<br />
得到改进。请参考最新版的“Internet正式协议标准”&nbsp;(STD1)来获得本协议的标准化程度<br />
和状态。本备忘录的发布不受任何限制。<br />
版权声明<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
摘要<br />
&nbsp;&nbsp;&nbsp;本文描述了在不使用MPEG-4系统的情况下携带MPEG-4音频和视觉码流的RTP负载格式。为了能<br />
直接将MPEG-4音频/视觉码流映射到RTP包上，它提供了RTP包头字段的使用规范和分片规则。同<br />
时文档中还规定了MIME类型注册和会话描述协议(SDP)的使用。<br />
目录<br />
本备忘录的状态	1<br />
版权声明	1<br />
摘要	1<br />
1.&nbsp;介绍	2<br />
1.1&nbsp;MPEG-4视觉RTP负载格式	3<br />
1.2&nbsp;MPEG-4音频RTP负载格式	3<br />
2.&nbsp;要求的术语	4<br />
3.&nbsp;MPEG-4视觉码流的RTP组包	4<br />
3.1&nbsp;MPEG-4视觉中RTP头字段的使用	4<br />
3.2&nbsp;MPEG-4视觉码流分片	5<br />
3.3&nbsp;MPEG-4视觉码流组包示例	6<br />
4.&nbsp;MPEG-4音频码流的RTP组包	7<br />
4.1&nbsp;RTP包格式	7<br />
4.2&nbsp;MPEG-4音频中RTP头字段的使用	8<br />
4.3&nbsp;MPEG-4音频码流分片	9<br />
5.&nbsp;MPEG-4视听流MIME类型注册	9<br />
5.1&nbsp;MPEG-4视觉MIME类型注册	9<br />
5.2&nbsp;MPEG-4视觉中SDP的用法	10<br />
5.3&nbsp;MPEG-4音频MIME类型登记	11<br />
5.4&nbsp;SDP&nbsp;usage&nbsp;of&nbsp;MPEG-4&nbsp;Audio	12<br />
6.&nbsp;安全性考虑	13<br />
7.&nbsp;参考文献	13<br />
8.&nbsp;作者地址	13<br />
9.&nbsp;版权声明	14<br />
致谢	14<br />
<br />
1.&nbsp;介绍<br />
本文描述的RTP负载格式规定了如何对MPEG-4音频流[3][5]和MPEG-4视觉流[2][4]进行分<br />
片并直接映射到RTP包中。<br />
	通过定义这些RTP负载格式，应用在不使用MPEG-4系统同步和流管理功能的情况下也能直接<br />
传输MPEG-4音频/视觉流。本文的RTP负载格式可应用于那些本身有流管理功能且不需要MPEG-4<br />
系统中类似功能的系统。例如H.323终端，其MPEG-4音/视频流的管理就不通过MPEG-4系统对象描<br />
述符进行管理，而是使用了H.245。流直接映射到RTP包中，并没有使用MPEG-4系统同步层。其它<br />
例子包括SIP和RTSP，它们使用了MIME和SDP。本文所述之RTP负载格式定义了MIME类型和SDP的用<br />
法，直接规定了不使用MPEG-4系统时的音/视觉流属性（如，媒体类型，打包格式和编码配置）。<br />
这样做明显的优点在于可以象对付那些非MPEG-4编码格式一样，采用一种通用的方法来对这些<br />
MPEG-4音频/视觉RTP负载格式进行处理。而缺点在于同基于MPEG-4系统环境的互操作可能会比较<br />
困难，其它负载格式则更适用于这些应用。<br />
	在此情况下，RTP包头的语义必须定义的非常清晰，其中包括MPEG-4音/视频数据元素的关<br />
系。此外，为了增强错误恢复能力，在MPEG-4视频流内部提供错误恢复工具，最好能为MPEG-4<br />
视频流定义好RTP包的分片规则。<br />
1.1&nbsp;MPEG-4视觉RTP负载格式<br />
MPEG-4视觉是一种视觉编码标准，它具有如下新特征：高编码效率；高错误恢复性；基于<br />
多样的，任意形的对象编码；等等[2]。其速率范围介于数Kbps到几Mbps。并且它能适应从无差<br />
错网络到高错误率的移动网络等多种网络类型。<br />
针对本文中定义的MPEG-4视觉码流的分片规则我们应当注意到，由于MPEG-4视觉将用于多<br />
种网络类型，因此在分片方面不应有太多的限制。诸如“单个视频包需映射到单个RTP包”这样<br />
的分片规则是不合理的。另一方面，大意，以及未知媒体分片也可能导致错误恢复率和带宽利用<br />
率的下降。本文描述的分片规则十分灵活，但在应用MPEG-4视觉错误恢复功能时为了避免无意义<br />
的分片也要定义一个最小的规则集。<br />
分片规则建议不要在一个RTP包中映射多个VOP，这样可以保证RTP时间戳能唯一地表示VOP<br />
分帧时间。而相反地，由于MPEG-4视频可以产生非常小的VOP，如一个只包含VOP头的空VOP&nbsp;<br />
(vop_coded=0)或者一个仅有少量码块的任意形VOP。为了减低开销，分片规则应允许将多个VOP<br />
连接到一个RTP包中。（参见3.2节分片规则(4)和3.1节标志位和时间戳）<br />
在H.261或MPEG-1/2等视频编码工具中往往通过所定义的额外媒体RTP包头来帮助在包丢失<br />
时恢复损坏的图片包头，而MPEG-4视觉已经为此提供了错误恢复功能，它们可用于RTP/IP网络，<br />
也可用于其它网络（H.223/Mobile,MPEG-2/TS等）。因此，无需在MPEG-4视觉RTP负载格式中定<br />
义额外的RTP包头。<br />
1.2&nbsp;MPEG-4音频RTP负载格式<br />
&nbsp;&nbsp;&nbsp;MPEG-4音频是一种集成了多种类型音频编码工具的新型音频标准。LATM(低负担MPEG-4音频传<br />
输复用)通过相当小的耗费来管理音频数据序列。对那些仅有音频的应用，不使用MPEG-4系统而<br />
采用直接将基于LATM的MPEG-4音频码流映射到RTP包的方式是很值得的。<br />
	LATM有如下几项复用特性：<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;在音频数据中携带配置信息，<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;将多个音频帧连接到一个音频流中，<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;多对象（程序）复用<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;可伸缩层的复用，<br />
	在RTP传输中不需要最后两项性质。因此，基于本文规定的RTP组包原则的应用程序不能使<br />
用这两个性质。由于LATM是为自然音频编码工具所开发，而非为合成工具开发，要用其来传输结<br />
构化音频(SA)数据和文语转换接口(TTSI)数据是很困难的。所以不能通过本文档的RTP组包方法<br />
传输SA数据和TTSI数据。<br />
	为了传输可伸缩流，每层的音频数据都应当打包到不同的RTP包，如此才可保证在IP层对不<br />
同层有不同的处理，比如通过一些区分服务。另一方面，可伸缩流的所有配置数据都包含于一个<br />
LATM配置数据"SteamMuxConfig"中，并且每一层共享该&nbsp;StreamMuxConfig。层与其配置数据的映<br />
射是通过音频数据附带的LATM头信息来完成的。为了表示可缩放流的依赖信息，还针对负载类型<br />
(PT)值(见4.2节)的动态分配规则使用了一种限制措施。<br />
对于MPEG-4音频编码工具而言，如果负载为单个音频帧，则包的丢失不会影响邻近包的解<br />
码。这同样也适用于其它音频编码器。因此MPEG-4音频不需要附加的用于错误恢复的媒体特定头。<br />
可采用已经存在的一些RTP保护机制来提高错误恢复率，如通用前向纠错(RFC&nbsp;2733)和冗余音频<br />
数据(RFC&nbsp;2198)。<br />
2.&nbsp;要求的术语<br />
本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，<br />
“建议”，“或许”，“可选的”在&nbsp;RFC&nbsp;2119&nbsp;中解释。&nbsp;&nbsp;&nbsp;<br />
3.&nbsp;MPEG-4视觉码流的RTP组包<br />
	本节规定了MPEG-4视觉内容的RTP组包规则。一个MPEG-4视觉码流可直接映射到RTP包而不<br />
需要增加额外的头字段或者删除任何视觉语法元素。为了将基本流的配置信息在相同的RTP端口<br />
上传送，必须使用合并配置/基本流模式。（参见ISO/IEC&nbsp;14496-2[2][9][4]中6.2.1"开始编码"）<br />
配置信息可以通过带外方式规定。对于H.323终端，必须使用H.245码<br />
点"decoderConfigurationInformation"。如果系统使用MIME内容类型和SDP参数，如SIP和RTSP，<br />
则必须用可选参数"config"来规定配置信息（参见5.1和5.2）。<br />
	当使用了短视频头模式时，应该H.263的RTP负载格式（建议使用RFC2429定义的格式，但也<br />
可使用RFC2190格式以实现同旧系统的兼容性）。<br />
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|V=2|P|X|&nbsp;&nbsp;CC&nbsp;&nbsp;&nbsp;|M|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sequence&nbsp;number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;RTP<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;timestamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Header<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;synchronization&nbsp;source&nbsp;(SSRC)&nbsp;identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;contributing&nbsp;source&nbsp;(CSRC)&nbsp;identifiers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;RTP<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPEG-4&nbsp;Visual&nbsp;stream&nbsp;(byte&nbsp;aligned)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Pay-<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;load<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:...OPTIONAL&nbsp;RTP&nbsp;padding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Figure&nbsp;1&nbsp;–&nbsp;一个MPEG-4视觉流的RTP包<br />
3.1&nbsp;MPEG-4视觉中RTP头字段的使用<br />
&nbsp;&nbsp;&nbsp;负载类型(PT):&nbsp;为新的包格式分配RTP负载类型超出了本文的范畴，不在此赘述。特定类<br />
型应用程序的RTP框架应该负责负载类型的分配，如若不能则应该通过带外信令协议（如，<br />
H.245,SIP等）在动态范围内选择一个负载类型。<br />
&nbsp;&nbsp;&nbsp;扩展位(Extension-X&nbsp;bit):&nbsp;由使用的RTP框架定义。<br />
&nbsp;&nbsp;&nbsp;序列号（Sequence&nbsp;Number）:&nbsp;为了安全从一个随机初始化值开始，每发送一个RTP数据包加1。<br />
&nbsp;&nbsp;&nbsp;标志位（Marker-M）&nbsp;bit:&nbsp;标志位设为1标志这是VOP的最后一个（或仅有一个）RTP包。若一<br />
个RTP包中携带有多个VOP则标志位也设为1。<br />
&nbsp;&nbsp;&nbsp;时间戳（Timestamp）:&nbsp;时间戳表示RTP包中的VOP采样时间。为了安全，加上了一个随机常数<br />
偏移。<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;当一个RTP包携带多个VOP时，时间戳表示其中最早的一个VOP的时间。其它VOP的时间戳信<br />
息通过VOP头的时间戳字段可得（modulo_time_base和vop_time_increment）。<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;如果RTP包只含有配置信息或Group_of_VideoObjectPlane()字段，使用编码队列中下一个<br />
VOP的时间戳。<br />
-	如果RTP包仅含有visual_object_sequence_end_code信息，使用编码队列中前一个VOP<br />
的时间戳。<br />
除非由带外方式规定，时间戳分辨率设为缺省值90KHz。<br />
&nbsp;&nbsp;&nbsp;其它头字段的使用见RFC&nbsp;1889&nbsp;[8]。<br />
3.2&nbsp;MPEG-4视觉码流分片<br />
&nbsp;&nbsp;&nbsp;使用合并配置/基本流模式，经过分片的MPEG-4视觉码流直接映射到RTP负载而不用增加任何<br />
额外头字段或者删除视觉语法元素。分片时可应用如下规则。<br />
&nbsp;&nbsp;&nbsp;下文中，头（Header）可能表示如下信息：<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;配置信息（视觉对象序列头，视觉对象头和视频对象层头）<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;visual_object_sequence_end_code<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;基本流的进入点函数头（Group_of_VideoObjectPlane(),<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;video_plane_with_short_header(),&nbsp;MeshObject()或FaceObject())<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;视频包头&nbsp;(video_packet_header()，next_resync_marker()除外)<br />
&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;gob_layer()头<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;配置信息和进入点函数的定义参见ISO/IEC&nbsp;14496-2&nbsp;[2][9][4]的6.2.1&nbsp;"开始编码"<br />
&nbsp;&nbsp;&nbsp;(1)&nbsp;配置信息和Group_of_VideoObjectPlane()字段应位于RTP负载的开始位置或在语法上的<br />
上层函数头之后。&nbsp;<br />
&nbsp;&nbsp;&nbsp;(2)&nbsp;如果RTP负载中存在一个或多个头，则RTP负载应从语法上的最高函数头开始。<br />
&nbsp;&nbsp;&nbsp;注意:&nbsp;visual_object_sequence_end_code作为最低函数。<br />
&nbsp;&nbsp;&nbsp;(3)&nbsp;一个头不应分到多个RTP包中。<br />
&nbsp;&nbsp;&nbsp;(4)&nbsp;不同的VOP应该分片为不同的RTP包，一个RTP包只包括与唯一VOP的时间相关的数据（在<br />
RTP包头的时间戳字段中指出）。例外情况是如果VOP很小，则单个RTP包携带多个按解码顺序连<br />
续的VOP。<br />
&nbsp;&nbsp;&nbsp;注意：当一个RTP负载携带了多个VOP时，第一个VOP后的VOP时间戳在解码时通过计算得到。<br />
该操作仅当RTP包标志位为1且RTP负载开始符合起始码时才是必须的。&nbsp;(见3.1节时间戳和标志<br />
位)<br />
&nbsp;&nbsp;&nbsp;(5)&nbsp;建议一个视频包组成一个RTP包进行发送。视频包的大小应该按如下方式来决定，即，结<br />
果RTP包大大小不得超过路径MTU的大小。<br />
&nbsp;&nbsp;&nbsp;注意：规则(5)不适用于以下场合，编码器配置禁止视频包（通过将VOL头中的<br />
resync_marker_disable设置为1），或者编码工具不支持视频包。在此情况下，一个VOP可能得<br />
经过在任意字节位置进行分片后才能发送。<br />
&nbsp;&nbsp;&nbsp;视频包从VOP头或视频包头开始，后面紧接着是motion_shape_texture()，以&nbsp;<br />
next_resync_marker()或next_start_code()结束。<br />
3.3&nbsp;MPEG-4视觉码流组包示例<br />
&nbsp;&nbsp;&nbsp;Figure&nbsp;2所示为按照3.2描述标准产生的RTP包的例子。<br />
&nbsp;&nbsp;&nbsp;(a)例表示包含了配置信息的MPEG-4视觉码流中第一个RTP包或随机访问点。根据规则&nbsp;(1)，<br />
视觉对象序列头应位于RTP负载的开始处，视觉对象头和视频对象层头(VO&nbsp;header,&nbsp;VOL&nbsp;header)<br />
之前。3.2中定义的分片规则保证了从visual_object_sequence_start_code开始的配置信息通常<br />
都位于RTP负载的开始位置，RTP接收端可通过检查RTP负载的头32位字段是否是<br />
visual_object_sequence_start_code来检测随机访问点。<br />
&nbsp;&nbsp;&nbsp;(b)是另一个包含配置信息的RTP包例子。它同(1)的区别为该RTP包在VOP中的配置信息后还包<br />
含有视频包。由于配置信息长度很短（一般为数十字节），一个RTP包如果仅含有配置信息会造<br />
成系统开销的上升，因此配置信息和其后的GOV和/或(部分)VOP可以打包到同一个RTP包中，如此<br />
例中所示。<br />
&nbsp;&nbsp;&nbsp;(c)是RTP包中包含了Group_of_VideoObjectPlane(GOV)的例子。根据规则(1)，GOV位于RTP<br />
负载的开始位置。一个仅有GOV字段的RTP包大小只有7个字节，这是对RTP/IP头开销的极大浪费。<br />
因此后续的VOP(或部分地)可以如本例所示打到同一个RTP包中。<br />
&nbsp;&nbsp;&nbsp;(d)例中，一个视频包被打包到一个RTP包中。当网络中包丢失率很高时推荐采用该方法。甚<br />
至当包含有VOP头的RTP包被丢弃时其它RTP包还可通过使用视频包头中的HEC信息进行解码。无需<br />
任何额外的RTP头字段。<br />
&nbsp;&nbsp;&nbsp;(e)例为多个视频包打在一个RTP包中的情况。&nbsp;在底层网络速率很低时这种组包方式可高效地<br />
节约RTP/IP头开销。不过，由于一个RTP包的丢失会导致将多个视频包同时丢失，这种方法会降<br />
低丢包恢复率。一个RTP包中理想的视频包数目和RTP包长度可通过丢包率和底层网络传输的比特<br />
率来决定。<br />
&nbsp;&nbsp;&nbsp;(f)示例为在VOL头中将resync_marker_disable设置为1从而禁止使用视频包。在此情况下，<br />
一个VOP可按照任意字节位置分为多个RTP包。比如将一个VOP按照固定长度进行分片。这种编码<br />
配置方法和RTP分片可应用于能提供极低错误率保证的网络。另一方面，由于它的丢包恢复率很<br />
差，建议不要在error-prone环境中使用。<br />
Figure&nbsp;3&nbsp;所示为按3.2规则建立的RTP包。<br />
按照(a)中将一个头分片到多个RTP包不仅造成RTP/IP头开销增加，也导致了错误恢复能力<br />
的下降。因此在规则(3)中禁止这样做。<br />
当将多个视频包串联到一个RTP包中时，VOP头或video_packet_header()不应放到RTP负载<br />
的中间。基于错误恢复的目的，(b)中的组包方法违反了规则(2)。比较该例同图2中的例6，尽管<br />
两者都是把两个视频包映射到两个RTP包中，其丢包恢复率却不一样。即是说，假设第二个RTP<br />
包丢失了，图3例(b)中两个视频包都将丢失，而在图2例(d)中仅丢失视频包2。<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------+------+<br />
(a)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;&nbsp;VS&nbsp;&nbsp;|&nbsp;&nbsp;VO&nbsp;&nbsp;|&nbsp;VOL&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|header|header|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------+------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------+------+------------+<br />
(b)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;&nbsp;VS&nbsp;&nbsp;|&nbsp;&nbsp;VO&nbsp;&nbsp;|&nbsp;VOL&nbsp;&nbsp;|Video&nbsp;Packet|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|header|header|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------+------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+-----+------------------+<br />
(c)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;GOV&nbsp;|Video&nbsp;Object&nbsp;Plane|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+-----+------------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+&nbsp;&nbsp;+------+------+------------+<br />
(d)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;VOP&nbsp;&nbsp;|Video&nbsp;Packet|&nbsp;&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;&nbsp;VP&nbsp;&nbsp;|Video&nbsp;Packet|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|&nbsp;&nbsp;&nbsp;&nbsp;(1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;|header|header|&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+&nbsp;&nbsp;+------+------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+------+------------+------+------------+<br />
(e)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;&nbsp;VP&nbsp;&nbsp;|Video&nbsp;Packet|&nbsp;&nbsp;VP&nbsp;&nbsp;|Video&nbsp;Packet|&nbsp;&nbsp;VP&nbsp;&nbsp;|Video&nbsp;Packet|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(1)&nbsp;&nbsp;&nbsp;&nbsp;|header|&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|header|&nbsp;&nbsp;&nbsp;&nbsp;(3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+------+------------+------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+&nbsp;&nbsp;+------+------------+<br />
(f)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;VOP&nbsp;&nbsp;|VOP&nbsp;fragment|&nbsp;&nbsp;|&nbsp;RTP&nbsp;&nbsp;|VOP&nbsp;fragment|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|&nbsp;&nbsp;&nbsp;&nbsp;(1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;|header|&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;___<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+------------+&nbsp;&nbsp;+------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;图2&nbsp;–&nbsp;RTP组包的MPEG-4视觉码流示例<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+-------------+&nbsp;&nbsp;+------+------------+------------+<br />
(a)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|First&nbsp;half&nbsp;of|&nbsp;&nbsp;|&nbsp;RTP&nbsp;&nbsp;|Last&nbsp;half&nbsp;of|Video&nbsp;Packet|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|&nbsp;&nbsp;VP&nbsp;header&nbsp;&nbsp;|&nbsp;&nbsp;|header|&nbsp;&nbsp;VP&nbsp;header&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+-------------+&nbsp;&nbsp;+------+------------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+----------+&nbsp;&nbsp;+------+---------+------+------------+<br />
(b)&nbsp;|&nbsp;RTP&nbsp;&nbsp;|&nbsp;VOP&nbsp;&nbsp;|First&nbsp;half|&nbsp;&nbsp;|&nbsp;RTP&nbsp;&nbsp;|Last&nbsp;half|&nbsp;&nbsp;VP&nbsp;&nbsp;|Video&nbsp;Packet|<br />
&nbsp;&nbsp;&nbsp;&nbsp;|header|header|&nbsp;of&nbsp;VP(1)&nbsp;|&nbsp;&nbsp;|header|&nbsp;of&nbsp;VP(1)|header|&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+------+------+----------+&nbsp;&nbsp;+------+---------+------+------------+<br />
<br />
&nbsp;&nbsp;&nbsp;图3&nbsp;–&nbsp;禁止RTP组包的MPEG-4视觉码流示例<br />
<br />
4.&nbsp;MPEG-4音频码流的RTP组包<br />
本节规定了MPEG-4音频码流的RTP组包规则。MPEG-4音频流必须通过LATM工具进行格式化，<br />
然后基于LATM的流将按照下面三节的描述映射到RTP包上。<br />
4.1&nbsp;RTP包格式<br />
基于LATM的流由一个包含了一个或多个音频帧的audioMuxElements序列组成。一个完整或<br />
部分完整的audioMuxElement可直接映射到一个RTP负载上，无需删除任何audioMuxElement语法<br />
元素&nbsp;(见图4)。每个audioMuxElement的第一个字节应该位于RTP包第一个负载所在的位置。<br />
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|V=2|P|X|&nbsp;&nbsp;CC&nbsp;&nbsp;&nbsp;|M|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sequence&nbsp;number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|RTP<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;timestamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|Header<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;synchronization&nbsp;source&nbsp;(SSRC)&nbsp;identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;contributing&nbsp;source&nbsp;(CSRC)&nbsp;identifiers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|RTP<br />
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;audioMuxElement&nbsp;(byte&nbsp;aligned)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:Payload<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:...OPTIONAL&nbsp;RTP&nbsp;padding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;图4&nbsp;–&nbsp;一个MPEG-4音频RTP包<br />
为了对audioMuxElement进行解码，必需得在其后通过带外方法指明muxConfigPresent。当<br />
SDP用于此指示时，MIME参数"cpresent“就对应了muxConfigPresent信息。(见5.3节).<br />
muxConfigPresent:&nbsp;如果该值为1(带内模式)，audioMuxElement应包括一个指示位<br />
"useSameStreamMux"并且可能包括一个音频压缩配置信息"StreamMuxConfig"。<br />
UseSameStreamMux位表示是否前一帧中的StreamMuxConfig元素也应用于本帧。如果<br />
useSameStreamMux位指示要使用前一帧的StreamMuxConfig，而前一帧已经丢失，则将无法对当<br />
前帧进行解码。因此，在带内模式下，StreamMuxConfig元素应根据网络条件重复传输。相反，<br />
如果muxConfigPresent设为0(带外模式)，StreamMuxConfig元素需要通过带外方式传输。如果是<br />
SDP，则要使用MIME参数"config"&nbsp;(见5.3节).<br />
4.2&nbsp;MPEG-4音频中RTP头字段的使用<br />
&nbsp;&nbsp;&nbsp;负载类型(PT):&nbsp;为这种新的包格式分配RTP负载类型超出了本文的范畴，不在此赘述。特<br />
定类型应用程序的RTP框架应该负责为编码分配负载类型，如若不能则应该通过带外信令协<br />
议（如，H.245,SIP等）在动态范围内选择一个负载类型。在为可伸缩流动态分配RTP负载类<br />
型时，应该为每一层分配不同的值。这些值应按层依赖关系的强弱顺序进行分配，最基本的<br />
层拥有最小的值。<br />
&nbsp;&nbsp;&nbsp;标志位(M):&nbsp;标志位指出了audioMuxElement范围。置为1说明RTP包包含有完整的&nbsp;&nbsp;&nbsp;<br />
audioMuxElement或audioMuxElement分片的最后一片。<br />
&nbsp;&nbsp;&nbsp;时间戳:&nbsp;时间戳表示RTP包中第一个音频帧的采样时间。从安全角度出发，建议时间戳从一个<br />
随机值开始。除非指定使用带外方式，时间戳的分辨率设为缺省值90KHz。<br />
&nbsp;&nbsp;&nbsp;顺序号:&nbsp;为了更加安全，顺序号应从一个随机初始化值开始，每发送一个RTP数据包加1。<br />
&nbsp;&nbsp;&nbsp;其它头字段的使用遵照RFC&nbsp;1889&nbsp;[8]。<br />
4.3&nbsp;MPEG-4音频码流分片<br />
	建议每个RTP包中只放一个audioMuxElement。如果audioMuxElement的大小保持得足够小，<br />
使得RTP包的大小不超过路径MTU的大小，则没有问题。否则就得将audioMuxElement分片到多个<br />
包中。<br />
5.&nbsp;MPEG-4视听流MIME类型注册<br />
&nbsp;&nbsp;&nbsp;接下来的几节描述了MPEG-4视听流的MIME类型注册。MPEG-4视觉流的MIME类型注册和SDP使用<br />
在5.1和5.2节中描述，而MPEG-4音频流的MIME类型注册和SDP用法在5.3和5.4中描述。<br />
5.1&nbsp;MPEG-4视觉MIME类型注册<br />
&nbsp;&nbsp;&nbsp;MIME媒体类型名:&nbsp;video<br />
&nbsp;&nbsp;&nbsp;MIME子类型名:&nbsp;MP4V-ES<br />
&nbsp;&nbsp;&nbsp;必需的参数:&nbsp;none<br />
&nbsp;&nbsp;&nbsp;可选参数:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rate(速率):&nbsp;该参数仅用于RTP传输。表示RTP头时间戳字段的分辨率。如果未指定该参数<br />
则使用缺省值90000(90KHz)。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;profile-level-id(框架级别ID):&nbsp;一个表示Table&nbsp;G-1&nbsp;of&nbsp;ISO/IEC&nbsp;14496-2&nbsp;[2][4]定义<br />
的MPEG-4视觉框架和级别值的十进制数&nbsp;(profile_and_level_indication)。该参数可用于性能<br />
交换或事务建立过程中以表示MPEG-4视觉框架和MPEG-4视觉编码器能达到的级别组合。如未指定<br />
该参数，则采用缺省值1。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Config(配置):&nbsp;该参数用于表示相应MPEG-4视觉流的配置。不应用于表示性能交换过程中<br />
的编码能力。它是一个16进制形式的8位字节串，可表示ISO/IEC14496-2&nbsp;[2][4][9]6.2.1小节中<br />
定义的MPEG-4视觉配置信息。该配置信息可按照MSB（最高有效位）优先原则直接映射到8位字节<br />
串。配置信息的第一位应位于第一个8位组的MSB。该参数表示的配置信息应和相应的MPEG-4视觉<br />
流的配置信息相同，除了first_half_vbv_occupancy和latter_half_vbv_occupancy，如果存在，<br />
那么它在MPEG-4视觉流内重复的配置信息方面有所不同。(见ISO/IEC14496-2的6.2.1小节“开始<br />
编码”).<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;关于该参数的用法示例如下:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;MPEG-4&nbsp;Visual&nbsp;Simple&nbsp;Profile/Level&nbsp;1:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Content-type:&nbsp;video/mp4v-es;&nbsp;profile-level-id=1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;MPEG-4&nbsp;Visual&nbsp;Core&nbsp;Profile/Level&nbsp;2:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Content-type:&nbsp;video/mp4v-es;&nbsp;profile-level-id=34<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;MPEG-4&nbsp;Visual&nbsp;Advanced&nbsp;Real&nbsp;Time&nbsp;Simple&nbsp;Profile/Level&nbsp;1:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Content-type:&nbsp;video/mp4v-es;&nbsp;profile-level-id=145<br />
&nbsp;&nbsp;&nbsp;已发行规范:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPEG-4视觉流规范参见ISO/IEC&nbsp;14469-2&nbsp;[2][4][9]。RTP负载格式在RFC&nbsp;3016中描述。<br />
&nbsp;&nbsp;&nbsp;编码考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;视频位流必须参照MPEG-4视觉规范(ISO/IEC&nbsp;14496-2)产生。一个视频位流是二进制数据，<br />
必须编码为可按非二进制传输(对于Email，Base64编码就已经足够了)。该类型也定义为通过RTP<br />
传输。RTP包必须遵照RFG&nbsp;3016定义的MPEG-4视觉RTP负载格式进行组包。<br />
&nbsp;&nbsp;&nbsp;安全性考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参见RFC&nbsp;3016第6节。<br />
&nbsp;&nbsp;&nbsp;互操作考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPEG-4视觉为视觉对象编码提供了大量丰富的工具集。为了高效地实现标准，也为特定的<br />
应用提供了MPEG-4视觉工具子集。这些子集称做'Profiles',限制了实现一个编码器所需要的工<br />
具集的大小。为了控制计算复杂性，每个Profile分为若干级别。Profile@Level组合如下:<br />
?	一个编解码器开发者，负责实现所需的标准子集，维护和相同组合内其它MPEG-4设备<br />
的相互作用。<br />
?	检查MPEG-4设备是否符合标准&nbsp;('一致性测试')。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;视觉流应同参数"profile-level-id"中规定的MPEG-4视觉Profile@Level兼容。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;发送方与接收方的互操作性，通过在MIME内容中指定参数"profile-level-id"，或者通过<br />
协调性能交换/声明过程将该参数设为相同值来实现。<br />
&nbsp;&nbsp;&nbsp;使用该媒体类型的应用:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;视听流和会议工具，Internet消息和电子邮件应用。<br />
&nbsp;&nbsp;&nbsp;附带信息:&nbsp;无<br />
&nbsp;&nbsp;&nbsp;联系人及其邮件地址：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;3016作者(见第8节)。<br />
&nbsp;&nbsp;&nbsp;预期用法:&nbsp;COMMON<br />
&nbsp;&nbsp;&nbsp;作者或修订者:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;3016作者(见第8节)。<br />
5.2&nbsp;MPEG-4视觉中SDP的用法<br />
&nbsp;&nbsp;&nbsp;MIME媒体类型video/MP4V-ES串可映射到SDP(RFC&nbsp;2327)，如下：<br />
?	MIME类型(video)加入SDP&nbsp;"m="作为媒体名。<br />
?	MIME子类型加入SDP&nbsp;"a=rtpmap"作为编码名。<br />
?	可选参数"rate"加入"a=rtpmap"作为时钟速率<br />
?	可选参数"profile-level-id"和"config"加入"a=fmtp"行分别表示编码器能力和配<br />
置。这些参数以分号分隔，按照“参数=值”的成对形式表示为MIME媒体类型串。<br />
&nbsp;&nbsp;&nbsp;下面是SDP中的媒体表示示例:<br />
Simple&nbsp;Profile/Level&nbsp;1,&nbsp;rate=90000(90kHz),&nbsp;"profile-level-id"且"config"存在于&nbsp;<br />
"a=fmtp"行:<br />
?	m=video&nbsp;49170/2&nbsp;RTP/AVP&nbsp;98<br />
?	a=rtpmap:98&nbsp;MP4V-ES/90000<br />
?	a=fmtp:98&nbsp;<br />
profile-level-id=1;config=000001B001000001B5090000010000000120008440FA282C<br />
2090A21F<br />
Core&nbsp;Profile/Level&nbsp;2,&nbsp;rate=90000(90kHz),&nbsp;"profile-level-id"存在于"a=fmtp"行:<br />
?	m=video&nbsp;49170/2&nbsp;RTP/AVP&nbsp;98<br />
?	a=rtpmap:98&nbsp;MP4V-ES/90000<br />
?	a=fmtp:98&nbsp;profile-level-id=34<br />
Advance&nbsp;Real&nbsp;Time&nbsp;Simple&nbsp;Profile/Level&nbsp;1,&nbsp;rate=90000(90kHz),"profile-level-id"存在于<br />
"a=fmtp"行:<br />
&nbsp;&nbsp;m=video&nbsp;49170/2&nbsp;RTP/AVP&nbsp;98<br />
&nbsp;&nbsp;a=rtpmap:98&nbsp;MP4V-ES/90000<br />
&nbsp;&nbsp;a=fmtp:98&nbsp;profile-level-id=145<br />
5.3&nbsp;MPEG-4音频MIME类型登记<br />
&nbsp;&nbsp;&nbsp;MIME媒体类型名:&nbsp;audio<br />
&nbsp;&nbsp;&nbsp;MIME子类型名:&nbsp;MP4A-LATM<br />
&nbsp;&nbsp;&nbsp;必需参数:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;速率:&nbsp;速率参数表示RTP时间戳的时钟速率。缺省值为90000。仅当该值设置为与音频<br />
采样频率（每秒钟采样数）相同值时也可指定其它非缺省速率。<br />
&nbsp;&nbsp;&nbsp;可选参数:<br />
profile-level-id:&nbsp;一个十进制形式的MPEG-4音频框架级别表示值，定义于<br />
ISO/IEC&nbsp;14496-1&nbsp;([6]及其修订版本)。该参数表示解码器可以使用哪个MPEG-4音频工<br />
具子集。如果没有在性能交换或者事务建立过程中指定该参数，则使用缺省值30（自然<br />
音频Profile/Level&nbsp;1）<br />
object:&nbsp;一个十进制形式的MPEG-4音频对象类型值，定义于ISO/IEC&nbsp;14496-3&nbsp;[5]。<br />
该参数指定了编码器使用的工具。可用该参数来限制性能于规定的"profile-level-id"<br />
之下。<br />
bitrate:&nbsp;音频数据流的数据传输率。<br />
cpresent:&nbsp;一个布尔值参数，表示音频负载配置数据是否已经复用到一个RTP负载<br />
中（参见4.1）。0表示尚未复用，1表示已经复用。该参数的缺省值为1。<br />
config:&nbsp;一个16进制形式的8位字节串，可表示ISO/IEC&nbsp;14496-3&nbsp;[5]&nbsp;(参见4.1)<br />
定义的MPEG-4音频负载配置数据"StreamMuxConfig"。该配置信息可按照MSB（最高有效<br />
位）优先原则直接映射到8位字节串。配置数据的第一位应位于第一个8位组的MSB。在<br />
最后一个8位组中,如果需要，应该在配置数据后跟随填充0。<br />
ptime:&nbsp;推荐的包持续时间，单位毫秒。<br />
&nbsp;&nbsp;&nbsp;已发行规范:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;本文描述了负载格式规范。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;编码规范遵照ISO/IEC&nbsp;14496-3&nbsp;[3][5]。<br />
&nbsp;&nbsp;&nbsp;编码考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;该类型仅定义为用于通过RTP进行传输。<br />
&nbsp;&nbsp;&nbsp;安全性考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参见RFC&nbsp;3016第6节。<br />
&nbsp;&nbsp;&nbsp;互操作性考虑:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPEG-4音频提供了大量而丰富的工具用于音频对象编码。为了更高效地实现标准，还<br />
提供了MPEG-4音频工具子集（类似于5.1中的MPEG-4视觉）。音频流工具应同<br />
"profile-level-id"参数指定的Profile@Level一致。发送方与接收方之间的互操作性可通<br />
过在MIME内容中指定参数"profile-level-id"，或在协商性能交换过程中，设置该参数为相<br />
同值来实现。此外参数"object"可用于在性能交换中将能力限制于指定的Profile@Level级<br />
别范围内。<br />
&nbsp;&nbsp;&nbsp;使用该媒体类型的应用:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;视听流与会议工具。<br />
&nbsp;&nbsp;&nbsp;附加信息:&nbsp;无<br />
&nbsp;&nbsp;&nbsp;联系人:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参见RFC&nbsp;3016第8节.<br />
&nbsp;&nbsp;&nbsp;预期用法:&nbsp;COMMON<br />
&nbsp;&nbsp;&nbsp;作者/修订者:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参见RFC&nbsp;3016第8节.<br />
5.4&nbsp;SDP&nbsp;usage&nbsp;of&nbsp;MPEG-4&nbsp;Audio<br />
MIME媒体类型audio/MP4A-LATM串可以映射到SDP（RFC&nbsp;2327）的字段上,&nbsp;如下:<br />
?	MIME类型(audio)加入SDP"m="中作为媒体名。<br />
?	MIME子类型(MP4A-LATM)加入SDP"a=rtpmap"作为编码名称<br />
?	必需参数"rate"加入"a=rtpmap"的作为时钟速率。<br />
?	可选参数"ptime"加入SDP&nbsp;"a=ptime"属性<br />
?	可选参数"profile-level-id"加入"a=fmtp"行表示编码器能力。参数"object"<br />
加入"a=fmtp"&nbsp;属性，负载格式相关参数"bitrate",&nbsp;"cpresent"和&nbsp;"config"<br />
加入"a=fmtp"行。这些参数以分号分隔，按照“参数=值”的成对形式表示MIME<br />
媒体类型串。<br />
&nbsp;&nbsp;&nbsp;下面是SDP中媒体表示的例子：&nbsp;<br />
对于6&nbsp;kb/s的CELP码流&nbsp;(音频采样频率为8&nbsp;kHz),<br />
?	m=audio&nbsp;49230&nbsp;RTP/AVP&nbsp;96<br />
?	a=rtpmap:96&nbsp;MP4A-LATM/8000<br />
?	a=fmtp:96&nbsp;profile-level-id=9;&nbsp;object=8;&nbsp;cpresent=0;&nbsp;<br />
config=9128B1071070<br />
?	a=ptime:20<br />
对于64&nbsp;kb/s的AAC&nbsp;LC立体声码流(音频采样频率为24&nbsp;kHz),<br />
?	m=audio&nbsp;49230&nbsp;RTP/AVP&nbsp;96<br />
?	a=rtpmap:96&nbsp;MP4A-LATM/24000<br />
?	a=fmtp:96&nbsp;profile-level-id=1;&nbsp;bitrate=64000;&nbsp;cpresent=0;<br />
?	config=9122620000<br />
&nbsp;&nbsp;&nbsp;在上面两个例子中，音频配置数据仅通过SDP进行了描述，并没有复用到RTP负载中去。<br />
此外，"时钟速率（clock&nbsp;rate）"也设置为音频采样速率。<br />
&nbsp;&nbsp;&nbsp;如果时钟速率设置为缺省值，并且必须要取得音频采样速率，则可通过解析参数"config"<br />
来实现。举例如下：<br />
?	m=audio&nbsp;49230&nbsp;RTP/AVP&nbsp;96<br />
?	a=rtpmap:96&nbsp;MP4A-LATM/90000<br />
?	a=fmtp:96&nbsp;object=8;&nbsp;cpresent=0;&nbsp;config=9128B1071070<br />
&nbsp;&nbsp;&nbsp;下例显示RTP负载中的音频配置数据。&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
?	m=audio&nbsp;49230&nbsp;RTP/AVP&nbsp;96<br />
?	a=rtpmap:96&nbsp;MP4A-LATM/90000<br />
?	a=fmtp:96&nbsp;object=2;&nbsp;cpresent=1<br />
6.&nbsp;安全性考虑<br />
本规范中描述的RTP包负载格式从属于RTP规范[8]中讨论的安全性考虑。这意味着媒体<br />
流的机密性要通过加密来实现。由于负载格式中数据压缩是端到端的，加密也可在压缩数据<br />
上进行，两种操作间并无矛盾。<br />
	完整的MPEG-4系统允许传输各种类型的数据，包括Java小程序（MPEG-J）和脚本。本负<br />
载格式限定为音频和视频流，因而不能用于传输这些活动内容。<br />
7.&nbsp;参考文献<br />
&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;Bradner,&nbsp;S.,&nbsp;"The&nbsp;Internet&nbsp;Standards&nbsp;Process&nbsp;--&nbsp;Revision&nbsp;3",&nbsp;BCP<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9,&nbsp;RFC&nbsp;2026,&nbsp;October&nbsp;1996.<br />
&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;ISO/IEC&nbsp;14496-2:1999,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding&nbsp;of&nbsp;audio-<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visual&nbsp;objects&nbsp;-&nbsp;Part2:&nbsp;Visual".<br />
&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;ISO/IEC&nbsp;14496-3:1999,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding&nbsp;of&nbsp;audio-<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visual&nbsp;objects&nbsp;-&nbsp;Part3:&nbsp;Audio".<br />
&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;ISO/IEC&nbsp;14496-2:1999/Amd.1:2000,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;audio-visual&nbsp;objects&nbsp;-&nbsp;Part&nbsp;2:&nbsp;Visual,&nbsp;Amendment&nbsp;1:&nbsp;Visual<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;extensions".<br />
&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;ISO/IEC&nbsp;14496-3:1999/Amd.1:2000,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;audio-visual&nbsp;objects&nbsp;-&nbsp;Part3:&nbsp;Audio,&nbsp;Amendment&nbsp;1:&nbsp;Audio<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;extensions".<br />
&nbsp;&nbsp;&nbsp;6&nbsp;&nbsp;ISO/IEC&nbsp;14496-1:1999,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding&nbsp;of&nbsp;audio-<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visual&nbsp;objects&nbsp;-&nbsp;Part1:&nbsp;Systems".<br />
&nbsp;&nbsp;&nbsp;7&nbsp;&nbsp;Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate&nbsp;Requirement<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Levels",&nbsp;BCP&nbsp;14,&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
&nbsp;&nbsp;&nbsp;8&nbsp;&nbsp;Schulzrinne,&nbsp;H.,&nbsp;Casner,&nbsp;S.,&nbsp;Frederick,&nbsp;R.&nbsp;and&nbsp;V.&nbsp;Jacobson&nbsp;"RTP:&nbsp;A<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Transport&nbsp;Protocol&nbsp;for&nbsp;Real&nbsp;Time&nbsp;Applications",&nbsp;RFC&nbsp;1889,&nbsp;January<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1996.<br />
&nbsp;&nbsp;&nbsp;9&nbsp;&nbsp;ISO/IEC&nbsp;14496-2:1999/Cor.1:2000,&nbsp;"Information&nbsp;technology&nbsp;-&nbsp;Coding<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;audio-visual&nbsp;objects&nbsp;-&nbsp;Part2:&nbsp;Visual,&nbsp;Technical&nbsp;corrigendum&nbsp;1".<br />
8.&nbsp;作者地址<br />
&nbsp;&nbsp;&nbsp;Yoshihiro&nbsp;Kikuchi<br />
&nbsp;&nbsp;&nbsp;Toshiba&nbsp;corporation<br />
&nbsp;&nbsp;&nbsp;1,&nbsp;Komukai&nbsp;Toshiba-cho,&nbsp;Saiwai-ku,&nbsp;Kawasaki,&nbsp;212-8582,&nbsp;Japan<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;yoshihiro.kikuchi@toshiba.co.jp<br />
&nbsp;&nbsp;&nbsp;Yoshinori&nbsp;Matsui<br />
&nbsp;&nbsp;&nbsp;Matsushita&nbsp;Electric&nbsp;Industrial&nbsp;Co.,&nbsp;LTD.<br />
&nbsp;&nbsp;&nbsp;1006,&nbsp;Kadoma,&nbsp;Kadoma-shi,&nbsp;Osaka,&nbsp;Japan<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;matsui@drl.mei.co.jp<br />
&nbsp;&nbsp;&nbsp;Toshiyuki&nbsp;Nomura<br />
&nbsp;&nbsp;&nbsp;NEC&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;t-nomura@ccm.cl.nec.co.jp<br />
&nbsp;&nbsp;&nbsp;Shigeru&nbsp;Fukunaga<br />
&nbsp;&nbsp;&nbsp;Oki&nbsp;Electric&nbsp;Industry&nbsp;Co.,&nbsp;Ltd.<br />
&nbsp;&nbsp;&nbsp;1-2-27&nbsp;Shiromi,&nbsp;Chuo-ku,&nbsp;Osaka&nbsp;540-6025&nbsp;Japan.<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;fukunaga444@oki.co.jp<br />
&nbsp;&nbsp;&nbsp;Hideaki&nbsp;Kimata<br />
&nbsp;&nbsp;&nbsp;Nippon&nbsp;Telegraph&nbsp;and&nbsp;Telephone&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;1-1,&nbsp;Hikari-no-oka,&nbsp;Yokosuka-shi,&nbsp;Kanagawa,&nbsp;Japan<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;kimata@nttvdt.hil.ntt.co.jp<br />
9.&nbsp;版权声明<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;translations&nbsp;of&nbsp;it&nbsp;may&nbsp;be&nbsp;copied&nbsp;and&nbsp;furnished&nbsp;to<br />
&nbsp;&nbsp;&nbsp;others,&nbsp;and&nbsp;derivative&nbsp;works&nbsp;that&nbsp;comment&nbsp;on&nbsp;or&nbsp;otherwise&nbsp;explain&nbsp;it<br />
&nbsp;&nbsp;&nbsp;or&nbsp;assist&nbsp;in&nbsp;its&nbsp;implementation&nbsp;may&nbsp;be&nbsp;prepared,&nbsp;copied,&nbsp;published<br />
&nbsp;&nbsp;&nbsp;and&nbsp;distributed,&nbsp;in&nbsp;whole&nbsp;or&nbsp;in&nbsp;part,&nbsp;without&nbsp;restriction&nbsp;of&nbsp;any<br />
&nbsp;&nbsp;&nbsp;kind,&nbsp;provided&nbsp;that&nbsp;the&nbsp;above&nbsp;copyright&nbsp;notice&nbsp;and&nbsp;this&nbsp;paragraph&nbsp;are<br />
&nbsp;&nbsp;&nbsp;included&nbsp;on&nbsp;all&nbsp;such&nbsp;copies&nbsp;and&nbsp;derivative&nbsp;works.&nbsp;&nbsp;However,&nbsp;this<br />
&nbsp;&nbsp;&nbsp;document&nbsp;itself&nbsp;may&nbsp;not&nbsp;be&nbsp;modified&nbsp;in&nbsp;any&nbsp;way,&nbsp;such&nbsp;as&nbsp;by&nbsp;removing<br />
&nbsp;&nbsp;&nbsp;the&nbsp;copyright&nbsp;notice&nbsp;or&nbsp;references&nbsp;to&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;other<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;organizations,&nbsp;except&nbsp;as&nbsp;needed&nbsp;for&nbsp;the&nbsp;purpose&nbsp;of<br />
&nbsp;&nbsp;&nbsp;developing&nbsp;Internet&nbsp;standards&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;procedures&nbsp;for<br />
&nbsp;&nbsp;&nbsp;copyrights&nbsp;defined&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Standards&nbsp;process&nbsp;must&nbsp;be<br />
&nbsp;&nbsp;&nbsp;followed,&nbsp;or&nbsp;as&nbsp;required&nbsp;to&nbsp;translate&nbsp;it&nbsp;into&nbsp;languages&nbsp;other&nbsp;than<br />
&nbsp;&nbsp;&nbsp;English.<br />
&nbsp;&nbsp;&nbsp;The&nbsp;limited&nbsp;permissions&nbsp;granted&nbsp;above&nbsp;are&nbsp;perpetual&nbsp;and&nbsp;will&nbsp;not&nbsp;be<br />
&nbsp;&nbsp;&nbsp;revoked&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;its&nbsp;successors&nbsp;or&nbsp;assigns.<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;the&nbsp;information&nbsp;contained&nbsp;herein&nbsp;is&nbsp;provided&nbsp;on&nbsp;an<br />
&nbsp;&nbsp;&nbsp;"AS&nbsp;IS"&nbsp;basis&nbsp;and&nbsp;THE&nbsp;INTERNET&nbsp;SOCIETY&nbsp;AND&nbsp;THE&nbsp;INTERNET&nbsp;ENGINEERING<br />
&nbsp;&nbsp;&nbsp;TASK&nbsp;FORCE&nbsp;DISCLAIMS&nbsp;ALL&nbsp;WARRANTIES,&nbsp;EXPRESS&nbsp;OR&nbsp;IMPLIED,&nbsp;INCLUDING<br />
&nbsp;&nbsp;&nbsp;BUT&nbsp;NOT&nbsp;LIMITED&nbsp;TO&nbsp;ANY&nbsp;WARRANTY&nbsp;THAT&nbsp;THE&nbsp;USE&nbsp;OF&nbsp;THE&nbsp;INFORMATION<br />
&nbsp;&nbsp;&nbsp;HEREIN&nbsp;WILL&nbsp;NOT&nbsp;INFRINGE&nbsp;ANY&nbsp;RIGHTS&nbsp;OR&nbsp;ANY&nbsp;IMPLIED&nbsp;WARRANTIES&nbsp;OF<br />
&nbsp;&nbsp;&nbsp;MERCHANTABILITY&nbsp;OR&nbsp;FITNESS&nbsp;FOR&nbsp;A&nbsp;PARTICULAR&nbsp;PURPOSE.<br />
致谢<br />
&nbsp;&nbsp;&nbsp;Funding&nbsp;for&nbsp;the&nbsp;RFC&nbsp;Editor&nbsp;function&nbsp;is&nbsp;currently&nbsp;provided&nbsp;by&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;Society.<br />
RRC3016&nbsp;&nbsp;RTP&nbsp;Payload&nbsp;Format&nbsp;for&nbsp;MPEG-4&nbsp;Audio/Visual&nbsp;Streams<br />
用于MPEG-4视听流的RTP负载格式<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />