Network Working Group J. Ott
Request for Comments: 4629 Helsinki University of Technology
Obsoletes: 2429 C. Bormann
Updates: 3555 Universitaet Bremen TZI
Category: Standards Track G. Sullivan
Microsoft
S. Wenger
Nokia
R. Even, Ed.
Polycom
January 2007
Network Working Group J. Ott
Request for Comments: 4629 Helsinki University of Technology
Obsoletes: 2429 C. Bormann
Updates: 3555 Universitaet Bremen TZI
Category: Standards Track G. Sullivan
Microsoft
S. Wenger
Nokia
R. Even, Ed.
Polycom
January 2007
RTP Payload Format for ITU-T Rec. H.263 Video
ITU-T Rec.H.263视频的RTP有效负载格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
本文档描述了一种使用实时传输协议（RTP）将H.263视频流打包以进行传输的方案，该协议具有任何承载RTP的底层协议。
The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.
本文档还描述了支持H.263视频编解码器所需的会话描述协议（SDP）参数的语法和语义。
The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type in RFC 3555.
本文件淘汰了RFC 2429，并更新了RFC 3555中的H263-1998和H263-2000介质类型。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. New H.263 Features ..............................................3
3. Usage of RTP ....................................................4
3.1. RTP Header Usage ...........................................5
3.2. Video Packet Structure .....................................6
4. Design Considerations ...........................................7
5. H.263+ Payload Header ...........................................9
5.1. General H.263+ Payload Header ..............................9
5.2. Video Redundancy Coding Header Extension ..................10
6. Packetization Schemes ..........................................12
6.1. Picture Segment Packets and Sequence Ending
Packets (P=1) .............................................12
6.1.1. Packets that begin with a Picture Start Code .......12
6.1.2. Packets that begin with GBSC or SSC ................13
6.1.3. Packets that begin with an EOS or EOSBS Code .......14
6.2. Encapsulating Follow-on Packet (P=0) ......................15
7. Use of this Payload Specification ..............................15
8. Media Type Definition ..........................................17
8.1. Media Type Registrations ..................................17
8.1.1. Registration of Media Type video/H263-1998 .........17
8.1.2. Registration of Media Type video/H263-2000 .........21
8.2. SDP Usage .................................................22
8.2.1. Usage with the SDP Offer Answer Model ..............23
9. Backward Compatibility to RFC 2429 .............................25
9.1. New Optional Parameters for SDP ...........................25
10. IANA Considerations ...........................................25
11. Security Considerations .......................................25
12. Acknowledgments ...............................................26
13. Changes from Previous Versions of the Documents ...............26
13.1. Changes from RFC 2429 ....................................26
13.2. Changes from RFC 3555 ....................................26
14. References ....................................................26
14.1. Normative References .....................................26
14.2. Informative References ...................................27
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. New H.263 Features ..............................................3
3. Usage of RTP ....................................................4
3.1. RTP Header Usage ...........................................5
3.2. Video Packet Structure .....................................6
4. Design Considerations ...........................................7
5. H.263+ Payload Header ...........................................9
5.1. General H.263+ Payload Header ..............................9
5.2. Video Redundancy Coding Header Extension ..................10
6. Packetization Schemes ..........................................12
6.1. Picture Segment Packets and Sequence Ending
Packets (P=1) .............................................12
6.1.1. Packets that begin with a Picture Start Code .......12
6.1.2. Packets that begin with GBSC or SSC ................13
6.1.3. Packets that begin with an EOS or EOSBS Code .......14
6.2. Encapsulating Follow-on Packet (P=0) ......................15
7. Use of this Payload Specification ..............................15
8. Media Type Definition ..........................................17
8.1. Media Type Registrations ..................................17
8.1.1. Registration of Media Type video/H263-1998 .........17
8.1.2. Registration of Media Type video/H263-2000 .........21
8.2. SDP Usage .................................................22
8.2.1. Usage with the SDP Offer Answer Model ..............23
9. Backward Compatibility to RFC 2429 .............................25
9.1. New Optional Parameters for SDP ...........................25
10. IANA Considerations ...........................................25
11. Security Considerations .......................................25
12. Acknowledgments ...............................................26
13. Changes from Previous Versions of the Documents ...............26
13.1. Changes from RFC 2429 ....................................26
13.2. Changes from RFC 3555 ....................................26
14. References ....................................................26
14.1. Normative References .....................................26
14.2. Informative References ...................................27
This document specifies an RTP payload header format applicable to the transmission of video streams based on the 1998 and 2000 versions of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.263 [H263]. Because the 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 and is recommended for this use by new implementations. This format replaces the payload format in RFC 2190 [RFC2190], which continues to be used by some existing implementations, and can be useful for backward compatibility. New implementations supporting H.263 SHALL use the payload format described in this document. RFC 2190 is moved to historic status [RFC4628].
本文件根据1998年和2000年版本的国际电信联盟电信标准化部门（ITU-T）建议H.263[H263]规定了适用于视频流传输的RTP有效载荷报头格式。由于H.263的1998和2000版本是1996年语法的超集，因此此格式也可与1996年版本的H.263一起使用，并建议新的实现使用此格式。此格式取代RFC 2190[RFC2190]中的有效负载格式，某些现有实现仍在使用该格式，并可用于向后兼容性。支持H.263的新实现应使用本文件中描述的有效载荷格式。RFC 2190移动到历史状态[RFC4628]。
The document updates the media type registration that was previously in RFC 3555 [RFC3555].
该文档更新了先前在RFC 3555[RFC3555]中的介质类型注册。
This document obsoletes RFC 2429 [RFC2429].
本文件淘汰了RFC 2429[RFC2429]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合RTP实施的要求级别。
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. In this document, the 1998 version is referred to as H.263+ and the 2000 version as H.263++.
1998年版本的ITU-T建议H.263增加了许多编码选项，以改善1996年版本的编解码器性能。在本文件中，1998年版本称为H.263+，2000年版本称为H.263++。
Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [H263] for more information on coding options.
在这些新选项中，对RTP有效负载规范和视频内容的错误恢复能力影响最大的是切片结构模式、独立段解码模式、参考图片选择模式和可伸缩性模式。本节总结了这些新编码选项对打包的影响。有关编码选项的更多信息，请参阅[H263]。
The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable for use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries.
切片结构模式被添加到H.263+中有三个目的：提供增强的错误恢复能力，使比特流更适合用于底层数据包传输（如RTP），以及最小化视频延迟。切片结构化模式支持宏块边界处的分段。
With the independent segment decoding (ISD) option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others.
使用独立段解码（ISD）选项，视频图片帧被分成段，并以每个段都可独立解码的方式进行编码。在有损网络环境中使用ISD有助于防止错误从图片的一段传播到另一段。
The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode may be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information. The Extended RTP Profile for RTP Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a back channel mechanism.
参考图片选择模式允许使用较旧的参考图片，而不是当前图片前面的参考图片。通常，最后发送的帧隐式地用作帧间预测的参考图片。如果使用参考图片选择模式，则数据流携带关于应该使用哪个参考帧的信息，该信息由时间参考指示为该参考帧的ID。参考图片选择模式可与或不与反向信道一起使用，其向编码器提供关于解码器的内部状态的信息。然而，本文没有针对回传信道信息作出特殊规定。基于RTP控制协议（RTCP）的反馈[RFC4585]的扩展RTP配置文件可用作后通道机制。
H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to-noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode, described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except that the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both.
H.263+还包括作为可选编码模式的比特流可伸缩性。定义了三种可伸缩性：时间、信噪比（SNR）和空间可伸缩性。时间可伸缩性是通过双向预测帧或B帧的一次性性质实现的。（称为P-图片时间可伸缩性的低延迟形式的时间可伸缩性也可以通过使用参考图片选择模式来实现，如前一段所述。）SNR可伸缩性允许对编码视频帧进行细化，从而提高质量（或SNR）。空间可伸缩性与SNR可伸缩性相似，不同之处在于细化层在水平维度、垂直维度或两者中的大小是基础层的两倍。
H.263++ added some new functionalities. Among the new functionalities are support for interlace mode, specified in H.263, annex W.6.3.11, and the definition of profiles and levels in H.263 annex X.
H.263++增加了一些新功能。新功能包括支持H.263附录W.6.3.11中规定的隔行模式，以及H.263附录X中的轮廓和级别定义。
When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream (including the fixed length codes and variable length codes) will be included in the packet, the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start code, the first 2 (all-zero) bytes of the start code shall be removed and replaced by setting an indicator bit in the payload header.
当通过互联网传输H.263+视频流时，编码器的输出可以直接打包。由比特流产生的所有比特（包括固定长度代码和可变长度代码）将包括在分组中，唯一的例外是当分组的有效载荷以图片、GOB、切片、序列结束（EOS）或子比特流结束（EOSB）开始代码开始时，前2个（全部为零）应通过在有效载荷标题中设置指示器位来删除和替换启动代码字节。
For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications.
对于以时间、空间或SNR可伸缩性编码的H.263+比特流，每一层可被传输到不同的网络地址。更具体地说，每一层可以使用唯一的IP地址和端口号组合。层之间的时间关系应使用RTP时间戳表示，以便在多播或单播应用中，它们可以在接收端同步。
The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in Section 5; it updates the one specified in RFC 2190. This section defines the usage of the RTP fixed header and H.263+ video packet structure.
H.263+视频流将作为RTP数据包中的有效负载数据携带。第5节定义了一个新的H.263+有效载荷头；它更新了RFC 2190中指定的。本节定义RTP固定报头和H.263+视频数据包结构的用法。
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header used for H.263+ video streams are further emphasized here.
每个RTP数据包都以一个固定的RTP报头开始。这里进一步强调用于H.263+视频流的RTP固定报头的以下字段。
Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame and is 0 otherwise.
标记位（M位）：当当前数据包携带当前帧的结尾时，RTP报头的标记位设置为1，否则为0。
Payload Type (PT): The RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, a payload type in the dynamic range shall be chosen by the sender.
有效负载类型（PT）：特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者，如果未分配有效负载类型，则发送方应选择动态范围内的有效负载类型。
Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to ITU-T Recommendation H.263 [H263] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of the RTP payload for H.261 stream [RFC2032]. Since both the H.263+ data and the RTP header contain time information, that timing information must run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. Any H.263+ picture clock frequency can be expressed as 1800000/(cd*cf) source pictures per second, in which cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock of the RTP timestamp, the time
时间戳：RTP时间戳对RTP数据包中包含的第一个视频帧数据的采样实例进行编码。如果视频帧占用多个数据包，则连续数据包上的RTP时间戳应相同。在多层场景中，对应于相同时间参考的所有图片应使用相同的时间戳。如果使用时间可伸缩性（如果存在B帧），则时间戳在RTP流中可能不会单调增加。如果它们与参考帧在单独的地址层上正确地同步，那么它们必须与参考帧在单独的地址层上同步。参考ITU-T建议H.263[H263]了解解码器所需传输顺序的信息。对于H.263+视频流，RTP时间戳基于90 kHz时钟，与H.261流的RTP有效载荷相同[RFC2032]。由于H.263+数据和RTP报头都包含时间信息，因此该时间信息必须同步运行。也就是说，RTP时间戳和时间参考（H.263的图片头部中的TR）都应该携带相同的相对定时信息。任何H.263+图片时钟频率都可以表示为每秒1800000/（cd*cf）源图片，其中cd是1到127之间的整数，cf是1000或1001。使用RTP时间戳的90 kHz时钟
increment between each coded H.263+ picture should therefore be an integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 30/1.001 Hz NTSC; 3600 for 25 Hz PAL; 3750 for 24 Hz film; and 1500, 1250, or 1200 for the computer display update rates of 60, 72, or 75 Hz, respectively). For RTP packetization of hypothetical H.263+ bitstreams using "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary for generating the RTP timestamps.
因此，每个编码的H.263+图片之间的增量应为（cd*cf）/20的整数倍。对于任何“合理”的图片时钟频率，这始终是一个整数（例如，对于30/1.001 Hz NTSC，它是3003；对于25 Hz PAL，它是3600；对于24 Hz胶片，它是3750；对于60、72或75 Hz的计算机显示更新率，它分别是1500、1250或1200）。对于使用“不合理”自定义图片时钟频率对假设的H.263+比特流进行RTP打包，可能需要数学舍入来生成RTP时间戳。
A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable, depending on the payload involved, as detailed in the Section 4. The layout of the RTP H.263+ video packet is shown as
H.263+压缩比特流的一部分作为有效载荷在每个RTP分组中携带。对于每个RTP分组，RTP报头后面紧跟着一个H.263+有效负载报头，该报头后面紧跟着一个标准H.263+压缩比特流的若干字节。H.263+有效载荷头的大小是可变的，这取决于所涉及的有效载荷，详见第4节。RTP H.263+视频分组的布局如图所示
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RTP Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Payload Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Compressed Data Stream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RTP Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Payload Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Compressed Data Stream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS starts codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned; however, since this is not required in H.263+, there may be some cases where GOB start codes are not aligned, such as when transmitting existing content, or when using H.263 encoders that do not support GOB start code alignment. In this case, Follow-on Packets (see Section 5.2) should be used for packetization.
通过使用H.263+的填充机制，编码器可以对任何H.263+起始代码进行字节对齐。按照H.263+中的规定，图片、切片和EOSB开始代码应始终为字节对齐，GOB和EOS开始代码可为字节对齐。出于打包目的，GOB起始代码应该是字节对齐的；然而，由于H.263+中不需要这样做，因此可能存在一些GOB开始代码未对齐的情况，例如在传输现有内容时，或者在使用不支持GOB开始代码对齐的H.263编码器时。在这种情况下，应使用后续数据包（见第5.2节）进行打包。
All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header.
所有H.263+开始代码（图片、GOB、切片、EOS和EOSB）都以16个零值位开始。如果起始代码是字节对齐的，并且发生在数据包的开头，则应在数据包化过程中从H.263+压缩数据流中删除这两个字节，并通过在有效负载报头中设置位（P位）来表示。
The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in cases when another packet containing the original picture header becomes lost.
此有效负载格式的目标是指定一种封装符合H.263+标准的比特流的有效方法，并增强对数据包丢失的恢复能力。由于H.263+中存在大量不同的可能编码方案，因此在适当的情况下，将带有配置信息的图片报头的副本插入到有效负载报头中。即使在包含原始图片报头的另一个分组丢失的情况下，使用图片报头的该副本以及有效载荷数据也可以允许对接收到的分组进行解码。
There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video.
与此H.263+有效负载标头设计相关的一些假设和约束条件。本节的目的是指出各种设计问题，并讨论H.263+提供的可能影响基于网络的H.263+视频性能的几种编码选项。
o The optional slice structured mode described in Annex K of [H263] enables more flexibility for packetization. Similar to a picture segment that begins with a GOB header, the motion vector predictors in a slice are restricted to reside within its boundaries. However, slices provide much greater freedom in the selection of the size and shape of the area that is represented as a distinct decodable region. In particular, slices can have a size that is dynamically selected to allow the data for each slice to fit into a chosen packet size. Slices can also be chosen to have a rectangular shape, which is conducive for minimizing the impact of errors and packet losses on motion-compensated prediction. For these reasons, the use of the slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs.
o [H263]附录K中描述的可选切片结构模式使打包更加灵活。与以GOB头开始的图片片段类似，切片中的运动矢量预测器被限制在其边界内。然而，切片在选择表示为不同可解码区域的区域的大小和形状方面提供了更大的自由度。特别地，片可以具有动态选择的大小，以允许每个片的数据适合所选择的分组大小。切片也可以选择为矩形，这有助于最小化错误和数据包丢失对运动补偿预测的影响。由于这些原因，强烈建议在发生重大数据包丢失的环境中使用切片结构化模式。
o In non-rectangular slice structured mode, only complete slices SHOULD be included in a packet. In other words, slices should not be fragmented across packet boundaries. The only reasonable need for a slice to be fragmented across packet boundaries is when the encoder that generated the H.263+ data stream could not be influenced by an awareness of the packetization process (such as when sending H.263+ data through a network other than the one to which the encoder is attached, as in network gateway implementations). Optimally, each packet will contain only one slice.
o 在非矩形切片结构模式下，数据包中只应包含完整的切片。换句话说，切片不应该跨包边界分割。在生成H.263+数据流的编码器不受对分组化过程的感知的影响时（例如，在网络网关实现中，通过编码器所连接的网络以外的网络发送H.263+数据时），才合理地需要跨分组边界分割切片. 最佳情况下，每个数据包将只包含一个切片。
o The independent segment decoding (ISD) described in Annex R of [H263] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to improve resiliency further in high loss conditions.
o [H263]附录R中描述的独立段解码（ISD）可防止参考图片中跨片或GOB边界的任何数据依赖性。它可用于在高损耗条件下进一步提高弹性。
o If ISD is used in conjunction with the slice structure, the rectangular slice submode shall be enabled, and the dimensions and quantity of the slices present in a frame shall remain the same between each two intra-coded frames (I-frames), as required in H.263+. The individual ISD segments may also be entirely intra coded from time to time to realize quick error recovery without adding the latency time associated with sending complete INTRA-pictures.
o 如果ISD与切片结构一起使用，则应启用矩形切片子模式，并且帧中存在的切片的尺寸和数量应在每两个帧内编码帧（I帧）之间保持相同，如H.263+所要求。各个ISD段还可以不时地完全进行帧内编码，以实现快速错误恢复，而不增加与发送完整帧内图片相关联的延迟时间。
o When the slice structure is not applied, the insertion of a (preferably byte-aligned) GOB header can be used to provide resync boundaries in the bitstream, as the presence of a GOB header eliminates the dependency of motion vector prediction across GOB boundaries. These resync boundaries provide natural locations for packet payload boundaries.
o 当不应用切片结构时，插入（优选字节对齐的）GOB报头可用于在比特流中提供重新同步边界，因为GOB报头的存在消除了跨GOB边界的运动矢量预测的依赖性。这些重新同步边界为数据包有效负载边界提供了自然位置。
o H.263+ allows picture headers to be sent in an abbreviated form in order to prevent repetition of overhead information that does not change from picture to picture. For resiliency, sending a complete picture header for every frame is often advisable. This means (especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable) that the sender may find it advisable always to set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263] for the definition of the UFEP and PLUSPTYPE fields).
o H.263+允许以缩写形式发送图片标题，以防止重复开销信息，而这些信息不会在图片之间改变。为了提高弹性，通常建议为每一帧发送一个完整的图片标题。这意味着（特别是在具有高分组丢失概率的情况下，其中图片报头内容不期望是高度可预测的）发送方可能发现建议始终将H.263+视频比特流中的PLUSPTYPE中的子字段UFEP设置为“001”。（有关UFEP和PLUSPTYPE字段的定义，请参见[H263]）。
o In a multi-layer scenario, each layer may be transmitted to a different network address. The configuration of each layer, such as the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type should be determined at the start of the session and should not change during the course of the session.
o 在多层方案中，每一层可以被传输到不同的网络地址。每个层的配置，如增强层编号（ELNUM）、参考层编号（RLNUM）和可伸缩性类型，应在会话开始时确定，并且在会话过程中不应更改。
o All start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned. The boundaries of these syntactical elements provide ideal locations for placing packet boundaries.
o 所有开始代码都可以是字节对齐的，图片、切片和EOSB开始代码始终是字节对齐的。这些语法元素的边界为放置数据包边界提供了理想的位置。
o We assume that a maximum Picture Header size of 504 bits is sufficient. The syntax of H.263+ does not explicitly prohibit larger picture header sizes, but the use of such extremely large picture headers is not expected.
o 我们假设504位的最大图片头大小就足够了。H.263+的语法没有明确禁止较大的图片标题大小，但不希望使用如此大的图片标题。
For H.263+ video streams, each RTP packet shall carry only one H.263+ video packet. The H.263+ payload header shall always be present for each H.263+ video packet. The payload header is of variable length. A 16-bit field of the general payload header, defined in 5.1, may be followed by an 8 bit field for Video Redundancy Coding (VRC) information, and/or by a variable-length extra picture header as indicated by PLEN. These optional fields appear in the order given above, when present.
对于H.263+视频流，每个RTP数据包只能携带一个H.263+视频数据包。对于每个H.263+视频包，H.263+有效负载报头应始终存在。有效负载收割台长度可变。5.1中定义的一般有效载荷报头的16位字段后面可以是用于视频冗余编码（VRC）信息的8位字段，和/或如PLEN所示的可变长度额外图片报头。这些可选字段在出现时按上述顺序显示。
If an extra picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, PLEN equal to 0 and no VRC information being present.
如果有效负载标头中包含额外图片标头，则以字节为单位的图片标头长度由PLEN指定。有效负载标头的最小长度为16位，PLEN等于0且不存在VRC信息。
The remainder of this section defines the various components of the RTP payload header. Section 6 defines the various packet types that are used to carry different types of H.263+ coded data, and Section 7 summarizes how to distinguish between the various packet types.
本节的其余部分定义了RTP有效负载标头的各个组件。第6节定义了用于承载不同类型的H.263+编码数据的各种数据包类型，第7节总结了如何区分各种数据包类型。
The H.263+ payload header is structured as follows:
H.263+有效负载标头的结构如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |P|V| PLEN |PEBIT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |P|V| PLEN |PEBIT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR: 5 bits
RR:5位
Reserved bits. It SHALL be zero and MUST be ignored by receivers.
保留位。它应为零，且必须被接收器忽略。
P: 1 bit
P:1位
Indicates the picture start or a picture segment (GOB/Slice) start or a video sequence end (EOS or EOSBS). Two bytes of zero bits then have to be prefixed to the payload of such a packet to compose a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the omission of the two first bytes of the start codes, thus improving the compression ratio.
指示图片开始或图片段（GOB/切片）开始或视频序列结束（EOS或EOSB）。然后，必须在这样一个数据包的有效负载前加上两个字节的零位前缀，以组成完整的picture/GOB/slice/EOS/EOSBS开始代码。该位允许省略起始码的前两个字节，从而提高压缩比。
V: 1 bit
V:1位
Indicates the presence of an 8-bit field containing information for Video Redundancy Coding (VRC), which follows immediately after the initial 16 bits of the payload header, if present. For syntax and semantics of that 8-bit VRC field, see Section 5.2.
表示存在包含视频冗余编码（VRC）信息的8位字段，该字段紧跟在有效负载头的初始16位之后（如果存在）。有关该8位VRC字段的语法和语义，请参见第5.2节。
PLEN: 6 bits
PLEN:6位
Length, in bytes, of the extra picture header. If no extra picture header is attached, PLEN is 0. If PLEN>0, the extra picture header is attached immediately following the rest of the payload header. Note that the length reflects the omission of the first two bytes of the picture start code (PSC). See Section 6.1.
额外图片标题的长度（字节）。如果未附加额外图片标题，则PLEN为0。如果PLEN>0，额外图片标头将紧跟在有效负载标头的其余部分之后。注意，长度反映了图片开始代码（PSC）前两个字节的省略。见第6.1节。
PEBIT: 3 bits
PEBIT:3位
Indicates the number of bits that shall be ignored in the last byte of the picture header. If PLEN is not zero, the ignored bits shall be the least significant bits of the byte. If PLEN is zero, then PEBIT shall also be zero.
指示图片标题最后一个字节中应忽略的位数。如果PLEN不为零，则忽略的位应为字节的最低有效位。如果PLEN为零，则PEBIT也应为零。
Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N of [H263]. By having multiple "threads" of independently inter-frame predicted pictures, damage to an individual frame will cause distortions only within its own thread, leaving the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture that is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For more information on codec support for VRC, see [Vredun].
视频冗余编码（VRC）是一种可选机制，旨在提高分组网络的容错能力。在H.263+中实现VRC需要[H263]附录N中所述的参考图片选择选项。通过拥有独立帧间预测图片的多个“线程”，对单个帧的损坏将只在其自身线程内引起失真，而其他线程不受影响。有时，所有线程聚合到所谓的同步帧（在多个线程中冗余表示的帧内图片或非帧内图片）；在此同步帧中，独立线程将再次启动。有关VRC编解码器支持的更多信息，请参阅[Vredun]。
P-picture temporal scalability is another use of the reference picture selection mode and can be considered a special case of VRC in which only one copy of each sync frame may be sent. It offers a thread-based method of temporal scalability without the increased delay caused by the use of B pictures. In this use, sync frames sent in the first thread of pictures are also used for the prediction of a second thread of pictures that fall temporally between the sync frames to increase the resulting frame rate. In this use, the pictures in the second thread can be discarded in order to obtain a reduction of bit rate or decoding complexity without harming the ability to decode later pictures. A third or more threads, can also be added, but each thread is predicted only from the sync frames
P-图片时间可伸缩性是参考图片选择模式的另一个用途，并且可以被视为VRC的特殊情况，其中每个同步帧的一个副本可以被发送。它提供了一种基于线程的时间可伸缩性方法，而不会因使用B图片而增加延迟。在该使用中，在第一图片线程中发送的同步帧还用于预测在同步帧之间暂时落下的第二图片线程，以增加结果帧速率。在这种使用中，可以丢弃第二线程中的图片，以便在不损害解码后续图片的能力的情况下获得比特率或解码复杂度的降低。还可以添加第三个或更多线程，但每个线程仅从同步帧预测
(which are sent at least in thread 0) or from frames within the same thread.
（至少在线程0中发送）或来自同一线程中的帧。
While a VRC data stream is (like all H.263+ data) totally self-contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, the thread-id, and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension.
虽然VRC数据流（与所有H.263+数据一样）是完全自包含的，但对于传输层次结构实现来说，了解每个线程的当前损坏状态可能是有用的。在Internet上，通过观察标记位、RTP头的序列号、线程id和循环的“每个线程的数据包”号，可以很容易地确定这种状态。后两个数字在VRC标题扩展中编码。
The format of the VRC header extension is as follows:
VRC标头扩展的格式如下所示：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S|
+-+-+-+-+-+-+-+-+
TID: 3 bits
TID:3位
Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC data will use as reference information only sync frames or frames within the same thread. By convention, thread 0 is expected to be the "canonical" thread, which is the thread from which the sync frame should ideally be used. In the case of corruption or loss of the thread 0 representation, a representation of the sync frame with a higher thread number can be used by the decoder. Lower thread numbers are expected to contain representations of the sync frames equal to or better than higher thread numbers in the absence of data corruption or loss. See [Vredun] for a detailed discussion of VRC.
线程ID。最多允许7个线程。H.263+VRC数据的每个帧将仅使用同步帧或同一线程内的帧作为参考信息。按照约定，线程0应该是“规范”线程，这是理想情况下使用同步帧的线程。在线程0表示损坏或丢失的情况下，解码器可以使用具有更高线程号的同步帧表示。在没有数据损坏或丢失的情况下，较低的线程号所包含的同步帧表示形式应等于或优于较高的线程号。有关VRC的详细讨论，请参见[Vredun]。
Trun: 4 bits
Trun:4位
Monotonically increasing (modulo 16) 4-bit number counting the packet number within each thread.
单调递增（模16）4位数，计算每个线程内的数据包数。
S: 1 bit
S:1位
A bit that indicates that the packet content is for a sync frame. An encoder using VRC may send several representations of the same "sync" picture, in order to ensure that, regardless of which thread of pictures is corrupted by errors or packet losses, the reception of at least one representation of a particular picture is ensured (within at least one thread). The sync picture can then be used for the prediction of any thread. If packet losses have not occurred, then the sync frame contents of thread 0 can be used, and those of other threads can be discarded (and similarly for other threads). Thread 0 is considered the "canonical" thread, the use of which is preferable
指示数据包内容用于同步帧的位。使用VRC的编码器可以发送同一“同步”图片的多个表示，以确保无论哪个图片线程被错误或数据包丢失损坏，都能够确保（在至少一个线程内）接收特定图片的至少一个表示。然后，同步图片可用于预测任何线程。如果没有发生数据包丢失，则可以使用线程0的同步帧内容，并丢弃其他线程的同步帧内容（对于其他线程也是如此）。线程0被认为是“规范”线程，最好使用它
to all others. The contents of packets having lower thread numbers shall be considered as having a higher processing and delivery priority than those with higher thread numbers. Thus, packets having lower thread numbers for a given sync frame shall be delivered first to the decoder under loss-free and low-time-jitter conditions, which will result in the discarding of the sync contents of the higher-numbered threads as specified in Annex N of [H263].
对所有其他人。具有较低线程编号的数据包的内容应被视为具有比具有较高线程编号的数据包更高的处理和交付优先级。因此，对于给定同步帧，具有较低线程编号的数据包应首先在无丢失和低时间抖动条件下交付给解码器，这将导致丢弃[H263]附录N中规定的较高编号线程的同步内容。
A picture segment packet is defined as a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This corresponds to the definition of the start of a video picture segment as defined in H.263+. For such packets, P=1 always.
图片段分组被定义为在H.263+数据流中的图片、GOB或片段开始代码的位置开始的分组。这对应于H.263+中定义的视频图片段开始的定义。对于此类数据包，P始终为1。
An extra picture header can sometimes be attached in the payload header of such packets. Whenever an extra picture header is attached as signified by PLEN>0, only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte-aligned picture start code can be conveniently assembled on the receiving end by prepending the sixteen leading '0' bits.
有时可以在此类分组的有效负载报头中附加额外图片报头。每当附加一个额外的图片头时，如PLEN>0所示，有效负载头中只包括其图片开始代码“100000”的最后六位。一个完整的H.263+图片头，带有字节对齐的图片开始代码，可以通过在16个前导“0”位前加前缀方便地在接收端组装。
When PLEN>0, the end bit position corresponding to the last byte of the picture header data is indicated by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header.
当PLEN>0时，与图片标题数据的最后一个字节相对应的结束位位置由PEBIT指示。实际比特流数据应在有效负载报头之后的8位字节边界上开始。
A sequence ending packet is defined as a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. This delineates the end of a sequence of H.263+ video data (more H.263+ video data may still follow later, however, as specified in ITU-T Recommendation H.263). For such packets, P=1 and PLEN=0 always.
序列结束分组被定义为在H.263+数据流中的EOS或EOSBS代码的位置开始的分组。这描绘了H.263+视频数据序列的结束（然而，如ITU-T建议H.263中所规定的，更多H.263+视频数据稍后仍可能跟随）。对于这样的数据包，P=1和PLEN=0总是存在的。
The optional header extension for VRC may or may not be present as indicated by the V bit flag.
如V位标志所示，VRC的可选标头扩展可能存在，也可能不存在。
Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC) and should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in such a case. However, if the coded picture contains an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization in order to provide
包含编码图片的全部或开头的任何数据包应从图片开始代码（PSC）的位置开始，并且通常应在没有额外图片标题副本的情况下进行封装。换言之，在这种情况下，通常PLEN=0。然而，如果编码图片包含不完整的图片标题（UFEP=“000”），则在打包期间可以附加完整（UFEP=“001”）图片标题的表示，以便提供
greater error resilience. Thus, for packets that start at the location of a picture start code, PLEN shall be zero unless both of the following conditions apply:
更大的错误恢复能力。因此，对于在图片开始代码位置开始的数据包，除非以下两个条件都适用，否则PLEN应为零：
1) The picture header in the H.263+ bitstream payload is incomplete (PLUSPTYPE present and UFEP="000").
1) H.263+比特流有效负载中的图片标头不完整（PLUSPTYPE present和UFEP=“000”）。
2) The additional picture header that is attached is not incomplete (UFEP="001").
2) 附加的附加图片标题不完整（UFEP=“001”）。
A packet that begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream and signify their presence by setting P=1 in the payload header.
从图片、GOB、切片、EOS或EOSBS开始代码位置开始的数据包应省略H.263+比特流中的前两个（全部为零）字节，并通过在有效负载报头中设置P=1表示其存在。
Here is an example of encapsulating the first packet in a frame (without an attached redundant complete picture header):
这里是将第一分组封装在帧中（没有附加的冗余完整图片报头）的示例：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: first two 0 bytes of the PSC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: first two 0 bytes of the PSC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a packet that begins at the location of a GOB or slice start code (GBSC), PLEN may be zero or nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when picture header contents are very seldom likely to change (except as can be detected from the GOB Frame ID (GFID) syntax of H.263+), a redundant copy of the picture header is not required. However, in less ideal circumstances a redundant picture header should be attached for enhanced error resilience, and its presence is indicated by PLEN>0.
对于在GOB或切片开始代码（GBSC）位置开始的分组，PLEN可以是零或非零，这取决于是否将冗余图片报头附加到分组。在数据包丢失率非常低的环境中，或者当图片标题内容很少可能发生变化时（除非可以从H.263+的GOB帧ID（GFID）语法中检测到），不需要图片标题的冗余副本。但是，在不太理想的情况下，应附加冗余图片标题以增强错误恢复能力，其存在由PLEN>0表示。
Assuming a PLEN of 9 and P=1, below is an example of a packet that begins with a byte-aligned GBSC or a Slice Start Code (SSC):
假设PLEN为9且P=1，下面是以字节对齐的GBSC或片起始码（SSC）开头的数据包示例：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: starting with TR, PTYPE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | bitstream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: data starting with GBSC/SSC without its first two 0 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: starting with TR, PTYPE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | bitstream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: data starting with GBSC/SSC without its first two 0 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled, if needed, on the receiving end by prepending the sixteen leading '0' bits.
请注意，只有图片开始代码的最后六位“100000”包含在有效负载标头中。如果需要，可以在接收端通过预加16个前导“0”位，方便地组装带有字节对齐图片开始代码的完整H.263+图片报头。
For a packet that begins with an EOS or EOSBS code, PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet. As with other packets beginning with start codes, the two all-zero bytes that begin the EOS or EOSBS code at the beginning of the packet shall be omitted, and their presence shall be indicated by setting the P bit to 1 in the payload header.
对于以EOS或EOSBS代码开头的数据包，PLEN应为零，且同一数据包中不得包含图片、GOB或切片开始代码。与以开始代码开始的其他数据包一样，应省略在数据包开始处开始EOS或EOSBS代码的两个全零字节，并且应通过在有效负载报头中将P位设置为1来指示其存在。
System designers should be aware that some decoders may interpret the loss of a packet containing only EOS or EOSBS information as the loss of essential video data and may thus respond by not displaying some subsequent video information. Since EOS and EOSBS codes do not actually affect the decoding of video pictures, they are somewhat unnecessary to send at all. Because of the danger of misinterpretation of the loss of such a packet (which can be detected by the sequence number), encoders are generally to be discouraged from sending EOS and EOSBS.
系统设计者应当意识到，一些解码器可能将仅包含EOS或EOSB信息的分组的丢失解释为基本视频数据的丢失，并且因此可能通过不显示一些后续视频信息来响应。由于EOS和EOSBS代码实际上并不影响视频图片的解码，因此根本不需要发送它们。由于这种分组的丢失（可通过序列号检测到）有被误解的危险，通常不鼓励编码器发送EOS和EOSB。
Below is an example of a packet containing an EOS code:
下面是包含EOS代码的数据包示例：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Follow-on Packet contains a number of bytes of coded H.263+ data that do not start at a synchronization point. That is, a Follow-on Packet does not start with a Picture, GOB, Slice, EOS, or EOSBS header, and it may or may not start at a macroblock boundary. Since Follow-on Packets do not start at synchronization points, the data at the beginning of a Follow-on Packet is not independently decodable. For such packets, P=0 always. If the preceding packet of a Follow-on Packet got lost, the receiver may discard that Follow-on Packet, as well as all other following Follow-on Packets. Better behavior, of course, would be for the receiver to scan the interior of the packet payload content to determine whether any start codes are found in the interior of the packet that can be used as resync points. The use of an attached copy of a picture header for a Follow-on Packet is useful only if the interior of the packet or some subsequent Follow-on Packet contains a resync code, such as a GOB or slice start code. PLEN>0 is allowed, since it may allow resync in the interior of the packet. The decoder may also be resynchronized at the next segment or picture packet.
后续数据包包含许多字节的编码H.263+数据，这些数据不从同步点开始。也就是说，后续分组不以图片、GOB、切片、EOS或EOSBS报头开始，并且它可以也可以不以宏块边界开始。由于后续数据包不在同步点开始，因此后续数据包开始处的数据不可独立解码。对于此类数据包，P始终为0。如果后续分组的前一分组丢失，则接收机可以丢弃该后续分组以及所有其他后续分组。当然，更好的行为是，接收器扫描数据包有效载荷内容的内部，以确定是否在数据包内部找到任何可以用作重新同步点的开始代码。仅当后续数据包或某个后续数据包的内部包含重新同步代码（例如GOB或slice开始代码）时，将图片报头的附加副本用于后续数据包才有用。允许PLEN>0，因为它可能允许在数据包内部重新同步。解码器还可以在下一段或图片分组处重新同步。
Here is an example of a Follow-on Packet (with PLEN=0):
以下是后续数据包的示例（PLEN=0）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
There is no syntactical difference between a picture segment packet and a Follow-on Packet, other than the indication P=1 for picture segment or sequence ending packets and P=0 for Follow-on Packets. See the following for a summary of the entire packet types and ways to distinguish between them.
图片段分组和后续分组之间没有语法上的差异，除了图片段或序列结束分组的指示P＝1和后续分组的指示P＝0之外。有关整个数据包类型的摘要以及区分它们的方法，请参见以下内容。
It is possible to distinguish between the different packet types by checking the P bit and the first 6 bits of the payload along with the header information. The following table shows the packet type for permutations of this information (see also the picture/GOB/Slice header descriptions in H.263+ for details):
通过检查有效载荷的P位和前6位以及报头信息，可以区分不同的分组类型。下表显示了该信息排列的数据包类型（详见H.263+中的picture/GOB/Slice头描述）：
-------------+--------------+----------------------+----------------
First 6 bits | P-Bit | PLEN | Packet | Remarks
of Payload |(payload hdr.)| |
-------------+--------------+----------------------+----------------
100000 | 1 | 0 | Picture | Typical Picture
100000 | 1 | > 0 | Picture | Note UFEP
1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs
1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs
Xxxxxx | 0 | 0 | Follow-on |
Xxxxxx | 0 | > 0 | Follow-on | Interior Resync
-------------+--------------+----------------------+----------------
-------------+--------------+----------------------+----------------
First 6 bits | P-Bit | PLEN | Packet | Remarks
of Payload |(payload hdr.)| |
-------------+--------------+----------------------+----------------
100000 | 1 | 0 | Picture | Typical Picture
100000 | 1 | > 0 | Picture | Note UFEP
1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs
1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs
Xxxxxx | 0 | 0 | Follow-on |
Xxxxxx | 0 | > 0 | Follow-on | Interior Resync
-------------+--------------+----------------------+----------------
The details regarding the possible values of the five bit Group Number (GN) field that follows the initial "1" bit when the P-bit is "1" for a GOB, Slice, EOS, or EOSBS packet are found in Section 5.2.3 of H.263 [H263].
当GOB、切片、EOS或EOSBS数据包的P位为“1”时，初始“1”位之后的五位组号（GN）字段可能值的详细信息见H.263[H263]第5.2.3节。
As defined in this specification, every start of a coded frame (as indicated by the presence of a PSC) has to be encapsulated as a picture segment packet. If the whole coded picture fits into one packet of reasonable size (which is dependent on the connection characteristics), this is the only type of packet that may need to be used. Due to the high compression ratio achieved by H.263+, it is often possible to use this mechanism, especially for small spatial picture formats such as Quarter Common Intermediate Format (QCIF) and typical Internet packet sizes around 1500 bytes.
如本规范中所定义，编码帧的每个开始（如PSC的存在所示）必须封装为图片段分组。如果整个编码图片适合一个大小合理的数据包（取决于连接特性），则这是可能需要使用的唯一数据包类型。由于H.263+实现的高压缩比，通常可以使用这种机制，特别是对于小型空间图片格式，如四分之一通用中间格式（QCIF）和1500字节左右的典型互联网数据包大小。
If the complete coded frame does not fit into a single packet, two different ways for the packetization may be chosen. In case of very low or zero packet loss probability, one or more Follow-on Packets may be used for coding the rest of the picture. Doing so leads to minimal coding and packetization overhead, as well as to an optimal use of the maximal packet size, but does not provide any added error resilience.
如果完整的编码帧不适合单个分组，则可以选择两种不同的分组方式。在包丢失概率非常低或为零的情况下，可以使用一个或多个后续包对图片的其余部分进行编码。这样做将导致最小的编码和分组开销，以及最大分组大小的最佳使用，但不会提供任何额外的错误恢复能力。
The alternative is to break the picture into reasonably small partitions, called Segments (by using the Slice or GOB mechanism), that do offer synchronization points. By doing so and using the Picture Segment payload with PLEN>0, decoding of the transmitted packets is possible even in cases in which the Picture packet containing the picture header was lost (provided any necessary reference picture is available). Picture Segment packets can also be used in conjunction with Follow-on Packets for large segment sizes.
另一种方法是将图片分成相当小的分区，称为段（通过使用Slice或GOB机制），这些分区确实提供了同步点。通过这样做并使用具有PLEN>0的图片段有效载荷，即使在包含图片报头的图片分组丢失的情况下（前提是任何必要的参考图片可用），也可以对发送的分组进行解码。图片段数据包也可以与后续数据包一起用于较大的数据段大小。
This section specifies optional parameters that MAY be used to select optional features of the H.263 codec. The parameters are specified here as part of the Media Type registration for the ITU-T H.263 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
本节指定可用于选择H.263编解码器可选功能的可选参数。此处指定的参数是ITU-T H.263编解码器媒体类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[RFC4566]的映射。多个参数应表示为媒体类型字符串，以分号分隔的参数=值对列表的形式。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555].
本节介绍与此有效负载格式关联的媒体类型和名称。本节更新了RFC 3555[RFC3555]中先前注册的版本。
Type name: video
类型名称：视频
Subtype name: H263-1998
子类型名称：H263-1998
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
SQCIF：指定SQCIF分辨率的MPI（最小图片间隔）。允许值是1到32之间的整数值，对应于每秒30/（1.001*指定值）帧的最大帧速率。
QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
QCIF：指定QCIF分辨率的MPI（最小图片间隔）。允许值是1到32之间的整数值，对应于每秒30/（1.001*指定值）帧的最大帧速率。
CIF: Specifies the MPI (Minimum Picture Interval) for CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF：指定CIF分辨率的MPI（最小图片间隔）。允许值是1到32之间的整数值，对应于每秒30/（1.001*指定值）帧的最大帧速率。
CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF4：指定4CIF分辨率的MPI（最小图片间隔）。允许值是1到32之间的整数值，对应于每秒30/（1.001*指定值）帧的最大帧速率。
CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF16：指定16CIF分辨率的MPI（最小图片间隔）。允许值是1到32之间的整数值，对应于每秒30/（1.001*指定值）帧的最大帧速率。
CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom-defined resolution. The custom parameter receives three comma-separated values, Xmax, Ymax, and MPI. The Xmax and Ymax parameters describe the number of pixels in the X and Y axis and must be evenly divisible by 4. The permissible values for MPI are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 *the specified value).
自定义：指定自定义分辨率的MPI（最小图片间隔）。自定义参数接收三个逗号分隔的值：Xmax、Ymax和MPI。Xmax和Ymax参数描述X轴和Y轴上的像素数，必须能被4整除。MPI的允许值为1到32之间的整数值，对应于30/（1.001*指定值）的最大帧速率。
A system that declares support of a specific MPI for one of the resolutions SHALL also implicitly support a lower resolution with the same MPI.
声明支持某一分辨率的特定MPI的系统也应隐式支持具有相同MPI的较低分辨率。
A list of optional annexes specifies which annexes of H.263 are supported. The optional annexes are defined as part of H263-1998, H263-2000. H.263 annex X [H263] defines profiles that group annexes for specific applications. A system that supports a specific annex SHALL specify its support using the optional parameters. If no annex is specified, then the stream is Baseline H.263.
可选附件列表指定支持H.263的哪些附件。可选附件定义为H263-1998、H263-2000的一部分。H.263附录X[H263]定义了针对特定应用对附录进行分组的配置文件。支持特定附件的系统应使用可选参数指定其支持。如果未指定附件，则流为基线H.263。
The allowed optional parameters for the annexes are "F", "I", "J", "T", "K", "N", and "P".
附件允许的可选参数为“F”、“I”、“J”、“T”、“K”、“N”和“P”。
"F", "I", "J", and "T" if supported, SHALL have the value "1". If not supported, they should not be listed or SHALL have the value "0".
“F”、“I”、“J”和“T”如有支持，应具有值“1”。如果不支持，则不应列出它们或其值为“0”。
"K" can receive one of four values 1 - 4:
“K”可以接收四个值1-4中的一个：
1: Slices In Order, Non-Rectangular
1：按顺序切片，非矩形
2: Slices In Order, Rectangular
2：按顺序切片，矩形
3: Slices Not Ordered, Non-Rectangular
3：切片未排序，非矩形
4: Slices Not Ordered, Rectangular
4：切片未排序，矩形
"N": Reference Picture Selection mode - Four numeric choices (1 - 4) are available, representing the following modes:
“N”：参考图片选择模式-四个数字选项（1-4）可用，代表以下模式：
1: NEITHER: No back-channel data is returned from the decoder to the encoder.
1：两者都不是：没有从解码器返回到编码器的后通道数据。
2: ACK: The decoder returns only acknowledgment messages.
2:ACK：解码器仅返回确认消息。
3: NACK: The decoder returns only non-acknowledgment messages.
3:NACK：解码器仅返回非确认消息。
4: ACK+NACK: The decoder returns both acknowledgment and non-acknowledgment messages.
4:ACK+NACK：解码器返回确认和非确认消息。
No special provision is made herein for carrying back channel information. The Extended RTP Profile for RTCP-based Feedback [RFC4585] MAY be used as a back channel mechanism.
本协议中没有关于回传信道信息的特殊规定。基于RTCP的反馈[RFC4585]的扩展RTP配置文件可用作后通道机制。
"P": Reference Picture Resampling, in which the following submodes are represented as a number from 1 to 4:
“P”：参考图片重采样，其中以下子模式表示为1到4之间的数字：
1: dynamicPictureResizingByFour
1：动态构造设计四
2: dynamicPictureResizingBySixteenthPel
2: dynamicPictureResizingBySixteenthPel
3: dynamicWarpingHalfPel
3：动态ARPINGHALPEL
4: dynamicWarpingSixteenthPel
4：动态ARPINGSIxtenthPel
Example: P=1,3
示例：P=1,3
PAR: Arbitrary Pixel Aspect Ratio. Defines the width:height ratio by two colon-separated integers between 0 and 255. Default ratio is 12:11, if not otherwise specified.
PAR：任意像素纵横比。通过两个介于0和255之间的冒号分隔整数定义宽高比。如果未另行规定，默认比率为12:11。
CPCF: Arbitrary (Custom) Picture Clock Frequency: CPCF is a comma-separated list of eight parameters specifying a custom picture clock frequency and the MPI (minimum picture interval) for the supported picture sizes when using that picture clock frequency. The first two parameters are cd, which is an integer from 1 to 127, and cf, which is either 1000 or 1001. The custom picture clock frequency is given by the formula 1800000/(cd*cf) provided in the RTP Timestamp semantics in Section 3.1 above (as specified in H.263 section 5.1.7). Following the values of cd and cf, the remaining six parameters are SQCIFMPI, QCIFMPI, CIFMPI, CIF4MPI, CIF16MPI, and CUSTOMMPI, which each specify an integer MPI (minimum picture interval) for the standard picture sizes SQCIF, QCIF, CIF, 4CIF, 16CIF, and CUSTOM, respectively, as described above. The MPI value indicates a maximum frame rate of 1800000/(cd*cf*MPI) frames per second for MPI parameters having a value in the range from 1 to 2048, inclusive. An MPI value of 0 specifies that the associated picture size is not supported for the custom picture clock frequency. If the CUSTOMMPI parameter is not equal to 0, the CUSTOM parameter SHALL also be present (so
CPCF：任意（自定义）图片时钟频率：CPCF是以逗号分隔的八个参数列表，指定自定义图片时钟频率和使用该图片时钟频率时支持的图片大小的MPI（最小图片间隔）。前两个参数是cd（从1到127的整数）和cf（1000或1001）。自定义图片时钟频率由上述第3.1节RTP时间戳语义中提供的公式1800000/（cd*cf）给出（如H.263第5.1.7节所规定）。在cd和cf的值之后，剩下的六个参数是SQCIFMPI、QCIFMPI、CIFMPI、CIF4MPI、CIF16MPI和CUSTOMMPI，它们分别为标准图片大小SQCIF、QCIF、CIF、4CIF、16CIF和CUSTOM指定整数MPI（最小图片间隔），如上所述。MPI值表示MPI参数的最大帧速率为每秒1800000/（cd*cf*MPI）帧，MPI参数的值范围为1到2048（包括1到2048）。MPI值为0指定自定义图片时钟频率不支持关联的图片大小。如果CUSTOMMPI参数不等于0，则还应存在自定义参数（因此
that the Xmax and Ymax dimensions of the custom picture size are defined).
自定义图片大小的Xmax和Ymax维度已定义）。
BPP: BitsPerPictureMaxKb. Maximum number of bits in units of 1024 bits allowed to represent a single picture. If this parameter is not present, then the default value, based on the maximum supported resolution, is used. BPP is integer value between 0 and 65536.
BPP:BitsPerPictureMaxKb。以1024位为单位表示单个图片所允许的最大位数。如果此参数不存在，则使用基于支持的最大分辨率的默认值。BPP是介于0和65536之间的整数值。
HRD: Hypothetical Reference Decoder. See annex B of H.263 specification [H263]. This parameter, if supported, SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0".
假设参考解码器。参见H.263规范[H263]的附录B。如果支持，该参数的值应为“1”。如果不支持，则不应列出，或应具有值“0”。
Encoding considerations:
编码注意事项：
This media type is framed and binary; see Section 4.8 in [RFC4288]
这种媒体类型是框架和二进制的；参见[RFC4288]中的第4.8节
Security considerations: See Section 11 of RFC 4629
安全注意事项：见RFC 4629第11节
Interoperability considerations:
互操作性注意事项：
These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will encode the H.263 stream without any of the annexes. Most decoders support at least QCIF and CIF fixed resolutions, and they are expected to be available almost in every H.263-based video application.
这些是接收器选项；当前实现不会在其SDP中发送任何可选参数。他们将忽略可选参数，并将在没有任何附件的情况下对H.263流进行编码。大多数解码器至少支持QCIF和CIF固定分辨率，预计几乎在每一个基于H.263的视频应用程序中都可以使用。
Published specification: RFC 4629
已发布规范：RFC4629
Applications that use this media type:
使用此媒体类型的应用程序：
Audio and video streaming and conferencing tools.
音频和视频流以及会议工具。
Additional information: None
其他信息：无
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Roni Even: roni.even@polycom.co.il
罗尼：罗尼。even@polycom.co.il
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Roni Even
作者：Roni Even
Change controller:
更改控制器：
IETF Audio/Video Transport working group, delegated from the IESG.
IETF音频/视频传输工作组，由IESG授权。
Type name: video
类型名称：视频
Subtype name: H263-2000
子类型名称：H263-2000
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
The optional parameters of the H263-1998 type MAY be used with this media subtype. Specific optional parameters that may be used with the H263-2000 type are as follows:
H263-1998类型的可选参数可用于此媒体子类型。H263-2000型可使用的具体可选参数如下：
PROFILE: H.263 profile number, in the range 0 through 10, specifying the supported H.263 annexes/subparts based on H.263 annex X [H263]. The annexes supported in each profile are listed in table X.1 of H.263 annex X. If no profile or H.263 annex is specified, then the stream is Baseline H.263 (profile 0 of H.263 annex X).
配置文件：H.263配置文件编号，范围从0到10，根据H.263附录X[H263]指定支持的H.263附录/子部分。H.263附录X的表X.1中列出了每个概要文件中支持的附件。如果未指定概要文件或H.263附录，则流为基线H.263（H.263附录X的概要文件0）。
LEVEL: Level of bitstream operation, in the range 0 through 100, specifying the level of computational complexity of the decoding process. The level are described in table X.2 of H.263 annex X.
级别：位流操作的级别，范围为0到100，指定解码过程的计算复杂度级别。H.263附录X表X.2中描述了该水平。
According to H.263 annex X, support of any level other than level 45 implies support of all lower levels. Support of level 45 implies support of level 10.
根据H.263附录X，45级以外的任何级别的支持意味着所有较低级别的支持。支持45级意味着支持10级。
A system that specifies support of a PROFILE MUST specify the supported LEVEL.
指定配置文件支持的系统必须指定支持的级别。
INTERLACE: Interlaced or 60 fields indicates the support for interlace display mode, as specified in H.263 annex W.6.3.11. This parameter, if supported SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0".
隔行扫描：隔行扫描或60个字段表示支持隔行扫描显示模式，如H.263附录W.6.3.11所述。如果支持，该参数的值应为“1”。如果不支持，则不应列出，或应具有值“0”。
Encoding considerations:
编码注意事项：
This media type is framed and binary; see Section 4.8 in [RFC4288]
这种媒体类型是框架和二进制的；参见[RFC4288]中的第4.8节
Security considerations: See Section 11 of RFC 4629
安全注意事项：见RFC 4629第11节
Interoperability considerations:
互操作性注意事项：
The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters.
可选参数剖面和标高不得与任何其他可选参数一起使用。
Published specification: RFC 4629
已发布规范：RFC4629
Applications that use this media type:
使用此媒体类型的应用程序：
Audio and video streaming and conferencing tools.
音频和视频流以及会议工具。
Additional information: None
其他信息：无
Person and email address to contact for further information :
联系人和电子邮件地址，以获取更多信息：
Roni Even: roni.even@polycom.co.il
罗尼：罗尼。even@polycom.co.il
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Roni Even
作者：Roni Even
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
The media types video/H263-1998 and video/H263-2000 are mapped to fields in the Session Description Protocol (SDP) as follows:
媒体类型video/H263-1998和video/H263-2000映射到会话描述协议（SDP）中的字段，如下所示：
o The media name in the "m=" line of SDP MUST be video.
o SDP的“m=”行中的媒体名称必须是视频。
o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 or H263-2000 (the media subtype).
o SDP的“a=rtpmap”行中的编码名称必须是H263-1998或H263-2000（媒体子类型）。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o “a=rtpmap”行中的时钟频率必须为90000。
o The optional parameters, if any, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters.
o 可选参数（如有）必须包含在SDP的“a=fmtp”行中。这些参数表示为媒体类型字符串，以分号分隔的参数=值对列表的形式。可选参数剖面和标高不得与任何其他可选参数一起使用。
For offering H.263 over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
对于在提供/应答模型[RFC3264]中使用SDP通过RTP提供H.263，需要考虑以下事项。
Codec options (F,I,J,K,N,P,T): These options MUST NOT appear unless the sender of these SDP parameters is able to decode those options. These options designate receiver capabilities even when sent in a "sendonly" offer.
编解码器选项（F、I、J、K、N、P、T）：除非这些SDP参数的发送方能够解码这些选项，否则不得显示这些选项。这些选项指定接收器功能，即使在以“仅发送”方式发送时也是如此。
Profile: The offer of a SDP profile parameter signals that the offerer can decode a stream that uses the specified profile. Each profile uses different H.263 annexes, so there is no implied relationship between them. An answerer SHALL NOT change the profile parameter and MUST reject the payload type containing an unsupported profile. A decoder that supports a profile SHALL also support H.263 baseline profile (profile 0). An offerer is RECOMMENDED to offer all the different profiles it is interested to use as individual payload types. In addition an offerer, sending an offer using the PROFILE optional parameter, is RECOMMENDED to offer profile 0, as this will enable communication, and in addition allows an answerer to add those profiles it does support in an answer.
配置文件：SDP配置文件参数的提供表示提供方可以解码使用指定配置文件的流。每个概要文件使用不同的H.263附件，因此它们之间没有隐含的关系。应答者不得更改剖面参数，必须拒绝包含不支持剖面的有效载荷类型。支持配置文件的解码器还应支持H.263基线配置文件（配置文件0）。建议报价人提供其感兴趣用作单独有效负载类型的所有不同配置文件。此外，建议使用配置文件可选参数发送报价的报价人提供配置文件0，因为这将启用通信，此外还允许应答者在应答中添加其支持的配置文件。
LEVEL: The LEVEL parameter in an offer indicates the maximum computational complexity supported by the offerer in performing decoding for the given PROFILE. An answerer MAY change the value (both up and down) of the LEVEL parameter in its answer to indicate the highest value it supports.
级别：报价中的级别参数表示报价人在对给定配置文件执行解码时支持的最大计算复杂度。回答者可以更改其回答中级别参数的值（向上和向下），以指示其支持的最高值。
INTERLACE: The parameter MAY be included in either offer or answer to indicate that the offerer or answerer respectively supports reception of interlaced content. The inclusion in either offer or answer is independent of each other.
隔行：该参数可以包含在要约或应答中，以表明要约人或应答人分别支持隔行内容的接收。报价或答复中包含的内容彼此独立。
Picture sizes and MPI: Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.263 can be combined. All picture sizes can be advertised to the other party, or only a subset. The terminal announces only those picture sizes (with their MPIs) which it is willing to receive. For example, MPI=2 means that the maximum (decodable) picture rate per second is 15/1.001 (approximately 14.985).
图片大小和MPI：可以组合支持的图片大小及其对应的H.263最小图片间隔（MPI）信息。所有图片大小都可以公布给另一方，或者只公布一个子集。终端仅公布其愿意接收的图片大小（及其MPI）。例如，MPI=2意味着每秒的最大（可解码）图片速率为15/1.001（约14.985）。
If the receiver does not specify the picture size/MPI optional parameter, then it SHOULD be ready to receive QCIF resolution with MPI=1.
如果接收器未指定图片大小/MPI可选参数，则应准备好接收MPI=1的QCIF分辨率。
Parameters offered first are the most preferred picture mode to be received.
首先提供的参数是要接收的最首选图片模式。
Here is an example of the usage of these parameters:
以下是使用这些参数的示例：
CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2
CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2
This means that the encoder SHOULD send CIF picture size, which it can decode at MPI=4. If that is not possible, then QCIF with MPI value 3 should be sent; if neither are possible, then SQCIF with MPI value=2. The receiver is capable of (but least preferred) decoding custom picture sizes (max 360x240) with MPI=2. Note that most decoders support at least QCIF and CIF fixed resolutions, and that they are expected to be available almost in every H.263-based video application.
这意味着编码器应该发送CIF图片大小，它可以在MPI=4时解码。如果不可能，则应发送MPI值为3的QCIF；如果两者都不可能，则使用MPI值=2的SQCIF。接收器能够（但至少是首选）解码MPI=2的自定义图片大小（最大360x240）。请注意，大多数解码器至少支持QCIF和CIF固定分辨率，并且几乎在每个基于H.263的视频应用程序中都可以使用它们。
Below is an example of H.263 SDP in an offer:
以下是报价中的H.263 SDP示例：
a=fmtp:xx CIF=4;QCIF=2;F=1;K=1
a=fmtp:xx CIF=4;QCIF=2;F=1;K=1
This means that the sender of this message can decode an H.263 bit stream with the following options and parameters: preferred resolution is CIF (at up to 30/4.004 frames per second), but if that is not possible then QCIF size is also supported (at up to 30/2.002 frames per second). Advanced Prediction mode (AP) and slicesInOrder-NonRect options MAY be used.
这意味着此消息的发送方可以使用以下选项和参数解码H.263比特流：首选分辨率为CIF（高达每秒30/4.004帧），但如果不可能，则还支持QCIF大小（高达每秒30/2.002帧）。可以使用高级预测模式（AP）和切片器顺序非重复选项。
Below is an example of H.263 SDP in an offer that includes the CPCF parameter.
以下是包含CPCF参数的报价中的H.263 SDP示例。
a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1
a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1
This means that the sender of this message can decode an H.263 bit stream with a preferred custom picture size of 640x480 at a maximum frame rate of 25 frames per second using a custom picture clock frequency of 50 Hz. If that is not possible, then the 640x480 picture size is also supported at up to 30/2.002 frames per second using the ordinary picture clock frequency of 30/1.001 Hz. If neither of those is possible, then the CIF and QCIF picture sizes are also supported at up to 50 frames per second using the custom picture clock frequency of 50 Hz or up to 30/1.001 frames per second using the ordinary picture clock frequency of 30/1.001 Hz, and CIF is preferred over QCIF.
这意味着，该消息的发送方可以使用50 Hz的自定义图片时钟频率，以每秒25帧的最大帧速率解码首选自定义图片大小为640x480的H.263比特流。如果不可能，则使用30/1.001 Hz的普通图片时钟频率，以每秒30/2.002帧的速度支持640x480图片大小。如果两者都不可能，则CIF和QCIF图片大小也支持使用50 Hz的自定义图片时钟频率每秒50帧，或使用30/1.001 Hz的普通图片时钟频率每秒30/1.001帧，并且CIF优于QCIF。
The following limitation applies for usage of these media types when performing offer/answer for sessions using multicast transport. An answerer SHALL NOT change any of the parameters in an answer, instead if the indicated values are not supported the payload type MUST be rejected.
以下限制适用于在对使用多播传输的会话执行提供/应答时使用这些媒体类型。回答者不得更改回答中的任何参数，相反，如果不支持指示值，则必须拒绝有效负载类型。
The current document is a revision of RFC 2429 and obsoletes it. This section will address the backward compatibility issues.
当前文件是RFC 2429的修订版，已废弃。本节将讨论向后兼容性问题。
The document adds new optional parameters to the H263-1998 and H263- 2000 payload type, defined in RFC 3555 [RFC3555]. Since these are optional parameters we expect that old implementations will ignore these parameters, and that new implementations that will receive the H263-1998 and H263-2000 payload types with no parameters will behave as if the other side can accept H.263 at QCIF resolution at a frame rate not exceeding 15/1.001 (approximately 14.985) frames per second.
本文件为RFC 3555[RFC3555]中定义的H263-1998和H263-2000有效载荷类型添加了新的可选参数。由于这些是可选参数，我们希望旧的实现将忽略这些参数，并且接收H263-1998和H263-2000有效负载类型（无参数）的新实现将表现为另一方可以在不超过15/1.001（约14.985）的帧速率下以QCIF分辨率接受H.263每秒帧数。
This document updates the H.263 (1998) and H.263 (2000) media types, described in RFC 3555 [RFC3555]. The updated media type registrations are in Section 8.1.
本文档更新了RFC 3555[RFC3555]中描述的H.263（1998）和H.263（2000）介质类型。更新后的媒体类型注册见第8.1节。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile (for example, [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression, so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适当RTP配置文件（例如[RFC3551]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩后执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED.
使用具有非均匀接收端计算负载的压缩技术进行数据编码存在潜在的拒绝服务威胁。攻击者可以向流中注入难以解码的病理数据报，并导致接收器过载。建议至少使用RTP数据包的身份验证。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [RFC2032] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，可以在IGMP[RFC2032]的未来版本和多播路由协议中实现特定源的修剪，以允许接收机选择允许哪些源到达它。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
对该有效负载格式的安全性审查发现，除了RTP规范中的考虑之外，没有其他考虑。
This is to acknowledge the work done by Chad Zhu, Linda Cline, Gim Deisher, Tom Gardos, Christian Maciocco, and Donald Newell from Intel Corp., who co-authored RFC 2429.
这是为了感谢英特尔公司的Chad Zhu、Linda Cline、Gim Deisher、Tom Gardos、Christian Maciocco和Donald Newell所做的工作，他们共同撰写了RFC 2429。
We would also like to acknowledge the work of Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with composing the text for the new media types.
我们还要感谢诺基亚的Petri Koskelainen和思科的Nermeen Ismail的工作，他们帮助撰写了新媒体类型的文本。
The changes from the RFC 2429 are:
RFC 2429的变更如下：
1. The H.263 1998 and 2000 media type are now in the payload specification.
1. H.263 1998和2000介质类型现在在有效负载规范中。
2. Added optional parameters to the H.263 1998 and 2000 media types.
2. 在H.263 1998和2000介质类型中添加了可选参数。
3. Mandate the usage of RFC 2429 for all H.263. RFC 2190 payload format should be used only to interact with legacy systems.
3. 所有RF263.24h的使用。RFC 2190有效负载格式应仅用于与遗留系统交互。
This document adds new optional parameters to the H263-1998 and H263-2000 payload types.
本文档为H263-1998和H263-2000有效负载类型添加了新的可选参数。
[H263] International Telecommunications Union - Telecommunication Standardization Sector, "Video coding for low bit rate communication", ITU-T Recommendation H.263, January 2005.
[H263]国际电信联盟-电信标准化部门，“低比特率通信的视频编码”，ITU-T建议H.263，2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555]Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 35552003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC2032] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[RFC2032]Turletti，T.，“H.261视频流的RTP有效载荷格式”，RFC 2032，1996年10月。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[RFC2190]Zhu，C.“H.263视频流的RTP有效载荷格式”，RFC 21901997年9月。
[RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[RFC2429]Bormann，C.，Cline，L.，Deisher，G.，Gardos，T.，Maciocco，C.，Newell，D.，Ott，J.，Sullivan，G.，Wenger，S.，和C.Zhu，“1998版ITU-T Rec.H.263视频（H.263+）的RTP有效载荷格式”，RFC 24291998年10月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to Historic Status", RFC 4628, January 2007.
[RFC4628]偶数，R.，“H.263将RFC 2190移动到历史状态的RTP有效载荷格式”，RFC 4628，2007年1月。
[Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. Audio-Visual Services over Packet Networks, Aberdeen, U.K. 9/1997, September 1997.
[Vredun]Wenger，S.，“H.263+中的视频冗余编码”，程序。在分组网络上的视听服务，阿伯丁，英国9/1997，1997年9月。
Authors' Addresses
作者地址
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 02015 TKK, Finland
芬兰赫尔辛基工业大学网络实验室PO盒3000，TKK，02015
EMail: jo@netlab.tkk.fi
EMail: jo@netlab.tkk.fi
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, GERMANY
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Gary Sullivan Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
加里·沙利文微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: garysull@microsoft.com
EMail: garysull@microsoft.com
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
斯蒂芬·温格诺基亚研究中心芬兰坦佩雷邮政信箱100 33721
EMail: stewe@stewe.org
EMail: stewe@stewe.org
Roni Even (editor) Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
Roni Even（编辑）Polycom 94 Derech Em Hamoshavot Petach Tikva 49130以色列
EMail: roni.even@polycom.co.il
EMail: roni.even@polycom.co.il
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。