Network Working Group A. Klemets
Request for Comments: 4425 Microsoft
Category: Standards Track February 2006
Network Working Group A. Klemets
Request for Comments: 4425 Microsoft
Category: Standards Track February 2006
RTP Payload Format for Video Codec 1 (VC-1)
视频编解码器1（VC-1）的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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television.
本备忘录规定了用于封装视频编解码器1（VC-1）压缩比特流的RTP有效载荷格式，如电影和电视工程师协会（SMPTE）标准SMPTE 421M所定义。SMPTE是运动成像行业的主要标准化机构，SMPTE 421M标准定义了用于电视的压缩视频比特流格式和解码过程。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Definitions and Abbreviations ...................................3
3. Overview of VC-1 ................................................5
3.1. VC-1 Bit Stream Layering Model .............................6
3.2. Bit-stream Data Units in Advanced Profile ..................7
3.3. Decoder Initialization Parameters ..........................7
3.4. Ordering of Frames .........................................8
4. Encapsulation of VC-1 Format Bit Streams in RTP .................9
4.1. Access Units ...............................................9
4.2. Fragmentation of VC-1 frames ..............................10
4.3. Time Stamp Considerations .................................11
4.4. Random Access Points ......................................13
4.5. Removal of HRD Parameters .................................14
4.6. Repeating the Sequence Layer Header .......................14
4.7. Signaling of Media Type Parameters ........................15
4.8. The "mode=1" Media Type Parameter .........................16
4.9. The "mode=3" Media Type Parameter .........................16
5. RTP Payload Format Syntax ......................................17
5.1. RTP Header Usage ..........................................17
5.2. AU Header Syntax ..........................................18
5.3. AU Control Field Syntax ...................................19
6. RTP Payload Format Parameters ..................................20
6.1. Media type Registration ...................................20
6.2. Mapping of media type parameters to SDP ...................28
6.3. Usage with the SDP Offer/Answer Model .....................29
6.4. Usage in Declarative Session Descriptions .................31
7. Security Considerations ........................................32
8. Congestion Control .............................................33
9. IANA Considerations ............................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................35
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Definitions and Abbreviations ...................................3
3. Overview of VC-1 ................................................5
3.1. VC-1 Bit Stream Layering Model .............................6
3.2. Bit-stream Data Units in Advanced Profile ..................7
3.3. Decoder Initialization Parameters ..........................7
3.4. Ordering of Frames .........................................8
4. Encapsulation of VC-1 Format Bit Streams in RTP .................9
4.1. Access Units ...............................................9
4.2. Fragmentation of VC-1 frames ..............................10
4.3. Time Stamp Considerations .................................11
4.4. Random Access Points ......................................13
4.5. Removal of HRD Parameters .................................14
4.6. Repeating the Sequence Layer Header .......................14
4.7. Signaling of Media Type Parameters ........................15
4.8. The "mode=1" Media Type Parameter .........................16
4.9. The "mode=3" Media Type Parameter .........................16
5. RTP Payload Format Syntax ......................................17
5.1. RTP Header Usage ..........................................17
5.2. AU Header Syntax ..........................................18
5.3. AU Control Field Syntax ...................................19
6. RTP Payload Format Parameters ..................................20
6.1. Media type Registration ...................................20
6.2. Mapping of media type parameters to SDP ...................28
6.3. Usage with the SDP Offer/Answer Model .....................29
6.4. Usage in Declarative Session Descriptions .................31
7. Security Considerations ........................................32
8. Congestion Control .............................................33
9. IANA Considerations ............................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................35
This memo specifies an RTP payload format for the video coding standard Video Codec 1, also known as VC-1. The specification for the VC-1 bit stream format and decoding process is published by the Society of Motion Picture and Television Engineers (SMPTE) as SMPTE 421M [1].
此备忘录为视频编码标准视频编解码器1（也称为VC-1）指定RTP有效负载格式。VC-1比特流格式和解码过程的规范由美国电影和电视工程师学会（SMPTE）发布为SMPTE 421M[1]。
VC-1 has a broad applicability, as it is suitable for low bit rate Internet streaming applications to High Definition Television (HDTV) broadcast and Digital Cinema applications with nearly lossless coding. The overall performance of VC-1 is such that bit rate
VC-1具有广泛的适用性，因为它适用于几乎无损编码的低比特率互联网流媒体应用、高清晰度电视（HDTV）广播和数字电影应用。VC-1的总体性能是这样的：比特率
savings of more than 50% are reported [9] when compared with MPEG-2. See [9] for further details about how VC-1 compares with other codecs, such as MPEG-4 and H.264/AVC. (In [9], VC-1 is referred to by its earlier name, VC-9.)
与MPEG-2相比，节省了50%以上[9]。有关VC-1如何与其他编解码器（如MPEG-4和H.264/AVC）进行比较的更多详细信息，请参见[9]。（在[9]中，VC-1指的是其早期名称VC-9。）
VC-1 is widely used for downloading and streaming movies on the Internet, in the form of Windows Media Video 9 (WMV-9) [9], because the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also recently been adopted as a mandatory compression format for the high-definition DVD formats HD DVD and Blu-ray.
VC-1以Windows Media Video 9（WMV-9）[9]的形式广泛用于在互联网上下载和流式传输电影，因为WMV-9编解码器符合VC-1标准。VC-1最近还被用作高清DVD格式HD DVD和蓝光的强制压缩格式。
SMPTE 421M defines the VC-1 bit stream syntax and specifies constraints that must be met by VC-1 conformant bit streams. SMPTE 421M also specifies the complete process required to decode the bit stream. However, it does not specify the VC-1 compression algorithm, thus allowing for different ways of implementing a VC-1 encoder.
SMPTE 421M定义VC-1比特流语法，并指定VC-1一致性比特流必须满足的约束。SMPTE 421M还指定解码比特流所需的完整过程。但是，它没有指定VC-1压缩算法，因此允许以不同的方式实现VC-1编码器。
The VC-1 bit stream syntax has three profiles. Each profile has specific bit stream syntax elements and algorithms associated with it. Depending on the application in which VC-1 is used, some profiles may be more suitable than others. For example, Simple profile is designed for low bit rate Internet streaming and for playback on devices that can only handle low-complexity decoding. Advanced profile is designed for broadcast applications, such as digital TV, HD DVD, or HDTV. Advanced profile is the only VC-1 profile that supports interlaced video frames and non-square pixels.
VC-1位流语法有三个配置文件。每个配置文件都有特定的位流语法元素和与之相关的算法。根据使用VC-1的应用程序，某些配置文件可能比其他配置文件更合适。例如，Simple profile专为低比特率互联网流媒体和只能处理低复杂度解码的设备上的播放而设计。高级配置文件是为广播应用而设计的，如数字电视、HD DVD或HDTV。Advanced profile是唯一支持隔行扫描视频帧和非方形像素的VC-1配置文件。
Section 2 defines the abbreviations used in this document. Section 3 provides a more detailed overview of VC-1. Sections 4 and 5 define the RTP payload format for VC-1, and section 6 defines the media type and SDP parameters for VC-1. See section 7 for security considerations, and section 8 for congestion control requirements.
第2节定义了本文件中使用的缩写。第3节提供了VC-1的更详细概述。第4节和第5节定义了VC-1的RTP有效负载格式，第6节定义了VC-1的媒体类型和SDP参数。关于安全考虑，请参见第7节；关于拥塞控制要求，请参见第8节。
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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
This document uses the definitions in SMPTE 421M [1]. For convenience, the following terms from SMPTE 421M are restated here:
本文件使用SMPTE 421M[1]中的定义。为方便起见，SMPTE 421M的以下术语在此重述：
B-picture: A picture that is coded using motion compensated prediction from past and/or future reference fields or frames. A B-picture cannot be used for predicting any other picture.
B-图片：使用过去和/或未来参考场或帧的运动补偿预测编码的图片。B图片不能用于预测任何其他图片。
BI-picture: A B-picture that is coded using information only from itself. A BI-picture cannot be used for predicting any other picture.
双画面：仅使用自身信息编码的B画面。BI图片不能用于预测任何其他图片。
Bit-stream data unit (BDU): A unit of the compressed data which may be parsed (i.e., syntax decoded) independently of other information at the same hierarchical level. A BDU can be, for example, a sequence layer header, an entry-point header, a frame, or a slice.
比特流数据单元（BDU）：可独立于同一层次上的其他信息进行解析（即语法解码）的压缩数据单元。例如，BDU可以是序列层头、入口点头、帧或切片。
Encapsulated BDU (EBDU): A BDU that has been encapsulated using the encapsulation mechanism described in Annex E of SMPTE 421M [1], to prevent emulation of the start code prefix in the bit stream.
封装的BDU（EBDU）：使用SMPTE 421M[1]附录E中描述的封装机制封装的BDU，以防止模拟位流中的起始代码前缀。
Entry-point: A point in the bit stream that offers random access.
入口点：位流中提供随机访问的点。
frame: A frame contains lines of spatial information of a video signal. For progressive video, these lines contain samples starting from one time instant and continuing through successive lines to the bottom of the frame. For interlaced video, a frame consists of two fields, a top field and a bottom field. One of these fields will commence one field period later than the other.
帧：帧包含视频信号的空间信息行。对于渐进式视频，这些行包含从一个时间瞬间开始并通过连续行继续到帧底部的采样。对于隔行扫描视频，帧由两个场组成，一个顶场和一个底场。其中一个油田将比另一个油田晚开始一个油田周期。
interlace: The property of frames where alternating lines of the frame represent different instances in time. In an interlaced frame, one of the fields is meant to be displayed first.
交错：帧的属性，其中帧的交替线表示时间上的不同实例。在隔行扫描帧中，其中一个字段将首先显示。
I-picture: A picture coded using information only from itself.
I-picture：仅使用自身信息编码的图片。
level: A defined set of constraints on the values that may be taken by the parameters (such as bit rate and buffer size) within a particular profile. A profile may contain one or more levels.
级别：对特定配置文件中的参数（如比特率和缓冲区大小）可能采用的值的一组定义的约束。配置文件可以包含一个或多个级别。
P-picture: A picture that is coded using motion compensated prediction from past reference fields or frames.
P-picture：使用过去参考场或帧的运动补偿预测编码的图片。
picture: For progressive video, a picture is identical to a frame, while for interlaced video, a picture may refer to a frame, or the top field or the bottom field of the frame depending on the context.
图片：对于渐进式视频，图片与帧相同，而对于隔行扫描视频，图片可能指帧，或帧的顶部字段或底部字段，具体取决于上下文。
profile: A defined subset of the syntax of VC-1 with a specific set of coding tools, algorithms, and syntax associated with it. There are three VC-1 profiles: Simple, Main, and Advanced.
配置文件：VC-1语法的定义子集，带有一组特定的编码工具、算法和与之相关的语法。有三个VC-1配置文件：简单、主要和高级。
progressive: The property of frames where all the samples of the frame represent the same instance in time.
渐进式：帧的属性，其中帧的所有样本在时间上表示同一实例。
random access: A random access point in the bit stream is defined by the following guarantee: If decoding begins at this point, all frames needed for display after this point will have no decoding dependency on any data preceding this point, and they are also present in the decoding sequence after this point. A random access point is also called an entry-point.
随机访问：比特流中的随机访问点由以下保证定义：如果解码从该点开始，则该点之后需要显示的所有帧将不依赖于该点之前的任何数据，并且它们也存在于该点之后的解码序列中。随机接入点也称为入口点。
sequence: A coded representation of a series of one or more pictures. In VC-1 Advanced profile, a sequence consists of a series of one or more entry-point segments, where each entry-point segment consists of a series of one or more pictures, and where the first picture in each entry-point segment provides random access. In VC-1 Simple and Main profiles, the first picture in each sequence is an I-picture.
序列：一系列一幅或多幅图片的编码表示。在VC-1高级配置文件中，序列由一系列一个或多个入口点段组成，其中每个入口点段由一系列一个或多个图片组成，每个入口点段中的第一个图片提供随机访问。在VC-1简单和主配置文件中，每个序列中的第一个图片是I图片。
slice: A consecutive series of macroblock rows in a picture, which are encoded as a single unit.
切片：图片中连续的一系列宏块行，编码为单个单元。
start codes (SC): Unique 32-bit codes that are embedded in the coded bit stream and identify the beginning of a BDU. Start codes consist of a unique three-byte Start Code Prefix (SCP), and a one-byte Start Code Suffix (SCS).
起始代码（SC）：嵌入编码位流中的唯一32位代码，用于标识BDU的开始。启动码由唯一的三字节启动码前缀（SCP）和一字节启动码后缀（SCS）组成。
The VC-1 bit stream syntax consists of three profiles: Simple, Main, and Advanced. Simple profile is designed for low bit rates and for low complexity applications, such as playback of media on personal digital assistants. The maximum bit rate supported by Simple profile
VC-1位流语法由三个配置文件组成：简单、主要和高级。Simple profile专为低比特率和低复杂性应用而设计，如在个人数字助理上播放媒体。简单配置文件支持的最大比特率
is 384 kbps. Main profile targets high bit rate applications, such as streaming and TV over IP. Main profile supports B-pictures, which provide improved compression efficiency at the cost of higher complexity.
是384kbps。Main profile面向高比特率应用，如流媒体和IP电视。主配置文件支持B-pictures，以更高的复杂性为代价提高了压缩效率。
Certain features that can be used to achieve high compression efficiency, such as non-square pixels and support for interlaced pictures, are only included in Advanced profile. The maximum bit rate supported by the Advanced profile is 135 Mbps, making it suitable for nearly lossless encoding of HDTV signals.
某些可用于实现高压缩效率的功能，如非方形像素和对隔行扫描图片的支持，仅包含在高级配置文件中。高级配置文件支持的最大比特率为135 Mbps，适用于HDTV信号的几乎无损编码。
Only Advanced profile supports carrying user-data (meta-data) in-band with the compressed bit stream. The user-data can be used for closed captioning support, for example.
只有高级配置文件支持在压缩比特流的频带内携带用户数据（元数据）。例如，用户数据可用于闭路字幕支持。
Of the three profiles, only Advanced profile allows codec configuration parameters, such as the picture aspect ratio, to be changed through in-band signaling in the compressed bit stream.
在这三个配置文件中，只有高级配置文件允许通过压缩比特流中的带内信令更改编解码器配置参数，例如图片纵横比。
For each of the profiles, a certain number of "levels" have been defined. Unlike a "profile", which implies a certain set of features or syntax elements, a "level" is a set of constraints on the values of parameters in a profile, such as the bit rate or buffer size. VC-1 Simple profile has two levels, Main profile has three, and Advanced profile has five. See Annex D of SMPTE 421M [1] for a detailed list of the profiles and levels.
对于每个配置文件，都定义了一定数量的“级别”。与“profile”不同，“level”表示一组特定的特性或语法元素，“level”是对profile中参数值的一组约束，例如比特率或缓冲区大小。VC-1简单概要文件有两个级别，主概要文件有三个，高级概要文件有五个。剖面和标高的详细列表见SMPTE 421M[1]的附录D。
The VC-1 bit stream is defined as a hierarchy of layers. This is conceptually similar to the notion of a protocol stack of networking protocols. The outermost layer is called the sequence layer. The other layers are entry-point, picture, slice, macroblock, and block.
VC-1比特流被定义为层的层次结构。这在概念上类似于网络协议的协议栈的概念。最外层称为序列层。其他层是入口点、图片、切片、宏块和块。
In Simple and Main profiles, a sequence in the sequence layer consists of a series of one or more coded pictures. In Advanced profile, a sequence consists of one or more entry-point segments, where each entry-point segment consists of a series of one or more pictures, and where the first picture in each entry-point segment provides random access. A picture is decomposed into macroblocks. A slice comprises one or more contiguous rows of macroblocks.
在简单和主配置文件中，序列层中的序列由一系列一个或多个编码图片组成。在高级配置文件中，序列由一个或多个入口点段组成，其中每个入口点段由一系列一个或多个图片组成，每个入口点段中的第一个图片提供随机访问。图片被分解成宏块。片包括一个或多个连续的宏块行。
The entry-point and slice layers are only present in Advanced profile. In Advanced profile, the start of each entry-point layer segment indicates a random access point. In Simple and Main profiles, each I-picture is a random access point.
入口点和切片层仅存在于高级配置文件中。在高级配置文件中，每个入口点层段的起点表示一个随机访问点。在简单和主配置文件中，每个I-picture都是一个随机访问点。
Each picture can be coded as an I-picture, P-picture, skipped picture, BI-picture, or as a B-picture. These terms are defined in section 2 of this document and in section 4.12 of SMPTE 421M [1].
每个图片可以编码为I图片、P图片、跳过图片、BI图片或B图片。本文件第2节和SMPTE 421M[1]第4.12节对这些术语进行了定义。
In Advanced profile, each picture and slice is considered a Bit-stream Data Unit (BDU). A BDU is always byte-aligned and is defined as a unit that can be parsed (i.e., syntax decoded) independently of other information in the same layer.
在高级配置文件中，每个图片和切片都被视为比特流数据单元（BDU）。BDU始终是字节对齐的，定义为可以独立于同一层中的其他信息进行解析（即语法解码）的单元。
The beginning of a BDU is signaled by an identifier called Start Code (SC). Sequence layer headers and entry-point headers are also BDUs and thus can be easily identified by their Start Codes. See Annex E of SMPTE 421M [1] for a complete list of Start Codes. Blocks and macroblocks are not BDUs and thus do not have a Start Code and are not necessarily byte-aligned.
BDU的开始由称为开始代码（SC）的标识符发出信号。序列层头和入口点头也是BDU，因此可以通过它们的起始代码轻松识别。有关启动代码的完整列表，请参见SMPTE 421M[1]的附录E。块和宏块不是BDU，因此没有起始代码，也不一定是字节对齐的。
The Start Code consists of four bytes. The first three bytes are 0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix (SCS) and it is used to indicate the type of BDU that follows the Start Code. For example, the SCS of a sequence layer header (0x0F) is different from the SCS of an entry-point header (0x0E). The Start Code is always byte-aligned and is transmitted in network byte order.
开始代码由四个字节组成。前三个字节是0x00、0x00和0x01。第四个字节称为起始代码后缀（SCS），用于指示起始代码后面的BDU类型。例如，序列层头（0x0F）的SCS不同于入口点头（0x0E）的SCS。起始代码始终按字节对齐，并按网络字节顺序传输。
To prevent accidental emulation of the Start Code in the coded bit stream, SMPTE 421M defines an encapsulation mechanism that uses byte stuffing. A BDU that has been encapsulated by this mechanism is referred to as an Encapsulated BDU, or EBDU.
为了防止在编码比特流中意外模拟起始代码，SMPTE 421M定义了一种使用字节填充的封装机制。由该机制封装的BDU称为封装BDU或EBDU。
In VC-1 Advanced profile, the sequence layer header contains parameters that are necessary to initialize the VC-1 decoder.
在VC-1高级配置文件中，序列层头包含初始化VC-1解码器所需的参数。
The parameters apply to all entry-point segments until the next occurrence of a sequence layer header in the coded bit stream.
参数应用于所有入口点段，直到编码比特流中出现下一个序列层头。
The parameters in the sequence layer header include the Advanced profile level, the maximum dimensions of the coded frames, the aspect ratio, interlace information, the frame rate and up to 31 leaky bucket parameter sets for the Hypothetical Reference Decoder (HRD).
序列层报头中的参数包括高级简档级别、编码帧的最大尺寸、纵横比、隔行信息、帧速率以及假想参考解码器（HRD）的多达31个漏桶参数集。
Section 6.1 of SMPTE 421M [1] provides the formal specification of the sequence layer header.
SMPTE 421M[1]第6.1节提供了序列层头的正式规范。
A sequence layer header is not defined for VC-1 Simple and Main profiles. For these profiles, decoder initialization parameters MUST be conveyed out-of-band. The decoder initialization parameters for Simple and Main profiles include the maximum dimensions of the coded frames and a leaky bucket parameter set for the HRD. Section 4.7 specifies how the parameters are conveyed by this RTP payload format.
未为VC-1简单配置文件和主配置文件定义序列层标头。对于这些配置文件，解码器初始化参数必须在带外传输。简单和主要简档的解码器初始化参数包括编码帧的最大尺寸和为HRD设置的漏桶参数。第4.7节规定了RTP有效载荷格式如何传递参数。
Each leaky bucket parameter set for the HRD specifies a peak transmission bit rate and a decoder buffer capacity. The coded bit stream is restricted by these parameters. The HRD model does not mandate buffering by the decoder. Its purpose is to limit the encoder's bit rate fluctuations according to a basic buffering model so that the resources necessary to decode the bit stream are predictable. The HRD has a constant-delay mode and a variable-delay mode. The constant-delay mode is appropriate for broadcast and streaming applications, while the variable-delay mode is designed for video-conferencing applications.
为HRD设置的每个漏桶参数指定峰值传输比特率和解码器缓冲器容量。编码比特流受这些参数的限制。HRD模型不要求解码器进行缓冲。其目的是根据基本缓冲模型限制编码器的比特率波动，以便解码比特流所需的资源是可预测的。HRD具有恒定延迟模式和可变延迟模式。恒定延迟模式适用于广播和流媒体应用，而可变延迟模式适用于视频会议应用。
Annex C of SMPTE 421M [1] specifies the usage of the hypothetical reference decoder for VC-1 bit streams. A general description of the theory of the HRD can be found in [10].
SMPTE 421M[1]的附录C规定了VC-1比特流的假设参考解码器的使用。HRD理论的一般描述见[10]。
For Simple and Main profiles, the current buffer fullness value for the HRD leaky bucket is signaled using the BF syntax element in the picture header of I-pictures and BI-pictures.
对于简单和主要配置文件，HRD泄漏存储桶的当前缓冲区满度值使用I-pictures和BI-pictures的图片标题中的BF语法元素发出信号。
For Advanced profile, the entry-point header specifies current buffer fullness values for the leaky buckets in the HRD. The entry-point header also specifies coding control parameters that are in effect until the occurrence of the next entry-point header in the bit stream. The concept of an entry-point layer applies only to VC-1 Advanced profile. See Section 6.2 of SMPTE 421M [1] for the formal specification of the entry-point header.
对于高级配置文件，入口点标头指定HRD中泄漏存储桶的当前缓冲区满度值。入口点报头还指定编码控制参数，这些参数在比特流中出现下一个入口点报头之前有效。入口点层的概念仅适用于VC-1高级配置文件。入口点标题的正式规范见SMPTE 421M[1]第6.2节。
Frames are transmitted in the same order in which they are captured, except if B-pictures or BI-pictures are present in the coded bit stream. A BI-picture is a special kind of B-picture, and in the remainder of this section the terms B-picture and B-frame also apply to BI-pictures and BI-frames, respectively.
帧以捕获它们的相同顺序传输，除非编码比特流中存在B图片或BI图片。双图片是一种特殊的B图片，在本节的其余部分中，术语B图片和B帧也分别适用于双图片和双帧。
When B-pictures are present in the coded bit stream, the frames are transmitted such that the frames that the B-pictures depend on are transmitted first. This is referred to as the coded order of the frames.
当编码比特流中存在B图片时，发送帧，使得首先发送B图片所依赖的帧。这被称为帧的编码顺序。
The rules for how a decoder converts frames from the coded order to the display order are stated in section 5.4 of SMPTE 421M [1]. In short, if B-pictures may be present in the coded bit stream, a hypothetical decoder implementation needs to buffer one additional decoded frame. When an I-frame or a P-frame is received, the frame can be decoded immediately but it is not displayed until the next I-or P-frame is received. However, B-frames are displayed immediately.
关于解码器如何将帧从编码顺序转换为显示顺序的规则，见SMPTE 421M[1]第5.4节。简言之，如果编码比特流中可能存在B图片，则假设的解码器实现需要缓冲一个额外的解码帧。当接收到I帧或P帧时，可以立即解码该帧，但在接收到下一个I帧或P帧之前不会显示该帧。但是，B帧会立即显示。
Figure 1 illustrates the timing relationship between the capture of frames, their coded order, and the display order of the decoded frames, when B-pictures are present in the coded bit stream. The figure shows that the display of frame P4 is delayed until frame P7 is received, while frames B2 and B3 are displayed immediately.
图1说明了当编码比特流中存在B图片时，帧的捕获、其编码顺序和解码帧的显示顺序之间的时序关系。该图显示，帧P4的显示延迟到接收到帧P7，而帧B2和B3立即显示。
Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ...
|
Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ...
|
Display order: | I0 P1 B2 B3 P4 B5 B6 ...
|
|+---+---+---+---+---+---+---+---+---+--> time
0 1 2 3 4 5 6 7 8 9
Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ...
|
Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ...
|
Display order: | I0 P1 B2 B3 P4 B5 B6 ...
|
|+---+---+---+---+---+---+---+---+---+--> time
0 1 2 3 4 5 6 7 8 9
Figure 1. Frame reordering when B-pictures are present
图1。存在B图片时的帧重新排序
If B-pictures are not present, the coded order and the display order are identical, and frames can then be displayed without the additional delay shown in Figure 1.
如果不存在B图片，则编码顺序和显示顺序相同，然后可以显示帧，而无需图1所示的额外延迟。
Each RTP packet contains an integral number of application data units (ADUs). For VC-1 format bit streams, an ADU is equivalent to one Access Unit (AU). An Access Unit is defined as the AU header (defined in section 5.2) followed by a variable length payload, with the rules and constraints described in sections 4.1 and 4.2. Figure 2 shows the layout of an RTP packet with multiple AUs.
每个RTP数据包包含整数个应用程序数据单元（ADU）。对于VC-1格式的比特流，ADU相当于一个访问单元（AU）。访问单元定义为AU报头（在第5.2节中定义），后跟可变长度有效载荷，规则和约束在第4.1节和第4.2节中描述。图2显示了具有多个AU的RTP数据包的布局。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| RTP | AU(1) | AU(2) | | AU(n) |
| Header | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| RTP | AU(1) | AU(2) | | AU(n) |
| Header | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 2. RTP packet structure
图2。RTP包结构
Each Access Unit MUST start with the AU header defined in section 5.2. The AU payload MUST contain data belonging to exactly one VC-1 frame. This means that data from different VC-1 frames will always be in different AUs. However, it possible for a single VC-1 frame to be fragmented across multiple AUs (see section 4.2).
每个访问单元必须以第5.2节中定义的AU头开始。AU有效负载必须包含恰好属于一个VC-1帧的数据。这意味着来自不同VC-1帧的数据将始终位于不同的AU中。但是，单个VC-1帧可能会在多个AU之间分段（见第4.2节）。
In the case of interlaced video, a VC-1 frame consists of two fields that may be coded as separate pictures. The two pictures still belong to the same VC-1 frame.
在隔行扫描视频的情况下，VC-1帧由两个字段组成，这两个字段可以编码为单独的图片。这两张图片仍然属于同一个VC-1框架。
The following rules apply to the contents of each AU payload when VC-1 Advanced profile is used:
使用VC-1高级配置文件时，以下规则适用于每个AU有效负载的内容：
- The AU payload MUST contain VC-1 bit stream data in EBDU format (i.e., the bit stream must use the byte-stuffing encapsulation mode defined in Annex E of SMPTE 421M [1].)
- AU有效载荷必须包含EBDU格式的VC-1比特流数据（即，比特流必须使用SMPTE 421M[1]附录e中定义的字节填充封装模式。）
- The AU payload MAY contain multiple EBDUs, e.g., a sequence layer header, an entry-point header, a frame (picture) header, a field header, and multiple slices and the associated user-data. However, all slices and their corresponding macroblocks MUST belong to the same video frame.
- AU有效载荷可以包含多个ebdu，例如，序列层报头、入口点报头、帧（图片）报头、字段报头、多个片和相关联的用户数据。但是，所有切片及其对应的宏块必须属于同一视频帧。
- The AU payload MUST start at an EBDU boundary, except when the AU payload contains a fragmented frame, in which case the rules in section 4.2 apply.
- AU有效载荷必须从EBDU边界开始，除非AU有效载荷包含碎片帧，在这种情况下，第4.2节中的规则适用。
When VC-1 Simple or Main profiles are used, the AU payload MUST start at the beginning of a frame, except when the AU payload contains a fragmented frame. Section 4.2 describes how to handle fragmented frames.
当使用VC-1简单配置文件或主配置文件时，AU有效负载必须从帧的开头开始，除非AU有效负载包含碎片帧。第4.2节描述了如何处理碎片帧。
Access Units MUST be byte-aligned. If the data in an AU (EBDUs in the case of Advanced profile and frame in the case of Simple and Main) does not end at an octet boundary, up to 7 zero-valued padding bits MUST be added to achieve octet-alignment.
访问单元必须是字节对齐的。如果AU中的数据（在高级配置文件中为EBDU，在简单和主要配置文件中为帧）不以八位字节边界结束，则必须添加多达7个零值填充位以实现八位字节对齐。
Each AU payload SHOULD contain a complete VC-1 frame. However, if this would cause the RTP packet to exceed the MTU size, the frame SHOULD be fragmented into multiple AUs to avoid IP-level fragmentation. When an AU contains a fragmented frame, this MUST be indicated by setting the FRAG field in the AU header as defined in section 5.3.
每个AU有效载荷应包含一个完整的VC-1机架。但是，如果这会导致RTP数据包超过MTU大小，则应将帧分段为多个AU，以避免IP级分段。当AU包含碎片帧时，必须按照第5.3节中的定义在AU标题中设置碎片字段来表示。
AU payloads that do not contain a fragmented frame or that contain the first fragment of a frame MUST start at an EBDU boundary if Advanced profile is used. In this case, for Simple and Main profiles, the AU payload MUST start at the beginning of a frame.
如果使用高级配置文件，则不包含碎片帧或包含帧的第一个片段的AU有效载荷必须从EBDU边界开始。在这种情况下，对于简单概要文件和主概要文件，AU有效负载必须从帧的开头开始。
If Advanced profile is used, AU payloads that contain a fragment of a frame other than the first fragment SHOULD start at an EBDU boundary, such as at the start of a slice.
如果使用高级配置文件，则包含帧片段而不是第一个片段的AU有效载荷应在EBDU边界处开始，例如在片段的开始处。
However, slices are only defined for Advanced profile, and are not always used. Blocks and macroblocks are not BDUs (have no Start Code) and are not byte-aligned. Therefore, it may not always be possible to continue a fragmented frame at an EBDU boundary. One can determine if an AU payload starts at an EBDU boundary by inspecting the first three bytes of the AU payload. The AU payload starts at an EBDU boundary if the first three bytes are identical to the Start Code Prefix (i.e., 0x00, 0x00, 0x01).
但是，切片仅为高级配置文件定义，并不总是使用。块和宏块不是BDU（没有起始代码），也不是字节对齐的。因此，在EBDU边界处可能并不总是能够继续分段帧。可以通过检查AU有效负载的前三个字节来确定AU有效负载是否从EBDU边界开始。如果前三个字节与起始代码前缀（即0x00、0x00、0x01）相同，则AU有效负载从EBDU边界开始。
In the case of Simple and Main profiles, since the blocks and macroblocks are not byte-aligned, the fragmentation boundary may be chosen arbitrarily.
在简单概要文件和主概要文件的情况下，由于块和宏块不是字节对齐的，因此可以任意选择分段边界。
If an RTP packet contains an AU with the last fragment of a frame, additional AUs SHOULD NOT be included in the RTP packet.
如果RTP数据包包含具有帧的最后一个片段的AU，则RTP数据包中不应包含其他AU。
If the PTS Delta field in the AU header is present, each fragment of a frame MUST have the same presentation time. If the DTS Delta field in the AU header is present, each fragment of a frame MUST have the same decode time.
如果AU标头中存在PTS增量字段，则帧的每个片段必须具有相同的显示时间。如果AU报头中存在DTS Delta字段，则帧的每个片段必须具有相同的解码时间。
VC-1 video frames MUST be transmitted in the coded order. A coded order implies that no frames are dependent on subsequent frames, as discussed in section 3.4. When a video frame consists of a single picture, the presentation time of the frame is identical to the presentation time of the picture. When the VC-1 interlace coding mode is used, frames may contain two pictures, one for each field. In that case, the presentation time of a frame is the presentation time of the field that is displayed first.
VC-1视频帧必须按编码顺序传输。编码顺序意味着没有帧依赖于后续帧，如第3.4节所述。当视频帧由单个图片组成时，帧的显示时间与图片的显示时间相同。当使用VC-1隔行编码模式时，帧可能包含两个图片，每个字段一个。在这种情况下，帧的显示时间是首先显示的字段的显示时间。
The RTP timestamp field MUST be set to the presentation time of the video frame contained in the first AU in the RTP packet. The presentation time can be used as the timestamp field in the RTP header because it differs from the sampling instant of the frame only by an arbitrary constant offset.
RTP timestamp字段必须设置为RTP数据包中第一个AU中包含的视频帧的显示时间。表示时间可以用作RTP报头中的时间戳字段，因为它与帧的采样瞬间仅相差任意常量偏移量。
If the video frame in an AU has a presentation time that differs from the RTP timestamp field, then the presentation time MUST be specified using the PTS Delta field in the AU header. Since the RTP timestamp field must be identical to the presentation time of the first video frame, this can only happen if an RTP packet contains multiple AUs. The syntax of the PTS Delta field is defined in section 5.2.
如果AU中的视频帧具有不同于RTP时间戳字段的显示时间，则必须使用AU标头中的PTS增量字段指定显示时间。由于RTP时间戳字段必须与第一个视频帧的显示时间相同，因此只有在RTP数据包包含多个AU时才会发生这种情况。第5.2节定义了PTS增量字段的语法。
The decode time of a VC-1 frame is always monotonically increasing when the video frames are transmitted in the coded order. If neither B- nor BI-pictures are present in the coded bit stream, then the decode time of a frame SHALL be equal to the presentation time of the frame. A BI-picture is a special kind of B-picture, and in the remainder of this section the terms B-picture and B-frame also apply to BI-pictures and BI-frames, respectively.
当视频帧以编码顺序传输时，VC-1帧的解码时间总是单调增加的。如果编码比特流中不存在B-或BI图片，则帧的解码时间应等于帧的呈现时间。双图片是一种特殊的B图片，在本节的其余部分中，术语B图片和B帧也分别适用于双图片和双帧。
If B-pictures may be present in the coded bit stream, then the decode times of frames are determined as follows:
如果编码比特流中可能存在B图片，则帧的解码时间确定如下：
- B-frames: The decode time SHALL be equal to the presentation time of the B-frame.
- B帧：解码时间应等于B帧的显示时间。
- First non-B frame in the coded order: The decode time SHALL be at least one frame period less than the decode time of the next frame in the coded order. A frame period is defined as the inverse of the frame rate used in the coded bit stream (e.g., 100 milliseconds if the frame rate is 10 frames per seconds.) For bit streams with a variable frame rate, the maximum frame rate SHALL determine the frame period. If the maximum frame is not specified, the maximum frame rate allowed by the profile and level SHALL be used.
- 编码顺序中的第一个非B帧：解码时间应至少比编码顺序中下一帧的解码时间短一个帧周期。帧周期定义为编码比特流中使用的帧速率的倒数（例如，如果帧速率为10帧/秒，则为100毫秒）。对于具有可变帧速率的比特流，最大帧速率应确定帧周期。如果未规定最大帧数，则应使用剖面和标高允许的最大帧速率。
- Non-B frames (other than the first frame in the coded order): The decode time SHALL be equal to the presentation time of the previous non-B frame in the coded order.
- 非B帧（编码顺序中的第一帧除外）：解码时间应等于编码顺序中前一个非B帧的显示时间。
As an example, consider Figure 1 in section 3.4. To determine the decode time of the first frame, I0, one must first determine the decode time of the next frame, P1. Because P1 is a non-B frame, its decode time is equal to the presentation time of I0, which is 3 time units. Thus, the decode time of I0 must be at least one frame period less than 3. In this example, the frame period is 1, because one frame is displayed every time unit. Consequently, the decode time of I0 is chosen as 2 time units. The decode time of the third frame in the coded order, P4, is 4, because it must be equal to the presentation time of the previous non-B frame in the coded order, P1. On the other hand, the decode time of B-frame B2 is 5 time units, which is identical to its presentation time.
作为一个例子，在第3.4节中考虑图1。要确定第一帧的解码时间I0，必须首先确定下一帧的解码时间P1。因为P1是非B帧，所以其解码时间等于I0的呈现时间，即3个时间单位。因此，I0的解码时间必须至少是小于3的一个帧周期。在本例中，帧周期为1，因为每个时间单位显示一帧。因此，将I0的解码时间选择为2个时间单位。编码顺序中的第三帧P4的解码时间是4，因为它必须等于编码顺序中的前一个非B帧P1的呈现时间。另一方面，B帧B2的解码时间是5个时间单位，这与其呈现时间相同。
If the decode time of a video frame differs from its presentation time, then the decode time MUST be specified using the DTS Delta field in the AU header. The syntax of the DTS Delta field is defined in section 5.2.
如果视频帧的解码时间与其呈现时间不同，则必须使用AU报头中的DTS增量字段指定解码时间。第5.2节定义了DTS增量字段的语法。
Receivers are not required to use the DTS Delta field. However, possible uses include buffer management and pacing of frames prior to decoding. If RTP packets are lost, it is possible to use the DTS Delta field to determine if the sequence of lost RTP packets contained reference frames or only B-frames. This can be done by comparing the decode and presentation times of the first frame received after the lost sequence against the presentation time of the last reference frame received prior to the lost sequence.
接收机无需使用DTS增量字段。然而，可能的用途包括缓冲区管理和解码前帧的步调。如果RTP数据包丢失，可以使用DTS增量字段来确定丢失的RTP数据包序列是包含参考帧还是仅包含B帧。这可以通过将丢失序列之后接收的第一帧的解码和呈现时间与丢失序列之前接收的最后一个参考帧的呈现时间进行比较来实现。
Knowing if the stream will contain B-pictures may help the receiver allocate resources more efficiently and can reduce delay, as an absence of B-pictures in the stream implies that no reordering of frames will be needed between the decoding process and the display of the decoded frames. This may be important for interactive applications.
知道流是否将包含B图片可以帮助接收机更有效地分配资源并且可以减少延迟，因为流中缺少B图片意味着在解码处理和解码帧的显示之间不需要对帧进行重新排序。这对于交互式应用程序可能很重要。
The receiver SHALL assume that the coded bit stream may contain B-pictures in the following cases:
在以下情况下，接收器应假设编码比特流可能包含B图片：
- Advanced profile: If the value of the "bpic" media type parameter defined in section 6.1 is 1, or if the "bpic" parameter is not specified.
- 高级配置文件：如果第6.1节中定义的“bpic”媒体类型参数的值为1，或者如果未指定“bpic”参数。
- Main profile: If the MAXBFRAMES field in STRUCT_C decoder initialization parameter has a non-zero value. STRUCT_C is conveyed in the "config" media type parameter, which is defined in section 6.1.
- 主配置文件：如果STRUCT_C解码器初始化参数中的MAXBFRAMES字段具有非零值。STRUCT_C在第6.1节中定义的“config”媒体类型参数中传输。
Simple profile does not use B-pictures.
简单配置文件不使用B图片。
The entry-point header contains information that is needed by the decoder to decode the frames in that entry-point segment. This means that in the event of lost RTP packets, the decoder may be unable to decode frames until the next entry-point header is received.
入口点报头包含解码器解码该入口点段中的帧所需的信息。这意味着在丢失RTP分组的情况下，解码器可能无法解码帧，直到接收到下一个入口点报头。
The first frame after an entry-point header is a random access point into the coded bit stream. Simple and Main profiles do not have entry-point headers, so for those profiles, each I-picture is a random access point.
入口点报头之后的第一帧是编码比特流中的随机接入点。简单配置文件和主配置文件没有入口点标题，因此对于这些配置文件，每个I-picture都是一个随机访问点。
To allow the RTP receiver to detect that an RTP packet that was lost contained a random access point, this RTP payload format defines a field called "RA Count". This field is present in every AU, and its value is incremented (modulo 256) for every random access point. For additional details, see the definition of "RA Count" in section 5.2.
为了允许RTP接收器检测丢失的RTP数据包包含随机接入点，此RTP有效负载格式定义了一个称为“RA计数”的字段。该字段存在于每个AU中，对于每个随机接入点，其值递增（模256）。有关更多详细信息，请参见第5.2节中“RA计数”的定义。
To make it easy to determine if an AU contains a random access point, this RTP payload format also defines a bit called the "RA" flag in the AU Control field. This bit is set to 1 only on those AU's that contain a random access point. The RA bit is defined in section 5.3.
为了便于确定AU是否包含随机接入点，此RTP有效负载格式还在AU控制字段中定义了一个称为“RA”标志的位。此位仅在包含随机访问点的AU上设置为1。RA位在第5.3节中定义。
The sequence layer header of Advanced profile may include up to 31 leaky bucket parameter sets for the Hypothetical Reference Decoder (HRD). Each leaky bucket parameter set specifies a possible peak transmission bit rate (HRD_RATE) and a decoder buffer capacity (HRD_BUFFER). See section 3.3 for additional discussion about the HRD.
高级简档的序列层报头可包括用于假想参考解码器（HRD）的多达31个漏桶参数集。每个漏桶参数集指定可能的峰值传输比特率（HRD_率）和解码器缓冲区容量（HRD_缓冲区）。有关人力资源开发的更多讨论，请参见第3.3节。
If the actual peak transmission rate is known by the RTP sender, the RTP sender MAY remove all leaky bucket parameter sets except for the one corresponding to the actual peak transmission rate.
如果RTP发送方知道实际峰值传输速率，则RTP发送方可移除除与实际峰值传输速率对应的参数集之外的所有泄漏桶参数集。
For each leaky bucket parameter set in the sequence layer header, there is also a parameter in the entry-point header that specifies the initial fullness (HRD_FULL) of the leaky bucket.
对于序列层标题中设置的每个漏桶参数，入口点标题中还有一个参数，用于指定漏桶的初始满度（HRD_FULL）。
If the RTP sender has removed any leaky bucket parameter sets from the sequence layer header, then for any removed leaky bucket parameter set, it MUST also remove the corresponding HRD_FULL parameter in the entry-point header.
如果RTP发送方已从序列层标头中删除任何漏桶参数集，则对于任何已删除的漏桶参数集，它还必须删除入口点标头中相应的HRD_FULL参数。
Removing leaky bucket parameter sets, as described above, may significantly reduce the size of the sequence layer headers and the entry-point headers.
如上所述，移除漏桶参数集可显著减小序列层标头和入口点标头的大小。
To improve robustness against loss of RTP packets, it is RECOMMENDED that if the sequence layer header changes, it should be repeated frequently in the bit stream. In this case, it is RECOMMENDED that the number of leaky bucket parameters in the sequence layer header and the entry-point headers be reduced to one, as described in section 4.5. This will help reduce the overhead caused by repeating the sequence layer header.
为了提高对RTP数据包丢失的鲁棒性，建议如果序列层报头发生变化，则应在比特流中频繁重复。在这种情况下，建议将序列层标题和入口点标题中的漏桶参数数量减少到一个，如第4.5节所述。这将有助于减少重复序列层标头所造成的开销。
Any data in the VC-1 bit stream, including repeated copies of the sequence header itself, must be accounted for when computing the leaky bucket parameter for the HRD. See section 3.3 for a discussion about the HRD.
在计算HRD的漏桶参数时，必须考虑VC-1比特流中的任何数据，包括序列头本身的重复副本。有关人力资源开发的讨论，请参见第3.3节。
If the value of TFCNTRFLAG in the sequence layer header is 1, each picture header contains a frame counter field (TFCNTR). Each time the sequence layer header is inserted in the bit stream, the value of this counter MUST be reset.
如果序列层标头中的TFCNTRFLAG值为1，则每个图片标头包含一个帧计数器字段（TFCNTR）。每次序列层头插入位流时，必须重置此计数器的值。
To allow the RTP receiver to detect that an RTP packet that was lost contained a new sequence layer header, the AU Control field defines a bit called the "SL" flag. This bit is toggled when a sequence layer header is transmitted, but only if that header is different from the most recently transmitted sequence layer header. The SL bit is defined in section 5.3.
为了允许RTP接收器检测丢失的RTP数据包包含新的序列层报头，AU控制字段定义了一个称为“SL”标志的位。当传输序列层报头时，该位被切换，但仅当该报头与最近传输的序列层报头不同时。SL位在第5.3节中定义。
When this RTP payload format is used with SDP, the decoder initialization parameters described in section 3.3 MUST be signaled in SDP using the media type parameters specified in section 6.1. Section 6.2 specifies how to map the media type parameters to SDP [5], section 6.3 defines rules specific to the SDP Offer/Answer model, and section 6.4 defines rules for when SDP is used in a declarative style.
当此RTP有效载荷格式与SDP一起使用时，必须使用第6.1节中规定的媒体类型参数在SDP中用信号通知第3.3节中描述的解码器初始化参数。第6.2节规定了如何将媒体类型参数映射到SDP[5]，第6.3节定义了SDP提供/应答模型的特定规则，第6.4节定义了SDP在声明式样式中使用的规则。
When Simple or Main profiles are used, it is not possible to change the decoder initialization parameters through the coded bit stream. Any changes to the decoder initialization parameters would have to be done through out-of-band means, e.g., by a SIP [14] re-invite or similar means that convey an updated session description.
当使用简单配置文件或主配置文件时，不可能通过编码比特流更改解码器初始化参数。解码器初始化参数的任何更改必须通过带外方式完成，例如，通过SIP[14]重新邀请或传达更新的会话描述的类似方式。
When Advanced profile is used, the decoder initialization parameters MAY be changed by inserting a new sequence layer header or an entry-point header in the coded bit stream.
当使用高级简档时，可通过在编码比特流中插入新的序列层报头或入口点报头来改变解码器初始化参数。
The sequence layer header specifies the VC-1 level, the maximum size of the coded frames and optionally also the maximum frame rate. The media type parameters "level", "width", "height", and "framerate" specify upper limits for these parameters. Thus, the sequence layer header MAY specify values that are lower than the values of the media type parameters "level", "width", "height", or "framerate", but the sequence layer header MUST NOT exceed the values of any of these media type parameters.
序列层标头指定VC-1级别、编码帧的最大大小以及可选的最大帧速率。媒体类型参数“级别”、“宽度”、“高度”和“帧率”指定了这些参数的上限。因此，序列层头可以指定低于媒体类型参数“level”、“width”、“height”或“framerate”的值的值，但是序列层头不能超过这些媒体类型参数中的任何一个的值。
In certain applications using Advanced profile, the sequence layer header never changes. This MAY be signaled with the media type parameter "mode=1". (The "mode" parameter is defined in section 6.1.) The "mode=1" parameter serves as a "hint" to the RTP receiver that all sequence layer headers in the bit stream will be identical. If "mode=1" is signaled and a sequence layer header is present in the coded bit stream, then it MUST be identical to the sequence layer header specified by the "config" media type parameter.
在某些使用高级配置文件的应用程序中，序列层标头永远不会更改。这可能通过媒体类型参数“mode=1”发出信号。（第6.1节中定义了“mode”参数。）“mode=1”参数用作RTP接收器的“提示”，表明比特流中的所有序列层头将是相同的。如果发出“mode=1”信号，且编码比特流中存在序列层标头，则该标头必须与“config”媒体类型参数指定的序列层标头相同。
Since the sequence layer header never changes in "mode=1", the RTP sender MAY remove it from the bit stream. Note, however, that if the value of TFCNTRFLAG in the sequence layer header is 1, each picture header contains a frame counter field (TFCNTR). This field is reset each time the sequence layer header occurs in the bit stream. If the RTP sender chooses to remove the sequence layer header, then it MUST ensure that the resulting bit stream is still compliant with the VC-1 specification (e.g., by adjusting the TFCNTR field, if necessary.)
由于序列层报头在“mode=1”中从不改变，因此RTP发送方可以将其从比特流中移除。然而，请注意，如果序列层报头中的TFCNTRFLAG的值为1，则每个图片报头包含一个帧计数器字段（TFCNTR）。每当序列层头出现在比特流中时，该字段被重置。如果RTP发送方选择删除序列层报头，则必须确保生成的比特流仍然符合VC-1规范（例如，如有必要，通过调整TFCNTR字段）
In certain applications using Advanced profile, both the sequence layer header and the entry-point header never change. This MAY be signaled with the media type parameter "mode=3". The same rules apply to "mode=3" as for "mode=1", described in section 4.8. Additionally, if "mode=3" is signaled, then the RTP sender MAY "compress" the coded bit stream by not including sequence layer headers and entry-point headers in the RTP packets.
在某些使用高级配置文件的应用程序中，序列层标头和入口点标头都不会更改。这可以通过媒体类型参数“mode=3”来表示。第4.8节所述的“模式=1”适用于“模式=3”。另外，如果发信号通知“mode＝3”，则RTP发送方可以通过在RTP分组中不包括序列层报头和入口点报头来“压缩”编码比特流。
The RTP receiver MUST "decompress" the coded bit stream by re-inserting the entry-point headers prior to delivering the coded bit stream to the VC-1 decoder. The sequence layer header does not need to be decompressed by the receiver, as it never changes.
在将编码比特流传送到VC-1解码器之前，RTP接收器必须通过重新插入入口点报头来“解压缩”编码比特流。序列层头不需要由接收方解压缩，因为它永远不会改变。
If "mode=3" is signaled and the RTP receiver receives a complete AU or the first fragment of an AU, and the RA bit is set to 1 but the AU does not begin with an entry-point header, then this indicates that the entry-point header has been "compressed". In that case, the RTP receiver MUST insert an entry-point header at the beginning of the AU. When inserting the entry-point header, the RTP receiver MUST use the one that was specified by the "config" media type parameter.
如果发出“mode=3”信号，RTP接收器接收到完整的AU或AU的第一个片段，并且RA位设置为1，但AU不以入口点报头开始，则这表示入口点报头已“压缩”。在这种情况下，RTP接收器必须在AU的开头插入一个入口点头。插入入口点标头时，RTP接收器必须使用“config”媒体类型参数指定的标头。
The format of the RTP header is specified in RFC 3550 [3] and is reprinted in Figure 3 for convenience.
RTP头的格式在RFC 3550[3]中指定，为了方便起见，在图3中重新打印。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550
图3。符合RFC 3550的RTP集管
The fields of the fixed RTP header have their usual meaning, which is defined in RFC 3550 and by the RTP profile in use, with the following additional notes:
固定RTP报头的字段具有其通常含义，RFC 3550和使用中的RTP配置文件对其进行了定义，并附有以下附加说明：
Marker bit (M): 1 bit This bit is set to 1 if the RTP packet contains an Access Unit containing a complete VC-1 frame or the last fragment of a VC-1 frame.
标记位（M）：1位如果RTP数据包包含包含完整VC-1帧或VC-1帧最后一个片段的访问单元，则该位设置为1。
Payload type (PT): 7 bits This document does not assign an RTP payload type for this RTP payload format. The assignment of a payload type has to be performed either through the RTP profile used or in a dynamic way.
有效负载类型（PT）：7位本文档未为此RTP有效负载格式分配RTP有效负载类型。有效负载类型的分配必须通过使用的RTP配置文件或以动态方式执行。
Sequence Number: 16 bits The RTP receiver can use the sequence number field to recover the coded order of the VC-1 frames. A typical VC-1 decoder will require the VC-1 frames to be delivered in coded order. When VC-1 frames have been fragmented across RTP packets, the RTP receiver can use the sequence number field to ensure that no fragment is missing.
序列号：16位RTP接收器可使用序列号字段恢复VC-1帧的编码顺序。典型的VC-1解码器将要求VC-1帧以编码顺序交付。当VC-1帧在RTP数据包中被分段时，RTP接收器可以使用序列号字段来确保没有片段丢失。
Timestamp: 32 bits The RTP timestamp is set to the presentation time of the VC-1 frame in the first Access Unit. A clock rate of 90 kHz MUST be used.
时间戳：32位RTP时间戳设置为第一访问单元中VC-1帧的显示时间。必须使用90 kHz的时钟频率。
The Access Unit header consists of a one-byte AU Control field, the RA Count field, and 3 optional fields. All fields MUST be written in network byte order. The structure of the AU header is illustrated in Figure 4.
访问单元标头由一个单字节AU控制字段、RA计数字段和3个可选字段组成。所有字段必须以网络字节顺序写入。AU头的结构如图4所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Structure of AU header
图4。金头结构
AU Control: 8 bits The usage of the AU Control field is defined in section 5.3.
AU控制：8位AU控制字段的使用在第5.3节中定义。
RA Count: 8 bits Random Access Point Counter. This field is a binary modulo 256 counter. The value of this field MUST be incremented by 1 each time an AU is transmitted where the RA bit in the AU Control field is set to 1. The initial value of this field is undefined and MAY be chosen randomly.
RA计数：8位随机接入点计数器。此字段是一个二进制模256计数器。当AU控制字段中的RA位设置为1时，每次传输AU时，该字段的值必须增加1。此字段的初始值未定义，可以随机选择。
AUP Len: 16 bits Access Unit Payload Length. Specifies the size, in bytes, of the payload of the Access Unit. The field does not include the size of the AU header itself. The field MUST be included in each AU header in an RTP packet, except for the last AU header in the packet. If this field is not included, the payload of the Access Unit SHALL be assumed to extend to the end of the RTP payload.
AUP Len：16位访问单元有效负载长度。指定访问单元有效负载的大小（以字节为单位）。该字段不包括AU标头本身的大小。该字段必须包含在RTP数据包的每个AU报头中，但数据包中的最后一个AU报头除外。如果不包括该字段，则应假定接入单元的有效载荷延伸至RTP有效载荷的末端。
PTS Delta: 32 bits Presentation time delta. Specifies the presentation time of the frame as a 2's complement offset (delta) from the timestamp field in the RTP header of this RTP packet. The PTS Delta field MUST use the same clock rate as the timestamp field in the RTP header.
PTS增量：32位表示时间增量。从该RTP数据包的RTP报头中的时间戳字段将帧的显示时间指定为2的补码偏移量（增量）。PTS增量字段必须使用与RTP报头中的时间戳字段相同的时钟速率。
This field SHOULD NOT be included in the first AU header in the RTP packet, because the RTP timestamp field specifies the presentation time of the frame in the first AU. If this field
此字段不应包含在RTP数据包的第一个AU报头中，因为RTP时间戳字段指定第一个AU中帧的显示时间。如果这个字段
is not included, the presentation time of the frame SHALL be assumed to be specified by the timestamp field in the RTP header.
如果不包括，则应假设帧的显示时间由RTP报头中的时间戳字段指定。
DTS Delta: 32 bits Decode time delta. Specifies the decode time of the frame as a 2's complement offset (delta) between the presentation time and the decode time. Note that if the presentation time is larger than the decode time, this results in a value for the DTS Delta field that is greater than zero. The DTS Delta field MUST use the same clock rate as the timestamp field in the RTP header. If this field is not included, the decode time of the frame SHALL be assumed to be identical to the presentation time of the frame.
DTS增量：32位解码时间增量。将帧的解码时间指定为表示时间和解码时间之间的2补码偏移量（增量）。请注意，如果呈现时间大于解码时间，这将导致DTS Delta字段的值大于零。DTS增量字段必须使用与RTP报头中的时间戳字段相同的时钟速率。如果不包括该字段，则应假定帧的解码时间与帧的呈现时间相同。
The structure of the 8-bit AU Control field is shown in Figure 5.
8位AU控制字段的结构如图5所示。
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field.
图5。AU控制字段的语法。
FRAG: 2 bits Fragmentation Information. This field indicates if the AU payload contains a complete frame or a fragment of a frame. It MUST be set as follows:
碎片：2位碎片信息。此字段指示AU有效负载是否包含完整帧或帧片段。它必须设置如下：
0: The AU payload contains a fragment of a frame other than the first or last fragment. 1: The AU payload contains the first fragment of a frame. 2: The AU payload contains the last fragment of a frame. 3: The AU payload contains a complete frame (not fragmented.)
0:AU有效负载包含帧的片段，而不是第一个或最后一个片段。1:AU有效载荷包含帧的第一个片段。2：AU有效载荷包含帧的最后一个片段。3：AU有效负载包含一个完整的帧（未分段）
RA: 1 bit Random Access Point indicator. This bit MUST be set to 1 if the AU contains a frame that is a random access point. In the case of Simple and Main profiles, any I-picture is a random access point.
RA：1位随机接入点指示器。如果AU包含随机访问点的帧，则该位必须设置为1。在简单和主配置文件的情况下，任何I-picture都是随机访问点。
In the case of Advanced profile, the first frame after an entry-point header is a random access point.
在高级配置文件的情况下，入口点报头之后的第一帧是随机接入点。
If entry-point headers are not transmitted at every random access point, this MUST be indicated using the media type parameter "mode=3".
如果未在每个随机接入点传输入口点报头，则必须使用媒体类型参数“mode=3”来指示。
SL: 1 bit Sequence Layer Counter. This bit MUST be toggled, i.e., changed from 0 to 1 or from 1 to 0, if the AU contains a sequence layer header and if it is different from the most recently transmitted sequence layer header. Otherwise, the value of this bit must be identical to the value of the SL bit in the previous AU.
SL：1位序列层计数器。如果AU包含序列层报头并且它与最近传输的序列层报头不同，则必须切换该位，即从0更改为1或从1更改为0。否则，该位的值必须与前一个AU中SL位的值相同。
The initial value of this bit is undefined and MAY be chosen randomly.
该位的初始值未定义，可以随机选择。
The bit MUST be 0 for Simple and Main profile bit streams or if the sequence layer header never changes.
对于简单和主配置文件位流，或者如果序列层标头从未更改，则位必须为0。
LP: 1 bit Length Present. This bit MUST be set to 1 if the AU header includes the AUP Len field.
LP：存在1位长度。如果AU标头包括AUP Len字段，则该位必须设置为1。
PT: 1 bit PTS Delta Present. This bit MUST be set to 1 if the AU header includes the PTS Delta field.
PT：存在1位PTS增量。如果AU标头包含PTS增量字段，则该位必须设置为1。
DT: 1 bit DTS Delta Present. This bit MUST be set to 1 if the AU header includes the DTS Delta field.
DT：存在1位DTS增量。如果AU标头包含DTS增量字段，则该位必须设置为1。
R: 1 bit Reserved. This bit MUST be set to 0 and MUST be ignored by receivers.
R：保留1位。此位必须设置为0，并且必须被接收器忽略。
This registration uses the template defined in RFC 4288 [7] and follows RFC 3555 [8].
此注册使用RFC 4288[7]中定义的模板，并遵循RFC 3555[8]。
Type name: video
类型名称：视频
Subtype name: vc1
子类型名称：vc1
Required parameters:
所需参数：
profile: The value is an integer identifying the VC-1 profile. The following values are defined:
profile：该值是标识VC-1配置文件的整数。定义了以下值：
0: Simple profile 1: Main profile 3: Advanced profile
0:简单配置文件1:主配置文件3:高级配置文件
If the profile parameter is used to indicate properties of a coded bit stream, it indicates the VC-1 profile that a decoder has to support when it decodes the bit stream.
如果profile参数用于指示编码比特流的属性，则它指示解码器解码比特流时必须支持的VC-1配置文件。
If the profile parameter is used for capability exchange or in a session setup procedure, it indicates the VC-1 profile that the codec supports.
如果profile参数用于功能交换或会话设置过程，则表示编解码器支持的VC-1配置文件。
level: The value is an integer that specifies the level of the VC-1 profile.
级别：该值是一个整数，用于指定VC-1配置文件的级别。
For Advanced profile, valid values are 0 through 4, which correspond to levels L0 through L4, respectively. For Simple and Main profiles, the following values are defined:
对于高级配置文件，有效值为0到4，分别对应于级别L0到L4。对于简单配置文件和主配置文件，定义了以下值：
1: Low Level 2: Medium Level 3: High Level (only valid for Main profile)
1：低级2：中级3：高级（仅适用于主剖面）
If the level parameter is used to indicate properties of a coded bit stream, it indicates the highest level of the VC-1 profile that a decoder has to support when it decodes the bit stream. Note that support for a level implies support for all numerically lower levels of the given profile.
如果level参数用于指示编码比特流的属性，则它指示解码器解码比特流时必须支持的VC-1配置文件的最高级别。请注意，对标高的支持意味着对给定纵断面的所有数值较低标高的支持。
If the level parameter is used for capability exchange or in a session setup procedure, it indicates the highest level of the VC-1 profile that the codec supports. See section 6.3 of RFC 4425 for specific rules for how this parameter is used with the SDP Offer/Answer model.
如果级别参数用于功能交换或会话设置过程，则表示编解码器支持的VC-1配置文件的最高级别。有关此参数如何与SDP报价/应答模型一起使用的具体规则，请参见RFC 4425第6.3节。
Optional parameters:
可选参数：
config: The value is a base16 [6] (hexadecimal) representation of an octet string that expresses the decoder initialization parameters. Decoder initialization parameters are mapped onto the base16 octet string in an MSB-first basis. The first bit of the decoder initialization parameters MUST be located at the MSB of the first octet. If the decoder initialization parameters are not multiples of 8 bits, up to 7 zero-valued padding bits MUST be added in the last octet to achieve octet alignment.
配置：该值是表示解码器初始化参数的八位字节字符串的base16[6]（十六进制）表示形式。解码器初始化参数以MSB优先的方式映射到base16八位字节字符串。解码器初始化参数的第一位必须位于第一个八位组的MSB。如果解码器初始化参数不是8位的倍数，则必须在最后一个八位字节中添加多达7个零值填充位，以实现八位字节对齐。
For Simple and Main profiles, the decoder initialization parameters are STRUCT_C, as defined in Annex J of SMPTE 421M [1].
对于简单和主要配置文件，解码器初始化参数为STRUCT_C，如SMPTE 421M[1]附录J中所定义。
For Advanced profile, the decoder initialization parameters are a sequence layer header directly followed by an entry-point header. The two headers MUST be in EBDU format, meaning that they must include their Start Codes and must use the encapsulation method defined in Annex E of SMPTE 421M [1].
对于高级配置文件，解码器初始化参数是一个序列层头，后跟一个入口点头。这两个标头必须采用EBDU格式，这意味着它们必须包含其起始代码，并且必须使用SMPTE 421M[1]附录E中定义的封装方法。
width: The value is an integer greater than zero, specifying the maximum horizontal size of the coded frames, in luma samples (pixels in the luma picture).
宽度：该值是一个大于零的整数，指定编码帧的最大水平大小，单位为luma样本（luma图片中的像素）。
For Simple and Main profiles, the value SHALL be identical to the actual horizontal size of the coded frames.
对于简单剖面和主要剖面，该值应与编码框架的实际水平尺寸相同。
For Advanced profile, the value SHALL be greater than, or equal to, the largest horizontal size of the coded frames.
对于高级剖面，该值应大于或等于编码帧的最大水平尺寸。
If this parameter is not specified, it defaults to the maximum horizontal size allowed by the specified profile and level.
如果未指定此参数，则默认为指定纵断面和标高允许的最大水平尺寸。
height: The value is an integer greater than zero, specifying the maximum vertical size of the coded frames, in luma samples (pixels in a progressively coded luma picture).
高度：该值是一个大于零的整数，指定编码帧的最大垂直大小，单位为luma样本（渐进编码luma图片中的像素）。
For Simple and Main profiles, the value SHALL be identical to the actual vertical size of the coded frames.
对于简单剖面和主要剖面，该值应与编码框架的实际垂直尺寸相同。
For Advanced profile, the value SHALL be greater than, or equal to, the largest vertical size of the coded frames.
对于高级剖面，该值应大于或等于编码帧的最大垂直尺寸。
If this parameter is not specified, it defaults to the maximum vertical size allowed by the specified profile and level.
如果未指定此参数，则默认为指定纵断面和标高允许的最大垂直尺寸。
bitrate: The value is an integer greater than zero, specifying the peak transmission rate of the coded bit stream in bits per second. The number does not include the overhead caused by RTP encapsulation, i.e., it does not include the AU headers, or any of the RTP, UDP, or IP headers.
比特率：该值是大于零的整数，指定编码比特流的峰值传输速率，单位为比特/秒。该数字不包括RTP封装造成的开销，即不包括AU头或任何RTP、UDP或IP头。
If this parameter is not specified, it defaults to the maximum bit rate allowed by the specified profile and level. See the values for "RMax" in Annex D of SMPTE 421M [1].
如果未指定此参数，则默认为指定配置文件和级别允许的最大比特率。参见SMPTE 421M[1]附录D中的“RMax”值。
buffer: The value is an integer specifying the leaky bucket size, B, in milliseconds, required to contain a stream transmitted at the transmission rate specified by the bitrate parameter. This parameter is defined in the hypothetical reference decoder model for VC-1, in Annex C of SMPTE 421M [1].
buffer: The value is an integer specifying the leaky bucket size, B, in milliseconds, required to contain a stream transmitted at the transmission rate specified by the bitrate parameter. This parameter is defined in the hypothetical reference decoder model for VC-1, in Annex C of SMPTE 421M [1].translate error, please retry
Note that this parameter relates to the codec bit stream only, and does not account for any buffering time that may be required to compensate for jitter in the network.
注意，该参数仅与编解码器比特流相关，并且不考虑补偿网络中的抖动所需的任何缓冲时间。
If this parameter is not specified, it defaults to the maximum buffer size allowed by the specified profile and level. See the values for "BMax" and "RMax" in Annex D of SMPTE 421M [1].
如果未指定此参数，则默认为指定配置文件和级别允许的最大缓冲区大小。参见SMPTE 421M[1]附录D中的“BMax”和“RMax”值。
framerate: The value is an integer greater than zero, specifying the maximum number of frames per second in the coded bit stream, multiplied by 1000 and rounded to the nearest integer value. For example, 30000/1001 (approximately 29.97) frames per second is represented as 29970.
帧速率：该值是大于零的整数，指定编码比特流中每秒的最大帧数，乘以1000并四舍五入到最接近的整数值。例如，每秒30000/1001（约29.97）帧表示为29970。
This parameter can be used to control resource allocation at the receiver. For example, a receiver may choose to perform additional post-processing on decoded frames only if the frame rate is expected to be low. The parameter MUST NOT be used for pacing of the rendering process, since the actual frame rate may differ from the specified value.
此参数可用于控制接收器处的资源分配。例如，接收机可以选择仅在预期帧速率低的情况下对解码帧执行附加后处理。由于实际帧速率可能与指定值不同，因此该参数不得用于渲染过程的调整。
If the parameter is not specified, it defaults to the maximum frame rate allowed by the specified profile and level.
如果未指定参数，则默认为指定配置文件和级别允许的最大帧速率。
bpic: This parameter signals that B- and BI-pictures may be present when Advanced profile is used. If this parameter is present, and B- or BI-pictures may be present in the coded bit stream, this parameter MUST be equal to 1.
bpic：此参数表示在使用高级配置文件时可能存在B和BI图片。如果存在此参数，并且编码比特流中可能存在B或BI图片，则此参数必须等于1。
A value of 0 indicates that B- and BI-pictures SHALL NOT be present in the coded bit stream, even if the sequence layer header changes. Inclusion of this parameter with a value of 0 is RECOMMENDED, if neither B- nor BI-pictures are included in the coded bit stream.
值为0表示编码比特流中不应存在B-和BI图片，即使序列层标头发生变化。如果编码比特流中既不包含B图片，也不包含BI图片，则建议将此参数的值包含为0。
This parameter MUST NOT be used with Simple and Main profiles. For Main profile, the presence of B- and BI-pictures is indicated by the MAXBFRAMES field in STRUCT_C decoder initialization parameter.
此参数不得用于简单配置文件和主配置文件。对于主配置文件，存在B和BI图片由STRUCT_C解码器初始化参数中的MAXBFRAMES字段指示。
For Advanced profile, if this parameter is not specified, a value of 1 SHALL be assumed.
对于高级外形，如果未指定此参数，则应假定值为1。
mode: The value is an integer specifying the use of the sequence layer header and the entry-point header. This parameter is only defined for Advanced profile. The following values are defined:
模式：该值是一个整数，指定序列层标头和入口点标头的使用。此参数仅为高级配置文件定义。定义了以下值：
0: Both the sequence layer header and the entry-point header may change, and changed headers will be included in the RTP packets. 1: The sequence layer header specified in the config parameter never changes. The rules in section 4.8 of RFC 4425 MUST be followed. 3: The sequence layer header and the entry-point header specified in the config parameter never change. The rules in section 4.9 of RFC 4425 MUST be followed.
0：序列层报头和入口点报头都可能更改，更改的报头将包含在RTP数据包中。1:配置参数中指定的序列层标头永远不会更改。必须遵守RFC 4425第4.8节中的规则。3：配置参数中指定的序列层标头和入口点标头永远不会更改。必须遵守RFC 4425第4.9节中的规则。
If the mode parameter is not specified, a value of 0 SHALL be assumed. The mode parameter SHOULD be specified if modes 1 or 3 apply to the VC-1 bit stream.
如果未规定模式参数，则应假定值为0。如果模式1或3适用于VC-1比特流，则应指定模式参数。
max-width, max-height, max-bitrate, max-buffer, max-framerate: These parameters are defined for use in a capability exchange procedure. The parameters do not signal properties of the coded bit stream, but rather upper limits or
最大宽度、最大高度、最大比特率、最大缓冲区、最大帧速率：这些参数定义用于功能交换过程。这些参数并不表示编码比特流的属性，而是表示上限或
preferred values for the "width", "height", "bitrate", "buffer", and "framerate" parameters. Section 6.3 of RFC 4425 provides specific rules for how these parameters are used with the SDP Offer/Answer model.
“宽度”、“高度”、“比特率”、“缓冲区”和“帧率”参数的首选值。RFC 4425第6.3节提供了如何将这些参数用于SDP报价/应答模型的具体规则。
Receivers that signal support for a given profile and level MUST support the maximum values for these parameters for that profile and level. For example, a receiver that indicates support for Main profile, Low level, must support a width of 352 luma samples and a height of 288 luma samples, even if this requires scaling the image to fit the resolution of a smaller display device.
信号支持给定轮廓和电平的接收器必须支持该轮廓和电平的这些参数的最大值。例如，指示支持主轮廓（低电平）的接收器必须支持352个亮度样本的宽度和288个亮度样本的高度，即使这需要缩放图像以适应较小显示设备的分辨率。
A receiver MAY use any of the max-width, max-height, max-bitrate, max-buffer, and max-framerate parameters to indicate preferred capabilities. For example, a receiver may choose to specify values for max-width and max-height that match the resolution of its display device, since a bit stream encoded using those parameters would not need to be rescaled.
接收机可以使用最大宽度、最大高度、最大比特率、最大缓冲区和最大帧率参数中的任何一个来指示首选功能。例如，接收机可以选择指定与其显示设备的分辨率匹配的最大宽度和最大高度的值，因为使用这些参数编码的比特流不需要重新缩放。
If any of the max-width, max-height, max-bitrate, max-buffer, and max-framerate parameters signal a capability that is less than the required capabilities of the signaled profile and level, then the parameter SHALL be interpreted as a preferred value for that capability.
如果“最大宽度”、“最大高度”、“最大比特率”、“最大缓冲区”和“最大帧速率”参数中的任何一个表示某个能力小于所发信号的配置文件和级别的所需能力，则该参数应解释为该能力的首选值。
Any of the parameters MAY also be used to signal capabilities that exceed the required capabilities of the signaled profile and level. In that case, the parameter SHALL be interpreted as the maximum value that can be supported for that capability.
任何参数也可用于表示超出信号配置文件和级别所需能力的能力。在这种情况下，该参数应解释为该能力可支持的最大值。
When more than one parameter from the set (max-width, max-height, max-bitrate, max-buffer, and max-framerate) is present, all signaled capabilities MUST be supported simultaneously.
当集合中存在多个参数（最大宽度、最大高度、最大比特率、最大缓冲区和最大帧率）时，必须同时支持所有信号功能。
A sender or receiver MUST NOT use these parameters to signal capabilities that meet the requirements of a higher level of the VC-1 profile than that specified in the "level" parameter, even if the sender or receiver can support all the properties of the higher level, except if specifying a higher level is not allowed due to other restrictions. As an example of such a restriction, in the SDP Offer/Answer model, the value of the level parameter that can be used in an Answer is limited by what was specified in the Offer.
发送方或接收方不得使用这些参数来表示满足VC-1配置文件中高于“级别”参数中规定的级别要求的功能，即使发送方或接收方可以支持更高级别的所有属性，但由于其他限制而不允许指定更高级别的功能除外。作为此类限制的一个示例，在SDP报价/应答模型中，可在应答中使用的级别参数的值受报价中指定的限制。
max-width: The value is an integer greater than zero, specifying a horizontal size for the coded frames, in luma samples (pixels in the luma picture). If the value is less than the maximum horizontal size allowed by the profile and level, then the value specifies the preferred horizontal size. Otherwise, it specifies the maximum horizontal size that is supported.
最大宽度：该值是大于零的整数，指定编码帧的水平大小，单位为luma样本（luma图片中的像素）。如果该值小于纵断面和标高允许的最大水平尺寸，则该值指定首选水平尺寸。否则，它将指定支持的最大水平大小。
If this parameter is not specified, it defaults to the maximum horizontal size allowed by the specified profile and level.
如果未指定此参数，则默认为指定纵断面和标高允许的最大水平尺寸。
max-height: The value is an integer greater than zero, specifying a vertical size for the coded frames, in luma samples (pixels in a progressively coded luma picture). If the value is less than the maximum vertical size allowed by the profile and level, then the value specifies the preferred vertical size. Otherwise, it specifies the maximum vertical size that is supported.
最大高度：该值是一个大于零的整数，指定编码帧的垂直大小，单位为luma样本（渐进编码luma图片中的像素）。如果该值小于纵断面和标高允许的最大垂直尺寸，则该值指定首选垂直尺寸。否则，它将指定支持的最大垂直大小。
If this parameter is not specified, it defaults to the maximum vertical size allowed by the specified profile and level.
如果未指定此参数，则默认为指定纵断面和标高允许的最大垂直尺寸。
max-bitrate: The value is an integer greater than zero, specifying a peak transmission rate for the coded bit stream in bits per second. The number does not include the overhead caused by RTP encapsulation, i.e., it does not include the AU headers, or any of the RTP, UDP, or IP headers.
最大比特率：该值是一个大于零的整数，指定编码比特流的峰值传输速率（以比特/秒为单位）。该数字不包括RTP封装造成的开销，即不包括AU头或任何RTP、UDP或IP头。
If the value is less than the maximum bit rate allowed by the profile and level, then the value specifies the preferred bit rate. Otherwise, it specifies the maximum bit rate that is supported.
如果该值小于配置文件和级别允许的最大比特率，则该值指定首选比特率。否则，它将指定支持的最大比特率。
If this parameter is not specified, it defaults to the maximum bit rate allowed by the specified profile and level. See the values for "RMax" in Annex D of SMPTE 421M [1].
如果未指定此参数，则默认为指定配置文件和级别允许的最大比特率。参见SMPTE 421M[1]附录D中的“RMax”值。
max-buffer: The value is an integer specifying a leaky bucket size, B, in milliseconds, required to contain a stream transmitted at the transmission rate specified by the max-bitrate
max buffer（最大缓冲区）：该值是一个整数，指定泄漏存储桶大小B（以毫秒为单位），以包含以最大比特率指定的传输速率传输的流
parameter. This parameter is defined in the hypothetical reference decoder model for VC-1, in Annex C of SMPTE 421M [1].
参数该参数在SMPTE 421M[1]附录C中VC-1的假设参考解码器模型中定义。
Note that this parameter relates to the codec bit stream only and does not account for any buffering time that may be required to compensate for jitter in the network.
注意，该参数仅与编解码器比特流相关，不考虑补偿网络中的抖动所需的任何缓冲时间。
If the value is less than the maximum leaky bucket size allowed by the max-bitrate parameter and the profile and level, then the value specifies the preferred leaky bucket size. Otherwise, it specifies the maximum leaky bucket size that is supported for the bit rate specified by the max-bitrate parameter.
如果该值小于最大比特率参数以及配置文件和级别允许的最大泄漏桶大小，则该值指定首选泄漏桶大小。否则，它将指定最大比特率参数指定的比特率所支持的最大漏桶大小。
If this parameter is not specified, it defaults to the maximum buffer size allowed by the specified profile and level. See the values for "BMax" and "RMax" in Annex D of SMPTE 421M [1].
如果未指定此参数，则默认为指定配置文件和级别允许的最大缓冲区大小。参见SMPTE 421M[1]附录D中的“BMax”和“RMax”值。
max-framerate: The value is an integer greater than zero, specifying a number of frames per second for the coded bit stream. The value is the frame rate multiplied by 1000 and rounded to the nearest integer value. For example, 30000/1001 (approximately 29.97) frames per second is represented as 29970.
最大帧速率：该值是大于零的整数，指定编码比特流每秒的帧数。该值是帧速率乘以1000并四舍五入到最接近的整数值。例如，每秒30000/1001（约29.97）帧表示为29970。
If the value is less than the maximum frame rate allowed by the profile and level, then the value specifies the preferred frame rate. Otherwise, it specifies the maximum frame rate that is supported.
如果该值小于配置文件和级别允许的最大帧速率，则该值指定首选帧速率。否则，它将指定支持的最大帧速率。
If the parameter is not specified, it defaults to the maximum frame rate allowed by the specified profile and level.
如果未指定参数，则默认为指定配置文件和级别允许的最大帧速率。
Encoding considerations: This media type is framed and contains binary data.
编码注意事项：此媒体类型是框架式的，包含二进制数据。
Security considerations: See Section 7 of RFC 4425.
安全注意事项：见RFC 4425第7节。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: RFC 4425.
已发布规范：RFC4425。
Applications that use this media type: Multimedia streaming and conferencing tools.
使用此媒体类型的应用程序：多媒体流媒体和会议工具。
Additional Information: None.
其他信息：无。
Person & email address to contact for further information: Anders Klemets <anderskl@microsoft.com> IETF AVT working group.
联系人和电子邮件地址，以获取更多信息：Anders Klemets<anderskl@microsoft.com>IETF AVT工作组。
Intended Usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing; therefore, it is only defined for transfer via RTP [3].
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP传输[3]。
Authors: Anders Klemets
作者：Anders Klemets
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4]. If SDP is used to specify sessions using this payload format, the mapping is done as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[4]中的字段具有特定映射。如果使用SDP指定使用此有效负载格式的会话，则映射如下所示：
o The media name in the "m=" line of SDP MUST be video (the type name).
o SDP的“m=”行中的媒体名称必须是视频（类型名称）。
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the subtype name).
o SDP的“a=rtpmap”行中的编码名称必须是vc1（子类型名称）。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o “a=rtpmap”行中的时钟频率必须为90000。
o The REQUIRED parameters "profile" and "level" MUST be included in the "a=fmtp" line of SDP.
o SDP的“a=fmtp”行中必须包含所需的参数“概要”和“级别”。
These parameters are expressed in the form of a semicolon separated list of parameter=value pairs.
这些参数以分号分隔的参数=值对列表的形式表示。
o The OPTIONAL parameters "config", "width", "height", "bitrate", "buffer", "framerate", "bpic", "mode", "max-width", "max-height", "max-bitrate", "max-buffer", and "max-framerate", when present, MUST be included in the "a=fmtp" line of SDP.
o 可选参数“配置”、“宽度”、“高度”、“比特率”、“缓冲区”、“帧速率”、“bpic”、“模式”、“最大宽度”、“最大高度”、“最大比特率”、“最大缓冲区”和“最大帧速率”（如果存在）必须包含在SDP的“a=fmtp”行中。
These parameters are expressed in the form of a semicolon separated list of parameter=value pairs:
这些参数以分号分隔的参数=值对列表的形式表示：
a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>]
a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>]
o Any unknown parameters to the device that uses the SDP MUST be ignored. For example, parameters defined in later specifications MAY be copied into the SDP and MUST be ignored by receivers that do not understand them.
o 必须忽略使用SDP的设备的任何未知参数。例如，稍后规范中定义的参数可能会复制到SDP中，不理解这些参数的接收器必须忽略这些参数。
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5] for negotiation for unicast usage, the following rules and limitations apply:
当VC-1通过RTP在提供/应答模型[5]中使用SDP提供，以协商单播使用时，以下规则和限制适用：
o The "profile" parameter MUST be used symmetrically, i.e., the answerer MUST either maintain the parameter or remove the media format (payload type) completely if the offered VC-1 profile is not supported.
o “配置文件”参数必须对称使用，即如果不支持提供的VC-1配置文件，应答者必须保留该参数或完全删除媒体格式（有效负载类型）。
o The "level" parameter specifies the highest level of the VC-1 profile supported by the codec.
o “level”参数指定编解码器支持的VC-1配置文件的最高级别。
The answerer MUST NOT specify a numerically higher level in the answer than that specified in the offer. The answerer MAY specify a level that is lower than that specified in the offer, i.e., the level parameter can be "downgraded".
回答者不得在回答中指定比报价中指定的数字更高的级别。回答者可以指定低于报价中规定的级别，即级别参数可以“降级”。
If the offer specifies the sendrecv or sendonly direction attribute and the answer downgrades the level parameter, this may require a new offer to specify an updated "config" parameter. If the "config" parameter cannot be used with the level specified in the answer, then the offerer MUST initiate another Offer/Answer round or not use media format (payload type).
如果报价指定sendrecv或sendonly方向属性，且答案降低了级别参数，则可能需要新报价指定更新的“配置”参数。如果“配置”参数不能与答案中指定的级别一起使用，则报价人必须发起另一轮报价/应答，或者不使用媒体格式（有效负载类型）。
o The parameters "config", "bpic", "width", "height", "framerate", "bitrate", "buffer", and "mode", describe the properties of the VC-1 bit stream that the offerer or answerer is sending for this media format configuration.
o 参数“config”、“bpic”、“width”、“height”、“framerate”、“bitrate”、“buffer”和“mode”描述了提供方或应答方为该媒体格式配置发送的VC-1比特流的属性。
In the case of unicast usage and when the direction attribute in the offer or answer is recvonly, the interpretation of these parameters is undefined and they MUST NOT be used.
在单播使用的情况下，当提供或应答中的方向属性为RecvoOnly时，这些参数的解释未定义，不得使用。
o The parameters "config", "width", "height", "bitrate", and "buffer" MUST be specified when the direction attribute is sendrecv or sendonly.
o 当方向属性为sendrecv或sendonly时，必须指定参数“配置”、“宽度”、“高度”、“比特率”和“缓冲区”。
o The parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MAY be specified in an offer or an answer, and their interpretation is as follows:
o 参数“最大宽度”、“最大高度”、“最大帧率”、“最大比特率”和“最大缓冲区”可在报价或答复中指定，其解释如下：
When the direction attribute is sendonly, the parameters describe the limits of the VC-1 bit stream that the sender is capable of producing for the given profile and level, and for any lower level of the same profile.
当方向属性为sendonly时，参数描述发送方能够为给定配置文件和级别以及相同配置文件的任何较低级别生成的VC-1比特流的限制。
When the direction attribute is recvonly or sendrecv, the parameters describe properties of the receiver implementation. If the value of a property is less than that allowed by the level of the VC-1 profile, then it SHALL be interpreted as a preferred value and the sender's VC-1 bit stream SHOULD NOT exceed it. If the value of a property is greater than what is allowed by the level of the VC-1 profile, then it SHALL be interpreted as the upper limit of the value that the receiver accepts for the given profile and level, and for any lower level of the same profile.
当方向属性为RECVOLY或sendrecv时，参数描述接收器实现的属性。如果属性值小于VC-1配置文件级别允许的值，则应将其解释为首选值，发送方的VC-1比特流不应超过该值。如果某个属性的值大于VC-1配置文件的级别所允许的值，则应将其解释为接收方接受的给定配置文件和级别以及同一配置文件的任何较低级别的值的上限。
For example, if a recvonly or sendrecv offer specifies "profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a suggested bit rate, because all receiver implementations of Simple profile, Low level, are required to support bit rates of up to 96 kbps. Assuming that the offer is accepted, the answerer should specify "bitrate=48000" in the answer, but any value up to 96000 is allowed. But if the offer specifies "max-bitrate=200000", this means that the receiver implementation supports a maximum of 200 kbps for the given profile and level (or lower level). In this case, the answerer is allowed to answer with a bitrate parameter of up to 200000.
例如，如果RECVOLY或sendrecv提供指定“profile=0；level=1；max bit rate=48000”，那么48 kbps仅仅是一个建议的比特率，因为所有简单profile、Low-level的接收器实现都需要支持高达96 kbps的比特率。假设要约被接受，应答者应在回答中指定“比特率=48000”，但允许任何高达96000的值。但是，如果提供指定“最大比特率=200000”，这意味着接收器实现对给定的配置文件和级别（或更低级别）支持最大200kbps。在这种情况下，允许应答者使用高达200000的比特率参数进行应答。
o If an offerer wishes to have non-symmetrical capabilities between sending and receiving, e.g., use different levels in each direction, then the offerer has to offer different RTP sessions. This can be done by specifying different media lines declared as "recvonly" and "sendonly", respectively.
o 如果发盘方希望在发送和接收之间具有非对称能力，例如，在每个方向使用不同的级别，那么发盘方必须提供不同的RTP会话。这可以通过分别指定声明为“RecvoOnly”和“sendonly”的不同媒体行来实现。
For streams being delivered over multicast, the following rules apply in addition:
对于通过多播传送的流，还应适用以下规则：
o The "level" parameter specifies the highest level of the VC-1 profile used by the participants in the multicast session. The value of this parameter MUST NOT be changed by the answerer. Thus, a payload type can be either accepted unaltered or removed.
o “level”参数指定多播会话中参与者使用的VC-1配置文件的最高级别。回答者不得更改此参数的值。因此，有效负载类型可以不改变地接受，也可以删除。
o The parameters "config", "bpic", "width", "height", "framerate", "bitrate", "buffer", and "mode", specify properties of the VC-1 bit stream that will be sent and/or received on the multicast session. The parameters MAY be specified, even if the direction attribute is recvonly.
o 参数“config”、“bpic”、“width”、“height”、“framerate”、“bitrate”、“buffer”和“mode”指定将在多播会话上发送和/或接收的VC-1比特流的属性。即使方向属性为recvonly，也可以指定参数。
The values of these parameters MUST NOT be changed by the answerer. Thus, a payload type can be either accepted unaltered or removed.
回答者不得更改这些参数的值。因此，有效负载类型可以不改变地接受，也可以删除。
o The values of the parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MUST be supported by the answerer for all streams declared as sendrecv or recvonly. Otherwise, one of the following actions MUST be performed: the media format is removed or the session is rejected.
o 应答器必须为所有声明为sendrecv或RecvoOnly的流支持参数“最大宽度”、“最大高度”、“最大帧率”、“最大比特率”和“最大缓冲区”的值。否则，必须执行以下操作之一：删除媒体格式或拒绝会话。
When VC-1 is offered over RTP using SDP in a declarative style, as in RTSP [12] or SAP [13], the following rules and limitations apply:
当VC-1通过RTP以声明式方式使用SDP提供时，如RTSP[12]或SAP[13]，以下规则和限制适用：
o The parameters "profile" and "level" indicate only the properties of the coded bit stream. They do not imply a limit on capabilities supported by the sender.
o 参数“profile”和“level”仅表示编码比特流的属性。它们并不意味着对发送方支持的功能有限制。
o The parameters "config", "width", "height", "bitrate", and "buffer" MUST be specified.
o 必须指定参数“配置”、“宽度”、“高度”、“比特率”和“缓冲区”。
o The parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MUST NOT be used.
o 不得使用参数“最大宽度”、“最大高度”、“最大帧率”、“最大比特率”和“最大缓冲区”。
An example of media representation in SDP is as follows (Simple profile, Medium level):
SDP中的媒体表示示例如下（简单配置文件，中等级别）：
m=video 49170 RTP/AVP 98
a=rtpmap:98 vc1/90000
a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000;
bitrate=384000;buffer=2000;config=4e291800
m=video 49170 RTP/AVP 98
a=rtpmap:98 vc1/90000
a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000;
bitrate=384000;buffer=2000;config=4e291800
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [4], and in any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption; for example, through the application of SRTP [11].
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[4]和任何适当RTP配置文件中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的；例如，通过应用SRTP[11]。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological RTP packets into the stream that are complex to decode and that cause the receiver to be overloaded. VC-1 is particularly vulnerable to such attacks, because it is possible for an attacker to generate RTP packets containing frames that affect the decoding process of many future frames. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; for example, with SRTP [11].
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以将病态RTP数据包注入流中，这些数据包很难解码，并且会导致接收器过载。VC-1特别容易受到此类攻击，因为攻击者可能生成包含帧的RTP数据包，这些帧会影响许多未来帧的解码过程。因此，建议使用至少RTP分组的数据源认证和数据完整性保护；例如，使用SRTP[11]。
Note that the appropriate mechanism to ensure confidentiality and integrity of RTP packets and their payloads is dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
请注意，确保RTP数据包及其有效负载的机密性和完整性的适当机制取决于应用程序以及所采用的传输和信令协议。因此，尽管上面给出了SRTP作为示例，但存在其他可能的选择。
VC-1 bit streams can carry user-data, such as closed captioning information and content meta-data. The VC-1 specification does not define how to interpret user-data. Identifiers for user-data are required to be registered with SMPTE. It is conceivable for types of user-data to be defined to include programmatic content, such as scripts or commands that would be executed by the receiver. Depending on the type of user-data, it might be possible for a sender to generate user-data in a non-compliant manner to crash the receiver or make it temporarily unavailable. Senders that transport VC-1 bit streams SHOULD ensure that the user-data is compliant with the specification registered with SMPTE (see Annex F of [1].) Receivers SHOULD prevent malfunction in case of non-compliant user-data.
VC-1比特流可以携带用户数据，例如闭路字幕信息和内容元数据。VC-1规范没有定义如何解释用户数据。用户数据的标识符需要向SMPTE注册。可以想象，将用户数据的类型定义为包括编程内容，例如将由接收器执行的脚本或命令。根据用户数据的类型，发送方可能以不兼容的方式生成用户数据，从而使接收方崩溃或使其暂时不可用。传输VC-1比特流的发送方应确保用户数据符合SMPTE注册的规范（见[1]的附录F）。如果用户数据不符合规范，接收方应防止出现故障。
It is important to note that VC-1 streams can have very high bandwidth requirements (up to 135 Mbps for high-definition video). This causes a potential for denial-of-service if transmitted onto many Internet paths. Therefore, users of this payload format MUST comply with the congestion control requirements described in section 8.
需要注意的是，VC-1流可能具有非常高的带宽要求（高清晰度视频高达135 Mbps）。如果传输到多个Internet路径，则可能会导致拒绝服务。因此，这种有效载荷格式的用户必须遵守第8节中描述的拥塞控制要求。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3], and with any applicable RTP profile; e.g., RFC 3551 [15].
RTP的拥塞控制应根据RFC 3550[3]和任何适用的RTP配置文件使用；e、 g.，RFC 3551[15]。
If best-effort service is being used, users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
如果正在使用尽力而为服务，则此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流能够达到在合理时间尺度上测量的平均吞吐量，即不小于RTP流所达到的平均吞吐量，则认为丢包是可接受的。可以通过实现拥塞控制机制来适应传输速率，或者如果丢失率高到不可接受的程度，则通过安排接收机离开会话来满足该条件。
The bit rate adaptation necessary for obeying the congestion control principle is easily achievable when real-time encoding is used. When pre-encoded content is being transmitted, bandwidth adaptation requires one or more of the following:
当使用实时编码时，遵守拥塞控制原则所需的比特率自适应很容易实现。传输预编码内容时，带宽自适应需要以下一项或多项：
- The availability of more than one coded representation of the same content at different bit rates. The switching between the different representations can normally be performed in the same RTP session by switching streams at random access point boundaries.
- 同一内容在不同比特率下的多个编码表示的可用性。通过在随机接入点边界处切换流，通常可以在同一RTP会话中执行不同表示之间的切换。
- The existence of non-reference frames (e.g., B-frames) in the bit stream. Non-reference frames can be discarded by the transmitter prior to encapsulation in RTP.
- 在比特流中存在非参考帧（例如，B帧）。在RTP封装之前，发射机可以丢弃非参考帧。
Only when non-downgradable parameters (such as the VC-1 "profile" parameter) are required to be changed does it become necessary to terminate and re-start the media stream. This may be accomplished by using a different RTP payload type.
只有当需要更改不可降级的参数（如VC-1“profile”参数）时，才有必要终止并重新启动媒体流。这可以通过使用不同的RTP有效负载类型来实现。
Regardless of the method used for bandwidth adaptation, the resulting bit stream MUST be compliant with the VC-1 specification [1]. For example, if non-reference frames are discarded, then the FRMCNT syntax element (Simple and Main profile frames only) and the optional TFCNTR syntax element (Advanced profile frames only) must increment as if no frames had been discarded. Because the TFCNTR syntax element counts the frames in the display order, which is different from the order in which they are transmitted (the coded order), it will require the transmitter to "look ahead" or buffer some number of frames.
无论采用何种带宽自适应方法，生成的比特流必须符合VC-1规范[1]。例如，如果放弃非参考帧，则FRMCNT语法元素（仅限于简单和主配置文件帧）和可选TFCNTR语法元素（仅限于高级配置文件帧）必须递增，就像没有放弃帧一样。由于TFCNTR语法元素按显示顺序对帧进行计数，这与发送顺序（编码顺序）不同，因此需要发送器“向前看”或缓冲一定数量的帧。
As another example, when switching between different representations of the same content, it may be necessary to signal a discontinuity by modifying the FRMCNT field, or if Advanced profile is used, by setting the BROKEN_LINK flag in the entry-point header to 1.
作为另一个示例，当在相同内容的不同表示之间切换时，可能需要通过修改FRMCNT字段来发出不连续信号，或者如果使用高级配置文件，则通过将入口点标题中的断开链接标志设置为1来发出不连续信号。
This payload format may also be used in networks that provide quality-of-service guarantees. If enhanced service is being used, receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
这种有效载荷格式也可用于提供服务质量保证的网络中。如果正在使用增强服务，则接收方应监控数据包丢失，以确保所请求的服务实际正在交付。如果不是，那么他们应该假设他们正在接受尽力而为的服务，并相应地采取行动。
IANA has registered the media type "video/vc1" and the associated RTP payload format in the Media Types registry and in the RTP Payload Format MIME types registry, as specified in section 6.1.
IANA已在媒体类型注册表和RTP有效负载格式MIME类型注册表中注册了媒体类型“视频/vc1”和相关RTP有效负载格式，如第6.1节所述。
[1] Society of Motion Picture and Television Engineers, "VC-1 Compressed Video Bitstream Format and Decoding Process", SMPTE 421M.
[1] 电影和电视工程师学会，“VC-1压缩视频比特流格式和解码过程”，SMPTE 421M。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[6] Josefsson，S.，编辑，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[8] Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 3555，2003年7月。
[9] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan, S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera, "Windows Media Video 9: overview and applications", Signal Processing: Image Communication, Volume 19, Issue 9, October 2004.
[9] Srinivasan，S.，Hsu，P.，Holcomb，T.，Mukerjee，K.，Regunathan，S.L.，Lin，B.，Liang，J.，Lee，M.，和J.Ribas Corbera，“Windows Media Video 9：概述和应用”，《信号处理：图像通信》，第19卷，第9期，2004年10月。
[10] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A generalized hypothetical reference decoder for H.264/AVC", IEEE Transactions on Circuits and Systems for Video Technology, August 2003.
[10] Ribas Corbera，J.，Chou，P.A.，和S.L.Regunathan，“H.264/AVC的广义假设参考解码器”，IEEE视频技术电路和系统交易，2003年8月。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[11] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[12] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[13] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[15] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
Acknowledgements
致谢
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar Regunathan, Gary Sullivan, Stephan Wenger, and Magnus Westerlund for providing detailed feedback on this document.
感谢Regis Crinon、Miska Hannuksela、Colin Perkins、Shankar Regunathan、Gary Sullivan、Stephan Wenger和Magnus Westerlund为本文件提供了详细反馈。
Author's Address
作者地址
Anders Klemets Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Anders Klemets微软公司美国华盛顿州雷德蒙微软路1号，邮编：98052
EMail: Anders.Klemets@microsoft.com
EMail: Anders.Klemets@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。