rfc3016.txt

RFC规范的翻译稿

   注意：当一个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节)。