Network Working Group D. Tynan
Request for Comments: 2431 Claddagh Films
Category: Standards Track October 1998
Network Working Group D. Tynan
Request for Comments: 2431 Claddagh Films
Category: Standards Track October 1998
RTP Payload Format for BT.656 Video Encoding
BT.656视频编码的RTP有效负载格式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.
本文件规定了在实时传输协议（RTP）中封装ITU建议BT.656-3视频流的RTP有效载荷格式。每个RTP包包含ITU建议BT.601-5定义的一条扫描线的全部或一部分，并包括分段、解码和定位信息。
This document describes a scheme to packetize uncompressed, studio-quality video streams as defined by BT.656 for transport using RTP [1]. A BT.656 video stream is defined by ITU-R Recommendation BT.656-3 [2], as a means of interconnecting digital television equipment operating on the 525-line or 625-line standards, and complying with the 4:2:2 encoding parameters as defined in ITU-R Recommendation BT.601-5 (formerly CCIR-601) [3], Part A.
本文档描述了一种使用RTP[1]对BT.656定义的用于传输的未压缩、工作室质量视频流进行打包的方案。BT.656视频流由ITU-R建议BT.656-3[2]定义，作为互连在525线或625线标准上运行的数字电视设备的一种方式，并符合ITU-R建议BT.601-5（以前的CCIR-601）[3]A部分中定义的4:2:2编码参数。
RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The complete specification of RTP for a particular application requires the RTP protocol document [1], a profile specification document [4], and a payload format specification. This document is intended to serve as the payload format specification for studio-quality video streams.
RTP由Internet工程任务组（IETF）定义，以提供端到端网络传输功能，适用于通过多播或单播网络服务传输实时数据的应用程序。特定应用的完整RTP规范需要RTP协议文档[1]、概要文件规范文档[4]和有效负载格式规范。本文档旨在作为studio质量视频流的有效负载格式规范。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
For the purposes of this document, the following definitions apply:
在本文件中，以下定义适用：
Y: An 8-bit or 10-bit coded "luminance" sample. Luminance in this context refers to the BT.601-5 [3] definition which is not the same as a true CIE luminance value. The value of "luminance" refers specifically to video luma. However, in order to avoid confusion with the BT.656 and BT.601 standards, the video luma value is referenced in this document as luminance. Each value has 220 quantization levels with the black level corresponding to level 16 and the peak white level corresponding to 235.
Y：8位或10位编码的“亮度”样本。本文中的亮度指的是BT.601-5[3]定义，该定义与真实CIE亮度值不同。“亮度”的值具体指视频亮度。然而，为了避免与BT.656和BT.601标准混淆，本文件中引用视频亮度值作为亮度。每个值具有220个量化电平，其中黑电平对应于电平16，峰值白电平对应于235。
Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per BT.601-5). Each color-difference value has 225 quantization levels in the centre part of the quantization scale with a color-difference of zero having an encoded value of 128.
Cb、Cr：8位或10位编码色差样本（根据BT.601-5）。每个色差值在量化尺度的中心部分具有225个量化层级，其中0的色差具有128的编码值。
True Black: BT.601-5 defines a true black level as the quad-sample sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values of 128 (0x80) and a luminance value of 16 (0x10).
真黑：BT.601-5将真黑级别定义为四采样序列0x80、0x10、0x80、0x10，表示128（0x80）的色差值和16（0x10）的亮度值。
SAV, EAV: Video timing reference codes which appear at the start and end of a BT.656 scan line.
SAV，EAV：出现在BT.656扫描线开始和结束处的视频定时参考代码。
ITU Recommendation BT.656-3 defines a schema for the digital interconnection of television video signals in conjunction with BT.601-5 which defines the digital representation of the original analog signal. While BT.601-5 refers to images with or without color subsampling, the interconnection standard (BT.656-3) specifically requires 4:2:2 subsampling. This specification also requires 4:2:2 subsampling such that the luminance stream occupies twice the bandwidth of each of the two color-difference streams. For normal 4:3 aspect ratio images, this results in 720 luminance samples per scan line, and 360 samples of each of the two chrominance channels. The total number of samples per scan line in this case is 1440. While this payload format specification can accomodate various image sizes and frame rates, only those in accordance with BT.601-5 are currently supported.
ITU建议BT.656-3结合定义原始模拟信号数字表示的BT.601-5定义了电视视频信号的数字互连模式。虽然BT.601-5指的是带有或不带颜色子采样的图像，但互连标准（BT.656-3）明确要求4:2:2子采样。本规范还要求4:2:2子采样，以便亮度流占用两个色差流中每个色差流的两倍带宽。对于正常的4:3纵横比图像，这将导致每个扫描线720个亮度样本，以及两个色度通道中每个通道的360个样本。在这种情况下，每条扫描线的样本总数为1440。虽然该有效载荷格式规范可以适应各种图像大小和帧速率，但目前仅支持符合BT.601-5的图像大小和帧速率。
Due to the lack of any form of video compression within the payload and sampling-rate compliance with BT.601-5, the resultant video stream can be considered "studio quality". However, such a stream can require approximately 20 megabytes per second of network bandwidth. In order to maximize packet size within a given MTU, and to optimize scan line decoding, each video scan line is encoded within one or more RTP packets.
由于有效载荷内缺乏任何形式的视频压缩，且采样率符合BT.601-5，因此产生的视频流可视为“工作室质量”。然而，这样的流可能需要大约每秒20兆字节的网络带宽。为了最大化给定MTU内的分组大小，并优化扫描线解码，在一个或多个RTP分组内对每个视频扫描线进行编码。
To allow for scan line synchronization, each packet includes certain flag bits (as defined in BT.656-3) and a unique scan line number. The SAV and EAV timing reference codes are removed. Furthermore, no line blanking samples are included, so no ancillary data can be included in the line blanking period. It is the responsibility of the receiver to generate the timing reference codes, and to insert the correct number of line blanking samples.
为了允许扫描线同步，每个数据包包括某些标志位（如BT.656-3中所定义）和唯一的扫描线编号。SAV和EAV正时参考代码被删除。此外，不包括行消隐样本，因此在行消隐期间不能包括辅助数据。接收机负责生成定时参考码，并插入正确数量的行消隐样本。
Similarly, there is no requirement that the frame blanking samples be provided. However, it is possible to include frame blanking samples if such samples contain relevant information, such as a vertical-interlace time code (VITC), or teletext data. In the absence of frame blanking samples, the receiver MUST generate true black levels as defined above, to complete the correct number of scan lines per field. If frame blanking samples are provided, they MUST be copied without modification into the resultant BT.656-3 stream.
同样，也不要求提供框架空白样品。然而，如果帧消隐样本包含相关信息，例如垂直隔行时间码（VITC）或图文电视数据，则可以包括帧消隐样本。在没有帧消隐采样的情况下，接收器必须生成如上定义的真实黑电平，以完成每个字段正确数量的扫描线。如果提供了帧消隐样本，则必须在不修改的情况下将其复制到生成的BT.656-3流中。
Scan lines MUST be sent in sequential order. Error concealment for missing scan lines or fragments of scan lines is at the discretion of the receiver.
扫描行必须按顺序发送。丢失扫描线或扫描线碎片的错误隐藏由接收器决定。
Both 8-bit and 10-bit quantization types as defined by BT.601-5 are supported. 10-bit samples are considered to have two extra bits of fixed-point precision such that a binary value of 10111110.11 represents a sample value of 190.75. Using 8-bit quantization, this would give a sample value of 190. An application receiving 8-bit samples for a 10-bit device MUST consider the sample as reflecting the most-significant 8 bits. The two least-significant bits SHOULD be set to zero. Similarly, an application sending 8-bit samples from a 10-bit device MUST drop the two least-significant bits. For a 10- bit quantization payload, each pair of samples MUST be encoded into a 40-bit word (five octets) prior to transmission, as specified in Section 6.
支持BT.601-5定义的8位和10位量化类型。10位样本被认为具有两个定点精度的额外比特，因此10111110.11的二进制值表示190.75的样本值。使用8位量化，这将给出190的采样值。接收10位设备的8位样本的应用程序必须考虑样本反映最重要的8位。两个最低有效位应设置为零。类似地，从10位设备发送8位样本的应用程序必须删除两个最低有效位。对于10位量化有效载荷，每对样本必须在传输前编码为40位字（五个八位字节），如第6节所述。
To allow for scan lines with octet lengths larger than the path maximum transmission unit (MTU), a scan offset field is included in the packet header. Applications SHOULD attempt path MTU discovery [6] and fragment scan lines into multiple packets no larger than the MTU.
为了允许八位组长度大于路径最大传输单元（MTU）的扫描线，在数据包报头中包括扫描偏移字段。应用程序应尝试路径MTU发现[6]，并将扫描线分割成不大于MTU的多个数据包。
Fragmentation MUST occur on a sample-pair boundary, such that the chrominance and luminance values are not split across packets. For 8-bit quantization this gives a four-octet alignment, and a five-octet alignment for 10-bit quantization. As a result, the scan offset refers not to the byte offset within the payload, but the sample-pair offset.
碎片必须发生在样本对边界上，这样色度和亮度值不会在数据包之间分割。对于8位量化，这给出了四个八位组对齐，对于10位量化，给出了五个八位组对齐。因此，扫描偏移量不是指有效负载内的字节偏移量，而是指样本对偏移量。
Due to the unreliable nature of the RTP protocol, and the lack of an orderly delivery mechanism, each packet contains enough information to form a single scan line without reference to prior scan lines or prior frames. In addition to the RTP header, a fixed length payload header is included in each packet. This header is four octets in length.
由于RTP协议的不可靠性质以及缺乏有序传递机制，每个数据包包含足够的信息以形成单个扫描线，而不参考先前的扫描线或先前的帧。除了RTP报头之外，每个分组中还包括固定长度的有效负载报头。此标头的长度为四个八位字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for BT.656-3 encapsulation:
每个RTP数据包都以一个固定的RTP报头开始。RTP固定报头的以下字段用于BT.656-3封装：
Marker bit (M): The Marker bit of the RTP header is set to 1 for the last packet of a frame (or the last fragment of the last scan line if fragmented), and set to 0 on all other packets.
标记位（M）：RTP报头的标记位对于帧的最后一个数据包（或最后一条扫描线的最后一个片段，如果是碎片）设置为1，对于所有其他数据包设置为0。
Payload Type (PT): The Payload Type indicates the use of the payload format defined in this document. A profile MAY assign a payload type value for this format either statically or dynamically as described in RFC 1890 [4].
有效负载类型（PT）：有效负载类型表示使用本文档中定义的有效负载格式。如RFC 1890[4]所述，配置文件可以静态或动态地为此格式分配有效负载类型值。
Timestamp: The RTP Timestamp encodes the sampling instant of the video frame currently being rendered. All scan line packets within the same frame will have the same timestamp. The timestamp SHOULD refer to the 'Ov' field synchronization point of the first field. For the payload format defined by this document, the RTP timestamp is based on a 90kHz clock.
时间戳：RTP时间戳对当前正在渲染的视频帧的采样瞬间进行编码。同一帧内的所有扫描线数据包将具有相同的时间戳。时间戳应指第一个字段的“Ov”字段同步点。对于本文档定义的有效负载格式，RTP时间戳基于90kHz时钟。
The payload header is a fixed four-octet header broken down as follows:
有效负载头是一个固定的四个八位字节头，分解如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1 bit When 0, indicates the first field of a frame (line 4 through 265 inclusive for Type=0 or 2, and line 1 through 312 inclusive for Type=1 or 3). Any other scan line is considered a component of the second field, and the F bit will be set to 1. This bit is copied directly from the BT.656-compliant stream by the transmitter, and inserted into the stream by the receiver.
F:0时为1位，表示帧的第一个字段（类型=0或2时包括第4行到第265行，类型=1或3时包括第1行到第312行）。任何其他扫描线被视为第二个字段的组成部分，F位将设置为1。该位由发射机直接从BT.656兼容流复制，并由接收机插入流中。
V: 1 bit When 1, indicates that the scan line is part of the vertical interval. Should always be 0 unless frame blanking data is sent. In which case, the V bit SHOULD be set to 1 for scan lines which do not form an integral part of the image. This bit is copied directly from the BT.656-compliant stream by the transmitter, and inserted into the stream by the receiver. For receivers which do not receive scan lines during the vertical interval, BT.656 vertical interval data MUST be generated by repeating the quad-sample sequence 0x80, 0x10, 0x80, 0x10, representing a true black level.
V:1位为1，表示扫描线是垂直间隔的一部分。除非发送帧消隐数据，否则应始终为0。在这种情况下，对于不构成图像完整部分的扫描线，V位应设置为1。该位由发射机直接从BT.656兼容流复制，并由接收机插入流中。对于在垂直间隔期间未接收扫描线的接收器，必须通过重复四采样序列0x80、0x10、0x80、0x10来生成BT.656垂直间隔数据，表示真实的黑色电平。
Type: 4 bits This field indicates the type of frame encoding within the payload. It MUST remain unchanged for all scan lines within the same frame. Currently only four types of encoding are defined. These are as follows;
类型：4位此字段指示有效负载内的帧编码类型。同一帧内的所有扫描线必须保持不变。目前只定义了四种类型的编码。这些措施如下：；
0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields
per second; 525 lines per frame)
0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields
per second; 525 lines per frame)
1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields
per second; 625 lines per frame)
1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields
per second; 625 lines per frame)
2 - High Definition NTSC (18MHz sample rate; 1144 samples per
line; 60 fields per second; 525 lines per frame)
2 - High Definition NTSC (18MHz sample rate; 1144 samples per
line; 60 fields per second; 525 lines per frame)
3 - High Definition PAL (18MHz sample rate; 1152 samples per
line; 50 fields per second; 625 lines per frame)
3 - High Definition PAL (18MHz sample rate; 1152 samples per
line; 50 fields per second; 625 lines per frame)
Further encodings can only be defined through the Internet Assigned Numbers Authority (IANA). For more information refer to Section 8, "IANA Considerations".
进一步的编码只能通过互联网分配号码管理局（IANA）定义。有关更多信息，请参阅第8节“IANA注意事项”。
P: 1 bit Indicates the required sample quantization size. When 0, the payload is comprised of 8-bit samples. Otherwise, it carries 10-bit samples. This bit MUST remain unchanged for all scan lines within the same frame.
P:1位表示所需的样本量化大小。当为0时，有效负载由8位样本组成。否则，它将携带10位样本。对于同一帧内的所有扫描线，该位必须保持不变。
Z: 2 bits Reserved for future use. Must be set to zero by the transmitter and ignored by the receiver.
Z：保留2位供将来使用。发射器必须将其设置为零，接收器则忽略此设置。
Scan Line (SL): 12 bits Indicates the scan line encapsulated in the payload. Valid values range from 1 through 625 inclusive. If no frame blanking data is being transmitted, only scan lines 23 through 310 inclusive, and lines 336 through 623 inclusive SHOULD be sent in the case of Type=1 or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263 inclusive and lines 273 through 525 SHOULD be transmitted.
扫描线（SL）：12位表示封装在有效负载中的扫描线。有效值的范围为1到625（含1到625）。如果未发送帧消隐数据，则在类型=1或3的情况下，应仅发送扫描线23至310，以及线336至623。对于525/60编码（类型=0或2），应发送扫描线10至263（含），以及扫描线273至525。
If a receiver is generating a BT.656-3 data stream directly from this packet, the F and V bits MUST be copied from the header rather than being generated implicitly from the scan line number. In the event of a conflict, the F and V bits have precedence.
如果接收机直接从此数据包生成BT.656-3数据流，则必须从报头复制F和V位，而不是从扫描行号隐式生成。在发生冲突的情况下，F和V位具有优先权。
Scan Offset (SO): 11 bits Indicates the offset within the scan line for application-level fragmentation. After doing PMTU discovery, if the path MTU is less than the required size for one complete scan line, the data SHOULD be fragmented such that a given RTP packet does not exceed the allowable MTU. The offset for the first packet of a scan line MUST be set to zero. The scan offset refers to the sample-pair offset within the scan such that for a scan line width of 720, the maximum scan offset is 359.
扫描偏移量（SO）：11位表示应用程序级碎片扫描线内的偏移量。在执行PMTU发现后，如果路径MTU小于一条完整扫描线所需的大小，则应分割数据，以便给定RTP数据包不超过允许的MTU。扫描线的第一个数据包的偏移量必须设置为零。扫描偏移是指扫描内的样本对偏移，因此对于720的扫描线宽，最大扫描偏移为359。
In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, each pair of color-difference samples will be intermixed with two luminance samples. As per BT.656, the format for transmission SHALL be Cb, Y, Cr, Y. The following is a representation of a 720 sample packet with 8-bit quantization:
根据BT.656和BT.601的4:2:2颜色子采样，每对色差样本将与两个亮度样本混合。根据BT.656，传输格式应为Cb、Y、Cr、Y。以下为720个样本数据包的8位量化表示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb0 | Y0 | Cr0 | Y1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb1 | Y2 | Cr1 | Y3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb359 | Y718 | Cr359 | Y719 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb0 | Y0 | Cr0 | Y1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb1 | Y2 | Cr1 | Y3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb359 | Y718 | Cr359 | Y719 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1144 and 1152 sample packets SHOULD increase the packet size accordingly while maintaining the sample order.
1144和1152样本数据包应相应地增加数据包大小，同时保持样本顺序。
For 10-bit quantization, each group of four samples MUST be encoded into a 40-bit word (five octets) prior to transmission. The sample order is identical to that for 8-bit quantization. The following is a representation of a 720 sample packet with 10-bit quantization:
对于10位量化，每组4个样本必须在传输之前编码为40位字（5个八位字节）。采样顺序与8位量化相同。以下是具有10位量化的720样本分组的表示：
0 1 2 3
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
+---------+---------+---------+---------+
| Cb0 | Y0 | Cr0 | Y1 |
+---------+---------+---------+---------+
| Cb1 | Y2 | Cr1 | Y3 |
+---------+---------+---------+---------+
.
.
.
+---------+---------+---------+---------+
| Cb359 | Y718 | Cr359 | Y719 |
+---------+---------+---------+---------+
(Note that the word width is 40 bits)
+-------+-------+-------+-------+-------+
Octets: | 0 | 1 | 2 | 3 | 4 |
+-------+-------+-------+-------+-------+
0 1 2 3
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
+---------+---------+---------+---------+
| Cb0 | Y0 | Cr0 | Y1 |
+---------+---------+---------+---------+
| Cb1 | Y2 | Cr1 | Y3 |
+---------+---------+---------+---------+
.
.
.
+---------+---------+---------+---------+
| Cb359 | Y718 | Cr359 | Y719 |
+---------+---------+---------+---------+
(Note that the word width is 40 bits)
+-------+-------+-------+-------+-------+
Octets: | 0 | 1 | 2 | 3 | 4 |
+-------+-------+-------+-------+-------+
The octets shown in these diagrams are transmitted in network byte order, that is, left-to-right as shown.
这些图中显示的八位字节按网络字节顺序传输，即从左到右，如图所示。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This implies that confidentiality of the media streams is achieved by encryption. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[1]中讨论的安全注意事项。这意味着媒体流的机密性是通过加密实现的。因为有效负载格式是端到端排列的，所以可以在封装之后执行加密，因此两个操作之间没有冲突。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
这种有效负载类型在数据包处理的接收方计算复杂性方面没有表现出任何显著的不均匀性，从而导致潜在的拒绝服务威胁。
The four encoding types defined by this document relate to specific schema defined by ITU-R Recommendation BT.656-3. Future revisions of the recommendation may create further encoding types which need to be supported over RTP. The "Type" field is four bits wide allowing for a total of up to sixteen possible encodings, with twelve currently reserved for future use. Due to the small number of possible encodings and given that it is very unlikely that future revisions of BT.656 will introduce any new schema, requests to extend the Type field MUST be vetted by the Internet Assigned Numbers Authority. Furthermore, implementors SHOULD check the IANA repository for new definitions of the Type field in order to comply with this document.
本文件定义的四种编码类型与ITU-R建议BT.656-3定义的特定模式相关。本建议的未来修订版可能会创建更多需要通过RTP支持的编码类型。“类型”字段的宽度为4位，最多允许16种可能的编码，其中12种目前保留供将来使用。由于可能的编码数量较少，并且BT.656的未来版本不太可能引入任何新模式，因此扩展类型字段的请求必须经过互联网分配号码管理局的审查。此外，实现者应检查IANA存储库中类型字段的新定义，以符合本文档的要求。
Applications for a new Type value MUST be submitted to the IANA and include the requestors name and contact information, the reason for requesting a new Type and references to appropriate standards, such as an updated version of ITU-R Recommendation BT.656. Furthermore, in the unlikely event that the new Type will lessen the security of a compliant implementation, such security risk MUST be detailed in the application. The application will be reviewed by a Designated Expert and if appropriate, a new Type will be assigned. This type will be listed in the IANA repository for future implementations.
新类型值的申请必须提交给IANA，并包括申请者姓名和联系信息、申请新类型的原因以及适当标准的参考，如ITU-R建议BT.656的更新版本。此外，在新类型可能会降低兼容实现的安全性的情况下，必须在应用程序中详细说明此类安全风险。申请将由指定的专家审查，如果合适，将指定一种新类型。此类型将在IANA存储库中列出，以供将来实施。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[2] 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 (Part A), ITU-R Recommendation BT.656-3, 1995.
[2] 在建议ITU-R BT.601（A部分），ITU-R建议BT.656-3，1995年的4:2:2水平下运行的525线和625线电视系统中的数字分量视频信号接口。
[3] Studio Encoding Parameters of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation BT.601-5, 1995.
[3] 标准4:3和宽屏幕16:9纵横比的数字电视演播室编码参数，ITU-R建议BT.601-51995。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conference with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6] Mogul，J.和S.Deering，“MTU发现路径”，RFC 119119119990年11月。
Dermot Tynan Claddagh Films Limited 3 White Oaks Clybaun Road Galway Ireland
德莫特·泰南·克拉达电影有限公司爱尔兰戈尔韦白橡树克莱伯恩路3号
EMail: dtynan@claddagh.ie
Phone: +353 91 529944
EMail: dtynan@claddagh.ie
Phone: +353 91 529944
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。