Internet Engineering Task Force (IETF) J. Weaver
Request for Comments: 8450 BBC
Category: Standards Track October 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Weaver
Request for Comments: 8450 BBC
Category: Standards Track October 2018
ISSN: 2070-1721
RTP Payload Format for VC-2 High Quality (HQ) Profile
VC-2高质量（HQ）配置文件的RTP有效负载格式
Abstract
摘要
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
本备忘录描述了美国电影电视工程师协会标准ST 2042-1（称为VC-2）高质量（HQ）配置文件的RTP有效载荷格式。本文档描述了RTP数据包中HQ配置文件VC-2的传输，并应用于无损和有损压缩视频的低复杂度、高带宽流传输。
The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).
VC-2的HQ配置文件旨在以高数据速率（压缩比为2:1或4:1）进行低延迟视频压缩（延迟可能为视频行的顺序）。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8450.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8450.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions, and Acronyms . . . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 10
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 11
4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 13
4.4. Stream Constraints . . . . . . . . . . . . . . . . . . . 14
4.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1. Reassembling the Data . . . . . . . . . . . . . . . . 16
5. Forward Error Correction (FEC) Considerations . . . . . . . . 18
6. Congestion Control Considerations . . . . . . . . . . . . . . 18
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 19
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 19
7.2. Mapping to the Session Description Protocol (SDP) . . . . 21
7.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions, and Acronyms . . . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 10
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 11
4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 13
4.4. Stream Constraints . . . . . . . . . . . . . . . . . . . 14
4.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1. Reassembling the Data . . . . . . . . . . . . . . . . 16
5. Forward Error Correction (FEC) Considerations . . . . . . . . 18
6. Congestion Control Considerations . . . . . . . . . . . . . . 18
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 19
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 19
7.2. Mapping to the Session Description Protocol (SDP) . . . . 21
7.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
This memo specifies an RTP payload format for the video coding standard Society of Motion Picture and Television Engineers ST 2042-1:2017 [VC2], also known as VC-2
本备忘录规定了视频编码标准电影和电视工程师协会ST 2042-1:2017[VC2]的RTP有效载荷格式，也称为VC-2
The VC-2 codec is a wavelet-based codec intended primarily for professional video use with high bit-rates and only low levels of compression. It has been designed to have a low level of complexity and potentially a very low latency through both encoder and decoder: with some choices of parameters, this latency may be as low as a few lines of video.
VC-2编解码器是一种基于小波的编解码器，主要用于高比特率和低压缩水平的专业视频使用。它被设计为具有较低的复杂性，并且通过编码器和解码器可能具有非常低的延迟：通过一些参数选择，该延迟可能低至几行视频。
The low level of complexity in the VC-2 codec allows for this low-latency operation but also means that it lacks many of the more powerful compression techniques used in other codecs. As such, it is suitable for low compression ratios that produce coded data rates around half to a quarter of that of uncompressed video, at a similar visual quality.
VC-2编解码器的低复杂度允许这种低延迟操作，但也意味着它缺少其他编解码器中使用的许多更强大的压缩技术。因此，它适用于产生编码数据速率约为未压缩视频的一半到四分之一的低压缩比，且具有相似的视觉质量。
The primary use for VC-2 is likely to be in professional video production environments.
VC-2的主要用途可能是在专业视频制作环境中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The VC-2 specification defines a VC-2 Stream as being composed of one or more Sequences. Each Sequence is independently decodable, containing all of the needed parameters and metadata for configuring the decoder.
VC-2规范将VC-2流定义为由一个或多个序列组成。每个序列都是可独立解码的，包含配置解码器所需的所有参数和元数据。
Each Sequence consists of a series of 13-octet Parse Info Headers and variable-length Data Units. The Sequence begins and ends with a Parse Info Header, and each Data Unit is preceded by a Parse Info Header. Data Units come in a variety of types, and the type of a Data Unit is signaled in the preceding Parse Info Header. The most important types are the Sequence Header, which contains configuration data needed by the decoder, and several types of Coded Picture, which contain the coded data for the pictures themselves. Each picture represents a frame in a progressively scanned video Sequence or a field in an interlaced video Sequence.
每个序列由一系列13个八位组解析信息头和可变长度数据单元组成。序列以Parse Info头开始和结束，每个数据单元前面都有Parse Info头。数据单元有多种类型，数据单元的类型在前面的Parse Info报头中发出信号。最重要的类型是序列头（包含解码器所需的配置数据）和几种类型的编码图片（包含图片本身的编码数据）。每幅图片表示逐行扫描视频序列中的一帧或隔行扫描视频序列中的一个场。
The first Data Unit in a Sequence as produced by an encoder is always a Sequence Header; however, Sequences can be joined in the middle, so it should not be assumed that the first Data Unit received will always be a Sequence Header.
由编码器产生的序列中的第一数据单元始终是序列头；然而，序列可以在中间连接，因此不应该假定接收到的第一数据单元永远是序列报头。
The High Quality (HQ) profile for VC-2 restricts the types of Parse Info Headers that may appear in the Sequence (and hence also the types of Data Unit) to only:
VC-2的高质量（HQ）配置文件将序列中可能出现的解析信息头的类型（以及数据单元的类型）限制为：
o Sequence Headers (which are always followed by a Data Unit),
o 序列头（后面总是跟一个数据单元），
o High Quality Pictures (which are always followed by a Data Unit),
o 高质量图片（后面总是有一个数据单元），
o High Quality Fragments (which are always followed by a Data Unit),
o 高质量片段（后面总是有一个数据单元），
o Auxiliary Data (which are always followed by a Data Unit),
o 辅助数据（后面总是有一个数据单元），
o Padding Data (which are always followed by a Data Unit), and
o 填充数据（后面总是跟一个数据单元），以及
o End of Sequence (which are never followed by a Data Unit).
o 序列结束（后面永远不会有数据单元）。
At the time of writing, there is no definition for the use of Auxiliary Data in VC-2, and Padding Data is required to be ignored by all receivers.
在编写本文时，VC-2中没有关于辅助数据使用的定义，所有接收器都需要忽略填充数据。
Each High Quality Picture Data Unit contains a set of parameters for the picture followed by a series of Coded Slices, each representing a rectangular region of the transformed picture. Slices within a picture may vary in coded length, but all represent the same shape and size of rectangle in the picture.
每个高质量图片数据单元包含图片的一组参数，后跟一系列编码切片，每个切片表示变换图片的矩形区域。图片中的切片可能在编码长度上有所不同，但都表示图片中矩形的相同形状和大小。
Each High Quality Fragment Data Unit contains either a set of parameters for a picture or a series of Coded Slices. Fragments carry the same data as pictures, but broken up into smaller units to facilitate transmission via packet-based protocols such as RTP.
每个高质量片段数据单元包含一组图片参数或一系列编码切片。片段携带与图片相同的数据，但分成更小的单元，以便于通过基于分组的协议（如RTP）进行传输。
This payload format only makes use of Fragments, not pictures.
此有效负载格式仅使用片段，而不使用图片。
In this specification, each RTP packet is used to carry data corresponding to a single Parse Info Header and its following Data Unit (if it has one). A single packet MAY NOT contain data from more than one Parse Info Header or Data Unit. A single Parse Info Header and Data Unit pair MUST NOT be split across more than one packet. The sole exception to this rule is that an Auxiliary Data Unit MAY be split between multiple packets, using the B and E flags to indicate start and end.
在本规范中，每个RTP数据包用于携带对应于单个解析信息报头及其后续数据单元（如果有）的数据。单个数据包不能包含来自多个解析信息头或数据单元的数据。单个解析信息头和数据单元对不能跨多个数据包拆分。该规则的唯一例外是，辅助数据单元可以在多个数据包之间分割，使用B和E标志来指示开始和结束。
This specification only covers the transport of Sequence Headers (together with their accompanying Data Unit), High Quality Fragments (together with their accompanying Data Unit), Auxiliary Data (together with their accompanying Data Unit), and (optionally) End Sequence Headers and Padding Data (for which no Data Unit it carried).
本规范仅涵盖序列头（及其附带的数据单元）、高质量片段（及其附带的数据单元）、辅助数据（及其附带的数据单元）和（可选）结束序列头和填充数据（其未携带数据单元）的传输。
High Quality Pictures can be transported by converting them into an equivalent set of High Quality Fragments. The size of Fragments should be chosen so as to fit within the MTU of the network in use.
高质量的图片可以通过将其转换为一组同等的高质量片段来传输。应选择片段的大小，以适合所用网络的MTU。
For this reason, this document defines six types of RTP packets in a VC-2 media stream:
因此，本文档在VC-2媒体流中定义了六种类型的RTP数据包：
o a VC-2 Sequence Header (Figure 1) (see Section 11 of the VC-2 specification [VC2]),
o VC-2序列头（图1）（参见VC-2规范[VC2]第11节），
o a Picture Fragment containing the VC-2 Transform Parameters for a Picture (Figure 2) (see Section 14 of the VC-2 specification [VC2]),
o 包含图片VC-2变换参数的图片片段（图2）（参见VC-2规范[VC2]第14节），
o a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a picture (see Section 14 of the VC-2 specification [VC2]),
o 图片片段，包含图片的VC-2编码切片（图3）（参见VC-2规范[VC2]第14节），
o the end of a VC-2 Sequence (Figure 4) (see Section 10.5.2 of the VC-2 specification [VC2]),
o VC-2序列的结束（图4）（参见VC-2规范[VC2]第10.5.2节），
o the contents of an Auxiliary Data Unit (Figure 5) (see Section 10.4.4 of the VC-2 specification [VC2]), and
o 辅助数据单元的内容（图5）（见VC-2规范[VC2]第10.4.4节），以及
o an indication of the presence of a padding Data Unit (Figure 6) (see Section 10.4.5 of the VC-2 specification [VC2]).
o 存在填充数据单元的指示（图6）（参见VC-2规范[VC2]第10.4.5节）。
These six packet types can be distinguished by the fact that they use different codes in the Parse Code ("PC") field, except for the two types of Picture Fragment that use the same value in PC but have different values in the "No. of Slices" field.
这六种数据包类型的区别在于，它们在解析代码（“PC”）字段中使用不同的代码，但在PC中使用相同值但在“切片数”字段中具有不同值的两种图片片段除外。
The options for PC codes are explained in more detail in Section 4.3.
PC代码的选项在第4.3节中有更详细的说明。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Sequence Header .
. .
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Sequence Header .
. .
+---------------------------------------------------------------+
Figure 1: RTP Payload Format for Sequence Header
图1：序列头的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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Transform Parameters .
. .
+---------------------------------------------------------------+
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Transform Parameters .
. .
+---------------------------------------------------------------+
Figure 2: RTP Payload Format for Transform Parameters Fragment
图2：转换参数片段的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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Offset X | Slice Offset Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Coded Slices .
. .
+---------------------------------------------------------------+
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Offset X | Slice Offset Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Coded Slices .
. .
+---------------------------------------------------------------+
Figure 3: RTP Payload Format for Fragment Containing Slices
图3：包含片段的片段的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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x10 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x10 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4: RTP Payload Format for End of Sequence
图4：序列结束时的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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Uncoded Payload Data .
. .
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Uncoded Payload Data .
. .
+---------------------------------------------------------------+
Figure 5: RTP Payload Format for Auxiliary Data
图5：辅助数据的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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+---------------------------------------------------------------+
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+---------------------------------------------------------------+
Figure 6: RTP Payload Format for Padding Data
图6：填充数据的RTP有效负载格式
All fields in the headers longer than a single bit are interpreted as unsigned integers in network byte order.
标头中长度超过一位的所有字段都将按网络字节顺序解释为无符号整数。
The fields of the RTP header have the following additional notes on their usage:
RTP标头字段的用法有以下附加说明：
Marker Bit (M): 1 bit. The marker bit MUST be set on any packet that contains the final slice in a coded picture and MUST NOT be set otherwise.
标记位（M）：1位。标记位必须设置在包含编码图片中最后一个片段的任何数据包上，不得以其他方式设置。
Payload Type (PT): 7 bits. A dynamically allocated payload type field that designates the payload as VC-2-coded video.
有效负载类型（PT）：7位。动态分配的有效负载类型字段，将有效负载指定为VC-2编码视频。
Sequence Number: 16 bits. Because the data rate of VC-2-coded Streams can often be very high, in the order of gigabits rather than megabits per second, the standard 16-bit RTP sequence number can cycle very quickly. For this reason, the sequence number is extended to 32 bits, and this field MUST hold the low-order 16 bits of this value.
序列号：16位。由于VC-2编码流的数据速率通常非常高，以每秒千兆位而不是兆位为单位，因此标准的16位RTP序列号可以非常快地循环。因此，序列号扩展到32位，并且该字段必须保存该值的低位16位。
Timestamp: 32 bits. If the packet contains Transform Parameters or Coded Slice data for a coded picture, then the timestamp corresponds to the sampling instant of the coded picture. A 90kHz clock SHOULD be used. A single RTP packet MUST NOT contain coded data for more than one coded picture, so there is no ambiguity here.
时间戳：32位。如果包包含编码图片的变换参数或编码切片数据，则时间戳对应于编码图片的采样瞬间。应使用90kHz时钟。单个RTP数据包不能包含多个编码图片的编码数据，因此这里没有歧义。
A Sequence Header packet SHOULD have the same timestamp as the picture that will follow it in the Stream. An End of Sequence packet SHOULD have the same timestamp as the previous picture that appeared in the Stream.
序列头数据包应具有与流中紧随其后的图片相同的时间戳。序列结束数据包应具有与流中出现的前一图片相同的时间戳。
The remaining RTP header fields are used as specified in RTP [RFC3550].
剩余的RTP头字段按照RTP[RFC3550]中的规定使用。
The fields of the extended headers are defined as follows:
扩展标头的字段定义如下：
Extended Sequence Number: 16 bits. MUST contain the high-order 16 bits of the 32-bit packet sequence number. This is needed since the high data rates of VC-2 Sequences mean that it is highly likely that the 16-bit sequence number will roll over too frequently to be of use for Stream synchronization.
扩展序列号：16位。必须包含32位数据包序列号的高阶16位。这是必需的，因为VC-2序列的高数据速率意味着16位序列号很可能会过度频繁地滚动，无法用于流同步。
B: 1 bit. MUST be set to 1 if the packet contains the first byte of an Auxiliary Data Unit and otherwise MUST be 0. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then every Auxiliary Data Unit will be small enough to fit in a single packet, and so this bit (where present) will always be 1.
B:1位。如果数据包包含辅助数据单元的第一个字节，则必须设置为1，否则必须为0。如果遵循第4.4节（“流约束”）中的建议，则每个辅助数据单元都将足够小，足以容纳单个数据包，因此该位（如果存在）将始终为1。
E: 1 bit. MUST be set to 1 if the packet contains the final byte of an Auxiliary Data Unit and otherwise MUST be 0. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then every Auxiliary Data Unit will be small enough to fit in a single packet, and so this bit (where present) will always be 1.
E:1位。如果数据包包含辅助数据单元的最后一个字节，则必须设置为1，否则必须为0。如果遵循第4.4节（“流约束”）中的建议，则每个辅助数据单元都将足够小，足以容纳单个数据包，因此该位（如果存在）将始终为1。
I: 1 bit. MUST be set to 1 if the packet contains coded picture parameters or slice data from a field in an interlaced frame. MUST be set to 0 if the packet contains data from any part of a progressive frame.
I:1位。如果数据包包含隔行扫描帧中字段的编码图片参数或切片数据，则必须设置为1。如果数据包包含来自渐进帧任何部分的数据，则必须设置为0。
F: 1 bit. MUST be set to 1 if the packet contains coded picture parameters or slice data from the second field of an interlaced frame. MUST be set to 0 if the packet contains data from the first field of an interlaced frame or any part of a progressive frame.
F:1位。如果数据包包含隔行扫描帧的第二个字段的编码图片参数或切片数据，则必须设置为1。如果数据包包含来自隔行扫描帧的第一个字段或逐行扫描帧的任何部分的数据，则必须设置为0。
Parse Code (PC): 8 bits. Contains a Parse Code that MUST be the value indicated for the type of data in the packet.
解析代码（PC）：8位。包含解析代码，该代码必须是为数据包中的数据类型指示的值。
Data Length: 32 bits. For an auxiliary Data Unit, this contains the number of bytes of data contained in the payload section of this packet. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then no Auxiliary Data Unit will be large enough to cause a packet to exceed the MTU of the network.
数据长度：32位。对于辅助数据单元，它包含此数据包的有效负载部分中包含的数据字节数。如果遵循第4.4节（“流约束”）中的建议，则任何辅助数据单元都不会大到足以导致数据包超过网络的MTU。
Picture Number: 32 bits. MUST contain the Picture Number for the coded picture this packet contains data for, as described in Section 12.1 of the VC-2 specification [VC2].
图片编号：32位。必须包含该数据包包含数据的编码图片的图片编号，如VC-2规范[VC2]第12.1节所述。
The sender MUST send at least one transform-parameters packet for each coded picture and MAY include more than one as long as they contain identical data. The sender MUST NOT send a packet from a new picture until all the coded data from the current picture has been sent.
发送方必须为每个编码图片发送至少一个变换参数包，并且可以包括多个变换参数包，只要它们包含相同的数据。在当前图片的所有编码数据发送完毕之前，发送方不得发送来自新图片的数据包。
If the receiver receives Coded Slices packets for a picture but does not receive a Transform Parameters packet for that picture, then this is an indication of either packet loss, joining a Stream mid-picture, or a non-compliant transmitter. In this case, the receiver MAY assume that the parameters are unchanged since the last picture, or it MAY discard the picture. Choosing between these two options is left up to the implementation as it will be dependent on intended use. The former may result in malformed pictures, while the latter will result in dropped frames.
如果接收器接收到图片的编码切片数据包，但没有接收到该图片的变换参数数据包，则这是数据包丢失、加入流中间图片或不符合发射机的指示。在这种情况下，接收机可以假设自最后一张图片以来参数没有改变，或者可以丢弃该图片。这两个选项之间的选择取决于实现，因为它将取决于预期用途。前者可能会导致图片格式错误，而后者则会导致帧丢失。
Slice Prefix Bytes: 16 bits. MUST contain the Slice Prefix Bytes value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification [VC2].
切片前缀字节：16位。必须包含该数据包包含数据的编码图片的切片前缀字节值，如VC-2规范[VC2]第12.3.4节所述。
In the VC-2 specification, this value is not restricted to 16 bits, but the constraints on Streams specified in this document (Section 4.4) do require this.
在VC-2规范中，该值不限于16位，但本文件（第4.4节）中规定的流约束确实需要该值。
Slice Size Scaler: 16 bits. MUST contain the Slice Size Scaler value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification [VC2].
切片大小定标器：16位。必须包含该数据包包含数据的编码图片的切片大小定标器值，如VC-2规范[VC2]第12.3.4节所述。
In the VC-2 specification, this value is not restricted to 16 bits, but the constraints on Streams specified in this document (Section 4.4) do require this.
在VC-2规范中，该值不限于16位，但本文件（第4.4节）中规定的流约束确实需要该值。
Fragment Length: 16 bits. MUST contain the number of bytes of data contained in the coded payload section of this packet.
片段长度：16位。必须包含此数据包的编码有效负载部分中包含的数据字节数。
No. of Slices: 16 bits. MUST contain the number of Coded Slices contained in this packet, which MUST be 0 for a packet containing Transform Parameters. In a packet containing Coded Slices, this number MUST be the number of whole slices contained in the packet, and the packet MUST NOT contain any partial slices.
片数：16位。必须包含此数据包中包含的编码片数，对于包含转换参数的数据包，该值必须为0。在包含编码切片的数据包中，此数字必须是数据包中包含的整个切片的数量，并且数据包不得包含任何部分切片。
Slice Offset X: 16 bits. MUST contain the X coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture.
切片偏移量X:16位。必须包含此数据包中第一个切片的X坐标，以切片为单位，从图片的左上角开始。
Slice Offset Y: 16 bits. MUST contain the Y coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture.
切片偏移量Y:16位。必须包含此数据包中第一个切片的Y坐标，以切片为单位，从图片的左上角开始。
The "PC" field in the packets is used to carry the Parse Code, which identifies the type of content in the packet. This code matches the value of the Parse Code used to identify each Data Unit in a VC-2 Stream, as defined in the VC-2 specification, and each packet contains the entire Data Unit.
数据包中的“PC”字段用于携带解析代码，该代码标识数据包中的内容类型。此代码与用于标识VC-2流中每个数据单元（如VC-2规范中所定义）的解析代码的值相匹配，并且每个数据包包含整个数据单元。
Figure 7 lists all of the Parse Codes currently allowed in a VC-2 Sequence. The final column indicates whether the code in question can be present in a Stream transmitted using this specification.
图7列出了VC-2序列中当前允许的所有解析代码。最后一列指示所讨论的代码是否可以出现在使用此规范传输的流中。
+----------+-----------+---------------------+---------------+
| PC (hex) | Binary | Description | Valid |
+----------+-----------+---------------------+---------------+
| 0x00 | 0000 0000 | Sequence Header | Yes |
| 0x10 | 0001 0000 | End of Sequence | Yes |
| 0x20 | 0010 0000 | Auxiliary Data | Yes |
| 0x30 | 0011 0000 | Padding Data | Yes |
+----------+-----------+---------------------+---------------+
| 0xC8 | 1100 1000 | LD Picture | No |
| 0xE8 | 1110 1000 | HQ Picture | No |
| 0xEC | 1110 1100 | HQ Picture Fragment | Yes |
+----------+-----------+---------------------+---------------+
+----------+-----------+---------------------+---------------+
| PC (hex) | Binary | Description | Valid |
+----------+-----------+---------------------+---------------+
| 0x00 | 0000 0000 | Sequence Header | Yes |
| 0x10 | 0001 0000 | End of Sequence | Yes |
| 0x20 | 0010 0000 | Auxiliary Data | Yes |
| 0x30 | 0011 0000 | Padding Data | Yes |
+----------+-----------+---------------------+---------------+
| 0xC8 | 1100 1000 | LD Picture | No |
| 0xE8 | 1110 1000 | HQ Picture | No |
| 0xEC | 1110 1100 | HQ Picture Fragment | Yes |
+----------+-----------+---------------------+---------------+
Figure 7: Parse Codes and Meanings
图7：解析代码和含义
A Sequence needs to conform to certain constraints in order to be transmissible with this specification.
序列需要符合某些约束条件，才能根据本规范进行传输。
o The Sequence MUST NOT contain Parse Info Headers with a Parse Code other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 (Auxiliary Data), 0x30 (Padding Data), or 0xEC (High Quality Picture Fragment). Some other Streams MAY be convertible to meet this restriction (see below).
o 序列不得包含解析代码不是0x00（序列头）、0x10（序列结束）、0x20（辅助数据）、0x30（填充数据）或0xEC（高质量图片片段）的解析信息头。一些其他流可以转换以满足此限制（见下文）。
o Every High Quality Picture Fragment MUST be no longer than 65535 bytes. This can usually be ensured by splitting large Fragments into several smaller Fragments, except in the case where an individual slice is too large, in which case see the notes below on conversion.
o 每个高质量图片片段的长度不得超过65535字节。这通常可以通过将大片段分割成几个小片段来确保，除非单个片段太大，在这种情况下，请参见下面关于转换的注释。
o Informative note: this requirement ensures that every High Quality Picture Fragment will always contain no more than 65535 slices.
o 资料性说明：此要求确保每个高质量图片片段始终包含不超过65535个切片。
o Every High Quality Picture Fragment SHOULD be small enough that the RTP packet carrying it will fit within the network MTU size. This can usually be ensured by splitting large Fragments into several smaller Fragments, except in the case where an individual slice is too large, in which case see the notes below on conversion.
o 每个高质量图片片段都应该足够小，以便承载它的RTP数据包能够适合网络MTU大小。这通常可以通过将大片段分割成几个小片段来确保，除非单个片段太大，在这种情况下，请参见下面关于转换的注释。
o Every High Quality Picture Fragment MUST be encoded using values for Slice Prefix Bytes and Slice Size Scaler no greater than 65535.
o 必须使用切片前缀字节和切片大小定标器不大于65535的值对每个高质量图片片段进行编码。
If a Sequence intended for transmission does not conform to these restrictions, then it MAY be possible to simply convert it into a form that does by splitting pictures and/or large Fragments into suitably sized Fragments. This can be done provided that the following (weaker) constraints are met:
如果拟用于传输的序列不符合这些限制，则可以简单地将其转换为通过将图片和/或大片段分割成适当大小的片段来实现的形式。如果满足以下（较弱的）约束条件，则可以执行此操作：
o The Sequence does not contain Parse Info Headers with a Parse Code other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 (Auxiliary Data), 0x30 (Padding Data), 0xE8 (High Quality Picture), or 0xEC (High Quality Picture Fragment).
o 序列不包含解析代码不是0x00（序列头）、0x10（序列结束）、0x20（辅助数据）、0x30（填充数据）、0xE8（高质量图片）或0xEC（高质量图片片段）的解析信息头。
o None of the High Quality Pictures or High Quality Picture Fragments contain slices that are individually longer than 65535 bytes. Note: When this is the case, the values of Slice Prefix Bytes and Slice Size Scaler will necessarily also be smaller than 65535.
o 高质量图片或高质量图片片段均不包含单独长度超过65535字节的片段。注意：在这种情况下，片前缀字节和片大小定标器的值也必然小于65535。
o None of the High Quality Pictures or High Quality Picture Fragments contain slices that are individually so large that an RTP packet carrying a Fragment containing that single slice will fit within the network MTU size.
o 高质量图片或高质量图片片段均不包含单独如此大的片段，以至于携带包含该单个片段的片段的RTP数据包将适合网络MTU大小。
It is not possible to send a Stream that does not meet the above requirements via this mechanism unless the Stream is re-encoded by a VC-2 Encoder so as to meet them.
除非流由VC-2编码器重新编码以满足上述要求，否则不可能通过该机制发送不满足上述要求的流。
In addition, every Auxiliary Data Unit SHOULD be small enough that a single RTP packet carrying it will fit within the network MTU size. Since there is currently no specification for the format of Auxiliary Data in VC-2, the mechanism for ensuring this with an encoder implementation that includes Auxiliary Data Units will be dependent upon the implementation's use for them.
此外，每个辅助数据单元应足够小，以使携带它的单个RTP数据包适合网络MTU大小。由于目前VC-2中没有辅助数据格式的规范，因此使用包含辅助数据单元的编码器实现来确保这一点的机制将取决于实现对辅助数据单元的使用。
When encoding VC-2 video intended to be transported via RTP, a VC-2 profile and level that ensures these requirements are met SHOULD be used.
当编码拟通过RTP传输的VC-2视频时，应使用确保满足这些要求的VC-2配置文件和级别。
For the Sequence Header packet type (PC = 0x00), the payload data MUST be the coded Sequence Header exactly as it appears in the VC-2 Sequence.
对于序列头数据包类型（PC=0x00），有效负载数据必须是编码序列头，与VC-2序列中显示的数据完全相同。
For the Transform Parameters packet type (PC = 0xEC and No. of Slices = 0), the payload data MUST be the variable-length coded Transform Parameters. This MUST NOT include the Fragment header (since all data in the picture header is already included in the packet header).
对于转换参数包类型（PC=0xEC，切片数=0），有效负载数据必须是可变长度编码的转换参数。这不能包括片段头（因为图片头中的所有数据都已经包含在数据包头中）。
For the Auxiliary Data packet type (PC = 0x20), the payload data MUST be a portion of the auxiliary data bytes contained in the Auxiliary Data Unit being transmitted. The B flag MUST be set on the packet that contains the first byte, the E flag MUST be set on the packet that contains the last byte, the bytes MUST be included in order, and the packets MUST have contiguous sequence numbers.
对于辅助数据分组类型（PC=0x20），有效负载数据必须是包含在正在传输的辅助数据单元中的辅助数据字节的一部分。必须在包含第一个字节的数据包上设置B标志，在包含最后一个字节的数据包上设置E标志，必须按顺序包含这些字节，并且数据包必须具有连续的序列号。
For the Picture Fragment packet type (PC = 0xEC and No. of Slices > 0), the payload data MUST be a specified number of Coded Slices in the same order that they appear in the VC-2 Stream. Which slices appear in the packet is identified using the Slice Offset X and Slice Offset Y fields in the payload header.
对于图片片段数据包类型（PC=0xEC，片数>0），有效载荷数据必须是指定数量的编码片，其顺序与它们在VC-2流中出现的顺序相同。使用有效负载报头中的Slice Offset X和Slice Offset Y字段识别数据包中出现的切片。
For the End of Sequence packet type (PC = 0x10), there is no payload data.
对于序列结束数据包类型（PC=0x10），没有有效负载数据。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x42 | 0x42 | 0x43 | 0x44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parse Code | Next Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prev Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x42 | 0x42 | 0x43 | 0x44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parse Code | Next Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prev Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
Figure 8: VC-2 Parse Info Header
图8:VC-2解析信息头
To reassemble the data in the RTP packets into a valid VC-2 Sequence:
要将RTP数据包中的数据重新组合为有效的VC-2序列：
o The receiver SHOULD take the data from each packet with a Parse Code of 0x00 and prepend a valid VC-2 Parse Info Header (Figure 8) with the same Parse Code (0x00). The resulting Sequence Header Parse Info Header and Data Unit MUST be included in the output stream before any coded pictures that followed the packet being processed in the RTP stream, unless an identical Sequence Header has already been included, and they MAY be repeated (with appropriate modifications to the next and previous header offsets) at any point that results in a valid VC-2 Stream.
o 接收方应从解析代码为0x00的每个数据包中获取数据，并使用相同的解析代码（0x00）预先发送一个有效的VC-2解析信息头（图8）。结果序列头Parse Info头和数据单元必须在RTP流中处理的包之后的任何编码图片之前包含在输出流中，除非已经包含相同的序列头，并且可以重复它们（对下一个和上一个头偏移进行适当修改）在任何导致有效VC-2流的点。
o The receiver SHOULD take the data from each packet with a Parse Code of 0xEC and No. of Slices set to 0 (which together indicate that this packet contains the Transform Parameters for a coded picture) and prepend with the same Parse Code a valid VC-2 Parse Info Header (Figure 8) followed by the picture number, Fragment data length, and slice count (0).
o 接收器应从解析代码为0xEC且切片数设置为0的每个数据包中获取数据（这一起表明该数据包包含编码图片的转换参数），并使用相同的解析代码预先发送一个有效的VC-2解析信息头（图8），后跟图片编号、片段数据长度、，和切片计数（0）。
o The receiver SHOULD take the data from each packet with a Parse Code of 0xEC and No. of Slices not set to 0 (which together indicate that this packet contains Coded Slices) and prepend with the same Parse Code a valid VC-2 Parse Info Header (Figure 8) followed by the picture number, Fragment data length, slice count, x offset and y offset taken from the packet header.
o 接收器应从解析代码为0xEC且片数未设置为0的每个数据包中获取数据（这一起表明该数据包包含编码片），并使用相同的解析代码预先发送一个有效的VC-2解析信息头（图8），后跟图片编号、片段数据长度、片数、，从数据包头获取的x偏移量和y偏移量。
o A receiver MAY combine all Fragment Data Units (with Parse Code 0xEC) and the same picture number into a single picture Data Unit with Parse Code 0xE8. If the Stream is required to comply with major versions 1 or 2 of the VC-2 specification, then this MUST be done.
o 接收器可以将所有片段数据单元（解析代码为0xEC）和相同的图片编号组合成一个解析代码为0xE8的图片数据单元。如果要求流符合VC-2规范的主要版本1或2，则必须这样做。
o The receiver SHOULD take the data from each packet with a Parse Code of 0x20 and the B bit set and prepend a valid VC-2 Parse Info Header (Figure 8) with the Parse Code 0x20, and then take each subsequent packet with Parse Code 0x20 without the B bit set and append its payload to the growing Data Unit. When all packets for a particular Data Unit have been received, it SHOULD be included in the output stream. The final packet for a Data Unit will have the E bit set.
o 接收器应从解析代码为0x20且B位设置为的每个数据包中获取数据，并用解析代码0x20预先添加一个有效的VC-2 Parse Info头（图8），然后获取解析代码为0x20且没有B位设置的每个后续数据包，并将其有效负载附加到不断增长的数据单元中。当接收到特定数据单元的所有数据包时，应将其包括在输出流中。数据单元的最终数据包将设置E位。
o Once a Data Unit has been assembled, whether a Sequence Header, Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the next parse offset and previous parse offset values in its Parse Info Header SHOULD be filled with the offset between the start of the header and the start of the next or previous header.
o 数据单元组装完成后，无论是序列头、编码图片片段、编码图片还是辅助数据单元，其解析信息头中的下一个解析偏移量和上一个解析偏移量值都应填充头的开始和下一个或上一个头的开始之间的偏移量。
o An End of Sequence Parse Info Header MAY be inserted when a packet with Parse Code set to 0x10 is encountered, or at any other time that is allowed in a valid VC-2 Stream. After an End of Sequence Parse Info Header is included in the output stream, either the Stream must end, or it MUST be followed by a Sequence Header indicating the start of a new Sequence. The next parse offset of the End of Sequence header MUST be set to 0, and the previous parse offset SHOULD be filled with the offset from the start of the previous Parse Info Header in the Stream.
o 当遇到解析代码设置为0x10的数据包时，或在有效VC-2流中允许的任何其他时间，可以插入序列结束解析信息头。在输出流中包含序列结束解析信息头之后，该流必须结束，或者后面必须有一个序列头，指示新序列的开始。序列结束标头的下一个解析偏移量必须设置为0，并且上一个解析偏移量应使用流中上一个解析信息标头开始处的偏移量填充。
o A Padding Data Parse Info Header MAY be inserted when a packet with Parse Code set to 0x30 and the B bit set is encountered, or at any other time that is allowed in a valid VC-2 Stream. The
o 当遇到解析代码设置为0x30且B位设置为的数据包时，或在有效VC-2流中允许的任何其他时间，可以插入填充数据解析信息头。这个
length of the accompanying Data Unit MAY have any value, and its contents MUST be set to a series of zero bytes. The next parse offset and previous parse offset values in its Parse Info Header SHOULD be filled with the offset between the start of the header and the start of the next or previous header.
随附数据单元的长度可以有任何值，其内容必须设置为一系列零字节。解析信息头中的下一个解析偏移量和上一个解析偏移量值应该用头的开始和下一个或上一个头的开始之间的偏移量填充。
VC-2 provides no underlying protection against data loss, so it may be useful to employ Forward Error Correction to the Stream. A mechanism for doing this to a generic RTP stream is specified in RFC 5109 [RFC5109]. If making use of this mechanism to provide multilevel protection, then the packets SHOULD be assigned to layers based upon their packet type, with the packet types being, in order of importance:
VC-2不提供防止数据丢失的底层保护，因此对流进行前向纠错可能是有用的。RFC 5109[RFC5109]中规定了对通用RTP流执行此操作的机制。如果利用此机制提供多级保护，则应根据数据包类型将数据包分配给各层，数据包类型按重要性顺序为：
1. Sequence Headers
1. 序列头
2. Fragments containing Transform Parameters
2. 包含转换参数的片段
3. Fragments containing Coded Slices
3. 包含编码片段的片段
4. Auxiliary Data and end of Sequence
4. 辅助数据和序列结束
5. Padding
5. 衬料
It is RECOMMENDED that if multilevel protection is to be used, then one layer will protect all Sequence Header packets, and a second will protect Sequence Headers and all Fragments. If desired, a third layer MAY protect Auxiliary Data and End of Sequence packets. Padding data SHOULD NOT be protected by FEC.
建议如果使用多级保护，则一层将保护所有序列头数据包，第二层将保护序列头和所有片段。如果需要，第三层可以保护辅助数据和序列结束分组。填充数据不应受到FEC的保护。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550] and any applicable RTP profile -- e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [RFC8083] are an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams, and applications implementing this standard MUST comply with it. RFC 8085 [RFC8085] provides additional information on the best practices for applying congestion control to UDP streams.
RTP的拥塞控制应根据RFC 3550[RFC3550]和任何适用的RTP配置文件（如RFC 3551[RFC3551]）使用。如果使用尽力而为服务，另一个要求是：此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。断路器[RFC8083]是对RTP[RFC3550]的更新，它定义了何时需要停止发送RTP数据包流的标准，实现该标准的应用程序必须遵守该标准。RFC 8085[RFC8085]提供了有关将拥塞控制应用于UDP流的最佳实践的附加信息。
In particular, it should be noted that the expected data rate for RTP sessions that use this profile is likely to be in the range of gigabits per second. If used on a closed network that has been correctly provisioned for the expected data rates, this might not pose a problem, but there is always the risk of data getting out onto the open internet.
特别是，应该注意，使用此配置文件的RTP会话的预期数据速率可能在每秒千兆位的范围内。如果在已为预期数据速率正确设置的封闭网络上使用，这可能不会造成问题，但始终存在数据泄露到开放internet的风险。
This RTP payload format is identified using the 'video/vc2' media type, which is registered in accordance with RFC 4855 [RFC4855], using the template of RFC 6838 [RFC6838].
该RTP有效负载格式使用“视频/vc2”媒体类型标识，该媒体类型根据RFC 4855[RFC4855]注册，使用RFC 6838[RFC6838]模板。
Type name:
类型名称：
video
视频
Subtype name:
子类型名称：
vc2
vc2
Required parameters:
所需参数：
rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000.
速率：RTP时间戳时钟速率。使用此有效负载格式的应用程序应使用90000的值。
profile: The VC-2 profile in use. The only value currently allowed is "HQ".
配置文件：正在使用的VC-2配置文件。当前唯一允许的值是“HQ”。
Optional parameters:
可选参数：
version: the VC-2 specification version in use. The only currently allowed value is "3" since all Sequences transported using this mechanism will contain HQ Picture Fragment Data Units, which the VC-2 specification [VC2] defines as requiring version 3.
版本：正在使用的VC-2规范版本。目前唯一允许的值是“3”，因为使用该机制传输的所有序列都将包含HQ图片片段数据单元，VC-2规范[VC2]将其定义为需要版本3。
level: The VC-2 level in use. Any integer may be used.
级别：正在使用的VC-2级别。可以使用任何整数。
Encoding considerations:
编码注意事项：
This media type is framed and binary; see Section 4.8 in RFC 6838 [RFC6838].
这种媒体类型是框架和二进制的；参见RFC 6838[RFC6838]中的第4.8节。
Security considerations:
安全考虑：
Please see the security considerations in RFC 8450.
请参阅RFC 8450中的安全注意事项。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification:
已发布的规范：
RFC 8450
RFC 8450
Applications that use this media type:
使用此媒体类型的应用程序：
Video Communication.
视频通信。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information: N/A
其他信息：不适用
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
James P. Weaver <james.barrett@bbc.co.uk>
James P. Weaver <james.barrett@bbc.co.uk>
Intended usage:
预期用途：
COMMON
常见的
Restrictions on usage:
使用限制：
This media type depends on RTP framing and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author:
作者：
James P. Weaver <james.barrett@bbc.co.uk>
James P. Weaver <james.barrett@bbc.co.uk>
Change controller:
更改控制器：
IETF PAYLOAD Working Group delegated from the IESG.
IESG授权的IETF有效载荷工作组。
Provisional registration? (standards tree only):
临时登记？（仅限标准树）：
No
不
The mapping of the above-defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].
应根据RFC 4855[RFC4855]第3节的规定，映射上述定义的有效负载格式媒体类型及其参数。
o The type name ("video") goes in SDP "m=" as the media name.
o 类型名称（“视频”）以SDP“m=”作为媒体名称。
o The subtype name ("vc2") goes in SDP "a=rtpmap" as the encoding name, followed by a slash ("/") and the rate parameter.
o 子类型名称（“vc2”）以SDP“a=rtpmap”作为编码名称，后跟斜杠（“/”）和速率参数。
o The required parameter profile and the optional parameters version and level, when present, are included in the "a=fmtp" attribute line of SDP as a semicolon-separated list of parameter=value pairs.
o 所需的参数配置文件和可选参数版本和级别（如果存在）以分号分隔的参数=值对列表的形式包含在SDP的“a=fmtp”属性行中。
Version and level SHALL be specified in decimal when present.
版本和级别应以十进制表示。
For example, a sample SDP mapping for VC-2 could be as follows:
例如，VC-2的示例SDP映射可以如下所示：
m=video 30000 RTP/AVP 112
a=rtpmap:112 vc2/90000
a=fmtp:112 profile=HQ;version=3;level=0
m=video 30000 RTP/AVP 112
a=rtpmap:112 vc2/90000
a=fmtp:112 profile=HQ;version=3;level=0
In this example, a dynamic payload type 112 is used for vc-2 data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. In the "a=fmtp:" line, profile HQ, version 3, and level 0 (unknown or non-standard level) are specified.
在此示例中，动态有效负载类型112用于vc-2数据。90 kHz RTP时间戳速率在子类型后的“a=rtpmap”行中指定。在“a=fmtp:”行中，指定了配置文件HQ、版本3和级别0（未知或非标准级别）。
All parameters are declarative.
所有参数都是声明性的。
IANA has registered 'video/vc2' as specified in Section 7.1. The media type has been added to the IANA registry for "RTP Payload Format Media Types" <https://www.iana.org/assignments/rtp-parameters>.
IANA已按照第7.1节的规定注册了“视频/vc2”。媒体类型已添加到IANA注册表中，用于“RTP有效负载格式媒体类型”<https://www.iana.org/assignments/rtp-parameters>.
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and 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]
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适用RTP配置文件（如RTP/AVP[RFC3551]、RTP/AVPF[RFC4585]、RTP/SAVP[RFC3711]或RTP/SAVPF[RFC5124]中讨论的安全注意事项的约束。然而，正如“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”[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 lies with 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的机密性、完整性和源真实性。任何在应用程序中使用RTP的人都有责任。他们可以在“保护RTP会话的选项”[RFC7201]中找到关于可用安全机制和重要注意事项的指导。应用程序应使用一个或多个适当的强安全机制。本节的其余部分将讨论影响有效负载格式本身安全性的属性。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
该RTP有效载荷格式及其媒体解码器在用于分组处理的接收器端计算复杂度方面不表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁。RTP有效负载格式也不包含任何活动内容。
To avoid buffer overruns when processing these packets, the receiver MUST consider both the reported Fragment length and the actual received size of a packet containing slice data.
为了避免处理这些分组时的缓冲区溢出，接收机必须考虑报告的片段长度和包含切片数据的包的实际接收大小。
In some cases, the transmitter may need to decode variable-length coded headers in order to extract some data from the VC-2 bitstream before assembling packets. This process is potentially subject to buffer overruns if not implemented carefully.
在某些情况下，发射机可能需要解码可变长度编码报头，以便在组装分组之前从VC-2比特流中提取一些数据。如果不小心实施，此过程可能会发生缓冲区溢出。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://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月<https://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, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<https://www.rfc-editor.org/info/rfc3551>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855]Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，DOI 10.17487/RFC4855，2007年2月<https://www.rfc-editor.org/info/rfc4855>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<https://www.rfc-editor.org/info/rfc6838>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083]Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话的断路器”，RFC 8083，DOI 10.17487/RFC8083，2017年3月<https://www.rfc-editor.org/info/rfc8083>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[VC2] SMPTE, "SMPTE Standard - VC-2 Video Compression", ST 2042-1:2017, DOI 10.5594/SMPTE.ST2042-1.2017, June 2017, <https://ieeexplore.ieee.org/servlet/ opac?punumber=7967894>.
[VC2]SMPTE，“SMPTE标准-VC-2视频压缩”，ST 2042-1:2017，DOI 10.5594/SMPTE.ST2042-1.2017，2017年6月<https://ieeexplore.ieee.org/servlet/ opac？punumber=7967894>。
[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, <https://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月<https://www.rfc-editor.org/info/rfc3711>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc4585>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<https://www.rfc-editor.org/info/rfc5109>.
[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, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<https://www.rfc-editor.org/info/rfc5124>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<https://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, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，DOI 10.17487/RFC7202，2014年4月<https://www.rfc-editor.org/info/rfc7202>.
Author's Address
作者地址
James P. Weaver BBC
詹姆斯·P·韦弗英国广播公司
Email: james.barrett@bbc.co.uk
Email: james.barrett@bbc.co.uk