Internet Engineering Task Force (IETF) Y.-K. Wang
Request for Comments: 7798 Qualcomm
Category: Standards Track Y. Sanchez
ISSN: 2070-1721 T. Schierl
Fraunhofer HHI
S. Wenger
Vidyo
M. M. Hannuksela
Nokia
March 2016
Internet Engineering Task Force (IETF) Y.-K. Wang
Request for Comments: 7798 Qualcomm
Category: Standards Track Y. Sanchez
ISSN: 2070-1721 T. Schierl
Fraunhofer HHI
S. Wenger
Vidyo
M. M. Hannuksela
Nokia
March 2016
RTP Payload Format for High Efficiency Video Coding (HEVC)
用于高效视频编码（HEVC）的RTP有效负载格式
Abstract
摘要
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.
本备忘录描述了视频编码标准ITU-T建议H.265和ISO/IEC国际标准23008-2的RTP有效载荷格式，两者也称为高效视频编码（HEVC），由视频编码联合协作小组（JCT-VC）开发。RTP有效载荷格式允许在每个RTP数据包有效载荷中对一个或多个网络抽象层（NAL）单元进行分组，以及将NAL单元分割成多个RTP数据包。此外，它支持通过单个流以及多个RTP流传输HEVC比特流。当使用多个RTP流时，可以使用单个传输或多个传输。有效载荷格式在视频会议、互联网视频流和高比特率娱乐质量视频等方面具有广泛的适用性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7798.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7798.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Overview of the HEVC Codec .................................4
1.1.1. Coding-Tool Features ................................4
1.1.2. Systems and Transport Interfaces ....................6
1.1.3. Parallel Processing Support ........................11
1.1.4. NAL Unit Header ....................................13
1.2. Overview of the Payload Format ............................14
2. Conventions ....................................................15
3. Definitions and Abbreviations ..................................15
3.1. Definitions ...............................................15
3.1.1. Definitions from the HEVC Specification ...........15
3.1.2. Definitions Specific to This Memo .................17
3.2. Abbreviations .............................................19
4. RTP Payload Format .............................................20
4.1. RTP Header Usage ..........................................20
4.2. Payload Header Usage ......................................22
4.3. Transmission Modes ........................................23
4.4. Payload Structures ........................................24
4.4.1. Single NAL Unit Packets ............................24
4.4.2. Aggregation Packets (APs) ..........................25
4.4.3. Fragmentation Units ................................29
4.4.4. PACI Packets .......................................32
4.4.4.1. Reasons for the PACI Rules (Informative) ..34
4.4.4.2. PACI Extensions (Informative) .............35
4.5. Temporal Scalability Control Information ..................36
4.6. Decoding Order Number .....................................37
5. Packetization Rules ............................................39
6. De-packetization Process .......................................40
7. Payload Format Parameters ......................................42
7.1. Media Type Registration ...................................42
7.2. SDP Parameters ............................................64
1. Introduction ....................................................3
1.1. Overview of the HEVC Codec .................................4
1.1.1. Coding-Tool Features ................................4
1.1.2. Systems and Transport Interfaces ....................6
1.1.3. Parallel Processing Support ........................11
1.1.4. NAL Unit Header ....................................13
1.2. Overview of the Payload Format ............................14
2. Conventions ....................................................15
3. Definitions and Abbreviations ..................................15
3.1. Definitions ...............................................15
3.1.1. Definitions from the HEVC Specification ...........15
3.1.2. Definitions Specific to This Memo .................17
3.2. Abbreviations .............................................19
4. RTP Payload Format .............................................20
4.1. RTP Header Usage ..........................................20
4.2. Payload Header Usage ......................................22
4.3. Transmission Modes ........................................23
4.4. Payload Structures ........................................24
4.4.1. Single NAL Unit Packets ............................24
4.4.2. Aggregation Packets (APs) ..........................25
4.4.3. Fragmentation Units ................................29
4.4.4. PACI Packets .......................................32
4.4.4.1. Reasons for the PACI Rules (Informative) ..34
4.4.4.2. PACI Extensions (Informative) .............35
4.5. Temporal Scalability Control Information ..................36
4.6. Decoding Order Number .....................................37
5. Packetization Rules ............................................39
6. De-packetization Process .......................................40
7. Payload Format Parameters ......................................42
7.1. Media Type Registration ...................................42
7.2. SDP Parameters ............................................64
7.2.1. Mapping of Payload Type Parameters to SDP ..........64
7.2.2. Usage with SDP Offer/Answer Model ..................65
7.2.3. Usage in Declarative Session Descriptions ..........73
7.2.4. Considerations for Parameter Sets ..................75
7.2.5. Dependency Signaling in Multi-Stream Mode ..........75
8. Use with Feedback Messages .....................................75
8.1. Picture Loss Indication (PLI) .............................75
8.2. Slice Loss Indication (SLI) ...............................76
8.3. Reference Picture Selection Indication (RPSI) .............77
8.4. Full Intra Request (FIR) ..................................77
9. Security Considerations ........................................78
10. Congestion Control ............................................79
11. IANA Considerations ...........................................80
12. References ....................................................80
12.1. Normative References .....................................80
12.2. Informative References ...................................82
Acknowledgments ...................................................85
Authors' Addresses ................................................86
7.2.1. Mapping of Payload Type Parameters to SDP ..........64
7.2.2. Usage with SDP Offer/Answer Model ..................65
7.2.3. Usage in Declarative Session Descriptions ..........73
7.2.4. Considerations for Parameter Sets ..................75
7.2.5. Dependency Signaling in Multi-Stream Mode ..........75
8. Use with Feedback Messages .....................................75
8.1. Picture Loss Indication (PLI) .............................75
8.2. Slice Loss Indication (SLI) ...............................76
8.3. Reference Picture Selection Indication (RPSI) .............77
8.4. Full Intra Request (FIR) ..................................77
9. Security Considerations ........................................78
10. Congestion Control ............................................79
11. IANA Considerations ...........................................80
12. References ....................................................80
12.1. Normative References .....................................80
12.2. Informative References ...................................82
Acknowledgments ...................................................85
Authors' Addresses ................................................86
The High Efficiency Video Coding specification, formally published as both ITU-T Recommendation H.265 [HEVC] and ISO/IEC International Standard 23008-2 [ISO23008-2], was ratified by the ITU-T in April 2013; reportedly, it provides significant coding efficiency gains over H.264 [H.264].
2013年4月，ITU-T批准了作为ITU-T建议H.265[HEVC]和ISO/IEC国际标准23008-2[ISO23008-2]正式发布的高效视频编码规范；据报道，它比H.264[H.264]提供了显著的编码效率增益。
This memo describes an RTP payload format for HEVC. It shares its basic design with the RTP payload formats of [RFC6184] and [RFC6190]. With respect to design philosophy, security, congestion control, and overall implementation complexity, it has similar properties to those earlier payload format specifications. This is a conscious choice, as at least RFC 6184 is widely deployed and generally known in the relevant implementer communities. Mechanisms from RFC 6190 were incorporated as HEVC version 1 supports temporal scalability.
本备忘录描述了HEVC的RTP有效负载格式。它与[RFC6184]和[RFC6190]的RTP有效负载格式共享其基本设计。在设计理念、安全性、拥塞控制和总体实现复杂性方面，它具有与早期有效负载格式规范类似的特性。这是一个有意识的选择，因为至少RFC6184被广泛部署，并且在相关的实现者社区中广为人知。来自RFC6190的机制被合并为HEVC版本1支持时间可伸缩性。
In order to help the overlapping implementer community, frequently only the differences between RFCs 6184 and 6190 and the HEVC payload format are highlighted in non-normative, explanatory parts of this memo. Basic familiarity with both specifications is assumed for those parts. However, the normative parts of this memo do not require study of RFCs 6184 or 6190.
为了帮助重叠的实施者群体，通常只有RFC 6184和6190与HEVC有效载荷格式之间的差异才会在本备忘录的非规范性解释部分突出显示。假设这些零件基本熟悉这两种规格。但是，本备忘录的规范性部分不要求研究RFC 6184或6190。
H.264 and HEVC share a similar hybrid video codec design. In this memo, we provide a very brief overview of those features of HEVC that are, in some form, addressed by the payload format specified herein. Implementers have to read, understand, and apply the ITU-T/ISO/IEC specifications pertaining to HEVC to arrive at interoperable, well-performing implementations. Implementers should consider testing their design (including the interworking between the payload format implementation and the core video codec) using the tools provided by ITU-T/ISO/IEC, for example, conformance bitstreams as specified in [H.265.1]. Not doing so has historically led to systems that perform badly and that are not secure.
H.264和HEVC共享类似的混合视频编解码器设计。在本备忘录中，我们简要概述了HEVC的功能，这些功能以某种形式通过本文指定的有效负载格式进行了说明。实施者必须阅读、理解并应用与HEVC相关的ITU-T/ISO/IEC规范，以实现可互操作、性能良好的实施。实现者应该考虑使用ITU-T/ISO/IEC提供的工具测试它们的设计（包括有效载荷格式实现和核心视频编解码器之间的互通），例如，在[H.265.1]中指定的一致性比特流。历史上，不这样做会导致系统性能差且不安全。
Conceptually, both H.264 and HEVC include a Video Coding Layer (VCL), which is often used to refer to the coding-tool features, and a Network Abstraction Layer (NAL), which is often used to refer to the systems and transport interface aspects of the codecs.
从概念上讲，H.264和HEVC都包括视频编码层（VCL）和网络抽象层（NAL），视频编码层（VCL）通常用于指代编码工具特性，网络抽象层（NAL）通常用于指代编解码器的系统和传输接口方面。
Similar to earlier hybrid-video-coding-based standards, including H.264, the following basic video coding design is employed by HEVC. A prediction signal is first formed by either intra- or motion-compensated prediction, and the residual (the difference between the original and the prediction) is then coded. The gains in coding efficiency are achieved by redesigning and improving almost all parts of the codec over earlier designs. In addition, HEVC includes several tools to make the implementation on parallel architectures easier. Below is a summary of HEVC coding-tool features.
与早期基于混合视频编码的标准（包括H.264）类似，HEVC采用以下基本视频编码设计。首先通过帧内或运动补偿预测形成预测信号，然后对残差（原始和预测之间的差）进行编码。与早期设计相比，通过重新设计和改进编解码器的几乎所有部分，可以提高编码效率。此外，HEVC还包括一些工具，使在并行体系结构上的实现更容易。下面是HEVC编码工具功能的摘要。
Quad-tree block and transform structure
四叉树块与变换结构
One of the major tools that contributes significantly to the coding efficiency of HEVC is the use of flexible coding blocks and transforms, which are defined in a hierarchical quad-tree manner. Unlike H.264, where the basic coding block is a macroblock of fixed-size 16x16, HEVC defines a Coding Tree Unit (CTU) of a maximum size of 64x64. Each CTU can be divided into smaller units in a hierarchical quad-tree manner and can represent smaller blocks down to size 4x4. Similarly, the transforms used in HEVC can have different sizes, starting from 4x4 and going up to 32x32. Utilizing large blocks and transforms contributes to the major gain of HEVC, especially at high resolutions.
对HEVC的编码效率做出重大贡献的主要工具之一是使用灵活的编码块和变换，它们以分层四叉树的方式定义。与H.264不同，H.264的基本编码块是固定大小16x16的宏块，HEVC定义了最大大小为64x64的编码树单元（CTU）。每个CTU可以以分层四叉树的方式划分为更小的单元，并且可以表示更小的块，大小为4x4。类似地，HEVC中使用的变换可以有不同的大小，从4x4到32x32。利用大的块和变换有助于HEVC的主要增益，特别是在高分辨率下。
Entropy coding
熵编码
HEVC uses a single entropy-coding engine, which is based on Context Adaptive Binary Arithmetic Coding (CABAC) [CABAC], whereas H.264 uses two distinct entropy coding engines. CABAC in HEVC shares many similarities with CABAC of H.264, but contains several improvements. Those include improvements in coding efficiency and lowered implementation complexity, especially for parallel architectures.
HEVC使用单个熵编码引擎，该引擎基于上下文自适应二进制算术编码（CABAC）[CABAC]，而H.264使用两个不同的熵编码引擎。HEVC中的CABAC与H.264中的CABAC有许多相似之处，但有一些改进。这些包括编码效率的提高和实现复杂性的降低，特别是对于并行体系结构。
In-loop filtering
环路内滤波
H.264 includes an in-loop adaptive deblocking filter, where the blocking artifacts around the transform edges in the reconstructed picture are smoothed to improve the picture quality and compression efficiency. In HEVC, a similar deblocking filter is employed but with somewhat lower complexity. In addition, pictures undergo a subsequent filtering operation called Sample Adaptive Offset (SAO), which is a new design element in HEVC. SAO basically adds a pixel-level offset in an adaptive manner and usually acts as a de-ringing filter. It is observed that SAO improves the picture quality, especially around sharp edges, contributing substantially to visual quality improvements of HEVC.
H.264包括一个环路内自适应去块滤波器，其中平滑重建图像中变换边缘周围的块效应，以提高图像质量和压缩效率。在HEVC中，采用了类似的解块滤波器，但复杂度稍低。此外，图片还要经过一个称为采样自适应偏移（SAO）的后续过滤操作，这是HEVC中的一个新设计元素。SAO基本上以自适应方式添加像素级偏移，通常用作去振铃滤波器。据观察，SAO改善了图像质量，尤其是锐利边缘周围的图像质量，大大有助于HEVC的视觉质量改善。
Motion prediction and coding
运动预测与编码
There have been a number of improvements in this area that are summarized as follows. The first category is motion merge and Advanced Motion Vector Prediction (AMVP) modes. The motion information of a prediction block can be inferred from the spatially or temporally neighboring blocks. This is similar to the DIRECT mode in H.264 but includes new aspects to incorporate the flexible quad-tree structure and methods to improve the parallel implementations. In addition, the motion vector predictor can be signaled for improved efficiency. The second category is high-precision interpolation. The interpolation filter length is increased to 8-tap from 6-tap, which improves the coding efficiency but also comes with increased complexity. In addition, the interpolation filter is defined with higher precision without any intermediate rounding operations to further improve the coding efficiency.
在这方面有许多改进，总结如下。第一类是运动合并和高级运动矢量预测（AMVP）模式。可以从空间或时间上相邻的块推断预测块的运动信息。这类似于H.264中的直接模式，但包含了新的方面，以结合灵活的四叉树结构和方法来改进并行实现。此外，可以向运动矢量预测器发送信号以提高效率。第二类是高精度插值。插值滤波器长度从6抽头增加到8抽头，这提高了编码效率，但也增加了复杂性。此外，插值滤波器的定义精度更高，无需任何中间舍入操作，以进一步提高编码效率。
Intra prediction and intra-coding
帧内预测和帧内编码
Compared to 8 intra prediction modes in H.264, HEVC supports angular intra prediction with 33 directions. This increased flexibility improves both objective coding efficiency and visual quality as the edges can be better predicted and ringing artifacts around the edges can be reduced. In addition, the reference samples are adaptively smoothed based on the prediction direction. To avoid contouring
与H.264中的8种帧内预测模式相比，HEVC支持33个方向的角度帧内预测。这种增加的灵活性提高了目标编码效率和视觉质量，因为可以更好地预测边缘，并且可以减少边缘周围的振铃伪影。此外，根据预测方向自适应平滑参考样本。避免轮廓
artifacts a new interpolative prediction generation is included to improve the visual quality. Furthermore, Discrete Sine Transform (DST) is utilized instead of traditional Discrete Cosine Transform (DCT) for 4x4 intra-transform blocks.
伪影包括一个新的插值预测生成，以提高视觉质量。此外，对于4x4帧内变换块，使用离散正弦变换（DST）代替传统的离散余弦变换（DCT）。
Other coding-tool features
其他编码工具功能
HEVC includes some tools for lossless coding and efficient screen-content coding, such as skipping the transform for certain blocks. These tools are particularly useful, for example, when streaming the user interface of a mobile device to a large display.
HEVC包括一些用于无损编码和高效屏幕内容编码的工具，例如跳过某些块的转换。例如，当将移动设备的用户界面流式传输到大型显示器时，这些工具特别有用。
HEVC inherited the basic systems and transport interfaces designs from H.264. These include the NAL-unit-based syntax structure, the hierarchical syntax and data unit structure, the Supplemental Enhancement Information (SEI) message mechanism, and the video buffering model based on the Hypothetical Reference Decoder (HRD). The hierarchical syntax and data unit structure consists of sequence-level parameter sets, multi-picture-level or picture-level parameter sets, slice-level header parameters, and lower-level parameters. In the following, a list of differences in these aspects compared to H.264 is summarized.
HEVC继承了H.264的基本系统和传输接口设计。其中包括基于NAL单元的语法结构、分层语法和数据单元结构、补充增强信息（SEI）消息机制以及基于假设参考解码器（HRD）的视频缓冲模型。分层语法和数据单元结构由序列级参数集、多图片级或图片级参数集、切片级标题参数和较低级别参数组成。在下文中，总结了这些方面与H.264相比的差异列表。
Video parameter set
视频参数集
A new type of parameter set, called Video Parameter Set (VPS), was introduced. For the first (2013) version of [HEVC], the VPS NAL unit is required to be available prior to its activation, while the information contained in the VPS is not necessary for operation of the decoding process. For future HEVC extensions, such as the 3D or scalable extensions, the VPS is expected to include information necessary for operation of the decoding process, e.g., decoding dependency or information for reference picture set construction of enhancement layers. The VPS provides a "big picture" of a bitstream, including what types of operation points are provided, the profile, tier, and level of the operation points, and some other high-level properties of the bitstream that can be used as the basis for session negotiation and content selection, etc. (see Section 7.1).
介绍了一种新的参数集，称为视频参数集（VPS）。对于[HEVC]的第一个（2013）版本，VPS NAL单元需要在激活之前可用，而VPS中包含的信息对于解码过程的操作不是必需的。对于未来的HEVC扩展，例如3D或可伸缩扩展，VPS预期包括解码过程的操作所必需的信息，例如解码依赖性或用于增强层的参考图片集构造的信息。VPS提供了比特流的“大图”，包括提供了什么类型的操作点、操作点的配置文件、层和级别，以及可作为会话协商和内容选择基础的比特流的一些其他高级属性等（参见第7.1节）。
Profile, tier, and level
配置文件、层和级别
The profile, tier, and level syntax structure that can be included in both the VPS and Sequence Parameter Set (SPS) includes 12 bytes of data to describe the entire bitstream (including all temporally scalable layers, which are referred to as sub-layers in the HEVC specification), and can optionally include more profile, tier, and
VPS和序列参数集（SPS）中都可以包含的配置文件、层和层语法结构包括12字节的数据来描述整个比特流（包括所有时间可伸缩层，在HEVC规范中称为子层），并且可以可选地包括更多的配置文件、层和层
level information pertaining to individual temporally scalable layers. The profile indicator shows the "best viewed as" profile when the bitstream conforms to multiple profiles, similar to the major brand concept in the ISO Base Media File Format (ISOBMFF) [IS014496-12] [IS015444-12] and file formats derived based on ISOBMFF, such as the 3GPP file format [3GPPFF]. The profile, tier, and level syntax structure also includes indications such as 1) whether the bitstream is free of frame-packed content, 2) whether the bitstream is free of interlaced source content, and 3) whether the bitstream is free of field pictures. When the answer is yes for both 2) and 3), the bitstream contains only frame pictures of progressive source. Based on these indications, clients/players without support of post-processing functionalities for the handling of frame-packed, interlaced source content or field pictures can reject those bitstreams that contain such pictures.
与单个时间可伸缩层相关的级别信息。当比特流符合多个配置文件时，配置文件指示器显示“最佳查看方式”配置文件，类似于ISO基本媒体文件格式（ISOBMFF）[IS014496-12][IS015444-12]中的主要品牌概念以及基于ISOBMFF派生的文件格式，例如3GPP文件格式[3GPPFF]。配置文件、层和层语法结构还包括指示，例如1）比特流是否没有帧压缩内容，2）比特流是否没有隔行扫描的源内容，以及3）比特流是否没有字段图片。当2）和3）的答案均为是时，比特流仅包含渐进源的帧图片。基于这些指示，不支持用于处理帧压缩、隔行扫描源内容或字段图片的后处理功能的客户端/播放器可以拒绝包含这些图片的比特流。
Bitstream and elementary stream
比特流和基本流
HEVC includes a definition of an elementary stream, which is new compared to H.264. An elementary stream consists of a sequence of one or more bitstreams. An elementary stream that consists of two or more bitstreams has typically been formed by splicing together two or more bitstreams (or parts thereof). When an elementary stream contains more than one bitstream, the last NAL unit of the last access unit of a bitstream (except the last bitstream in the elementary stream) must contain an end of bitstream NAL unit, and the first access unit of the subsequent bitstream must be an Intra-Random Access Point (IRAP) access unit. This IRAP access unit may be a Clean Random Access (CRA), Broken Link Access (BLA), or Instantaneous Decoding Refresh (IDR) access unit.
HEVC包含一个基本流的定义，与H.264相比是新的。基本流由一个或多个比特流的序列组成。由两个或多个比特流组成的基本流通常通过将两个或多个比特流（或其部分）拼接在一起而形成。当基本流包含多个比特流时，比特流的最后一个访问单元的最后一个NAL单元（基本流中的最后一个比特流除外）必须包含比特流结束NAL单元，并且后续比特流的第一个访问单元必须是帧内随机访问点（IRAP）访问单元。该IRAP接入单元可以是干净随机接入（CRA）、断开链路接入（BLA）或瞬时解码刷新（IDR）接入单元。
Random access support
随机存取支持
HEVC includes signaling in the NAL unit header, through NAL unit types, of IRAP pictures beyond IDR pictures. Three types of IRAP pictures, namely IDR, CRA, and BLA pictures, are supported: IDR pictures are conventionally referred to as closed group-of-pictures (closed-GOP) random access points whereas CRA and BLA pictures are conventionally referred to as open-GOP random access points. BLA pictures usually originate from splicing of two bitstreams or part thereof at a CRA picture, e.g., during stream switching. To enable better systems usage of IRAP pictures, altogether six different NAL units are defined to signal the properties of the IRAP pictures, which can be used to better match the stream access point types as defined in the ISOBMFF [IS014496-12] [IS015444-12], which are utilized for random access support in both 3GP-DASH [3GPDASH] and MPEG DASH [MPEGDASH]. Pictures following an IRAP picture in decoding order and preceding the IRAP picture in output order are referred to
HEVC通过NAL单元类型在NAL单元报头中包括IDR图片以外的IRAP图片的信令。支持三种类型的IRAP图片，即IDR、CRA和BLA图片：IDR图片通常称为封闭图片组（封闭GOP）随机接入点，而CRA和BLA图片通常称为开放GOP随机接入点。BLA图片通常源于CRA图片处两个比特流或其一部分的拼接，例如，在流切换期间。为了使系统更好地使用IRAP图片，总共定义了六个不同的NAL单元来表示IRAP图片的属性，这些NAL单元可用于更好地匹配ISOBMFF[IS014496-12][IS015444-12]中定义的流接入点类型，ISOBMFF[IS014496-12]中定义的流接入点类型用于3GP-DASH[3GPDASH]和MPEG-DASH中的随机接入支持[MPEGDASH]。参考以解码顺序在IRAP图片之后、以输出顺序在IRAP图片之前的图片
as leading pictures associated with the IRAP picture. There are two types of leading pictures: Random Access Decodable Leading (RADL) pictures and Random Access Skipped Leading (RASL) pictures. RADL pictures are decodable when the decoding started at the associated IRAP picture; RASL pictures are not decodable when the decoding started at the associated IRAP picture and are usually discarded. HEVC provides mechanisms to enable specifying the conformance of a bitstream wherein the originally present RASL pictures have been discarded. Consequently, system components can discard RASL pictures, when needed, without worrying about causing the bitstream to become non-compliant.
作为与IRAP图片关联的主要图片。有两种类型的前导图片：随机访问可解码前导（RADL）图片和随机访问跳过前导（RASL）图片。当解码在相关IRAP图片处开始时，RADL图片是可解码的；当解码从相关的IRAP图片开始时，RASL图片不可解码，通常会被丢弃。HEVC提供了一些机制，用于指定比特流的一致性，其中原始呈现的RASL图片已被丢弃。因此，系统组件可以在需要时丢弃RASL图片，而无需担心导致比特流不兼容。
Temporal scalability support
时间可伸缩性支持
HEVC includes an improved support of temporal scalability, by inclusion of the signaling of TemporalId in the NAL unit header, the restriction that pictures of a particular temporal sub-layer cannot be used for inter prediction reference by pictures of a lower temporal sub-layer, the sub-bitstream extraction process, and the requirement that each sub-bitstream extraction output be a conforming bitstream. Media-Aware Network Elements (MANEs) can utilize the TemporalId in the NAL unit header for stream adaptation purposes based on temporal scalability.
HEVC包括时间可伸缩性的改进支持，通过在NAL单元报头中包括TemporalId的信令、特定时间子层的图片不能被较低时间子层的图片用于帧间预测参考的限制、子比特流提取过程、，以及要求每个子比特流提取输出是一致的比特流。媒体感知网元（mane）可以基于时间可伸缩性利用NAL单元报头中的TemporalId进行流适配。
Temporal sub-layer switching support
时态子层交换支持
HEVC specifies, through NAL unit types present in the NAL unit header, the signaling of Temporal Sub-layer Access (TSA) and Step-wise Temporal Sub-layer Access (STSA). A TSA picture and pictures following the TSA picture in decoding order do not use pictures prior to the TSA picture in decoding order with TemporalId greater than or equal to that of the TSA picture for inter prediction reference. A TSA picture enables up-switching, at the TSA picture, to the sub-layer containing the TSA picture or any higher sub-layer, from the immediately lower sub-layer. An STSA picture does not use pictures with the same TemporalId as the STSA picture for inter prediction reference. Pictures following an STSA picture in decoding order with the same TemporalId as the STSA picture do not use pictures prior to the STSA picture in decoding order with the same TemporalId as the STSA picture for inter prediction reference. An STSA picture enables up-switching, at the STSA picture, to the sub-layer containing the STSA picture, from the immediately lower sub-layer.
HEVC通过NAL单元报头中存在的NAL单元类型指定临时子层访问（TSA）和逐级临时子层访问（STSA）的信令。TSA图片和在解码顺序中的TSA图片之后的图片不使用在解码顺序中的TSA图片之前的图片，其时间ID大于或等于用于帧间预测参考的TSA图片的时间ID。TSA图片使得能够在TSA图片处从直接较低的子层向上切换到包含TSA图片的子层或任何较高的子层。STSA图片不使用与用于帧间预测参考的STSA图片具有相同时间id的图片。以与STSA图片具有相同时间id的解码顺序在STSA图片之后的图片不将以与STSA图片具有相同时间id的解码顺序在STSA图片之前的图片用于帧间预测参考。STSA图片使得能够在STSA图片处从紧邻较低的子层向上切换到包含该STSA图片的子层。
Sub-layer reference or non-reference pictures
子层参考或非参考图片
The concept and signaling of reference/non-reference pictures in HEVC are different from H.264. In H.264, if a picture may be used by any other picture for inter prediction reference, it is a reference
HEVC中参考/非参考图片的概念和信令不同于H.264。在H.264中，如果图片可被任何其他图片用于帧间预测参考，则它是参考
picture; otherwise, it is a non-reference picture, and this is signaled by two bits in the NAL unit header. In HEVC, a picture is called a reference picture only when it is marked as "used for reference". In addition, the concept of sub-layer reference picture was introduced. If a picture may be used by another other picture with the same TemporalId for inter prediction reference, it is a sub-layer reference picture; otherwise, it is a sub-layer non-reference picture. Whether a picture is a sub-layer reference picture or sub-layer non-reference picture is signaled through NAL unit type values.
图画否则，它是一个非参考图片，由NAL单元报头中的两位发出信号。在HEVC中，只有当图片标记为“用于参考”时，才称为参考图片。此外，还引入了子层参考图的概念。如果图片可被具有相同时间id的另一图片用于帧间预测参考，则该图片是子层参考图片；否则，它是一个子层非参考图片。图片是子层参考图片还是子层非参考图片都通过NAL单元类型值来表示。
Extensibility
扩展性
Besides the TemporalId in the NAL unit header, HEVC also includes the signaling of a six-bit layer ID in the NAL unit header, which must be equal to 0 for a single-layer bitstream. Extension mechanisms have been included in the VPS, SPS, Picture Parameter Set (PPS), SEI NAL unit, slice headers, and so on. All these extension mechanisms enable future extensions in a backward-compatible manner, such that bitstreams encoded according to potential future HEVC extensions can be fed to then-legacy decoders (e.g., HEVC version 1 decoders), and the then-legacy decoders can decode and output the base-layer bitstream.
除了NAL单元报头中的临时ID之外，HEVC还包括NAL单元报头中六位层ID的信令，对于单层比特流，该ID必须等于0。扩展机制包括在VPS、SP、图片参数集（PPS）、SEI NAL单元、切片头等中。所有这些扩展机制以向后兼容的方式实现未来扩展，使得根据潜在的未来HEVC扩展编码的比特流可以馈送到随后的遗留解码器（例如，HEVC版本1解码器），并且随后的遗留解码器可以解码并输出基本层比特流。
Bitstream extraction
比特流提取
HEVC includes a bitstream-extraction process as an integral part of the overall decoding process. The bitstream extraction process is used in the process of bitstream conformance tests, which is part of the HRD buffering model.
HEVC包括比特流提取过程，作为整个解码过程的一个组成部分。比特流提取过程用于比特流一致性测试过程，这是HRD缓冲模型的一部分。
Reference picture management
参考图片管理
The reference picture management of HEVC, including reference picture marking and removal from the Decoded Picture Buffer (DPB) as well as Reference Picture List Construction (RPLC), differs from that of H.264. Instead of the reference picture marking mechanism based on a sliding window plus adaptive Memory Management Control Operation (MMCO) described in H.264, HEVC specifies a reference picture management and marking mechanism based on Reference Picture Set (RPS), and the RPLC is consequently based on the RPS mechanism. An RPS consists of a set of reference pictures associated with a picture, consisting of all reference pictures that are prior to the associated picture in decoding order, that may be used for inter prediction of the associated picture or any picture following the associated picture in decoding order. The reference picture set consists of five lists of reference pictures; RefPicSetStCurrBefore, RefPicSetStCurrAfter, RefPicSetStFoll, RefPicSetLtCurr, and RefPicSetLtFoll. RefPicSetStCurrBefore, RefPicSetStCurrAfter, and
HEVC的参考图片管理，包括参考图片标记和从解码图片缓冲区（DPB）移除以及参考图片列表构建（RPLC），与H.264的不同。与H.264中描述的基于滑动窗口加自适应内存管理控制操作（MMCO）的参考图片标记机制不同，HEVC指定了基于参考图片集（RPS）的参考图片管理和标记机制，因此RPLC基于RPS机制。RPS由与图片相关联的一组参考图片组成，该组参考图片由解码顺序在相关图片之前的所有参考图片组成，可用于相关图片或解码顺序在相关图片之后的任何图片的帧间预测。参考图片集包括五个参考图片列表；RefPicSetStCurrBefore、RefPicSetStCurrAfter、RefPicSetStFoll、REFPICSETLTLTCURR和RefPicSetLtFoll。RefPicSetStCurrBefore、RefPicSetStCurrAfter和
RefPicSetLtCurr contain all reference pictures that may be used in inter prediction of the current picture and that may be used in inter prediction of one or more of the pictures following the current picture in decoding order. RefPicSetStFoll and RefPicSetLtFoll consist of all reference pictures that are not used in inter prediction of the current picture but may be used in inter prediction of one or more of the pictures following the current picture in decoding order. RPS provides an "intra-coded" signaling of the DPB status, instead of an "inter-coded" signaling, mainly for improved error resilience. The RPLC process in HEVC is based on the RPS, by signaling an index to an RPS subset for each reference index; this process is simpler than the RPLC process in H.264.
RefPicSetLtCurr包含可用于当前图片的帧间预测以及可用于以解码顺序在当前图片之后的一个或多个图片的帧间预测的所有参考图片。RefPicSetStFoll和RefPicSetLtFoll由所有参考图片组成，这些参考图片不用于当前图片的帧间预测，但可用于按照解码顺序对当前图片后面的一个或多个图片进行帧间预测。RPS提供DPB状态的“帧内编码”信令，而不是“帧间编码”信令，主要用于改进错误恢复能力。HEVC中的RPLC过程基于RPS，通过向每个参考索引的RPS子集发送索引信号；这个过程比H.264中的RPLC过程简单。
Ultra-low delay support
超低延迟支持
HEVC specifies a sub-picture-level HRD operation, for support of the so-called ultra-low delay. The mechanism specifies a standard-compliant way to enable delay reduction below a one-picture interval. Coded Picture Buffer (CPB) and DPB parameters at the sub-picture level may be signaled, and utilization of this information for the derivation of CPB timing (wherein the CPB removal time corresponds to decoding time) and DPB output timing (display time) is specified. Decoders are allowed to operate the HRD at the conventional access-unit level, even when the sub-picture-level HRD parameters are present.
HEVC指定一个子图片级HRD操作，以支持所谓的超低延迟。该机制指定了一种标准兼容方式，以使延迟减少到一个图片间隔以下。子图片级的编码图片缓冲器（CPB）和DPB参数可以被发信号，并且指定将该信息用于CPB定时（其中CPB移除时间对应于解码时间）和DPB输出定时（显示时间）的推导。允许解码器在常规接入单元级操作HRD，即使存在子画面级HRD参数。
New SEI messages
新SEI消息
HEVC inherits many H.264 SEI messages with changes in syntax and/or semantics making them applicable to HEVC. Additionally, there are a few new SEI messages reviewed briefly in the following paragraphs.
HEVC继承了许多H.264 SEI消息，并在语法和/或语义上进行了更改，使其适用于HEVC。此外，以下段落简要回顾了一些新的SEI信息。
The display orientation SEI message informs the decoder of a transformation that is recommended to be applied to the cropped decoded picture prior to display, such that the pictures can be properly displayed, e.g., in an upside-up manner.
显示方向SEI消息通知解码器建议在显示之前应用于裁剪的解码图片的变换，以便可以例如以倒置的方式正确显示图片。
The structure of pictures SEI message provides information on the NAL unit types, picture-order count values, and prediction dependencies of a sequence of pictures. The SEI message can be used, for example, for concluding what impact a lost picture has on other pictures.
图片SEI消息的结构提供有关NAL单元类型、图片顺序计数值和图片序列的预测相关性的信息。例如，SEI信息可用于总结丢失图片对其他图片的影响。
The decoded picture hash SEI message provides a checksum derived from the sample values of a decoded picture. It can be used for detecting whether a picture was correctly received and decoded.
解码图片散列SEI消息提供从解码图片的样本值导出的校验和。它可用于检测图片是否正确接收和解码。
The active parameter sets SEI message includes the IDs of the active video parameter set and the active sequence parameter set and can be used to activate VPSs and SPSs. In addition, the SEI message includes the following indications: 1) An indication of whether "full random accessibility" is supported (when supported, all parameter sets needed for decoding of the remaining of the bitstream when random accessing from the beginning of the current CVS by completely discarding all access units earlier in decoding order are present in the remaining bitstream, and all coded pictures in the remaining bitstream can be correctly decoded); 2) An indication of whether there is no parameter set within the current CVS that updates another parameter set of the same type preceding in decoding order. An update of a parameter set refers to the use of the same parameter set ID but with some other parameters changed. If this property is true for all CVSs in the bitstream, then all parameter sets can be sent out-of-band before session start.
活动参数集SEI消息包括活动视频参数集和活动序列参数集的ID，可用于激活VPS和SPSs。此外，SEI消息包括以下指示：1）指示是否支持“完全随机可访问性”（如果支持，当通过完全丢弃解码顺序中较早的所有访问单元从当前CVS的开始进行随机访问时，解码剩余比特流所需的所有参数集都存在于剩余比特流中，并且剩余比特流中的所有编码图片都可以正确解码）；2）指示当前CVS中是否没有参数集，用于按照解码顺序更新前面相同类型的另一个参数集。参数集的更新是指使用相同的参数集ID，但更改了一些其他参数。如果此属性对于位流中的所有CVS都为true，则可以在会话开始之前将所有参数集发送到带外。
The decoding unit information SEI message provides information regarding coded picture buffer removal delay for a decoding unit. The message can be used in very-low-delay buffering operations.
解码单元信息SEI消息提供关于解码单元的编码图片缓冲器移除延迟的信息。该消息可用于极低延迟缓冲操作。
The region refresh information SEI message can be used together with the recovery point SEI message (present in both H.264 and HEVC) for improved support of gradual decoding refresh. This supports random access from inter-coded pictures, wherein complete pictures can be correctly decoded or recovered after an indicated number of pictures in output/display order.
区域刷新信息SEI消息可以与恢复点SEI消息（在H.264和HEVC中都存在）一起使用，以改进对渐进解码刷新的支持。这支持来自帧间编码图片的随机访问，其中完整图片可以在按输出/显示顺序指定数量的图片之后正确解码或恢复。
The reportedly significantly higher encoding computational demand of HEVC over H.264, in conjunction with the ever-increasing video resolution (both spatially and temporally) required by the market, led to the adoption of VCL coding tools specifically targeted to allow for parallelization on the sub-picture level. That is, parallelization occurs, at the minimum, at the granularity of an integer number of CTUs. The targets for this type of high-level parallelization are multicore CPUs and DSPs as well as multiprocessor systems. In a system design, to be useful, these tools require signaling support, which is provided in Section 7 of this memo. This section provides a brief overview of the tools available in [HEVC].
据报道，HEVC对H.264的编码计算需求明显高于H.264，加上市场对视频分辨率（空间和时间）的不断提高，导致采用了VCL编码工具，专门针对子图片级别的并行化。也就是说，并行化至少以整数个CTU的粒度发生。这种高级并行化的目标是多核CPU和DSP以及多处理器系统。在系统设计中，这些工具需要信号支持，这在本备忘录第7节中提供。本节简要概述了[HEVC]中提供的工具。
Many of the tools incorporated in HEVC were designed keeping in mind the potential parallel implementations in multicore/multiprocessor architectures. Specifically, for parallelization, four picture partition strategies, as described below, are available.
HEVC中包含的许多工具的设计都考虑了多核/多处理器体系结构中潜在的并行实现。具体来说，对于并行化，可以使用如下所述的四种图片分区策略。
Slices are segments of the bitstream that can be reconstructed independently from other slices within the same picture (though there may still be interdependencies through loop filtering operations). Slices are the only tool that can be used for parallelization that is also available, in virtually identical form, in H.264. Parallelization based on slices does not require much inter-processor or inter-core communication (except for inter-processor or inter-core data sharing for motion compensation when decoding a predictively coded picture, which is typically much heavier than inter-processor or inter-core data sharing due to in-picture prediction), as slices are designed to be independently decodable. However, for the same reason, slices can require some coding overhead. Further, slices (in contrast to some of the other tools mentioned below) also serve as the key mechanism for bitstream partitioning to match Maximum Transfer Unit (MTU) size requirements, due to the in-picture independence of slices and the fact that each regular slice is encapsulated in its own NAL unit. In many cases, the goal of parallelization and the goal of MTU size matching can place contradicting demands to the slice layout in a picture. The realization of this situation led to the development of the more advanced tools mentioned below.
切片是可以独立于同一图片中的其他切片重建的比特流片段（尽管通过循环过滤操作可能仍然存在相互依赖性）。切片是唯一可以用于并行化的工具，它在H.264中以几乎相同的形式提供。基于切片的并行化不需要太多处理器间或核心间通信（除了解码预测编码图片时用于运动补偿的处理器间或核心间数据共享，由于图片内预测，其通常比处理器间或核心间数据共享重得多），as切片设计为可独立解码。然而，出于同样的原因，切片可能需要一些编码开销。此外，片（与下面提到的一些其他工具相比）还作为比特流分区的关键机制，以匹配最大传输单元（MTU）大小要求，这是因为片的图片内独立性以及每个常规片封装在其自己的NAL单元中的事实。在许多情况下，并行化的目标和MTU大小匹配的目标可能会对图片中的切片布局提出矛盾的要求。这种情况的实现导致了下面提到的更先进工具的开发。
Dependent slice segments allow for fragmentation of a coded slice into fragments at CTU boundaries without breaking any in-picture prediction mechanisms. They are complementary to the fragmentation mechanism described in this memo in that they need the cooperation of the encoder. As a dependent slice segment necessarily contains an integer number of CTUs, a decoder using multiple cores operating on CTUs can process a dependent slice segment without communicating parts of the slice segment's bitstream to other cores. Fragmentation, as specified in this memo, in contrast, does not guarantee that a fragment contains an integer number of CTUs.
依赖片段允许在CTU边界处将编码片分割成片段，而不破坏任何图片内预测机制。它们是对本备忘录中描述的分段机制的补充，因为它们需要编码器的配合。由于从属片段必然包含整数个CTU，因此使用在CTU上操作的多个核的解码器可以处理从属片段，而无需将片段比特流的一部分传送给其他核。相反，本备忘录中规定的碎片并不保证碎片包含整数个CTU。
In Wavefront Parallel Processing (WPP), the picture is partitioned into rows of CTUs. Entropy decoding and prediction are allowed to use data from CTUs in other partitions. Parallel processing is possible through parallel decoding of CTU rows, where the start of the decoding of a row is delayed by two CTUs, so to ensure that data related to a CTU above and to the right of the subject CTU is available before the subject CTU is being decoded. Using this staggered start (which appears like a wavefront when represented graphically), parallelization is possible with up to as many processors/cores as the picture contains CTU rows.
在波前并行处理（WPP）中，图像被分割成若干行CTU。熵解码和预测允许在其他分区中使用来自CTU的数据。并行处理可以通过并行解码CTU行来实现，其中一行解码的开始被两个CTU延迟，以确保在解码对象CTU之前，与对象CTU上方和右侧的CTU相关的数据可用。使用这种交错启动（当以图形表示时，它看起来像一个波前），可以使用最多与图片中包含CTU行的处理器/内核进行并行化。
Because in-picture prediction between neighboring CTU rows within a picture is allowed, the required inter-processor/inter-core communication to enable in-picture prediction can be substantial. The WPP partitioning does not result in the creation of more NAL
由于允许在图片内相邻CTU行之间进行图片内预测，因此实现图片内预测所需的处理器间/核心间通信可能是大量的。WPP分区不会导致创建更多NAL
units compared to when it is not applied; thus, WPP cannot be used for MTU size matching, though slices can be used in combination for that purpose.
与未应用时相比的单位；因此，WPP不能用于MTU大小匹配，尽管切片可以组合使用。
Tiles define horizontal and vertical boundaries that partition a picture into tile columns and rows. The scan order of CTUs is changed to be local within a tile (in the order of a CTU raster scan of a tile), before decoding the top-left CTU of the next tile in the order of tile raster scan of a picture. Similar to slices, tiles break in-picture prediction dependencies (including entropy decoding dependencies). However, they do not need to be included into individual NAL units (same as WPP in this regard); hence, tiles cannot be used for MTU size matching, though slices can be used in combination for that purpose. Each tile can be processed by one processor/core, and the inter-processor/inter-core communication required for in-picture prediction between processing units decoding neighboring tiles is limited to conveying the shared slice header in cases a slice is spanning more than one tile, and loop-filtering-related sharing of reconstructed samples and metadata. Insofar, tiles are less demanding in terms of inter-processor communication bandwidth compared to WPP due to the in-picture independence between two neighboring partitions.
平铺定义将图片划分为平铺列和行的水平和垂直边界。在按照图片的平铺光栅扫描顺序解码下一个平铺的左上角CTU之前，CTU的扫描顺序更改为平铺内的本地（按照平铺的CTU光栅扫描顺序）。与切片类似，分片在图片预测依赖项（包括熵解码依赖项）中中断。但是，它们不需要包含在单独的NAL单元中（这方面与WPP相同）；因此，瓷砖不能用于MTU尺寸匹配，尽管切片可以组合使用。每个片可由一个处理器/核心处理，并且解码相邻片的处理单元之间的画面内预测所需的处理器间/核心间通信限于在片跨越多个片的情况下传送共享片头部，与循环过滤相关的重构样本和元数据共享。到目前为止，由于两个相邻分区之间的图像内独立性，与WPP相比，TILE对处理器间通信带宽的要求较低。
HEVC maintains the NAL unit concept of H.264 with modifications. HEVC uses a two-byte NAL unit header, as shown in Figure 1. The payload of a NAL unit refers to the NAL unit excluding the NAL unit header.
HEVC对H.264的NAL单元概念进行了修改。HEVC使用一个两字节的NAL单元头，如图1所示。NAL单元的有效负载指除NAL单元头之外的NAL单元。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Type | LayerId | TID |
+-------------+-----------------+
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Type | LayerId | TID |
+-------------+-----------------+
Figure 1: The Structure of the HEVC NAL Unit Header
图1:HEVC NAL单元头的结构
The semantics of the fields in the NAL unit header are as specified in [HEVC] and described briefly below for convenience. In addition to the name and size of each field, the corresponding syntax element name in [HEVC] is also provided.
NAL单元头中字段的语义如[HEVC]中所述，为方便起见，下文将对其进行简要说明。除了每个字段的名称和大小外，[HEVC]中还提供了相应的语法元素名称。
F: 1 bit forbidden_zero_bit. Required to be zero in [HEVC]. Note that the inclusion of this bit in the NAL unit header was to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S]. In the context of this memo,
F:1位禁止\u零位\u位。要求在[HEVC]中为零。注意，在NAL单元报头中包含该位是为了通过MPEG-2传输系统传输HEVC视频（避免开始代码模拟）[MPEG2S]。在这份备忘录中，
the value 1 may be used to indicate a syntax violation, e.g., for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3.
如第4.4.3节所述，值1可用于表示语法冲突，例如，对于因聚合NAL单元的多个分段单元而导致的NAL单元，但缺少最后一个分段。
Type: 6 bits nal_unit_type. This field specifies the NAL unit type as defined in Table 7-1 of [HEVC]. If the most significant bit of this field of a NAL unit is equal to 0 (i.e., the value of this field is less than 32), the NAL unit is a VCL NAL unit. Otherwise, the NAL unit is a non-VCL NAL unit. For a reference of all currently defined NAL unit types and their semantics, please refer to Section 7.4.2 in [HEVC].
类型：6位nal\U单元\U类型。该字段指定[HEVC]表7-1中定义的NAL装置类型。如果NAL单元的该字段的最高有效位等于0（即，该字段的值小于32），则NAL单元为VCL NAL单元。否则，NAL单元是非VCL NAL单元。有关所有当前定义的NAL装置类型及其语义的参考，请参考[HEVC]中的第7.4.2节。
LayerId: 6 bits nuh_layer_id. Required to be equal to zero in [HEVC]. It is anticipated that in future scalable or 3D video coding extensions of this specification, this syntax element will be used to identify additional layers that may be present in the CVS, wherein a layer may be, e.g., a spatial scalable layer, a quality scalable layer, a texture view, or a depth view.
LayerId:6位nuh_layer_id。要求在[HEVC]中等于零。预计在本规范的未来可伸缩或三维视频编码扩展中，该语法元素将用于识别CVS中可能存在的附加层，其中层可以是例如空间可伸缩层、质量可伸缩层、纹理视图或深度视图。
TID: 3 bits nuh_temporal_id_plus1. This field specifies the temporal identifier of the NAL unit plus 1. The value of TemporalId is equal to TID minus 1. A TID value of 0 is illegal to ensure that there is at least one bit in the NAL unit header equal to 1, so to enable independent considerations of start code emulations in the NAL unit header and in the NAL unit payload data.
TID:3位数字时间id加1。此字段指定NAL单元的时间标识符加1。TemporalId的值等于TID减去1。TID值为0是非法的，以确保NAL单元标头中至少有一位等于1，从而使NAL单元标头和NAL单元有效负载数据中的启动代码仿真能够独立考虑。
This payload format defines the following processes required for transport of HEVC coded data over RTP [RFC3550]:
此有效负载格式定义了通过RTP[RFC3550]传输HEVC编码数据所需的以下过程：
o Usage of RTP header with this payload format
o 使用此有效负载格式的RTP标头
o Packetization of HEVC coded NAL units into RTP packets using three types of payload structures: a single NAL unit packet, aggregation packet, and fragment unit
o 使用三种有效负载结构将HEVC编码的NAL单元打包成RTP数据包：单个NAL单元数据包、聚合数据包和片段单元
o Transmission of HEVC NAL units of the same bitstream within a single RTP stream or multiple RTP streams (within one or more RTP sessions), where within an RTP stream transmission of NAL units may be either non-interleaved (i.e., the transmission order of NAL units is the same as their decoding order) or interleaved (i.e., the transmission order of NAL units is different from the decoding order)
o 在单个RTP流或多个RTP流（在一个或多个RTP会话内）内传输相同比特流的HEVC NAL单元，其中在RTP流内，NAL单元的传输可以是非交织（即，NAL单元的传输顺序与其解码顺序相同）或交织（即，NAL单元的发送顺序不同于解码顺序）
o Media type parameters to be used with the Session Description Protocol (SDP) [RFC4566]
o 与会话描述协议（SDP）一起使用的媒体类型参数[RFC4566]
o A payload header extension mechanism and data structures for enhanced support of temporal scalability based on that extension mechanism.
o 一种有效负载报头扩展机制和数据结构，用于基于该扩展机制增强对时间可伸缩性的支持。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
In this document, the above key words will convey that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance described in RFC 2119.
在本文件中，只有在所有大写字母中，上述关键词才会传达这种解释。这些词语的小写用法不得解释为具有RFC 2119中所述的意义。
This specification uses the notion of setting and clearing a bit when bit fields are handled. Setting a bit is the same as assigning that bit the value of 1 (On). Clearing a bit is the same as assigning that bit the value of 0 (Off).
本规范使用在处理位字段时设置和清除位的概念。设置位与将该位的值指定为1（On）相同。清除一个位与将该位赋值为0（关闭）相同。
This document uses the terms and definitions of [HEVC]. Section 3.1.1 lists relevant definitions from [HEVC] for convenience. Section 3.1.2 provides definitions specific to this memo.
本文件使用[HEVC]的术语和定义。为了方便起见，第3.1.1节列出了[HEVC]中的相关定义。第3.1.2节提供了本备忘录的特定定义。
access unit: A set of NAL units that are associated with each other according to a specified classification rule, that are consecutive in decoding order, and that contain exactly one coded picture.
存取单元：根据规定的分类规则相互关联的一组NAL单元，它们在解码顺序上是连续的，并且只包含一个编码图片。
BLA access unit: An access unit in which the coded picture is a BLA picture.
BLA存取单元：其中编码图片为BLA图片的存取单元。
BLA picture: An IRAP picture for which each VCL NAL unit has nal_unit_type equal to BLA_W_LP, BLA_W_RADL, or BLA_N_LP.
BLA图片：每个VCL NAL单元的NAL_单元类型等于BLA_W_LP、BLA_W_RADL或BLA_N_LP的IRAP图片。
Coded Video Sequence (CVS): A sequence of access units that consists, in decoding order, of an IRAP access unit with NoRaslOutputFlag equal to 1, followed by zero or more access units that are not IRAP access units with NoRaslOutputFlag equal to 1, including all subsequent access units up to but not including any subsequent access unit that is an IRAP access unit with NoRaslOutputFlag equal to 1.
编码视频序列（CVS）：访问单元序列，按解码顺序由NoRaslOutputFlag等于1的IRAP访问单元，然后是NoRaslOutputFlag等于1的非IRAP访问单元的零个或多个访问单元组成，包括所有后续访问单元，但不包括NoRaslOutputFlag等于1的IRAP访问单元的任何后续访问单元。
Informative note: An IRAP access unit may be an IDR access unit, a BLA access unit, or a CRA access unit. The value of NoRaslOutputFlag is equal to 1 for each IDR access unit, each BLA access unit, and each CRA access unit that is the first access unit in the bitstream in decoding order, is the first access unit that follows an end of sequence NAL unit in decoding order, or has HandleCraAsBlaFlag equal to 1.
资料性说明：IRAP访问单元可以是IDR访问单元、BLA访问单元或CRA访问单元。对于每个IDR访问单元、每个BLA访问单元和每个CRA访问单元，NoRaslOutputFlag的值等于1，每个IDR访问单元、每个BLA访问单元是位流中以解码顺序排列的第一个访问单元，是以解码顺序排列在序列结束NAL单元之后的第一个访问单元，或者HandleCraAsBlaFlag等于1。
CRA access unit: An access unit in which the coded picture is a CRA picture.
CRA存取单元：其中编码图片为CRA图片的存取单元。
CRA picture: A RAP picture for which each VCL NAL unit has nal_unit_type equal to CRA_NUT.
CRA图片：每个VCL NAL单元的NAL_单元类型等于CRA_螺母的RAP图片。
IDR access unit: An access unit in which the coded picture is an IDR picture.
IDR访问单元：其中编码图片为IDR图片的访问单元。
IDR picture: A RAP picture for which each VCL NAL unit has nal_unit_type equal to IDR_W_RADL or IDR_N_LP.
IDR图片：每个VCL NAL单元的NAL_单元类型等于IDR_W_RADL或IDR_N_LP的RAP图片。
IRAP access unit: An access unit in which the coded picture is an IRAP picture.
IRAP访问单元：其中编码图片为IRAP图片的访问单元。
IRAP picture: A coded picture for which each VCL NAL unit has nal_unit_type in the range of BLA_W_LP (16) to RSV_IRAP_VCL23 (23), inclusive.
IRAP图片：每个VCL NAL单元的NAL_单元_类型在BLA_W_LP（16）到RSV_IRAP_VCL23（23）范围内的编码图片。
layer: A set of VCL NAL units that all have a particular value of nuh_layer_id and the associated non-VCL NAL units, or one of a set of syntactical structures having a hierarchical relationship.
层：一组VCL NAL单元，它们都具有nuh_layer_id的特定值和相关的非VCL NAL单元，或具有层次关系的一组语法结构之一。
operation point: bitstream created from another bitstream by operation of the sub-bitstream extraction process with the another bitstream, a target highest TemporalId, and a target-layer identifier list as input.
操作点：通过子比特流提取过程的操作从另一个比特流创建的比特流，另一个比特流、目标最高时间ID和目标层标识符列表作为输入。
random access: The act of starting the decoding process for a bitstream at a point other than the beginning of the bitstream.
随机存取：在比特流起始点以外的点开始比特流解码过程的行为。
sub-layer: A temporal scalable layer of a temporal scalable bitstream consisting of VCL NAL units with a particular value of the TemporalId variable, and the associated non-VCL NAL units.
子层：时间可伸缩比特流的时间可伸缩层，由具有特定时间变量值的VCL NAL单元和相关的非VCL NAL单元组成。
sub-layer representation: A subset of the bitstream consisting of NAL units of a particular sub-layer and the lower sub-layers.
子层表示：由特定子层和较低子层的NAL单元组成的比特流子集。
tile: A rectangular region of coding tree blocks within a particular tile column and a particular tile row in a picture.
平铺：图片中特定平铺列和特定平铺行内编码树块的矩形区域。
tile column: A rectangular region of coding tree blocks having a height equal to the height of the picture and a width specified by syntax elements in the picture parameter set.
平铺列：编码树块的矩形区域，其高度等于图片的高度，宽度由图片参数集中的语法元素指定。
tile row: A rectangular region of coding tree blocks having a height specified by syntax elements in the picture parameter set and a width equal to the width of the picture.
平铺行：编码树块的矩形区域，其高度由图片参数集中的语法元素指定，宽度等于图片的宽度。
dependee RTP stream: An RTP stream on which another RTP stream depends. All RTP streams in a Multiple RTP streams on a Single media Transport (MRST) or Multiple RTP streams on Multiple media Transports (MRMT), except for the highest RTP stream, are dependee RTP streams.
dependee RTP流：另一个RTP流所依赖的RTP流。单个媒体传输（MRST）上的多个RTP流或多个媒体传输（MRMT）上的多个RTP流中的所有RTP流（最高RTP流除外）都是依赖RTP流。
highest RTP stream: The RTP stream on which no other RTP stream depends. The RTP stream in a Single RTP stream on a Single media Transport (SRST) is the highest RTP stream.
最高RTP流：没有其他RTP流依赖的RTP流。单个媒体传输（SRST）上的单个RTP流中的RTP流是最高的RTP流。
Media-Aware Network Element (MANE): A network element, such as a middlebox, selective forwarding unit, or application-layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to their contents.
媒体感知网元（MANE）：能够解析RTP有效负载报头或RTP有效负载的某些方面并对其内容作出反应的网元，如中间盒、选择性转发单元或应用层网关。
Informative note: The concept of a MANE goes beyond normal routers or gateways in that a MANE has to be aware of the signaling (e.g., to learn about the payload type mappings of the media streams), and in that it has to be trusted when working with Secure RTP (SRTP). The advantage of using MANEs is that they allow packets to be dropped according to the needs of the media coding. For example, if a MANE has to drop packets due to congestion on a certain link, it can identify and remove those packets whose elimination produces the least adverse effect on the user experience. After dropping packets, MANEs must rewrite RTCP packets to match the changes to the RTP stream, as specified in Section 7 of [RFC3550].
资料性说明：MANE的概念超出了普通路由器或网关，因为MANE必须了解信令（例如，了解媒体流的有效负载类型映射），并且在使用安全RTP（SRTP）时必须信任它。使用mane的优点是，它们允许根据媒体编码的需要丢弃数据包。例如，如果MANE由于某一链路上的拥塞而不得不丢弃分组，则它可以识别并移除那些其消除对用户体验产生最小不利影响的分组。丢弃数据包后，MANE必须重写RTCP数据包以匹配RTP流的更改，如[RFC3550]第7节所述。
Media Transport: As used in the MRST, MRMT, and SRST definitions below, Media Transport denotes the transport of packets over a transport association identified by a 5-tuple (source address, source port, destination address, destination port, transport protocol). See also Section 2.1.13 of [RFC7656].
媒体传输：正如在下面的MRST、MRMT和SRST定义中所使用的，媒体传输表示通过5元组（源地址、源端口、目标地址、目标端口、传输协议）标识的传输关联传输数据包。另见[RFC7656]第2.1.13节。
Informative note: The term "bitstream" in this document is equivalent to the term "encoded stream" in [RFC7656].
资料性说明：本文件中的术语“比特流”等同于[RFC7656]中的术语“编码流”。
Multiple RTP streams on a Single media Transport (MRST): Multiple RTP streams carrying a single HEVC bitstream on a Single Transport. See also Section 3.5 of [RFC7656].
单个媒体传输（MRST）上的多个RTP流：在单个传输上承载单个HEVC比特流的多个RTP流。另见[RFC7656]第3.5节。
Multiple RTP streams on Multiple media Transports (MRMT): Multiple RTP streams carrying a single HEVC bitstream on Multiple Transports. See also Section 3.5 of [RFC7656].
多媒体传输上的多个RTP流（MRMT）：多个传输上承载单个HEVC比特流的多个RTP流。另见[RFC7656]第3.5节。
NAL unit decoding order: A NAL unit order that conforms to the constraints on NAL unit order given in Section 7.4.2.4 in [HEVC].
NAL单元解码顺序：符合[HEVC]第7.4.2.4节中给出的NAL单元顺序约束的NAL单元顺序。
NAL unit output order: A NAL unit order in which NAL units of different access units are in the output order of the decoded pictures corresponding to the access units, as specified in [HEVC], and in which NAL units within an access unit are in their decoding order.
NAL单元输出顺序：一种NAL单元顺序，其中不同访问单元的NAL单元按照[HEVC]中规定的与访问单元对应的解码图片的输出顺序，并且访问单元内的NAL单元按照其解码顺序。
NAL-unit-like structure: A data structure that is similar to NAL units in the sense that it also has a NAL unit header and a payload, with a difference that the payload does not follow the start code emulation prevention mechanism required for the NAL unit syntax as specified in Section 7.3.1.1 of [HEVC]. Examples of NAL-unit-like structures defined in this memo are packet payloads of Aggregation Packet (AP), PAyload Content Information (PACI), and Fragmentation Unit (FU) packets.
NAL单元类结构：一种与NAL单元相似的数据结构，即它也有一个NAL单元头和一个有效载荷，不同之处在于有效载荷不遵循[HEVC]第7.3.1.1节中规定的NAL单元语法所需的启动码仿真预防机制。本备忘录中定义的类NAL单元结构的示例为聚合数据包（AP）、有效负载内容信息（PACI）和碎片单元（FU）数据包的数据包有效负载。
NALU-time: The value that the RTP timestamp would have if the NAL unit would be transported in its own RTP packet.
NALU时间：如果NAL单元将在其自己的RTP数据包中传输，则RTP时间戳将具有的值。
RTP stream: See [RFC7656]. Within the scope of this memo, one RTP stream is utilized to transport one or more temporal sub-layers.
RTP流：请参阅[RFC7656]。在本备忘录的范围内，一个RTP流用于传输一个或多个时间子层。
Single RTP stream on a Single media Transport (SRST): Single RTP stream carrying a single HEVC bitstream on a Single (Media) Transport. See also Section 3.5 of [RFC7656].
单个媒体传输（SRST）上的单个RTP流：单个RTP流在单个（媒体）传输上承载单个HEVC比特流。另见[RFC7656]第3.5节。
transmission order: The order of packets in ascending RTP sequence number order (in modulo arithmetic). Within an aggregation packet, the NAL unit transmission order is the same as the order of appearance of NAL units in the packet.
传输顺序：以RTP序列号升序排列的数据包顺序（在模运算中）。在聚合分组内，NAL单元传输顺序与分组中NAL单元的出现顺序相同。
AP Aggregation Packet
AP聚合包
BLA Broken Link Access
断开链接访问
CRA Clean Random Access
清洁随机存取
CTB Coding Tree Block
编码树块
CTU Coding Tree Unit
编码树单元
CVS Coded Video Sequence
CVS编码视频序列
DPH Decoded Picture Hash
DPH解码图片散列
FU Fragmentation Unit
FU破碎装置
HRD Hypothetical Reference Decoder
假设参考解码器
IDR Instantaneous Decoding Refresh
瞬时解码刷新
IRAP Intra Random Access Point
内部随机接入点
MANE Media-Aware Network Element
MANE媒体感知网元
MRMT Multiple RTP streams on Multiple media Transports
MRMT多个媒体传输上的多个RTP流
MRST Multiple RTP streams on a Single media Transport
在单个媒体传输上MRST多个RTP流
MTU Maximum Transfer Unit
最大传输单元
NAL Network Abstraction Layer
NAL网络抽象层
NALU Network Abstraction Layer Unit
NALU网络抽象层单元
PACI PAyload Content Information
PACI有效载荷内容信息
PHES Payload Header Extension Structure
PHES有效载荷头扩展结构
PPS Picture Parameter Set
PPS图片参数集
RADL Random Access Decodable Leading (Picture)
随机存取可解码引导（图片）
RASL Random Access Skipped Leading (Picture)
RASL随机访问跳过前导（图片）
RPS Reference Picture Set
参考图片集
SEI Supplemental Enhancement Information
SEI补充增强信息
SPS Sequence Parameter Set
SPS序列参数集
SRST Single RTP stream on a Single media Transport
SRST单个媒体传输上的单个RTP流
STSA Step-wise Temporal Sub-layer Access
STSA分步时态子层接入
TSA Temporal Sub-layer Access
时态子层接入
TSCI Temporal Scalability Control Information
时间可伸缩性控制信息
VCL Video Coding Layer
视频编码层
VPS Video Parameter Set
视频参数集
The format of the RTP header is specified in [RFC3550] (reprinted as Figure 2 for convenience). This payload format uses the fields of the header in a manner consistent with that specification.
RTP报头的格式在[RFC3550]中指定（为了方便起见，重新打印为图2）。此有效负载格式以与该规范一致的方式使用报头的字段。
The RTP payload (and the settings for some RTP header bits) for aggregation packets and fragmentation units are specified in Sections 4.4.2 and 4.4.3, respectively.
第4.4.2节和第4.4.3节分别规定了聚合数据包和分段单元的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RTP Header According to [RFC3550]
图2:RTP标头符合[RFC3550]
The RTP header information to be set according to this RTP payload format is set as follows:
要根据此RTP有效负载格式设置的RTP报头信息设置如下：
Marker bit (M): 1 bit
标记位（M）：1位
Set for the last packet of the access unit, carried in the current RTP stream. This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling. When MRST or MRMT is in use, if an access unit appears in multiple RTP streams, the marker bit is set on each RTP stream's last packet of the access unit.
为当前RTP流中携带的接入单元的最后一个数据包设置。这符合视频格式中M位的正常使用，以允许有效的播放缓冲区处理。当使用MRST或MRMT时，如果一个接入单元出现在多个RTP流中，则在接入单元的每个RTP流的最后一个分组上设置标记位。
Informative note: The content of a NAL unit does not tell whether or not the NAL unit is the last NAL unit, in decoding order, of an access unit. An RTP sender implementation may obtain this information from the video encoder. If, however, the implementation cannot obtain this information directly from the encoder, e.g., when the bitstream was pre-encoded, and also there is no timestamp allocated for each NAL unit, then the sender implementation can inspect subsequent NAL units in decoding order to determine whether or not the NAL unit is the last NAL unit of an access unit as follows. A NAL unit is determined to be the last NAL unit of an access unit if it is the last NAL unit of the bitstream. A NAL unit naluX is also determined to be the last NAL unit of an access unit if both the following conditions are true: 1) the next VCL NAL unit naluY in decoding order has the high-order bit of the first byte after its NAL unit header equal to 1, and 2) all NAL units between naluX and naluY, when present, have nal_unit_type in the range of 32 to 35, inclusive, equal to 39, or in the ranges of 41 to 44, inclusive, or 48 to 55, inclusive.
信息性说明：NAL单元的内容不能说明NAL单元是否是接入单元的最后一个NAL单元（按解码顺序）。RTP发送器实现可从视频编码器获得该信息。然而，如果实现不能直接从编码器获得该信息，例如，当比特流被预编码时，并且没有为每个NAL单元分配时间戳，然后，发送方实现可以在解码中检查后续的NAL单元，以便如下确定NAL单元是否是接入单元的最后一个NAL单元。如果NAL单元是比特流的最后一个NAL单元，则将其确定为接入单元的最后一个NAL单元。如果以下两个条件均为真，则NAL单元naluX也被确定为接入单元的最后一个NAL单元：1）解码顺序中的下一个VCL NAL单元naluY在其NAL单元头之后的第一个字节的高阶位等于1，以及2）naluX和naluY之间的所有NAL单元（当存在时），nal_单位_类型在32到35之间（含32到35），等于39，或在41到44之间（含41到44），或48到55之间（含48到55）。
Payload Type (PT): 7 bits
有效负载类型（PT）：7位
The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. The assignment of a payload type has to be performed either through the profile used or in a dynamic way.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。有效负载类型的分配必须通过使用的配置文件或以动态方式执行。
Informative note: It is not required to use different payload type values for different RTP streams in MRST or MRMT.
资料性说明：对于MRST或MRMT中的不同RTP流，不需要使用不同的有效负载类型值。
Sequence Number (SN): 16 bits
序列号（SN）：16位
Set and used in accordance with [RFC3550].
按照[RFC3550]进行设置和使用。
Timestamp: 32 bits
时间戳：32位
The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used.
RTP时间戳设置为内容的采样时间戳。必须使用90 kHz的时钟频率。
If the NAL unit has no timing properties of its own (e.g., parameter set and SEI NAL units), the RTP timestamp MUST be set to the RTP timestamp of the coded picture of the access unit in which the NAL unit (according to Section 7.4.2.4.4 of [HEVC]) is included.
如果NAL单元本身没有定时属性（例如，参数集和SEI-NAL单元），则必须将RTP时间戳设置为包含NAL单元的接入单元的编码图片的RTP时间戳（根据[HEVC]第7.4.2.4.4节）。
Receivers MUST use the RTP timestamp for the display process, even when the bitstream contains picture timing SEI messages or decoding unit information SEI messages as specified in [HEVC]. However, this does not mean that picture timing SEI messages in the bitstream should be discarded, as picture timing SEI messages may contain frame-field information that is important in appropriately rendering interlaced video.
接收机必须为显示过程使用RTP时间戳，即使比特流包含[HEVC]中规定的图片定时SEI消息或解码单元信息SEI消息。然而，这并不意味着应当丢弃比特流中的图片定时SEI消息，因为图片定时SEI消息可以包含在适当地渲染隔行视频中重要的帧场信息。
Synchronization source (SSRC): 32 bits
同步源（SSRC）：32位
Used to identify the source of the RTP packets. When using SRST, by definition a single SSRC is used for all parts of a single bitstream. In MRST or MRMT, different SSRCs are used for each RTP stream containing a subset of the sub-layers of the single (temporally scalable) bitstream. A receiver is required to correctly associate the set of SSRCs that are included parts of the same bitstream.
用于标识RTP数据包的源。使用SRST时，根据定义，单个SSRC用于单个比特流的所有部分。在MRST或MRMT中，不同的ssrc用于包含单个（时间可伸缩）比特流的子层子集的每个RTP流。接收机需要正确关联包含在同一比特流中的SSRC集。
The first two bytes of the payload of an RTP packet are referred to as the payload header. The payload header consists of the same fields (F, Type, LayerId, and TID) as the NAL unit header as shown in Section 1.1.4, irrespective of the type of the payload structure.
RTP数据包的有效负载的前两个字节称为有效负载报头。如第1.1.4节所示，无论有效负载结构的类型如何，有效负载报头包含与NAL单元报头相同的字段（F、类型、分层和TID）。
The TID value indicates (among other things) the relative importance of an RTP packet, for example, because NAL units belonging to higher temporal sub-layers are not used for the decoding of lower temporal sub-layers. A lower value of TID indicates a higher importance. More-important NAL units MAY be better protected against transmission losses than less-important NAL units.
TID值指示（除其他外）RTP分组的相对重要性，例如，因为属于较高时间子层的NAL单元不用于较低时间子层的解码。TID值越低表示重要性越高。与不太重要的NAL单元相比，更重要的NAL单元可以更好地防止传输损耗。
This memo enables transmission of an HEVC bitstream over:
此备忘录允许通过以下方式传输HEVC比特流：
o a Single RTP stream on a Single media Transport (SRST),
o 单个媒体传输（SRST）上的单个RTP流，
o Multiple RTP streams over a Single media Transport (MRST), or
o 通过单个媒体传输（MRST）的多个RTP流，或
o Multiple RTP streams on Multiple media Transports (MRMT).
o 多媒体传输（MRMT）上的多个RTP流。
Informative note: While this specification enables the use of MRST within the H.265 RTP payload, the signaling of MRST within SDP offer/answer is not fully specified at the time of this writing. See [RFC5576] and [RFC5583] for what is supported today as well as [RTP-MULTI-STREAM] and [SDP-NEG] for future directions.
资料性说明：虽然本规范允许在H.265 RTP有效载荷内使用MRST，但在撰写本文时，SDP提供/应答内的MRST信令并未完全规定。参见[RFC5576]和[RFC5583]了解当前支持的内容，以及[RTP-MULTI-STREAM]和[SDP-NEG]了解未来的方向。
When in MRMT, the dependency of one RTP stream on another RTP stream is typically indicated as specified in [RFC5583]. [RFC5583] can also be utilized to specify dependencies within MRST, but only if the RTP streams utilize distinct payload types.
在MRMT中，一个RTP流对另一个RTP流的依赖性通常如[RFC5583]中所述。[RFC5583]也可用于指定MRST内的依赖关系，但仅当RTP流使用不同的有效负载类型时。
SRST or MRST SHOULD be used for point-to-point unicast scenarios, whereas MRMT SHOULD be used for point-to-multipoint multicast scenarios where different receivers require different operation points of the same HEVC bitstream, to improve bandwidth utilizing efficiency.
SRST或MRST应用于点对点单播场景，而MRMT应用于点对多点多播场景，其中不同的接收器需要相同HEVC比特流的不同操作点，以提高带宽利用效率。
Informative note: A multicast may degrade to a unicast after all but one receivers have left (this is a justification of the first "SHOULD" instead of "MUST"), and there might be scenarios where MRMT is desirable but not possible, e.g., when IP multicast is not deployed in certain network (this is a justification of the second "SHOULD" instead of "MUST").
资料性说明：在除一个接收器外的所有接收器都离开后，多播可能降级为单播（这是第一个“应该”而不是“必须”的理由），并且可能存在需要MRMT但不可能的情况，例如，当IP多播未部署在特定网络中时（这是第二个“应该”而不是“必须”的理由）“必须”）。
The transmission mode is indicated by the tx-mode media parameter (see Section 7.1). If tx-mode is equal to "SRST", SRST MUST be used. Otherwise, if tx-mode is equal to "MRST", MRST MUST be used. Otherwise (tx-mode is equal to "MRMT"), MRMT MUST be used.
传输模式由tx mode介质参数指示（见第7.1节）。如果tx模式等于“SRST”，则必须使用SRST。否则，如果tx模式等于“MRST”，则必须使用MRST。否则（tx模式等于“MRMT”），必须使用MRMT。
Informative note: When an RTP stream does not depend on other RTP streams, any of SRST, MRST, or MRMT may be in use for the RTP stream.
资料性说明：当RTP流不依赖于其他RTP流时，SRST、MRST或MRMT中的任何一个都可以用于RTP流。
Receivers MUST support all of SRST, MRST, and MRMT.
接收器必须支持所有SRST、MRST和MRMT。
Informative note: The required support of MRMT by receivers does not imply that multicast must be supported by receivers.
资料性说明：接收方对MRMT的必要支持并不意味着接收方必须支持多播。
Four different types of RTP packet payload structures are specified. A receiver can identify the type of an RTP packet payload through the Type field in the payload header.
指定了四种不同类型的RTP数据包有效负载结构。接收机可以通过有效载荷报头中的type字段识别RTP分组有效载荷的类型。
The four different payload structures are as follows:
四种不同的有效载荷结构如下所示：
o Single NAL unit packet: Contains a single NAL unit in the payload, and the NAL unit header of the NAL unit also serves as the payload header. This payload structure is specified in Section 4.4.1.
o 单个NAL单元数据包：有效负载中包含单个NAL单元，并且NAL单元的NAL单元报头也用作有效负载报头。第4.4.1节规定了该有效载荷结构。
o Aggregation Packet (AP): Contains more than one NAL unit within one access unit. This payload structure is specified in Section 4.4.2.
o 聚合数据包（AP）：在一个访问单元中包含多个NAL单元。第4.4.2节规定了该有效载荷结构。
o Fragmentation Unit (FU): Contains a subset of a single NAL unit. This payload structure is specified in Section 4.4.3.
o 碎片单元（FU）：包含单个NAL单元的子集。第4.4.3节规定了该有效载荷结构。
o PACI carrying RTP packet: Contains a payload header (that differs from other payload headers for efficiency), a Payload Header Extension Structure (PHES), and a PACI payload. This payload structure is specified in Section 4.4.4.
o PACI承载RTP数据包：包含一个有效负载报头（与其他有效负载报头的效率不同）、一个有效负载报头扩展结构（PHES）和一个PACI有效负载。第4.4.4节规定了该有效载荷结构。
A single NAL unit packet contains exactly one NAL unit, and consists of a payload header (denoted as PayloadHdr), a conditional 16-bit DONL field (in network byte order), and the NAL unit payload data (the NAL unit excluding its NAL unit header) of the contained NAL unit, as shown in Figure 3.
单个NAL单元数据包只包含一个NAL单元，它由一个有效负载报头（表示为PayloadHdr）、一个有条件的16位DONL字段（以网络字节顺序）和包含的NAL单元的NAL单元有效负载数据（NAL单元不包括其NAL单元报头）组成，如图3所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit payload data |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit payload data |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Structure of a Single NAL Unit Packet
图3：单个NAL单元数据包的结构
The payload header SHOULD be an exact copy of the NAL unit header of the contained NAL unit. However, the Type (i.e., nal_unit_type) field MAY be changed, e.g., when it is desirable to handle a CRA picture to be a BLA picture [JCTVC-J0107].
有效负载标头应该是所包含NAL单元的NAL单元标头的精确副本。然而，例如，当希望将CRA图片处理为BLA图片时，类型（即，nal_单位_类型）字段可以改变[JCTVC-J0107]。
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the contained NAL unit. If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DONL field MUST be present, and the variable DON for the contained NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DONL field MUST NOT be present.
DONL字段（当存在时）指定所包含NAL单元的解码顺序号的16个最低有效位的值。如果任何RTP流的sprop max don diff大于0，则必须存在DONL字段，并且包含的NAL单元的变量don将被导出为等于DONL字段的值。否则（对于所有RTP流，sprop max don diff等于0），DONL字段不得存在。
Aggregation Packets (APs) are introduced to enable the reduction of packetization overhead for small NAL units, such as most of the non-VCL NAL units, which are often only a few octets in size.
引入聚合数据包（AP）是为了减少小型NAL单元（如大多数非VCL NAL单元）的数据包化开销，这些NAL单元通常只有几个八位字节。
An AP aggregates NAL units within one access unit. Each NAL unit to be carried in an AP is encapsulated in an aggregation unit. NAL units aggregated in one AP are in NAL unit decoding order.
AP在一个接入单元内聚合NAL单元。AP中要携带的每个NAL单元被封装在聚合单元中。在一个AP中聚合的NAL单元以NAL单元解码顺序。
An AP consists of a payload header (denoted as PayloadHdr) followed by two or more aggregation units, as shown in Figure 4.
AP由一个负载头（表示为PayloadHdr）和两个或多个聚合单元组成，如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| two or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| two or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Structure of an Aggregation Packet
图4：聚合数据包的结构
The fields in the payload header are set as follows. The F bit MUST be equal to 0 if the F bit of each aggregated NAL unit is equal to zero; otherwise, it MUST be equal to 1. The Type field MUST be equal to 48. The value of LayerId MUST be equal to the lowest value of LayerId of all the aggregated NAL units. The value of TID MUST be the lowest value of TID of all the aggregated NAL units.
有效负载标题中的字段设置如下。如果每个聚合NAL单元的F位等于零，则F位必须等于0；否则，它必须等于1。类型字段必须等于48。LayerId的值必须等于所有聚合NAL单元中LayerId的最低值。TID值必须是所有聚合NAL单元中TID的最低值。
Informative note: All VCL NAL units in an AP have the same TID value since they belong to the same access unit. However, an AP may contain non-VCL NAL units for which the TID value in the NAL unit header may be different than the TID value of the VCL NAL units in the same AP.
资料性说明：AP中的所有VCL NAL单元都具有相同的TID值，因为它们属于相同的访问单元。然而，AP可能包含非VCL NAL单元，其中NAL单元头中的TID值可能不同于同一AP中VCL NAL单元的TID值。
An AP MUST carry at least two aggregation units and can carry as many aggregation units as necessary; however, the total amount of data in an AP obviously MUST fit into an IP packet, and the size SHOULD be chosen so that the resulting IP packet is smaller than the MTU size so to avoid IP layer fragmentation. An AP MUST NOT contain FUs specified in Section 4.4.3. APs MUST NOT be nested; i.e., an AP must not contain another AP.
AP必须携带至少两个聚合单元，并且可以根据需要携带任意多个聚合单元；然而，AP中的数据总量显然必须适合IP数据包，并且应选择大小，以使生成的IP数据包小于MTU大小，从而避免IP层碎片。AP不得包含第4.4.3节中规定的FU。AP不得嵌套；i、 例如，一个AP不得包含另一个AP。
The first aggregation unit in an AP consists of a conditional 16-bit DONL field (in network byte order) followed by a 16-bit unsigned size information (in network byte order) that indicates the size of the NAL unit in bytes (excluding these two octets, but including the NAL unit header), followed by the NAL unit itself, including its NAL unit header, as shown in Figure 5.
AP中的第一个聚合单元由一个有条件的16位DONL字段（按网络字节顺序）和一个16位无符号大小信息（按网络字节顺序）组成，该信息以字节表示NAL单元的大小（不包括这两个八位字节，但包括NAL单元头），然后是NAL单元本身，包括它的NAL单元头，如图5所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DONL (conditional) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU size | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DONL (conditional) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU size | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Structure of the First Aggregation Unit in an AP
图5：AP中第一个聚合单元的结构
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the aggregated NAL unit.
DONL字段（当存在时）指定聚合NAL单元的解码顺序号的16个最低有效位的值。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DONL field MUST be present in an aggregation unit that is the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DONL field MUST NOT be present in an aggregation unit that is the first aggregation unit in an AP.
如果任何RTP流的sprop max don diff大于0，则作为AP中第一个聚合单元的聚合单元中必须存在DONL字段，并且聚合NAL单元的变量don将被导出为等于DONL字段的值。否则（对于所有RTP流，sprop max don diff等于0），作为AP中第一个聚合单元的聚合单元中不得存在DONL字段。
An aggregation unit that is not the first aggregation unit in an AP consists of a conditional 8-bit DOND field followed by a 16-bit unsigned size information (in network byte order) that indicates the size of the NAL unit in bytes (excluding these two octets, but including the NAL unit header), followed by the NAL unit itself, including its NAL unit header, as shown in Figure 6.
不是AP中第一个聚合单元的聚合单元由条件8位DOND字段和16位无符号大小信息（按网络字节顺序）组成，该信息以字节表示NAL单元的大小（不包括这两个八位字节，但包括NAL单元头），后跟NAL单元本身，包括其NAL单元头，如图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DOND (cond) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DOND (cond) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Structure of an Aggregation Unit That Is Not the First Aggregation Unit in an AP
图6：不是AP中第一个聚合单元的聚合单元的结构
When present, the DOND field plus 1 specifies the difference between the decoding order number values of the current aggregated NAL unit and the preceding aggregated NAL unit in the same AP.
当存在时，DOND字段加1指定同一AP中当前聚合NAL单元和前一聚合NAL单元的解码顺序号值之间的差值。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DOND field MUST be present in an aggregation unit that is not the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DOND field MUST NOT be present in an aggregation unit that is not the first aggregation unit in an AP, and in this case the transmission order and decoding order of NAL units carried in the AP are the same as the order the NAL units appear in the AP.
如果任何RTP流的sprop max don diff大于0，则DOND字段必须存在于不是AP中第一个聚合单元的聚合单元中，并且，聚合NAL单元的变量DON被导出为等于相同AP中先前聚合NAL单元的DON加上DOND字段的值加上1模65536。否则（对于所有RTP流，sprop max don diff等于0），DOND字段不得出现在不是AP中第一个聚合单元的聚合单元中，在这种情况下，AP中携带的NAL单元的传输顺序和解码顺序与NAL单元在AP中出现的顺序相同。
Figure 7 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, without the DONL and DOND fields being present.
图7显示了一个AP示例，该AP包含两个聚合单元，在图中标记为1和2，不存在DONL和DOND字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 1 Data |
| . . . |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+ NALU 2 Data |
| . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 1 Data |
| . . . |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+ NALU 2 Data |
| . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: An Example of an AP Packet Containing Two Aggregation Units without the DONL and DOND Fields
图7：包含两个聚合单元的AP数据包示例，其中没有DONL和DOND字段
Figure 8 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, with the DONL and DOND fields being present.
图8显示了一个AP示例，该AP包含两个聚合单元，在图中标记为1和2，并且存在DONL和DOND字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 DONL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NALU 1 Data . . . |
| |
+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 DOND | NALU 2 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 2 Data |
| |
| . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 DONL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NALU 1 Data . . . |
| |
+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 DOND | NALU 2 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 2 Data |
| |
| . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: An Example of an AP Containing Two Aggregation Units with the DONL and DOND Fields
图8：包含两个聚合单元的AP示例，其中包含DONL和DOND字段
Fragmentation Units (FUs) are introduced to enable fragmenting a single NAL unit into multiple RTP packets, possibly without cooperation or knowledge of the HEVC encoder. A fragment of a NAL unit consists of an integer number of consecutive octets of that NAL unit. Fragments of the same NAL unit MUST be sent in consecutive order with ascending RTP sequence numbers (with no other RTP packets within the same RTP stream being sent between the first and last fragment).
引入分段单元（FUs）可将单个NAL单元分段为多个RTP数据包，可能无需HEVC编码器的配合或了解。NAL单元的片段由该NAL单元的整数个连续八位字节组成。同一NAL单元的片段必须以递增RTP序列号的连续顺序发送（同一RTP流中的其他RTP数据包不得在第一个片段和最后一个片段之间发送）。
When a NAL unit is fragmented and conveyed within FUs, it is referred to as a fragmented NAL unit. APs MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU must not contain a subset of another FU.
当NAL单元被分段并在FUs内传送时，它被称为分段NAL单元。AP不能是碎片化的。FU不得嵌套；i、 例如，一个FU不能包含另一个FU的子集。
The RTP timestamp of an RTP packet carrying an FU is set to the NALU-time of the fragmented NAL unit.
携带FU的RTP分组的RTP时间戳被设置为分段NAL单元的NALU时间。
An FU consists of a payload header (denoted as PayloadHdr), an FU header of one octet, a conditional 16-bit DONL field (in network byte order), and an FU payload, as shown in Figure 9.
FU由有效载荷头（表示为PayloadHdr）、一个八位字节的FU头、一个条件16位DONL字段（以网络字节顺序）和一个FU有效载荷组成，如图9所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=49) | FU header | DONL (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| DONL (cond) | |
|-+-+-+-+-+-+-+-+ |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=49) | FU header | DONL (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| DONL (cond) | |
|-+-+-+-+-+-+-+-+ |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Structure of an FU
图9：安府的结构
The fields in the payload header are set as follows. The Type field MUST be equal to 49. The fields F, LayerId, and TID MUST be equal to the fields F, LayerId, and TID, respectively, of the fragmented NAL unit.
有效负载标题中的字段设置如下。类型字段必须等于49。字段F、LayerId和TID必须分别等于分段NAL单元的字段F、LayerId和TID。
The FU header consists of an S bit, an E bit, and a 6-bit FuType field, as shown in Figure 10.
FU头由一个S位、一个E位和一个6位FuType字段组成，如图10所示。
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E| FuType |
+---------------+
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E| FuType |
+---------------+
Figure 10: The Structure of FU Header
图10:FU头的结构
The semantics of the FU header fields are as follows:
FU头字段的语义如下所示：
S: 1 bit When set to 1, the S bit indicates the start of a fragmented NAL unit, i.e., the first byte of the FU payload is also the first byte of the payload of the fragmented NAL unit. When the FU payload is not the start of the fragmented NAL unit payload, the S bit MUST be set to 0.
S:1位当设置为1时，S位表示分段NAL单元的开始，即FU有效负载的第一个字节也是分段NAL单元有效负载的第一个字节。当FU有效负载不是分段NAL单元有效负载的开始时，S位必须设置为0。
E: 1 bit When set to 1, the E bit indicates the end of a fragmented NAL unit, i.e., the last byte of the payload is also the last byte of the fragmented NAL unit. When the FU payload is not the last fragment of a fragmented NAL unit, the E bit MUST be set to 0.
E:1位当设置为1时，E位表示分段NAL单元的结束，即有效负载的最后一个字节也是分段NAL单元的最后一个字节。当FU有效载荷不是分段NAL单元的最后一个片段时，E位必须设置为0。
FuType: 6 bits The field FuType MUST be equal to the field Type of the fragmented NAL unit.
FuType:6位字段FuType必须等于单元的字段类型。
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the fragmented NAL unit.
DONL字段（当存在时）指定分段NAL单元的解码顺序号的16个最低有效位的值。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, and the S bit is equal to 1, the DONL field MUST be present in the FU, and the variable DON for the fragmented NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams, or the S bit is equal to 0), the DONL field MUST NOT be present in the FU.
如果任何RTP流的sprop max don diff大于0，且S位等于1，则FU中必须存在DONL字段，并且分段NAL单元的变量don被导出为等于DONL字段的值。否则（对于所有RTP流，sprop max don diff等于0，或者S位等于0），FU中不得存在DONL字段。
A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start bit and End bit must not both be set to 1 in the same FU header.
非分段NAL单元不得在一个FU中传输；i、 例如，在同一FU标头中，起始位和结束位不得同时设置为1。
The FU payload consists of fragments of the payload of the fragmented NAL unit so that if the FU payloads of consecutive FUs, starting with an FU with the S bit equal to 1 and ending with an FU with the E bit equal to 1, are sequentially concatenated, the payload of the fragmented NAL unit can be reconstructed. The NAL unit header of the fragmented NAL unit is not included as such in the FU payload, but rather the information of the NAL unit header of the fragmented NAL unit is conveyed in F, LayerId, and TID fields of the FU payload headers of the FUs and the FuType field of the FU header of the FUs. An FU payload MUST NOT be empty.
FU有效载荷由分段NAL单元的有效载荷的片段组成，因此，如果连续FU的FU有效载荷（从S位等于1的FU开始，到E位等于1的FU结束）被顺序串联，则可以重构分段NAL单元的有效载荷。分段NAL单元的NAL单元报头不包括在FU有效载荷中，而是分段NAL单元的NAL单元报头的信息在FUs的FU有效载荷报头的F、LayerId和TID字段以及FUs的FU报头的FuType字段中传送。FU有效载荷不得为空。
If an FU is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit, unless the decoder in the receiver is known to be prepared to gracefully handle incomplete NAL units.
如果FU丢失，则接收机应按照与相同分段NAL单元相对应的传输顺序丢弃所有后续分段单元，除非已知接收机中的解码器准备好优雅地处理不完整的NAL单元。
A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is not received. In this case, the forbidden_zero_bit of the NAL unit MUST be set to 1 to indicate a syntax violation.
端点或MANE中的接收器可以将NAL单元的前n-1个片段聚合为（不完整的）NAL单元，即使没有接收到该NAL单元的片段n。在这种情况下，NAL单元的禁止\u零\u位必须设置为1，以指示语法冲突。
This section specifies the PACI packet structure. The basic payload header specified in this memo is intentionally limited to the 16 bits of the NAL unit header so to keep the packetization overhead to a minimum. However, cases have been identified where it is advisable to include control information in an easily accessible position in the packet header, despite the additional overhead. One such control information is the TSCI as specified in Section 4.5. PACI packets carry this and future, similar structures.
本节指定PACI数据包结构。本备忘录中指定的基本有效负载报头有意限制为NAL单元报头的16位，以便将打包开销保持在最小。然而，已经确定了一些情况，其中建议在分组报头中的容易访问的位置包括控制信息，尽管存在额外的开销。第4.5节规定的TSCI就是此类控制信息之一。PACI数据包携带这种和未来类似的结构。
The PACI packet structure is based on a payload header extension mechanism that is generic and extensible to carry payload header extensions. In this section, the focus lies on the use within this specification. Section 4.4.4.2 provides guidance for the specification designers in how to employ the extension mechanism in future specifications.
PACI分组结构基于负载报头扩展机制，该机制是通用的，可扩展以承载负载报头扩展。在本节中，重点在于本规范中的使用。第4.4.4.2节为规范设计人员提供了如何在未来规范中使用扩展机制的指导。
A PACI packet consists of a payload header (denoted as PayloadHdr), for which the structure follows what is described in Section 4.2. The payload header is followed by the fields A, cType, PHSsize, F[0..2], and Y.
PACI数据包由有效载荷报头（表示为PayloadHdr）组成，其结构如第4.2节所述。有效负载头后面是字段A、cType、PHSsize、F[0..2]和Y。
Figure 11 shows a PACI packet in compliance with this memo, i.e., without any extensions.
图11显示了符合此备忘录的PACI数据包，即没有任何扩展。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header Extension Structure (PHES) |
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=|
| |
| PACI payload: NAL unit |
| . . . |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header Extension Structure (PHES) |
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=|
| |
| PACI payload: NAL unit |
| . . . |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The Structure of a PACI
图11:PACI的结构
The fields in the payload header are set as follows. The F bit MUST be equal to 0. The Type field MUST be equal to 50. The value of LayerId MUST be a copy of the LayerId field of the PACI payload NAL unit or NAL-unit-like structure. The value of TID MUST be a copy of the TID field of the PACI payload NAL unit or NAL-unit-like structure.
有效负载标题中的字段设置如下。F位必须等于0。类型字段必须等于50。LayerId的值必须是PACI有效负载NAL单元或类似NAL单元的结构的LayerId字段的副本。TID的值必须是PACI有效负载NAL单元或类似NAL单元结构的TID字段的副本。
The semantics of other fields are as follows:
其他字段的语义如下所示：
A: 1 bit Copy of the F bit of the PACI payload NAL unit or NAL-unit-like structure.
A:PACI有效负载NAL单元或类似NAL单元的结构的F位的1位拷贝。
cType: 6 bits Copy of the Type field of the PACI payload NAL unit or NAL-unit-like structure.
cType:PACI有效负载NAL单元或类似NAL单元的结构的类型字段的6位副本。
PHSsize: 5 bits Indicates the length of the PHES field. The value is limited to be less than or equal to 32 octets, to simplify encoder design for MTU size matching.
PHSsize:5位表示PHES字段的长度。该值限制为小于或等于32个八位字节，以简化MTU大小匹配的编码器设计。
F0: This field equal to 1 specifies the presence of a temporal scalability support extension in the PHES.
F0：该字段等于1，指定PHE中存在临时可伸缩性支持扩展。
F1, F2: MUST be 0, available for future extensions, see Section 4.4.4.2. Receivers compliant with this version of the HEVC payload format MUST ignore F1=1 and/or F2=1, and also ignore any information in the PHES indicated as present by F1=1 and/or F2=1.
F1、F2：必须为0，可用于将来的扩展，请参见第4.4.4.2节。符合此版本HEVC有效载荷格式的接收器必须忽略F1=1和/或F2=1，并且忽略由F1=1和/或F2=1指示的PHE中的任何信息。
Informative note: The receiver can do that by first decoding information associated with F0=1, and then skipping over any remaining bytes of the PHES based on the value of PHSsize.
信息性说明：接收机可以通过首先解码与F0=1相关联的信息，然后基于PHSsize的值跳过PHE的任何剩余字节来实现。
Y: 1 bit MUST be 0, available for future extensions, see Section 4.4.4.2. Receivers compliant with this version of the HEVC payload format MUST ignore Y=1, and also ignore any information in the PHES indicated as present by Y.
Y:1位必须为0，可用于将来的扩展，请参见第4.4.4.2节。符合此版本HEVC有效载荷格式的接收器必须忽略Y=1，并且也忽略Y指示的PHES中的任何信息。
PHES: variable number of octets A variable number of octets as indicated by the value of PHSsize.
PHES：可变八位字节数PHSsize值指示的可变八位字节数。
PACI Payload: The single NAL unit packet or NAL-unit-like structure (such as: FU or AP) to be carried, not including the first two octets.
PACI有效载荷：要携带的单个NAL单元数据包或类似NAL单元的结构（例如：FU或AP），不包括前两个八位字节。
Informative note: The first two octets of the NAL unit or NAL-unit-like structure carried in the PACI payload are not included in the PACI payload. Rather, the respective values are copied in locations of the PayloadHdr of the RTP packet. This design offers two advantages: first, the overall structure of the payload header is preserved, i.e., there is no special case of payload header structure that needs to be implemented for PACI. Second, no additional overhead is introduced.
资料性说明：PACI有效载荷中携带的NAL单元或类似NAL单元的结构的前两个八位字节不包括在PACI有效载荷中。相反，在RTP分组的PayloadHdr的位置中复制相应的值。这种设计提供了两个优点：首先，保留了有效负载报头的整体结构，即没有需要为PACI实现的有效负载报头结构的特殊情况。其次，不引入额外的开销。
A PACI payload MAY be a single NAL unit, an FU, or an AP. PACIs MUST NOT be fragmented or aggregated. The following subsection documents the reasons for these design choices.
PACI有效载荷可以是单个NAL单元、FU或AP。太平洋岛国不得分散或聚合。以下小节记录了这些设计选择的原因。
A PACI cannot be fragmented. If a PACI could be fragmented, and a fragment other than the first fragment got lost, access to the information in the PACI would not be possible. Therefore, a PACI must not be fragmented. In other words, an FU must not carry (fragments of) a PACI.
和平进程不能支离破碎。如果一个PACI可以被分割，而第一个片段以外的片段丢失，那么就不可能访问PACI中的信息。因此，和平倡议决不能支离破碎。换言之，安福不能携带帕西（帕西的碎片）。
A PACI cannot be aggregated. Aggregation of PACIs is inadvisable from a compression viewpoint, as, in many cases, several to be aggregated NAL units would share identical PACI fields and values which would be carried redundantly for no reason. Most, if not all, of the practical effects of PACI aggregation can be achieved by aggregating NAL units and bundling them with a PACI (see below). Therefore, a PACI must not be aggregated. In other words, an AP must not contain a PACI.
不能聚合PACI。从压缩的角度来看，聚合PACI是不可取的，因为在许多情况下，几个待聚合的NAL单元将共享相同的PACI字段和值，这些字段和值将毫无理由地进行冗余携带。PACI聚合的大部分（如果不是全部的话）实际效果可以通过聚合NAL单元并将其与PACI捆绑（见下文）来实现。因此，不得对PACI进行汇总。换句话说，AP不得包含PACI。
The payload of a PACI can be a fragment. Both middleboxes and sending systems with inflexible (often hardware-based) encoders occasionally find themselves in situations where a PACI and its headers, combined, are larger than the MTU size. In such a scenario, the middlebox or sender can fragment the NAL unit and encapsulate the fragment in a PACI. Doing so preserves the payload header extension information for all fragments, allowing downstream middleboxes and the receiver to take advantage of that information. Therefore, a sender may place a fragment into a PACI, and a receiver must be able to handle such a PACI.
PACI的有效载荷可以是碎片。中间盒和带有不灵活（通常基于硬件）编码器的发送系统偶尔会发现自己处于PACI及其标头的组合大于MTU大小的情况下。在这种情况下，中间盒或发送方可以对NAL单元进行分段，并将该分段封装在PACI中。这样做会保留所有片段的有效负载报头扩展信息，从而允许下游中间盒和接收器利用该信息。因此，发送方可以将片段放入PACI中，接收方必须能够处理这样的PACI。
The payload of a PACI can be an aggregation NAL unit. HEVC bitstreams can contain unevenly sized and/or small (when compared to the MTU size) NAL units. In order to efficiently packetize such small NAL units, APs were introduced. The benefits of APs are independent from the need for a payload header extension. Therefore, a sender may place an AP into a PACI, and a receiver must be able to handle such a PACI.
PACI的有效负载可以是聚合NAL单元。HEVC比特流可能包含大小不均和/或较小（与MTU大小相比）的NAL单元。为了有效地将这些小型NAL单元打包，引入了APs。AP的好处独立于有效负载报头扩展的需要。因此，发送方可以将AP放入PACI，接收方必须能够处理此类PACI。
This section includes recommendations for future specification designers on how to extent the PACI syntax to accommodate future extensions. Obviously, designers are free to specify whatever appears to be appropriate to them at the time of their design. However, a lot of thought has been invested into the extension mechanism described below, and we suggest that deviations from it warrant a good explanation.
本节为未来的规范设计者提供了关于如何扩展PACI语法以适应未来扩展的建议。显然，设计师在设计时可以自由地指定任何适合他们的东西。然而，在下面描述的扩展机制中已经投入了大量的思想，我们建议对它的偏差进行很好的解释。
This memo defines only a single payload header extension (TSCI, described in Section 4.5); therefore, only the F0 bit carries semantics. F1 and F2 are already named (and not just marked as reserved, as a typical video spec designer would do). They are intended to signal two additional extensions. The Y bit allows one to, recursively, add further F and Y bits to extend the mechanism beyond three possible payload header extensions. It is suggested to define a new packet type (using a different value for Type) when assigning the F1, F2, or Y bits different semantics than what is suggested below.
本备忘录仅定义了一个有效载荷标题扩展（TSCI，如第4.5节所述）；因此，只有F0位承载语义。F1和F2已经命名（而不仅仅像典型的视频规格设计师那样标记为保留）。它们旨在发出两个额外扩展的信号。Y位允许递归地添加更多的F和Y位，以将机制扩展到三个可能的有效负载头扩展之外。建议在为F1、F2或Y位分配不同于下面建议的语义时，定义一个新的数据包类型（使用不同的类型值）。
When a Y bit is set, an 8-bit flag-extension is inserted after the Y bit. A flag-extension consists of 7 flags F[n..n+6], and another Y bit.
设置Y位时，在Y位之后插入8位标志扩展名。标志扩展由7个标志F[n..n+6]和另一个Y位组成。
The basic PACI header already includes F0, F1, and F2. Therefore, the Fx bits in the first flag-extensions are numbered F3, F4, ..., F9; the F bits in the second flag-extension are numbered F10, F11, ..., F16, and so forth. As a result, at least three Fx bits are always in the PACI, but the number of Fx bits (and associated types of extensions) can be increased by setting the next Y bit and adding an octet of flag-extensions, carrying seven flags and another Y bit. The size of this list of flags is subject to the limits specified in Section 4.4.4 (32 octets for all flag-extensions and the PHES information combined).
基本PACI标头已经包括F0、F1和F2。因此，第一标志扩展中的Fx位被编号为F3、F4、…、F9；第二标志扩展中的F位编号为F10、F11、…、F16等。因此，PACI中始终至少有三个Fx位，但可以通过设置下一个Y位并添加八位标志扩展（携带七个标志和另一个Y位）来增加Fx位（以及相关扩展类型）的数量。此标志列表的大小受第4.4.4节规定的限制（所有标志扩展和PHES信息组合为32个八位字节）。
Each of the F bits can indicate either the presence or the absence of certain information in the Payload Header Extension Structure (PHES).
每个F位可以指示有效负载报头扩展结构（PHES）中存在或不存在某些信息。
When a spec developer devises a new syntax that takes advantage of the PACI extension mechanism, he/she must follow the constraints listed below; otherwise, the extension mechanism may break.
当规范开发人员设计一种利用PACI扩展机制的新语法时，他/她必须遵循下面列出的约束条件；否则，延伸机构可能会断裂。
1) The fields added for a particular Fx bit MUST be fixed in length and not depend on what other Fx bits are set (no parsing dependency).
1) 为特定Fx位添加的字段的长度必须固定，并且不依赖于设置的其他Fx位（无解析依赖项）。
2) The Fx bits must be assigned in order.
2) 必须按顺序分配Fx位。
3) An implementation that supports the n-th Fn bit for any value of n must understand the syntax (though not necessarily the semantics) of the fields Fk (with k < n), so as to be able to either use those bits when present, or at least be able to skip over them.
3) 对于任何值n，支持第n个Fn位的实现必须理解字段Fk（k<n）的语法（但不一定是语义），以便能够在出现这些位时使用它们，或者至少能够跳过它们。
This section describes the single payload header extension defined in this specification, known as TSCI. If, in the future, additional payload header extensions become necessary, they could be specified in this section of an updated version of this document, or in their own documents.
本节描述了本规范中定义的单一有效负载标头扩展，称为TSCI。如果将来需要额外的有效负载标头扩展，可以在本文档更新版本的本节中或在其自己的文档中指定这些扩展。
When F0 is set to 1 in a PACI, this specifies that the PHES field includes the TSCI fields TL0PICIDX, IrapPicID, S, and E as follows:
当在PACI中将F0设置为1时，这指定PHES字段包括TSCI字段TL0PICIDX、IrapPicID、S和E，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TL0PICIDX | IrapPicID |S|E| RES | |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .... |
| PACI payload: NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TL0PICIDX | IrapPicID |S|E| RES | |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .... |
| PACI payload: NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Structure of a PACI with a PHES Containing a TSCI
图12：含含TSCI的PHES的PACI结构
TL0PICIDX (8 bits) When present, the TL0PICIDX field MUST be set to equal to temporal_sub_layer_zero_idx as specified in Section D.3.22 of [HEVC] for the access unit containing the NAL unit in the PACI.
TL0PICIDX（8位）当存在时，TL0PICIDX字段必须设置为等于[HEVC]第D.3.22节中针对PACI中包含NAL单元的接入单元规定的时间子层零idx。
IrapPicID (8 bits) When present, the IrapPicID field MUST be set to equal to irap_pic_id as specified in Section D.3.22 of [HEVC] for the access unit containing the NAL unit in the PACI.
IrapPicID（8位）当存在时，必须将IrapPicID字段设置为等于[HEVC]第D.3.22节中针对PACI中包含NAL单元的接入单元规定的irap_PICU id。
S (1 bit) The S bit MUST be set to 1 if any of the following conditions is true and MUST be set to 0 otherwise:
S（1位）如果以下任一条件为真，则S位必须设置为1，否则必须设置为0：
o The NAL unit in the payload of the PACI is the first VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是图片的第一个VCL NAL单元（按解码顺序）。
o The NAL unit in the payload of the PACI is an AP, and the NAL unit in the first contained aggregation unit is the first VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是AP，并且第一包含的聚合单元中的NAL单元是图片的第一VCL NAL单元（按解码顺序）。
o The NAL unit in the payload of the PACI is an FU with its S bit equal to 1 and the FU payload containing a fragment of the first VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是其S比特等于1的FU，并且FU有效载荷包含图片的第一VCL NAL单元的片段（按解码顺序）。
E (1 bit) The E bit MUST be set to 1 if any of the following conditions is true and MUST be set to 0 otherwise:
E（1位）如果以下任一条件为真，则E位必须设置为1，否则必须设置为0：
o The NAL unit in the payload of the PACI is the last VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是图片的最后一个VCL NAL单元（按解码顺序）。
o The NAL unit in the payload of the PACI is an AP and the NAL unit in the last contained aggregation unit is the last VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是AP，最后包含的聚合单元中的NAL单元是图片的最后VCL NAL单元（按解码顺序）。
o The NAL unit in the payload of the PACI is an FU with its E bit equal to 1 and the FU payload containing a fragment of the last VCL NAL unit, in decoding order, of a picture.
o PACI的有效载荷中的NAL单元是其E比特等于1的FU，并且FU有效载荷包含图片的最后VCL NAL单元的片段（按解码顺序）。
RES (6 bits) MUST be equal to 0. Reserved for future extensions.
RES（6位）必须等于0。保留供将来扩展。
The value of PHSsize MUST be set to 3. Receivers MUST allow other values of the fields F0, F1, F2, Y, and PHSsize, and MUST ignore any additional fields, when present, than specified above in the PHES.
PHSsize的值必须设置为3。接收器必须允许字段F0、F1、F2、Y和PHSsize的其他值，并且必须忽略除上述PHES中规定之外的任何其他字段（如果存在）。
For each NAL unit, the variable AbsDon is derived, representing the decoding order number that is indicative of the NAL unit decoding order.
对于每个NAL单元，导出表示表示NAL单元解码顺序的解码顺序号的变量AbsDon。
Let NAL unit n be the n-th NAL unit in transmission order within an RTP stream.
假设NAL单元n是RTP流中传输顺序的第n个NAL单元。
If sprop-max-don-diff is equal to 0 for all the RTP streams carrying the HEVC bitstream, AbsDon[n], the value of AbsDon for NAL unit n, is derived as equal to n.
如果对于承载HEVC比特流的所有RTP流，sprop max don diff等于0，则NAL单元n的AbsDon值AbsDon[n]将导出为等于n。
Otherwise (sprop-max-don-diff is greater than 0 for any of the RTP streams), AbsDon[n] is derived as follows, where DON[n] is the value of the variable DON for NAL unit n:
否则（对于任何RTP流，sprop max don diff大于0），AbsDon[n]的推导如下，其中don[n]是NAL单元n的变量don的值：
o If n is equal to 0 (i.e., NAL unit n is the very first NAL unit in transmission order), AbsDon[0] is set equal to DON[0].
o 如果n等于0（即，NAL单元n是传输顺序中的第一个NAL单元），则AbsDon[0]被设置为等于DON[0]。
o Otherwise (n is greater than 0), the following applies for derivation of AbsDon[n]:
o 否则（n大于0），以下适用于AbsDon[n]的推导：
If DON[n] == DON[n-1], AbsDon[n] = AbsDon[n-1]
如果DON[n]==DON[n-1]，则AbsDon[n]=AbsDon[n-1]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768),
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768),
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 -
DON[n])
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 -
DON[n])
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
For any two NAL units m and n, the following applies:
对于任意两个NAL单位m和n，以下各项适用：
o AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit m in NAL unit decoding order.
o AbsDon[n]大于AbsDon[m]表示NAL单元n以NAL单元解码顺序跟随NAL单元m。
o When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding order of the two NAL units can be in either order.
o 当AbsDon[n]等于AbsDon[m]时，两个NAL单元的NAL单元解码顺序可以是任意顺序。
o AbsDon[n] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m in decoding order.
o 小于AbsDon[m]的AbsDon[n]表示在解码顺序上NAL单元n先于NAL单元m。
Informative note: When two consecutive NAL units in the NAL unit decoding order have different values of AbsDon, the absolute difference between the two AbsDon values may be greater than or equal to 1.
资料性说明：当NAL单元解码顺序中的两个连续NAL单元具有不同的AbsDon值时，两个AbsDon值之间的绝对差值可能大于或等于1。
Informative note: There are multiple reasons to allow for the absolute difference of the values of AbsDon for two consecutive NAL units in the NAL unit decoding order to be greater than one. An increment by one is not required, as at the time of associating values of AbsDon to NAL units, it may not be known whether all NAL units are to be delivered to the receiver. For example, a gateway may not forward VCL NAL units of higher sub-layers or some SEI NAL units when there is congestion in the network. In another example, the first intra-coded picture of a pre-encoded clip is transmitted in advance to ensure that it is readily available in the receiver, and when transmitting the first intra-coded picture, the originator does not exactly know how many NAL units will be encoded before the first intra-coded picture of the pre-encoded clip follows in decoding order. Thus, the values of AbsDon for the NAL units of the first intra-coded picture of the pre-encoded clip have to be estimated when they are transmitted, and gaps in values of AbsDon may occur. Another example is MRST or MRMT with sprop-max-don-diff greater than 0, where the AbsDon values must indicate cross-layer decoding order for NAL units conveyed in all the RTP streams.
资料性说明：有多种原因允许NAL单元解码顺序中两个连续NAL单元的AbsDon值的绝对差值大于1。不需要增加1，因为在将AbsDon的值与NAL单元相关联时，可能不知道是否所有NAL单元都要交付给接收机。例如，当网络中存在拥塞时，网关可能不转发更高子层的VCL NAL单元或某些SEI NAL单元。在另一示例中，预先发送预编码片段的第一帧内编码图片以确保其在接收器中随时可用，并且在发送第一帧内编码图片时，发起者不确切地知道在预编码片段的第一帧内编码图片按照解码顺序跟随之前将编码多少NAL单元。因此，当传输预编码片段的第一帧内编码图片的NAL单元时，必须估计其AbsDon的值，并且AbsDon的值中可能出现间隙。另一个示例是sprop max don diff大于0的MRST或MRMT，其中AbsDon值必须指示所有RTP流中传输的NAL单元的跨层解码顺序。
The following packetization rules apply:
以下打包规则适用：
o If sprop-max-don-diff is greater than 0 for any of the RTP streams, the transmission order of NAL units carried in the RTP stream MAY be different than the NAL unit decoding order and the NAL unit output order. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order and, when tx-mode is equal to "MRST" or "MRMT", MUST also be the same as the NAL unit output order.
o 如果任何RTP流的sprop max don diff大于0，则RTP流中携带的NAL单元的传输顺序可能不同于NAL单元解码顺序和NAL单元输出顺序。否则（对于所有RTP流，sprop max don diff等于0），RTP流中携带的NAL单元的传输顺序必须与NAL单元解码顺序相同，并且当tx模式等于“MRST”或“MRMT”时，也必须与NAL单元输出顺序相同。
o A NAL unit of a small size SHOULD be encapsulated in an aggregation packet together with one or more other NAL units in order to avoid the unnecessary packetization overhead for small NAL units. For example, non-VCL NAL units such as access unit delimiters, parameter sets, or SEI NAL units are typically small and can often be aggregated with VCL NAL units without violating MTU size constraints.
o 小尺寸的NAL单元应与一个或多个其他NAL单元一起封装在聚合分组中，以避免小NAL单元不必要的打包开销。例如，非VCL NAL单元（如访问单元定界符、参数集或SEI-NAL单元）通常很小，并且通常可以与VCL NAL单元聚合而不违反MTU大小约束。
o Each non-VCL NAL unit SHOULD, when possible from an MTU size match viewpoint, be encapsulated in an aggregation packet together with its associated VCL NAL unit, as typically a non-VCL NAL unit would be meaningless without the associated VCL NAL unit being available.
o 在可能的情况下，从MTU大小匹配的角度来看，每个非VCL NAL单元应与其关联的VCL NAL单元一起封装在聚合分组中，因为如果关联的VCL NAL单元不可用，通常非VCL NAL单元将毫无意义。
o For carrying exactly one NAL unit in an RTP packet, a single NAL unit packet MUST be used.
o 为了在RTP数据包中只携带一个NAL单元，必须使用一个NAL单元数据包。
The general concept behind de-packetization is to get the NAL units out of the RTP packets in an RTP stream and all RTP streams the RTP stream depends on, if any, and pass them to the decoder in the NAL unit decoding order.
反打包背后的一般概念是从RTP流中的RTP包和RTP流所依赖的所有RTP流（如果有）中获取NAL单元，并按照NAL单元解码顺序将它们传递给解码器。
The de-packetization process is implementation dependent. Therefore, the following description should be seen as an example of a suitable implementation. Other schemes may be used as well, as long as the output for the same input is the same as the process described below. The output is the same when the set of output NAL units and their order are both identical. Optimizations relative to the described algorithms are possible.
反打包过程取决于实现。因此，应将以下描述视为适当实现的示例。也可以使用其他方案，只要相同输入的输出与下面描述的过程相同。当输出NAL单元集及其顺序都相同时，输出相同。与所述算法相关的优化是可能的。
All normal RTP mechanisms related to buffer management apply. In particular, duplicated or outdated RTP packets (as indicated by the RTP sequences number and the RTP timestamp) are removed. To determine the exact time for decoding, factors such as a possible intentional delay to allow for proper inter-stream synchronization must be factored in.
所有与缓冲区管理相关的正常RTP机制都适用。特别地，删除重复的或过时的RTP分组（如RTP序列号和RTP时间戳所示）。为了确定解码的确切时间，必须考虑一些因素，例如允许适当的流间同步的可能故意延迟。
NAL units with NAL unit type values in the range of 0 to 47, inclusive, may be passed to the decoder. NAL-unit-like structures with NAL unit type values in the range of 48 to 63, inclusive, MUST NOT be passed to the decoder.
NAL单元类型值在0到47（包括0到47）范围内的NAL单元可以传递给解码器。NAL单元类型值在48到63（包括48到63）范围内的NAL单元类结构不得传递给解码器。
The receiver includes a receiver buffer, which is used to compensate for transmission delay jitter within individual RTP streams and across RTP streams, to reorder NAL units from transmission order to the NAL unit decoding order, and to recover the NAL unit decoding order in MRST or MRMT, when applicable. In this section, the receiver operation is described under the assumption that there is no transmission delay jitter within an RTP stream and across RTP streams. To make a difference from a practical receiver buffer that is also used for compensation of transmission delay jitter, the receiver buffer is hereafter called the de-packetization buffer in this section. Receivers should also prepare for transmission delay jitter; that is, either reserve separate buffers for transmission delay jitter buffering and de-packetization buffering or use a receiver buffer for both transmission delay jitter and de-packetization. Moreover, receivers should take transmission delay jitter into account in the buffering operation, e.g., by additional initial buffering before starting of decoding and playback.
接收机包括接收机缓冲器，其用于补偿单个RTP流内和跨RTP流的传输延迟抖动，将NAL单元从传输顺序重新排序为NAL单元解码顺序，并在适用时恢复MRST或MRMT中的NAL单元解码顺序。在该部分中，在RTP流内和跨RTP流没有传输延迟抖动的假设下描述接收机操作。为了区别于也用于补偿传输延迟抖动的实际接收器缓冲器，在本节中，接收器缓冲器在下文中称为去分组缓冲器。接收机还应为传输延迟抖动做好准备；也就是说，为传输延迟抖动缓冲和去分组缓冲保留单独的缓冲器，或者为传输延迟抖动和去分组缓冲使用接收机缓冲器。此外，接收器应在缓冲操作中考虑传输延迟抖动，例如，在开始解码和回放之前通过附加初始缓冲。
When sprop-max-don-diff is equal to 0 for all the received RTP streams, the de-packetization buffer size is zero bytes, and the process described in the remainder of this paragraph applies. When there is only one RTP stream received, the NAL units carried in the single RTP stream are directly passed to the decoder in their transmission order, which is identical to their decoding order. When there is more than one RTP stream received, the NAL units carried in the multiple RTP streams are passed to the decoder in their NTP timestamp order. When there are several NAL units of different RTP streams with the same NTP timestamp, the order to pass them to the decoder is their dependency order, where NAL units of a dependee RTP stream are passed to the decoder prior to the NAL units of the dependent RTP stream. When there are several NAL units of the same RTP stream with the same NTP timestamp, the order to pass them to the decoder is their transmission order.
当所有接收到的RTP流的sprop max don diff等于0时，反打包缓冲区大小为零字节，本段剩余部分中描述的过程适用。当仅接收到一个RTP流时，单个RTP流中携带的NAL单元以其传输顺序直接传递给解码器，这与它们的解码顺序相同。当接收到多个RTP流时，多个RTP流中携带的NAL单元以其NTP时间戳顺序传递给解码器。当存在具有相同NTP时间戳的不同RTP流的多个NAL单元时，将它们传递给解码器的顺序是它们的依赖顺序，其中依赖RTP流的NAL单元在依赖RTP流的NAL单元之前传递给解码器。当具有相同NTP时间戳的相同RTP流的多个NAL单元时，将它们传递给解码器的顺序是它们的传输顺序。
Informative note: The mapping between RTP and NTP timestamps is conveyed in RTCP SR packets. In addition, the mechanisms for faster media timestamp synchronization discussed in [RFC6051] may be used to speed up the acquisition of the RTP-to-wall-clock mapping.
资料性说明：RTP和NTP时间戳之间的映射在RTCP SR数据包中传输。此外，[RFC6051]中讨论的更快的媒体时间戳同步机制可用于加快RTP到墙壁时钟映射的获取。
When sprop-max-don-diff is greater than 0 for any the received RTP streams, the process described in the remainder of this section applies.
对于任何接收到的RTP流，当sprop max don diff大于0时，本节剩余部分中描述的过程适用。
There are two buffering states in the receiver: initial buffering and buffering while playing. Initial buffering starts when the reception is initialized. After initial buffering, decoding and playback are started, and the buffering-while-playing mode is used.
接收器中有两种缓冲状态：初始缓冲和播放时缓冲。初始缓冲在接收初始化时开始。初始缓冲后，开始解码和播放，并使用播放时缓冲模式。
Regardless of the buffering state, the receiver stores incoming NAL units, in reception order, into the de-packetization buffer. NAL units carried in RTP packets are stored in the de-packetization buffer individually, and the value of AbsDon is calculated and stored for each NAL unit. When MRST or MRMT is in use, NAL units of all RTP streams of a bitstream are stored in the same de-packetization buffer. When NAL units carried in any two RTP streams are available to be placed into the de-packetization buffer, those NAL units carried in the RTP stream that is lower in the dependency tree are placed into the buffer first. For example, if RTP stream A depends on RTP stream B, then NAL units carried in RTP stream B are placed into the buffer first.
无论缓冲状态如何，接收器都会按接收顺序将传入的NAL单元存储到反打包缓冲区中。RTP数据包中携带的NAL单元分别存储在解包缓冲区中，并且计算并存储每个NAL单元的AbsDon值。当使用MRST或MRMT时，一个比特流的所有RTP流的NAL单元存储在同一反打包缓冲区中。当任意两个RTP流中携带的NAL单元可放入反打包缓冲区时，在依赖关系树中较低的RTP流中携带的NAL单元将首先放入缓冲区。例如，如果RTP流A依赖于RTP流B，则RTP流B中携带的NAL单元首先被放入缓冲区。
Initial buffering lasts until condition A (the difference between the greatest and smallest AbsDon values of the NAL units in the de-packetization buffer is greater than or equal to the value of sprop-max-don-diff of the highest RTP stream) or condition B (the number of NAL units in the de-packetization buffer is greater than the value of sprop-depack-buf-nalus) is true.
初始缓冲持续到条件A（反打包缓冲区中NAL单元的最大和最小AbsDon值之间的差值大于或等于最高RTP流的sprop max don diff值）或条件B（反打包缓冲区中的NAL单元数大于sprop depack buf nalus的值）为真。
After initial buffering, whenever condition A or condition B is true, the following operation is repeatedly applied until both condition A and condition B become false:
初始缓冲后，每当条件A或条件B为真时，重复执行以下操作，直到条件A和条件B都变为假：
o The NAL unit in the de-packetization buffer with the smallest value of AbsDon is removed from the de-packetization buffer and passed to the decoder.
o 反打包缓冲区中具有最小值AbsDon的NAL单元从反打包缓冲区中移除并传递给解码器。
When no more NAL units are flowing into the de-packetization buffer, all NAL units remaining in the de-packetization buffer are removed from the buffer and passed to the decoder in the order of increasing AbsDon values.
当没有更多的NAL单元流入反打包缓冲区时，反打包缓冲区中剩余的所有NAL单元将从缓冲区中移除，并按照增加AbsDon值的顺序传递给解码器。
This section specifies the parameters that MAY be used to select optional features of the payload format and certain features or properties of the bitstream or the RTP stream. The parameters are specified here as part of the media type registration for the HEVC codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.
本节规定了可用于选择有效负载格式的可选特征以及比特流或RTP流的某些特征或属性的参数。此处指定的参数是HEVC编解码器的媒体类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[RFC4566]的映射。可以在其他地方定义等效参数，以便与不使用SDP的控制协议一起使用。
The media subtype for the HEVC codec is allocated from the IETF tree.
HEVC编解码器的媒体子类型是从IETF树中分配的。
The receiver MUST ignore any unrecognized parameter.
接收器必须忽略任何无法识别的参数。
Type name: video
类型名称：视频
Subtype name: H265
子类型名称：H265
Required parameters: none
所需参数：无
OPTIONAL parameters:
可选参数：
profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id:
配置文件空间、层标志、配置文件id、配置文件兼容性指示器、互操作约束和级别id：
These parameters indicate the profile, tier, default level, and some constraints of the bitstream carried by the RTP stream and all RTP streams the RTP stream depends on, or a specific set of the profile, tier, default level, and some constraints the receiver supports.
这些参数表示RTP流和RTP流所依赖的所有RTP流所承载的比特流的配置文件、层、默认级别和一些约束，或者表示接收机支持的配置文件、层、默认级别和一些约束的特定集合。
The profile and some constraints are indicated collectively by profile-space, profile-id, profile-compatibility-indicator, and interop-constraints. The profile specifies the subset of coding tools that may have been used to generate the bitstream or that the receiver supports.
概要文件和一些约束由概要文件空间、概要文件id、概要文件兼容性指示符和互操作约束共同表示。配置文件指定了编码工具的子集，这些工具可能已用于生成比特流或接收器支持的比特流。
Informative note: There are 32 values of profile-id, and there are 32 flags in profile-compatibility-indicator, each flag corresponding to one value of profile-id. According to HEVC version 1 in [HEVC], when more than one of the 32 flags is set for a bitstream, the bitstream would comply with all the profiles corresponding to the set flags. However, in a draft of HEVC version 2 in [HEVCv2], Subclause A.3.5, 19 Format Range Extensions profiles have been specified, all using the same value of profile-id (4), differentiated by some of the 48 bits in interop-constraints; this (rather unexpected way of profile signaling) means that one of the 32 flags may correspond to multiple profiles. To be able to support whatever HEVC extension profile that might be specified and indicated using profile-space, profile-id, profile-compatibility-indicator, and interop-constraints in the future, it would be safe to require symmetric use of these parameters in SDP offer/answer unless recv-sub-layer-id is included in the SDP answer for choosing one of the sub-layers offered.
资料性说明：配置文件id有32个值，配置文件兼容性指示器中有32个标志，每个标志对应一个配置文件id值。根据[HEVC]中的HEVC版本1，当为一个位流设置32个标志中的一个以上时，该位流将符合与设置标志对应的所有配置文件。然而，在[HEVCv2]中的HEVC第2版草案中，子条款a.3.5规定了19个格式范围扩展配置文件，所有配置文件都使用相同的配置文件id（4）值，由互操作约束中的48位中的一些进行区分；这（相当意外的配置文件信令方式）意味着32个标志之一可能对应于多个配置文件。为了能够支持将来使用配置文件空间、配置文件id、配置文件兼容性指示符和互操作约束指定和指示的任何HEVC扩展配置文件，在SDP报价/应答中要求对称使用这些参数是安全的，除非SDP应答中包含recv子层id，用于选择提供的子层之一。
The tier is indicated by tier-flag. The default level is indicated by level-id. The tier and the default level specify the limits on values of syntax elements or arithmetic combinations of values of syntax elements that are followed when generating the bitstream or that the receiver supports.
层由层标志指示。默认级别由level-id表示。层和默认级别指定生成比特流时所遵循的语法元素值或语法元素值的算术组合的限制，或接收器支持的限制。
A set of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id parameters ptlA is said to be consistent with another set of these parameters ptlB if any decoder that conforms to the profile, tier, level, and constraints indicated by ptlB can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by ptlA.
如果符合由ptlB指示的简档、层、层和约束的任何解码器可以解码符合该简档、层、层的任何比特流，则简档空间、层标志、简档id、简档兼容性指示符、互操作约束和层id参数ptlA的集合被称为与这些参数ptlB的另一集合一致，级别，以及ptlA指示的约束。
In SDP offer/answer, when the SDP answer does not include the recv-sub-layer-id parameter that is less than the sprop-sub-layer-id parameter in the SDP offer, the following applies:
在SDP报价/应答中，当SDP应答不包括小于SDP报价中sprop子层id参数的recv子层id参数时，以下情况适用：
o The profile-space, tier-flag, profile-id, profile-compatibility-indicator, and interop-constraints parameters MUST be used symmetrically, i.e., the value of each of these parameters in the offer MUST be the same as that in the answer, either explicitly signaled or implicitly inferred.
o 配置文件空间、层标志、配置文件id、配置文件兼容性指示符和互操作约束参数必须对称使用，即报价中每个参数的值必须与答案中的值相同，无论是显式表示还是隐式推断。
o The level-id parameter is changeable as long as the highest level indicated by the answer is either equal to or lower than that in the offer. Note that the highest level is indicated by level-id and max-recv-level-id together.
o 只要答案指示的最高级别等于或低于报价中的级别，级别id参数就可以更改。请注意，最高级别由级别id和最大recv级别id共同表示。
In SDP offer/answer, when the SDP answer does include the recv-sub-layer-id parameter that is less than the sprop-sub-layer-id parameter in the SDP offer, the set of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id parameters included in the answer MUST be consistent with that for the chosen sub-layer representation as indicated in the SDP offer, with the exception that the level-id parameter in the SDP answer is changeable as long as the highest level indicated by the answer is either lower than or equal to that in the offer.
在SDP报价/应答中，当SDP应答包含的recv子层id参数小于SDP报价中的sprop子层id参数时，配置文件空间集、层标志、配置文件id、配置文件兼容性指示器、互操作约束，答案中包含的级别id参数必须与SDP报价中所示的所选子层表示一致，但SDP答案中的级别id参数可以更改，只要答案中所示的最高级别低于或等于报价中的级别id参数。
More specifications of these parameters, including how they relate to the values of the profile, tier, and level syntax elements specified in [HEVC] are provided below.
下面提供了这些参数的更多规范，包括它们与[HEVC]中指定的概要文件、层和层语法元素的值的关系。
profile-space, profile-id:
配置文件空间，配置文件id:
The value of profile-space MUST be in the range of 0 to 3, inclusive. The value of profile-id MUST be in the range of 0 to 31, inclusive.
配置文件空间的值必须在0到3之间（包括0到3）。配置文件id的值必须在0到31之间（包括0到31）。
When profile-space is not present, a value of 0 MUST be inferred. When profile-id is not present, a value of 1 (i.e., the Main profile) MUST be inferred.
如果不存在配置文件空间，则必须推断值0。当配置文件id不存在时，必须推断值1（即主配置文件）。
When used to indicate properties of a bitstream, profile-space and profile-id are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_profile_space, general_profile_idc, sub_layer_profile_space[j], and sub_layer_profile_idc[j] are specified in [HEVC]:
当用于指示比特流的属性时，配置文件空间和配置文件id源自SPS或VPS NAL单元中的配置文件、层和层语法元素，如下所示，其中[HEVC]中指定了通用配置文件空间、通用配置文件idc、子层配置文件空间[j]和子层配置文件idc[j]：
If the RTP stream is the highest RTP stream, the following applies:
如果RTP流是最高的RTP流，则以下情况适用：
o profile-space = general_profile_space o profile-id = general_profile_idc
o 配置文件空间=常规配置文件空间o配置文件id=常规配置文件idc
Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
否则（RTP流是dependee RTP流），以下内容适用，j是sprop子层id参数的值：
o profile-space = sub_layer_profile_space[j] o profile-id = sub_layer_profile_idc[j]
o 配置文件空间=子层配置文件空间[j]o配置文件id=子层配置文件空间[j]
tier-flag, level-id:
层标志，层id：
The value of tier-flag MUST be in the range of 0 to 1, inclusive. The value of level-id MUST be in the range of 0 to 255, inclusive.
tier flag的值必须在0到1的范围内（包括0到1）。级别id的值必须在0到255（包括0到255）之间。
If the tier-flag and level-id parameters are used to indicate properties of a bitstream, they indicate the tier and the highest level the bitstream complies with.
如果层标志和级别id参数用于指示位流的属性，则它们指示位流所遵循的层和最高级别。
If the tier-flag and level-id parameters are used for capability exchange, the following applies. If max-recv-level-id is not present, the default level defined by level-id indicates the highest level the codec wishes to support. Otherwise, max-recv-level-id indicates the highest level the codec supports for receiving. For either receiving or sending, all levels that are lower than the highest level supported MUST also be supported.
如果层标志和层id参数用于能力交换，则以下情况适用。如果max recv level id不存在，则level id定义的默认级别表示编解码器希望支持的最高级别。否则，max recv level id表示编解码器支持接收的最高级别。对于接收或发送，还必须支持低于支持的最高级别的所有级别。
If no tier-flag is present, a value of 0 MUST be inferred; if no level-id is present, a value of 93 (i.e., level 3.1) MUST be inferred.
如果不存在层标志，则必须推断值0；如果不存在级别id，则必须推断值93（即级别3.1）。
When used to indicate properties of a bitstream, the tier-flag and level-id parameters are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_tier_flag, general_level_idc, sub_layer_tier_flag[j], and sub_layer_level_idc[j] are specified in [HEVC]:
当用于指示比特流的属性时，tier flag和level id参数是从SPS或VPS NAL单元中的概要文件、tier和level语法元素派生出来的，如下所示，其中[HEVC]中指定了general_tier_flag、general_level_idc、sub_layer_tier_flag[j]和sub_layer_level_idc[j]：
If the RTP stream is the highest RTP stream, the following applies:
如果RTP流是最高的RTP流，则以下情况适用：
o tier-flag = general_tier_flag o level-id = general_level_idc
o 层标志=通用层标志o级别id=通用层标志
Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
否则（RTP流是dependee RTP流），以下内容适用，j是sprop子层id参数的值：
o tier-flag = sub_layer_tier_flag[j] o level-id = sub_layer_level_idc[j]
o 层标志=子层层标志[j]o层id=子层标志[j]
interop-constraints:
互操作限制：
A base16 [RFC4648] (hexadecimal) representation of six bytes of data, consisting of progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, and reserved_zero_44bits.
六字节数据的一种base16[RFC4648]（十六进制）表示法，由渐进式源标志、交错式源标志、非压缩式约束标志、仅帧约束标志和保留的零位44位组成。
If the interop-constraints parameter is not present, the following MUST be inferred:
如果互操作约束参数不存在，则必须推断以下内容：
o progressive_source_flag = 1 o interlaced_source_flag = 0 o non_packed_constraint_flag = 1 o frame_only_constraint_flag = 1 o reserved_zero_44bits = 0
o 渐进式\u源\u标志=1 o交错式\u源\u标志=0 o非压缩\u约束\u标志=1 o仅帧\u约束\u标志=1 o保留\u零\u 44位=0
When the interop-constraints parameter is used to indicate properties of a bitstream, the following applies, where general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, sub_layer_progressive_source_flag[j], sub_layer_interlaced_source_flag[j], sub_layer_non_packed_constraint_flag[j], sub_layer_frame_only_constraint_flag[j], and sub_layer_reserved_zero_44bits[j] are specified in [HEVC]:
当interop constraints参数用于指示位流的属性时，以下情况适用，其中general_progressive_source_标志、general_Intersected_source_标志、general_non_packed_constraint_标志、general_non_packed_constraint_标志、general_frame_only_constraint_标志、general_reserved_0_44位，[HEVC]中指定了子层逐行源标志[j]、子层交错源标志[j]、子层非压缩约束标志[j]、子层仅帧约束标志[j]和子层保留零位44位[j]：
If the RTP stream is the highest RTP stream, the following applies:
如果RTP流是最高的RTP流，则以下情况适用：
o progressive_source_flag = general_progressive_source_flag
o 渐进源标志=通用渐进源标志
o interlaced_source_flag = general_interlaced_source_flag
o 交错源标志=一般交错源标志
o non_packed_constraint_flag = general_non_packed_constraint_flag
o 非压缩约束标志=通用非压缩约束标志
o frame_only_constraint_flag = general_frame_only_constraint_flag
o 仅帧\u约束\u标志=常规\u仅帧\u约束\u标志
o reserved_zero_44bits = general_reserved_zero_44bits
o 保留零位=一般保留零位=44位
Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
否则（RTP流是dependee RTP流），以下内容适用，j是sprop子层id参数的值：
o progressive_source_flag = sub_layer_progressive_source_flag[j]
o 渐进源标志=子层渐进源标志[j]
o interlaced_source_flag = sub_layer_interlaced_source_flag[j]
o 交错源标志=子层交错源标志[j]
o non_packed_constraint_flag = sub_layer_non_packed_constraint_flag[j]
o 非压缩约束标志=子层非压缩约束标志[j]
o frame_only_constraint_flag = sub_layer_frame_only_constraint_flag[j]
o 仅帧约束标志=子层约束标志[j]
o reserved_zero_44bits = sub_layer_reserved_zero_44bits[j]
o 保留零位=子层保留零位44位[j]
Using interop-constraints for capability exchange results in a requirement on any bitstream to be compliant with the interop-constraints.
对功能交换使用互操作约束会导致任何比特流都需要符合互操作约束。
profile-compatibility-indicator:
配置文件兼容性指示器：
A base16 [RFC4648] representation of four bytes of data.
四字节数据的base16[RFC4648]表示。
When profile-compatibility-indicator is used to indicate properties of a bitstream, the following applies, where general_profile_compatibility_flag[j] and sub_layer_profile_compatibility_flag[i][j] are specified in [HEVC]:
当配置文件兼容性指示符用于指示比特流的属性时，以下内容适用，其中[HEVC]中指定了通用配置文件兼容性标志[j]和子层配置文件兼容性标志[i][j]：
The profile-compatibility-indicator in this case indicates additional profiles to the profile defined by profile-space, profile-id, and interop-constraints the bitstream conforms to. A decoder that conforms to any of all the profiles the bitstream conforms to would be capable of decoding the bitstream. These additional profiles are defined by profile-space, each set bit of profile-compatibility-indicator, and interop-constraints.
在这种情况下，配置文件兼容性指示符指示由配置文件空间、配置文件id和位流符合的互操作约束定义的配置文件的其他配置文件。符合比特流所符合的所有简档中的任何简档的解码器将能够解码比特流。这些额外的配置文件由配置文件空间、配置文件兼容性指示符的每个设置位和互操作约束定义。
If the RTP stream is the highest RTP stream, the following applies for each value of j in the range of 0 to 31, inclusive:
如果RTP流是最高的RTP流，则以下适用于0到31（包括0到31）范围内j的每个值：
o bit j of profile-compatibility-indicator = general_profile_compatibility_flag[j]
o 配置文件兼容性指示符的第j位=通用配置文件兼容性标志[j]
Otherwise (the RTP stream is a dependee RTP stream), the following applies for i equal to sprop-sub-layer-id and for each value of j in the range of 0 to 31, inclusive:
否则（RTP流是dependee RTP流），以下适用于i等于sprop子层id，以及0到31范围内的每个j值，包括：
o bit j of profile-compatibility-indicator = sub_layer_profile_compatibility_flag[i][j]
o 配置文件兼容性指示符的第j位=子层配置文件兼容性标志[i][j]
Using profile-compatibility-indicator for capability exchange results in a requirement on any bitstream to be compliant with the profile-compatibility-indicator. This is intended to handle cases where any future HEVC profile is defined as an intersection of two or more profiles.
将配置文件兼容性指示符用于功能交换会导致要求任何比特流符合配置文件兼容性指示符。这旨在处理任何未来HEVC纵断面被定义为两个或多个纵断面相交的情况。
If this parameter is not present, this parameter defaults to the following: bit j, with j equal to profile-id, of profile-compatibility-indicator is inferred to be equal to 1, and all other bits are inferred to be equal to 0.
如果此参数不存在，则此参数默认为以下值：配置文件兼容性指示符的位j（j等于配置文件id）被推断为等于1，所有其他位被推断为等于0。
sprop-sub-layer-id:
存储过程子层id：
This parameter MAY be used to indicate the highest allowed value of TID in the bitstream. When not present, the value of sprop-sub-layer-id is inferred to be equal to 6.
此参数可用于指示位流中允许的最高TID值。如果不存在，则sprop子层id的值将被推断为等于6。
The value of sprop-sub-layer-id MUST be in the range of 0 to 6, inclusive.
sprop子层id的值必须在0到6的范围内（包括0到6）。
recv-sub-layer-id:
recv子层id：
This parameter MAY be used to signal a receiver's choice of the offered or declared sub-layer representations in the sprop-vps. The value of recv-sub-layer-id indicates the TID of the highest sub-layer of the bitstream that a receiver supports. When not present, the value of recv-sub-layer-id is inferred to be equal to the value of the sprop-sub-layer-id parameter in the SDP offer.
该参数可用于向接收器发送信号，表明其选择sprop vps中提供的或声明的子层表示。recv sub layer id的值表示接收机支持的比特流的最高子层的TID。当不存在时，recv子层id的值被推断为等于SDP报价中sprop子层id参数的值。
The value of recv-sub-layer-id MUST be in the range of 0 to 6, inclusive.
recv子层id的值必须在0到6的范围内（包括0到6）。
max-recv-level-id:
最大recv级别id：
This parameter MAY be used to indicate the highest level a receiver supports. The highest level the receiver supports is equal to the value of max-recv-level-id divided by 30.
此参数可用于指示接收器支持的最高级别。接收器支持的最高电平等于最大recv电平id值除以30。
The value of max-recv-level-id MUST be in the range of 0 to 255, inclusive.
max recv level id的值必须在0到255（包括0到255）之间。
When max-recv-level-id is not present, the value is inferred to be equal to level-id.
当max recv level id不存在时，将推断该值等于level-id。
max-recv-level-id MUST NOT be present when the highest level the receiver supports is not higher than the default level.
当接收器支持的最高级别不高于默认级别时，max recv级别id不得出现。
tx-mode:
发送模式：
This parameter indicates whether the transmission mode is SRST, MRST, or MRMT.
此参数指示传输模式是SRST、MRST还是MRMT。
The value of tx-mode MUST be equal to "SRST", "MRST" or "MRMT". When not present, the value of tx-mode is inferred to be equal to "SRST".
tx模式的值必须等于“SRST”、“MRST”或“MRMT”。当不存在时，tx模式的值被推断为等于“SRST”。
If the value is equal to "MRST", MRST MUST be in use. Otherwise, if the value is equal to "MRMT", MRMT MUST be in use. Otherwise (the value is equal to "SRST"), SRST MUST be in use.
如果该值等于“MRST”，则必须使用MRST。否则，如果该值等于“MRMT”，则必须使用MRMT。否则（该值等于“SRST”），必须使用SRST。
The value of tx-mode MUST be equal to "MRST" for all RTP streams in an MRST.
对于MRST中的所有RTP流，tx模式的值必须等于“MRST”。
The value of tx-mode MUST be equal to "MRMT" for all RTP streams in an MRMT.
对于MRMT中的所有RTP流，tx模式的值必须等于“MRMT”。
sprop-vps:
sprop vps：
This parameter MAY be used to convey any video parameter set NAL unit of the bitstream for out-of-band transmission of video parameter sets. The parameter MAY also be used for capability exchange and to indicate sub-stream characteristics (i.e., properties of sub-layer representations as defined in [HEVC]). The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the video parameter set NAL units as specified in Section 7.3.2.1 of [HEVC].
该参数可用于将任何视频参数集传送到比特流的任何单元，以用于视频参数集的带外传输。该参数还可用于能力交换和指示子流特征（即[HEVC]中定义的子层表示的属性）。参数值为[HEVC]第7.3.2.1节规定的视频参数集NAL单位的base64[RFC4648]表示的逗号分隔（'，'）列表。
The sprop-vps parameter MAY contain one or more than one video parameter set NAL unit. However, all other video parameter sets contained in the sprop-vps parameter MUST be consistent with the first video parameter set in the sprop-vps parameter. A video parameter set vpsB is said to be consistent with another video parameter set vpsA if any decoder that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_idc, inclusive, in the first profile_tier_level( ) syntax structure in vpsA can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_idc, inclusive, in the first profile_tier_level( ) syntax structure in vpsB.
sprop vps参数可以包含一个或多个视频参数集。但是，sprop vps参数中包含的所有其他视频参数集必须与sprop vps参数中设置的第一个视频参数一致。视频参数集vpsB被称为与另一视频参数集vpsA一致，如果任何解码器符合第一个配置文件层（）中从语法元素general_profile_空间到语法元素general_level_idc（含）的12字节数据所指示的配置文件、层、级别和约束vpsA中的语法结构可以解码符合vpsB中第一个profile_tier_level（）语法结构中从语法元素general_profile_space到语法元素general_level_idc（含）的12字节数据所指示的配置文件、层、级别和约束的任何比特流。
sprop-sps:
sprop sps：
This parameter MAY be used to convey sequence parameter set NAL units of the bitstream for out-of-band transmission of sequence parameter sets. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the sequence parameter set NAL units as specified in Section 7.3.2.2 of [HEVC].
该参数可用于传送用于序列参数集的带外传输的比特流的所有单元的序列参数集。参数值为[HEVC]第7.3.2.2节规定的序列参数集NAL单位的base64[RFC4648]表示的逗号分隔（'，'）列表。
sprop-pps:
sprop pps：
This parameter MAY be used to convey picture parameter set NAL units of the bitstream for out-of-band transmission of picture parameter sets. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the picture parameter set NAL units as specified in Section 7.3.2.3 of [HEVC].
该参数可用于传送用于图片参数集的带外传输的比特流的所有单元的图片参数集。参数值为[HEVC]第7.3.2.3节规定的图片参数集NAL单位的base64[RFC4648]表示的逗号分隔（'，'）列表。
sprop-sei:
sprop sei：
This parameter MAY be used to convey one or more SEI messages that describe bitstream characteristics. When present, a decoder can rely on the bitstream characteristics that are described in the SEI messages for the entire duration of the session, independently from the persistence scopes of the SEI messages as specified in [HEVC].
该参数可用于传送描述比特流特征的一个或多个SEI消息。当存在时，解码器可以在会话的整个持续时间内依赖SEI消息中描述的比特流特征，独立于[HEVC]中指定的SEI消息的持久性范围。
The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of SEI NAL units as specified in Section 7.3.2.4 of [HEVC].
参数值为[HEVC]第7.3.2.4节中规定的SEI NAL单位的base64[RFC4648]表示的逗号分隔（'，'）列表。
Informative note: Intentionally, no list of applicable or inapplicable SEI messages is specified here. Conveying certain SEI messages in sprop-sei may be sensible in some application scenarios and meaningless in others. However, a few examples are described below:
资料性说明：此处无意指定适用或不适用的SEI消息列表。在sprop SEI中传输某些SEI消息在某些应用程序场景中可能是合理的，而在其他应用程序场景中可能是无意义的。然而，下面描述了几个示例：
1) In an environment where the bitstream was created from film-based source material, and no splicing is going to occur during the lifetime of the session, the film grain characteristics SEI message or the tone mapping information SEI message are likely meaningful, and sending them in sprop-sei rather than in the bitstream at each entry point may help with saving bits and allows one to configure the renderer only once, avoiding unwanted artifacts.
1) 在比特流是从基于胶片的源材料创建的，并且在会话的生存期内不会发生拼接的环境中，胶片纹理特征SEI消息或色调映射信息SEI消息可能是有意义的，在每个入口点以sprop sei而不是位流的形式发送它们可能有助于节省位，并允许只配置一次渲染器，从而避免不必要的瑕疵。
2) The structure of pictures information SEI message in sprop-sei can be used to inform a decoder of information on the NAL unit types, picture-order count values, and prediction dependencies of a sequence of pictures. Having such knowledge can be helpful for error recovery.
2) sprop SEI中的图片信息SEI消息的结构可用于通知解码器关于NAL单元类型、图片顺序计数值和图片序列的预测相关性的信息。掌握这些知识有助于错误恢复。
3) Examples for SEI messages that would be meaningless to be conveyed in sprop-sei include the decoded picture hash SEI message (it is close to impossible that all decoded pictures have the same hashtag), the display orientation SEI message when the device is a handheld device (as the display orientation may change when the handheld device is turned around), or the filler payload SEI message (as there is no point in just having more bits in SDP).
3) 在sprop SEI中传输的SEI消息的示例包括解码图片散列SEI消息（几乎不可能所有解码图片都具有相同的散列标签）、当设备是手持设备时的显示方向SEI消息（当手持设备转动时，显示方向可能会改变）或填充有效负载SEI消息（因为SDP中没有更多位的意义）。
max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc:
最大lsr、最大lps、最大cpb、最大dpb、最大br、最大tr、最大tc：
These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. The highest level (specified by max-recv-level-id) MUST be the highest that the receiver is fully capable of supporting. max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc MAY be used to indicate capabilities of the receiver that extend the required capabilities of the highest level, as specified below.
这些参数可用于向接收机实现的能力发送信号。这些参数不得用于任何其他目的。最高电平（由max recv level id指定）必须是接收器完全能够支持的最高电平。max lsr、max lps、max cpb、max dpb、max br、max tr和max tc可用于指示接收机扩展最高级别所需能力的能力，如下所述。
When more than one parameter from the set (max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc) is present, the receiver MUST support all signaled capabilities simultaneously. For example, if both max-lsr and max-br are present, the
当集合中存在多个参数（最大lsr、最大lps、最大cpb、最大dpb、最大br、最大tr、最大tc）时，接收器必须同时支持所有信号功能。例如，如果存在最大lsr和最大br，则
highest level with the extension of both the picture rate and bitrate is supported. That is, the receiver is able to decode bitstreams in which the luma sample rate is up to max-lsr (inclusive), the bitrate is up to max-br (inclusive), the coded picture buffer size is derived as specified in the semantics of the max-br parameter below, and the other properties comply with the highest level specified by max-recv-level-id.
支持扩展图片速率和比特率的最高级别。也就是说，接收机能够解码其中luma采样率高达max lsr（包括），比特率高达max br（包括），编码图片缓冲区大小按照下面max br参数的语义中的指定导出，并且其他属性符合max-recv-level-id指定的最高级别。
Informative note: When the OPTIONAL media type parameters are used to signal the properties of a bitstream, and max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc are not present, the values of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id must always be such that the bitstream complies fully with the specified profile, tier, and level.
资料性说明：当使用可选媒体类型参数来表示比特流的属性，并且不存在max lsr、max lps、max cpb、max dpb、max br、max tr和max tc时，配置文件空间、层标志、配置文件id、配置文件兼容性指示符、互操作约束、，级别id必须始终确保比特流完全符合指定的配置文件、层和级别。
max-lsr:
最大lsr：
The value of max-lsr is an integer indicating the maximum processing rate in units of luma samples per second. The max-lsr parameter signals that the receiver is capable of decoding video at a higher rate than is required by the highest level.
max lsr的值是一个整数，表示以luma采样数/秒为单位的最大处理速率。max lsr参数表示接收器能够以高于最高级别要求的速率解码视频。
When max-lsr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxLumaSR value in Table A-2 of [HEVC] for the highest level is replaced with the value of max-lsr. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the highest level.
当发送max lsr信号时，接收器必须能够解码符合最高级别的比特流，但[HEVC]表A-2中最高级别的MaxLumaSR值替换为max lsr值除外。发送者可以使用此知识以高于最高级别指示的图片速率发送给定大小的图片。
When not present, the value of max-lsr is inferred to be equal to the value of MaxLumaSR given in Table A-2 of [HEVC] for the highest level.
当不存在时，最大lsr值被推断为等于[HEVC]表A-2中给出的最高水平的最大LUMASR值。
The value of max-lsr MUST be in the range of MaxLumaSR to 16 * MaxLumaSR, inclusive, where MaxLumaSR is given in Table A-2 of [HEVC] for the highest level.
max lsr的值必须在MaxLumaSR到16*MaxLumaSR（包括16*MaxLumaSR）的范围内，其中MaxLumaSR在[HEVC]的表A-2中给出了最高级别。
max-lps:
最大lps：
The value of max-lps is an integer indicating the maximum picture size in units of luma samples. The max-lps parameter signals that the receiver is capable of decoding larger picture sizes than are required by the highest level. When max-lps is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the
max lps的值是一个整数，表示以luma样本为单位的最大图片大小。max lps参数表示接收器能够解码比最高级别所需更大的图片大小。当发送max lps信号时，接收器必须能够解码符合最高级别的比特流，但以下情况除外：
MaxLumaPS value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-lps. Senders MAY use this knowledge to send larger pictures at a proportionally lower picture rate than is indicated in the highest level.
[HEVC]表A-1中最高级别的MaxLumaPS值替换为max lps值。发送者可以使用此知识以低于最高级别的比例发送较大的图片。
When not present, the value of max-lps is inferred to be equal to the value of MaxLumaPS given in Table A-1 of [HEVC] for the highest level.
当不存在时，最大lps的值被推断为等于[HEVC]表A-1中给出的最高水平的MaxLumaPS的值。
The value of max-lps MUST be in the range of MaxLumaPS to 16 * MaxLumaPS, inclusive, where MaxLumaPS is given in Table A-1 of [HEVC] for the highest level.
max lps的值必须在MaxLumaPS到16*MaxLumaPS（包括16*MaxLumaPS）的范围内，其中[HEVC]的表A-1中给出了最高级别的MaxLumaPS。
max-cpb:
最大cpb：
The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of CpbBrVclFactor bits for the VCL HRD parameters and in units of CpbBrNalFactor bits for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]. The max-cpb parameter signals that the receiver has more memory than the minimum amount of coded picture buffer memory required by the highest level. When max-cpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxCPB value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-cpb. Senders MAY use this knowledge to construct coded bitstreams with greater variation of bitrate than can be achieved with the MaxCPB value in Table A-1 of [HEVC].
max cpb的值是一个整数，表示VCL HRD参数的最大编码图片缓冲区大小（以CpbBrVclFactor位为单位）和NAL HRD参数的最大编码图片缓冲区大小（以CpbBrNalFactor位为单位），其中CpbBrVclFactor和CpbBrNalFactor在[HEVC]第A.4节中定义。max cpb参数表示接收器的内存大于最高级别所需的最小编码图片缓冲内存量。当发送最大cpb信号时，接收器必须能够解码符合最高级别的比特流，但[HEVC]表A-1中最高级别的最大cpb值替换为最大cpb值的情况除外。发送方可以利用这一知识构造比特率变化比[HEVC]表A-1中的MaxCPB值更大的编码比特流。
When not present, the value of max-cpb is inferred to be equal to the value of MaxCPB given in Table A-1 of [HEVC] for the highest level.
当不存在时，最大cpb值被推断为等于[HEVC]表A-1中给出的最高水平的最大cpb值。
The value of max-cpb MUST be in the range of MaxCPB to 16 * MaxCPB, inclusive, where MaxLumaCPB is given in Table A-1 of [HEVC] for the highest level.
最大cpb的值必须在MaxCPB到16*MaxCPB的范围内（包括16*MaxCPB），其中[HEVC]的表A-1中给出了最高级别的MaxLumaCPB。
Informative note: The coded picture buffer is used in the hypothetical reference decoder (Annex C of [HEVC]). The use of the hypothetical reference decoder is recommended in HEVC encoders to verify that the produced bitstream conforms to the standard and to control the output bitrate. Thus, the coded picture buffer is conceptually independent of any other potential buffers in the receiver, including de-packetization and de-jitter buffers. The coded picture buffer need not be implemented in decoders as specified in Annex C of [HEVC], but rather standard-compliant decoders
资料性说明：编码图片缓冲器用于假设参考解码器（HEVC的附录C）。建议在HEVC编码器中使用假设参考解码器，以验证生成的比特流是否符合标准并控制输出比特率。因此，编码图片缓冲器在概念上独立于接收机中的任何其他潜在缓冲器，包括去分组和去抖动缓冲器。编码图片缓冲器不需要在[HEVC]附录C中规定的解码器中实现，而是在符合标准的解码器中实现
can have any buffering arrangements provided that they can decode standard-compliant bitstreams. Thus, in practice, the input buffer for a video decoder can be integrated with de-packetization and de-jitter buffers of the receiver.
可以具有任何缓冲安排，前提是它们可以解码符合标准的比特流。因此，在实践中，视频解码器的输入缓冲器可以与接收机的解分组和解抖动缓冲器集成。
max-dpb:
最大dpb：
The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units decoded pictures at the MaxLumaPS for the highest level, i.e., the number of decoded pictures at the maximum picture size defined by the highest level. The value of max-dpb MUST be in the range of 1 to 16, respectively. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by default, which is MaxDpbPicBuf as defined in [HEVC] (equal to 6). When max-dpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxDpbPicBuff value defined in [HEVC] as 6 is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded pictures (MaxDpbSize) in its decoded picture buffer:
max dpb的值是一个整数，表示最高级别的maxlumap处解码图片的最大解码图片缓冲区大小（单位为解码图片），即最高级别定义的最大图片大小处的解码图片数量。最大dpb的值必须分别在1到16之间。max dpb参数表示接收器的内存大于默认情况下所需的最小解码图片缓冲内存量，即[HEVC]中定义的MaxDpbPicBuf（等于6）。当发送max dpb信号时，接收器必须能够解码符合最高级别的比特流，但[HEVC]中定义为6的MaxDpbPicBuff值被替换为max dpb值除外。因此，发送max dpb信号的接收器必须能够在其解码图片缓冲器中存储以下数量的解码图片（MaxDpbSize）：
if( PicSizeInSamplesY <= ( MaxLumaPS >> 2 ) )
MaxDpbSize = Min( 4 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( MaxLumaPS >> 1 ) )
MaxDpbSize = Min( 2 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( ( 3 * MaxLumaPS ) >> 2
) )
MaxDpbSize = Min( (4 * max-dpb) / 3, 16 )
else
MaxDpbSize = max-dpb
if( PicSizeInSamplesY <= ( MaxLumaPS >> 2 ) )
MaxDpbSize = Min( 4 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( MaxLumaPS >> 1 ) )
MaxDpbSize = Min( 2 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( ( 3 * MaxLumaPS ) >> 2
) )
MaxDpbSize = Min( (4 * max-dpb) / 3, 16 )
else
MaxDpbSize = max-dpb
Wherein MaxLumaPS given in Table A-1 of [HEVC] for the highest level and PicSizeInSamplesY is the current size of each decoded picture in units of luma samples as defined in [HEVC].
其中，[HEVC]表A-1中给出的最高级别和PicSizeInSamplesY的MaxLumaPS是每个解码图片的当前大小，单位为[HEVC]中定义的luma样本。
The value of max-dpb MUST be greater than or equal to the value of MaxDpbPicBuf (i.e., 6) as defined in [HEVC]. Senders MAY use this knowledge to construct coded bitstreams with improved compression.
max dpb的值必须大于或等于[HEVC]中定义的MaxDpbPicBuf（即6）。发送者可以使用此知识构造具有改进压缩的编码比特流。
When not present, the value of max-dpb is inferred to be equal to the value of MaxDpbPicBuf (i.e., 6) as defined in [HEVC].
当不存在时，最大dpb的值被推断为等于[HEVC]中定义的最大dpbpicbuf的值（即6）。
Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The
资料性说明：添加此参数主要是为了补充ITU-T建议H.245中的类似代码点，以便于信令网关设计。这个
decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-packetization and de-jitter buffers.
解码的图片缓冲区存储重建的样本。解码图片缓冲区的大小与RTP中使用的缓冲区之间没有关系，尤其是去分组和去抖动缓冲区。
max-br:
最大br：
The value of max-br is an integer indicating the maximum video bitrate in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC].
max br的值是一个整数，表示VCL HRD参数的最大视频比特率，以每秒CpbBrVclFactor比特为单位，NAL HRD参数的最大视频比特率以每秒CpbBrNalFactor比特为单位，其中CpbBrVclFactor和CpbBrNalFactor在[HEVC]第A.4节中定义。
The max-br parameter signals that the video decoder of the receiver is capable of decoding video at a higher bitrate than is required by the highest level.
max br参数表示接收器的视频解码器能够以高于最高级别要求的比特率解码视频。
When max-br is signaled, the video codec of the receiver MUST be able to decode bitstreams that conform to the highest level, with the following exceptions in the limits specified by the highest level:
当发出max br信号时，接收器的视频编解码器必须能够解码符合最高级别的比特流，但在最高级别指定的限制内有以下例外情况：
o The value of max-br replaces the MaxBR value in Table A-2 of [HEVC] for the highest level.
o 最高等级的最大br值替换[HEVC]表A-2中的最大br值。
o When the max-cpb parameter is not present, the result of the following formula replaces the value of MaxCPB in Table A-1 of [HEVC]:
o 当最大cpb参数不存在时，以下公式的结果将替换[HEVC]表A-1中的最大cpb值：
(MaxCPB of the highest level) * max-br / (MaxBR of the highest level)
（最高级别的最大CPB）*最大br/（最高级别的最大br）
For example, if a receiver signals capability for Main profile Level 2 with max-br equal to 2000, this indicates a maximum video bitrate of 2000 kbits/sec for VCL HRD parameters, a maximum video bitrate of 2200 kbits/sec for NAL HRD parameters, and a CPB size of 2000000 bits (2000000 / 1500000 * 1500000).
例如，如果接收器向主配置文件级别2发送信号，最大br等于2000，则表示VCL HRD参数的最大视频比特率为2000 kbits/sec，NAL HRD参数的最大视频比特率为2200 kbits/sec，CPB大小为2000000比特（2000000/1500000*1500000）。
Senders MAY use this knowledge to send higher bitrate video as allowed in the level definition of Annex A of [HEVC] to achieve improved video quality.
发送方可以使用此知识发送[HEVC]附录A中级别定义允许的更高比特率视频，以实现更高的视频质量。
When not present, the value of max-br is inferred to be equal to the value of MaxBR given in Table A-2 of [HEVC] for the highest level.
当不存在时，最大br值被推断为等于[HEVC]表A-2中给出的最高级别的最大br值。
The value of max-br MUST be in the range of MaxBR to 16 * MaxBR, inclusive, where MaxBR is given in Table A-2 of [HEVC] for the highest level.
max br的值必须在MaxBR到16*MaxBR（包括16*MaxBR）的范围内，其中最高级别的MaxBR在[HEVC]的表A-2中给出。
Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The assumption that the network is capable of handling such bitrates at any given time cannot be made from the value of this parameter. In particular, no conclusion can be drawn that the signaled bitrate is possible under congestion control constraints.
资料性说明：添加此参数主要是为了补充ITU-T建议H.245中的类似代码点，以便于信令网关设计。根据该参数的值，不能假设网络能够在任何给定时间处理此类比特率。特别地，不能得出在拥塞控制约束下信号比特率是可能的结论。
max-tr:
最大tr：
The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than the value allowed by the highest level.
max tr的值是一个整数，表示磁贴行的最大数量。max tr参数表示接收器能够解码具有比最高级别允许的值更多瓦片行数的视频。
When max-tr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tr.
当发送max tr信号时，接收器必须能够解码符合最高级别的比特流，但[HEVC]表A-1中最高级别的MaxTileRows值被替换为max-tr值除外。
Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than the value allowed by the highest level.
发件人可以使用此知识发送图片，使用的平铺行数超过最高级别允许的值。
When not present, the value of max-tr is inferred to be equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level.
当不存在时，max tr的值被推断为等于[HEVC]表A-1中给出的最高级别的MaxTileRows的值。
The value of max-tr MUST be in the range of MaxTileRows to 16 * MaxTileRows, inclusive, where MaxTileRows is given in Table A-1 of [HEVC] for the highest level.
max tr的值必须在MaxTileRows到16*MaxTileRows（含16*MaxTileRows）的范围内，其中[HEVC]的表A-1中给出了最高级别的MaxTileRows。
max-tc:
最大温度：
The value of max-tc is an integer indication the maximum number of tile columns. The max-tc parameter signals that the receiver is capable of decoding video with a larger number of tile columns than the value allowed by the highest level.
max tc的值是一个整数，表示磁贴列的最大数量。max tc参数表示接收器能够解码具有比最高级别允许的值更多瓦片列数的视频。
When max-tc is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileCols value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tc.
当发送max tc信号时，接收器必须能够解码符合最高级别的比特流，但[HEVC]表A-1中最高级别的MaxTileCols值被替换为max tc值的情况除外。
Senders MAY use this knowledge to send pictures utilizing a larger number of tile columns than the value allowed by the highest level.
发送者可以使用此知识，使用比最高级别允许的值更多的平铺列发送图片。
When not present, the value of max-tc is inferred to be equal to the value of MaxTileCols given in Table A-1 of [HEVC] for the highest level.
当不存在时，最大tc值被推断为等于[HEVC]表A-1中给出的最高水平的最大TileCols值。
The value of max-tc MUST be in the range of MaxTileCols to 16 * MaxTileCols, inclusive, where MaxTileCols is given in Table A-1 of [HEVC] for the highest level.
最大tc的值必须在MaxTileCols到16*MaxTileCols（含16*MaxTileCols）的范围内，其中[HEVC]的表A-1中给出了最高级别的MaxTileCols。
max-fps:
最大fps：
The value of max-fps is an integer indicating the maximum picture rate in units of pictures per 100 seconds that can be effectively processed by the receiver. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of processing video effectively at the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br.
max fps的值是一个整数，表示接收机可以有效处理的最大图片速率，单位为每100秒的图片。max fps参数可用于发出接收器具有约束的信号，其中接收器不能以最高电平暗示的全画面速率有效地处理视频，并且当存在时，参数max lsr、max lps和max br中的一个或多个。
The value of max-fps is not necessarily the picture rate at which the maximum picture size can be sent, it constitutes a constraint on maximum picture rate for all resolutions.
max fps的值不一定是可以发送最大图片大小的图片速率，它构成了对所有分辨率的最大图片速率的约束。
Informative note: The max-fps parameter is semantically different from max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps is used to signal a constraint, lowering the maximum picture rate from what is implied by other parameters.
资料性说明：max fps参数在语义上与max lsr、max lps、max cpb、max dpb、max br、max tr和max tc不同，因为max fps用于表示约束，从而降低了其他参数所暗示的最大图片速率。
The encoder MUST use a picture rate equal to or less than this value. In cases where the max-fps parameter is absent, the encoder is free to choose any picture rate according to the highest level and any signaled optional parameters.
编码器必须使用等于或小于此值的图片速率。在没有最大fps参数的情况下，编码器可以根据最高级别和任何信号可选参数自由选择任何图片速率。
The value of max-fps MUST be smaller than or equal to the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br.
max fps的值必须小于或等于最高级别所暗示的全图速率，以及存在时的一个或多个参数max lsr、max lps和max br。
sprop-max-don-diff:
sprop最大不差异：
If tx-mode is equal to "SRST" and there is no NAL unit naluA that is followed in transmission order by any NAL unit preceding naluA in decoding order (i.e., the transmission order of the NAL units is the same as the decoding order), the value of this parameter MUST be equal to 0.
如果tx模式等于“SRST”，并且没有NAL单元naluA在传输顺序上被解码顺序上在naluA之前的任何NAL单元跟随（即，NAL单元的传输顺序与解码顺序相同），则该参数的值必须等于0。
Otherwise, if tx-mode is equal to "MRST" or "MRMT", the decoding order of the NAL units of all the RTP streams is the same as the NAL unit transmission order and the NAL unit output order, the value of this parameter MUST be equal to either 0 or 1.
否则，如果tx mode等于“MRST”或“MRMT”，则所有RTP流的NAL单元的解码顺序与NAL单元传输顺序和NAL单元输出顺序相同，则该参数的值必须等于0或1。
Otherwise, if tx-mode is equal to "MRST" or "MRMT" and the decoding order of the NAL units of all the RTP streams is the same as the NAL unit transmission order but not the same as the NAL unit output order, the value of this parameter MUST be equal to 1.
否则，如果tx模式等于“MRST”或“MRMT”，并且所有RTP流的NAL单元的解码顺序与NAL单元传输顺序相同，但与NAL单元输出顺序不同，则该参数的值必须等于1。
Otherwise, this parameter specifies the maximum absolute difference between the decoding order number (i.e., AbsDon) values of any two NAL units naluA and naluB, where naluA follows naluB in decoding order and precedes naluB in transmission order.
否则，此参数指定任意两个NAL单元naluA和naluB的解码顺序号（即AbsDon）值之间的最大绝对差值，其中naluA在解码顺序上紧跟在naluB之后，在传输顺序上紧跟在naluB之前。
The value of sprop-max-don-diff MUST be an integer in the range of 0 to 32767, inclusive.
sprop max don diff的值必须是介于0到32767（包括0到32767）之间的整数。
When not present, the value of sprop-max-don-diff is inferred to be equal to 0.
不存在时，sprop max don diff的值被推断为等于0。
sprop-depack-buf-nalus:
sprop depack buf nalus：
This parameter specifies the maximum number of NAL units that precede a NAL unit in transmission order and follow the NAL unit in decoding order.
此参数指定以传输顺序在NAL单元之前、以解码顺序在NAL单元之后的NAL单元的最大数量。
The value of sprop-depack-buf-nalus MUST be an integer in the range of 0 to 32767, inclusive.
sprop depack buf nalus的值必须是介于0到32767（包括0到32767）之间的整数。
When not present, the value of sprop-depack-buf-nalus is inferred to be equal to 0.
如果不存在，则sprop depack buf nalus的值被推断为等于0。
When sprop-max-don-diff is present and greater than 0, this parameter MUST be present and the value MUST be greater than 0.
存在sprop max don diff且大于0时，此参数必须存在且值必须大于0。
sprop-depack-buf-bytes:
存储过程退包buf字节：
This parameter signals the required size of the de-packetization buffer in units of bytes. The value of the parameter MUST be greater than or equal to the maximum buffer occupancy (in units of bytes) of the de-packetization buffer as specified in Section 6.
此参数以字节为单位表示反打包缓冲区的所需大小。参数的值必须大于或等于第6节中规定的反打包缓冲区的最大缓冲区占用率（以字节为单位）。
The value of sprop-depack-buf-bytes MUST be an integer in the range of 0 to 4294967295, inclusive.
sprop depack buf字节的值必须是介于0到4294967295（包括0和4294967295）之间的整数。
When sprop-max-don-diff is present and greater than 0, this parameter MUST be present and the value MUST be greater than 0. When not present, the value of sprop-depack-buf-bytes is inferred to be equal to 0.
存在sprop max don diff且大于0时，此参数必须存在且值必须大于0。如果不存在，则sprop depack buf字节的值被推断为等于0。
Informative note: The value of sprop-depack-buf-bytes indicates the required size of the de-packetization buffer only. When network jitter can occur, an appropriately sized jitter buffer has to be available as well.
资料性说明：sprop depack buf字节的值仅表示反打包缓冲区所需的大小。当网络抖动可能发生时，还必须提供大小合适的抖动缓冲区。
depack-buf-cap:
卸下buf cap：
This parameter signals the capabilities of a receiver implementation and indicates the amount of de-packetization buffer space in units of bytes that the receiver has available for reconstructing the NAL unit decoding order from NAL units carried in one or more RTP streams. A receiver is able to handle any RTP stream, and all RTP streams the RTP stream depends on, when present, for which the value of the sprop-depack-buf-bytes parameter is smaller than or equal to this parameter.
该参数表示接收机实现的能力，并指示接收机可用于从一个或多个RTP流中携带的NAL单元重构NAL单元解码顺序的以字节为单位的去分组缓冲区空间量。接收器能够处理任何RTP流，并且RTP流所依赖的所有RTP流（当存在时）sprop depack buf bytes参数的值小于或等于此参数。
When not present, the value of depack-buf-cap is inferred to be equal to 4294967295. The value of depack-buf-cap MUST be an integer in the range of 1 to 4294967295, inclusive.
如果不存在，则推断退包buf cap的值等于4294967295。depack buf cap的值必须是介于1到4294967295（包括1和4294967295）之间的整数。
Informative note: depack-buf-cap indicates the maximum possible size of the de-packetization buffer of the receiver only, without allowing for network jitter.
资料性说明：depack buf cap仅表示接收器的反打包缓冲区的最大可能大小，不考虑网络抖动。
sprop-segmentation-id:
存储过程分段id：
This parameter MAY be used to signal the segmentation tools present in the bitstream and that can be used for parallelization. The value of sprop-segmentation-id MUST be an integer in the range of 0 to 3, inclusive. When not present, the value of sprop-segmentation-id is inferred to be equal to 0.
此参数可用于向位流中存在的分段工具发送信号，并可用于并行化。sprop分段id的值必须是0到3（包括0到3）范围内的整数。如果不存在，则sprop分段id的值被推断为等于0。
When sprop-segmentation-id is equal to 0, no information about the segmentation tools is provided. When sprop-segmentation-id is equal to 1, it indicates that slices are present in the bitstream. When sprop-segmentation-id is equal to 2, it indicates that tiles are present in the bitstream. When sprop-segmentation-id is equal to 3, it indicates that WPP is used in the bitstream.
当sprop分段id等于0时，将不提供有关分段工具的信息。当sprop segmentation id等于1时，表示位流中存在切片。当sprop segmentation id等于2时，表示位流中存在分片。当sprop segmentation id等于3时，表示位流中使用了WPP。
sprop-spatial-segmentation-idc:
sprop空间分段：
A base16 [RFC4648] representation of the syntax element min_spatial_segmentation_idc as specified in [HEVC]. This parameter MAY be used to describe parallelization capabilities of the bitstream.
[HEVC]中规定的语法元素min_spatial_segmentation_idc的base16[RFC4648]表示形式。该参数可用于描述比特流的并行化能力。
dec-parallel-cap:
dec平行帽：
This parameter MAY be used to indicate the decoder's additional decoding capabilities given the presence of tools enabling parallel decoding, such as slices, tiles, and WPP, in the bitstream. The decoding capability of the decoder may vary with the setting of the parallel decoding tools present in the bitstream, e.g., the size of the tiles that are present in a bitstream. Therefore, multiple capability points may be provided, each indicating the minimum required decoding capability that is associated with a parallelism requirement, which is a requirement on the bitstream that enables parallel decoding.
该参数可用于指示解码器的附加解码能力，前提是比特流中存在支持并行解码的工具，例如切片、分片和WPP。解码器的解码能力可随位流中存在的并行解码工具的设置而变化，例如，位流中存在的分片的大小。因此，可以提供多个能力点，每个能力点指示与并行性要求相关联的最小所需解码能力，并行性要求是比特流上实现并行解码的要求。
Each capability point is defined as a combination of 1) a parallelism requirement, 2) a profile (determined by profile-space and profile-id), 3) a highest level, and 4) a maximum processing rate, a maximum picture size, and a maximum video bitrate that may be equal to or greater than that determined by the highest level. The parameter's syntax in ABNF [RFC5234] is as follows:
每个能力点定义为1）并行性要求、2）配置文件（由配置文件空间和配置文件id确定）、3）最高级别和4）最大处理速率、最大图片大小和可能等于或大于最高级别确定的最大视频比特率的组合。ABNF[RFC5234]中的参数语法如下：
dec-parallel-cap = "dec-parallel-cap={" cap-point *(","
cap-point) "}"
dec-parallel-cap = "dec-parallel-cap={" cap-point *(","
cap-point) "}"
cap-point = ("w" / "t") ":" spatial-seg-idc 1*(";"
cap-parameter)
cap-point = ("w" / "t") ":" spatial-seg-idc 1*(";"
cap-parameter)
spatial-seg-idc = 1*4DIGIT ; (1-4095)
spatial-seg-idc = 1*4DIGIT ; (1-4095)
cap-parameter = tier-flag / level-id / max-lsr
/ max-lps / max-br
cap-parameter = tier-flag / level-id / max-lsr
/ max-lps / max-br
tier-flag = "tier-flag" EQ ("0" / "1")
tier-flag = "tier-flag" EQ ("0" / "1")
level-id = "level-id" EQ 1*3DIGIT ; (0-255)
level-id = "level-id" EQ 1*3DIGIT ; (0-255)
max-lsr = "max-lsr" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615)
max lsr=“max lsr”等式1*20位；(0- 18,446,744,073,709,551,615)
max-lps = "max-lps" EQ 1*10DIGIT ; (0-4,294,967,295)
max-lps = "max-lps" EQ 1*10DIGIT ; (0-4,294,967,295)
max-br = "max-br" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615)
max br=“max br”等式1*20位；(0- 18,446,744,073,709,551,615)
EQ = "="
EQ=“=”
The set of capability points expressed by the dec-parallel-cap parameter is enclosed in a pair of curly braces ("{}"). Each set of two consecutive capability points is separated by a comma (','). Within each capability point, each set of two consecutive parameters, and, when present, their values, is separated by a semicolon (';').
由dec parallel cap参数表示的能力点集包含在一对花括号（“{}”）中。每组两个连续的能力点用逗号（'，'）分隔。在每个功能点中，每组两个连续参数以及它们的值（如果存在）用分号（“；”）分隔。
The profile of all capability points is determined by profile-space and profile-id, which are outside the dec-parallel-cap parameter.
所有能力点的配置文件由配置文件空间和配置文件id确定，它们位于dec parallel cap参数之外。
Each capability point starts with an indication of the parallelism requirement, which consists of a parallel tool type, which may be equal to 'w' or 't', and a decimal value of the spatial-seg-idc parameter. When the type is 'w', the capability point is valid only for H.265 bitstreams with WPP in use, i.e., entropy_coding_sync_enabled_flag equal to 1. When the type is 't', the capability point is valid only for H.265 bitstreams with WPP not in use (i.e., entropy_coding_sync_enabled_flag equal to 0). The capability-point is valid only for H.265 bitstreams with min_spatial_segmentation_idc equal to or greater than spatial-seg-idc.
每个能力点以平行度要求的指示开始，该指示由平行工具类型（可能等于“w”或“t”）和空间seg idc参数的十进制值组成。当类型为“w”时，能力点仅对使用WPP的H.265比特流有效，即熵_编码_同步_启用_标志等于1。当类型为“t”时，能力点仅对WPP未使用的H.265比特流有效（即，熵_编码_同步_启用_标志等于0）。能力点仅对最小空间分段idc等于或大于空间分段idc的H.265比特流有效。
After the parallelism requirement indication, each capability point continues with one or more pairs of parameter and value in any order for any of the following parameters:
在并行性要求指示后，每个能力点继续以一对或多对参数和值的任何顺序表示以下任何参数：
o tier-flag o level-id o max-lsr o max-lps o max-br
o 层标志o层id o最大lsr o最大lps o最大br
At most, one occurrence of each of the above five parameters is allowed within each capability point.
在每个能力点内，上述五个参数最多允许出现一次。
The values of dec-parallel-cap.tier-flag and dec-parallel-cap.level-id for a capability point indicate the highest level of the capability point. The values of dec-parallel-cap.max-lsr, dec-parallel-cap.max-lps, and dec-parallel-cap.max-br for a capability point indicate the maximum processing rate in units of luma samples per second, the maximum picture size in units of luma samples, and the maximum video bitrate (in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]).
能力点的dec-parallel-cap.tier-flag和dec-parallel-cap.level-id值表示能力点的最高级别。能力点的dec-parallel-cap.max-lsr、dec-parallel-cap.max-lps和dec-parallel-cap.max-br的值表示以luma采样为单位每秒的最大处理速率、以luma采样为单位的最大图片大小和最大视频比特率（VCL HRD参数以每秒CpbBrVclFactor位为单位，NAL HRD参数以每秒CpbBrNalFactor位为单位，其中[HEVC]第A.4节中定义了CpbBrVclFactor和CpbBrNalFactor）。
When not present, the value of dec-parallel-cap.tier-flag is inferred to be equal to the value of tier-flag outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.level-id is inferred to be equal to the value of max-recv-level-id outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.max-lsr, dec-parallel-cap.max-lps, or dec-parallel-cap.max-br is inferred to be equal to the value of max-lsr, max-lps, or max-br, respectively, outside the dec-parallel-cap parameter.
如果不存在，dec-parallel-cap.tier-flag的值将被推断为等于dec parallel cap参数外部的tier flag的值。当不存在时，dec-parallel-cap.level-id的值被推断为等于dec parallel cap参数之外的max recv level id的值。如果不存在，则推断dec-parallel-cap.max-lsr、dec-parallel-cap.max-lps或dec-parallel-cap.max-br的值分别等于dec parallel cap参数之外的max lsr、max lps或max br的值。
The general decoding capability, expressed by the set of parameters outside of dec-parallel-cap, is defined as the capability point that is determined by the following combination of parameters: 1) the parallelism requirement corresponding to the value of sprop-segmentation-id equal to 0 for a bitstream, 2) the profile determined by profile-space, profile-id, profile-compatibility-indicator, and interop-constraints, 3) the tier and the highest level determined by tier-flag and max-recv-level-id, and 4) the maximum processing rate, the maximum picture size, and the maximum video bitrate determined by the highest level. The general decoding capability MUST NOT be included as one of the set of capability points in the dec-parallel-cap parameter.
一般解码能力由dec parallel cap之外的一组参数表示，定义为通过以下参数组合确定的能力点：1）对应于等于0的sprop分段id值的并行性要求（对于比特流），2）由配置文件空间确定的配置文件，配置文件id、配置文件兼容性指示符和互操作约束，3）由tier flag和max recv level id确定的层和最高级别，以及4）由最高级别确定的最大处理速率、最大图片大小和最大视频比特率。一般解码能力不得作为dec parallel cap参数中的一组能力点包括在内。
For example, the following parameters express the general decoding capability of 720p30 (Level 3.1) plus an additional decoding capability of 1080p30 (Level 4) given that the spatially largest tile or slice used in the bitstream is equal to or less than 1/3 of the picture size:
例如，以下参数表示720p30（级别3.1）的一般解码能力加上1080p30（级别4）的附加解码能力，前提是比特流中使用的空间上最大的块或片等于或小于图片大小的1/3：
a=fmtp:98 level-id=93;dec-parallel-cap={t:8;level- id=120}
a=fmtp:98 level-id=93;dec-parallel-cap={t:8;level- id=120}
For another example, the following parameters express an additional decoding capability of 1080p30, using dec-parallel-cap.max-lsr and dec-parallel-cap.max-lps, given that WPP is used in the bitstream:
对于另一个示例，以下参数表示1080p30的额外解码能力，使用dec-parallel-cap.max-lsr和dec-parallel-cap.max-lps，假设比特流中使用了WPP：
a=fmtp:98 level-id=93;dec-parallel-cap={w:8;
max-lsr=62668800;max-lps=2088960}
a=fmtp:98 level-id=93;dec-parallel-cap={w:8;
max-lsr=62668800;max-lps=2088960}
Informative note: When min_spatial_segmentation_idc is present in a bitstream and WPP is not used, [HEVC] specifies that there is no slice or no tile in the bitstream containing more than 4 * PicSizeInSamplesY / ( min_spatial_segmentation_idc + 4 ) luma samples.
资料性说明：当比特流中存在min_spatial_segmentation_idc且未使用WPP时，[HEVC]指定在包含超过4*PicSizeInSamplesY/（min_spatial_segmentation_idc+4）luma样本的比特流中不存在切片或平铺。
include-dph:
包括dph：
This parameter is used to indicate the capability and preference to utilize or include Decoded Picture Hash (DPH) SEI messages (see Section D.3.19 of [HEVC]) in the bitstream. DPH SEI messages can be used to detect picture corruption so the receiver can request picture repair, see Section 8. The value is a comma-separated list of hash types that is supported or requested to be used, each hash type provided as an unsigned integer value (0-255), with the hash types listed from most preferred to the least preferred. Example: "include-dph=0,2", which indicates the capability for MD5 (most preferred) and Checksum (less preferred). If the parameter is not included or the value contains no hash types, then no capability to utilize DPH SEI messages is assumed. Note that DPH SEI messages MAY still be included in the bitstream even when there is no declaration of capability to use them, as in general SEI messages do not affect the normative decoding process and decoders are allowed to ignore SEI messages.
该参数用于指示在比特流中利用或包括解码图片散列（DPH）SEI消息（见[HEVC]第D.3.19节）的能力和偏好。DPH SEI消息可用于检测图片损坏，以便接收器可以请求图片修复，请参阅第8节。该值是受支持或请求使用的哈希类型的逗号分隔列表，每个哈希类型作为无符号整数值（0-255）提供，哈希类型从最优先到最不优先列出。示例：“include dph=0,2”，表示MD5（首选）和校验和（首选）的能力。如果未包含参数或该值不包含哈希类型，则假定无法利用DPH SEI消息。注意，即使在没有使用它们的能力声明的情况下，DPH SEI消息仍然可以包括在比特流中，因为通常SEI消息不会影响标准解码过程，并且允许解码器忽略SEI消息。
Encoding considerations:
编码注意事项：
This type is only defined for transfer via RTP (RFC 3550).
此类型仅定义为通过RTP（RFC 3550）传输。
Security considerations:
安全考虑：
See Section 9 of RFC 7798.
见RFC 7798第9节。
Published specification:
已发布的规范：
Please refer to RFC 7798 and its Section 12.
请参考RFC 7798及其第12节。
Additional information: None
其他信息：无
File extensions: none
文件扩展名：无
Macintosh file type code: none
Macintosh文件类型代码：无
Object identifier or OID: none
对象标识符或OID:无
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Ye-Kui Wang (yekui.wang@gmail.com)
王业奎（王业奎）。wang@gmail.com)
Intended usage: COMMON
预期用途：普通
Author: See Authors' Addresses section of RFC 7798.
作者：参见RFC 7798的作者地址部分。
Change controller:
更改控制器：
IETF Audio/Video Transport Payloads working group delegated from the IESG.
IESG授权的IETF音频/视频传输有效载荷工作组。
The receiver MUST ignore any parameter unspecified in this memo.
接收方必须忽略本备忘录中未指定的任何参数。
The media type video/H265 string is mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
媒体类型video/H265字符串映射到会话描述协议（SDP）[RFC4566]中的字段，如下所示：
o The media name in the "m=" line of SDP MUST be video.
o SDP的“m=”行中的媒体名称必须是视频。
o The encoding name in the "a=rtpmap" line of SDP MUST be H265 (the media subtype).
o SDP的“a=rtpmap”行中的编码名称必须是H265（媒体子类型）。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o “a=rtpmap”行中的时钟频率必须为90000。
o The OPTIONAL parameters profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, sprop-sub-layer-id, recv-sub-layer-id, max-recv-level-id, tx-mode,
o 可选参数profile space、profile id、tier flag、level id、interop约束、profile compatibility indicator、sprop子层id、recv子层id、max recv level id、tx mode、，
max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc, max-fps, sprop-max-don-diff, sprop-depack-buf-nalus, sprop-depack-buf-bytes, depack-buf-cap, sprop-segmentation-id, sprop-spatial-segmentation-idc, dec-parallel-cap, and include-dph, when present, MUST be included in the "a=fmtp" line of SDP. This parameter is expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
最大lsr、最大lps、最大cpb、最大dpb、最大br、最大tr、最大tc、最大fps、sprop max don diff、sprop depack buf nalus、sprop depack buf buf字节、depack buf cap、sprop分段id、sprop空间分段idc、dec并行cap和include dph（如果存在）必须包含在SDP的“a=fmtp”行中。此参数表示为媒体类型字符串，形式为参数=值对的分号分隔列表。
o The OPTIONAL parameters sprop-vps, sprop-sps, and sprop-pps, when present, MUST be included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]. For a particular media format (i.e., RTP payload type), sprop-vps sprop-sps, or sprop-pps MUST NOT be both included in the "a=fmtp" line of SDP and conveyed using the "fmtp" source attribute. When included in the "a=fmtp" line of SDP, these parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. When conveyed in the "a=fmtp" line of SDP for a particular payload type, the parameters sprop-vps, sprop-sps, and sprop-pps MUST be applied to each SSRC with the payload type. When conveyed using the "fmtp" source attribute, these parameters are only associated with the given source and payload type as parts of the "fmtp" source attribute.
o 可选参数sprop vps、sprop sps和sprop pps（如果存在）必须包含在SDP的“a=fmtp”行中，或使用[RFC5576]第6.3节中规定的“fmtp”源属性进行传输。对于特定媒体格式（即RTP有效负载类型），sprop vps sprop SP或sprop pps不得同时包含在SDP的“a=fmtp”行中，且不得使用“fmtp”源属性进行传输。当包含在SDP的“a=fmtp”行中时，这些参数表示为媒体类型字符串，以分号分隔的参数=值对列表的形式。当在SDP的“a=fmtp”行中传输特定有效负载类型时，参数sprop vps、sprop sps和sprop pps必须应用于具有有效负载类型的每个SSRC。当使用“fmtp”源属性进行传输时，这些参数仅与作为“fmtp”源属性一部分的给定源和有效负载类型相关联。
Informative note: Conveyance of sprop-vps, sprop-sps, and sprop-pps using the "fmtp" source attribute allows for out-of-band transport of parameter sets in topologies like Topo-Video-switch-MCU as specified in [RFC7667].
资料性说明：使用“fmtp”源属性传输sprop VP、sprop SP和sprop PP允许带外传输拓扑（如[RFC7667]中规定的拓扑视频开关MCU）中的参数集。
An example of media representation in SDP is as follows:
SDP中的媒体表示示例如下：
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1;
sprop-vps=<video parameter sets data>
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1;
sprop-vps=<video parameter sets data>
When HEVC is offered over RTP using SDP in an offer/answer model [RFC3264] for negotiation for unicast usage, the following limitations and rules apply:
当HEVC通过RTP使用提供/应答模型[RFC3264]中的SDP提供，以协商单播使用时，以下限制和规则适用：
o The parameters identifying a media format configuration for HEVC are profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, and tx-mode. These media configuration parameters, except level-id, MUST be used symmetrically when the answerer does not include recv-sub-layer-id
o 标识HEVC媒体格式配置的参数包括配置文件空间、配置文件id、层标志、级别id、互操作约束、配置文件兼容性指示符和发送模式。当应答器不包括recv子层id时，这些介质配置参数（级别id除外）必须对称使用
in the answer for the media format (payload type) or the included recv-sub-layer-id is equal to sprop-sub-layer-id in the offer. The answerer MUST:
在回答中，媒体格式（有效负载类型）或包含的recv子层id等于报价中的sprop子层id。回答者必须：
1) maintain all configuration parameters with the values remaining the same as in the offer for the media format (payload type), with the exception that the value of level-id is changeable as long as the highest level indicated by the answer is not higher than that indicated by the offer;
1) 保持所有配置参数的值与媒体格式（有效负载类型）报价中的值相同，但级别id的值可以更改，只要答案指示的最高级别不高于报价指示的最高级别；
2) include in the answer the recv-sub-layer-id parameter, with a value less than the sprop-sub-layer-id parameter in the offer, for the media format (payload type), and maintain all configuration parameters with the values being the same as signaled in the sprop-vps for the chosen sub-layer representation, with the exception that the value of level-id is changeable as long as the highest level indicated by the answer is not higher than the level indicated by the sprop-vps in offer for the chosen sub-layer representation; or
2) 在回答中包括recv子层id参数，其值小于报价中的sprop子层id参数，用于媒体格式（有效负载类型），并维护所有配置参数，其值与所选子层表示的sprop vps中的信号相同，除了级别id的值可以更改外，只要答案指示的最高级别不高于所选子层表示的sprop vps在报价中指示的级别；或
3) remove the media format (payload type) completely (when one or more of the parameter values are not supported).
3) 完全删除媒体格式（负载类型）（当一个或多个参数值不受支持时）。
Informative note: The above requirement for symmetric use does not apply for level-id, and does not apply for the other bitstream or RTP stream properties and capability parameters.
资料性说明：上述对称使用要求不适用于级别id，也不适用于其他比特流或RTP流属性和功能参数。
o The profile-compatibility-indicator, when offered as sendonly, describes bitstream properties. The answerer MAY accept an RTP payload type even if the decoder is not capable of handling the profile indicated by the profile-space, profile-id, and interop-constraints parameters, but capable of any of the profiles indicated by the profile-space, profile-compatibility-indicator, and interop-constraints. However, when the profile-compatibility-indicator is used in a recvonly or sendrecv media description, the bitstream using this RTP payload type is required to conform to all profiles indicated by profile-space, profile-compatibility-indicator, and interop-constraints.
o 配置文件兼容性指示符（当作为sendonly提供时）描述位流属性。应答者可以接受RTP有效载荷类型，即使解码器不能处理由简档空间、简档id和互操作约束参数指示的简档，但能够处理由简档空间、简档兼容性指示符和互操作约束指示的任何简档。但是，当配置文件兼容性指示符用于RecVoOnly或sendrecv媒体描述时，使用此RTP有效负载类型的比特流需要符合由配置文件空间、配置文件兼容性指示符和互操作约束指示的所有配置文件。
o To simplify handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [RFC3264].
o 为了简化这些配置的处理和匹配，响应中还应使用报价中使用的相同RTP有效负载类型编号，如[RFC3264]中所述。
o The same RTP payload type number used in the offer for the media subtype H265 MUST be used in the answer when the answer includes recv-sub-layer-id. When the answer does not include recv-sub-layer-id, the answer MUST NOT contain a payload type number used
o 当回答包括recv-sub-layer-id时，回答中必须使用与介质子类型H265报价中使用的相同RTP有效负载类型号。当回答不包括recv-sub-layer-id时，回答中不得包含使用的有效负载类型号
in the offer for the media subtype H265 unless the configuration is exactly the same as in the offer or the configuration in the answer only differs from that in the offer with a different value of level-id. The answer MAY contain the recv-sub-layer-id parameter if an HEVC bitstream contains multiple operation points (using temporal scalability and sub-layers) and sprop-vps is included in the offer where information of sub-layers are present in the first video parameter set contained in sprop-vps. If the sprop-vps is provided in an offer, an answerer MAY select a particular operation point indicated in the first video parameter set contained in sprop-vps. When the answer includes a recv-sub-layer-id that is less than a sprop-sub-layer-id in the offer, all video parameter sets contained in the sprop-vps parameter in the SDP answer and all video parameter sets sent in-band for either the offerer-to-answerer direction or the answerer-to-offerer direction MUST be consistent with the first video parameter set in the sprop-vps parameter of the offer (see the semantics of sprop-vps in Section 7.1 of this document on one video parameter set being consistent with another video parameter set), and the bitstream sent in either direction MUST conform to the profile, tier, level, and constraints of the chosen sub-layer representation as indicated by the first profile_tier_level( ) syntax structure in the first video parameter set in the sprop-vps parameter of the offer.
在媒体子类型H265的报价中，除非配置与报价中的配置完全相同，或者答案中的配置仅与报价中的配置不同，具有不同的级别id值。如果HEVC比特流包含多个操作点，则答案可能包含recv子层id参数（使用时间可伸缩性和子层）并且sprop vps包括在报价中，其中子层的信息存在于sprop vps中包含的第一个视频参数集中。如果报价中提供了sprop vps，则应答者可以选择sprop vps中包含的第一个视频参数集中指示的特定操作点。当应答包括recv子层id that小于报价中的sprop子层id，SDP应答中sprop vps参数中包含的所有视频参数集，以及为报价方至应答方方向或应答方至报价方方向在频带内发送的所有视频参数集，必须与报价的sprop vps参数中的第一个视频参数集一致（参见本文件第7.1节中关于一个视频参数集与另一个视频参数集一致的sprop VP的语义），并且向任一方向发送的比特流必须符合所选子层表示的配置文件、层、级别和约束，如第一个配置文件\u tier\u level（）在报价的sprop vps参数中设置的第一个视频参数中的语法结构。
Informative note: When an offerer receives an answer that does not include recv-sub-layer-id, it has to compare payload types not declared in the offer based on the media type (i.e., video/H265) and the above media configuration parameters with any payload types it has already declared. This will enable it to determine whether the configuration in question is new or if it is equivalent to configuration already offered, since a different payload type number may be used in the answer. The ability to perform operation point selection enables a receiver to utilize the temporal scalable nature of an HEVC bitstream.
资料性说明：当报价人收到不包括recv子层id的答复时，必须根据媒体类型（即视频/H265）和上述媒体配置参数，将报价中未声明的有效负载类型与其已声明的任何有效负载类型进行比较。这将使其能够确定所讨论的配置是新的还是与已经提供的配置等效，因为答案中可能会使用不同的有效负载类型编号。执行操作点选择的能力使得接收机能够利用HEVC比特流的时间可伸缩性。
o The parameters sprop-max-don-diff, sprop-depack-buf-nalus, and sprop-depack-buf-bytes describe the properties of an RTP stream, and all RTP streams the RTP stream depends on, when present, that the offerer or the answerer is sending for the media format configuration. This differs from the normal usage of the offer/answer parameters: normally such parameters declare the properties of the bitstream or RTP stream that the offerer or the answerer is able to receive. When dealing with HEVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered.
o 参数sprop max don diff、sprop depack buf nalus和sprop depack buf bytes描述RTP流的属性，并且RTP流所依赖的所有RTP流（当存在时）取决于提供方或应答方正在发送的媒体格式配置。这与提供/应答参数的正常用法不同：通常，这些参数声明提供方或应答方能够接收的比特流或RTP流的属性。与HEVC打交道时，报价人假设应答人能够接收使用所提供配置编码的媒体。
Informative note: The above parameters apply for any RTP stream and all RTP streams the RTP stream depends on, when present, sent by a declaring entity with the same configuration. In other words, the applicability of the above parameters to RTP streams depends on the source endpoint. Rather than being bound to the payload type, the values may have to be applied to another payload type when being sent, as they apply for the configuration.
资料性说明：上述参数适用于任何RTP流以及RTP流所依赖的所有RTP流（当存在时），由具有相同配置的声明实体发送。换句话说，上述参数对RTP流的适用性取决于源端点。这些值在发送时可能必须应用于另一个有效负载类型，而不是绑定到有效负载类型，因为它们适用于配置。
o The capability parameters max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc MAY be used to declare further capabilities of the offerer or answerer for receiving. These parameters MUST NOT be present when the direction attribute is sendonly.
o 能力参数max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr和max-tc可用于声明报价人或应答人的进一步接收能力。当方向属性为sendonly时，这些参数不得存在。
o The capability parameter max-fps MAY be used to declare lower capabilities of the offerer or answerer for receiving. The parameters MUST NOT be present when the direction attribute is sendonly.
o 能力参数max fps可用于声明报价人或应答人较低的接收能力。当方向属性为sendonly时，参数不得存在。
o The capability parameter dec-parallel-cap MAY be used to declare additional decoding capabilities of the offerer or answerer for receiving. Upon receiving such a declaration of a receiver, a sender MAY send a bitstream to the receiver utilizing those capabilities under the assumption that the bitstream fulfills the parallelism requirement. A bitstream that is sent based on choosing a capability point with parallel tool type 'w' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 1 and min_spatial_segmentation_idc equal to or larger than dec-parallel-cap.spatial-seg-idc of the capability point. A bitstream that is sent based on choosing a capability point with parallel tool type 't' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 0 and min_spatial_segmentation_idc equal to or larger than dec-parallel-cap.spatial-seg-idc of the capability point.
o 能力参数dec parallel cap可用于声明报价人或应答人用于接收的额外解码能力。在接收到接收机的这种声明时，发送方可以在比特流满足并行性要求的假设下，利用这些能力向接收机发送比特流。基于从dec parallel cap选择并行工具类型为“w”的能力点发送的比特流必须具有熵_coding_sync_enabled_标志等于1，最小空间分割_idc等于或大于该能力点的dec-parallel-cap.spatial-seg-idc。基于从dec parallel cap选择并行工具类型为“t”的能力点发送的比特流必须具有熵_coding_sync_enabled_标志等于0，最小空间分割_idc等于或大于该能力点的dec-parallel-cap.spatial-seg-idc。
o An offerer has to include the size of the de-packetization buffer, sprop-depack-buf-bytes, as well as sprop-max-don-diff and sprop-depack-buf-nalus, in the offer for an interleaved HEVC bitstream or for the MRST or MRMT transmission mode when sprop-max-don-diff is greater than 0 for at least one of the RTP streams. To enable the offerer and answerer to inform each other about their capabilities for de-packetization buffering in receiving RTP streams, both parties are RECOMMENDED to include depack-buf-cap. For interleaved RTP streams or in MRST or MRMT, it is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown.
o 当至少一个RTP流的sprop max don diff大于0时，报价人必须在交织HEVC比特流或MRST或MRMT传输模式的报价中包括反打包缓冲区、sprop depack buf字节以及sprop max don diff和sprop depack buf nalus的大小。为了使报价人和应答人能够相互告知其在接收RTP流时的反打包缓冲能力，建议双方包括退包buf cap。对于交错的RTP流或MRST或MRMT，还建议考虑当接收机的能力未知时提供具有不同缓冲要求的多个有效载荷类型。
o The capability parameter include-dph MAY be used to declare the capability to utilize decoded picture hash SEI messages and which types of hashes in any HEVC RTP streams received by the offerer or answerer.
o capability参数include dph可用于声明利用解码图片散列SEI消息的能力，以及报价人或应答人接收的任何HEVC RTP流中的散列类型。
o The sprop-vps, sprop-sps, or sprop-pps, when present (included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]), are used for out-of-band transport of the parameter sets (VPS, SPS, or PPS, respectively).
o sprop VP、sprop SP或sprop PP（当存在时）（包括在SDP的“a=fmtp”行中或使用[RFC5576]第6.3节中规定的“fmtp”源属性传输）用于参数集（分别为vps、SP或pps）的带外传输。
o The answerer MAY use either out-of-band or in-band transport of parameter sets for the bitstream it is sending, regardless of whether out-of-band parameter sets transport has been used in the offerer-to-answerer direction. Parameter sets included in an answer are independent of those parameter sets included in the offer, as they are used for decoding two different bitstreams, one from the answerer to the offerer and the other in the opposite direction. In case some RTP streams are sent before the SDP offer/answer settles down, in-band parameter sets MUST be used for those RTP stream parts sent before the SDP offer/answer.
o 应答器可以对其发送的比特流使用参数集的带外传输或带内传输，而不管是否在提供方到应答方的方向上使用了带外参数集传输。答案中包含的参数集独立于报价中包含的参数集，因为它们用于解码两个不同的比特流，一个从应答方到报价方，另一个在相反方向。如果某些RTP流在SDP报价/应答确定之前发送，则必须为SDP报价/应答之前发送的RTP流部分使用带内参数集。
o The following rules apply to transport of parameter set in the offerer-to-answerer direction.
o 以下规则适用于将报价人方向的参数集传输到应答人方向。
+ An offer MAY include sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters is present in the offer, then only in-band transport of parameter sets is used.
+ 报价可能包括sprop VP、sprop SP和/或sprop PP。如果报价中没有这些参数，则仅使用参数集的带内传输。
+ If the level to use in the offerer-to-answerer direction is equal to the default level in the offer, the answerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams. Otherwise, the answerer MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) and the offerer MUST transmit parameter sets in-band.
+ 如果在“报价人-应答人”方向中使用的级别等于报价中的默认级别，则应答人必须准备使用sprop vps、sprop SP和sprop pps中包含的参数集（包括在SDP的“a=fmtp”行中或使用“fmtp”源属性传送）来解码传入比特流，例如。，在传递RTP流中携带的任何NAL单元之前，通过将这些参数集NAL单元传递给视频解码器。否则，应答方必须忽略sprop VP、sprop SP和sprop pps（包括在SDP的“a=fmtp”行中，或使用“fmtp”源属性传输），并且报价方必须在频带内传输参数集。
+ In MRST or MRMT, the answerer MUST be prepared to use the parameter sets out-of-band transmitted for the RTP stream and all RTP streams the RTP stream depends on, when present, for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ 在MRST或MRMT中，应答者必须准备使用为RTP流和RTP流所依赖的所有RTP流（当存在时）发送的带外参数集来解码传入比特流，例如，通过在传递RTP流中携带的任何NAL单元之前将这些参数集NAL单元传递给视频解码器。
o The following rules apply to transport of parameter set in the answerer-to-offerer direction.
o 以下规则适用于应答方向报价方方向传输参数集。
+ An answer MAY include sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters is present in the answer, then only in-band transport of parameter sets is used.
+ 答案可能包括sprop VP、sprop SP和/或sprop PP。如果答案中没有这些参数，则仅使用参数集的带内传输。
+ The offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ 报价人必须准备好使用sprop vps、sprop SP和sprop pps中包含的参数集（包括在SDP的“a=fmtp”行中，或使用“fmtp”源属性传送）对传入比特流进行解码，例如。，在传递RTP流中携带的任何NAL单元之前，通过将这些参数集NAL单元传递给视频解码器。
+ In MRST or MRMT, the offerer MUST be prepared to use the parameter sets out-of-band transmitted for the RTP stream and all RTP streams the RTP stream depends on, when present, for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ 在MRST或MRMT中，报价人必须准备使用为RTP流和RTP流所依赖的所有RTP流（当存在时）发送的带外参数集来解码传入比特流，例如，通过在传递RTP流中携带的任何NAL单元之前将这些参数集NAL单元传递给视频解码器。
o When sprop-vps, sprop-sps, and/or sprop-pps are conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576], the receiver of the parameters MUST store the parameter sets included in sprop-vps, sprop-sps, and/or sprop-pps and associate them with the source given as part of the "fmtp" source attribute. Parameter sets associated with one source (given as part of the "fmtp" source attribute) MUST only be used to decode NAL units conveyed in RTP packets from the same source (given as part of the "fmtp" source attribute). When this mechanism is in use, SSRC collision detection and resolution MUST be performed as specified in [RFC5576].
o 当使用[RFC5576]第6.3节规定的“fmtp”源属性传送sprop VP、sprop SP和/或sprop PP时，参数接收器必须存储sprop VP、sprop SP和/或sprop PP中包含的参数集，并将其与作为“fmtp”源属性一部分给出的源关联。与一个源关联的参数集（作为“fmtp”源属性的一部分给出）只能用于解码来自同一源（作为“fmtp”源属性的一部分给出）的RTP数据包中传输的NAL单元。使用此机制时，必须按照[RFC5576]中的规定执行SSRC碰撞检测和解决。
For bitstreams being delivered over multicast, the following rules apply:
对于通过多播传送的比特流，以下规则适用：
o The media format configuration is identified by profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, and tx-mode. These media format configuration parameters, including level-id, MUST be used symmetrically; that is, the answerer MUST either maintain all configuration parameters or remove the media format (payload type) completely. Note that this implies that the level-id for offer/answer in multicast is not changeable.
o 媒体格式配置由配置文件空间、配置文件id、层标志、级别id、互操作限制、配置文件兼容性指示符和发送模式标识。这些媒体格式配置参数（包括级别id）必须对称使用；也就是说，应答者必须保留所有配置参数或完全删除媒体格式（有效负载类型）。请注意，这意味着多播中提供/应答的级别id是不可更改的。
o To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [RFC3264]. An answer MUST NOT contain a payload type number used in the offer unless the configuration is the same as in the offer.
o 为了简化这些配置的处理和匹配，响应中还应使用报价中使用的相同RTP有效负载类型号，如[RFC3264]中所述。答案不得包含报价中使用的有效负载类型编号，除非配置与报价中的配置相同。
o Parameter sets received MUST be associated with the originating source and MUST only be used in decoding the incoming bitstream from the same source.
o 接收到的参数集必须与原始源关联，并且只能用于解码来自同一源的传入比特流。
o The rules for other parameters are the same as above for unicast as long as the three above rules are obeyed.
o 只要遵守上述三条规则，其他参数的规则与上述单播相同。
Table 1 lists the interpretation of all the parameters that MUST be used for the various combinations of offer, answer, and direction attributes. Note that the two columns wherein the recv-sub-layer-id parameter is used only apply to answers, whereas the other columns apply to both offers and answers.
表1列出了报价、应答和方向属性的各种组合必须使用的所有参数的解释。请注意，使用recv子层id参数的两列仅适用于答案，而其他列同时适用于报价和答案。
Table 1. Interpretation of parameters for various combinations of offers, answers, direction attributes, with and without recv-sub-layer-id. Columns that do not indicate offer or answer apply to both.
表1。解释各种报价、答案、方向属性组合的参数，包括和不包括recv-sub-layer-id。不表示报价或答案的列适用于两者。
sendonly --+
answer: recvonly, recv-sub-layer-id --+ |
recvonly w/o recv-sub-layer-id --+ | |
answer: sendrecv, recv-sub-layer-id --+ | | |
sendrecv w/o recv-sub-layer-id --+ | | | |
| | | | |
profile-space C D C D P
profile-id C D C D P
tier-flag C D C D P
level-id D D D D P
interop-constraints C D C D P
profile-compatibility-indicator C D C D P
tx-mode C C C C P
max-recv-level-id R R R R -
sprop-max-don-diff P P - - P
sprop-depack-buf-nalus P P - - P
sprop-depack-buf-bytes P P - - P
depack-buf-cap R R R R -
sprop-segmentation-id P P P P P
sprop-spatial-segmentation-idc P P P P P
max-br R R R R -
max-cpb R R R R -
max-dpb R R R R -
max-lsr R R R R -
max-lps R R R R -
max-tr R R R R -
max-tc R R R R -
max-fps R R R R -
sprop-vps P P - - P
sprop-sps P P - - P
sprop-pps P P - - P
sprop-sub-layer-id P P - - P
recv-sub-layer-id X O X O -
dec-parallel-cap R R R R -
include-dph R R R R -
sendonly --+
answer: recvonly, recv-sub-layer-id --+ |
recvonly w/o recv-sub-layer-id --+ | |
answer: sendrecv, recv-sub-layer-id --+ | | |
sendrecv w/o recv-sub-layer-id --+ | | | |
| | | | |
profile-space C D C D P
profile-id C D C D P
tier-flag C D C D P
level-id D D D D P
interop-constraints C D C D P
profile-compatibility-indicator C D C D P
tx-mode C C C C P
max-recv-level-id R R R R -
sprop-max-don-diff P P - - P
sprop-depack-buf-nalus P P - - P
sprop-depack-buf-bytes P P - - P
depack-buf-cap R R R R -
sprop-segmentation-id P P P P P
sprop-spatial-segmentation-idc P P P P P
max-br R R R R -
max-cpb R R R R -
max-dpb R R R R -
max-lsr R R R R -
max-lps R R R R -
max-tr R R R R -
max-tc R R R R -
max-fps R R R R -
sprop-vps P P - - P
sprop-sps P P - - P
sprop-pps P P - - P
sprop-sub-layer-id P P - - P
recv-sub-layer-id X O X O -
dec-parallel-cap R R R R -
include-dph R R R R -
Legend:
图例：
C: configuration for sending and receiving bitstreams D: changeable configuration, same as C except possible to answer with a different but consistent value (see the semantics of the six parameters related to profile, tier, and level on these parameters being consistent) P: properties of the bitstream to be sent R: receiver capabilities O: operation point selection X: MUST NOT be present -: not usable, when present MUST be ignored
C：发送和接收比特流的配置D：可更改配置，与C相同，但可能使用不同但一致的值进行应答（请参见与这些参数上的profile、tier和level相关的六个参数的语义一致）P：要发送的比特流的属性R：接收器功能O：操作点选择X：不得存在-：不可用，存在时必须忽略
Parameters used for declaring receiver capabilities are, in general, downgradable; i.e., they express the upper limit for a sender's possible behavior. Thus, a sender MAY select to set its encoder using only lower/lesser or equal values of these parameters.
通常，用于声明接收器功能的参数是可降级的；i、 例如，它们表示发送者可能行为的上限。因此，发送方可选择仅使用这些参数的较低/较小或相等值来设置其编码器。
When the answer does not include a recv-sub-layer-id that is less than the sprop-sub-layer-id in the offer, parameters declaring a configuration point are not changeable, with the exception of the level-id parameter for unicast usage, and these parameters express values a receiver expects to be used and MUST be used verbatim in the answer as in the offer.
如果回答中不包括小于报价中存储子层id的recv子层id，则声明配置点的参数不可更改，但单播使用的级别id参数除外，这些参数表示接收者期望使用的值，并且在回答中必须像在报价中一样逐字使用。
When a sender's capabilities are declared with the configuration parameters, these parameters express a configuration that is acceptable for the sender to receive bitstreams. In order to achieve high interoperability levels, it is often advisable to offer multiple alternative configurations. It is impossible to offer multiple configurations in a single payload type. Thus, when multiple configuration offers are made, each offer requires its own RTP payload type associated with the offer. However, it is possible to offer multiple operation points using one configuration in a single payload type by including sprop-vps in the offer and recv-sub-layer-id in the answer.
当使用配置参数声明发送方的功能时，这些参数表示发送方可以接收比特流的配置。为了实现高互操作性级别，通常建议提供多种备选配置。不可能在一种有效负载类型中提供多种配置。因此，当做出多个配置报价时，每个报价都需要与报价关联的自己的RTP有效负载类型。但是，通过在报价中包含sprop VP，在应答中包含recv子层id，可以在单个有效负载类型中使用一种配置提供多个操作点。
A receiver SHOULD understand all media type parameters, even if it only supports a subset of the payload format's functionality. This ensures that a receiver is capable of understanding when an offer to receive media can be downgraded to what is supported by the receiver of the offer.
接收器应该理解所有媒体类型参数，即使它只支持有效负载格式功能的一个子集。这确保接收者能够理解何时可以将接收媒体的要约降级为要约接收者支持的内容。
An answerer MAY extend the offer with additional media format configurations. However, to enable their usage, in most cases a second offer is required from the offerer to provide the bitstream property parameters that the media sender will use. This also has the effect that the offerer has to be able to receive this media format configuration, not only to send it.
应答者可以通过附加媒体格式配置来延长报价。然而，为了能够使用它们，在大多数情况下，需要提供方提供第二次提供，以提供媒体发送方将使用的比特流属性参数。这也意味着，报价人必须能够接收此媒体格式配置，而不仅仅是发送它。
When HEVC over RTP is offered with SDP in a declarative style, as in Real Time Streaming Protocol (RTSP) [RFC2326] or Session Announcement Protocol (SAP) [RFC2974], the following considerations are necessary.
当HEVC over RTP以声明式方式与SDP一起提供时，如在实时流协议（RTSP）[RFC2326]或会话公告协议（SAP）[RFC2974]中，需要考虑以下事项。
o All parameters capable of indicating both bitstream properties and receiver capabilities are used to indicate only bitstream properties. For example, in this case, the parameter profile-tier-level-id declares the values used by the bitstream, not the capabilities for receiving bitstreams. As a result, the following interpretation of the parameters MUST be used:
o 所有能够同时指示位流属性和接收器功能的参数仅用于指示位流属性。例如，在这种情况下，参数profile tier level id声明了位流使用的值，而不是接收位流的功能。因此，必须使用以下参数解释：
+ Declaring actual configuration or bitstream properties: - profile-space - profile-id - tier-flag - level-id - interop-constraints - profile-compatibility-indicator - tx-mode - sprop-vps - sprop-sps - sprop-pps - sprop-max-don-diff - sprop-depack-buf-nalus - sprop-depack-buf-bytes - sprop-segmentation-id - sprop-spatial-segmentation-idc
+ 声明实际配置或位流属性：-配置文件空间-配置文件id-层标志-级别id-互操作约束-配置文件兼容性指示器-发送模式-sprop vps-sprop sps-sprop pps-sprop max don diff-sprop depack buf nalus-sprop depack buf字节-sprop分段id-sprop空间分段idc
+ Not usable (when present, they MUST be ignored): - max-lps - max-lsr - max-cpb - max-dpb - max-br - max-tr - max-tc - max-fps - max-recv-level-id - depack-buf-cap - sprop-sub-layer-id - dec-parallel-cap - include-dph
+ 不可用（存在时，必须忽略）：-max lps-max lsr-max cpb-max dpb-max br-max tr-max tc-max fps-max recv level id-depack buf cap-sprop子层id-dec parallel cap-包括dph
o A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver MUST reject (RTSP) or not participate in (SAP) the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.
o SDP接收器需要支持提供的所有参数和参数值；否则，接收方必须拒绝（RTSP）或不参与（SAP）会话。会话的创建者需要使用接收应用程序预期支持的值。
When out-of-band transport of parameter sets is used, parameter sets MAY still be additionally transported in-band unless explicitly disallowed by an application, and some of these additional parameter sets may update some of the out-of-band transported parameter sets. Update of a parameter set refers to the sending of a parameter set of the same type using the same parameter set ID but with different values for at least one other parameter of the parameter set.
当使用参数集的带外传输时，除非应用程序明确禁止，否则参数集仍然可以在带内额外传输，并且这些额外的参数集中的一些可能会更新一些带外传输的参数集。参数集更新是指使用相同的参数集ID发送相同类型的参数集，但参数集的至少一个其他参数的值不同。
If MRST or MRMT is used, the rules on signaling media decoding dependency in SDP as defined in [RFC5583] apply. The rules on "hierarchical or layered encoding" with multicast in Section 5.7 of [RFC4566] do not apply. This means that the notation for Connection Data "c=" SHALL NOT be used with more than one address, i.e., the sub-field <number of addresses> in the sub-field <connection-address> of the "c=" field, described in [RFC4566], must not be present. The order of session dependency is given from the RTP stream containing the lowest temporal sub-layer to the RTP stream containing the highest temporal sub-layer.
如果使用MRST或MRMT，则适用[RFC5583]中定义的SDP中关于信令媒体解码相关性的规则。[RFC4566]第5.7节中关于多播的“分层或分层编码”规则不适用。这意味着连接数据“c=”的符号不得与多个地址一起使用，即，[RFC4566]中描述的“c=”字段的子字段<Connection address>中的子字段<number of addresses>。会话依赖的顺序是从包含最低时态子层的RTP流到包含最高时态子层的RTP流。
The following subsections define the use of the Picture Loss Indication (PLI), Slice Lost Indication (SLI), Reference Picture Selection Indication (RPSI), and Full Intra Request (FIR) feedback messages with HEVC. The PLI, SLI, and RPSI messages are defined in [RFC4585], and the FIR message is defined in [RFC5104].
以下小节定义了图像丢失指示（PLI）、片丢失指示（SLI）、参考图像选择指示（RPSI）和完整帧内请求（FIR）反馈消息与HEVC的使用。PLI、SLI和RPSI消息在[RFC4585]中定义，FIR消息在[RFC5104]中定义。
As specified in RFC 4585, Section 6.3.1, the reception of a PLI by a media sender indicates "the loss of an undefined amount of coded video data belonging to one or more pictures". Without having any specific knowledge of the setup of the bitstream (such as use and location of in-band parameter sets, non-IDR decoder refresh points, picture structures, and so forth), a reaction to the reception of an PLI by an HEVC sender SHOULD be to send an IDR picture and relevant parameter sets; potentially with sufficient redundancy so to ensure correct reception. However, sometimes information about the bitstream structure is known. For example, state could have been established outside of the mechanisms defined in this document that parameter sets are conveyed out of band only, and stay static for the duration of the session. In that case, it is obviously unnecessary to send them in-band as a result of the reception of a PLI. Other
如RFC 4585第6.3.1节所述，媒体发送方接收到PLI表示“丢失了属于一张或多张图片的未定义数量的编码视频数据”。在不具备比特流设置的任何特定知识（例如带内参数集、非IDR解码器刷新点、图片结构等的使用和位置）的情况下，HEVC发送方对PLI的接收的反应应该是发送IDR图片和相关参数集；可能具有足够的冗余，以确保正确接收。然而，有时关于比特流结构的信息是已知的。例如，可以在本文档中定义的机制之外建立状态，即参数集仅在带外传输，并且在会话期间保持静态。在这种情况下，由于接收到PLI，显然没有必要在频带内发送它们。另外
examples could be devised based on a priori knowledge of different aspects of the bitstream structure. In all cases, the timing and congestion control mechanisms of RFC 4585 MUST be observed.
可以基于比特流结构的不同方面的先验知识设计示例。在所有情况下，必须遵守RFC 4585的定时和拥塞控制机制。
The SLI described in RFC 4585 can be used to indicate, to a sender, the loss of a number of Coded Tree Blocks (CTBs) in a CTB raster scan order of a picture. In the SLI's Feedback Control Indication (FCI) field, the subfield "First" MUST be set to the CTB address of the first lost CTB. Note that the CTB address is in CTB-raster-scan order of a picture. For the first CTB of a slice segment, the CTB address is the value of slice_segment_address when present, or 0 when the value of first_slice_segment_in_pic_flag is equal to 1; both syntax elements are in the slice segment header. The subfield "Number" MUST be set to the number of consecutive lost CTBs, again in CTB-raster-scan order of a picture. Note that due to both the "First" and "Number" being counted in CTBs in CTB-raster-scan order, of a picture, not in tile-scan order (which is the bitstream order of CTBs), multiple SLI messages may be needed to report the loss of one tile covering multiple CTB rows but less wide than the picture.
RFC 4585中描述的SLI可用于向发送方指示图片的CTB光栅扫描顺序中的多个编码树块（CTB）的丢失。在SLI的反馈控制指示（FCI）字段中，必须将子字段“First”设置为第一个丢失CTB的CTB地址。请注意，CTB地址按图片的CTB光栅扫描顺序。对于片段的第一个CTB，当存在时，CTB地址是片段地址的值，或者当片段标志中的第一个片段地址的值等于1时，CTB地址为0；这两个语法元素都位于切片段标头中。子字段“编号”必须设置为连续丢失CTB的数量，同样是图片的CTB光栅扫描顺序。请注意，由于CTB光栅扫描顺序中的“第一个”和“数量”都是以CTB光栅扫描顺序计数的图片，而不是以磁贴扫描顺序（这是CTB的位流顺序），因此可能需要多条SLI消息来报告一个磁贴的丢失，该磁贴覆盖多个CTB行，但宽度小于图片。
The subfield "PictureID" MUST be set to the 6 least significant bits of a binary representation of the value of PicOrderCntVal, as defined in [HEVC], of the picture for which the lost CTBs are indicated. Note that for IDR pictures the syntax element slice_pic_order_cnt_lsb is not present, but then the value is inferred to be equal to 0.
子字段“PictureID”必须设置为PicOrderCntVal值的二进制表示的6个最低有效位，如[HEVC]中所定义，该值是指示丢失CTB的图片的值。请注意，对于IDR图片，语法元素slice_pic_order_cnt_lsb不存在，但随后该值被推断为等于0。
As described in RFC 4585, an encoder in a media sender can use this information to "clean up" the corrupted picture by sending intra information, while observing the constraints described in RFC 4585, for example, with respect to congestion control. In many cases, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncorrupted regions of the picture through motion compensation. Reference-picture selection can also be used to "clean up" the corrupted picture, which is usually more efficient and less likely to generate congestion than sending intra information.
如RFC 4585中所述，媒体发送器中的编码器可以使用该信息通过发送帧内信息来“清理”损坏的图片，同时观察RFC 4585中所述的约束，例如，关于拥塞控制。在许多情况下，由于通过运动补偿将错误导入图片的未损坏区域，因此需要错误跟踪来识别接收器状态中的损坏区域（参考图片）。参考图片选择还可用于“清理”损坏的图片，这通常比发送帧内信息更有效，也不太可能产生拥塞。
In contrast to the video codecs contemplated in RFCs 4585 and 5104 [RFC5104], in HEVC, the "macroblock size" is not fixed to 16x16 luma samples, but is variable. That, however, does not create a conceptual difficulty with SLI, because the setting of the CTB size is a sequence-level functionality, and using a slice loss indication across CVS boundaries is meaningless as there is no prediction across sequence boundaries. However, a proper use of SLI messages is not as straightforward as it was with older, fixed-macroblock-sized video
与RFCs 4585和5104[RFC5104]中设想的视频编解码器相反，在HEVC中，“宏块大小”不是固定为16x16 luma样本，而是可变的。然而，这不会给SLI带来概念上的困难，因为CTB大小的设置是序列级功能，跨CVS边界使用切片丢失指示是没有意义的，因为跨序列边界没有预测。然而，SLI消息的正确使用并不像旧的、固定宏块大小的视频那样简单
codecs, as the state of the sequence parameter set (where the CTB size is located) has to be taken into account when interpreting the "First" subfield in the FCI.
编解码器，因为在解释FCI中的“第一”子字段时，必须考虑序列参数集的状态（CTB大小所在的位置）。
Feedback-based reference picture selection has been shown as a powerful tool to stop temporal error propagation for improved error resilience [Girod99][Wang05]. In one approach, the decoder side tracks errors in the decoded pictures and informs the encoder side that a particular picture that has been decoded relatively earlier is correct and still present in the decoded picture buffer; it requests the encoder to use that correct picture-availability information when encoding the next picture, so to stop further temporal error propagation. For this approach, the decoder side should use the RPSI feedback message.
基于反馈的参考图片选择已被证明是一种强大的工具，可以阻止时间错误传播，从而提高错误恢复能力[Girod99][Wang05]。在一种方法中，解码器侧跟踪解码图片中的错误，并通知编码器侧相对较早解码的特定图片是正确的并且仍然存在于解码图片缓冲器中；它要求编码器在编码下一张图片时使用正确的图片可用性信息，从而停止进一步的时间错误传播。对于这种方法，解码器端应该使用RPSI反馈消息。
Encoders can encode some long-term reference pictures as specified in H.264 or HEVC for purposes described in the previous paragraph without the need of a huge decoded picture buffer. As shown in [Wang05], with a flexible reference picture management scheme, as in H.264 and HEVC, even a decoded picture buffer size of two picture storage buffers would work for the approach described in the previous paragraph.
编码器可以按照H.264或HEVC中的规定对一些长期参考图片进行编码，以达到上一段所述的目的，而不需要庞大的解码图片缓冲区。如[Wang05]所示，对于灵活的参考图片管理方案，如H.264和HEVC中所示，即使两个图片存储缓冲区的解码图片缓冲区大小也适用于上一段中描述的方法。
The field "Native RPSI bit string defined per codec" is a base16 [RFC4648] representation of the 8 bits consisting of the 2 most significant bits equal to 0 and 6 bits of nuh_layer_id, as defined in [HEVC], followed by the 32 bits representing the value of the PicOrderCntVal (in network byte order), as defined in [HEVC], for the picture that is indicated by the RPSI feedback message.
字段“每个编解码器定义的本机RPSI位字符串”是8位的base16[RFC4648]表示，8位包括[HEVC]中定义的等于0的2个最高有效位和nuh_layer_id的6位，然后是[HEVC]中定义的表示PicOrderCntVal值（以网络字节顺序）的32位，对于RPSI反馈消息指示的图片。
The use of the RPSI feedback message as positive acknowledgement with HEVC is deprecated. In other words, the RPSI feedback message MUST only be used as a reference picture selection request, such that it can also be used in multicast.
不推荐使用RPSI反馈消息作为HEVC的肯定确认。换句话说，RPSI反馈消息必须仅用作参考图片选择请求，以便它也可以在多播中使用。
The purpose of the FIR message is to force an encoder to send an independent decoder refresh point as soon as possible (observing, for example, the congestion-control-related constraints set out in RFC 5104).
FIR消息的目的是迫使编码器尽快发送独立的解码器刷新点（例如，观察RFC 5104中设置的拥塞控制相关约束）。
Upon reception of a FIR, a sender MUST send an IDR picture. Parameter sets MUST also be sent, except when there is a priori knowledge that the parameter sets have been correctly established. A
收到FIR后，发送方必须发送IDR图片。还必须发送参数集，除非事先知道参数集已正确建立。A.
typical example for that is an understanding between sender and receiver, established by means outside this document, that parameter sets are exclusively sent out-of-band.
典型的例子是发送方和接收方之间通过本文件以外的方式达成的谅解，即参数集仅在带外发送。
The scope of this Security Considerations section is limited to the payload format itself and to one feature of HEVC that may pose a particularly serious security risk if implemented naively. The payload format, in isolation, does not form a complete system. Implementers are advised to read and understand relevant security-related documents, especially those pertaining to RTP (see the Security Considerations section in [RFC3550]), and the security of the call-control stack chosen (that may make use of the media type registration of this memo). Implementers should also consider known security vulnerabilities of video coding and decoding implementations in general and avoid those.
本安全注意事项部分的范围仅限于有效负载格式本身和HEVC的一个功能，如果简单实现，可能会带来特别严重的安全风险。有效负载格式孤立地不构成一个完整的系统。建议实施者阅读并理解相关的安全相关文档，尤其是与RTP相关的文档（参见[RFC3550]中的安全注意事项部分），以及所选调用控制堆栈的安全性（可利用本备忘录的媒体类型注册）。实现者还应该考虑一般的视频编码和解码实现的已知安全漏洞，并避免这些漏洞。
Within this RTP payload format, and with the exception of the user data SEI message as described below, no security threats other than those common to RTP payload formats are known. In other words, neither the various media-plane-based mechanisms, nor the signaling part of this memo, seems to pose a security risk beyond those common to all RTP-based systems.
在该RTP有效负载格式中，除了下面描述的用户数据SEI消息之外，除了RTP有效负载格式常见的安全威胁之外，没有已知的安全威胁。换句话说，无论是基于媒体平面的各种机制，还是本备忘录的信令部分，似乎都不会带来超出所有基于RTP的系统所共有的安全风险。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this section discusses the security impacting properties of the payload format itself.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适用RTP配置文件（如RTP/AVP[RFC3551]、RTP/AVPF[RFC4585]、RTP/SAVP[RFC3711]或RTP/SAVPF[RFC5124]中讨论的安全注意事项的约束。然而，正如[RFC7202]所讨论的“保护RTP框架：为什么RTP不强制要求单一媒体安全解决方案”，RTP有效负载格式不负责讨论或强制要求使用什么解决方案来满足RTP的基本安全目标，如机密性、完整性和源真实性。这一责任由在应用程序中使用RTP的任何人承担。他们可以在“保护RTP会话的选项”[RFC7201]中找到关于可用安全机制和重要注意事项的指导。应用程序应使用一个或多个适当的强安全机制。本节的其余部分将讨论影响有效负载格式本身安全性的属性。
Because the data compression used with this payload format is applied end-to-end, any encryption needs to be performed after compression. 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 bitstream that are complex to decode and that cause the receiver to be overloaded. H.265 is particularly vulnerable to such
由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此任何加密都需要在压缩后执行。使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向比特流中注入病理数据报，这些数据报解码复杂，导致接收器过载。H.265特别容易受到这种影响
attacks, as it is extremely simple to generate datagrams containing NAL units that affect the decoding process of many future NAL units. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED, for example, with SRTP [RFC3711].
攻击，因为生成包含影响许多未来NAL单元解码过程的NAL单元的数据报非常简单。因此，建议至少使用RTP分组的数据源认证和数据完整性保护，例如，使用SRTP[RFC3711]。
Like [H.264], HEVC includes a user data Supplemental Enhancement Information (SEI) message. This SEI message allows inclusion of an arbitrary bitstring into the video bitstream. Such a bitstring could include JavaScript, machine code, and other active content. HEVC leaves the handling of this SEI message to the receiving system. In order to avoid harmful side effects of the user data SEI message, decoder implementations cannot naively trust its content. For example, it would be a bad and insecure implementation practice to forward any JavaScript a decoder implementation detects to a web browser. The safest way to deal with user data SEI messages is to simply discard them, but that can have negative side effects on the quality of experience by the user.
与[H.264]类似，HEVC包括用户数据补充增强信息（SEI）消息。此SEI消息允许将任意位字符串包含到视频位流中。这样的位字符串可以包括JavaScript、机器代码和其他活动内容。HEVC将此SEI消息的处理留给接收系统。为了避免用户数据SEI消息的有害副作用，解码器实现不能天真地信任其内容。例如，将解码器实现检测到的任何JavaScript转发到web浏览器将是一种糟糕且不安全的实现实践。处理用户数据SEI消息最安全的方法是简单地丢弃它们，但这可能会对用户的体验质量产生负面影响。
End-to-end security with authentication, integrity, or confidentiality protection will prevent a MANE from performing media-aware operations other than discarding complete packets. In the case of confidentiality protection, it will even be prevented from discarding packets in a media-aware way. To be allowed to perform such operations, a MANE is required to be a trusted entity that is included in the security context establishment.
具有身份验证、完整性或机密性保护的端到端安全性将防止MANE执行除丢弃完整数据包以外的媒体感知操作。在保密保护的情况下，甚至可以防止它以媒体感知的方式丢弃数据包。要允许执行此类操作，MANE必须是安全上下文建立中包含的受信任实体。
Congestion control for RTP SHALL be used in accordance with RTP [RFC3550] and with any applicable RTP profile, e.g., AVP [RFC3551]. If best-effort service is being used, an additional requirement is that users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within an acceptable range. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than all RTP streams combined is achieving. This condition can be satisfied by implementing congestion-control mechanisms to adapt the transmission rate, the number of layers subscribed for a layered multicast session, or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
RTP的拥塞控制应根据RTP[RFC3550]和任何适用的RTP配置文件（如AVP[RFC3551]）使用。如果正在使用尽力而为服务，另一个要求是，此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的范围内。如果通过相同网络路径并经历相同网络条件的TCP流将达到在合理时间尺度上测量的平均吞吐量，即不小于所有RTP流组合所达到的平均吞吐量，则认为丢包是可接受的。通过实现拥塞控制机制以适应传输速率、为分层多播会话订阅的层数，或者如果丢失率高得令人无法接受，则通过安排接收机离开会话，可以满足该条件。
The bitrate adaptation necessary for obeying the congestion control principle is easily achievable when real-time encoding is used, for example, by adequately tuning the quantization parameter.
当使用实时编码时，例如通过适当地调整量化参数，可以容易地实现遵守拥塞控制原则所必需的比特率自适应。
However, when pre-encoded content is being transmitted, bandwidth adaptation requires the pre-coded bitstream to be tailored for such adaptivity. The key mechanism available in HEVC is temporal scalability. A media sender can remove NAL units belonging to higher temporal sub-layers (i.e., those NAL units with a high value of TID) until the sending bitrate drops to an acceptable range. HEVC contains mechanisms that allow the lightweight identification of switching points in temporal enhancement layers, as discussed in Section 1.1.2 of this memo. An HEVC media sender can send packets belonging to NAL units of temporal enhancement layers starting from these switching points to probe for available bandwidth and to utilized bandwidth that has been shown to be available.
然而，当传输预编码内容时，带宽自适应要求针对这种自适应性定制预编码比特流。HEVC中可用的关键机制是时间可伸缩性。媒体发送器可以移除属于更高时间子层的NAL单元（即，那些具有高TID值的NAL单元），直到发送比特率下降到可接受的范围。HEVC包含允许在时间增强层中轻量级识别切换点的机制，如本备忘录第1.1.2节所述。HEVC媒体发送器可以从这些交换点开始发送属于时间增强层的NAL单元的分组，以探测可用带宽和已显示可用的已利用带宽。
Above mechanisms generally work within a defined profile and level and, therefore, no renegotiation of the channel is required. Only when non-downgradable parameters (such as profile) are required to be changed does it become necessary to terminate and restart the RTP stream(s). This may be accomplished by using different RTP payload types.
上述机制通常在定义的概要文件和级别内工作，因此，不需要对渠道进行重新协商。只有当需要更改不可降级的参数（如配置文件）时，才有必要终止并重新启动RTP流。这可以通过使用不同的RTP有效负载类型来实现。
MANEs MAY remove certain unusable packets from the RTP stream when that RTP stream was damaged due to previous packet losses. This can help reduce the network load in certain special cases. For example, MANES can remove those FUs where the leading FUs belonging to the same NAL unit have been lost or those dependent slice segments when the leading slice segments belonging to the same slice have been lost, because the trailing FUs or dependent slice segments are meaningless to most decoders. MANES can also remove higher temporal scalable layers if the outbound transmission (from the MANE's viewpoint) experiences congestion.
当RTP流由于先前的数据包丢失而损坏时，MANE可以从RTP流中移除某些不可用的数据包。在某些特殊情况下，这有助于减少网络负载。例如，mane可以删除属于同一NAL单元的前导fu丢失的那些fu，或者删除属于同一片的前导片段丢失时的那些从属片段，因为尾随fu或从属片段对大多数解码器来说是无意义的。如果出站传输（从MANE的角度来看）遇到拥塞，MANE还可以移除更高的时间可伸缩层。
A new media type, as specified in Section 7.1 of this memo, has been registered with IANA.
本备忘录第7.1节规定的新媒体类型已在IANA注册。
[H.264] ITU-T, "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, April 2013.
[H.264]ITU-T，“通用视听服务的高级视频编码”，ITU-T建议H.264，2013年4月。
[HEVC] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, April 2013.
[HEVC]ITU-T，“高效视频编码”，ITU-T建议H.265，2013年4月。
[ISO23008-2] ISO/IEC, "Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding", ISO/IEC 23008-2, 2013.
[ISO23008-2]ISO/IEC，“信息技术——异构环境中的高效编码和媒体交付——第2部分：高效视频编码”，ISO/IEC 23008-22013。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 5576，DOI 10.17487/RFC5576，2009年6月<http://www.rfc-editor.org/info/rfc5576>.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583]Schierl，T.和S.Wenger，“会话描述协议（SDP）中的信令媒体解码依赖性”，RFC 5583，DOI 10.17487/RFC5583，2009年7月<http://www.rfc-editor.org/info/rfc5583>.
[3GPDASH] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)", 3GPP TS 26.247 12.1.0, December 2013.
[3GPDASH]3GPP，“透明端到端分组交换流媒体服务（PSS）；通过HTTP的渐进下载和动态自适应流媒体服务（3GPDASH）”，3GPP TS 26.247 12.1.012013年12月。
[3GPPFF] 3GPP, "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244 12.20, December 2013.
[3GPPFF]3GPP，“透明端到端分组交换流媒体服务（PSS）；3GPP文件格式（3GP）”，3GPP TS 26.244 12.202013年12月。
[CABAC] Sole, J., Joshi, R., Nguyen, N., Ji, T., Karczewicz, M., Clare, G., Henry, F., and Duenas, A., "Transform coefficient coding in HEVC", IEEE Transactions on Circuts and Systems for Video Technology, Vol. 22, No. 12, pp. 1765-1777, DOI 10.1109/TCSVT.2012.2223055, December 2012.
[CABAC]Sole，J.，Joshi，R.，Nguyen，N.，Ji，T.，Karczewicz，M.，Clare，G.，Henry，F.，和Duenas，A.，“HEVC中的变换系数编码”，IEEE视频技术电路和系统交易，第22卷，第12期，第1765-1777页，DOI 10.1109/TCSVT.2012.2223055，2012年12月。
[Girod99] Girod, B. and Faerber, F., "Feedback-based error control for mobile video transmission", Proceedings of the IEEE, Vol. 87, No. 10, pp. 1707-1723, DOI 10.1109/5.790632, October 1999.
[Girod99]Girod，B.和Faerber，F.，“基于反馈的移动视频传输差错控制”，《IEEE会议录》，第87卷，第10期，第1707-1723页，DOI 10.1109/5.790632，1999年10月。
[H.265.1] ITU-T, "Conformance specification for ITU-T H.265 high efficiency video coding", ITU-T Recommendation H.265.1, October 2014.
[H.265.1]ITU-T，“ITU-T H.265高效视频编码的一致性规范”，ITU-T建议H.265.1，2014年10月。
[HEVCv2] Flynn, D., Naccari, M., Rosewarne, C., Sharman, K., Sole, J., Sullivan, G. J., and T. Suzuki, "High Efficiency Video Coding (HEVC) Range Extensions text specification: Draft 7", JCT-VC document JCTVC-Q1005, 17th JCT-VC meeting, Valencia, Spain, March/April 2014.
[HEVCv2]Flynn，D.，Naccari，M.，Rosewarne，C.，Sharman，K.，Sole，J.，Sullivan，G.J.，和T.Suzuki，“高效视频编码（HEVC）范围扩展文本规范：草案7”，JCT-VC文件JCTVC-Q1005，第17次JCT-VC会议，西班牙巴伦西亚，2014年3月/4月。
[IS014496-12] IS0/IEC, "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", IS0/IEC 14496-12, 2015.
[IS014496-12]IS0/IEC，“信息技术-视听对象的编码-第12部分：ISO基本媒体文件格式”，IS0/IEC 14496-12，2015年。
[IS015444-12] IS0/IEC, "Information technology - JPEG 2000 image coding system - Part 12: ISO base media file format", IS0/IEC 15444-12, 2015.
[IS015444-12]IS0/IEC，“信息技术-JPEG 2000图像编码系统-第12部分：ISO基本媒体文件格式”，IS0/IEC 15444-12，2015年。
[JCTVC-J0107] Wang, Y.-K., Chen, Y., Joshi, R., and Ramasubramonian, K., "AHG9: On RAP pictures", JCT-VC document JCTVC-L0107, 10th JCT-VC meeting, Stockholm, Sweden, July 2012.
[JCTVC-J0107]Wang，Y.-K.，Chen，Y.，Joshi，R.，和Ramasubramonian，K.，“AHG9：说唱音乐图片”，JCT-VC文件JCTVC-L0107，第十届JCT-VC会议，瑞典斯德哥尔摩，2012年7月。
[MPEG2S] ISO/IEC, "Information technology - Generic coding of moving pictures and associated audio information - Part 1: Systems", ISO International Standard 13818-1, 2013.
[MPEG2S]ISO/IEC，“信息技术-运动图像和相关音频信息的通用编码-第1部分：系统”，ISO国际标准13818-12013。
[MPEGDASH] ISO/IEC, "Information technology - Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO International Standard 23009-1, 2012.
[MPEGDASH]ISO/IEC，“信息技术——HTTP上的动态自适应流传输（DASH）——第1部分：媒体呈现描述和片段格式”，ISO国际标准23009-12012。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，DOI 10.17487/RFC2326，1998年4月<http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<http://www.rfc-editor.org/info/rfc2974>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 6051，DOI 10.17487/RFC6051，2010年11月<http://www.rfc-editor.org/info/rfc6051>.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <http://www.rfc-editor.org/info/rfc6184>.
[RFC6184]Wang，Y.-K.，Even，R.，Kristensen，T.，和R.Jesup，“H.264视频的RTP有效载荷格式”，RFC 6184，DOI 10.17487/RFC6184，2011年5月<http://www.rfc-editor.org/info/rfc6184>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190]Wenger，S.，Wang，Y.-K.，Schierl，T.，和A.Eleftheriadis，“可伸缩视频编码的RTP有效载荷格式”，RFC 6190DOI 10.17487/RFC6190，2011年5月<http://www.rfc-editor.org/info/rfc6190>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，DOI 10.17487/RFC7202，2014年4月<http://www.rfc-editor.org/info/rfc7202>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<http://www.rfc-editor.org/info/rfc7667>.
[RTP-MULTI-STREAM] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-11, December 2015.
[RTP-MULTI-STREAM]Lennox，J.，Westerlund，M.，Wu，Q.，和C.Perkins，“在单个RTP会话中发送多个媒体流”，正在进行的工作，草稿-ietf-avtcore-RTP-MULTI-STREAM-112015年12月。
[SDP-NEG] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Medai Multiplexing Using Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-25, January 2016.
[SDP-NEG]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商Medai多路复用”，正在进行的工作，草稿-ietf-mmusic-SDP-bundle-NEGATING-252016年1月。
[Wang05] Wang, Y.-K., Zhu, C., and Li, H., "Error resilient video coding using flexible reference fames", Visual Communications and Image Processing 2005 (VCIP 2005), Beijing, China, July 2005.
[Wang05]Wang，Y.-K.，Zhu，C.，和Li，H.，“使用灵活参考名目的容错视频编码”，视觉通信和图像处理2005（VCIP 2005），中国北京，2005年7月。
Acknowledgements
致谢
Muhammed Coban and Marta Karczewicz are thanked for discussions on the specification of the use with feedback messages and other aspects in this memo. Jonathan Lennox and Jill Boyce are thanked for their contributions to the PACI design included in this memo. Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund, and Tom Kristensen are thanked for their contributions to signaling related to parallel processing. Magnus Westerlund, Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even, Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross Finlayson, Danny Hong, Bo Burman, Ben Campbell, Brian Carpenter, Qin Wu, Stephen Farrell, and Min Wang made valuable review comments that led to improvements.
感谢Muhammed Coban和Marta Karczewicz就本备忘录中的反馈信息和其他方面的使用规范进行讨论。感谢Jonathan Lennox和Jill Boyce为本备忘录中的PACI设计所做的贡献。感谢Rickard Sjoberg、Arild Fuldseth、Bo Burman、Magnus Westerlund和Tom Kristensen为并行处理相关的信令做出的贡献。Magnus Westerlund、Jonathan Lennox、Bernard Aboba、Jonatan Samuelsson、Roni Een、Rickard Sjoberg、Sachin Deshpande、Woo Johnman、Mo Zanaty、Ross Finlayson、Danny Hong、Bo Burman、Ben Campbell、Brian Carpenter、Qin Wu、Stephen Farrell和Min Wang发表了宝贵的评论，这些评论带来了改进。
Authors' Addresses
作者地址
Ye-Kui Wang Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 United States Phone: +1-858-651-8345 Email: yekui.wang@gmail.com
Ye Kui Wang高通公司5775 Morehouse Drive San Diego，CA 92121美国电话：+1-858-651-8345电子邮件：yekui。wang@gmail.com
Yago Sanchez Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany Phone: +49 30 31002-663 Email: yago.sanchez@hhi.fraunhofer.de
Yago Sanchez Fraunhofer HHI Einsteinufer 37 D-10587德国柏林电话：+49 30 31002-663电子邮件：Yago。sanchez@hhi.fraunhofer.de
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany Phone: +49-30-31002-227 Email: thomas.schierl@hhi.fraunhofer.de
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587德国柏林电话：+49-30-31002-227电子邮件：Thomas。schierl@hhi.fraunhofer.de
Stephan Wenger Vidyo, Inc. 433 Hackensack Ave., 7th floor Hackensack, NJ 07601 United States Phone: +1-415-713-5473 Email: stewe@stewe.org
Stephan Wenger Vidyo，Inc.美国新泽西州哈肯萨克大街433号哈肯萨克7楼07601电话：+1-415-713-5473电子邮件：stewe@stewe.org
Miska M. Hannuksela Nokia Corporation P.O. Box 1000 33721 Tampere Finland Phone: +358-7180-08000 Email: miska.hannuksela@nokia.com
Miska M.Hannuksela诺基亚公司邮箱1000 33721坦佩雷芬兰电话：+358-7180-08000电子邮件：Miska。hannuksela@nokia.com