Network Working Group D. Hoffman
Request for Comments: 2250 G. Fernando
Obsoletes: 2038 Sun Microsystems, Inc.
Category: Standards Track V. Goyal
Precept Software, Inc.
M. Civanlar
AT&T Labs - Research
January 1998
Network Working Group D. Hoffman
Request for Comments: 2250 G. Fernando
Obsoletes: 2038 Sun Microsystems, Inc.
Category: Standards Track V. Goyal
Precept Software, Inc.
M. Civanlar
AT&T Labs - Research
January 1998
RTP Payload Format for MPEG1/MPEG2 Video
MPEG1/MPEG2视频的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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
本备忘录描述了MPEG视频和音频流的打包方案。所提出的方案可用于通过RTP支持的传输协议传输这样的视频或音频流。描述了两种方法。第一个设计用于支持与MPEG系统环境的最大互操作性。第二个设计用于提供与其他RTP封装媒体流的最大兼容性，以及IETF未来的会议控制工作。
This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.
本备忘录是对互联网标准跟踪协议RFC 2038的修订。在本版本中，第3.4节中的丢包恢复机制被扩展，以包括MPEG2所需的额外图片报头信息。添加了关于此有效负载类型的安全注意事项的新部分。
ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard (ISO/IEC 13818)[2]. This memo describes a packetization scheme to transport MPEG video and audio streams using the Real-time Transport Protocol (RTP), version 2 [3, 4].
ISO/IEC JTC1/SC29 WG11（也称为MPEG委员会）定义了MPEG1标准（ISO/IEC 11172）[1]和MPEG2标准（ISO/IEC 13818）[2]。本备忘录描述了使用实时传输协议（RTP）版本2[3，4]传输MPEG视频和音频流的打包方案。
The MPEG1 specification is defined in three parts: System, Video and Audio. It is designed primarily for CD-ROM-based applications, and is optimized for approximately 1.5 Mbits/sec combined data rates. The video and audio portions of the specification describe the basic format of the video or audio stream. These formats define the Elementary Streams (ES). The MPEG1 System specification defines an encapsulation of the ES that contains Presentation Time Stamps (PTS), Decoding Time Stamps and System Clock references, and performs multiplexing of MPEG1 compressed video and audio ES's with user data.
MPEG1规范分为三个部分：系统、视频和音频。它主要为基于CD-ROM的应用程序而设计，并针对大约1.5 Mbits/sec的组合数据速率进行了优化。本规范的视频和音频部分描述视频或音频流的基本格式。这些格式定义了基本流。MPEG1系统规范定义了ES的封装，其中包含表示时间戳（PTS）、解码时间戳和系统时钟参考，并执行MPEG1压缩视频和音频ES与用户数据的多路复用。
The MPEG2 specification is structured in a similar way. However, it hasn't been restricted only to CD-ROM applications. The MPEG2 System specification defines two system stream formats: the MPEG2 Transport Stream (MTS) and the MPEG2 Program Stream (MPS). The MTS is tailored for communicating or storing one or more programs of MPEG2 compressed data and also other data in relatively error-prone environments. The MPS is tailored for relatively error-free environments.
MPEG2规范的结构与此类似。然而，它并不仅仅局限于CD-ROM应用。MPEG2系统规范定义了两种系统流格式：MPEG2传输流（MTS）和MPEG2程序流（MPS）。MTS专门用于在相对容易出错的环境中通信或存储一个或多个MPEG2压缩数据程序以及其他数据。MPS是为相对无错误的环境定制的。
We seek to achieve interoperability among 4 types of end-systems in the following specification. The 4 types are:
我们寻求在以下规范中实现4种终端系统之间的互操作性。这4种类型是：
1. Transmitting Interworking Unit (TIU)
1. 发送互通单元（TIU）
Receives MPEG information from a native MTS system for distribution over packet networks using a native RTP-based system layer (such as an IP-based internetwork). Examples: real-time encoder, MTS satellite link to Internet, video server with MTS-encoded source material.
从本机MTS系统接收MPEG信息，以便使用基于本机RTP的系统层（例如基于IP的互联网）在分组网络上分发。示例：实时编码器、MTS卫星与互联网的链接、带有MTS编码源材料的视频服务器。
2. Receiving Interworking Unit (RIU)
2. 接收互通单元（RIU）
Receives MPEG information in real time from an RTP-based network for forwarding to a native MTS environment. Examples: Internet-based video server to MTS-based cable distribution plant.
从基于RTP的网络实时接收MPEG信息，以便转发到本机MTS环境。示例：基于互联网的视频服务器到基于MTS的电缆分配设备。
3. Transmitting Internet End-System (TAES)
3. 传输互联网终端系统（TAES）
Transmits MPEG information generated or stored within the internet end-system itself, or received from internet-based computer networks. Example: video server.
传输在互联网终端系统本身内生成或存储的MPEG信息，或从基于互联网的计算机网络接收的MPEG信息。示例：视频服务器。
4. Receiving Internet End-System (RAES)
4. 接收互联网终端系统（RAES）
Receives MPEG information over an RTP-based internet for consumption at the internet end-system or forwarding to traditional computer network. Example: desktop PC or workstation viewing training video.
通过基于RTP的互联网接收MPEG信息，供互联网终端系统使用或转发至传统计算机网络。示例：台式PC或工作站查看培训视频。
Each of the 2 types of transmitters must work with each of the 2 types of receivers. Because it is probable that the TAES, and certain that the RAES, will be based on existing and planned internet-connected computers, it is highly desirable for the interoperable protocol to be based on RTP.
这两种类型的发射机必须与这两种接收机中的每一种一起工作。由于TAE和RAE很可能基于现有和计划中的互联网连接计算机，因此非常希望互操作协议基于RTP。
Because of the range of applications that might employ MPEG streams, we propose to define two payload formats.
由于可能采用MPEG流的应用范围，我们建议定义两种有效负载格式。
Much interest in the MPEG community is in the use of one of the MPEG System encodings, and hence, in Section 2 we propose encapsulations of MPEG1 System streams and MPEG2 Transport and Program Streams with RTP. This profile supports the full semantics of MPEG System and offers basic interoperability among all four end-system types.
MPEG社区最感兴趣的是其中一种MPEG系统编码的使用，因此，在第2节中，我们建议使用RTP封装MPEG1系统流和MPEG2传输和节目流。此配置文件支持MPEG系统的完整语义，并提供所有四种终端系统类型之间的基本互操作性。
When operating only among internet-based end-systems (i.e., TAES and RAES) a payload format that provides greater compatibility with the Internet architecture is desired, deferring some of the system issues to other protocols being defined in the Internet community (such as the MMUSIC WG). In Section 3 we propose an encapsulation of compressed video and audio data (referred to in MPEG documentation as "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2. Here, neither of the System standards of MPEG1 or MPEG2 are utilized. The ES's are directly encapsulated with RTP.
当仅在基于互联网的终端系统（即TAE和RAE）之间运行时，需要提供与互联网架构更大兼容性的有效负载格式，将一些系统问题推迟到互联网社区中定义的其他协议（如MMUSIC WG）。在第3节中，我们提出了一种符合MPEG1或MPEG2的压缩视频和音频数据（在MPEG文档中称为“基本流”（ES））的封装。此处，未使用MPEG1或MPEG2的系统标准。ES直接用RTP封装。
Throughout this specification, we make extensive use of MPEG terminology. The reader should consult the primary MPEG references for definitive descriptions of this terminology.
在本规范中，我们广泛使用了MPEG术语。读者应查阅主要的MPEG参考资料，以获得此术语的明确描述。
Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference. This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR) and represents the target transmission time of the first byte of the
每个RTP数据包将包含一个从发送方的90KHz时钟参考中导出的时间戳。该时钟与系统流程序时钟参考（PCR）或系统时钟参考（SCR）同步，并表示数据流的第一个字节的目标传输时间
packet payload. The RTP timestamp will not be passed to the MPEG decoder. This use of the timestamp is somewhat different than normally is the case in RTP, in that it is not considered to be the media display or presentation timestamp. The primary purposes of the RTP timestamp will be to estimate and reduce any network-induced jitter and to synchronize relative time drift between the transmitter and receiver.
数据包有效载荷。RTP时间戳不会传递给MPEG解码器。时间戳的这种使用与RTP中通常的情况有所不同，因为它不被认为是媒体显示或表示时间戳。RTP时间戳的主要目的是估计和减少任何网络引起的抖动，并同步发射机和接收机之间的相对时间漂移。
For MPEG2 Transport Streams the RTP payload will contain an integral number of MPEG transport packets. To avoid end system inefficiencies, data from multiple small MTS packets (normally fixed in size at 188 bytes) are aggregated into a single RTP packet. The number of transport packets contained is computed by dividing RTP payload length by the length of an MTS packet (188).
对于MPEG2传输流，RTP有效负载将包含整数个MPEG传输数据包。为了避免终端系统效率低下，将来自多个小型MTS数据包（通常大小固定为188字节）的数据聚合到单个RTP数据包中。通过将RTP有效负载长度除以MTS数据包的长度来计算包含的传输数据包的数量（188）。
For MPEG2 Program streams and MPEG1 system streams there are no packetization restrictions; these streams are treated as a packetized stream of bytes.
对于MPEG2程序流和MPEG1系统流，没有打包限制；这些流被视为分组字节流。
The RTP header fields are used as follows:
RTP标头字段的使用方式如下：
Payload Type: Distinct payload types should be assigned for MPEG1 System Streams, MPEG2 Program Streams and MPEG2 Transport Streams. See [4] for payload type assignments.
有效负载类型：应为MPEG1系统流、MPEG2程序流和MPEG2传输流分配不同的有效负载类型。有关有效负载类型分配，请参见[4]。
M bit: Set to 1 whenever the timestamp is discontinuous (such as might happen when a sender switches from one data source to another). This allows the receiver and any intervening RTP mixers or translators that are synchronizing to the flow to ignore the difference between this timestamp and any previous timestamp in their clock phase detectors.
M位：当时间戳不连续时（例如发送方从一个数据源切换到另一个数据源时），设置为1。这允许接收器和与流同步的任何介入RTP混频器或转换器忽略该时间戳与其时钟相位检测器中的任何先前时间戳之间的差异。
timestamp: 32 bit 90K Hz timestamp representing the target transmission time for the first byte of the packet.
时间戳：32位90K Hz时间戳，表示数据包第一个字节的目标传输时间。
The following ES types may be encapsulated directly in RTP:
以下ES类型可直接封装在RTP中：
(a) MPEG1 Video (ISO/IEC 11172-2) (b) MPEG2 Video (ISO/IEC
13818-2) (c) MPEG1 Audio (ISO/IEC 11172-3) (d) MPEG2 Audio
(ISO/IEC 13818-3)
(a) MPEG1 Video (ISO/IEC 11172-2) (b) MPEG2 Video (ISO/IEC
13818-2) (c) MPEG1 Audio (ISO/IEC 11172-3) (d) MPEG2 Audio
(ISO/IEC 13818-3)
A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and MPEG1/MPEG2 Audio, respectively. Further indication as to whether the data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG-specific headers of this encapsulation, as this information is available in the ES headers.
MPEG1/MPEG2视频和MPEG1/MPEG2音频分别分配了不同的RTP有效负载类型。关于数据是MPEG1还是MPEG2的进一步指示不需要在该封装的RTP或MPEG特定报头中提供，因为该信息在ES报头中可用。
Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz shall be carried in the fixed RTP header. All packets that make up a audio or video frame shall have the same time stamp.
应在固定RTP报头中携带精度为90 kHz的32位显示时间戳（PTS）。构成音频或视频帧的所有数据包应具有相同的时间戳。
MPEG1 Video can be distinguished from MPEG2 Video at the video sequence header, i.e. for MPEG2 Video a sequence_header() is followed by sequence_extension(). The particular profile and level of MPEG2 Video (MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc) are determined by the profile_and_level_indicator field of the sequence_extension header of MPEG2 Video.
MPEG1视频可以在视频序列头上与MPEG2视频区分开来，即对于MPEG2视频，序列头（）后面跟着序列扩展（）。MPEG2视频的特定配置文件和级别（主_Profile@MAIN_Level，高_Profile@HIGH_Level等）由MPEG2视频序列扩展头的profile_和_level_指示符字段确定。
The MPEG bit-stream semantics were designed for relatively error-free environments, and there is significant amount of dependency (both temporal and spatial) within the stream such that loss of some data make other uncorrupted data useless. The format as defined in this encapsulation uses application layer framing information plus additional information in the RTP stream-specific header to allow for certain recovery mechanisms. Appendix 1 suggests several recovery strategies based on the properties of this encapsulation.
MPEG比特流语义是为相对无错误的环境而设计的，流中存在大量的依赖性（时间和空间），因此某些数据的丢失会使其他未损坏的数据变得无用。此封装中定义的格式使用应用层帧信息加上RTP流特定标头中的附加信息，以允许某些恢复机制。附录1根据这种封装的特性提出了几种恢复策略。
Since MPEG pictures can be large, they will normally be fragmented into packets of size less than a typical LAN/WAN MTU. The following fragmentation rules apply:
由于MPEG图片可能很大，它们通常会被分割成小于典型LAN/WAN MTU的数据包。以下分段规则适用：
1. The MPEG Video_Sequence_Header, when present, will always be at the beginning of an RTP payload. 2. An MPEG GOP_header, when present, will always be at the beginning of the RTP payload, or will follow a Video_Sequence_Header. 3. An MPEG Picture_Header, when present, will always be at the beginning of a RTP payload, or will follow a GOP_header.
1. MPEG Video_Sequence_头（如果存在）将始终位于RTP有效负载的开头。2.MPEG GOP_头（当存在时）将始终位于RTP有效载荷的开头，或者将跟随视频序列_头。3.MPEG Picture_头（如果存在）将始终位于RTP有效负载的开头，或紧跟在GOP_头之后。
Each ES header must be completely contained within the packet. Consequently, a minimum RTP payload size of 261 bytes must be supported to contain the largest single header defined in the ES (that is, the extension_data() header containing the quant_matrix_extension()). Otherwise, there are no restrictions on where headers may appear within packet payloads.
每个ES报头必须完全包含在数据包中。因此，必须支持261字节的最小RTP有效负载大小，以包含ES中定义的最大单个报头（即，包含quant_matrix_extension（）的extension_data（）报头）。否则，在数据包有效负载中的报头出现位置没有限制。
In MPEG, each picture is made up of one or more "slices," and a slice is intended to be the unit of recovery from data loss or corruption. An MPEG-compliant decoder will normally advance to the beginning of next slice whenever an error is encountered in the stream. MPEG slice begin and end bits are provided in the encapsulation header to facilitate this.
在MPEG中，每个图片由一个或多个“切片”组成，一个切片旨在作为从数据丢失或损坏中恢复的单元。每当流中遇到错误时，符合MPEG的解码器通常会前进到下一个片段的开头。在封装报头中提供了MPEG片段开始和结束位，以便于实现这一点。
The beginning of a slice must either be the first data in a packet (after any MPEG ES headers) or must follow after some integral number of slices in a packet. This requirement insures that the beginning of the next slice after one with a missing packet can be found without requiring that the receiver scan the packet contents. Slices may be fragmented across packets as long as all the above rules are met.
片段的开头必须是数据包中的第一个数据（在任何MPEG ES头之后），或者必须在数据包中某个整数个片段之后。该要求确保可以在不要求接收器扫描数据包内容的情况下找到丢失数据包后的下一个数据片的开头。只要满足上述所有规则，切片就可以在数据包之间分段。
An implementation based on this encapsulation assumes that the Video_Sequence_Header is repeated periodically in the MPEG bit-stream. In practice (though not required by MPEG standard) this is used to allow channel switching and to receive and start decoding a continuously relayed MPEG bit-stream at arbitrary points in the media stream. It is suggested that when playing back from an MPEG stream from a file format (where the Video_Sequence_Header may only be represented at the beginning of the stream) that the first Video_Sequence_Header (preceded by an end-of-stream indicator) be saved by the packetizer for periodic injection in to the network stream.
基于此封装的实现假定视频序列头在MPEG比特流中周期性地重复。在实践中（尽管MPEG标准不要求），这用于允许信道切换，并在媒体流中的任意点接收和开始解码连续中继的MPEG比特流。建议当从文件格式（其中视频序列头可能仅在流的开始处表示）的MPEG流回放时，由打包器保存第一视频序列头（前面有流结束指示符），以便周期性地注入到网络流中。
MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG ancillary_data() header. For either MPEG1 or MPEG2 Audio, distinct Presentation Time Stamps may be present for frames which correspond to either 384 samples for Layer-I, or 1152 samples for Layer-II or Layer-III. The actual number of bytes required to represent this number of samples will vary depending on the encoder parameters.
MPEG1音频可以从MPEG/U data（）头中与MPEG2音频区分开来。对于MPEG1或MPEG2音频，对于与第一层的384个样本或第二层或第三层的1152个样本相对应的帧，可能存在不同的呈现时间戳。表示此样本数所需的实际字节数将根据编码器参数而变化。
Multiple audio frames may be encapsulated within one RTP packet. In this case, an integral number of audio frames must be contained within the packet and the fragmentation header defined in Section 3.5 shall be set to 0.
多个音频帧可以封装在一个RTP分组中。在这种情况下，数据包中必须包含整数个音频帧，并且第3.5节中定义的分段头应设置为0。
Also, if relatively short packets are to be used, one frame may be so large that it may straddle multiple RTP packets. For example, for Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would represent a time slot of 26.1 msec. At this sampling rate if the compressed bit-rate is 384 kbits/sec (i.e. 48 kBytes/sec) then the average audio frame size would be 1.25 KBytes. If packets were to be 500 Bytes long, then each audio frame would straddle 3 RTP packets.
此外，如果要使用相对较短的分组，则一个帧可能非常大，以至于它可能跨越多个RTP分组。例如，对于以44.1 KHz的速率采样的第二层MPEG音频，每个帧将表示26.1毫秒的时隙。在此采样率下，如果压缩比特率为384千比特/秒（即48千字节/秒），则平均音频帧大小为1.25千字节。如果数据包的长度为500字节，那么每个音频帧将跨越3个RTP数据包。
The audio fragmentation indicator header (See Section 3.5) shall be present for an MPEG1/2 Audio payload type to provide for this fragmentation.
应为MPEG1/2音频有效负载类型提供音频分段指示器标题（见第3.5节），以提供该分段。
The RTP header fields are used as follows:
RTP标头字段的使用方式如下：
Payload Type: Distinct payload types should be assigned for video elementary streams and audio elementary streams. See [4] for payload type assignments.
有效负载类型：应为视频基本流和音频基本流分配不同的有效负载类型。有关有效负载类型分配，请参见[4]。
M bit: For video, set to 1 on packet containing MPEG frame end code, 0 otherwise. For audio, set to 1 on first packet of a "talk-spurt," 0 otherwise.
M位：对于视频，在包含MPEG帧结束码的数据包上设置为1，否则设置为0。对于音频，在“通话爆发”的第一个数据包上设置为1，否则设置为0。
PT: MPEG video or audio stream ID.
PT:MPEG视频或音频流ID。
timestamp: 32-bit 90K Hz timestamp representing presentation time of MPEG picture or audio frame. Same for all packets that make up a picture or audio frame. May not be monotonically increasing in video stream if B pictures present in stream. For packets that contain only a video sequence and/or GOP header, the timestamp is that of the subsequent picture.
时间戳：32位90K Hz时间戳，表示MPEG图片或音频帧的显示时间。对于构成图片或音频帧的所有数据包也是如此。若视频流中存在B图片，则视频流中可能不会单调增加。对于仅包含视频序列和/或GOP报头的数据包，时间戳是后续图片的时间戳。
This header shall be attached to each RTP packet after the RTP fixed header.
该报头应连接至RTP固定报头后的每个RTP数据包。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T| TR | |N|S|B|E| P | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AN FBV FFV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T| TR | |N|S|B|E| P | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AN FBV FFV
MBZ: Unused. Must be set to zero in current specification. This space is reserved for future use.
没用过。在当前规范中必须设置为零。这个空间留作将来使用。
T: MPEG-2 (Two) specific header extension present (1 bit). Set to 1 when the MPEG-2 video-specific header extension (see Section 3.4.1) follows this header. This extension may be needed for improved error resilience; however, its inclusion in an RTP packet is optional. (See Appendix 1.)
T:MPEG-2（两个）特定的报头扩展（1位）。当MPEG-2视频特定头扩展（见第3.4.1节）跟随此头时，设置为1。可能需要这种扩展来提高错误恢复能力；但是，在RTP数据包中包含它是可选的。（见附录1。）
TR: Temporal-Reference (10 bits). The temporal reference of the current picture within the current GOP. This value ranges from 0-1023 and is constant for all RTP packets of a given picture.
TR：时间参考（10位）。当前GOP中当前图片的时间参考。该值的范围为0-1023，对于给定图片的所有RTP数据包都是常量。
AN: Active N bit for error resilience (1 bit). Set to 1 when the following bit (N) is used to signal changes in the picture header information for MPEG-2 payloads. It must be set to 0 for MPEG-1 payloads or when N bit is not used.
AN：用于错误恢复的活动N位（1位）。当以下位（N）用于表示MPEG-2有效载荷的图片头信息的变化时，设置为1。对于MPEG-1有效载荷或未使用N位时，必须将其设置为0。
N: New picture header (1 bit). Used for MPEG-2 payloads when the previous bit (AN) is set to 1. Otherwise, it must be set to zero. Set to 1 when the information contained in the previously transmitted Picture Headers can't be used to reconstruct a header for the current picture. This happens when the current picture is encoded using a different set of parameters than the previous pictures of the same type. The N bit must be constant for all RTP packets that belong to the same picture so that receipt of any packet from a picture allows detecting whether information necessary for reconstruction was contained in that picture (N = 1) or a previous one (N = 0).
N：新图片标题（1位）。当前一位（AN）设置为1时，用于MPEG-2有效载荷。否则，它必须设置为零。当先前传输的图片标题中包含的信息无法用于重建当前图片的标题时，设置为1。当使用与相同类型的先前图片不同的一组参数对当前图片进行编码时，会发生这种情况。对于属于同一图片的所有RTP数据包，N位必须是恒定的，以便从图片接收任何数据包都允许检测重建所需的信息是包含在该图片中（N=1）还是包含在前一图片中（N=0）。
S: Sequence-header-present (1 bit). Normally 0 and set to 1 at the occurrence of each MPEG sequence header. Used to detect presence of sequence header in RTP packet.
序列头存在（1位）。通常为0，并在每个MPEG序列头出现时设置为1。用于检测RTP数据包中是否存在序列头。
B: Beginning-of-slice (BS) (1 bit). Set when the start of the packet payload is a slice start code, or when a slice start code is preceded only by one or more of a Video_Sequence_Header, GOP_header and/or Picture_Header.
B：片的开始（BS）（1位）。当数据包有效负载的开始是片段开始代码时，或者当片段开始代码之前只有一个或多个视频序列头、GOP头和/或图片头时设置。
E: End-of-slice (ES) (1 bit). Set when the last byte of the payload is the end of an MPEG slice.
E：切片结束（ES）（1位）。当有效负载的最后一个字节是MPEG片段的结尾时设置。
P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This value is constant for each RTP packet of a given picture. Value 000B is forbidden and 101B - 111B are reserved to support future extensions to the MPEG ES specification.
P：图片类型（3位）。I（1）、P（2）、B（3）或D（4）。对于给定图片的每个RTP数据包，该值是恒定的。值000B被禁止，101B-111B被保留以支持将来对MPEG ES规范的扩展。
FBV: full_pel_backward_vector BFC: backward_f_code FFV: full_pel_forward_vector FFC: forward_f_code Obtained from the most recent picture header, and are constant for each RTP packet of a given picture. For I frames none of these values are present in the picture header and
FBV:full_pel_backward_vector BFC:backward_f_code FFV:full_pel_forward_vector FFC:forward_f_code从最近的图片头中获取，对于给定图片的每个RTP包都是常量。对于I帧，图片标题和
they must be set to zero in the RTP header. For P frames only the last two values are present and FBV and BFC must be set to zero in the RTP header. For B frames all the four values are present.
它们必须在RTP标头中设置为零。对于P帧，只有最后两个值存在，并且必须在RTP报头中将FBV和BFC设置为零。对于B帧，所有四个值都存在。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X: Unused (1 bit). Must be set to zero in current specification. This space is reserved for future use.
X：未使用（1位）。在当前规范中必须设置为零。这个空间留作将来使用。
E: Extensions present (1 bit). If set to 1, this header extension, including the composite display extension when D = 1, will be followed by one or more of the following extensions: quant matrix extension, picture display extension, picture temporal scalable extension, picture spatial scalable extension and copyright extension.
E：存在扩展（1位）。如果设置为1，则此标题扩展（包括D=1时的复合显示扩展）后面将跟随一个或多个以下扩展：数量矩阵扩展、图片显示扩展、图片时间可伸缩扩展、图片空间可伸缩扩展和版权扩展。
The first byte of these extensions data gives the length of the extensions in 32 bit words including the length field itself. Zero padding bytes are used at the end if required to align the extensions to 32 bit boundary.
这些扩展数据的第一个字节以32位字表示扩展的长度，包括长度字段本身。如果需要将扩展与32位边界对齐，则在末尾使用零填充字节。
Since they may not be vital in decoding of a picture, the inclusion of any one of these extensions in an RTP packet is optional even when the MPEG-2 video-specific header extension is included in the packet (T = 1). (See Appendix 1.) If present, they should be copied from the corresponding extensions following the most recent MPEG-2 picture coding extension and they remain constant for each RTP packet of a given picture.
由于这些扩展在图片解码中可能不重要，因此即使在分组中包括MPEG-2视频特定报头扩展（T＝1）时，在RTP分组中包括这些扩展中的任何一个也是可选的。（见附录1。）如果存在，则应从最新的MPEG-2图片编码扩展之后的相应扩展中复制，并且对于给定图片的每个RTP数据包，它们保持不变。
The extension start code (32 bits) and the extension start code ID (4 bits) are included. Therefore the extensions are self identifying.
包括扩展开始代码（32位）和扩展开始代码ID（4位）。因此，扩展是自识别的。
f_[0,0]: forward horizontal f_code (4 bits) f_[0,1]: forward vertical f_code (4 bits) f_[1,0]: backward horizontal f_code (4 bits) f_[1,1]: backward vertical f_code (4 bits) DC: intra_DC_precision (2 bits) PS: picture_structure (2 bits)
前向水平f_码（4位）f_码（0,1）：前向垂直f_码（4位）f_码（1,0）：后向水平f_码（4位）f_码（1,1）：后向垂直f_码（4位）DC：帧内DC_精度（2位）PS：图片结构（2位）
T: top_field_first (1 bit) P: frame_predicted_frame_dct (1 bit) C: concealment_motion_vectors (1 bit) Q: q_scale type (1 bit) V: intra_vlc_format (1 bit) A: alternate scan (1 bit) R: repeat_first_field (1 bit) H: chroma_420_type (1 bit) G: progressive frame (1 bit) D: composite_display_flag (1 bit). If set to 1, next 32 bits following this one contains 12 zeros followed by 20 bits of composite display information.
T:top_field_first（1位）P:frame_predicted_frame_dct（1位）C:Underation_motion_vectors（1位）Q:Q_scale type（1位）V:intra_vlc_format（1位）A:alternate scan（1位）R:repeat_first_field（1位）H:chroma_420_type（1位）G:progressive frame（1位）D:composite_display_flag（1位）D:composite_flag（1位）。如果设置为1，则该位之后的下一个32位包含12个零，后跟20位复合显示信息。
These values are copied from the most recent picture coding extension and are constant for each RTP packet of a given picture. Their meanings are as explained in the MPEG-2 standard.
这些值是从最近的图片编码扩展中复制的，对于给定图片的每个RTP数据包都是常量。它们的含义如MPEG-2标准所述。
This header shall be attached to each RTP packet at the start of the payload and after any RTP headers for an MPEG1/2 Audio payload type.
对于MPEG1/2音频有效负载类型，该报头应在有效负载开始时和任何RTP报头之后连接到每个RTP数据包。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | Frag_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | Frag_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frag_offset: Byte offset into the audio frame for the data in this packet.
Frag_offset：此数据包中数据进入音频帧的字节偏移量。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3], and any appropriate RTP profile (for example [4]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[3]和任何适当RTP配置文件（例如[4]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。然而，这种编码并没有表现出任何显著的非均匀性。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，可以在IGMP[5]的未来版本和多播路由协议中实现特定源的修剪，以允许接收机选择允许哪些源到达它。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
对该有效负载格式的安全性审查发现，除了RTP规范中的考虑之外，没有其他考虑。
Appendix 1. Error Recovery and Resynchronization Strategies.
附录1。错误恢复和重新同步策略。
The following error recovery and resynchronization strategies are intended to be guidelines only. A compliant receiver is free to employ alternative (or no) strategies.
以下错误恢复和重新同步策略仅供参考。合规接收机可自由采用替代（或无）策略。
When initially decoding an RTP-encapsulated MPEG Elementary Stream, the receiver may discard all packets until the Sequence-header-present bit is set to 1. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder.
当最初解码RTP封装的MPEG基本流时，接收机可以丢弃所有分组，直到序列报头呈现比特被设置为1为止。此时，流中包含足够的状态信息以允许MPEG解码器进行处理。
Loss of packets containing the GOP_header and/or Picture_Header are detected by an unexpected change in the Temporal-Reference and Picture-Type values. Consider the following example GOP sequence:
包含GOP_报头和/或Picture_报头的分组的丢失由时间参考值和图片类型值中的意外变化检测。考虑下面的例子GOP序列：
In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ... In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
按显示顺序：0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B。。。按流顺序：2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I。。。
Consider also two counters:
同时考虑两个计数器：
ref_pic_temp (Reference Picture (I,P) Temporal Reference) dep_pic_temp (Dependent Picture (B) Temporal Reference)
参考图片临时（参考图片（I，P）临时参考）副图片临时（从属图片（B）临时参考）
At each GOP beginning, set these counters to the temporal reference value of the corresponding picture type. For our example GOP sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing BOTH counters by unity with each following picture. Ref_pic_temp should match the temporal references of the I and P frames, and dep_pic_temp should match the temporal references of the B frames.
在每个GOP开始时，将这些计数器设置为相应图片类型的时间参考值。对于我们的示例GOP序列，ref_pic_temp=2和dep_pic_temp=0。在下图中，两个计数器按单位递增。Ref_pic_temp应匹配I和P帧的时间参考，dep_pic_temp应匹配B帧的时间参考。
dep_pic_temp: - 0 1 2 3 4 5 6 7 8 9
In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
ref_pic_temp: 2 3 4 5 6 7 8 9 10 ^ 11
-------------------------- | ^
Match Drop |
Mismatch
in ref_pic_temp
dep_pic_temp: - 0 1 2 3 4 5 6 7 8 9
In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
ref_pic_temp: 2 3 4 5 6 7 8 9 10 ^ 11
-------------------------- | ^
Match Drop |
Mismatch
in ref_pic_temp
The loss of a GOP header can be detected by matching the appropriate counter (based on picture type) to the temporal reference value. A mismatch indicates a lost GOP header. If desired, a GOP header can be re-constructed using a "null" time_code, repeating the closed_gop flag from previous GOP headers, and setting the broken_link flag to 1.
可以通过将适当的计数器（基于图片类型）与时间参考值匹配来检测GOP报头的丢失。不匹配表示丢失GOP标头。如果需要，可以使用“空”时间\代码重新构造GOP头，从以前的GOP头重复关闭\ GOP标志，并将断开\链接标志设置为1。
The loss of a Picture_Header can also be detected by a mismatch in the Temporal Reference contained in the RTP packet from the appropriate dep_pic_temp or ref_pic_temp counters at the receiver.
图片头部的丢失也可以通过来自接收器处的适当dep_pic_temp或ref_pic_temp计数器的RTP分组中包含的时间参考中的不匹配来检测。
For MPEG-1 payloads, after scanning to the next Beginning-of-slice the Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and FFC contained in that packet, and from stream-dependent default values.
对于MPEG-1有效载荷，在扫描到切片的下一个开始之后，从该分组中包含的P、TR、FBV、BFC、FFV和FFC以及依赖于流的默认值重构图片_报头。
For MPEG-2, additional information is needed for the reconstruction. This information is provided by the MPEG-2 video specific header extension contained in that packet if the T bit is set to 1, or the Picture Header for the current picture may be available from previous packets belonging to the same picture. The transmitter's strategy for inclusion of the MPEG-2 video specific header extension may depend upon a number of factors. This header may not be needed when:
对于MPEG-2，重建需要额外的信息。如果T比特被设置为1，则该信息由该分组中包含的MPEG-2视频特定报头扩展提供，或者当前图片的图片报头可以从属于相同图片的先前分组中获得。发射机包含MPEG-2视频特定报头扩展的策略可能取决于许多因素。以下情况下可能不需要此标题：
1. the information has been transmitted a sufficient number of times in previous packets to assure reception with the desired probability, or
1. 该信息在先前分组中已被发送足够次数以确保以期望的概率接收，或
2. the information is transmitted over a separate reliable channel, or
2. 信息通过单独的可靠信道传输，或
3. expected loss rates are low enough that missed frames are not a concern, or
3. 预期的丢失率足够低，因此丢失的帧不成问题，或者
4. conserving bandwidth is more important than error resilience, etc.
4. 节约带宽比错误恢复能力等更重要。
If T=1 and E=0, there may be extensions present in the original video bitstream that are not included in the current packet. The transmitter may choose not to include extensions in a packet when they are not necessary for decoding or if one of the cases listed above for not including the MPEG-2 video specific header extension in a packet applies only to the extension data.
如果T＝1且E＝0，则原始视频比特流中可能存在未包括在当前分组中的扩展。当解码不需要扩展时，或者如果上面列出的在分组中不包括MPEG-2视频特定报头扩展的情况之一仅适用于扩展数据，则发射机可以选择不在分组中包括扩展。
If N=0, then the Picture Header from a previous picture of the same type (I,P or B) may be used so long as at least one packet has been received for every intervening picture of the same type and that the N bit was 0 for each of those pictures. This may involve:
如果N＝0，则可以使用来自相同类型（I、P或B）的先前图片的图片报头，只要对于相同类型的每个介入图片已经接收到至少一个分组，并且对于这些图片中的每个图片，N位是0。这可能涉及：
1. Saving the relevant picture header information that can be obtained from the MPEG-2 video specific header extension or directly from the video bitstream for each picture type,
1. 保存可从MPEG-2视频特定报头扩展或直接从每种图片类型的视频比特流获得的相关图片报头信息，
2. Keeping validity indicators for this saved information based on the received N bits and lost packets, and,
2. 根据接收到的N位和丢失的数据包，保留该保存信息的有效性指示符，以及，
3. Updating the data whenever a packet with N=1 is received.
3. 每当接收到N＝1的数据包时更新数据。
If the necessary information is not available from any of these sources, data deletion until a new picture start code is advised.
如果这些来源中的任何一个都没有必要的信息，请删除数据，直到建议使用新的图片开始代码。
Any time an RTP packet is lost (as indicated by a gap in the RTP sequence number), the receiver may discard all packets until the Beginning-of-slice bit is set. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder starting at the next slice boundary (possibly after reconstruction of the GOP_header and/or Picture_Header as described above).
每当RTP数据包丢失时（如RTP序列号中的间隙所示），接收机可以丢弃所有数据包，直到设置了片位的开头。此时，流中包含足够的状态信息以允许MPEG解码器从下一个片边界开始进行处理（可能在如上所述重构GOP_报头和/或Picture_报头之后）。
References
工具书类
[1] ISO/IEC International Standard 11172; "Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbits/s", November 1993.
[1] ISO/IEC国际标准11172；“高达约1.5 Mbits/s的数字存储媒体的运动图像和相关音频编码”，1993年11月。
[2] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information", November 1994.
[2] ISO/IEC国际标准13818；“运动图像和相关音频信息的通用编码”，1994年11月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
Authors' Addresses
作者地址
Gerard Fernando Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
美国加利福尼亚州加西亚大道山景城Gerard Fernando Sun Microsystems，Inc.邮件站UMPK14-305 2550 94043-1100
Phone: +1 415-786-6373
EMail: gerard.fernando@eng.sun.com
Phone: +1 415-786-6373
EMail: gerard.fernando@eng.sun.com
Vivek Goyal Precept Software, Inc. 1072 Arastradero Rd, Palo Alto, CA 94304 USA
美国加利福尼亚州帕洛阿尔托阿拉斯塔德罗路1072号Vivek Goyal Procept软件有限公司，邮编94304
Phone: +1 415-845-5200
EMail: goyal@precept.com
Phone: +1 415-845-5200
EMail: goyal@precept.com
Don Hoffman Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
美国加利福尼亚州山景城加西亚大道2550号唐霍夫曼太阳微系统公司邮件站UMPK14-305 94043-1100
Phone: +1 503-297-1580
EMail: don.hoffman@eng.sun.com
Phone: +1 503-297-1580
EMail: don.hoffman@eng.sun.com
M. Reha Civanlar AT&T Labs - Research 100 Schutlz Drive, 3-213 Red Bank, NJ 07701-7033 USA
M.Reha Civanlar AT&T实验室-美国新泽西州红银行3-213号舒特尔茨大道100号研究中心，邮编：07701-7033
Phone: +1 732-345-3305
EMail: civanlar@research.att.com
Phone: +1 732-345-3305
EMail: civanlar@research.att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。