RRC3016 中文版.docx
《RRC3016 中文版.docx》由会员分享，可在线阅读，更多相关《RRC3016 中文版.docx（18页珍藏版）》请在冰豆网上搜索。
RRC3016中文版
RRC3016RTPPayloadFormatforMPEG-4Audio/VisualStreams
用于MPEG-4视听流的RTP负载格式
本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”（STD1）来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明
Copyright（C）TheInternetSociety（2000）.AllRightsReserved.
摘要
本文描述了在不使用MPEG-4系统的情况下携带MPEG-4音频和视觉码流的RTP负载格式。
为了能直接将MPEG-4音频/视觉码流映射到RTP包上，它提供了RTP包头字段的使用规范和分片规则。
同时文档中还规定了MIME类型注册和会话描述协议（SDP）的使用。
目录
本备忘录的状态1
版权声明1
摘要1
1.介绍2
1.1MPEG-4视觉RTP负载格式3
1.2MPEG-4音频RTP负载格式3
2.要求的术语4
3.MPEG-4视觉码流的RTP组包4
3.1MPEG-4视觉中RTP头字段的使用4
3.2MPEG-4视觉码流分片5
3.3MPEG-4视觉码流组包示例6
4.MPEG-4音频码流的RTP组包7
4.1RTP包格式7
4.2MPEG-4音频中RTP头字段的使用8
4.3MPEG-4音频码流分片9
5.MPEG-4视听流MIME类型注册9
5.1MPEG-4视觉MIME类型注册9
5.2MPEG-4视觉中SDP的用法10
5.3MPEG-4音频MIME类型登记11
5.4SDPusageofMPEG-4Audio12
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.1MPEG-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.2MPEG-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保护机制来提高错误恢复率，如通用前向纠错（RFC2733）和冗余音频数据（RFC2198）。
2.要求的术语
本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建议”，“或许”，“可选的”在RFC2119中解释。
3.MPEG-4视觉码流的RTP组包
本节规定了MPEG-4视觉内容的RTP组包规则。
一个MPEG-4视觉码流可直接映射到RTP包而不需要增加额外的头字段或者删除任何视觉语法元素。
为了将基本流的配置信息在相同的RTP端口上传送，必须使用合并配置/基本流模式。
（参见ISO/IEC14496-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格式以实现同旧系统的兼容性）。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|CC|M|PT|sequencenumber|RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|timestamp|Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|synchronizationsource（SSRC）identifier|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|contributingsource（CSRC）identifiers|
|....|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
||RTP
|MPEG-4Visualstream（bytealigned）|Pay-
||load
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|:
...OPTIONALRTPpadding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure1–一个MPEG-4视觉流的RTP包
3.1MPEG-4视觉中RTP头字段的使用
负载类型（PT）:
为新的包格式分配RTP负载类型超出了本文的范畴，不在此赘述。
特定类型应用程序的RTP框架应该负责负载类型的分配，如若不能则应该通过带外信令协议（如，
H.245,SIP等）在动态范围内选择一个负载类型。
扩展位（Extension-Xbit）:
由使用的RTP框架定义。
序列号（SequenceNumber）:
为了安全从一个随机初始化值开始，每发送一个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。
其它头字段的使用见RFC1889[8]。
3.2MPEG-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/IEC14496-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.3MPEG-4视觉码流组包示例
Figure2所示为按照3.2描述标准产生的RTP包的例子。
+------+------+------+------+
（a）|RTP|VS|VO|VOL|
|header|header|header|header|
+------+------+------+------+
（a）例表示包含了配置信息的MPEG-4视觉码流中第一个RTP包或随机访问点。
根据规则
（1），视觉对象序列头应位于RTP负载的开始处，视觉对象头和视频对象层头（VOheader,VOLheader）之前。
3.2中定义的分片规则保证了从visual_object_sequence_start_code开始的配置信息通常都位于RTP负载的开始位置，RTP接收端可通过检查RTP负载的头32位字段是否是visual_object_sequence_start_code来检测随机访问点。
+------+------+------+------+------------+
（b）|RTP|VS|VO|VOL|VideoPacket|
|header|header|header|header||
+------+------+------+------+------------+
（b）是另一个包含配置信息的RTP包例子。
它同
（1）的区别为该RTP包在VOP中的配置信息后还包含有视频包。
由于配置信息长度很短（一般为数十字节），一个RTP包如果仅含有配置信息会造成系统开销的上升，因此配置信息和其后的GOV和/或（部分）VOP可以打包到同一个RTP包中，如此例中所示。
+------+-----+------------------+
（c）|RTP|GOV|VideoObjectPlane|
|header|||
+------+-----+------------------+
（c）是RTP包中包含了Group_of_VideoObjectPlane（GOV）的例子。
根据规则
（1），GOV位于RTP负载的开始位置。
一个仅有GOV字段的RTP包大小只有7个字节，这是对RTP/IP头开销的极大浪费。
因此后续的VOP（或部分地）可以如本例所示打到同一个RTP包中。
+------+------+------------++------+------+------------+
（d）|RTP|VOP|VideoPacket||RTP|VP|VideoPacket|
|header|header|
（1）||header|header|
（2）|
+------+------+------------++------+------+------------+
（d）例中，一个视频包被打包到一个RTP包中。
当网络中包丢失率很高时推荐采用该方法。
甚至当包含有VOP头的RTP包被丢弃时其它RTP包还可通过使用视频包头中的HEC信息进行解码。
无需任何额外的RTP头字段。
+------+------+------------+------+------------+------+------------+
（e）|RTP|VP|VideoPacket|VP|VideoPacket|VP|VideoPacket|
|header|header|
（1）|header|
（2）|header|（3）|
+------+------+------------+------+------------+------+------------+
（e）例为多个视频包打在一个RTP包中的情况。
在底层网络速率很低时这种组包方式可高效地节约RTP/IP头开销。
不过，由于一个RTP包的丢失会导致将多个视频包同时丢失，这种方法会降低丢包恢复率。
一个RTP包中理想的视频包数目和RTP包长度可通过丢包率和底层网络传输的比特率来决定。
+------+------+------------++------+------------+
（f）|RTP|VOP|VOPfragment||RTP|VOPfragment|
|header|header|
（1）||header|
（2）|___
+------+------+------------++------+------------+
图2–RTP组包的MPEG-4视觉码流示例
+------+-------------++------+------------+------------+
（a）|RTP|Firsthalfof||RTP|Lasthalfof|VideoPacket|
|header|VPheader||header|VPheader||
+------+-------------++------+------------+------------+
+------+------+----------++------+---------+------+------------+
（b）|RTP|VOP|Firsthalf||RTP|Lasthalf|VP|VideoPacket|
|header|header|ofVP
（1）||header|ofVP
（1）|header|
（2）|
+------+------+----------++------+---------+------+------------+
图3–禁止RTP组包的MPEG-4视觉码流示例
（f）示例为在VOL头中将resync_marker_disable设置为1从而禁止使用视频包。
在此情况下，一个VOP可按照任意字节位置分为多个RTP包。
比如将一个VOP按照固定长度进行分片。
这种编码配置方法和RTP分片可应用于能提供极低错误率保证的网络。
另一方面，由于它的丢包恢复率很差，建议不要在error-prone环境中使用。
Figure3所示为按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.1RTP包格式
基于LATM的流由一个包含了一个或多个音频帧的audioMuxElements序列组成。
一个完整或部分完整的audioMuxElement可直接映射到一个RTP负载上，无需删除任何audioMuxElement语法元素（见图4）。
每个audioMuxElement的第一个字节应该位于RTP包第一个负载所在的位置。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|CC|M|PT|sequencenumber|RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|timestamp|Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|synchronizationsource（SSRC）identifier|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|contributingsource（CSRC）identifiers|
|....|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
||RTP
:
audioMuxElement（bytealigned）:
Payload
||
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|:
...OPTIONALRTPpadding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图4–一个MPEG-4音频RTP包
为了对audioMuxElement进行解码，必需得在其后通过带外方法指明muxConfigPresent。
当SDP用于此指示时，MIME参数"cpresent“就对应了mux
升级会员 