Network Working Group J. van der Meer
Request for Comments: 3640 Philips Electronics
Category: Standards Track D. Mackie
Apple Computer
V. Swaminathan
Sun Microsystems Inc.
D. Singer
Apple Computer
P. Gentric
Philips Electronics
November 2003
Network Working Group J. van der Meer
Request for Comments: 3640 Philips Electronics
Category: Standards Track D. Mackie
Apple Computer
V. Swaminathan
Sun Microsystems Inc.
D. Singer
Apple Computer
P. Gentric
Philips Electronics
November 2003
RTP Payload Format for Transport of MPEG-4 Elementary Streams
用于传输MPEG-4基本流的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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.
电影专家组（MPEG）委员会（ISO/IEC JTC1/SC29 WG11）是ISO的一个工作组，负责制定MPEG-4标准。MPEG定义了将视听信息等内容压缩为基本流的工具。本规范定义了一种简单但通用的RTP有效载荷格式，用于传输任何非多路复用的MPEG-4基本流。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Carriage of MPEG-4 Elementary Streams Over RTP . . . . . . . . 4
2.1. Signaling by MIME Format Parameters . . . . . . . . . . 4
2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . 5
2.3. Concatenation of Access Units . . . . . . . . . . . . . 5
2.4. Fragmentation of Access Units . . . . . . . . . . . . . 6
2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Time Stamp Information . . . . . . . . . . . . . . . . . 7
2.7. State Indication of MPEG-4 System Streams . . . . . . . 8
2.8. Random Access Indication . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Carriage of MPEG-4 Elementary Streams Over RTP . . . . . . . . 4
2.1. Signaling by MIME Format Parameters . . . . . . . . . . 4
2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . 5
2.3. Concatenation of Access Units . . . . . . . . . . . . . 5
2.4. Fragmentation of Access Units . . . . . . . . . . . . . 6
2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Time Stamp Information . . . . . . . . . . . . . . . . . 7
2.7. State Indication of MPEG-4 System Streams . . . . . . . 8
2.8. Random Access Indication . . . . . . . . . . . . . . . . 8
2.9. Carriage of Auxiliary Information . . . . . . . . . . . 8
2.10. MIME Format Parameters and Configuring Conditional Field 8
2.11. Global Structure of Payload Format . . . . . . . . . . . 9
2.12. Modes to Transport MPEG-4 Streams . . . . . . . . . . . 9
2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . 10
3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Usage of RTP Header Fields and RTCP . . . . . . . . . . 10
3.2. RTP Payload Structure . . . . . . . . . . . . . . . . . 11
3.2.1. The AU Header Section . . . . . . . . . . . . . 11
3.2.1.1. The AU-header . . . . . . . . . . . . 12
3.2.2. The Auxiliary Section . . . . . . . . . . . . . 14
3.2.3. The Access Unit Data Section . . . . . . . . . . 15
3.2.3.1. Fragmentation. . . . . . . . . . . . . 16
3.2.3.2. Interleaving . . . . . . . . . . . . . 16
3.2.3.3. Constraints for Interleaving . . . . . 17
3.2.3.4. Crucial and Non-Crucial AUs with
MPEG-4 System Data . . . . . . . . . . 20
3.3. Usage of this Specification. . . . . . . . . . . . . . . 21
3.3.1. General. . . . . . . . . . . . . . . . . . . . . 21
3.3.2. The Generic Mode . . . . . . . . . . . . . . . . 22
3.3.3. Constant Bit Rate CELP . . . . . . . . . . . . . 22
3.3.4. Variable Bit Rate CELP . . . . . . . . . . . . . 23
3.3.5. Low Bit Rate AAC . . . . . . . . . . . . . . . . 24
3.3.6. High Bit Rate AAC. . . . . . . . . . . . . . . . 25
3.3.7. Additional Modes . . . . . . . . . . . . . . . . 26
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
4.1. MIME Type Registration . . . . . . . . . . . . . . . . . 27
4.2. Registration of Mode Definitions with IANA . . . . . . . 33
4.3. Concatenation of Parameters. . . . . . . . . . . . . . . 33
4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1. The a=fmtp Keyword . . . . . . . . . . . . . . . 34
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
APPENDIX: Usage of this Payload Format. . . . . . . . . . . . . . 36
Appendix A. Interleave Analysis . . . . . . . . . . . . . . . . . 36
A. Examples of Delay Analysis with Interleave. . . . . . . . . . 36
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
A.2. De-interleaving and Error Concealment . . . . . . . . . 36
A.3. Simple Group Interleave . . . . . . . . . . . . . . . . 36
A.3.1. Introduction . . . . . . . . . . . . . . . . . . 36
A.3.2. Determining the De-interleave Buffer Size . . . 37
A.3.3. Determining the Maximum Displacement . . . . . . 37
A.4. More Subtle Group Interleave . . . . . . . . . . . . . . 38
A.4.1. Introduction . . . . . . . . . . . . . . . . . . 38
A.4.2. Determining the De-interleave Buffer Size. . . . 38
A.4.3. Determining the Maximum Displacement . . . . . . 39
A.5. Continuous Interleave . . . . . . . . . . . . . . . . . 39
A.5.1. Introduction . . . . . . . . . . . . . . . . . . 39
2.9. Carriage of Auxiliary Information . . . . . . . . . . . 8
2.10. MIME Format Parameters and Configuring Conditional Field 8
2.11. Global Structure of Payload Format . . . . . . . . . . . 9
2.12. Modes to Transport MPEG-4 Streams . . . . . . . . . . . 9
2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . 10
3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Usage of RTP Header Fields and RTCP . . . . . . . . . . 10
3.2. RTP Payload Structure . . . . . . . . . . . . . . . . . 11
3.2.1. The AU Header Section . . . . . . . . . . . . . 11
3.2.1.1. The AU-header . . . . . . . . . . . . 12
3.2.2. The Auxiliary Section . . . . . . . . . . . . . 14
3.2.3. The Access Unit Data Section . . . . . . . . . . 15
3.2.3.1. Fragmentation. . . . . . . . . . . . . 16
3.2.3.2. Interleaving . . . . . . . . . . . . . 16
3.2.3.3. Constraints for Interleaving . . . . . 17
3.2.3.4. Crucial and Non-Crucial AUs with
MPEG-4 System Data . . . . . . . . . . 20
3.3. Usage of this Specification. . . . . . . . . . . . . . . 21
3.3.1. General. . . . . . . . . . . . . . . . . . . . . 21
3.3.2. The Generic Mode . . . . . . . . . . . . . . . . 22
3.3.3. Constant Bit Rate CELP . . . . . . . . . . . . . 22
3.3.4. Variable Bit Rate CELP . . . . . . . . . . . . . 23
3.3.5. Low Bit Rate AAC . . . . . . . . . . . . . . . . 24
3.3.6. High Bit Rate AAC. . . . . . . . . . . . . . . . 25
3.3.7. Additional Modes . . . . . . . . . . . . . . . . 26
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
4.1. MIME Type Registration . . . . . . . . . . . . . . . . . 27
4.2. Registration of Mode Definitions with IANA . . . . . . . 33
4.3. Concatenation of Parameters. . . . . . . . . . . . . . . 33
4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1. The a=fmtp Keyword . . . . . . . . . . . . . . . 34
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
APPENDIX: Usage of this Payload Format. . . . . . . . . . . . . . 36
Appendix A. Interleave Analysis . . . . . . . . . . . . . . . . . 36
A. Examples of Delay Analysis with Interleave. . . . . . . . . . 36
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
A.2. De-interleaving and Error Concealment . . . . . . . . . 36
A.3. Simple Group Interleave . . . . . . . . . . . . . . . . 36
A.3.1. Introduction . . . . . . . . . . . . . . . . . . 36
A.3.2. Determining the De-interleave Buffer Size . . . 37
A.3.3. Determining the Maximum Displacement . . . . . . 37
A.4. More Subtle Group Interleave . . . . . . . . . . . . . . 38
A.4.1. Introduction . . . . . . . . . . . . . . . . . . 38
A.4.2. Determining the De-interleave Buffer Size. . . . 38
A.4.3. Determining the Maximum Displacement . . . . . . 39
A.5. Continuous Interleave . . . . . . . . . . . . . . . . . 39
A.5.1. Introduction . . . . . . . . . . . . . . . . . . 39
A.5.2. Determining the De-interleave Buffer Size . . . 40
A.5.3. Determining the Maximum Displacement . . . . . . 40
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Normative References . . . . . . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 43
A.5.2. Determining the De-interleave Buffer Size . . . 40
A.5.3. Determining the Maximum Displacement . . . . . . 40
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Normative References . . . . . . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 43
The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29 that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4 standards [1]. The MPEG-4 standard specifies compression of audio-visual data into, for example an audio or video elementary stream. In the MPEG-4 standard, these streams take the form of audio-visual objects that may be arranged into an audio-visual scene by means of a scene description. Each MPEG-4 elementary stream consists of a sequence of Access Units; examples of an Access Unit (AU) are an audio frame and a video picture.
MPEG委员会是ISO/IEC JTC1 SC29中的第11工作组（WG11），该工作组规定了MPEG-1、MPEG-2以及最近的MPEG-4标准[1]。MPEG-4标准规定将音频-视频数据压缩成例如音频或视频基本流。在MPEG-4标准中，这些流采用视听对象的形式，该视听对象可以通过场景描述被安排到视听场景中。每个MPEG-4基本流由一系列访问单元组成；访问单元（AU）的示例是音频帧和视频图片。
This specification defines a general and configurable payload structure to transport MPEG-4 elementary streams, in particular MPEG-4 audio (including speech) streams, MPEG-4 video streams and also MPEG-4 systems streams, such as BIFS (BInary Format for Scenes), OCI (Object Content Information), OD (Object Descriptor) and IPMP (Intellectual Property Management and Protection) streams. The RTP payload defined in this document is simple to implement and reasonably efficient. It allows for optional interleaving of Access Units (such as audio frames) to increase error resiliency in packet loss.
本规范定义了用于传输MPEG-4基本流（尤其是MPEG-4音频（包括语音）流、MPEG-4视频流以及MPEG-4系统流（例如BIFS（场景二进制格式）、OCI（对象内容信息）、OD（对象描述符）和IPMP）的通用且可配置的有效负载结构（知识产权管理和保护）流。本文档中定义的RTP有效负载易于实现且相当有效。它允许可选的访问单元（如音频帧）交错，以提高数据包丢失时的错误恢复能力。
Some types of MPEG-4 elementary streams include "crucial" information whose loss cannot be tolerated. However, RTP does not provide reliable transmission, so receipt of that crucial information is not assured. Section 3.2.3.4 specifies how stream state is conveyed so that the receiver can detect the loss of crucial information and cease decoding until the next random access point has been received. Applications transmitting streams that include crucial information, such as OD commands, BIFS commands, or programmatic content such as MPEG-J (Java) and ECMAScript, should include random access points, at a suitable periodicity depending upon the probability of loss, in order to reduce stream corruption to an acceptable level. An example is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1 [1].
某些类型的MPEG-4基本流包含不能容忍丢失的“关键”信息。然而，RTP不能提供可靠的传输，因此无法确保接收到关键信息。第3.2.3.4节规定了如何传输流状态，以便接收机能够检测到关键信息的丢失，并停止解码，直到接收到下一个随机接入点。传输包含关键信息（如OD命令、BIFS命令）或编程内容（如MPEG-J（Java）和ECMAScript）的流的应用程序应包括随机访问点，并根据丢失的概率以适当的周期进行传输，以便将流损坏降低到可接受的水平。例如，ISO/IEC 14496-1[1]中由MPEG定义的转盘机制。
Such applications may also employ additional protocols or services to reduce the probability of loss. At the RTP layer, these measures include payload formats and profiles for retransmission or forward error correction (such as in RFC 2733 [10]), that must be employed
此类应用还可采用附加协议或服务来降低丢失的概率。在RTP层，这些措施包括必须采用的用于重传或前向纠错的有效载荷格式和配置文件（如RFC 2733[10]）
with due consideration to congestion control. Another solution that may be appropriate for some applications is to carry RTP over TCP (such as in RFC 2326 [8], section 10.12). At the network layer, resource allocation or preferential service may be available to reduce the probability of loss. For a general description of methods to repair streaming media, see RFC 2354 [9].
在充分考虑拥塞控制的情况下。另一种可能适用于某些应用的解决方案是通过TCP传输RTP（如RFC 2326[8]，第10.12节）。在网络层，可以使用资源分配或优惠服务来降低丢失的概率。有关修复流媒体方法的一般说明，请参阅RFC 2354[9]。
Though the RTP payload format defined in this document is capable of transporting any MPEG-4 stream, other, more specific, formats may exist, such as RFC 3016 [12] for transport of MPEG-4 video (ISO/IEC 14496 [1] part 2).
尽管本文档中定义的RTP有效载荷格式能够传输任何MPEG-4流，但可能存在其他更具体的格式，例如用于传输MPEG-4视频的RFC 3016[12]（ISO/IEC 14496[1]第2部分）。
Configuration of the payload is provided to accommodate the transportation of any MPEG-4 stream at any possible bit rate. However, for a specific MPEG-4 elementary stream typically only very few configurations are needed. So as to allow for the design of simplified, but dedicated receivers, this specification requires that specific modes be defined for transport of MPEG-4 streams. This document defines modes for MPEG-4 CELP and AAC streams, as well as a generic mode that can be used to transport any MPEG-4 stream. In the future, new RFCs are expected to specify additional modes for the transportation of MPEG-4 streams.
提供有效载荷的配置以适应以任何可能的比特率传输任何MPEG-4流。然而，对于特定的MPEG-4基本流，通常只需要很少的配置。为了允许设计简化但专用的接收器，本规范要求为MPEG-4流的传输定义特定模式。本文档定义了MPEG-4 CELP和AAC流的模式，以及可用于传输任何MPEG-4流的通用模式。在未来，新的rfc有望为MPEG-4流的传输指定额外的模式。
The RTP payload format defined in this document specifies carriage of system-related information that is often equivalent to the information that may be contained in the MPEG-4 Sync Layer (SL) as defined in MPEG-4 Systems [1]. This document does not prescribe how to transcode or map information from the SL to fields defined in the RTP payload format. Such processing, if any, is left to the discretion of the application. However, to anticipate the need for the transportation of any additional system-related information in the future, an auxiliary field can be configured that may carry any such data.
本文件中定义的RTP有效载荷格式规定了系统相关信息的传输，这些信息通常相当于MPEG-4系统中定义的MPEG-4同步层（SL）中可能包含的信息[1]。本文档未规定如何将SL中的信息转码或映射到RTP有效负载格式中定义的字段。此类处理（如有）由申请自行决定。然而，为了预测将来传输任何附加系统相关信息的需要，可以配置可携带任何此类数据的辅助字段。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[4]中的描述进行解释。
With this payload format, a single MPEG-4 elementary stream can be transported. Information on the type of MPEG-4 stream carried in the payload is conveyed by MIME format parameters, as in an SDP [5] message or by other means (see section 4). These MIME format parameters specify the configuration of the payload. To allow for simplified and dedicated receivers, a MIME format parameter is
使用这种有效载荷格式，可以传输单个MPEG-4基本流。有效载荷中携带的MPEG-4流类型信息通过MIME格式参数传送，如SDP[5]消息或其他方式（见第4节）。这些MIME格式参数指定有效负载的配置。为了实现简化的专用接收器，需要使用MIME格式参数
available to signal a specific mode of using this payload. A mode definition MAY include the type of MPEG-4 elementary stream, as well as the applied configuration, so as to avoid the need for receivers to parse all MIME format parameters. The applied mode MUST be signaled.
可用于发出使用此有效负载的特定模式的信号。模式定义可以包括MPEG-4基本流的类型以及应用的配置，以避免接收机解析所有MIME格式参数的需要。应用模式必须发出信号。
For carriage of compressed audio-visual data, MPEG defines Access Units. An MPEG Access Unit (AU) is the smallest data entity to which timing information is attributed. In the case of audio, an Access Unit may represent an audio frame and in the case of video, a picture. MPEG Access Units are octet-aligned by definition. If, for example, an audio frame is not octet-aligned, up to 7 zero-padding bits MUST be inserted at the end of the frame to achieve the octet-aligned Access Units, as required by the MPEG-4 specification. MPEG-4 decoders MUST be able to decode AUs in which such padding is applied.
对于压缩视听数据的传输，MPEG定义了访问单元。MPEG访问单元（AU）是时间信息所属的最小数据实体。在音频的情况下，访问单元可以表示音频帧，在视频的情况下，可以表示图片。MPEG访问单元是按定义对齐的八位字节。例如，如果音频帧不是八位字节对齐的，则必须按照MPEG-4规范的要求，在帧的末尾插入多达7个零填充位，以实现八位字节对齐的访问单元。MPEG-4解码器必须能够解码应用这种填充的AU。
Consistent with the MPEG-4 specification, this document requires that each MPEG-4 part 2 video Access Unit include all the coded data of a picture, any video stream headers that may precede the coded picture data, and any video stream stuffing that may follow it, up to but not including the startcode indicating the start of a new video stream or the next Access Unit.
与MPEG-4规范一致，本文件要求每个MPEG-4第2部分视频访问单元包括图片的所有编码数据、可能在编码图片数据之前的任何视频流头以及可能在编码图片数据之后的任何视频流填充，最多但不包括指示新视频流或下一个访问单元开始的startcode。
Frequently it is possible to carry multiple Access Units in one RTP packet. This is particularly useful for audio; for example, when AAC is used for encoding a stereo signal at 64 kbits/sec, AAC frames contain on average, approximately 200 octets. On a LAN with a 1500 octet MTU, this would allow an average of 7 complete AAC frames to be carried per RTP packet.
通常，在一个RTP包中携带多个接入单元是可能的。这对于音频特别有用；例如，当AAC用于以64 kbits/sec的速度编码立体声信号时，AAC帧平均包含约200个八位字节。在具有1500个八位组MTU的LAN上，这将允许每个RTP数据包平均携带7个完整的AAC帧。
Access Units may have a fixed size in octets, but a variable size is also possible. To facilitate parsing in the case of multiple concatenated AUs in one RTP packet, the size of each AU is made known to the receiver. When concatenating in the case of a constant AU size, this size is communicated "out of band" through a MIME format parameter. When concatenating in case of variable size AUs, the RTP payload carries "in band" an AU size field for each contained AU.
访问单元可以有固定大小的八位字节，但也可以有可变大小。为了便于在一个RTP数据包中有多个串联AU的情况下进行解析，接收机知道每个AU的大小。在恒定AU大小的情况下进行连接时，此大小通过MIME格式参数“带外”进行通信。在可变大小AU的情况下进行连接时，RTP有效负载为每个包含的AU携带“带内”AU大小字段。
In combination with the RTP payload length, the size information allows the RTP payload to be split by the receiver back into the individual AUs.
结合RTP有效负载长度，大小信息允许接收机将RTP有效负载拆分回各个AU。
To simplify the implementation of RTP receivers, it is required that when multiple AUs are carried in an RTP packet, each AU MUST be complete, i.e., the number of AUs in an RTP packet MUST be integral.
为了简化RTP接收机的实现，要求在RTP分组中携带多个AU时，每个AU必须是完整的，即RTP分组中的AU数量必须是整数。
In addition, an AU MUST NOT be repeated in other RTP packets; hence repetition of an AU is only possible when using a duplicate RTP packet.
此外，AU不得在其他RTP数据包中重复；因此，只有在使用重复的RTP数据包时才可能重复AU。
MPEG allows for very large Access Units. Since most IP networks have significantly smaller MTU sizes, this payload format allows for the fragmentation of an Access Unit over multiple RTP packets. Hence, when an IP packet is lost after IP-level fragmentation, only an AU fragment may get lost instead of the entire AU. To simplify the implementation of RTP receivers, an RTP packet SHALL either carry one or more complete Access Units or a single fragment of one AU, i.e., packets MUST NOT contain fragments of multiple Access Units.
MPEG允许非常大的访问单元。由于大多数IP网络具有显著更小的MTU大小，因此该有效负载格式允许在多个RTP数据包上对接入单元进行分段。因此，当IP数据包在IP级碎片化后丢失时，只有一个AU片段可能丢失，而不是整个AU。为了简化RTP接收机的实现，RTP分组应携带一个或多个完整的接入单元或一个AU的单个片段，即分组不得包含多个接入单元的片段。
When an RTP packet carries a contiguous sequence of Access Units, the loss of such a packet can result in a "decoding gap" for the user. One method of alleviating this problem is to allow for the Access Units to be interleaved in the RTP packets. For a modest cost in latency and implementation complexity, significant error resiliency to packet loss can be achieved.
当RTP分组携带接入单元的连续序列时，这种分组的丢失可导致用户的“解码间隙”。缓解该问题的一种方法是允许在RTP分组中交织接入单元。对于延迟和实现复杂性方面的适度成本，可以实现对数据包丢失的显著错误恢复能力。
To support optional interleaving of Access Units, this payload format allows for index information to be sent for each Access Unit. After informing receivers about buffer resources to allocate for de-interleaving, the RTP sender is free to choose the interleaving pattern without propagating this information a priori to the receiver(s). Indeed, the sender could dynamically adjust the interleaving pattern based on the Access Unit size, error rates, etc. The RTP receiver does not need to know the interleaving pattern used; it only needs to extract the index information of the Access Unit and insert the Access Unit into the appropriate sequence in the decoding or rendering queue. An example of interleaving is given below.
为了支持访问单元的可选交错，此有效负载格式允许为每个访问单元发送索引信息。在通知接收方要分配用于解交织的缓冲区资源后，RTP发送方可以自由选择交织模式，而无需事先将该信息传播给接收方。实际上，发送方可以基于接入单元大小、错误率等动态地调整交织模式。RTP接收机不需要知道所使用的交织模式；它只需要提取访问单元的索引信息，并将访问单元插入解码或呈现队列中的适当序列中。下面给出了交织的一个示例。
For example, if we assume that an RTP packet contains 3 AUs, and that the AUs are numbered 0, 1, 2, 3, 4, and so forth, and if an interleaving group length of 9 is chosen, then RTP packet(i) contains the following AU(n):
例如，如果我们假设RTP分组包含3个AU，并且AU编号为0、1、2、3、4等等，并且如果选择了9的交织组长度，则RTP分组（i）包含以下AU（n）：
RTP packet(0): AU(0), AU(3), AU(6) RTP packet(1): AU(1), AU(4), AU(7) RTP packet(2): AU(2), AU(5), AU(8) RTP packet(3): AU(9), AU(12), AU(15) RTP packet(4): AU(10), AU(13), AU(16) Etc.
RTP包（0）：AU（0），AU（3），AU（6）RTP包（1）：AU（1），AU（4），AU（7）RTP包（2）：AU（2），AU（5），AU（8）RTP包（3）：AU（9），AU（12），AU（15）RTP包（4）：AU（10），AU（13），AU（16）等。
The RTP time stamp MUST carry the sampling instant of the first AU (fragment) in the RTP packet. When multiple AUs are carried within an RTP packet, the time stamps of subsequent AUs can be calculated if the frame period of each AU is known. For audio and video, this is possible if the frame rate is constant. However, in some cases it is not possible to make such a calculation (for example, for variable frame rate video, or for MPEG-4 BIFS streams carrying composition information). To support such cases, this payload format can be configured to carry a time stamp in the RTP payload for each contained Access Unit. A time stamp MAY be conveyed in the RTP payload only for non-first AUs in the RTP packet, and SHALL NOT be conveyed for the first AU (fragment), as the time stamp for the first AU in the RTP packet is carried by the RTP time stamp.
RTP时间戳必须携带RTP数据包中第一个AU（片段）的采样瞬间。当一个RTP包中携带多个AU时，如果每个AU的帧周期已知，则可以计算后续AU的时间戳。对于音频和视频，如果帧速率恒定，这是可能的。然而，在某些情况下，不可能进行这样的计算（例如，对于可变帧速率视频，或者对于携带构图信息的MPEG-4bifs流）。为了支持这种情况，可以将该有效载荷格式配置为在RTP有效载荷中为每个包含的访问单元携带时间戳。时间戳可仅针对RTP分组中的非第一AU在RTP有效载荷中传送，且不应针对第一AU（片段）传送，因为RTP分组中的第一AU的时间戳由RTP时间戳携带。
MPEG-4 defines two types of time stamps: the composition time stamp (CTS) and the decoding time stamp (DTS). The CTS represents the sampling instant of an AU, and hence the CTS is equivalent to the RTP time stamp. The DTS may be used in MPEG-4 video streams that use bi-directional coding, i.e., when pictures are predicted in both forward and backward direction by using either a reference picture in the past, or a reference picture in the future. The DTS cannot be carried in the RTP header. In some cases, the DTS can be derived from the RTP time stamp using frame rate information; this requires deep parsing in the video stream, which may be considered objectionable. If the video frame rate is variable, the required information may not even be present in the video stream. For both reasons, the capability has been defined to optionally carry the DTS in the RTP payload for each contained Access Unit.
MPEG-4定义了两种时间戳：合成时间戳（CTS）和解码时间戳（DTS）。CTS表示AU的采样瞬间，因此CTS相当于RTP时间戳。DTS可用于使用双向编码的MPEG-4视频流中，即，当通过使用过去的参考图片或未来的参考图片在向前和向后方向上预测图片时。不能在RTP标头中携带DTS。在某些情况下，可以使用帧速率信息从RTP时间戳导出DTS；这需要在视频流中进行深度解析，这可能会被认为是不合适的。如果视频帧速率是可变的，则所需信息甚至可能不存在于视频流中。出于这两个原因，该能力被定义为可选地在RTP有效负载中为每个包含的接入单元承载DTS。
To keep the coding of time stamps efficient, each time stamp contained in the RTP payload is coded as a difference. For the CTS, the offset from the RTP time stamps is provided, and for the DTS, the offset from the CTS.
为了保持时间戳的编码效率，RTP有效负载中包含的每个时间戳都被编码为差。对于CTS，提供与RTP时间戳的偏移，对于DTS，提供与CTS的偏移。
ISO/IEC 14496-1 defines states for MPEG-4 system streams. So as to convey state information when transporting MPEG-4 system streams, this payload format allows for the optional carriage in the RTP payload of the stream state for each contained Access Unit. Stream states are used to signal "crucial" AUs that carry information whose loss cannot be tolerated and are also useful when repeating AUs according to the carousel mechanism defined in ISO/IEC 14496-1.
ISO/IEC 14496-1定义了MPEG-4系统流的状态。为了在传输MPEG-4系统流时传送状态信息，该有效载荷格式允许在RTP有效载荷中为每个包含的访问单元可选地传送流状态。流状态用于向“关键”AU发送信号，这些AU携带的信息丢失是不可容忍的，并且在根据ISO/IEC 14496-1中定义的转盘机制重复AU时也很有用。
Random access to the content of MPEG-4 elementary streams may be possible at some but not all Access Units. To signal Access Units where random access is possible, a random access point flag can optionally be carried in the RTP payload for each contained Access Unit. Carriage of random access points is particularly useful for MPEG-4 system streams in combination with the stream state.
对MPEG-4基本流的内容的随机访问可以在一些但不是所有的访问单元处进行。为了向可能进行随机访问的访问单元发送信号，可以选择在RTP有效载荷中为每个包含的访问单元携带随机访问点标志。随机接入点的承载对于结合流状态的MPEG-4系统流特别有用。
This payload format defines a specific field to carry auxiliary data. The auxiliary data field is preceded by a field that specifies the length of the auxiliary data, so as to facilitate the skipping of data without parsing it. The coding of the auxiliary data is not defined in this document; instead, the format, meaning and signaling of auxiliary information is expected to be specified in one or more future RFCs. Auxiliary information MUST NOT be transmitted until its format, meaning and signaling have been specified and its use has been signaled. Receivers that have knowledge of the auxiliary data MAY decode the auxiliary data, but receivers without knowledge of such data MUST skip the auxiliary data field.
此有效负载格式定义了一个特定字段，用于承载辅助数据。辅助数据字段前面有一个指定辅助数据长度的字段，以便在不解析数据的情况下跳过数据。本文件未定义辅助数据的编码；相反，期望在一个或多个未来rfc中指定辅助信息的格式、含义和信令。在指定了辅助信息的格式、含义和信号并发出了使用信号之前，不得传输辅助信息。知道辅助数据的接收机可以解码辅助数据，但不知道此类数据的接收机必须跳过辅助数据字段。
To support the features described in the previous sections, several fields are defined for carriage in the RTP payload. However, their use strongly depends on the type of MPEG-4 elementary stream that is carried. Sometimes a specific field is needed with a certain length, while in other cases such a field is not needed. To be efficient in either case, the fields to support these features are configurable by means of MIME format parameters. In general, a MIME format parameter defines the presence and length of the associated field. A length of zero indicates absence of the field. As a consequence, parsing of the payload requires knowledge of MIME format parameters. The MIME format parameters are conveyed to the receiver via SDP [5] messages, as specified in section 4.4.1, or through other means.
为了支持前面章节中描述的功能，为RTP有效载荷中的运载定义了几个字段。然而，它们的使用在很大程度上取决于所承载的MPEG-4基本流的类型。有时需要具有一定长度的特定字段，而在其他情况下则不需要此类字段。为了在任何一种情况下都有效，支持这些功能的字段都可以通过MIME格式参数进行配置。通常，MIME格式参数定义关联字段的存在和长度。长度为零表示没有字段。因此，有效负载的解析需要了解MIME格式参数。MIME格式参数通过第4.4.1节规定的SDP[5]消息或通过其他方式传送给接收方。
The RTP payload following the RTP header, contains three octet-aligned data sections, of which the first two MAY be empty, see Figure 1.
RTP报头后面的RTP有效负载包含三个八位字节对齐的数据部分，其中前两个可能为空，见图1。
+---------+-----------+-----------+---------------+
| RTP | AU Header | Auxiliary | Access Unit |
| Header | Section | Section | Data Section |
+---------+-----------+-----------+---------------+
+---------+-----------+-----------+---------------+
| RTP | AU Header | Auxiliary | Access Unit |
| Header | Section | Section | Data Section |
+---------+-----------+-----------+---------------+
<----------RTP Packet Payload----------->
<----------RTP Packet Payload----------->
Figure 1: Data sections within an RTP packet
图1:RTP包中的数据部分
The first data section is the AU (Access Unit) Header Section, that contains one or more AU-headers; however, each AU-header MAY be empty, in which case the entire AU Header Section is empty. The second section is the Auxiliary Section, containing auxiliary data; this section MAY also be configured empty. The third section is the Access Unit Data Section, containing either a single fragment of one Access Unit or one or more complete Access Units. The Access Unit Data Section MUST NOT be empty.
第一数据部分是AU（访问单元）报头部分，它包含一个或多个AU报头；然而，每个AU报头可能为空，在这种情况下，整个AU报头部分为空。第二部分为辅助部分，包含辅助数据；此部分也可以配置为空。第三部分是访问单元数据部分，包含一个访问单元的单个片段或一个或多个完整的访问单元。访问单元数据部分不能为空。
While it is possible to build fully configurable receivers capable of receiving any MPEG-4 stream, this specification also allows for the design of simplified, but dedicated receivers, that are for example, capable of receiving only one type of MPEG-4 stream. This is achieved by requiring that specific modes be defined in order to use this specification. Each mode may define constraints for transport of one or more types of MPEG-4 streams, for instance on the payload configuration.
虽然可以构建能够接收任何MPEG-4流的完全可配置的接收器，但本规范还允许设计简化但专用的接收器，例如，仅能够接收一种类型的MPEG-4流。这是通过要求定义特定模式以使用本规范来实现的。每种模式可定义用于传输一种或多种类型的MPEG-4流的约束，例如在有效载荷配置上。
The applied mode MUST be signaled. Signaling the mode is particularly important for receivers that are only capable of decoding one or more specific modes. Such receivers need to determine whether the applied mode is supported, so as to avoid problems with processing of payloads that are beyond the capabilities of the receiver.
应用模式必须发出信号。对于仅能够解码一个或多个特定模式的接收机，发送该模式的信令尤其重要。此类接收器需要确定是否支持应用模式，以避免处理超出接收器能力的有效载荷的问题。
In this document several modes are defined for the transportation of MPEG-4 CELP and AAC streams, as well as a generic mode that can be used for any MPEG-4 stream. In the future, new RFCs may specify other modes of using this specification. However, each mode MUST be in full compliance with this specification (see section 3.3.7).
在本文档中，定义了用于传输MPEG-4 CELP和AAC流的几种模式，以及可用于任何MPEG-4流的通用模式。将来，新的RFC可能会指定使用本规范的其他模式。但是，每种模式必须完全符合本规范（见第3.3.7节）。
This payload can be configured as nearly identical to the payload format defined in RFC 3016 [12] for the MPEG-4 video configurations recommended in RFC 3016. Hence, receivers that comply with RFC 3016 can decode such RTP payload, provided that additional packets containing video decoder configuration (VO, VOL, VOSH) are inserted in the stream, as required by RFC 3016 [12]. Conversely, receivers that comply with the specification in this document SHOULD be able to decode payloads, names and parameters defined for MPEG-4 video in RFC 3016 [12]. In this respect, it is strongly RECOMMENDED that the implementation provide the ability to ignore "in band" video decoder configuration packets that may be found in streams conforming to the RFC 3016 video payload.
对于RFC 3016中推荐的MPEG-4视频配置，可以将该有效负载配置为与RFC 3016[12]中定义的有效负载格式几乎相同。因此，符合RFC 3016的接收机可以解码这样的RTP有效载荷，前提是按照RFC 3016[12]的要求，在流中插入包含视频解码器配置（VO、VOL、VOSH）的附加分组。相反，符合本文件规范的接收器应能够解码RFC 3016[12]中为MPEG-4视频定义的有效载荷、名称和参数。在这方面，强烈建议实现提供忽略可能在符合RFC 3016视频有效载荷的流中找到的“带内”视频解码器配置分组的能力。
Note the "out of band" availability of the video decoder configuration is optional in RFC 3016 [12]. To achieve maximum interoperability with the RTP payload format defined in this document, applications that use RFC 3016 to transport MPEG-4 video (part 2) are recommended to make the video decoder configuration available as a MIME parameter.
注：在RFC 3016[12]中，视频解码器配置的“带外”可用性是可选的。为了实现与本文档中定义的RTP有效负载格式的最大互操作性，建议使用RFC 3016传输MPEG-4视频（第2部分）的应用程序将视频解码器配置作为MIME参数提供。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP).
有效负载类型（PT）：此数据包格式的RTP有效负载类型的分配不在本文档的范围内；它由使用此有效负载格式的RTP配置文件指定，或在带外动态发送信号（例如，使用SDP）。
Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet payload contains either the final fragment of a fragmented Access Unit or one or more complete Access Units.
标记（M）位：将M位设置为1，以指示RTP数据包有效负载包含分段访问单元的最终片段或一个或多个完整访问单元。
Extension (X) bit: Defined by the RTP profile used.
扩展（X）位：由使用的RTP配置文件定义。
Sequence Number: The RTP sequence number SHOULD be generated by the sender in the usual manner with a constant random offset.
序列号：RTP序列号应由发送方以通常的方式以恒定的随机偏移量生成。
Timestamp: Indicates the sampling instant of the first AU contained in the RTP payload. This sampling instant is equivalent to the CTS in the MPEG-4 time domain. When using SDP, the clock rate of the RTP time stamp MUST be expressed using the "rtpmap" attribute. If an MPEG-4 audio stream is transported, the rate SHOULD be set to the same value as the sampling rate of the audio stream. If an MPEG-4 video stream is transported, it is RECOMMENDED that the rate be set to 90 kHz.
时间戳：指示RTP有效负载中包含的第一个AU的采样瞬间。此采样瞬间相当于MPEG-4时域中的CTS。使用SDP时，RTP时间戳的时钟速率必须使用“rtpmap”属性表示。如果传输MPEG-4音频流，则速率应设置为与音频流的采样速率相同的值。如果传输MPEG-4视频流，建议将速率设置为90 kHz。
In all cases, the sender SHALL make sure that RTP time stamps are identical only if the RTP time stamp refers to fragments of the same Access Unit.
在所有情况下，发送方应确保RTP时间戳仅在RTP时间戳引用相同访问单元的片段时相同。
According to RFC 3550 [2] (section 5.1), it is RECOMMENDED that RTP time stamps start at a random value for security reasons. This is not an issue for synchronization of multiple RTP streams. However, when streams from multiple sources are to be synchronized (for example one stream from local storage, another from an RTP streaming server), synchronization may become impossible if the receiver only knows the original time stamp relationships. In such cases the time stamp relationship required for obtaining synchronization may be provided by out of band means. The format of such information, as well as methods to convey such information, are beyond the scope of this specification.
根据RFC 3550[2]（第5.1节），出于安全原因，建议RTP时间戳以随机值开始。这不是多个RTP流同步的问题。然而，当来自多个源的流要被同步时（例如，来自本地存储器的一个流，来自RTP流服务器的另一个流），如果接收器仅知道原始时间戳关系，则同步可能变得不可能。在这种情况下，可通过带外方式提供获得同步所需的时间戳关系。此类信息的格式以及传达此类信息的方法超出了本规范的范围。
SSRC: set as described in RFC 3550 [2].
SSRC：设置如RFC 3550[2]所述。
CC and CSRC fields are used as described in RFC 3550 [2].
CC和CSC字段的使用如RFC 3550[2]所述。
RTCP SHOULD be used as defined in RFC 3550 [2]. Note that time stamps in RTCP Sender Reports may be used to synchronize multiple MPEG-4 elementary streams and also to synchronize MPEG-4 streams with non-MPEG-4 streams, in case the delivery of these streams uses RTP.
RTCP应按照RFC 3550[2]中的定义使用。请注意，RTCP发送方报告中的时间戳可用于同步多个MPEG-4基本流，也可用于同步MPEG-4流与非MPEG-4流，前提是这些流的传送使用RTP。
When present, the AU Header Section consists of the AU-headers-length field, followed by a number of AU-headers, see Figure 2.
如果存在，AU Header部分由AU headers length字段组成，后面是许多AU Header，见图2。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
|AU-headers-length|AU-header|AU-header| |AU-header|padding|
| | (1) | (2) | | (n) | bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
|AU-headers-length|AU-header|AU-header| |AU-header|padding|
| | (1) | (2) | | (n) | bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
Figure 2: The AU Header Section
图2:AU标题部分
The AU-headers are configured using MIME format parameters and MAY be empty. If the AU-header is configured empty, the AU-headers-length field SHALL NOT be present and consequently the AU Header Section is empty. If the AU-header is not configured empty, then the AU-headers-length is a two octet field that specifies the length in bits of the immediately following AU-headers, excluding the padding bits.
AU头是使用MIME格式参数配置的，可能为空。如果AU标头配置为空，则AU标头长度字段不应存在，因此AU标头部分为空。如果AU头未配置为空，则AU头长度是一个双八位组字段，用于指定紧跟其后的AU头的位长度，不包括填充位。
Each AU-header is associated with a single Access Unit (fragment) contained in the Access Unit Data Section in the same RTP packet.
每个AU报头与同一RTP分组中的接入单元数据部分中包含的单个接入单元（片段）相关联。
For each contained Access Unit (fragment), there is exactly one AU-header. Within the AU Header Section, the AU-headers are bit-wise concatenated in the order in which the Access Units are contained in the Access Unit Data Section. Hence, the n-th AU-header refers to the n-th AU (fragment). If the concatenated AU-headers consume a non-integer number of octets, up to 7 zero-padding bits MUST be inserted at the end in order to achieve octet-alignment of the AU Header Section.
对于每个包含的访问单元（片段），正好有一个AU头。在AU报头部分中，AU报头按照访问单元数据部分中包含访问单元的顺序按位连接。因此，第n个AU头指的是第n个AU（片段）。如果串联的AU报头使用非整数个八位字节，则必须在结尾插入多达7个零填充位，以实现AU报头部分的八位字节对齐。
Each AU-header may contain the fields given in Figure 3. The length in bits of the fields, with the exception of the CTS-flag, the DTS-flag and the RAP-flag fields, is defined by MIME format parameters; see section 4.1. If a MIME format parameter has the default value of zero, then the associated field is not present. The number of bits for fields that are present and that represent the value of a parameter MUST be chosen large enough to correctly encode the largest value of that parameter during the session.
每个AU头可能包含图3中给出的字段。除CTS标志、DTS标志和RAP标志字段外，字段的位长度由MIME格式参数定义；见第4.1节。如果MIME格式参数的默认值为零，则关联字段不存在。必须选择足够大的字段位数，以便在会话期间正确编码该参数的最大值。
If present, the fields MUST occur in the mutual order given in Figure 3. In the general case, a receiver can only discover the size of an AU-header by parsing it since the presence of the CTS-delta and DTS-delta fields is signaled by the value of the CTS-flag and DTS-flag, respectively.
如果存在，字段必须按照图3中给出的相互顺序出现。在一般情况下，接收机只能通过解析来发现AU报头的大小，因为CTS delta和DTS delta字段的存在分别由CTS标志和DTS标志的值发出信号。
+---------------------------------------+
| AU-size |
+---------------------------------------+
| AU-Index / AU-Index-delta |
+---------------------------------------+
| CTS-flag |
+---------------------------------------+
| CTS-delta |
+---------------------------------------+
| DTS-flag |
+---------------------------------------+
| DTS-delta |
+---------------------------------------+
| RAP-flag |
+---------------------------------------+
| Stream-state |
+---------------------------------------+
+---------------------------------------+
| AU-size |
+---------------------------------------+
| AU-Index / AU-Index-delta |
+---------------------------------------+
| CTS-flag |
+---------------------------------------+
| CTS-delta |
+---------------------------------------+
| DTS-flag |
+---------------------------------------+
| DTS-delta |
+---------------------------------------+
| RAP-flag |
+---------------------------------------+
| Stream-state |
+---------------------------------------+
Figure 3: The fields in the AU-header. If used, the AU-Index field only occurs in the first AU-header within an AU Header Section; in any other AU-header, the AU-Index-delta field occurs instead.
图3:AU头中的字段。如果使用，AU索引字段仅出现在AU标头部分内的第一个AU标头中；在任何其他AU标头中，会出现AU索引增量字段。
AU-size: Indicates the size in octets of the associated Access Unit in the Access Unit Data Section in the same RTP packet. When the AU-size is associated with an AU fragment, the AU size indicates the size of the entire AU and not the size of the fragment. In this case, the size of the fragment is known from the size of the AU data section. This can be exploited to determine whether a packet contains an entire AU or a fragment, which is particularly useful after losing a packet carrying the last fragment of an AU.
AU size：表示同一RTP数据包中访问单元数据段中相关访问单元的大小（以八位字节为单位）。当AU大小与AU碎片关联时，AU大小表示整个AU的大小，而不是碎片的大小。在这种情况下，片段的大小由AU数据段的大小可知。可以利用这一点来确定数据包是包含整个AU还是片段，这在丢失包含AU最后一个片段的数据包后特别有用。
AU-Index: Indicates the serial number of the associated Access Unit (fragment). For each (in decoding order) consecutive AU or AU fragment, the serial number is incremented by 1. When present, the AU-Index field occurs in the first AU-header in the AU Header Section, but MUST NOT occur in any subsequent (non-first) AU-header in that Section. To encode the serial number in any such non-first AU-header, the AU-Index-delta field is used.
AU索引：指示相关访问单元（片段）的序列号。对于每个（按解码顺序）连续的AU或AU片段，序列号递增1。如果存在，AU索引字段出现在AU标头部分的第一个AU标头中，但不得出现在该部分的任何后续（非第一个）AU标头中。要对任何此类非第一个AU头中的序列号进行编码，使用AU索引增量字段。
AU-Index-delta: The AU-Index-delta field is an unsigned integer that specifies the serial number of the associated AU as the difference with respect to the serial number of the previous Access Unit. Hence, for the n-th (n>1) AU, the serial number is found from:
AU Index delta：AU Index delta字段是一个无符号整数，它将关联AU的序列号指定为与先前访问单元序列号的差值。因此，对于第n个（n>1）AU，序列号可从以下位置找到：
AU-Index(n) = AU-Index(n-1) + AU-Index-delta(n) + 1
AU-Index(n) = AU-Index(n-1) + AU-Index-delta(n) + 1
If the AU-Index field is present in the first AU-header in the AU Header Section, then the AU-Index-delta field MUST be present in any subsequent (non-first) AU-header. When the AU-Index-delta is coded with the value 0, it indicates that the Access Units are consecutive in decoding order. An AU-Index-delta value larger than 0 signals that interleaving is applied.
如果AU索引字段出现在AU标头部分的第一个AU标头中，则AU索引增量字段必须出现在任何后续（非第一个）AU标头中。当AU索引增量用值0编码时，它指示接入单元在解码顺序上是连续的。大于0的AU索引增量值表示应用了交织。
CTS-flag: Indicates whether the CTS-delta field is present. A value of 1 indicates that the field is present, a value of 0 indicates that it is not present.
CTS标志：指示是否存在CTS增量字段。值1表示该字段存在，值0表示该字段不存在。
The CTS-flag field MUST be present in each AU-header if the length of the CTS-delta field is signaled to be larger than zero. In that case, the CTS-flag field MUST have the value 0 in the first AU-header and MAY have the value 1 in all non-first AU-headers. The CTS-flag field SHOULD be 0 for any non-first fragment of an Access Unit.
如果CTS delta字段的长度被信号通知大于零，则每个AU标头中必须存在CTS标志字段。在这种情况下，CTS标志字段在第一个AU头中必须具有值0，并且在所有非第一个AU头中可能具有值1。对于访问单元的任何非第一个片段，CTS标志字段应为0。
CTS-delta: Encodes the CTS by specifying the value of CTS as a 2's complement offset (delta) from the time stamp in the RTP header of this RTP packet. The CTS MUST use the same clock rate as the time stamp in the RTP header.
CTS delta：通过将CTS的值指定为此RTP数据包的RTP报头中的时间戳的2的补码偏移量（delta），对CTS进行编码。CTS必须使用与RTP报头中的时间戳相同的时钟速率。
DTS-flag: Indicates whether the DTS-delta field is present. A value of 1 indicates that DTS-delta is present, a value of 0 indicates that it is not present.
DTS标志：指示DTS增量字段是否存在。值1表示存在DTS增量，值0表示不存在。
The DTS-flag field MUST be present in each AU-header if the length of the DTS-delta field is signaled to be larger than zero. The DTS-flag field MUST have the same value for all fragments of an Access Unit.
如果DTS增量字段的长度被信号通知大于零，则每个AU标头中必须存在DTS标志字段。对于访问单元的所有片段，DTS标志字段必须具有相同的值。
DTS-delta: Specifies the value of the DTS as a 2's complement offset (delta) from the CTS. The DTS MUST use the same clock rate as the time stamp in the RTP header. The DTS-delta field MUST have the same value for all fragments of an Access Unit.
DTS增量：将DTS的值指定为CTS的2补码偏移量（增量）。DTS必须使用与RTP报头中的时间戳相同的时钟速率。对于访问单元的所有片段，DTS增量字段必须具有相同的值。
RAP-flag: When set to 1, indicates that the associated Access Unit provides a random access point to the content of the stream. If an Access Unit is fragmented, the RAP flag, if present, MUST be set to 0 for each non-first fragment of the AU.
RAP标志：设置为1时，表示关联的访问单元为流的内容提供随机访问点。如果访问单元是分段的，则RAP标志（如果存在）必须为AU的每个非第一个片段设置为0。
Stream-state: Specifies the state of the stream for an AU of an MPEG-4 system stream; each state is identified by a value of a modulo counter. In ISO/IEC 14496-1, MPEG-4 system streams use the AU_SequenceNumber to signal stream states. When the stream state changes, the value of the stream-state MUST be incremented by one.
流状态：指定MPEG-4系统流的AU的流状态；每个状态由模计数器的值标识。在ISO/IEC 14496-1中，MPEG-4系统流使用AU_SequenceNumber来表示流状态。当流状态更改时，流状态的值必须增加1。
Note: no relation is required between stream-states of different streams.
注：不同流的流状态之间不需要关系。
The Auxiliary Section consists of the auxiliary-data-size field followed by the auxiliary-data field. Receivers MAY (but are not required to) parse the auxiliary-data field; to facilitate skipping of the auxiliary-data field by receivers, the auxiliary-data-size field indicates the length in bits of the auxiliary-data. If the concatenation of the auxiliary-data-size and the auxiliary-data fields consume a non-integer number of octets, up to 7 zero padding bits MUST be inserted immediately after the auxiliary data in order to achieve octet-alignment. See Figure 4.
辅助部分由辅助数据大小字段和辅助数据字段组成。接收器可以（但不需要）解析辅助数据字段；为了便于接收机跳过辅助数据字段，辅助数据大小字段指示辅助数据的位长度。如果辅助数据大小和辅助数据字段的串联使用非整数个八位字节，则必须在辅助数据之后立即插入多达7个零填充位，以实现八位字节对齐。参见图4。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
| auxiliary-data-size | auxiliary-data |padding bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
| auxiliary-data-size | auxiliary-data |padding bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
Figure 4: The fields in the Auxiliary Section
图4：辅助部分中的字段
The length in bits of the auxiliary-data-size field is configurable by a MIME format parameter; see section 4.1. The default length of zero indicates that the entire Auxiliary Section is absent.
辅助数据大小字段的位长度可通过MIME格式参数配置；见第4.1节。默认长度为零表示缺少整个辅助部分。
auxiliary-data-size: specifies the length in bits of the immediately following auxiliary-data field;
辅助数据大小：指定紧跟其后的辅助数据字段的长度（位）；
auxiliary-data: the auxiliary-data field contains data of a format not defined by this specification.
辅助数据：辅助数据字段包含本规范未定义格式的数据。
The Access Unit Data Section contains an integer number of complete Access Units or a single fragment of one AU. The Access Unit Data Section is never empty. If data of more than one Access Unit is present, then the AUs are concatenated into a contiguous string of octets. See Figure 5. The AUs inside the Access Unit Data Section MUST be in decoding order, though not necessarily contiguous in the case of interleaving.
访问单元数据部分包含完整访问单元的整数或一个AU的单个片段。访问单元数据部分从不为空。如果存在多个访问单元的数据，则将AU连接成连续的八位字节字符串。参见图5。接入单元数据部分内的AU必须处于解码顺序，尽管在交织的情况下不一定是连续的。
The size and number of Access Units SHOULD be adjusted such that the resulting RTP packet is not larger than the path MTU. To handle larger packets, this payload format relies on lower layers for fragmentation, which may result in reduced performance.
应调整接入单元的大小和数量，以使产生的RTP分组不大于路径MTU。为了处理较大的数据包，此有效负载格式依赖较低的层进行分段，这可能会导致性能降低。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(1) |
+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AU(2) |
+-+-+-+-+-+-+-+-+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AU(n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(n) continued|
|-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(1) |
+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AU(2) |
+-+-+-+-+-+-+-+-+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AU(n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(n) continued|
|-+-+-+-+-+-+-+-+
Figure 5: Access Unit Data Section; each AU is octet-aligned.
图5：访问单元数据部分；每个AU都是八位组对齐的。
When multiple Access Units are carried, the size of each AU MUST be made available to the receiver. If the AU size is variable, then the size of each AU MUST be indicated in the AU-size field of the corresponding AU-header. However, if the AU size is constant for a stream, this mechanism SHOULD NOT be used; instead, the fixed size SHOULD be signaled by the MIME format parameter "constantSize"; see section 4.1.
当携带多个接入单元时，必须向接收器提供每个AU的大小。如果AU大小可变，则必须在相应AU标题的AU大小字段中指示每个AU的大小。然而，如果流的AU尺寸恒定，则不应使用该机制；相反，固定大小应该由MIME格式参数“constantSize”表示；见第4.1节。
The absence of both AU-size in the AU-header and the constantSize MIME format parameter indicates the carriage of a single AU (fragment), i.e., that a single Access Unit (fragment) is transported in each RTP packet for that stream.
AU报头和constantSize MIME format参数中都没有AU大小，这表明携带了单个AU（片段），即，在该流的每个RTP数据包中传输单个访问单元（片段）。
A packet SHALL carry either one or more complete Access Units, or a single fragment of an Access Unit. Fragments of the same Access Unit have the same time stamp but different RTP sequence numbers. The marker bit in the RTP header is 1 on the last fragment of an Access Unit, and 0 on all other fragments.
数据包应携带一个或多个完整的访问单元，或一个访问单元的单个片段。同一访问单元的片段具有相同的时间戳，但RTP序列号不同。RTP头中的标记位在访问单元的最后一个片段上为1，在所有其他片段上为0。
Unless prohibited by the signaled mode, a sender MAY interleave Access Units. Receivers that are capable of receiving modes that support interleaving MUST be able to decode interleaved Access Units.
除非信号模式禁止，否则发送方可以交错接入单元。能够接收支持交织的模式的接收机必须能够解码交织的接入单元。
When a sender interleaves Access Units, it needs to provide sufficient information to enable a receiver to unambiguously reconstruct the original order, even in the case of out-of-order packets, packet loss or duplication. The information that senders need to provide depends on whether or not the Access Units have a constant time duration. Access Units have a constant time duration, if:
当发送方交错接入单元时，它需要提供足够的信息，以使接收方能够毫不含糊地重建原始顺序，即使在顺序错误的数据包、数据包丢失或重复的情况下也是如此。发送方需要提供的信息取决于访问单元是否具有恒定的持续时间。访问单元具有恒定的持续时间，如果：
TS(i+1) - TS(i) = constant
TS(i+1) - TS(i) = constant
for any i, where: i indicates the index of the AU in the original order, and TS(i) denotes the time stamp of AU(i)
对于任何i，其中：i表示AU的原始顺序索引，TS（i）表示AU（i）的时间戳
The MIME parameter "constantDuration" SHOULD be used to signal that Access Units have a constant time duration; see section 4.1.
MIME参数“constantDuration”应用于表示访问单元具有恒定的持续时间；见第4.1节。
If the "constantDuration" parameter is present, the receiver can reconstruct the original Access Unit timing based solely on the RTP timestamp and AU-Index-delta. Accordingly, when transmitting Access Units of constant duration, the AU-Index, if present, MUST be set to
如果存在“constantDuration”参数，则接收机可以仅基于RTP时间戳和AU索引增量重构原始接入单元定时。因此，当发送恒定持续时间的接入单元时，必须将AU索引（如果存在）设置为
the value 0. Receivers of constant duration Access Units MUST use the RTP timestamp to determine the index of the first AU in the RTP packet. The AU-Index-delta header and the signaled "constantDuration" are used to reconstruct AU timing.
值为0。恒定持续时间访问单元的接收器必须使用RTP时间戳来确定RTP数据包中第一个AU的索引。AU索引增量标头和信号“constantDuration”用于重建AU定时。
If the "constantDuration" parameter is not present, then senders MAY signal AUs of constant duration by coding the AU-Index with zero in each RTP packet. In the absence of the constantDuration parameter receivers MUST conclude that the AUs have constant duration if the AU-index is zero in two consecutive RTP packets.
如果“constantDuration”参数不存在，则发送方可以通过在每个RTP数据包中将AU索引编码为零来发送持续时间恒定的AU信号。在缺少恒定持续时间参数的情况下，如果两个连续RTP数据包中的AU索引为零，则接收机必须得出AU具有恒定持续时间的结论。
When transmitting Access Units of variable duration, then the "constantDuration" parameter MUST NOT be present, and the transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of each AU in the RTP packet. The number of bits of the AU-Index field MUST be chosen so that valid index information is provided at the applied interleaving scheme, without causing problems due to roll-over of the AU-Index field. In addition, the CTS-delta MUST be coded in the AU header for each non-first AU in the RTP packet, so that receivers can place the AUs correctly in time.
当发送可变持续时间的接入单元时，则“constantDuration”参数不得存在，并且发射机必须使用AU索引来编码重新排序所需的索引信息，并且接收机必须使用该值来确定RTP分组中每个AU的索引。必须选择AU索引字段的位数，以便在应用的交织方案中提供有效的索引信息，而不会由于AU索引字段的滚动而导致问题。此外，对于RTP数据包中的每个非第一个AU，必须在AU报头中对CTS增量进行编码，以便接收机能够及时正确放置AU。
When interleaving is applied, a de-interleave buffer is needed in receivers to put the Access Units in their correct logical consecutive decoding order. This requires the computation of the time stamp for each Access Unit. In case of a constant time duration per Access Unit, the time stamp of the i-th access unit in an RTP packet with RTP time stamp T is calculated as follows:
当应用交织时，接收机中需要一个解交织缓冲器，以将接入单元置于其正确的逻辑连续解码顺序中。这需要计算每个访问单元的时间戳。在每个接入单元的持续时间恒定的情况下，具有RTP时间戳T的RTP分组中的第i接入单元的时间戳计算如下：
Timestamp[0] = T
Timestamp[i, i > 0] = T +(Sum(for k=1 to i of (AU-Index-delta[k]
+ 1))) * access-unit-duration
Timestamp[0] = T
Timestamp[i, i > 0] = T +(Sum(for k=1 to i of (AU-Index-delta[k]
+ 1))) * access-unit-duration
When AU-Index-delta is always 0, this reduces to T + i * (access-unit-duration). This is the non-interleaved case, where the frames are consecutive in decoding order. Note that the AU-Index field (present for the first Access Unit) is indeed not needed in this calculation.
当AU索引增量始终为0时，这将减少到T+i*（访问单元持续时间）。这是非交织情况，其中帧在解码顺序上是连续的。注意，在该计算中确实不需要AU索引字段（第一访问单元的索引字段）。
The size of the packets should be suitably chosen to be appropriate to both the path MTU and the capacity of the receiver's de-interleave buffer. The maximum packet size for a session SHOULD be chosen to not exceed the path MTU.
分组的大小应适当地选择为适合于路径MTU和接收机的解交织缓冲器的容量。会话的最大数据包大小应选择为不超过路径MTU。
To allow receivers to allocate sufficient resources for de-interleaving, senders MUST provide the information to receivers as specified in this section.
为了允许接收方为解交织分配足够的资源，发送方必须按照本节的规定向接收方提供信息。
AUs enter the decoder in decoding order. The de-interleave buffer is used to re-order a stream of interleaved AUs back into decoding order. When interleaving is applied, the decoding of "early" AUs has to be postponed until all AUs that precede it in decoding order are present. Therefore, these "early" AUs are stored in the de-interleave buffer. As an example in Figure 6, the interleaving pattern from section 2.5 is considered.
AUs按解码顺序输入解码器。解交织缓冲器用于将交织的AU流重新排序为解码顺序。当应用交织时，“早期”AU的解码必须延迟，直到在解码顺序中位于其之前的所有AU都存在。因此，这些“早期”AU存储在解交织缓冲器中。作为图6中的示例，考虑了第2.5节中的交织模式。
+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
+--+--+--+--+--+--+--+--+--+--+--+-
Storage of "early" AUs 3 3 3 3 3 3
6 6 6 6 6 6
4 4 4
7 7 7
12 12
+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
+--+--+--+--+--+--+--+--+--+--+--+-
Storage of "early" AUs 3 3 3 3 3 3
6 6 6 6 6 6
4 4 4
7 7 7
12 12
Figure 6: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
图6：每个交织AU在反交织缓冲区中的“早期”AU存储。
AU(3) is to be delivered to the decoder after AU(0), AU(1) and AU(2); of these AUs, AU(2) arrives from the network last and hence AU(3) needs to be stored until AU(2) is present in the pattern. Similarly, AU(6) is to be stored until AU(5) is present, while AU(4) and AU(7) are to be stored until AU(2) and AU(5) are present, respectively. Note that the fullness of the de-interleave buffer varies in time. In Figure 6, the de-interleave buffer contains at most 4, but often less AUs.
AU（3）在AU（0）、AU（1）和AU（2）之后被传送到解码器；在这些AU中，AU（2）最后从网络到达，因此需要存储AU（3），直到AU（2）出现在模式中。类似地，AU（6）将被存储直到AU（5）存在，而AU（4）和AU（7）将被存储直到AU（2）和AU（5）分别存在。请注意，反交织缓冲区的满度随时间而变化。在图6中，解交织缓冲区最多包含4个AU，但通常较少。
So as to give a rough indication of the resources needed in the receiver for de-interleaving, the maximum displacement in time of an AU is defined. For any AU(j) in the pattern, each AU(i) with i<j that is not yet present can be determined. The maximum displacement in time of an AU is the maximum difference between the time stamp of an AU in the pattern and the time stamp of the earliest AU that is not yet present. In other words, when considering a sequence of interleaved AUs, then:
为了给出接收机中解交织所需资源的粗略指示，定义了AU的最大时间位移。对于模式中的任何AU（j），可以确定i<j的每个AU（i）尚未存在。AU的最大时间位移是模式中AU的时间戳与尚未出现的最早AU的时间戳之间的最大差异。换句话说，当考虑交错AU序列时，则：
Maximum displacement = max{TS(i) - TS(j)}
Maximum displacement = max{TS(i) - TS(j)}
for any i and any j>i, where: i and j indicate the index of the AU in the interleaving pattern, and TS denotes the time stamp of the AU.
对于任意i和任意j>i，其中：i和j表示交织模式中AU的索引，TS表示AU的时间戳。
As an example in Figure 7, the interleaving pattern from section 2.5 is considered. For each AU in the pattern, the index is given of the earliest of any earlier AUs not yet present. Hence for each AU(n) in the interleaving pattern the smallest index k (with k<n) of not yet delivered AUs is indicated. A "-" indicates that all previous AUs are present. If the AU period is constant, the maximum displacement equals 5 AU periods, as found for AU(6) and AU(7).
作为图7中的示例，考虑了第2.5节中的交织模式。对于模式中的每个AU，给出了尚未出现的任何早期AU中最早的AU的索引。因此，对于交织模式中的每个AU（n），指示尚未递送的AU的最小索引k（k<n）。“-”表示所有以前的AU都存在。如果AU周期为常数，则最大位移等于5个AU周期，如AU（6）和AU（7）所示。
+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
+--+--+--+--+--+--+--+--+--+--+--+-
+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
+--+--+--+--+--+--+--+--+--+--+--+-
Earliest not yet present AU - 1 1 - 2 2 - - - - 10
Earliest not yet present AU - 1 1 - 2 2 - - - - 10
Figure 7: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
图7：对于交错模式中的每个AU，任何早期AU中最早的AU尚未出现
When interleaving, senders MUST signal the maximum displacement in time during the session via the MIME format parameter "maxDisplacement"; see section 4.1.
交织时，发送方必须在会话期间通过MIME格式参数“maxDisplacement”及时发出最大位移信号；见第4.1节。
An estimate of the size of the de-interleave buffer is found by multiplying the maximum displacement by the maximum bit rate:
通过将最大位移乘以最大比特率，找到解交织缓冲器大小的估计值：
size(de-interleave buffer) = {(maxDisplacement) * Rate(max)} / (RTP
clock frequency),
size(de-interleave buffer) = {(maxDisplacement) * Rate(max)} / (RTP
clock frequency),
where: Rate(max) is the maximum bit-rate of the transported stream.
其中：速率（max）是传输流的最大比特率。
Note that receivers can derive Rate(max) from the MIME format parameters streamType, profile-level-id, and config.
请注意，接收者可以从MIME格式参数streamType、概要文件级别id和config派生速率（max）。
However, this calculation estimates the size of the de-interleave buffer and the required size may differ from the calculated value. If this calculation under-estimates the size of the de-interleave buffer, then senders, when interleaving, MUST signal a size of the de-interleave buffer via the MIME format parameter "de-interleaveBufferSize"; see section 4.1. If the calculation over-estimates the size of the de-interleave buffer, then senders, when interleaving, MAY signal a size of the de-interleave buffer via the MIME format parameter "de-interleaveBufferSize".
然而，该计算估计解交织缓冲器的大小，并且所需大小可能与计算值不同。如果此计算低估了解交织缓冲区的大小，则发送方在交织时必须通过MIME格式参数“解交织缓冲区大小”发出解交织缓冲区大小的信号；见第4.1节。如果计算过度估计解交织缓冲区的大小，则发送方在交织时可以通过MIME格式参数“解交织缓冲区大小”来发送解交织缓冲区的大小的信号。
The signaled size of the de-interleave buffer MUST be large enough to contain all "early" AUs at any point in time during the session. That is:
解交织缓冲区的信号大小必须足够大，以包含会话期间任何时间点的所有“早期”AU。即:
minimum de-interleave buffer size = max [sum {if TS(i) > TS(j) then
AU-size(i) else 0}]
minimum de-interleave buffer size = max [sum {if TS(i) > TS(j) then
AU-size(i) else 0}]
for any j and any i<j, where: i and j indicate the index of an AU in the interleaving pattern, TS(i) denotes the time stamp of AU(i), and AU-size(i) denotes the size of AU(i) in number of octets.
对于任意j和任意i<j，其中：i和j表示交错模式中AU的索引，TS（i）表示AU（i）的时间戳，AU size（i）表示AU（i）的大小（以八位组为单位）。
If the "de-interleaveBufferSize" parameter is present, then the applied buffer for de-interleaving in a receiver MUST have a size that is at least equal to the signaled size of the de-interleave buffer, else a size that is at least equal to the calculated size of the de-interleave buffer.
如果存在“解交织缓冲区大小”参数，则接收机中用于解交织的应用缓冲区的大小必须至少等于解交织缓冲区的信号大小，否则至少等于解交织缓冲区的计算大小。
No matter what interleaving scheme is used, the scheme must be analyzed to calculate the applicable maxDisplacement value, as well as the required size of the de-interleave buffer. Senders SHOULD signal values that are not larger than the strictly required values; if larger values are signaled, the receiver will buffer excessively.
无论使用何种交织方案，都必须对该方案进行分析，以计算适用的最大位移值以及所需的解交织缓冲区大小。发送方应发出不大于严格要求值的信号；如果发送较大值的信号，接收器将过度缓冲。
Note that for low bit-rate material, the applied interleaving may make packets shorter than the MTU size.
注意，对于低比特率材料，应用的交织可使分组短于MTU大小。
Some Access Units with MPEG-4 system data, called "crucial" AUs, carry information whose loss cannot be tolerated, either in the presentation or in the decoder. At each crucial AU in an MPEG-4 system stream, the stream state changes. The stream-state MAY remain constant at non-crucial AUs. In ISO/IEC 14496-1, MPEG-4 system streams use the AU_SequenceNumber to signal stream states.
一些带有MPEG-4系统数据的访问单元称为“关键”AU，它们携带的信息无论是在演示文稿中还是在解码器中都无法容忍丢失。在MPEG-4系统流中的每个关键AU处，流状态改变。流状态可能在非关键AU处保持不变。在ISO/IEC 14496-1中，MPEG-4系统流使用AU_SequenceNumber来表示流状态。
Example: Given three AUs, AU1 = "Insertion of node X", AU2 = "Set position of node X", AU3 = "Set position of node X". AU1 is crucial, since if it is lost, AU2 cannot be executed. However, AU2 is not crucial, since AU3 can be executed even if AU2 is lost.
示例：给定三个AU，AU1=“插入节点X”，AU2=“设置节点X的位置”，AU3=“设置节点X的位置”。AU1至关重要，因为如果它丢失，AU2将无法执行。然而，AU2并不重要，因为即使AU2丢失，也可以执行AU3。
When a crucial AU is (possibly) lost, the stream is corrupted. For example, when an AU is lost and the stream state has changed at the next received AU, then it is possible that the lost AU was crucial. Once corrupted, the stream remains corrupted until the next random access point. Note that loss of non-crucial AUs does not corrupt the stream. When a decoder starts receiving a stream, the decoder MUST
当关键AU（可能）丢失时，流被破坏。例如，当一个AU丢失并且流状态在下一个接收到的AU发生变化时，丢失的AU可能是关键的。一旦损坏，流将一直损坏，直到下一个随机访问点。请注意，非关键AU的丢失不会损坏流。当解码器开始接收流时，解码器必须
consider the stream corrupted until an AU is received that provides a random access point.
考虑流被破坏直到接收到提供随机接入点的AU。
An AU that provides a random access point, as signaled by the RAP-flag, may or may not be crucial. Non-crucial RAP AUs provide a "repeated" random access point for use by decoders that recently joined the stream or that need to re-start decoding after a stream corruption. Non-crucial RAP AUs MUST include all updates since the last crucial RAP AU.
如RAP标志所示，提供随机接入点的AU可能至关重要，也可能不至关重要。非关键RAP AU提供“重复”随机接入点，供最近加入流或在流损坏后需要重新开始解码的解码器使用。非关键RAP AU必须包括自上次关键RAP AU以来的所有更新。
Upon receiving AUs, decoders are to react as follows:
接收到AUs后，解码器的反应如下：
a) if the RAP-flag is set to 1 and the stream-state changes, then the AU is a crucial RAP AU, and the AU MUST be decoded.
a) 如果RAP标志设置为1且流状态改变，则AU是关键RAP AU，且必须对AU进行解码。
b) if the RAP-flag is set to 1 and the stream state does not change, then the AU is a non-crucial RAP AU, and the receiver SHOULD decode it if the stream is corrupted. Otherwise, the decoder MUST ignore the AU.
b) 如果RAP标志设置为1且流状态未改变，则AU为非关键RAP AU，并且如果流损坏，则接收器应对其进行解码。否则，解码器必须忽略AU。
c) if the RAP-flag is set to 0, then the AU MUST be decoded, unless the stream is corrupted, in which case the AU MUST be ignored.
c) 如果RAP标志设置为0，则必须解码AU，除非流损坏，在这种情况下必须忽略AU。
Usage of this specification requires definition of a mode. A mode defines how to use this specification, as deemed appropriate. Senders MUST signal the applied mode via the MIME format parameter "mode", as specified in section 4.1. This specification defines a generic mode that can be used for any MPEG-4 stream, as well as specific modes for the transportation of MPEG-4 CELP and MPEG-4 AAC streams, defined in ISO/IEC 14496-3 [1].
使用本规范需要定义模式。模式定义了如何使用本规范（视情况而定）。发送方必须按照第4.1节的规定，通过MIME格式参数“mode”发出应用模式的信号。本规范定义了可用于任何MPEG-4流的通用模式，以及ISO/IEC 14496-3[1]中定义的用于传输MPEG-4 CELP和MPEG-4 AAC流的特定模式。
When use of this payload format is signaled using SDP [5], an "rtpmap" attribute is part of that signaling. The same requirements apply for the rtpmap attribute in any mode compliant to this specification. The general form of an rtpmap attribute is:
当使用SDP[5]发出使用此有效负载格式的信号时，“rtpmap”属性是该信号的一部分。相同的要求适用于符合本规范的任何模式下的rtpmap属性。rtpmap属性的一般形式为：
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
For audio streams, <encoding parameters> specifies the number of audio channels: 2 for stereo material (see RFC 2327 [5]) and 1 for mono. Provided no additional parameters are needed, this parameter may be omitted for mono material, hence its default value is 1.
对于音频流，<encoding parameters>指定音频通道的数量：2个用于立体声材质（请参见RFC 2327[5]），1个用于单声道。如果不需要其他参数，则对于mono材质可以忽略此参数，因此其默认值为1。
The generic mode can be used for any MPEG-4 stream. In this mode, no mode-specific constraints are applied; hence, in the generic mode, the full flexibility of this specification can be exploited. The generic mode is signaled by mode=generic.
通用模式可用于任何MPEG-4流。在此模式中，不应用特定于模式的约束；因此，在通用模式下，可以充分利用该规范的灵活性。通用模式由模式=通用发出信号。
An example is given below for the transportation of a BIFS-Anim stream. In this example carriage of multiple BIFS-Anim Access Units is allowed in one RTP packet. The AU-header contains the AU-size field, the CTS-flag and, if the CTS flag is set to 1, the CTS-delta field. The number of bits of the AU-size and the CTS-delta fields are 10 and 16, respectively. The AU-header also contains the RAP-flag and the Stream-state of 4 bits. This results in an AU-header with a total size of two or four octets per BIFS-Anim AU. The RTP time stamp uses a 1 kHz clock. Note that the media type name is video, because the BIFS-Anim stream is part of an audio-visual presentation. For conventions on media type names, see section 4.1.
下面给出了BIFS动画流的传输示例。在此示例中，一个RTP数据包中允许携带多个BIFS动画访问单元。AU标头包含AU大小字段、CTS标志，如果CTS标志设置为1，则包含CTS增量字段。AU大小和CTS delta字段的位数分别为10和16。AU报头还包含RAP标志和4位的流状态。这导致每个BIFS Anim AU的AU头总大小为两个或四个八位组。RTP时间戳使用1 kHz时钟。请注意，媒体类型名称为“视频”，因为BIFS动画流是视听演示的一部分。有关媒体类型名称的约定，请参见第4.1节。
In detail:
详细内容：
m=video 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/1000
a=fmtp:96 streamtype=3; profile-level-id=1807; mode=generic;
objectType=2; config=0842237F24001FB400094002C0; sizeLength=10;
CTSDeltaLength=16; randomAccessIndication=1;
streamStateIndication=4
m=video 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/1000
a=fmtp:96 streamtype=3; profile-level-id=1807; mode=generic;
objectType=2; config=0842237F24001FB400094002C0; sizeLength=10;
CTSDeltaLength=16; randomAccessIndication=1;
streamStateIndication=4
Note: The a=fmtp line has been wrapped to fit the page, it comprises a single line in the SDP file.
注意：a=fmtp行已被包装以适合页面，它在SDP文件中包含一行。
The hexadecimal value of the "config" parameter is the BIFSConfiguration() as defined in ISO/IEC 14496-1. The BIFSConfiguration() specifies that the BIFS stream is a BIFS-Anim stream. For the description of MIME parameters, see section 4.1.
“config”参数的十六进制值是ISO/IEC 14496-1中定义的BIFSConfiguration（）。BIFSConfiguration（）指定BIFS流是BIFS动画流。有关MIME参数的描述，请参见第4.1节。
This mode is signaled by mode=CELP-cbr. In this mode, one or more complete CELP frames of fixed size can be transported in one RTP packet; interleaving MUST NOT be used with this mode. The RTP payload consists of one or more concatenated CELP frames, each of equal size. CELP frames MUST NOT be fragmented when using this mode. Both the AU Header Section and the Auxiliary Section MUST be empty.
该模式由模式=CELP cbr发出信号。在此模式中，一个或多个固定大小的完整CELP帧可以在一个RTP分组中传输；交织不能与此模式一起使用。RTP有效负载由一个或多个串联的CELP帧组成，每个帧的大小相同。使用此模式时，CELP帧不得分段。AU标题部分和辅助部分都必须为空。
The MIME format parameter constantSize MUST be provided to specify the length of each CELP frame.
必须提供MIME格式参数constantSize以指定每个CELP帧的长度。
For example:
例如：
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-cbr; config=
440E00; constantSize=27; constantDuration=240
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-cbr; config=
440E00; constantSize=27; constantDuration=240
Note: The a=fmtp line has been wrapped to fit the page, it comprises a single line in the SDP file.
注意：a=fmtp行已被包装以适合页面，它在SDP文件中包含一行。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig()as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono CELP stream with a sampling rate of 16 kHz at a fixed bitrate of 14.4 kb/s and 6 sub-frames per CELP frame. For the description of MIME parameters, see section 4.1.
“config”参数的十六进制值是ISO/IEC 14496-3中定义的AudioSpecificConfig（）。AudioSpecificConfig（）指定采样率为16 kHz、固定比特率为14.4 kb/s和每个CELP帧6个子帧的mono CELP流。有关MIME参数的描述，请参见第4.1节。
This mode is signaled by mode=CELP-vbr. With this mode, one or more complete CELP frames of variable size can be transported in one RTP packet with OPTIONAL interleaving. In this mode, the largest possible value for AU-size is greater than the maximum CELP frame size. Because CELP frames are very small, there is no support for fragmentation of CELP frames. Hence, CELP frames MUST NOT be fragmented when using this mode.
该模式由mode=CELP vbr发出信号。在这种模式下，一个或多个可变大小的完整CELP帧可以通过可选的交织在一个RTP包中传输。在此模式下，AU大小的最大可能值大于最大CELP帧大小。因为CELP帧非常小，所以不支持CELP帧的分段。因此，在使用此模式时，CELP帧不得分段。
In this mode, the RTP payload consists of the AU Header Section, followed by one or more concatenated CELP frames. The Auxiliary Section MUST be empty. For each CELP frame contained in the payload, there MUST be a one octet AU-header in the AU Header Section to provide:
在此模式下，RTP有效负载由AU报头部分组成，后面是一个或多个连接的CELP帧。辅助部分必须为空。对于有效负载中包含的每个CELP帧，在AU报头部分中必须有一个八位组AU报头，以提供：
a) the size of each CELP frame in the payload and
a) 有效负载中每个CELP帧的大小，以及
b) index information for computing the sequence (and hence timing) of each CELP frame.
b) 用于计算每个CELP帧的序列（以及由此产生的定时）的索引信息。
Transport of CELP frames requires that the AU-size field be coded with 6 bits. Therefore, in this mode 6 bits are allocated to the AU-size field, and 2 bits to the AU-Index(-delta) field. Each AU-Index field MUST be coded with the value 0. In the AU Header Section, the concatenated AU-headers are preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
CELP帧的传输要求AU大小字段编码为6位。因此，在此模式下，6位分配给AU大小字段，2位分配给AU索引（-delta）字段。每个AU索引字段必须用值0编码。如第3.2.1节所述，在AU头部分中，连接的AU头前面有16位AU头长度字段。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. CELP frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration
除了必需的MIME格式参数外，还必须存在以下参数：sizeLength、indexLength和IndexDeltagent。CELP帧始终具有每个访问单元的固定持续时间；在此模式下交错时，此特定持续时间
MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
必须由MIME格式参数constantDuration发出信号。此外，交错时必须存在参数maxDisplacement。
For example:
例如：
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-vbr; config=
440F20; sizeLength=6; indexLength=2; indexDeltaLength=2;
constantDuration=160; maxDisplacement=5
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-vbr; config=
440F20; sizeLength=6; indexLength=2; indexDeltaLength=2;
constantDuration=160; maxDisplacement=5
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注：a=fmtp行已包装以适合页面；它包含SDP文件中的一行。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig() as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono CELP stream with a sampling rate of 16 kHz, at a bitrate that varies between 13.9 and 16.2 kb/s and with 4 sub-frames per CELP frame. For the description of MIME parameters, see section 4.1.
“config”参数的十六进制值是ISO/IEC 14496-3中定义的AudioSpecificConfig（）。AudioSpecificConfig（）指定采样率为16 kHz的mono CELP流，比特率在13.9和16.2 kb/s之间变化，每个CELP帧有4个子帧。有关MIME参数的描述，请参见第4.1节。
This mode is signaled by mode=AAC-lbr. This mode supports the transportation of one or more complete AAC frames of variable size. In this mode, the AAC frames are allowed to be interleaved and hence receivers MUST support de-interleaving. The maximum size of an AAC frame in this mode is 63 octets. AAC frames MUST NOT be fragmented when using this mode. Hence, when using this mode, encoders MUST ensure that the size of each AAC frame is at most 63 octets.
该模式由模式=AAC lbr发出信号。此模式支持一个或多个完整的可变尺寸AAC框架的运输。在这种模式下，AAC帧允许交织，因此接收机必须支持解交织。此模式下AAC帧的最大大小为63个八位字节。使用此模式时，AAC帧不得分段。因此，使用此模式时，编码器必须确保每个AAC帧的大小最多为63个八位字节。
The payload configuration in this mode is the same as in the variable bit-rate CELP mode as defined in 3.3.4. The RTP payload consists of the AU Header Section, followed by concatenated AAC frames. The Auxiliary Section MUST be empty. For each AAC frame contained in the payload, the one octet AU-header MUST provide:
此模式下的有效负载配置与3.3.4中定义的可变比特率CELP模式下的有效负载配置相同。RTP有效负载由AU报头部分组成，后面是连接的AAC帧。辅助部分必须为空。对于有效负载中包含的每个AAC帧，一个八位组AU报头必须提供：
a) the size of each AAC frame in the payload and
a) 有效负载中每个AAC帧的大小，以及
b) index information for computing the sequence (and hence timing) of each AAC frame.
b) 用于计算每个AAC帧的序列（以及由此产生的定时）的索引信息。
In the AU-header Section, the concatenated AU-headers MUST be preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
如第3.2.1节所述，在AU头部分中，串联的AU头前面必须有16位AU头长度字段。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. AAC frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
除了必需的MIME格式参数外，还必须存在以下参数：sizeLength、indexLength和IndexDeltagent。AAC帧始终具有每个接入单元的固定持续时间；在此模式下交错时，此特定持续时间必须由MIME格式参数constantDuration发出信号。此外，交错时必须存在参数maxDisplacement。
For example:
例如：
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/22050/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=AAC-lbr; config=
1388; sizeLength=6; indexLength=2; indexDeltaLength=2;
constantDuration=1024; maxDisplacement=5
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/22050/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=AAC-lbr; config=
1388; sizeLength=6; indexLength=2; indexDeltaLength=2;
constantDuration=1024; maxDisplacement=5
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注：a=fmtp行已包装以适合页面；它包含SDP文件中的一行。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig(), as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono AAC stream with a sampling rate of 22.05 kHz. For the description of MIME parameters, see section 4.1.
“config”参数的十六进制值是AudioSpecificConfig（），如ISO/IEC 14496-3中所定义。AudioSpecificConfig（）指定采样率为22.05 kHz的单声道AAC流。有关MIME参数的描述，请参见第4.1节。
This mode is signaled by mode=AAC-hbr. This mode supports the transportation of variable size AAC frames. In one RTP packet, either one or more complete AAC frames are carried, or a single fragment of an AAC frame is carried. In this mode, the AAC frames are allowed to be interleaved and hence receivers MUST support de-interleaving. The maximum size of an AAC frame in this mode is 8191 octets.
该模式由模式=AAC hbr发出信号。此模式支持传输可变大小的AAC框架。在一个RTP包中，携带一个或多个完整的AAC帧，或者携带AAC帧的单个片段。在这种模式下，AAC帧允许交织，因此接收机必须支持解交织。此模式下AAC帧的最大大小为8191个八位字节。
In this mode, the RTP payload consists of the AU Header Section, followed by either one AAC frame, several concatenated AAC frames or one fragmented AAC frame. The Auxiliary Section MUST be empty. For each AAC frame contained in the payload, there MUST be an AU-header in the AU Header Section to provide:
在此模式下，RTP有效负载由AU报头部分组成，后面是一个AAC帧、几个串联的AAC帧或一个分段的AAC帧。辅助部分必须为空。对于有效负载中包含的每个AAC帧，AU报头部分中必须有一个AU报头，以提供：
a) the size of each AAC frame in the payload and
a) 有效负载中每个AAC帧的大小，以及
b) index information for computing the sequence (and hence timing) of each AAC frame.
b) 用于计算每个AAC帧的序列（以及由此产生的定时）的索引信息。
To code the maximum size of an AAC frame requires 13 bits. Therefore, in this configuration 13 bits are allocated to the AU-size, and 3 bits to the AU-Index(-delta) field. Thus, each AU-header
编码AAC帧的最大大小需要13位。因此，在此配置中，13位分配给AU大小，3位分配给AU索引（-delta）字段。因此，每个AU头
has a size of 2 octets. Each AU-Index field MUST be coded with the value 0. In the AU Header Section, the concatenated AU-headers MUST be preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
大小为2个八位组。每个AU索引字段必须用值0编码。如第3.2.1节所述，在AU头部分中，串联的AU头前面必须有16位AU头长度字段。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. AAC frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
除了必需的MIME格式参数外，还必须存在以下参数：sizeLength、indexLength和IndexDeltagent。AAC帧始终具有每个接入单元的固定持续时间；在此模式下交错时，此特定持续时间必须由MIME格式参数constantDuration发出信号。此外，交错时必须存在参数maxDisplacement。
For example:
例如：
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/6
a=fmtp:96 streamtype=5; profile-level-id=16; mode=AAC-hbr;
config=11B0; sizeLength=13; indexLength=3;
indexDeltaLength=3; constantDuration=1024
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/6
a=fmtp:96 streamtype=5; profile-level-id=16; mode=AAC-hbr;
config=11B0; sizeLength=13; indexLength=3;
indexDeltaLength=3; constantDuration=1024
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注：a=fmtp行已包装以适合页面；它包含SDP文件中的一行。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig(), as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a 5.1 channel AAC stream with a sampling rate of 48 kHz. For the description of MIME parameters, see section 4.1.
“config”参数的十六进制值是AudioSpecificConfig（），如ISO/IEC 14496-3中所定义。AudioSpecificConfig（）指定采样率为48 kHz的5.1通道AAC流。有关MIME参数的描述，请参见第4.1节。
This specification only defines the modes specified in sections 3.3.2 through 3.3.6. Additional modes are expected to be defined in future RFCs. Each additional mode MUST be in full compliance with this specification.
本规范仅定义了第3.3.2节至第3.3.6节中规定的模式。其他模式预计将在未来的RFC中定义。每个附加模式必须完全符合本规范。
Any new mode MUST be defined such that an implementation including all the features of this specification can decode the payload format corresponding to this new mode. For this reason, a mode MUST NOT specify new default values for MIME parameters. In particular, MIME parameters that configure the RTP payload MUST be present (unless they have the default value), even if its presence is redundant in case the mode assigns a fixed value to a parameter. A mode may additionally define that some MIME parameters are required instead of optional, that some MIME parameters have fixed values (or ranges), and that there are rules restricting its usage.
必须定义任何新模式，以便包括本规范所有特征的实现能够解码对应于该新模式的有效载荷格式。因此，模式不能为MIME参数指定新的默认值。特别是，配置RTP有效负载的MIME参数必须存在（除非它们具有默认值），即使在模式为参数指定固定值的情况下其存在是冗余的。模式还可以定义某些MIME参数是必需的而不是可选的，某些MIME参数具有固定值（或范围），并且存在限制其使用的规则。
This section describes the MIME types and names associated with this payload format. Section 4.1 registers the MIME types, as per RFC 2048 [3].
本节介绍与此有效负载格式关联的MIME类型和名称。根据RFC 2048[3]，第4.1节注册MIME类型。
This format may require additional information about the mapping to be made available to the receiver. This is done using parameters described in the next section.
此格式可能需要向接收方提供有关映射的附加信息。这是使用下一节中描述的参数完成的。
MIME media type name: "video" or "audio" or "application"
MIME媒体类型名称：“视频”或“音频”或“应用程序”
"video" MUST be used for MPEG-4 Visual streams (ISO/IEC 14496-2) or MPEG-4 Systems streams (ISO/IEC 14496-1) that convey information needed for an audio/visual presentation.
“视频”必须用于传输音频/视频演示所需信息的MPEG-4视频流（ISO/IEC 14496-2）或MPEG-4系统流（ISO/IEC 14496-1）。
"audio" MUST be used for MPEG-4 Audio streams (ISO/IEC 14496-3) or MPEG-4 Systems streams that convey information needed for an audio only presentation.
“音频”必须用于传输仅音频演示所需信息的MPEG-4音频流（ISO/IEC 14496-3）或MPEG-4系统流。
"application" MUST be used for MPEG-4 Systems streams (ISO/IEC 14496-1) that serve purposes other than audio/visual presentation, e.g., in some cases when MPEG-J (Java) streams are transmitted.
“应用程序”必须用于MPEG-4系统流（ISO/IEC 14496-1），该系统流用于音频/视频演示以外的目的，例如，在某些情况下，当传输MPEG-J（Java）流时。
Depending on the required payload configuration, MIME format parameters may need to be available to the receiver. This is done using the parameters described in the next section. There are required and optional parameters.
根据所需的有效负载配置，MIME格式参数可能需要对接收器可用。这是使用下一节中描述的参数完成的。有必需参数和可选参数。
Optional parameters are of two types: general parameters and configuration parameters. The configuration parameters are used to configure the fields in the AU Header section and in the auxiliary section. The absence of any configuration parameter is equivalent to the associated field set to its default value, which is always zero. The absence of all configuration parameters results in a default "basic" configuration with an empty AU-header section and an empty auxiliary section in each RTP packet.
可选参数有两种类型：常规参数和配置参数。配置参数用于配置AU标头部分和辅助部分中的字段。缺少任何配置参数相当于将关联字段设置为其默认值（始终为零）。缺少所有配置参数会导致默认的“基本”配置，每个RTP数据包中都有一个空的AU头部分和一个空的辅助部分。
MIME subtype name: mpeg4-generic
MIME子类型名称：mpeg4通用
Required parameters:
所需参数：
MIME format parameters are not case dependent; for clarity however, both upper and lower case are used in the names of the parameters described in this specification.
MIME格式参数不依赖于大小写；然而，为了清楚起见，在本规范中描述的参数名称中使用了大写和小写。
streamType: The integer value that indicates the type of MPEG-4 stream that is carried; its coding corresponds to the values of the streamType, as defined in Table 9 (streamType Values) in ISO/IEC 14496-1.
streamType：表示所携带的MPEG-4流类型的整数值；其编码对应于ISO/IEC 14496-1表9（流型值）中定义的流型值。
profile-level-id: A decimal representation of the MPEG-4 Profile Level indication. This parameter MUST be used in the capability exchange or session set-up procedure to indicate the MPEG-4 Profile and Level combination of which the relevant MPEG-4 media codec is capable.
配置文件级别id：MPEG-4配置文件级别指示的十进制表示。此参数必须在功能交换或会话设置过程中使用，以指示相关MPEG-4媒体编解码器能够使用的MPEG-4配置文件和级别组合。
For MPEG-4 Audio streams, this parameter is the decimal value from Table 5 (audioProfileLevelIndication Values) in ISO/IEC 14496- 1, indicating which MPEG-4 Audio tool subsets are required to decode the audio stream.
对于MPEG-4音频流，此参数是ISO/IEC 14496-1中表5（audioProfileLevelIndication Values）中的十进制值，表示解码音频流需要哪些MPEG-4音频工具子集。
For MPEG-4 Visual streams, this parameter is the decimal value from Table G-1 (FLC table for profile and level indication) of ISO/IEC 14496-2 [1], indicating which MPEG-4 Visual tool subsets are required to decode the visual stream.
对于MPEG-4视频流，该参数是ISO/IEC 14496-2[1]表G-1（轮廓和级别指示的FLC表）中的十进制值，表示解码视频流需要哪些MPEG-4视频工具子集。
For BIFS streams, this parameter is the decimal value obtained from (SPLI + 256*GPLI), where: SPLI is the decimal value from Table 4 in ISO/IEC 14496-1 with the applied sceneProfileLevelIndication; GPLI is the decimal value from Table 7 in ISO/IEC 14496-1 with the applied graphicsProfileLevelIndication.
对于BIFS流，该参数是从（SPLI+256*GPLI）中获得的十进制值，其中：SPLI是ISO/IEC 14496-1中表4中的十进制值，带有应用的SceneProfileLevel指示；GPLI是ISO/IEC 14496-1表7中的十进制值，带有应用图形ProfileLevel指示。
For MPEG-J streams, this parameter is the decimal value from table 13 (MPEGJProfileLevelIndication) in ISO/IEC 14496-1, indicating the profile and level of the MPEG-J stream.
对于MPEG-J流，此参数是ISO/IEC 14496-1中表13（MPEGJProfileLevelIndication）中的十进制值，表示MPEG-J流的配置文件和级别。
For OD streams, this parameter is the decimal value from table 3 (ODProfileLevelIndication) in ISO/IEC 14496-1, indicating the profile and level of the OD stream.
对于OD流，该参数是ISO/IEC 14496-1中表3（ODProfileLevelIndication）中的十进制值，表示OD流的轮廓和水平。
For IPMP streams, this parameter has either the decimal value 0, indicating an unspecified profile and level, or a value larger than zero, indicating an MPEG-4 IPMP profile and level as defined in a future MPEG-4 specification.
对于IPMP流，此参数具有十进制值0（表示未指定的配置文件和级别），或大于零的值（表示未来MPEG-4规范中定义的MPEG-4 IPMP配置文件和级别）。
For Clock Reference streams and Object Content Info streams, this parameter has the decimal value zero, indicating that profile and level information is conveyed through the OD framework.
对于时钟参考流和对象内容信息流，此参数的十进制值为零，表示配置文件和级别信息通过OD框架传输。
config: A hexadecimal representation of an octet string that expresses the media payload configuration. Configuration data is mapped onto the hexadecimal octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, if necessary to achieve octet-alignment, up to 7 zero-valued padding bits shall follow the configuration data.
配置：表示媒体有效负载配置的八位字节字符串的十六进制表示形式。配置数据以MSB优先顺序映射到十六进制八位字符串。配置数据的第一位应位于第一个八位组的MSB。在最后一个八位字节中，如果需要实现八位字节对齐，配置数据后面最多应跟随7个零值填充位。
For MPEG-4 Audio streams, config is the audio object type specific decoder configuration data AudioSpecificConfig(), as defined in ISO/IEC 14496-3. For Structured Audio, the AudioSpecificConfig() may be conveyed by other means, not defined by this specification. If the AudioSpecificConfig() is conveyed by other means for Structured Audio, then the config MUST be a quoted empty hexadecimal octet string, as follows: config="".
对于MPEG-4音频流，config是音频对象类型特定的解码器配置数据AudioSpecificConfig（），如ISO/IEC 14496-3中所定义。对于结构化音频，AudioSpecificConfig（）可以通过本规范未定义的其他方式传送。如果AudioSpecificConfig（）是通过结构化音频的其他方式传输的，则该配置必须是一个带引号的空十六进制八位字符串，如下所示：config=”“。
Note that a future mode of using this RTP payload format for Structured Audio may define such other means.
注意，对于结构化音频使用该RTP有效载荷格式的未来模式可以定义这样的其他方式。
For MPEG-4 Visual streams, config is the MPEG-4 Visual configuration information as defined in subclause 6.2.1, Start codes of ISO/IEC 14496-2. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first-half-vbv-occupancy and latter-half-vbv-occupancy, if it exists, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC 14496-2).
对于MPEG-4视频流，config是ISO/IEC 14496-2子条款6.2.1“开始代码”中定义的MPEG-4视频配置信息。该参数指示的配置信息应与相应MPEG-4视频流中的配置信息相同，但前半部分vbv占用和后半部分vbv占用（如果存在）除外，这可能在MPEG-4视频流中的重复配置信息中有所不同（参见ISO/IEC 14496-2的6.2.1启动代码）。
For BIFS streams, this is the BIFSConfig() information as defined in ISO/IEC 14496-1. Version 1 of BIFSConfig is defined in section 9.3.5.2, and version 2 is defined in section 9.3.5.3. The MIME format parameter objectType signals the version of BIFSConfig.
对于BIFS流，这是ISO/IEC 14496-1中定义的BIFSConfig（）信息。第9.3.5.2节定义了BIFSConfig的第1版，第9.3.5.3节定义了第2版。MIME格式参数objectType表示BIFSConfig的版本。
For IPMP streams, this is either a quoted empty hexadecimal octet string, indicating the absence of any decoder configuration information (config=""), or the IPMPConfiguration() as will be defined in a future MPEG-4 IPMP specification.
对于IPMP流，这是一个带引号的空十六进制八位字符串，表示没有任何解码器配置信息（config=“”），或者是IPMPConfiguration（），这将在未来的MPEG-4 IPMP规范中定义。
For Object Content Info (OCI) streams, this is the OCIDecoderConfiguration() information of the OCI stream, as defined in section 8.4.2.4 in ISO/IEC 14496-1.
对于对象内容信息（OCI）流，这是OCI流的OCIDecoderConfiguration（）信息，如ISO/IEC 14496-1第8.4.2.4节所定义。
For OD streams, Clock Reference streams and MPEG-J streams, this is a quoted empty hexadecimal octet string (config=""), as no information on the decoder configuration is required.
对于OD流、时钟参考流和MPEG-J流，这是引用的空十六进制八位字节字符串（config=“”），因为不需要关于解码器配置的信息。
mode: The mode in which this specification is used. The following modes can be signaled:
模式：使用本规范的模式。可以用信号通知以下模式：
mode=generic, mode=CELP-cbr, mode=CELP-vbr, mode=AAC-lbr and mode=AAC-hbr.
模式=通用，模式=CELP cbr，模式=CELP vbr，模式=AAC lbr，模式=AAC hbr。
Other modes are expected to be defined in future RFCs. See also section 3.3.7 and 4.2 of RFC 3640.
其他模式预计将在未来的RFC中定义。另见RFC 3640第3.3.7节和第4.2节。
Optional general parameters:
可选的一般参数：
objectType: The decimal value from Table 8 in ISO/IEC 14496-1, indicating the value of the objectTypeIndication of the transported stream. For BIFS streams, this parameter MUST be present to signal the version of BIFSConfiguration(). Note that objectTypeIndication may signal a non-MPEG-4 stream and that the RTP payload format defined in this document may not be suitable for carrying a stream that is not defined by MPEG-4. The objectType parameter SHOULD NOT be set to a value that signals a stream that cannot be carried by this payload format.
objectType：ISO/IEC 14496-1表8中的十进制值，表示传输流的objectType指示值。对于BIFS流，必须存在此参数，以指示BIFSConfiguration（）的版本。请注意，objectTypeIndication可能会向非MPEG-4流发送信号，并且本文档中定义的RTP有效负载格式可能不适合承载未由MPEG-4定义的流。objectType参数不应设置为表示此有效负载格式无法承载的流的值。
constantSize: The constant size in octets of each Access Unit for this stream. The constantSize and the sizeLength parameters MUST NOT be simultaneously present.
constantSize：此流的每个访问单元的恒定大小（以八位字节为单位）。constantSize和sizeLength参数不能同时存在。
constantDuration: The constant duration of each Access Unit for this stream, measured with the same units as the RTP time stamp.
constantDuration：此流的每个访问单元的恒定持续时间，使用与RTP时间戳相同的单位测量。
maxDisplacement: The decimal representation of the maximum displacement in time of an interleaved AU, as defined in section 3.2.3.3, expressed in units of the RTP time stamp clock.
maxDisplacement：第3.2.3.3节中定义的交错AU最大时间位移的十进制表示，以RTP时间戳时钟为单位表示。
This parameter MUST be present when interleaving is applied.
应用交织时，此参数必须存在。
de-interleaveBufferSize: The decimal representation in number of octets of the size of the de-interleave buffer, described in section 3.2.3.3. When interleaving, this parameter MUST be present if the calculation of the de-interleave buffer size given in 3.2.3.3 and based on maxDisplacement and rate(max) under-estimates the size of the de-interleave buffer. If this calculation does not under-estimate the size of the de-interleave buffer, then the de-interleaveBufferSize parameter SHOULD NOT be present.
解交织缓冲区大小：第3.2.3.3节中描述的解交织缓冲区大小的十进制表示，以八位字节为单位。交织时，如果3.2.3.3中给出的解交织缓冲区大小的计算基于maxDisplacement和rate（max）低于估计的解交织缓冲区大小，则必须存在此参数。如果此计算未低估解交织缓冲区的大小，则不应存在解交织缓冲区大小参数。
Optional configuration parameters:
可选配置参数：
sizeLength: The number of bits on which the AU-size field is encoded in the AU-header. The sizeLength and the constantSize parameters MUST NOT be simultaneously present.
sizeLength：在AU标头中对AU大小字段进行编码的位数。sizeLength和constantSize参数不能同时存在。
indexLength: The number of bits on which the AU-Index is encoded in the first AU-header. The default value of zero indicates the absence of the AU-Index field in each first AU-header.
indexLength：在第一个AU头中对AU索引进行编码的位数。默认值为零表示每个第一个AU头中都没有AU索引字段。
indexDeltaLength: The number of bits on which the AU-Index-delta field is encoded in any non-first AU-header. The default value of zero indicates the absence of the AU-Index-delta field in each non-first AU-header.
indexDeltaLength：在任何非第一个AU头中对AU索引增量字段进行编码的位数。默认值为零表示每个非第一个AU头中没有AU索引增量字段。
CTSDeltaLength: The number of bits on which the CTS-delta field is encoded in the AU-header.
CTSDeltaLength：在AU头中编码CTS增量字段的位数。
DTSDeltaLength: The number of bits on which the DTS-delta field is encoded in the AU-header.
DTS增量长度：在AU标头中对DTS增量字段进行编码的位数。
randomAccessIndication: A decimal value of zero or one, indicating whether the RAP-flag is present in the AU-header. The decimal value of one indicates presence of the RAP-flag, the default value zero indicates its absence.
randomAccessIndication：零或一的十进制值，指示AU标头中是否存在RAP标志。十进制值1表示存在RAP标志，默认值0表示不存在RAP标志。
streamStateIndication: The number of bits on which the Stream-state field is encoded in the AU-header. This parameter MAY be present when transporting MPEG-4 system streams, and SHALL NOT be present for MPEG-4 audio and MPEG-4 video streams.
streamStateIndication：流状态字段在AU头中编码的位数。在传输MPEG-4系统流时，此参数可能存在，而对于MPEG-4音频和MPEG-4视频流，此参数不应存在。
auxiliaryDataSizeLength: The number of bits that is used to encode the auxiliary-data-size field.
辅助数据大小长度：用于编码辅助数据大小字段的位数。
Applications MAY use more parameters, in addition to those defined above. Each additional parameter MUST be registered with IANA to ensure that there is not a clash of names. Each additional parameter MUST be accompanied by a specification in the form of an RFC, MPEG standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]). Receivers MUST tolerate the presence of such additional parameters, but these parameters SHALL NOT impact the decoding of receivers that comply with this specification.
除了上面定义的参数外，应用程序还可以使用更多参数。必须向IANA注册每个附加参数，以确保名称不冲突。每个附加参数必须附有RFC、MPEG标准或其他永久性且随时可用的参考文件形式的规范（RFC 2434[6]中定义的“所需规范”政策）。接收器必须允许存在此类附加参数，但这些参数不得影响符合本规范的接收器的解码。
Encoding considerations: This MIME subtype is defined for RTP transport only. System bitstreams MUST be generated according to MPEG-4 Systems specifications (ISO/IEC 14496-1). Video bitstreams MUST be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). Audio bitstreams MUST be generated according to MPEG-4 Audio specifications (ISO/IEC 14496-3). The RTP packets MUST be packetized according to the RTP payload format defined in RFC 3640.
编码注意事项：此MIME子类型仅为RTP传输定义。必须根据MPEG-4系统规范（ISO/IEC 14496-1）生成系统比特流。视频比特流必须根据MPEG-4视频规范（ISO/IEC 14496-2）生成。音频比特流必须根据MPEG-4音频规范（ISO/IEC 14496-3）生成。RTP数据包必须根据RFC 3640中定义的RTP有效负载格式进行打包。
Security considerations: As defined in section 5 of RFC 3640.
安全注意事项：如RFC 3640第5节所定义。
Interoperability considerations: MPEG-4 provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more 'Levels' are set for each Profile. A Profile@Level combination allows:
互操作性注意事项：MPEG-4为可视对象的编码提供了大量丰富的工具。为了有效实施该标准，提供了MPEG-4工具集的子集，以用于特定应用。这些称为“概要文件”的子集限制了解码器需要实现的工具集的大小。为了限制计算复杂性，为每个配置文件设置一个或多个“级别”。A.Profile@Level组合允许：
. a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices that implement the same combination, and
. 编解码器生成器，仅实现其所需标准的子集，同时保持与实现相同组合的其他MPEG-4设备的互通，以及
. checking whether MPEG-4 devices comply with the standard ('conformance testing').
. 检查MPEG-4设备是否符合标准（“一致性测试”）。
A stream SHALL be compliant with the MPEG-4 Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver is achieved by specifying the parameter "profile-level-id" in MIME content. In the capability exchange/announcement procedure, this parameter may mutually be set to the same value.
流应符合MPEG-4标准Profile@Level由参数“配置文件级别id”指定。发送方和接收方之间的互操作性是通过在MIME内容中指定参数“profile level id”来实现的。在能力交换/公告过程中，此参数可以相互设置为相同的值。
Published specification: The specifications for MPEG-4 streams are presented in ISO/IEC 14496-1, 14496-2, and 14496-3. The RTP payload format is described in RFC 3640.
已发布规范：ISO/IEC 14496-1、14496-2和14496-3中介绍了MPEG-4流的规范。RFC 3640中描述了RTP有效负载格式。
Applications which use this media type: Multimedia streaming and conferencing tools.
使用此媒体类型的应用程序：多媒体流媒体和会议工具。
Additional information: none
其他信息：无
Magic number(s): none
幻数：无
File extension(s): None. A file format with the extension .mp4 has been defined for MPEG-4 content but is not directly correlated with this MIME type for which the sole purpose is RTP transport.
文件扩展名：无。已为MPEG-4内容定义了一种扩展名为.mp4的文件格式，但该格式与此MIME类型没有直接关联，其唯一用途是RTP传输。
Macintosh File Type Code(s): none
Macintosh文件类型代码：无
Person & email address to contact for further information: Authors of RFC 3640, IETF Audio/Video Transport working group.
联系人和电子邮件地址以获取更多信息：IETF音频/视频传输工作组RFC 3640的作者。
Intended usage: COMMON
预期用途：普通
Author/Change controller: Authors of RFC 3640, IETF Audio/Video Transport working group.
作者/变更控制者：IETF音频/视频传输工作组RFC3640的作者。
This specification can be used in a number of modes. The mode of operation is signaled using the "mode" MIME parameter, with the initial set of values specified in section 4.1. New modes may be defined at any time, as described in section 3.3.7. These modes MUST be registered with IANA, to ensure that there is not a clash of names.
本规范可用于多种模式。使用“mode”MIME参数和第4.1节中规定的初始值集来表示操作模式。如第3.3.7节所述，可随时定义新模式。这些模式必须向IANA注册，以确保没有名称冲突。
A new mode registration MUST be accompanied by a specification in the form of an RFC, MPEG standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]).
新的模式注册必须附有RFC、MPEG标准或其他永久性且随时可用的参考（RFC 2434[6]中定义的“所需规范”策略）形式的规范。
Multiple parameters SHOULD be expressed as a MIME media type string, in the form of a semicolon-separated list of parameter=value pairs (for parameter usage examples see sections 3.3.2 up to 3.3.6).
多个参数应以参数=值对的分号分隔列表的形式表示为MIME媒体类型字符串（有关参数使用示例，请参见第3.3.2节至第3.3.6节）。
It is assumed that one typical way to transport the above-described parameters associated with this payload format is via an SDP message [5] for example transported to the client in reply to an RTSP DESCRIBE [8] or via SAP [11]. In that case, the (a=fmtp) keyword MUST be used as described in RFC 2327 [5], section 6, the syntax then being:
假设传输与该有效载荷格式相关联的上述参数的一种典型方式是通过SDP消息[5]，例如，通过RTSP descripe[8]或SAP[11]传输到客户端。在这种情况下，必须按照RFC 2327[5]第6节的说明使用（a=fmtp）关键字，语法如下：
a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>]
a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>]
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [2]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data so there is no conflict between the two operations. The packet processing complexity of this payload type (i.e., excluding media data processing) does not exhibit any significant non-uniformity in the receiver side to cause a denial-of-service threat.
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[2]中讨论的安全注意事项。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以对压缩数据执行加密，因此两个操作之间没有冲突。该有效负载类型的分组处理复杂性（即，不包括媒体数据处理）在接收器侧不表现出任何显著的非均匀性，从而导致拒绝服务威胁。
However, it is possible to inject non-compliant MPEG streams (Audio, Video, and Systems) so that the receiver/decoder's buffers are overloaded, which might compromise the functionality of the receiver or even crash it. This is especially true for end-to-end systems like MPEG, where the buffer models are precisely defined.
然而，有可能注入不兼容的MPEG流（音频、视频和系统），从而使接收器/解码器的缓冲区过载，这可能损害接收器的功能，甚至使其崩溃。对于端到端系统（如MPEG），尤其如此，在MPEG中，缓冲区模型是精确定义的。
MPEG-4 Systems support stream types including commands that are executed on the terminal, like OD commands, BIFS commands, etc. and programmatic content like MPEG-J (Java(TM) Byte Code) and MPEG-4 scripts. It is possible to use one or more of the above in a manner non-compliant to MPEG to crash the receiver or make it temporarily unavailable. Senders that transport MPEG-4 content SHOULD ensure that such content is MPEG compliant, as defined in the compliance part of IEC/ISO 14496 [1]. Receivers that support MPEG-4 content should prevent malfunctioning of the receiver in case of non MPEG compliant content.
MPEG-4系统支持流类型，包括在终端上执行的命令，如OD命令、BIFS命令等，以及编程内容，如MPEG-J（Java（TM）字节码）和MPEG-4脚本。可以以不符合MPEG的方式使用上述一种或多种方法来使接收器崩溃或使其暂时不可用。传输MPEG-4内容的发送方应确保此类内容符合IEC/ISO 14496[1]中规定的MPEG标准。支持MPEG-4内容的接收器应防止在出现不符合MPEG的内容时接收器出现故障。
Authentication mechanisms can be used to validate the sender and the data to prevent security problems due to non-compliant malignant MPEG-4 streams.
身份验证机制可用于验证发送方和数据，以防止由于不符合MPEG-4流而导致的安全问题。
In ISO/IEC 14496-1, a security model is defined for MPEG-4 Systems streams carrying MPEG-J access units that comprise Java(TM) classes and objects. MPEG-J defines a set of Java APIs and a secure execution model. MPEG-J content can call this set of APIs and Java(TM) methods from a set of Java packages supported in the receiver within the defined security model. According to this security model, downloaded byte code is forbidden to load libraries, define native methods, start programs, read or write files, or read system properties. Receivers can implement intelligent filters to validate the buffer requirements or parametric (OD, BIFS, etc.) or programmatic (MPEG-J, MPEG-4 scripts) commands in the streams. However, this can increase the complexity significantly.
在ISO/IEC 14496-1中，为MPEG-4系统流定义了安全模型，该系统流承载由Java（TM）类和对象组成的MPEG-J访问单元。MPEG-J定义了一组Java API和安全执行模型。MPEG-J内容可以从定义的安全模型中接收器支持的一组Java包中调用这组API和Java（TM）方法。根据这个安全模型，下载的字节码被禁止加载库、定义本机方法、启动程序、读取或写入文件或读取系统属性。接收器可以实现智能过滤器，以验证缓冲区要求或流中的参数（OD、BIFS等）或编程（MPEG-J、MPEG-4脚本）命令。但是，这会显著增加复杂性。
Implementors of MPEG-4 streaming over RTP who also implement MPEG-4 scripts (subset of ECMAScript) MUST ensure that the action of such scripts is limited solely to the domain of the single presentation in which they reside (thus disallowing session to session communication, access to local resources and storage, etc). Though loading static network-located resources (such as media) into the presentation should be permitted, network access by scripts MUST be restricted to such a (media) download.
同时实施MPEG-4脚本（ECMAScript的子集）的RTP上MPEG-4流媒体的实施者必须确保此类脚本的操作仅限于其所在的单个表示的域（因此不允许会话间通信、访问本地资源和存储等）。虽然应该允许将静态网络资源（如媒体）加载到演示文稿中，但脚本的网络访问必须限制为此类（媒体）下载。
This document evolved into RFC 3640 after several revisions. Thanks to contributions from people in the ISMA forum, the IETF AVT Working Group and the 4-on-IP ad-hoc group within MPEG. The authors wish to thank all people involved, particularly Andrea Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John Lazaro, Zvi Lifshitz, Young-kwon Lim, Alex MacAulay, Bill May, Colin Perkins, Dorairaj V and Stephan Wenger for their valuable comments and support.
本文件经过多次修订后演变为RFC 3640。感谢ISMA论坛、IETF AVT工作组和MPEG内的4-on-IP特设工作组的人员的贡献。作者希望感谢所有相关人员，特别是安德烈亚·巴索、斯蒂芬·卡斯纳、M.雷哈·西瓦纳尔、卡斯滕·赫尔佩尔、约翰·拉扎罗、兹维·利夫希茨、杨权林、亚历克斯·麦考利、比尔·梅、科林·珀金斯、多莱拉伊·V和斯蒂芬·温格，感谢他们的宝贵评论和支持。
APPENDIX: Usage of this Payload Format
附录：此有效负载格式的使用
A. Examples of Delay Analysis with Interleave
A.交织时延分析示例
Interleaving issues are discussed in this appendix. Some general notes are provided on de-interleaving and error concealment, while a number of interleaving patterns are examined, in particular for determining the size of the de-interleave buffer and the maximum displacement of access units in time. In these examples, the maximum displacement is cited in terms of an access unit count, for ease of reading. In actual streams, it is signaled in units of the RTP time stamp clock.
本附录讨论了交错问题。提供了关于解交织和错误隐藏的一些一般说明，同时检查了许多交织模式，特别是用于确定解交织缓冲器的大小和访问单元在时间上的最大位移。在这些示例中，为了便于阅读，根据访问单元计数引用了最大位移。在实际流中，以RTP时间戳时钟为单位发送信号。
This appendix does not describe any details on de-interleaving and error concealment, as the control of the AU decoding and error concealment process has little to do with interleaving. If the next AU to be decoded is present and there is sufficient storage available for the decoded AU, then decode it immediately. If not, wait. When the decoding deadline is reached (i.e., the time when decoding must begin in order to be completed by the time the AU is to be presented), or if the decoder is some hardware that presents a constant delay between initiation of decoding of an AU and presentation of that AU, then decoding must begin at that deadline time.
由于AU解码和错误隐藏过程的控制与交织关系不大，因此本附录不描述关于解交织和错误隐藏的任何细节。如果存在下一个要解码的AU，并且有足够的存储空间用于解码的AU，则立即对其进行解码。如果没有，请等待。当达到解码截止时间时（即，解码必须开始的时间，以便在AU将被呈现的时间之前完成），或者如果解码器是在AU的解码开始和AU的呈现之间呈现恒定延迟的某个硬件，则解码必须在该截止时间开始。
If the next AU to be decoded is not present when the decoding deadline is reached, then that AU is lost so the receiver must take whatever error concealment measures are deemed appropriate. The play-out delay may need to be adjusted at that point (especially if other AUs have also missed their deadline recently). Or, if it was a momentary delay, and maintaining the latency is important, then the receiver should minimize the glitch and continue processing with the next AU.
如果到达解码截止日期时，下一个要解码的AU不存在，则该AU丢失，因此接收机必须采取任何被认为合适的错误隐藏措施。此时可能需要调整比赛延期（特别是如果其他澳大利亚国家最近也错过了最后期限）。或者，如果是瞬时延迟，并且保持延迟很重要，那么接收器应该将故障最小化，并继续处理下一个AU。
An example of regular interleave is when packets are formed into
groups. If the 'stride' of the interleave (the distance between
interleaved AUs) is N, packet 0 could contain AU(0), AU(N), AU(2N),
and so on; packet 1 could contain AU(1), AU(1+N), AU(1+2N), and so
An example of regular interleave is when packets are formed into
groups. If the 'stride' of the interleave (the distance between
interleaved AUs) is N, packet 0 could contain AU(0), AU(N), AU(2N),
and so on; packet 1 could contain AU(1), AU(1+N), AU(1+2N), and so
on. If there are M access units in a packet, then there are M*N access units in the group.
在…上如果一个数据包中有M个访问单元，则组中有M*N个访问单元。
An example with N=M=3 follows; note that this is the same example as given in section 2.5 and that a fixed time duration per Access Unit is assumed:
下面是N=M=3的示例；请注意，这与第2.5节中给出的示例相同，并且假设每个访问单元具有固定的持续时间：
Packet Time stamp Carried AUs AU-Index, AU-Index-delta P(0) T[0] 0, 3, 6 0, 2, 2 P(1) T[1] 1, 4, 7 0, 2, 2 P(2) T[2] 2, 5, 8 0, 2, 2 P(3) T[9] 9,12,15 0, 2, 2
数据包时间戳携带AUs AU索引，AU索引增量P（0）T[0]0,3,60,2,2p（1）T[1]1,4,70,2,2p（2）T[2]2,5,80,2,2p（3）T[9]9,12,150,2,2
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for fixed duration AUs. The position of the first AU of each packet within the group is defined by the RTP time stamp, while the AU-Index-delta field indicates the position of subsequent AUs relative to the first AU in the packet. All AU-Index-delta fields are coded with the value N-1, equal to 2 in this example. Hence the RTP time stamp and the AU-Index-delta are used to reconstruct the original order. See also section 3.2.3.2.
在本例中，AU索引出现在第一个AU头中，并按照固定持续时间AU的要求使用值0进行编码。组内每个分组的第一个AU的位置由RTP时间戳定义，而AU索引delta字段指示后续AU相对于分组中第一个AU的位置。所有AU索引增量字段都用值N-1编码，在本例中等于2。因此，RTP时间戳和AU指数增量用于重建原始顺序。另见第3.2.3.2节。
For the regular pattern as in this example, Figure 6 in section 3.2.3.3 shows that the de-interleave buffer stores at most 4 AUs. A de-interleaveBufferSize value that is at least equal to the total number of octets of any 4 "early" AUs that are stored at the same time may be signaled.
对于本例中的规则模式，第3.2.3.3节中的图6显示，解交织缓冲区最多存储4个AU。可以用信号通知至少等于同时存储的任何4个“早期”AU的八位字节总数的解交织缓冲区大小值。
For the regular pattern as in this example, Figure 7 in section 3.3 shows that the maximum displacement in time equals 5 AU periods. Hence, the minimum maxDisplacement value that must be signaled is 5 AU periods. In case each AU has the same size, this maxDisplacement value over-estimates the de-interleave buffer size with one AU. However, note that in case of variable AU sizes, the total size of any 4 "early" AUs that must be stored at the same time may exceed maxDisplacement times the maximum bitrate, in which case the de-interleaveBufferSize must be signaled.
对于本例中的规则模式，第3.3节中的图7显示，时间上的最大位移等于5个AU周期。因此，必须发出信号的最小最大位移值为5个AU周期。如果每个AU都具有相同的大小，则此maxDisplacement值会过高估计一个AU的解交织缓冲区大小。然而，请注意，在可变AU大小的情况下，必须同时存储的任何4个“早期”AU的总大小可能超过最大位移乘以最大比特率，在这种情况下，必须用信号通知解交织缓冲区大小。
Another example of forming packets with group interleave is given below. In this example, the packets are formed such that the loss of two subsequent RTP packets does not cause the loss of two subsequent AUs. Note that in this example, the RTP time stamps of packet 3 and packet 4 are earlier than the RTP time stamps of packets 1 and 2, respectively; a fixed time duration per Access Unit is assumed.
下面给出了使用组交织形成分组的另一个示例。在此示例中，分组的形成使得两个后续RTP分组的丢失不会导致两个后续au的丢失。注意，在该示例中，分组3和分组4的RTP时间戳分别早于分组1和2的RTP时间戳；假定每个访问单元具有固定的持续时间。
Packet Time stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0, 5 0, 4 1 T[2] 2, 7 0, 4 2 T[4] 4, 9 0, 4 3 T[1] 1, 6 0, 4 4 T[3] 3, 8 0, 4 5 T[10] 10, 15 0, 4 and so on ..
数据包时间戳携带AUs AU索引、AU索引增量0T[0]0、50、41T[2]2、70、42T[4]4、90、43T[1]1、60、44T[3]3、80、45T[10]10、150、4等等。。
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for AUs with a fixed duration. To reconstruct the original order, the RTP time stamp and the AU-Index-delta (coded with the value 4) are used. See also section 3.2.3.2.
在本例中，AU索引出现在第一个AU头中，并使用值0进行编码，这是具有固定持续时间的AU所需的。为了重建原始顺序，使用RTP时间戳和AU索引增量（用值4编码）。另见第3.2.3.2节。
From Figure 8, it can be to determined that at most 5 "early" AUs are to be stored. If the AUs are of constant size, then this value equals 5 times the AU size. The minimum size of the de-interleave buffer equals the maximum total number of octets of the "early" AUs that are to be stored at the same time. This gives the minimum value of the de-interleaveBufferSize that may be signaled.
从图8可以确定最多要存储5个“早期”AU。如果AU大小恒定，则该值等于AU大小的5倍。解交织缓冲区的最小大小等于同时存储的“早期”AU的最大八位字节总数。这给出了可能发出信号的解交织缓冲区大小的最小值。
+--+--+--+--+--+--+--+--+--+--+
Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
+--+--+--+--+--+--+--+--+--+--+
- - 5 - 5 - 2 7 4 9
7 4 9 5
"Early" AUs 5 6
7 7
9 9
+--+--+--+--+--+--+--+--+--+--+
Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
+--+--+--+--+--+--+--+--+--+--+
- - 5 - 5 - 2 7 4 9
7 4 9 5
"Early" AUs 5 6
7 7
9 9
Figure 8: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
图8：每个交织AU在反交织缓冲区中的“早期”AU存储。
From Figure 9, it can be seen that the maximum displacement in time equals 8 AU periods. Hence the minimum maxDisplacement value to be signaled is 8 AU periods.
从图9可以看出，时间上的最大位移等于8个AU周期。因此，发出信号的最小最大位移值为8个AU周期。
+--+--+--+--+--+--+--+--+--+--+
Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+
Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
+--+--+--+--+--+--+--+--+--+--+
Earliest not yet present AU - 1 1 1 1 1 - 3 - -
Earliest not yet present AU - 1 1 1 1 1 - 3 - -
Figure 9: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
图9：对于交错模式中的每个AU，任何早期AU中最早的AU尚未出现
In case each AU has the same size, the found maxDisplacement value over-estimates the de-interleave buffer size with three AUs. However, in case of variable AU sizes, the total size of any 5 "early" AUs stored at the same time may exceed maxDisplacement times the maximum bitrate, in which case de-interleaveBufferSize must be signaled.
如果每个AU具有相同的大小，则找到的maxDisplacement值会过高估计具有三个AU的解交织缓冲区大小。然而，在可变AU大小的情况下，同时存储的任何5个“早期”AU的总大小可能超过最大位移乘以最大比特率，在这种情况下，必须发出解交织缓冲大小信号。
In continuous interleave, once the scheme is 'primed', the number of AUs in a packet exceeds the 'stride' (the distance between them). This shortens the buffering needed, smoothes the data-flow, and gives slightly larger packets -- and thus lower overhead -- for the same interleave. For example, here is a continuous interleave also over a stride of 3 AUs, but with 4 AUs per packet, for a run of 20 AUs. This shows both how the scheme 'starts up' and how it finishes. Once again, the example assumes fixed time duration per Access Unit.
在连续交织中，一旦方案被“预处理”，数据包中的AU数量就会超过“跨步”（它们之间的距离）。这缩短了所需的缓冲，平滑了数据流，并为相同的交织提供了稍大的数据包，从而降低了开销。例如，这里的连续交织也跨越3个AU，但每个数据包4个AU，运行20个AU。这显示了方案如何“启动”以及如何完成。同样，该示例假定每个访问单元的持续时间是固定的。
Packet Time-stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0 0 1 T[1] 1 4 0 2 2 T[2] 2 5 8 0 2 2 3 T[3] 3 6 9 12 0 2 2 2 4 T[7] 7 10 13 16 0 2 2 2 5 T[11] 11 14 17 20 0 2 2 2 6 T[15] 15 18 0 2 7 T[19] 19 0
数据包时间戳携带AUs AU索引，AU索引增量0 T[0]0 1 T[1]1 4 0 2 T[2]2 5 8 0 2 2 3 T[3]3 6 9 12 0 2 2 4 T[7]7 10 16 0 2 2 5 T[11]11 14 17 20 0 2 2 6 T[15]15 18 0 2 7 T[19]19 0
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for AUs with a fixed duration. To reconstruct the original order, the RTP time stamp and the
在本例中，AU索引出现在第一个AU头中，并使用值0进行编码，这是具有固定持续时间的AU所需的。为了重建原始顺序，RTP时间戳和
AU-Index-delta (coded with the value 2) are used. See also 3.2.3.2. Note that this example has RTP time-stamps in increasing order.
使用AU索引增量（用值2编码）。另见3.2.3.2。请注意，此示例的RTP时间戳的顺序是递增的。
For this example the de-interleave buffer size can be derived from Figure 10. The maximum number of "early" AUs is 3. If the AUs are of constant size, then the de-interleave buffer size equals 3 times the AU size. Compared to the example in A.2, for constant size AUs the de-interleave buffer size is reduced from 4 to 3 times the AU size, while maintaining the same 'stride'.
对于这个例子，解交织缓冲区大小可以从图10中导出。“早期”AU的最大数量为3。如果AU的大小恒定，则解交织缓冲区大小等于AU大小的3倍。与A.2中的示例相比，对于恒定大小的AU，解交织缓冲区大小从AU大小的4倍减少到3倍，同时保持相同的“步长”。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
- - - 4 - - 4 8 - - 8 12 - -
5 9
"Early" AUs 8 12
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
- - - 4 - - 4 8 - - 8 12 - -
5 9
"Early" AUs 8 12
Figure 10: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
图10：每个交织AU在反交织缓冲器中的“早期”AU存储。
For this example, the maximum displacement has a value of 5 AU periods. See Figure 11. Compared to the example in A.2, the maximum displacement does not decrease, though in fact less de-interleave buffering is required.
对于本例，最大位移的值为5个AU周期。参见图11。与A.2中的示例相比，最大位移没有减少，但实际上需要更少的解交织缓冲。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Earliest not yet
present AU - - 2 - 3 3 - - 7 7 - - 11 11
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
Earliest not yet
present AU - - 2 - 3 3 - - 7 7 - - 11 11
Figure 11: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
图11：对于交错模式中的每个AU，任何早期AU中最早的AU尚未出现
References
工具书类
Normative References
规范性引用文件
[1] ISO/IEC International Standard 14496 (MPEG-4); "Information technology - Coding of audio-visual objects", January 2000
[1] ISO/IEC国际标准14496（MPEG-4）；“信息技术-视听对象的编码”，2000年1月
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[3] Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Informative References
资料性引用
[7] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[7] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1998年1月。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real-Time Session Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时会话协议（RTSP）”，RFC2326，1998年4月。
[9] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[9] Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[10] Schulzrinne, H. and J. Rosenberg, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[10] Schulzrinne，H.和J.Rosenberg，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11] Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[12] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y. and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[12] Kikuchi，Y.，Nomura，T.，Fukunaga，S.，Matsui，Y.和H.Kimata，“MPEG-4音频/视频流的RTP有效载荷格式”，RFC3016，2000年11月。
Authors' Addresses
作者地址
Jan van der Meer Philips Electronics Prof Holstlaan 4 Building WAH-1 5600 JZ Eindhoven Netherlands
Jan van der Meer Philips Electronics Prof Holstlaan 4号楼WAH-1 5600 JZ埃因霍温荷兰
EMail: jan.vandermeer@philips.com
EMail: jan.vandermeer@philips.com
David Mackie Apple Computer, Inc. One Infinite Loop, MS:302-3KS Cupertino CA 95014
David Mackie Apple Computer，Inc.One Infinite Loop，MS:302-3KS Cupertino CA 95014
EMail: dmackie@apple.com
EMail: dmackie@apple.com
Viswanathan Swaminathan Sun Microsystems Inc. 2600 Casey Avenue Mountain View, CA 94043
维斯瓦纳坦·斯瓦米纳坦太阳微系统公司，加利福尼亚州山景城凯西大道2600号，邮编94043
EMail: viswanathan.swaminathan@sun.com
EMail: viswanathan.swaminathan@sun.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014
David Singer苹果电脑有限公司一个无限循环，MS:302-3MT Cupertino CA 95014
EMail: singer@apple.com
EMail: singer@apple.com
Philippe Gentric Philips Electronics 51 rue Carnot 92156 Suresnes France
飞利浦Gentric飞利浦电子公司法国卡诺街51号，邮编92156
EMail: philippe.gentric@philips.com
EMail: philippe.gentric@philips.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。