用于MPEG4视听流的RTP负载格式.docx
《用于MPEG4视听流的RTP负载格式.docx》由会员分享,可在线阅读,更多相关《用于MPEG4视听流的RTP负载格式.docx(15页珍藏版)》请在冰豆网上搜索。
用于MPEG4视听流的RTP负载格式
用于MPEG-4视听流的RTP负载格式(RFC3016)
组织:
中国互动出版网(http:
//www.china-
RFC文档中文翻译计划(http:
//www.china-
E-mail:
ouyang@china-
译者:
李超(licc_li,licc_li@)
译文发布时间:
2001-4-26
版权:
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载,但必须
保留本文档的翻译及版权信息。
NetworkWorkingGroupY.Kikuchi
RequestforComments:
3016Toshiba
Category:
StandardsTrackT.Nomura
NEC
S.Fukunaga
Oki
Y.Matsui
Matsushita
H.Kimata
NTT
November2000
用于MPEG-4视听流的RTP负载格式
(RRC3016RTPPayloadFormatforMPEG-4Audio/VisualStreams)
本备忘录的状态
本文档讲述了一种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