Internet Engineering Task Force (IETF) T. Edwards
Request for Comments: 8331 FOX
Category: Standards Track February 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Edwards
Request for Comments: 8331 FOX
Category: Standards Track February 2018
ISSN: 2070-1721
RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data
电影和电视工程师协会（SMPTE）ST 291-1辅助数据的RTP有效载荷
Abstract
摘要
This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).
本备忘录描述了电影电视工程师协会（SMPTE）辅助空间（ANC）数据的实时传输协议（RTP）有效载荷格式，如SMPTE ST 291-1所定义。SMPTE ANC数据通常与专业视频格式一起使用，以承载一系列辅助数据类型，包括时间码、闭路字幕和活动格式描述（AFD）。
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/rfc8331.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8331.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 4
2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5
3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. Grouping ANC Data Streams with Other Media Streams . . . 15
5. Offer/Answer Model and Declarative Considerations . . . . . . 15
5.1. Offer/Answer Model . . . . . . . . . . . . . . . . . . . 15
5.2. Declarative SDP Considerations . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 4
2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5
3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. Grouping ANC Data Streams with Other Media Streams . . . 15
5. Offer/Answer Model and Declarative Considerations . . . . . . 15
5.1. Offer/Answer Model . . . . . . . . . . . . . . . . . . . 15
5.2. Declarative SDP Considerations . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1 [ST291]. ANC data is transmitted in the ancillary space of serial digital video interfaces, the space outside of the active video region of images intended for users to view. Ancillary space roughly corresponds to vertical and horizontal blanking periods of cathode ray tube type displays. ANC data can carry a range of data types, including time code, Closed Captioning, and the Active Format Description (AFD).
本备忘录描述了电影电视工程师协会（SMPTE）辅助空间（ANC）数据的实时传输协议（RTP）有效载荷格式，如SMPTE ST 291-1[ST291]所定义。ANC数据在串行数字视频接口的辅助空间中传输，该空间是供用户查看的图像的活动视频区域之外的空间。辅助空间大致相当于阴极射线管型显示器的垂直和水平消隐周期。ANC数据可以携带一系列数据类型，包括时间代码、闭路字幕和活动格式描述（AFD）。
ANC data is generally associated with the carriage of metadata within the bit stream of a Serial Digital Interface (SDI), such as the standard definition (SD) Serial Digital Interface, the 1.5 Gb/s Serial Digital Interface for high definition (HD) television applications, or the 3 Gb/s Signal/Data Serial Interface (SMPTE ST 259 [ST259], SMPTE ST 292-1 [ST292], and SMPTE ST 424 [ST424]).
ANC数据通常与串行数字接口（SDI）位流中的元数据传输相关，例如标准清晰度（SD）串行数字接口、高清晰度（HD）电视应用的1.5 Gb/s串行数字接口或3 Gb/s信号/数据串行接口（SMPTE ST 259[ST259]），SMPTE ST 292-1[ST292]和SMPTE ST 424[ST424]）。
ANC data packet payload definitions for a specific application are specified by a SMPTE Standard, Recommended Practice, Registered Disclosure Document, or by a document generated by another organization, a company, or an individual (an entity). When a payload format is registered with SMPTE, it is identified by a registered data identification word.
特定应用的ANC数据包有效载荷定义由SMPTE标准、推荐规程、注册披露文件或由其他组织、公司或个人（实体）生成的文件规定。当有效负载格式向SMPTE注册时，它由注册的数据标识字标识。
This memo describes an RTP payload that supports carriage of ANC data packets that originate from any location within any SMPTE-defined SDI signal. This payload also supports the carriage of ANC data packets that did not originate from an SDI signal. Sufficient information is provided to enable the ANC data packets at the output of the decoder to be restored to their original locations in the serial digital video signal raster (if that is desired). An optional media type parameter allows for the signaling of carriage of one or more types of ANC data as specified by data identification (DID) and secondary data identification (SDID) words. Another optional media type parameter allows for the identification of the Video Payload ID (VPID) code of the source interface of ANC data packets.
本备忘录描述了一种RTP有效载荷，该有效载荷支持传输源自任何SMPTE定义的SDI信号内任何位置的ANC数据包。该有效载荷还支持非源自SDI信号的ANC数据包的传输。提供足够的信息，使解码器输出处的ANC数据包能够恢复到其在串行数字视频信号光栅中的原始位置（如果需要）。可选媒体类型参数允许通过数据标识（DID）和辅助数据标识（SDID）字指定的一种或多种类型的ANC数据的传输信令。另一可选媒体类型参数允许识别ANC数据分组的源接口的视频有效负载ID（VPID）代码。
Note that the Ancillary Data Flag (ADF) word is not specifically carried in this RTP payload. The ADF might be specified in a document defining an interconnecting digital video interface; otherwise, a default ADF is specified by SMPTE ST 291-1 [ST291].
请注意，辅助数据标志（ADF）字未在该RTP有效载荷中具体携带。可以在定义互连数字视频接口的文档中指定ADF；否则，默认ADF由SMPTE ST 291-1[ST291]指定。
This ANC data payload can be used by itself or used along with a range of RTP video formats. In particular, it has been designed so that it could be used along with "RTP Payload Format for Uncompressed Video" [RFC4175] or "RTP Payload Format for JPEG 2000 Video Streams" [RFC5371].
该ANC数据有效载荷可以单独使用，也可以与一系列RTP视频格式一起使用。特别是，其设计可与“用于未压缩视频的RTP有效负载格式”[RFC4175]或“用于JPEG 2000视频流的RTP有效负载格式”[RFC5371]一起使用。
The data model in this document for the ANC data RTP payload is based on the data model of SMPTE ST 2038 [ST2038], which standardizes the carriage of ANC data packets in an MPEG-2 Transport Stream.
本文件中ANC数据RTP有效载荷的数据模型基于SMPTE ST 2038[ST2038]的数据模型，该模型标准化了MPEG-2传输流中ANC数据包的传输。
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]所述进行解释。
An example of the format of an RTP packet containing SMPTE ST 291 ANC data is shown below:
包含SMPTE ST 291 ANC数据的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length=32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANC_Count=2 | F | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Line_Number=9 | Horizontal_Offset |S| StreamNum=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DID | SDID | Data_Count=0x84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User_Data_Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum_Word | word_align |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Line_Number=10 | Horizontal_Offset |S| StreamNum=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DID | SDID | Data_Count=0x105 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User_Data_Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum_Word |word_align |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length=32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANC_Count=2 | F | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Line_Number=9 | Horizontal_Offset |S| StreamNum=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DID | SDID | Data_Count=0x84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User_Data_Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum_Word | word_align |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Line_Number=10 | Horizontal_Offset |S| StreamNum=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DID | SDID | Data_Count=0x105 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User_Data_Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum_Word |word_align |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SMPTE Ancillary Data RTP Packet Format
图1:SMPTE辅助数据RTP包格式
In this example, two ANC data packets are present. The first has four 10-bit User_Data_Words, and the second has five 10-bit User_Data_Words (note that few ANC data packets are this small; thus, this example does not reflect actual defined ANC data packets and does not specifically call out the DIDs and SDIDs). The ANC data packets are located on lines 9 and 10 of the SDI raster.
在此示例中，存在两个ANC数据包。第一个有四个10位用户数据字，第二个有五个10位用户数据字（注意，很少有ANC数据包这么小；因此，本示例不反映实际定义的ANC数据包，也不专门调用DID和SDID）。ANC数据包位于SDI光栅的第9行和第10行。
The term "network byte order" in the payload format SHALL refer to the Data Transmission Order as defined in Appendix B of RFC 791 [RFC0791].
有效载荷格式中的术语“网络字节顺序”应指RFC 791[RFC0791]附录B中定义的数据传输顺序。
RTP packet header fields SHALL be interpreted as per RFC 3550 [RFC3550], with the following specifics:
RTP数据包头字段应按照RFC 3550[RFC3550]进行解释，具体如下：
Timestamp: 32 bits The timestamp field is interpreted in a similar fashion to RFC 4175 [RFC4175]:
时间戳：32位时间戳字段的解释方式与RFC 4175[RFC4175]类似：
For progressive scan video, the timestamp denotes the sampling instant of the frame to which the ANC data in the RTP packet belongs. RTP packets MUST NOT include ANC data from multiple frames, and all RTP packets with ANC data belonging to the same frame MUST have the same timestamp.
对于逐行扫描视频，时间戳表示RTP分组中的ANC数据所属帧的采样时刻。RTP数据包不得包含来自多个帧的ANC数据，且具有属于同一帧的ANC数据的所有RTP数据包必须具有相同的时间戳。
For interlaced video, the timestamp denotes the sampling instant of the field to which the ANC data in the RTP packet belongs. RTP packets MUST NOT include ANC data packets from multiple fields, and all RTP packets belonging to the same field MUST have the same timestamp.
对于隔行扫描视频，时间戳表示RTP分组中的ANC数据所属的场的采样时刻。RTP数据包不得包含来自多个字段的ANC数据包，并且属于同一字段的所有RTP数据包必须具有相同的时间戳。
If the sampling instant does not correspond to an integer value of the clock, the value SHALL be truncated to the next lowest integer with no ambiguity. Section 3.1 describes timestamp clock rates.
如果采样瞬间与时钟的整数值不对应，则应将该值截断为下一个最低整数，且无歧义。第3.1节描述了时间戳时钟速率。
Marker bit (M): 1 bit The marker bit set to "1" indicates the last ANC data RTP packet for a frame (for progressive scan video) or the last ANC data RTP packet for a field (for interlaced video).
标记位（M）：1位设置为“1”的标记位表示帧的最后一个ANC数据RTP包（用于逐行扫描视频）或场的最后一个ANC数据RTP包（用于隔行扫描视频）。
The ANC data RTP payload header fields are defined as:
ANC数据RTP有效载荷标题字段定义为：
Extended Sequence Number: 16 bits The high-order bits of the extended 32-bit sequence number, in network byte order. This is the same as the Extended Sequence Number field in RFC 4175 [RFC4175].
扩展序列号：16位扩展32位序列号的高位，按网络字节顺序排列。这与RFC 4175[RFC4175]中的扩展序列号字段相同。
Length: 16 bits Number of octets of the ANC data RTP payload, beginning with the "C" bit of the first ANC packet data header, as an unsigned integer in network byte order. Note that all word_align fields contribute to the calculation of the Length field.
长度：ANC数据RTP有效载荷的16位八位组数，从第一个ANC数据包头的“C”位开始，作为网络字节顺序的无符号整数。请注意，所有word_align字段都有助于计算长度字段。
ANC_Count: 8 bits This field is the count of the total number of ANC data packets carried in the RTP payload, as an unsigned integer. A single ANC data RTP packet payload cannot carry more than 255 ANC data packets.
ANC_计数：8位此字段是RTP有效负载中承载的ANC数据包总数的计数，为无符号整数。单个ANC数据RTP数据包有效负载不能承载超过255个ANC数据包。
If more than 255 ANC data packets need to be carried in a field or frame, additional RTP packets carrying ANC data MAY be sent with the same RTP timestamp but with different sequence numbers. ANC_Count of 0 indicates that there are no ANC data packets in the payload (for example, an RTP packet that carries no actual ANC data packets even though its marker bit indicates the last ANC data RTP packet in a field/ frame). If the ANC_Count is 0, the Length will also be 0.
如果在一个字段或帧中需要携带255个以上的ANC数据包，则携带ANC数据的附加RTP包可以使用相同的RTP时间戳但具有不同的序列号来发送。ANC_计数为0表示有效载荷中没有ANC数据包（例如，即使其标记位指示字段/帧中的最后一个ANC数据RTP包，也不携带实际ANC数据包的RTP包）。如果ANC_计数为0，则长度也将为0。
F: 2 bits These two bits relate to signaling the field specified by the RTP timestamp in an interlaced SDI raster. A value of 0b00 indicates that either the video format is progressive or that no field is specified. A value of 0b10 indicates that the timestamp refers to the first field of an interlaced video signal. A value of 0b11 indicates that the timestamp refers to the second field of an interlaced video signal. The value 0b01 is not valid. Receivers SHOULD ignore an ANC data packet with an F field value of 0b01 and SHOULD process any other ANC data packets with valid F field values that are present in the RTP payload.
F:2位这两位与隔行扫描SDI光栅中RTP时间戳指定的字段相关。值0b00表示视频格式为渐进式或未指定任何字段。值0b10表示时间戳指隔行扫描视频信号的第一个字段。值0b11表示时间戳指隔行扫描视频信号的第二字段。值0b01无效。接收机应忽略F字段值为0b01的ANC数据包，并应处理RTP有效载荷中存在的具有有效F字段值的任何其他ANC数据包。
Note that some multi-stream SDI interfaces might use multiple interlaced signal streams to transmit progressive images, in which case the "F" bits would refer to the field of the interlaced stream used for transport of the ANC data packet.
注意，一些多流SDI接口可以使用多个隔行扫描信号流来传输逐行扫描图像，在这种情况下，“F”位将指用于传输ANC数据分组的隔行扫描流的字段。
reserved: 22 bits The 22 reserved bits of value "0" follow the F field to ensure that the first ANC data packet header field in the payload begins 32-bit word-aligned with the start of the RTP header to ease implementation.
保留：22位值为“0”的22个保留位跟随F字段，以确保有效负载中的第一个ANC数据包报头字段开始与RTP报头的开头对齐的32位字，以便于实现。
For each ANC data packet in the payload, the following ANC data packet header fields MUST be present:
对于有效载荷中的每个ANC数据包，必须存在以下ANC数据包头字段：
C: 1 bit This flag, when set to "1", indicates that the ANC data corresponds to the color-difference data channel (C). When set to "0", this flag indicates either that the ANC data corresponds to the luma (Y) data channel, that the ANC data source is from an SD signal, or that the ANC data source has
C:1位此标志设置为“1”时，表示ANC数据对应于色差数据通道（C）。当设置为“0”时，该标志表示ANC数据对应于luma（Y）数据通道，ANC数据源来自SD信号，或者ANC数据源具有
no specific luma or color-difference data channels. For ANC data from a multi-stream interface source, the C flag SHALL refer to the channel of the stream used to transport the ANC data packet. For situations where there is no SDI source, if the ANC data type definition specifically requires the use of the C or Y data channel, the C flag SHALL reflect that requirement.
没有特定的亮度或色差数据通道。对于来自多流接口源的ANC数据，C标志应指用于传输ANC数据包的流的信道。对于没有SDI源的情况，如果ANC数据类型定义特别要求使用C或Y数据通道，C标志应反映该要求。
Line_Number: 11 bits This field contains the digital interface line number that corresponds to the location of the ANC data packet as an unsigned integer in network byte order.
Line_Number：11位此字段包含数字接口行号，该行号以网络字节顺序作为无符号整数，对应于ANC数据包的位置。
The following special Line_Number values indicate that the location of the ANC data packet is in certain generic vertical regions of the SDI raster:
以下特殊行_数值表示ANC数据包的位置在SDI光栅的某些通用垂直区域内：
+-------------+--------------------------------------------------------+
| Line_Number | ANC data packet generic vertical location |
+-------------+--------------------------------------------------------+
| 0x7FF | Without specific line location within the field or |
| | frame |
| | |
| 0x7FE | On any line in the range from the second line after |
| | the line specified for switching, as defined in SMPTE |
| | RP 168 [RP168], to the last line before active video, |
| | inclusive |
| | |
| 0x7FD | On a line number larger than can be represented in 11 |
| | bits of this field (if needed for future formats) |
+-------------+--------------------------------------------------------+
+-------------+--------------------------------------------------------+
| Line_Number | ANC data packet generic vertical location |
+-------------+--------------------------------------------------------+
| 0x7FF | Without specific line location within the field or |
| | frame |
| | |
| 0x7FE | On any line in the range from the second line after |
| | the line specified for switching, as defined in SMPTE |
| | RP 168 [RP168], to the last line before active video, |
| | inclusive |
| | |
| 0x7FD | On a line number larger than can be represented in 11 |
| | bits of this field (if needed for future formats) |
+-------------+--------------------------------------------------------+
Note that the lines that are available to convey ANC data are as defined in the applicable sample structure specification (e.g., SMPTE ST 274 [ST274], SMPTE ST 296 [ST296], ITU-R BT.656 [BT656]) and are possibly further restricted per SMPTE RP 168 [RP168].
注意，可用于传输ANC数据的线路如适用的样本结构规范（例如，SMPTE ST 274[ST274]、SMPTE ST 296[ST296]、ITU-R BT.656[BT656]）中所定义，并且可能根据SMPTE RP 168[RP168]进一步限制。
In multi-stream interfaces, this field refers to the line number that an ANC data packet is carried on within a particular data stream in the interface.
在多流接口中，该字段是指在接口中的特定数据流中承载ANC数据包的行号。
Horizontal_Offset: 12 bits This field defines the location of the ANC data packet in an SDI raster relative to the start of active video (SAV; a digital synchronizing signal present in SDI interfaces) as an unsigned integer in network byte order. A value of 0 means that the ADF of the ANC data packet begins immediately
水平偏移：12位该字段将ANC数据包在SDI光栅中相对于活动视频（SAV；SDI接口中存在的数字同步信号）开始的位置定义为网络字节顺序的无符号整数。值为0表示ANC数据包的ADF立即开始
following SAV. The horizontal offset from SAV is measured in terms of 10-bit words of the indicated data stream and data channel.
跟随SAV。SAV的水平偏移量根据指示数据流和数据通道的10位字进行测量。
The following special Horizontal_Offset values indicate that the location of the ANC data packet is in certain generic horizontal regions of the SDI raster:
以下特殊水平偏移值表示ANC数据包的位置在SDI光栅的某些通用水平区域内：
+-------------+--------------------------------------------------------+
| Horizontal_ | ANC data packet generic horizontal location |
| Offset | |
+-------------+--------------------------------------------------------+
| 0xFFF | Without specific horizontal location |
| | |
| 0xFFE | Within horizontal ancillary data space (HANC) as |
| | defined in SMPTE ST 291-1 [ST291] |
| | |
| 0xFFD | Within the ancillary data space located between SAV |
| | (Start of Active Video) and EAV (End of Active Video) |
| | markers of the serial digital interface |
| | |
| 0xFFC | Horizontal offset is larger than can be represented in |
| | the 12 bits of this field (if needed for future |
| | formats or for certain low frame rate 720p formats) |
+-------------+--------------------------------------------------------+
+-------------+--------------------------------------------------------+
| Horizontal_ | ANC data packet generic horizontal location |
| Offset | |
+-------------+--------------------------------------------------------+
| 0xFFF | Without specific horizontal location |
| | |
| 0xFFE | Within horizontal ancillary data space (HANC) as |
| | defined in SMPTE ST 291-1 [ST291] |
| | |
| 0xFFD | Within the ancillary data space located between SAV |
| | (Start of Active Video) and EAV (End of Active Video) |
| | markers of the serial digital interface |
| | |
| 0xFFC | Horizontal offset is larger than can be represented in |
| | the 12 bits of this field (if needed for future |
| | formats or for certain low frame rate 720p formats) |
+-------------+--------------------------------------------------------+
In multi-stream interfaces, this field refers to the horizontal location where an ANC data packet is placed on a line carried within a particular data stream in the interface.
在多流接口中，该字段是指ANC数据包被放置在接口中特定数据流中承载的线路上的水平位置。
Note that HANC data space will generally have higher luma sample numbers than any samples in the active digital line. Also note that SMPTE ST 296 [ST296] (1280 x 720 progressive active images) image sampling systems 7 and 8 (1280 x 720 progressive @ 24 fps and 1280 x 720 progressive @ 23.98 fps respectively) have a luma sample number maximum of 4124. It is unlikely that an actual implementation would have an ANC data packet begin at a Horizontal_Offset beyond 4091 (0xFFB) in these formats; should that occur, the Horizontal_Offset value 0xFFC can be used to signal a horizontal offset larger than can be represented in the field. Further note that the 12-bit field of Horizontal_Offset is kept that size in this memo to maintain easy conversion to/from SMPTE ST 2038 [ST2038], which also has a 12-bit Horizontal_Offset field.
请注意，HANC数据空间通常比活动数字线中的任何样本具有更高的luma样本数。还请注意，SMPTE ST 296[ST296]（1280 x 720渐进式活动图像）图像采样系统7和8（分别为1280 x 720渐进式@24 fps和1280 x 720渐进式@23.98 fps）的最大luma采样数为4124。在这些格式中，实际实现不太可能使ANC数据包以超过4091（0xFFB）的水平_偏移开始；如果出现这种情况，水平偏移值0xFFC可用于表示大于字段中可表示的水平偏移。进一步注意，水平_偏移的12位字段在本备忘录中保持该大小，以保持与SMPTE ST 2038[ST2038]之间的轻松转换，SMPTE ST 2038[ST2038]也具有12位水平_偏移字段。
S (Data Stream Flag): 1 bit This field indicates whether the data stream number of a multi-stream data mapping used to transport the ANC data packet is specified. If the S bit is '0', then the StreamNum field provides no guidance regarding the source data stream number of the ANC data packet. If the S bit is '1', then the StreamNum field carries information regarding the source data stream number of the ANC data packet.
S（数据流标志）：1位该字段指示是否指定了用于传输ANC数据包的多流数据映射的数据流编号。如果S位为“0”，则StreamNum字段不提供有关ANC数据包的源数据流编号的指导。如果S位为“1”，则StreamNum字段携带关于ANC数据分组的源数据流编号的信息。
StreamNum: 7 bits If the S bit (Data Stream Flag) is '1', then the StreamNum field MUST carry identification of the source data stream number of the ANC data packet. If the data stream is numbered, then the StreamNum field SHALL carry the number of the source data stream minus one. If the source multi-stream interface does not have numbered data streams, the following numbers SHALL be used in this field: '0' for link A data stream and '1' for link B data stream. For stereoscopic multi-stream interface formats that do not have numbered streams, the following numbers SHALL be used in this field: '0' for left eye stream and '1' for right eye stream.
StreamNum:7位如果S位（数据流标志）为“1”，则StreamNum字段必须包含ANC数据包的源数据流编号的标识。如果数据流已编号，则StreamNum字段应携带源数据流的编号减去1。如果源多流接口没有编号的数据流，则此字段中应使用以下编号：“0”表示链路A数据流，“1”表示链路B数据流。对于没有编号流的立体多流接口格式，此字段中应使用以下数字：“0”表示左眼流，“1”表示右眼流。
Note that in multi-link SDI connections, the physical link that a particular stream utilizes is typically specified by the interface standard. Also note that numbering of data streams is across the interface as a whole. For example, in the SMPTE ST 425-3 dual-link 3 Gb/s interface, the data streams are numbered 1-4 with data streams 1 and 2 on link 1 and data streams 3 and 4 on link 2.
注意，在多链路SDI连接中，特定流使用的物理链路通常由接口标准指定。还请注意，数据流的编号作为一个整体贯穿整个接口。例如，在SMPTE ST 425-3双链路3 Gb/s接口中，数据流编号为1-4，数据流1和2在链路1上，数据流3和4在链路2上。
An ANC data packet with the header fields Line_Number of 0x7FF and Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame.
报头字段行数为0x7FF、水平偏移量为0xFFF的ANC数据包应视为在字段或帧内没有任何特定位置的情况下携带。
For each ANC data packet in the payload, immediately after the ANC data packet header fields, the following data fields MUST be present with the fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word representing the 10-bit words carried in the ANC data packet, as per SMPTE ST 291-1 [ST291]:
根据SMPTE ST 291-1[ST291]，对于有效载荷中的每个ANC数据包，紧接在ANC数据包报头字段之后，以下数据字段必须与代表ANC数据包中携带的10位字的字段DID、SDID、数据计数、用户数据字和校验和字一起出现：
DID: 10 bits Data identification word
DID：10位数据标识字
SDID: 10 bits Secondary data identification word. Used only for a "Type 2" ANC data packet. Note that in a "Type 1" ANC data packet, this word will actually carry the data block number (DBN).
SDID：10位辅助数据标识字。仅用于“2型”ANC数据包。注意，在“1型”ANC数据包中，该字实际上携带数据块号（DBN）。
Data_Count: 10 bits The lower 8 bits of Data_Count, corresponding to bits b7 (MSB; most significant bit) through b0 (LSB; least significant bit) of the 10-bit Data_Count word, contain the actual count of 10-bit words in User_Data_Words. Bit b8 is the even parity for bits b7 through b0, and bit b9 is the inverse (logical NOT) of bit b8.
数据计数：10位数据计数的低8位，对应于10位数据计数字的位b7（MSB；最高有效位）到位b0（LSB；最低有效位），包含用户数据字中10位字的实际计数。位b8是位b7到b0的偶数奇偶校验，位b9是位b8的倒数（逻辑非）。
User_Data_Words: integer number of 10-bit words User_Data_Words (UDW) are used to convey information of a type as identified by the DID word or the DID and SDID words. The number of 10-bit words in the UDW is defined by the Data_Count field. The 10-bit words are carried in order starting with the most significant bit and ending with the least significant bit.
用户数据字：整数个10位字用户数据字（UDW）用于传递由DID字或DID和SDID字标识的类型的信息。UDW中的10位字数由数据计数字段定义。10位字按从最高有效位开始到最低有效位结束的顺序携带。
Checksum_Word: 10 bits The Checksum_Word can be used to determine the validity of the ANC data packet from the DID word through the UDW. It consists of 10 bits, where bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9 is the inverse (logical NOT) of bit b8. The checksum value is equal to the nine least significant bits of the sum of the nine least significant bits of the DID word, the SDID word, the Data_Count word, and all User_Data_Words in the ANC data packet. The checksum is initialized to zero before calculation, and any "end carry" resulting from the checksum calculation is ignored.
校验和字：10位校验和字可用于从DID字通过UDW确定ANC数据包的有效性。它由10位组成，其中位b8（MSB）到位b0（LSB）定义校验和值，位b9是位b8的倒数（逻辑非）。校验和值等于ANC数据包中DID字、SDID字、数据计数字和所有用户数据字的九个最低有效位之和的九个最低有效位。校验和在计算之前初始化为零，并且忽略校验和计算产生的任何“结束进位”。
At the end of each ANC data packet in the payload:
在有效载荷中每个ANC数据包的末尾：
word_align: bits as needed to complete 32-bit word Word_align contains enough "0" bits as needed to complete the last 32-bit word of an ANC data packet in the RTP payload. If an ANC data packet in the RTP payload ends and is aligned with a word boundary, there is no need to add any word alignment bits. Word align SHALL be used even for the last ANC data packet in an RTP packet. Word align SHALL NOT be used if there are zero ANC data packets being carried in the RTP packet.
字对齐：完成32位字字对齐所需的位包含足够的“0”位，以完成RTP有效负载中ANC数据包的最后32位字。如果RTP有效载荷中的ANC数据包结束并且与字边界对齐，则不需要添加任何字对齐位。即使RTP数据包中的最后一个ANC数据包也应使用“对齐”字。如果RTP数据包中携带零个ANC数据包，则不得使用“对齐”字。
When reconstructing an SDI signal based on this payload, it is important to place ANC data packets into the locations indicated by the ANC data packet header fields C, Line_Number and Horizontal_Offset, and also to follow the requirements of Section 7 of SMPTE ST 291-1 [ST291], "Ancillary Data Space Formatting (Component or Composite Interface)", which includes rules on the placement of initial ANC data into allowed spaces as well as the
当基于该有效载荷重构SDI信号时，重要的是将ANC数据分组放入ANC数据分组报头字段C、行数和水平偏移量指示的位置，并遵循SMPTE ST 291-1[ST291]第7节“辅助数据空间格式化（组件或复合接口）”的要求，其中包括将初始ANC数据放置到允许空间的规则以及
contiguity of ANC data packet sequences within those spaces in order to assure that the resulting ANC data packets in the SDI signal are valid. The optional media type parameter VPID_Code can inform receivers of the type of originating SDI interface. For multi-stream originating interfaces, the StreamNum field can provide information regarding which stream an ANC data packet can be placed in to match the ANC data location in the originating SDI interface.
这些空间内ANC数据分组序列的连续性，以确保SDI信号中产生的ANC数据分组有效。可选的媒体类型参数VPID_Code可以通知接收方发起SDI接口的类型。对于多流发起接口，StreamNum字段可以提供关于ANC数据包可以放置在哪个流中以匹配发起SDI接口中的ANC数据位置的信息。
Senders of this payload SHOULD transmit available ANC data packets as soon as practical to reduce end-to-end latency, especially if the receivers will be embedding the received ANC data packet into an SDI signal emission. One millisecond is a reasonable upper bound for the amount of time between when an ANC data packet becomes available to a sender and the emission of an RTP payload containing that ANC data packet.
该有效载荷的发送方应尽快发送可用的ANC数据包，以减少端到端延迟，尤其是当接收方将接收到的ANC数据包嵌入SDI信号发射时。一毫秒是从ANC数据分组对发送方可用到包含该ANC数据分组的RTP有效载荷的发射之间的时间量的合理上限。
ANC data packets with headers that indicate specific location within a field or frame SHOULD be sent in raster scan order, both in terms of packing position within an RTP packet and in terms of transmission time of RTP packets.
带有指示字段或帧内特定位置的报头的ANC数据包应以光栅扫描顺序发送，包括RTP包内的打包位置和RTP包的传输时间。
This RTP payload format is identified using the "video/smpte291" media type, which is registered in accordance with RFC 4855 [RFC4855]; the template defined in RFC 6838 [RFC6838] is used.
该RTP有效负载格式使用“视频/smpte291”媒体类型标识，该媒体类型根据RFC 4855[RFC4855]注册；使用RFC 6838[RFC6838]中定义的模板。
Note that the media type definition is in the "video" tree due to the expected use of SMPTE ST 291 Ancillary Data along with video formats.
注意，由于SMPTE ST 291辅助数据与视频格式的预期使用，媒体类型定义位于“视频”树中。
Type name: video
类型名称：视频
Subtype name: smpte291
子类型名称：smpte291
Required parameters:
所需参数：
Rate: RTP timestamp clock rate.
速率：RTP时间戳时钟速率。
When an ANC data RTP stream is to be associated with an RTP video stream, the RTP timestamp rates SHOULD be the same to ensure that ANC data packets can be associated with the appropriate frame or field. Otherwise, a 90 kHz rate SHOULD be used.
当ANC数据RTP流将与RTP视频流相关联时，RTP时间戳速率应相同，以确保ANC数据分组可以与适当的帧或字段相关联。否则，应使用90 kHz的频率。
Note that techniques described in RFC 7273 [RFC7273] can provide a common reference clock for multiple RTP streams intended for synchronized presentation.
注意，RFC 7273[RFC7273]中描述的技术可以为多个用于同步表示的RTP流提供公共参考时钟。
Optional parameters:
可选参数：
DID_SDID: Data identification and secondary data identification words.
DID_SDID：数据标识和辅助数据标识字。
The presence of the DID_SDID parameters signals that all ANC data packets of this stream are of a particular type or types, i.e., labeled with particular DIDs and SDIDs. DID and SDID values of SMPTE-registered ANC data packet types can be found in the SMPTE Registry for Data Identification Word Assignments [SMPTE-RA].
DID_SDID参数的存在表明该流的所有ANC数据包都是特定类型的，即，标记有特定DID和SDID。SMPTE注册的ANC数据包类型的DID和SDID值可在SMPTE注册表中找到，用于数据标识字分配[SMPTE-RA]。
"Type 1" ANC data packets (which do not have SDIDs defined) SHALL be labeled with SDID=0x00.
“1类”ANC数据包（未定义SDID）应标有SDID=0x00。
DID and SDID values can be registered with SMPTE as per SMPTE ST 291-1 [ST291].
DID和SDID值可根据SMPTE ST 291-1[ST291]向SMPTE注册。
The absence of the DID_SDID parameter signals that determination of the DID and SDID of ANC data packets in the payload can only be achieved through direct inspection of the ANC data packet fields.
没有DID_SDID参数表明，只能通过直接检查ANC数据包字段来确定有效载荷中ANC数据包的DID和SDID。
The ABNF description of the DID_SDID parameter is described in Section 4.
DID_SDID参数的ABNF说明见第4节。
VPID_Code: This integer parameter specifies the Video Payload ID (VPID) code of the source interface of ANC data packets using the value from byte 1 of the VPID as defined in SMPTE ST 352 [ST352]. The integer SHALL be made with bit 7 of VPID byte 1 being the most significant bit and bit 0 of VPID byte 1 being the least significant bit. For example, 132 refers to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gb/s (nominal) serial digital interface.
VPID_代码：该整数参数使用SMPTE ST 352[ST352]中定义的VPID字节1中的值指定ANC数据包源接口的视频有效负载ID（VPID）代码。整数应以VPID字节1的第7位为最高有效位，VPID字节1的第0位为最低有效位。例如，132是指SMPTE ST 292-1，720线视频有效载荷在1.5 Gb/s（标称）串行数字接口上。
Encoding considerations: This media type is framed and binary; see Section 4.8 of RFC 6838 [RFC6838].
编码注意事项：此媒体类型为框架和二进制；参见RFC 6838[RFC6838]第4.8节。
Security considerations: See Section 7.
安全注意事项：见第7节。
Interoperability considerations: Data items in smpte291 can be very diverse. Receivers might only be capable of interpreting a subset of the possible data items. Some implementations might care about the location of the ANC data packets in the SDI raster, but other implementations might not care.
互操作性注意事项：smpte291中的数据项可能非常多样化。接收者可能只能解释可能的数据项的子集。一些实现可能关心ANC数据包在SDI光栅中的位置，但其他实现可能不关心。
Published specification: RFC 8331
已发布规范：RFC 8331
Applications that use this media type: Devices that stream real-time professional video, especially those that interoperate with legacy serial digital interfaces (SDI).
使用此媒体类型的应用程序：流式实时专业视频的设备，尤其是那些与传统串行数字接口（SDI）互操作的设备。
Additional Information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
T. Edwards <thomas.edwards@fox.com>
IETF Payload Working Group <payload@ietf.org>
T. Edwards <thomas.edwards@fox.com>
IETF Payload Working Group <payload@ietf.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP RFC 3550 [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP RFC 3550[RFC3550]传输。此时未定义其他帧协议内的传输。
Author: T. Edwards <thomas.edwards@fox.com>
Author: T. Edwards <thomas.edwards@fox.com>
Change controller: The IETF PAYLOAD Working Group, or other party as designated by the IESG.
变更控制员：IETF有效载荷工作组或IESG指定的其他方。
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 ("smpte291") goes in SDP "a=rtpmap" as the encoding name, followed by a slash ("/") and the rate parameter.
o 子类型名称（“smpte291”）以SDP“a=rtpmap”作为编码名称，后跟斜杠（“/”）和速率参数。
o The optional parameters VPID_Code and DID_SDID, when present, are included in the "a=fmtp" attribute line of SDP as a semicolon-separated list of parameter=value pairs.
o 可选参数VPID_Code和DID_SDID（如果存在）以分号分隔的参数=值对列表的形式包含在SDP的“a=fmtp”属性行中。
DID and SDID values SHALL be specified in hexadecimal with a "0x" prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the DID_SDID optional parameter SHALL be:
DID和SDID值应以十六进制形式指定，并带有“0x”前缀（如“0x61”）。DID_SDID可选参数RFC 5234[RFC5234]规定的ABNF应为：
TwoHex = "0x" 1*2(HEXDIG)
DidSdid = "DID_SDID={" TwoHex "," TwoHex "}"
TwoHex = "0x" 1*2(HEXDIG)
DidSdid = "DID_SDID={" TwoHex "," TwoHex "}"
For example, EIA 608 Closed Caption data would be signaled with the parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not specified, then the ANC data stream might potentially contain ANC data packets of any type.
例如，EIA 608闭路字幕数据将通过参数DID_SDID={0x61,0x02}发出信号。如果未指定DID_SDID参数，则ANC数据流可能包含任何类型的ANC数据包。
Multiple DID_SDID parameters can be specified (separated by semicolons) to signal the presence of multiple types of ANC data in the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example, signals the presence of EIA 608 Closed Captions as well as AFD/Bar Data. Multiple DID_SDID parameters do not imply any particular ordering of the different types of ANC data packets in the stream.
可以指定多个DID_SDID参数（用分号分隔），以表示流中存在多种类型的ANC数据。DID_SDID={0x61,0x02}；例如，DID_SDID={0x41,0x05}表示存在EIA 608闭路字幕以及AFD/Bar数据。多个DID_SDID参数并不意味着流中不同类型ANC数据包的任何特定顺序。
If the optional parameter VPID_Code is present, it SHALL be present only once in the semicolon-separated list, taking a single integer value.
如果存在可选参数VPID_Code，则该参数在分号分隔列表中仅出现一次，取一个整数值。
A sample SDP mapping for ANC data is as follows:
ANC数据的SDP映射示例如下：
m=video 30000 RTP/AVP 112
a=rtpmap:112 smpte291/90000
a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};VPID_Code=132
m=video 30000 RTP/AVP 112
a=rtpmap:112 smpte291/90000
a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};VPID_Code=132
In this example, a dynamic payload type 112 is used for ANC data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. In the "a=fmtp:" line, DID 0x61 and SDID 0x02 are specified (registered to EIA 608 Closed Caption Data by SMPTE), and also DID 0x41 and SDID 0x05 (registered to AFD/Bar Data). The VPID_Code is 132 (referring to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gb/s serial digital interface).
在此示例中，动态有效负载类型112用于ANC数据。90 kHz RTP时间戳速率在子类型后的“a=rtpmap”行中指定。在“a=fmtp:”行中，指定了DID 0x61和SDID 0x02（通过SMPTE注册到EIA 608闭路字幕数据），还指定了DID 0x41和SDID 0x05（注册到AFD/Bar数据）。VPID_代码为132（参考SMPTE ST 292-1，在1.5 Gb/s串行数字接口上的720线视频有效载荷）。
To indicate the association of an ANC data stream with a particular video stream, implementers MAY group the "m" lines together using Flow Identification ("FID") semantics as defined in RFC 5888 [RFC5888].
为了指示ANC数据流与特定视频流的关联，实现者可以使用RFC 5888[RFC5888]中定义的流标识（“FID”）语义将“m”行分组在一起。
A sample SDP mapping for grouping ANC data with video as described in RFC 4175 [RFC4175] is as follows:
RFC 4175[RFC4175]中描述的用于将ANC数据与视频分组的示例SDP映射如下：
v=0
o=Al 123456 11 IN IP4 host.example.com
s=Professional Networked Media Test
i=A test of synchronized video and ANC data
t=0 0
a=group:FID V1 M1
m=video 50000 RTP/AVP 96
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=mid:V1
m=video 50010 RTP/AVP 97
c=IN IP4 233.252.0.2/255
a=rtpmap:97 smpte291/90000
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
a=mid:M1
v=0
o=Al 123456 11 IN IP4 host.example.com
s=Professional Networked Media Test
i=A test of synchronized video and ANC data
t=0 0
a=group:FID V1 M1
m=video 50000 RTP/AVP 96
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=mid:V1
m=video 50010 RTP/AVP 97
c=IN IP4 233.252.0.2/255
a=rtpmap:97 smpte291/90000
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
a=mid:M1
Receivers might wish to receive ANC data streams with specific DID_SDID parameters. Thus, when offering ANC data streams using the Session Description Protocol (SDP) in an Offer/Answer model [RFC3264], the offerer MAY provide a list of ANC data streams available with specific DID_SDID parameters in the fmtp line. The answerer MAY (1) respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered, (2) set the corresponding port number to 0 to decline the smpte291 stream if not in the same media section as a corresponding video stream, or (3) remove the corresponding payload type if the smpte291 stream is in the same media section as a corresponding video stream. There are no restrictions on updating DID_SDID parameters in a subsequent offer.
接收机可能希望接收具有特定DID_SDID参数的ANC数据流。因此，当在报价/应答模型[RFC3264]中使用会话描述协议（SDP）提供ANC数据流时，报价人可以在fmtp行中提供具有特定DID_SDID参数的可用ANC数据流列表。应答者可以（1）使用提供的所有或一个子集的DID_SDID参数和fmtp线路一起提供的所有或一个子集进行响应，（2）如果smpte291流不在与相应视频流相同的媒体部分中，则将相应的端口号设置为0以拒绝该smpte291流，或者（3）如果smpte291流与相应的视频流位于同一媒体段中，请删除相应的有效负载类型。在后续报价中更新DID_SDID参数没有限制。
For declarative use of SDP, nothing specific is defined for this payload format. The configuration given by the SDP MUST be used when sending and/or receiving media in the session.
对于SDP的声明性使用，没有为此有效负载格式定义任何特定内容。在会话中发送和/或接收媒体时，必须使用SDP提供的配置。
The media type "video/smpte291" is defined in Section 3.1. IANA has registered "video/smpte291" in the "Media Types" registry.
第3.1节定义了媒体类型“视频/smpte291”。IANA已在“媒体类型”注册表中注册“视频/smpte291”。
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 Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not the responsibility of an RTP payload format to discuss or mandate what solutions are to be 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 appropriately 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]中找到关于可用安全机制和重要注意事项的指导。应用程序应该使用一个或多个适当的强大安全机制。本节的其余部分将讨论影响有效负载格式本身安全性的属性。
To avoid potential buffer overflow attacks, receivers SHOULD validate that the ANC data packets in the RTP payload are of the appropriate length (using the Data_Count field) for the ANC data type specified by DID and SDID. Also, the Checksum_Word SHOULD be checked against the ANC data packet to ensure that its data has not been damaged in transit; note that the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack.
为避免潜在的缓冲区溢出攻击，接收方应验证RTP有效负载中的ANC数据包是否具有DID和SDID指定的ANC数据类型的适当长度（使用data_Count字段）。此外，应对照ANC数据包检查校验和_字，以确保其数据在传输过程中没有损坏；注意，在定向攻击的情况下，校验和_字不太可能提供有效负载完整性检查。
Some receivers will simply move the ANC data packet bits from the RTP payload into SDI. It might still be a good idea for these "re-embedders" to perform the above-mentioned validity tests to avoid downstream SDI systems from becoming confused by bad ANC data packets, which could be used for a denial-of-service attack.
一些接收机将简单地将ANC数据分组比特从RTP有效载荷移动到SDI中。这些“重新嵌入者”执行上述有效性测试可能仍然是一个好主意，以避免下游SDI系统被可能用于拒绝服务攻击的坏ANC数据包所迷惑。
"Re-embedders" into SDI SHOULD also double check that the Line_Number and Horizontal_Offset lead to the ANC data packet being inserted into a legal area to carry ANC data in the SDI video bit stream of the output video format.
SDI中的“重新嵌入器”还应仔细检查行号和水平偏移是否导致ANC数据包插入到合法区域，以在输出视频格式的SDI视频比特流中携带ANC数据。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<https://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, <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>.
[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>.
[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>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，DOI 10.17487/RFC5888，2010年6月<https://www.rfc-editor.org/info/rfc5888>.
[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>.
[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>.
[RP168] SMPTE, "RP 168:2009, Definition of Vertical Interval Switching Point for Synchronous Video Switching", 2009.
[RP168]SMPTE，“RP 168:2009，同步视频切换垂直间隔切换点的定义”，2009年。
[ST291] SMPTE, "SMPTE Standard - Ancillary Data Packet and Space Formatting", ST 291-1:2011, DOI 10.5594/SMPTE.ST291-1.2011, September 2011, <http://ieeexplore.ieee.org/document/7291794/>.
[ST291]SMPTE，“SMPTE标准-辅助数据包和空间格式化”，ST 291-1:2011，DOI 10.5594/SMPTE.ST291-1.2011，2011年9月<http://ieeexplore.ieee.org/document/7291794/>.
[ST352] SMPTE, "SMPTE Standard - Payload Identification Codes for Serial Digital Interfaces", ST 352:2013, DOI 10.5594/SMPTE.ST352.2013, February 2013, <http://ieeexplore.ieee.org/document/7290261/>.
[ST352]SMPTE，“SMPTE标准-串行数字接口的有效载荷识别码”，ST 352:2013，DOI 10.5594/SMPTE.ST352.2013，2013年2月<http://ieeexplore.ieee.org/document/7290261/>.
[ST424] SMPTE, "SMPTE Standard - 3 Gb/s Signal/Data Serial Interface", ST 424:2012, DOI 10.5594/SMPTE.ST424.2012, October 2012, <http://ieeexplore.ieee.org/document/7290519/>.
[ST424]SMPTE，“SMPTE标准-3 Gb/s信号/数据串行接口”，ST 424:2012，DOI 10.5594/SMPTE.ST424.2012，2012年10月<http://ieeexplore.ieee.org/document/7290519/>.
[BT656] ITU-R, "Interfaces for Digital Component Video Signals in 525-Line and 625-Line Television Systems Operating at the 4:2:2 Level of Recommendation ITU-R BT.601", ITU-R Recommendation BT.656-5, December 2007.
[BT656]ITU-R，“在建议ITU-R BT.601的4:2:2级别上运行的525线和625线电视系统中的数字分量视频信号接口”，ITU-R建议BT.656-5，2007年12月。
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, September 2005, <https://www.rfc-editor.org/info/rfc4175>.
[RFC4175]Gharai，L.和C.Perkins，“未压缩视频的RTP有效载荷格式”，RFC 4175，DOI 10.17487/RFC4175，2005年9月<https://www.rfc-editor.org/info/rfc4175>.
[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload Format for JPEG 2000 Video Streams", RFC 5371, DOI 10.17487/RFC5371, October 2008, <https://www.rfc-editor.org/info/rfc5371>.
[RFC5371]Futemma，S.，Itakura，E.和A.Leung，“JPEG 2000视频流的RTP有效载荷格式”，RFC 5371，DOI 10.17487/RFC53712008年10月<https://www.rfc-editor.org/info/rfc5371>.
[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>.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, <https://www.rfc-editor.org/info/rfc7273>.
[RFC7273]Williams，A.，Gross，K.，van Brandenburg，R.，和H.Stokking，“RTP时钟源信令”，RFC 7273，DOI 10.17487/RFC7273，2014年6月<https://www.rfc-editor.org/info/rfc7273>.
[SMPTE-RA] SMPTE Registration Authority, LLC, "SMPTE Ancillary Data SMPTE ST 291", <https://smpte-ra.org/smpte-ancillary-data-smpte-st-291>.
[SMPTE-RA]SMPTE注册管理局有限责任公司，“SMPTE辅助数据SMPTE ST 291”<https://smpte-ra.org/smpte-ancillary-data-smpte-st-291>.
[ST2038] SMPTE, "SMPTE Standard - Carriage of Ancillary Data Packets in an MPEG-2 Transport Stream", ST 2038:2008, DOI 10.5594/SMPTE.ST2038.2008, September 2008, <http://ieeexplore.ieee.org/document/7290549/>.
[ST2038]SMPTE，“SMPTE标准-MPEG-2传输流中辅助数据包的传输”，ST 2038:2008，DOI 10.5594/SMPTE.ST2038.2008，2008年9月<http://ieeexplore.ieee.org/document/7290549/>.
[ST259] SMPTE, "SMPTE Standard - For Television - SDTV Digital Signal/Data - Serial Digital Interface", ST 259:2008, DOI 10.5594/SMPTE.ST259.2008, January 2008, <http://ieeexplore.ieee.org/document/7292109/>.
[ST259]SMPTE，“SMPTE标准-电视-SDTV数字信号/数据-串行数字接口”，ST 259:2008，DOI 10.5594/SMPTE.ST259.2008，2008年1月<http://ieeexplore.ieee.org/document/7292109/>.
[ST274] SMPTE, "SMPTE Standard - For Television - 1920 x 1080 Image Sample Structure, Digital Representation and Digital Timing Reference Sequences for Multiple Picture Rates", ST 274:2008, DOI 10.5594/SMPTE.ST274.2008, January 2008, <http://ieeexplore.ieee.org/document/7290129/>.
[ST274]SMPTE，“SMPTE标准-用于电视-1920 x 1080多画面速率的图像样本结构、数字表示和数字定时参考序列”，ST 274:2008，DOI 10.5594/SMPTE.ST274.2008，2008年1月<http://ieeexplore.ieee.org/document/7290129/>.
[ST292] SMPTE, "SMPTE Standard - 1.5 Gb/s Signal/Data Serial Interface", ST 292-1:2012, DOI 10.5594/SMPTE.ST292-1.2012, January 2012, <http://ieeexplore.ieee.org/document/7291770/>.
[ST292]SMPTE，“SMPTE标准-1.5 Gb/s信号/数据串行接口”，ST 292-1:2012，DOI 10.5594/SMPTE.ST292-1.2012，2012年1月<http://ieeexplore.ieee.org/document/7291770/>.
[ST296] SMPTE, "SMPTE Standard - 1280 x 720 Progressive Image 4:2:2 and 4:4:4 Sample Structure - Analog and Digital Representation and Analog Interface", ST 296:2012, DOI 10.5594/SMPTE.ST296.2012, May 2012, <http://ieeexplore.ieee.org/document/7291722/>.
[ST296]SMPTE，“SMPTE标准-1280 x 720渐进式图像4:2:2和4:4:4样本结构-模拟和数字表示及模拟接口”，ST 296:2012，DOI 10.5594/SMPTE.ST296.2012，2012年5月<http://ieeexplore.ieee.org/document/7291722/>.
Author's Address
作者地址
Thomas G. Edwards FOX 10201 W. Pico Blvd. Los Angeles, CA 90035 United States of America
托马斯·G·爱德华兹·福克斯，皮科大道西10201号。加利福尼亚州洛杉矶90035美利坚合众国
Phone: +1 310 369 6696
Email: thomas.edwards@fox.com
Phone: +1 310 369 6696
Email: thomas.edwards@fox.com