Network Working Group L. Gharai
Request for Comments: 4175 USC/ISI
Category: Standards Track C. Perkins
University of Glasgow
September 2005
Network Working Group L. Gharai
Request for Comments: 4175 USC/ISI
Category: Standards Track C. Perkins
University of Glasgow
September 2005
RTP Payload Format for Uncompressed Video
未压缩视频的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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed.
此备忘录指定了一种打包方案，用于将未压缩视频封装为实时传输协议RTP的有效负载格式。它支持一系列标准和高清晰度视频格式，包括常见的电视格式，如ITU BT.601，以及电影和电视工程师协会（SMPTE）的标准，如SMPTE 274M和SMPTE 296M。该格式设计为在开发新的视频格式时适用并可扩展。
This memo defines a scheme to packetize uncompressed, studio-quality video streams for transport using RTP [RTP]. It supports a range of standard and high-definition video formats, including ITU-R BT.601 [601], SMPTE 274M [274] and SMPTE 296M [296].
此备忘录定义了一种使用RTP[RTP]对未压缩、studio质量的视频流进行打包传输的方案。它支持一系列标准和高清视频格式，包括ITU-R BT.601[601]、SMPTE 274M[274]和SMPTE 296M[296]。
Formats for uncompressed standard definition television are defined by ITU Recommendation BT.601 [601] along with bit-serial and parallel interfaces in Recommendation BT.656 [656]. These formats allow both 625-line and 525-line operation, with 720 samples per digital active line, 4:2:2 color sub-sampling, and 8- or 10-bit digital representation.
未压缩标准清晰度电视的格式由ITU建议BT.601[601]以及建议BT.656[656]中的位串行和并行接口定义。这些格式允许625行和525行操作，每个数字活动行720个采样，4:2:2颜色子采样，以及8位或10位数字表示。
The representation of uncompressed high-definition television is specified in SMPTE standards 274M [274] and 296M [296]. SMPTE 274M defines a family of scanning systems with an image format of 1920x1080 pixels with progressive and interlaced scanning, while SMPTE 296M defines systems with an image size of 1280x720 pixels and progressive scanning. In progressive scanning, scan lines are displayed in sequence from top to bottom of a full frame. In interlaced scanning, a frame is divided into its odd and even scan lines (called fields) and the two fields are displayed in succession. SMPTE 274M and 296M define images with aspect ratios of 16:9, and define the digital representation for RGB and YCbCr components. In the case of YCbCr components, the Cb and Cr components are horizontally sub-sampled by a factor of two (4:2:2 color encoding).
SMPTE标准274M[274]和296M[296]规定了未压缩高清晰度电视的表示。SMPTE 274M定义了一系列扫描系统，图像格式为1920x1080像素，采用逐行扫描和隔行扫描，而SMPTE 296M定义了图像大小为1280x720像素，采用逐行扫描的系统。在逐行扫描中，扫描线在整个帧的上下顺序显示。在隔行扫描中，一帧被分成奇数和偶数扫描线（称为场），两个场依次显示。SMPTE 274M和296M定义宽高比为16:9的图像，并定义RGB和YCbCr组件的数字表示。在YCbCr分量的情况下，Cb和Cr分量以两个因子（4:2:2颜色编码）进行水平亚采样。
Although these formats differ in their details, they are structurally very similar. This memo specifies a payload format to encapsulate these and other similar video formats for transport within RTP.
尽管这些格式在细节上有所不同，但它们在结构上非常相似。此备忘录指定了一种有效负载格式，用于封装这些和其他类似的视频格式，以便在RTP中传输。
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 [2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2119]中所述进行解释。
Each scan line of digital video is packetized into one or more RTP packets. If the data for a complete scan line exceeds the network MTU, the scan line SHOULD be fragmented into multiple RTP packets, each smaller than the MTU. A single RTP packet MAY contain data for more than one scan line. Only the active samples are included in the RTP payload: inactive samples and the contents of horizontal and vertical blanking SHOULD NOT be transported. In instances where ancillary data is being transmitted, the sender and receiver can disambiguate between ancillary and video data via scan line numbers. That is, the ancillary data will use scan line numbers that are not within the scope of the video frame.
数字视频的每一扫描行被打包成一个或多个RTP包。如果完整扫描线的数据超过网络MTU，则扫描线应分段为多个RTP数据包，每个RTP数据包都小于MTU。单个RTP数据包可能包含多条扫描线的数据。RTP有效载荷中仅包括活动样品：不活动样品以及水平和垂直下料的内容物不应运输。在发送辅助数据的情况下，发送方和接收方可以通过扫描行号消除辅助数据和视频数据之间的歧义。也就是说，辅助数据将使用不在视频帧范围内的扫描行号。
Scan line numbers are included in the RTP payload header, along with a field identifier for interlaced video.
扫描行号与隔行扫描视频的字段标识符一起包含在RTP有效负载报头中。
For SMPTE 296M format video, valid scan line numbers are from 26 through 745, inclusive. For progressive scan SMPTE 274M format video, valid scan lines are from scan line 42 through 1121, inclusive. For interlaced scan SMPTE 274M format video, valid scan line numbers for field one (F=0) are from 21 to 560 and valid scan line numbers for the second field (F=1) are from 584 to 1123. For ITU-R BT.601 format video, the blanking intervals defined in
对于SMPTE 296M格式视频，有效扫描行号为26到745，包括26到745。对于渐进式扫描SMPTE 274M格式视频，有效扫描线从扫描线42到1121，包括在内。对于隔行扫描SMPTE 274M格式视频，场1（F=0）的有效扫描行号为21到560，第二场（F=1）的有效扫描行号为584到1123。对于ITU-R BT.601格式视频，中定义的消隐间隔
BT.656 are used: for 625 line video, lines 24 to 310 of field one (F=0) and 337 to 623 of the second field (F=1) are valid; for 525 line video, lines 21 to 263 of the first field, and 284 to 525 of the second field are valid. Other formats (e.g., [372]) may define different ranges of active lines.
使用BT.656：对于625行视频，字段1（F=0）的第24至310行和第二个字段（F=1）的第337至623行有效；对于525行视频，第一个字段的第21至263行和第二个字段的284至525行有效。其他格式（例如，[372]）可以定义不同范围的活动线。
The payload header contains a 16-bit extension to the standard 16-bit RTP sequence number, thereby extending the sequence number to 32 bits and enabling the payload format to accommodate high data rates without ambiguity. This is necessary as the 16-bit RTP sequence number will roll over very quickly for high data rates. For example, for a 1-Gbps video stream with packet sizes of at least 1000 octets, the standard RTP packet will roll over in 0.5 seconds, which can be a problem for detecting loss and out-of-order packets particularly in instances where the round-trip time is greater than half a second. The extended 32-bit number allows for a longer wrap-around time of approximately nine hours.
有效负载报头包含对标准16位RTP序列号的16位扩展，从而将序列号扩展到32位，并使有效负载格式能够适应高数据速率而不会产生歧义。这是必要的，因为对于高数据速率，16位RTP序列号将非常快地滚动。例如，对于分组大小至少为1000个八位字节的1-Gbps视频流，标准RTP分组将在0.5秒内滚动，这对于检测丢失和无序分组可能是一个问题，特别是在往返时间大于半秒的情况下。扩展的32位数字允许大约9小时的较长环绕时间。
Each scan line comprises an integer number of pixels. Each pixel is represented by a number of samples. Samples may be coded as 8-, 10-, 12-, or 16-bit values. A sample may represent a color component or a luminance component of the video. Color samples may be shared between adjacent pixels. The sharing of color samples between adjacent pixels is known as color sub-sampling. This is typically done in the YCbCr color space for the purpose of reducing the size of the image data.
每个扫描线包括整数个像素。每个像素由多个样本表示。样本可编码为8、10、12或16位值。样本可以表示视频的颜色分量或亮度分量。颜色样本可以在相邻像素之间共享。相邻像素之间的颜色采样共享称为颜色子采样。这通常在YCbCr颜色空间中完成，以减小图像数据的大小。
Pixels that share sample values MUST be transported together as a "pixel group". If 10-bit or 12-bit samples are used, each pixel may also comprise a non-integer number of octets. In this case, several pixels MUST be combined into an octet-aligned pixel group for transmission. These restrictions simplify the operation of receivers by ensuring that the complete payload is octet aligned, and that samples relating to a single pixel are not fragmented across multiple packets [ALF].
共享采样值的像素必须作为“像素组”一起传输。如果使用10位或12位样本，则每个像素还可以包括非整数个八位字节。在这种情况下，必须将多个像素组合成一个八进制对齐的像素组进行传输。这些限制通过确保完整的有效载荷是八位组对齐的，并且与单个像素相关的样本不会在多个数据包中分割，从而简化了接收机的操作[ALF]。
For example, in YCbCr video with 4:1:1 color sub-sampling, each group of 4 adjacent pixels comprises 6 samples, Y1 Y2 Y3 Y4 Cr Cb, with the Cr and Cb values being shared between all 4 pixels. If samples are 8-bit values, the result is a group of 4 pixels comprising 6 octets. If, however, samples are 10-bit values, the resulting 60-bit group is not octet aligned. To be both octet aligned and appropriately framed, two groups of 4 adjacent pixels must be collected, thereby becoming octet aligned on a 15-octet boundary. This length is referred to as the pixel group size ("pgroup").
例如，在具有4:1:1颜色子采样的YCbCr视频中，每组4个相邻像素包括6个采样，Y1 Y2 Y3 Y4 Cr Cb，Cr和Cb值在所有4个像素之间共享。如果样本是8位值，则结果是由6个八位字节组成的4个像素组。但是，如果采样是10位值，则生成的60位组不是八位组对齐的。要使八位位组对齐并适当加框，必须收集两组4个相邻像素，从而使八位位组在15个八位位组的边界上对齐。该长度称为像素组大小（“pgroup”）。
Formally, the "pgroup" parameter is the size in octets of the smallest grouping of pixels such that 1) the grouping comprises an integer number of octets; and 2) if color sub-sampling is used, samples are only shared within the grouping. When packetizing digital active line content, video data MUST NOT be fragmented within a pgroup.
形式上，“pgroup”参数是最小像素分组的大小（以八位字节为单位），使得1）分组包括整数个八位字节；2）如果使用颜色子采样，则仅在分组内共享采样。对数字活动线路内容进行打包时，视频数据不得在pgroup中分割。
Video content is almost always associated with additional information such as audio tracks, time code, etc. In professional digital video applications, this data is commonly embedded in non-active portions of the video stream (horizontal and vertical blanking periods) so that precise and robust synchronization is maintained. This payload format requires that applications using such synchronized ancillary data SHOULD deliver it in separate RTP sessions that operate concurrently with the video session. The normal RTP mechanisms SHOULD be used to synchronize the media.
视频内容几乎总是与诸如音频轨迹、时间代码等附加信息相关联。在专业数字视频应用中，这些数据通常嵌入在视频流的非活动部分（水平和垂直消隐周期）中，以便保持精确和稳健的同步。此有效负载格式要求使用此类同步辅助数据的应用程序应在与视频会话同时运行的单独RTP会话中交付该数据。应使用常规RTP机制来同步介质。
The standard RTP header is followed by a 2-octet payload header that extends the RTP Sequence Number, and by a 6-octet payload header for each line (or partial line) of video included. One or more lines, or partial lines, of video data follow. This format makes the payload header 32-bit aligned in the common case, where one scan line (or fragment) of video is included in each RTP packet.
标准RTP报头之后是扩展RTP序列号的2-八位字节有效负载报头，以及包括的视频的每一行（或部分行）的6-八位字节有效负载报头。随后是视频数据的一行或多行或部分行。这种格式使有效负载报头在常见情况下32位对齐，其中每个RTP数据包中包括一条视频扫描线（或片段）。
For example, if two lines of video are encapsulated, the payload format will be as shown in Figure 1.
例如，如果封装了两行视频，有效负载格式将如图1所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Line No |C| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |F| Line No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Offset | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Two (partial) lines of video 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Line No |C| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |F| Line No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Offset | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Two (partial) lines of video data .
. .
+---------------------------------------------------------------+
Figure 1: RTP Payload Format showing two (partial) lines of video
图1:RTP有效负载格式显示两行（部分）视频
The fields of the fixed RTP header have their usual meaning, with the following additional notes:
固定RTP标头的字段具有其通常的含义，并附有以下附加说明：
Payload Type (PT): 7 bits
有效负载类型（PT）：7位
A dynamically allocated payload type field that designates the payload as uncompressed video.
动态分配的有效负载类型字段，将有效负载指定为未压缩视频。
Timestamp: 32 bits
时间戳：32位
For progressive scan video, the timestamp denotes the sampling instant of the frame to which the RTP packet belongs. Packets MUST NOT include data from multiple frames, and all packets belonging to the same frame MUST have the same timestamp.
对于逐行扫描视频，时间戳表示RTP数据包所属帧的采样时刻。数据包不得包含来自多个帧的数据，并且属于同一帧的所有数据包必须具有相同的时间戳。
For interlaced video, the timestamp denotes the sampling instant of the field to which the RTP packet belongs. Packets MUST NOT include data from multiple fields, and all packets belonging to the same field MUST have the same timestamp. Use of field timestamps, rather than a frame timestamp and field indicator bit, is needed to support reverse 3-2 pulldown.
对于隔行扫描视频，时间戳表示RTP分组所属字段的采样瞬间。数据包不得包含来自多个字段的数据，属于同一字段的所有数据包必须具有相同的时间戳。支持反向3-2下拉需要使用字段时间戳，而不是帧时间戳和字段指示符位。
A 90-kHz timestamp SHOULD be used in both cases. If the sampling instant does not correspond to an integer value of the clock (as may be the case when interleaving), the value SHALL be truncated to the next lowest integer, with no ambiguity.
在这两种情况下都应使用90 kHz的时间戳。如果采样瞬间与时钟的整数值不一致（交织时可能会出现这种情况），则应将该值截断为下一个最低的整数，且无歧义。
Marker bit (M): 1 bit
标记位（M）：1位
If progressive scan video is being transmitted, the marker bit denotes the end of a video frame. If interlaced video is being transmitted, it denotes the end of the field. The marker bit MUST be set to 1 for the last packet of the video frame/field. It MUST be set to 0 for other packets.
如果正在传输逐行扫描视频，则标记位表示视频帧的结束。如果正在传输隔行扫描视频，则表示场的结束。对于视频帧/字段的最后一个数据包，标记位必须设置为1。对于其他数据包，必须将其设置为0。
Sequence Number: 16 bits
序列号：16位
The low-order bits for RTP sequence number. The standard 16-bit sequence number is augmented with another 16 bits in the payload header in order avoid problems due to wrap-around when operating at high rate rates.
RTP序列号的低位。标准的16位序列号在有效负载报头中增加了另外16位，以避免在高速率下运行时由于环绕而产生的问题。
Extended Sequence Number: 16 bits
扩展序列号：16位
The high order bits of the extended 32-bit sequence number, in network byte order.
扩展32位序列号的高位，按网络字节顺序。
Length: 16 bits
长度：16位
Number of octets of data included from this scan line, in network byte order. This MUST be a multiple of the pgroup value.
此扫描线中包含的数据的八位字节数，以网络字节顺序排列。这必须是pgroup值的倍数。
Line No.: 15 bits
行号：15位
Scan line number of encapsulated data, in network byte order. Successive RTP packets MAY contains parts of the same scan line (with an incremented RTP sequence number, but the same timestamp), if it is necessary to fragment a line.
以网络字节顺序扫描封装数据的行号。如果需要分割一条线，则连续的RTP数据包可能包含相同扫描线的部分（RTP序列号递增，但时间戳相同）。
Offset: 15 bits
偏移量：15位
Offset of the first pixel of the payload data within the scan line. If YCbCr format data is being transported, this is the pixel offset of the luminance sample; if RGB format data is being transported, it is the pixel offset of the red sample; if BGR format data is being transported, it is the pixel offset of the blue sample. The
扫描线内有效负载数据的第一像素的偏移量。如果正在传输YCbCr格式数据，则这是亮度样本的像素偏移；如果正在传输RGB格式数据，则为红色样本的像素偏移量；如果正在传输BGR格式数据，则为蓝色样本的像素偏移量。这个
value is in network byte order. The offset has a value of zero if the first sample in the payload corresponds to the start of the line, and increments by one for each pixel.
值按网络字节顺序排列。如果有效负载中的第一个样本对应于行的开始，则偏移量的值为零，并且每个像素增加一个。
Field Identification (F): 1 bit
字段标识（F）：1位
Identifies which field the scan line belongs to, for interlaced data. F=0 identifies the first field and F=1 the second field. For progressive scan data (e.g., SMPTE 296M format video), F MUST always be set to zero.
为隔行扫描数据标识扫描线所属的字段。F=0表示第一个字段，F=1表示第二个字段。对于逐行扫描数据（例如SMPTE 296M格式视频），F必须始终设置为零。
Continuation (C): 1 bit
连续（C）：1位
Determines if an additional scan line header follows the current scan line header in the RTP packet. Set to 1 if an additional header follows, implying that the RTP packet is carrying data for more than one scan line. Set to 0 otherwise. Several scan lines MAY be included in a single packet, up to the path MTU limit. The only way to determine the number of scan lines included per packet is to parse the payload headers.
确定RTP数据包中的当前扫描线标头之后是否有其他扫描线标头。如果随后出现额外的报头，则将其设置为1，这意味着RTP数据包正在承载多条扫描线的数据。否则设置为0。多条扫描线可包括在单个分组中，直至路径MTU限制。确定每个数据包包含的扫描行数的唯一方法是解析有效负载头。
Depending on the video format, each RTP packet can include either a single complete scan line, a single fragment of a scan line, or one (or more) complete scan lines and scan line fragments. The length of each scan line or scan line fragment MUST be an integer multiple of the pgroup size in octets. Scan lines SHOULD be fragmented so that the resulting RTP packet is smaller than the path MTU.
根据视频格式，每个RTP数据包可以包括单个完整扫描线、扫描线的单个片段或一个（或多个）完整扫描线和扫描线片段。每个扫描线或扫描线片段的长度必须是pgroup大小（以八位字节为单位）的整数倍。扫描线应分段，以便生成的RTP数据包小于路径MTU。
It is possible that the scan line length is not evenly divisible by the number of pixels in a pgroup, so the final pixel data of a scan line does not align to either an octet or a pgroup boundary. Nonetheless, the payload MUST contain a whole number of pgroups; the sender MUST fill the remaining bits of the final pgroup with zero and the receiver MUST ignore the fill data. (In effect, the trailing edge of the image is black-filled to a pgroup boundary.)
扫描线长度可能无法被PG组中的像素数均匀整除，因此扫描线的最终像素数据不与八位字节或PG组边界对齐。尽管如此，有效负载必须包含完整数量的pgroup；发送方必须用零填充最终pgroup的剩余位，接收方必须忽略填充数据。（实际上，图像的后缘以黑色填充到pgroup边界。）
For RGB format video, samples are packed in order Red-Green-Blue. For BGR format video, samples are packed in order Blue-Green-Red. For both formats, if 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15- octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms a separate 6-octet pgroup.
对于RGB格式的视频，样品按红、绿、蓝顺序包装。对于BGR格式的视频，样品按蓝绿红顺序包装。对于这两种格式，如果使用8位样本，则pgroup为3个八位字节。如果使用10位采样，则来自4个相邻像素的采样形成15个八位组。如果使用12位采样，则来自2个相邻像素的采样形成9个八位组。如果使用16位采样，则每个像素形成一个单独的6八位组。
For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. For BGRA format video, samples are packed in order Blue-Green-Red-Alpha. For 8-, 10-, 12-, or 16-bit samples, each pixel forms its own pgroup, with octet sizes of 4, 5, 6, and 8, respectively.
对于RGBA格式的视频，样本按红-绿-蓝-阿尔法顺序打包。对于BGRA格式的视频，样本按蓝绿红阿尔法顺序包装。对于8位、10位、12位或16位采样，每个像素形成自己的pgroup，八位字节大小分别为4、5、6和8。
If the video is in YCbCr format, the packing of samples into the payload depends on the color sub-sampling used.
如果视频为YCbCr格式，则将样本打包到有效负载中取决于所使用的颜色子采样。
For YCbCr 4:4:4 format video, samples are packed in order Cb-Y-Cr for both interlaced and progressive frames. If 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15-octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms a separate 6-octet pgroup.
对于YCbCr 4:4:4格式的视频，对于隔行扫描帧和逐行扫描帧，样本按Cb-Y-Cr顺序打包。如果使用8位样本，则pgroup为3个八位字节。如果使用10位采样，则来自4个相邻像素的采样形成15个八位组。如果使用12位采样，则来自2个相邻像素的采样形成9个八位组。如果使用16位采样，则每个像素形成一个单独的6八位组。
For YCbCr 4:2:2 format video, the Cb and Cr components are horizontally sub-sampled by a factor of two (each Cb and Cr sample corresponds to two Y components). Samples are packed in order Cb0- Y0-Cr0-Y1 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from two adjacent pixels (4, 5, 6, or 8 octets, respectively).
对于YCbCr 4:2:2格式的视频，Cb和Cr分量以两个因数进行水平亚采样（每个Cb和Cr样本对应两个Y分量）。对于隔行扫描线和逐行扫描线，样品按Cb0-Y0-Cr0-Y1顺序包装。对于8、10、12或16位采样，pgroup由两个相邻像素（分别为4、5、6或8个八位字节）构成。
For YCbCr 4:1:1 format video, the Cb and Cr components are horizontally sub-sampled by a factor of four (each Cb and Cr sample corresponds to four Y components). Samples are packed in order Cb0- Y0-Y1-Cr0-Y2-Y3 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from four adjacent pixels (6, 15, 9, or 12 octets, respectively).
对于YCbCr 4:1:1格式的视频，Cb和Cr分量以四个因子进行水平亚采样（每个Cb和Cr样本对应四个Y分量）。对于隔行扫描线和逐行扫描线，样品按Cb0-Y0-Y1-Cr0-Y2-Y3顺序包装。对于8、10、12或16位采样，pgroup由四个相邻像素（分别为6、15、9或12个八位字节）构成。
For YCbCr 4:2:0 video, the Cb and Cr components are sub-sampled by a factor of two both horizontally and vertically. Therefore, chrominance samples are shared between certain adjacent lines. Figure 2 shows the composition of luminance and chrominance samples for a 6x6 pixel grid of 4:2:0 YCbCr video. The pixel group is a group of four pixels arranged in a 2x2 matrix. The octet size of the pgroup for progressive scan 4:2:0 video with samples sizes of 8, 10, 12, and 16 bits is 6, 15, 9, and 12 octets, respectively. For interlaced 4:2:0 video, the corresponding pgroups are 4, 5, 6, and 8 octets.
对于YCbCr 4:2:0视频，Cb和Cr分量在水平和垂直方向上以两个因子进行子采样。因此，色度样本在某些相邻线之间共享。图2显示了4:2:0 YCbCr视频的6x6像素网格的亮度和色度样本的组成。像素组是以2x2矩阵排列的四个像素组成的组。渐进扫描4:2:0视频（采样大小为8、10、12和16位）的pgroup的八位字节大小分别为6、15、9和12个八位字节。对于隔行扫描4:2:0视频，相应的P组为4、5、6和8个八位字节。
line 0: Y00 Y01 Y02 Y03 Y04 Y05 Cb00 Cr00 Cb01 Cr01 Cb02 Cr02 line 1: Y10 Y11 Y12 Y13 Y14 Y15
0号线：Y00 Y01 Y02 Y03 Y04 Y05 Cb00 Cr00 Cb01 Cr01 Cb02 Cr02 1号线：Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20 Y21 Y22 Y23 Y24 Y25 Cb10 Cr10 Cb11 Cr11 Cb12 Cr12 line 3: Y30 Y31 Y32 Y33 Y34 Y35
2号线：Y20 Y21 Y22 Y23 Y24 Y25 Cb10 Cr10 Cb11 Cr11 Cb12 Cr12 3号线：Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40 Y41 Y42 Y43 Y44 Y45 Cb20 Cr20 Cb21 Cr21 Cb22 Cr22 line 5: Y50 Y51 Y52 Y53 Y54 Y55
4号线：Y40 Y41 Y42 Y43 Y44 Y45 Cb20 Cr20 Cb21 Cr21 Cb22 Cr22 5号线：Y50 Y51 Y52 Y53 Y54 Y55
Figure 2: Chrominance/luminance composition in 4:2:0 YCbCr video
Figure 2: Chrominance/luminance composition in 4:2:0 YCbCr video
When packetizing progressive scan 4:2:0 YCbCr video, samples from two consecutive scan lines are included in each packet. The scan line number in the payload header is set to that of the first scan line of the pair:
将渐进扫描4:2:0 YCbCr视频打包时，每个包中包括两条连续扫描线的样本。有效负载标头中的扫描线编号设置为该对中第一条扫描线的编号：
line 0/1: Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01 Y04-Y05-Y14-Y15-Cb02-Cr02
生产线0/1:Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01 Y04-Y05-Y14-Y15-Cb02-Cr02
line 2/3: Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11 Y24-Y25-Y34-Y35-Cb12-Cr12
2/3号线：Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11 Y24-Y25-Y34-Y35-Cb12-Cr12
line 4/5: Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21 Y44-Y45-Y54-Y55-Cb22-Cr22
4/5号线：Y40-Y41-Y50-Y51-Cb20-Cr20-Y42-Y43-Y52-Y53-Cb21-Cr21-Y44-Y45-Y54-Y55-Cb22-Cr22
Figure 3: Packetization of progressive 4:2:0 YCbCr video
Figure 3: Packetization of progressive 4:2:0 YCbCr video
For interlaced transport, chrominance samples are transported with every other line. The first set of chrominance samples may be transported with either the first line of field 0, or the first line of field 1. Figure 4 illustrates the transport of chrominance samples starting with the first line of field 0 (signaled by the "top-field-first" MIME parameter).
对于隔行传输，色度样本每隔一行传输一次。第一组色度样本可以使用字段0的第一行或字段1的第一行进行传输。图4说明了从字段0的第一行开始的色度样本的传输（由“top field first”MIME参数表示）。
field 0: line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02 line 2: Y20-Y21 Y22-Y23 Y24-Y25 line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
字段0：线路0:Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02线路2:Y20-Y21 Y22-Y23 Y24-Y25线路4:Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
field 1: line 1: Y10-Y11 Y12-Y13 Y14-Y15 line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12 line 5: Y50-Y51 Y52-Y53 Y54-Y55
字段1：线路1:Y10-Y11 Y12-Y13 Y14-Y15线路3:Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12线路5:Y50-Y51 Y52-Y53 Y54-Y55
Figure 4: Packetization of interlaced 4:2:0 YCbCr video with top-field-first.
图4：首先使用顶场的隔行扫描4:2:0 YCbCr视频的打包。
Chrominance values may be sampled with different offsets relative to luminance values. For instance, in Figure 2, chrominance values are sampled at the same distance from neighboring luminance samples. It is also possible for a chrominance sample to be co-sited with a luminance sample, as in Figure 5:
可以使用相对于亮度值的不同偏移对色度值进行采样。例如，在图2中，在与相邻亮度样本相同的距离处对色度值进行采样。色度样品也可能与亮度样品共存，如图5所示：
line 0: Y00-C Y01 Y02-C Y03 Y04-C Y05
第0行：Y00-C Y01 Y02-C Y03 Y04-C Y05
line 1: Y10 Y11 Y12 Y13 Y14 Y15
第1行：Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25
第二行：Y20-C Y21 Y22-C Y23 Y24-C Y25
line 3: Y30 Y31 Y32 Y33 Y34 Y35
三号线：Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45
第4行：Y40-C Y41 Y42-C Y43 Y44-C Y45
line 5: Y50 Y51 Y52 Y53 Y54 Y55
5号线：Y50 Y51 Y52 Y53 Y54 Y55
Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C designates a CbCr pair
图5:4:2:0 YCbCr视频中的共址视频采样，其中C表示CbCr对
In general, chrominance values may be placed between luminance samples or co-sited. Positions can be designated by an integer numbering system starting from left to right and top to bottom. The position matrices shown in Figures 6, 7, and 8 apply for 4:2:0, 4:2:2, and 4:1:1 video, respectively:
通常，色度值可放置在亮度样本之间或同一位置。位置可以由从左到右、从上到下的整数编号系统指定。图6、7和8中所示的位置矩阵分别适用于4:2:0、4:2:2和4:1:1视频：
line N: Y[0] [1] Y[2] Y[0] [1] Y[2]
[3] [4] Y[5] [3] [4] [5]
line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8]
line N: Y[0] [1] Y[2] Y[0] [1] Y[2]
[3] [4] Y[5] [3] [4] [5]
line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8]
Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3] line N+1: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]
行N:Y[0][1]Y[2][3]Y[0][1]Y[2][3]行N+1:Y[0][1]Y[2][3]Y[0][1]Y[2][3]
Figure 7: Chrominance position matrix for 4:2:2 YCbCr video
Figure 7: Chrominance position matrix for 4:2:2 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[4] [5] Y[6] line N+1: Y[0] [1] Y[2] [3] Y[4] [5] Y[6]
行N:Y[0][1]Y[2][3]Y[4][5]Y[6]行N+1:Y[0][1]Y[2][3]Y[4][5]Y[6]
Figure 8: Chrominance position matrix for 4:1:1 YCbCr video
Figure 8: Chrominance position matrix for 4:1:1 YCbCr video
Although these positions do not affect the packetization order of chrominance and luminance samples, the information is needed for interpolation prior to display and therefore should be signaled to the receiver.
尽管这些位置不影响色度和亮度样本的打包顺序，但在显示之前需要插值信息，因此应将信息发送给接收器。
RTCP SHOULD be used as specified in RFC 3550 [RTP]. It is to be noted that the sender's octet count in SR packets and the cumulative number of packets lost will wrap around quickly for high data rate streams. This means that these two fields may not accurately represent octet count and number of packets lost since the beginning of transmission, as defined in RFC 3550. Therefore, for network monitoring purposes, other means of keeping track of these variables SHOULD be used.
应按照RFC 3550[RTP]的规定使用RTCP。需要注意的是，对于高数据速率流，SR分组中发送方的八位组计数和丢失的分组的累积数量将迅速结束。这意味着这两个字段可能无法准确表示自传输开始以来丢失的八位字节数和数据包数，如RFC 3550中所定义。因此，出于网络监控目的，应使用其他方法跟踪这些变量。
The IANA has registered one new MIME subtype along with an associated RTP Payload Format, and has created two sub-parameter registries, as described in the following.
IANA已注册了一个新的MIME子类型以及相关的RTP有效负载格式，并创建了两个子参数注册表，如下所述。
MIME media type name: video
MIME媒体类型名称：视频
MIME subtype name: raw
MIME子类型名称：raw
Required parameters:
所需参数：
rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000.
速率：RTP时间戳时钟速率。使用此有效负载格式的应用程序应使用90000的值。
sampling: Determines the color (sub-)sampling mode of the video stream. Currently defined values are RGB, RGBA, BGR, BGRA, YCbCr-4:4:4, YCbCr-4:2:2, YCbCr-4:2:0, and YCbCr-4:1:1. New values may be registered as described in section 6.2 of RFC 4175.
采样：确定视频流的颜色（子）采样模式。当前定义的值为RGB、RGBA、BGR、BGRA、YCbCr-4:4:4、YCbCr-4:2:2、YCbCr-4:2:0和YCbCr-4:1:1。新值可按照RFC 4175第6.2节所述进行登记。
width: Determines the number of pixels per line. This is an integer between 1 and 32767.
宽度：确定每行的像素数。这是一个介于1和32767之间的整数。
height: Determines the number of lines per frame. This is an integer between 1 and 32767.
高度：确定每帧的行数。这是一个介于1和32767之间的整数。
depth: Determines the number of bits per sample. This is an integer with typical values including 8, 10, 12, and 16.
深度：确定每个采样的位数。这是一个典型值为8、10、12和16的整数。
colorimetry: This parameter defines the set of colorimetric specifications and other transfer characteristics for the video source, by reference to an external specification. Valid values and their specification are:
色度学：此参数通过参考外部规范定义视频源的色度学规范和其他传输特性集。有效值及其规格为：
BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240]
BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240]
New values may be registered as described in section 6.2 of RFC 4175.
新值可按照RFC 4175第6.2节所述进行登记。
Optional parameters:
可选参数：
Interlace: If this OPTIONAL parameter is present, it indicates that the video stream is interlaced. If absent, progressive scan is implied.
隔行：如果存在此可选参数，则表示视频流隔行。如果没有，则暗示进行扫描。
Top-field-first: If this OPTIONAL parameter is present, it indicates that chrominance samples are packetized starting with the first line of field 0. Its absence implies that chrominance samples are packetized starting with the first line of field 1.
Top field first：如果存在此可选参数，则表示从字段0的第一行开始对色度样本进行打包。它的缺失意味着色度样本从字段1的第一行开始打包。
chroma-position: This OPTIONAL parameter defines the position of chrominance samples relative to luminance samples. It is either a single integer or a comma separated pair of integers. Integer values range from 0 to 8, as specified in Figures 6-8 of RFC 4175. A single integer implies that Cb and Cr are co-sited. A comma separated pair of integers designates the locations of Cb and Cr samples, respectively. In its absence, a single value of zero is assumed for color-subsampled video (chroma-position=0).
色度位置：此可选参数定义色度采样相对于亮度采样的位置。它可以是单个整数，也可以是逗号分隔的整数对。整数值范围为0到8，如RFC 4175图6-8所示。单个整数表示Cb和Cr位于同一位置。逗号分隔的一对整数分别指定Cb和Cr样本的位置。如果没有，则假定彩色子采样视频的单个值为零（色度位置=0）。
gamma: An OPTIONAL floating point gamma correction value.
gamma：可选的浮点gamma校正值。
Encoding considerations:
编码注意事项：
Uncompressed video is only transmitted over RTP as specified in RFC 4175. No file format media type has been defined to go with this transmission media type at this time.
未压缩视频仅通过RFC 4175中规定的RTP传输。目前尚未定义与此传输介质类型配套的文件格式介质类型。
Security considerations: See section 9 of RFC 4175.
安全注意事项：见RFC 4175第9节。
Interoperability considerations: NONE.
互操作性考虑：无。
Published specification: RFC 4175.
已发布规范：RFC 4175。
Applications which use this media type: Video communication.
使用此媒体类型的应用程序：视频通信。
Additional information: None
其他信息：无
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Ladan Gharai <ladan@isi.edu> IETF Audio/Video Transport working group.
拉丹·加拉伊<ladan@isi.edu>IETF音频/视频传输工作组。
Intended usage: COMMON
预期用途：普通
Author: Ladan Gharai <ladan@isi.edu>
Change controller: IETF AVT Working Group
delegated from the IESG
Author: Ladan Gharai <ladan@isi.edu>
Change controller: IETF AVT Working Group
delegated from the IESG
New values of the "sampling" parameter MAY be registered with the IANA provided they reference an RFC or other permanent and readily available specification (the Specification Required policy of RFC 2434 [2434]). A new registration MUST define the packing order of samples and a valid combinations of color and sub-sampling modes.
“采样”参数的新值可向IANA注册，前提是它们参考RFC或其他永久性和现成的规范（RFC 2434[2434]的规范要求政策）。新注册必须定义样品的包装顺序以及颜色和子采样模式的有效组合。
New values of the "colorimetry" parameter MAY be registered with the IANA provided they reference an RFC or other permanent and readily available specification if colorimetric parameters and other applicable transfer characteristics (the Specification Required policy of RFC 2434 [2434]).
“色度学”参数的新值可向IANA注册，前提是它们参考了RFC或其他永久和现成的规范，如果色度学参数和其他适用的传输特性（RFC 2434[2434]的规范要求政策）。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [SDP], which is commonly used to describe RTP sessions. When SDP is used to specify sessions transporting uncompressed video, the mapping is as follows:
MIME媒体类型规范中包含的信息与会话描述协议（SDP）[SDP]中的字段具有特定映射，SDP通常用于描述RTP会话。使用SDP指定传输未压缩视频的会话时，映射如下：
- The MIME type ("video") goes in SDP "m=" as the media name.
- MIME类型（“视频”）以SDP“m=”作为媒体名称。
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
- MIME子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。
- Remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 其余的参数直接从MIME媒体类型字符串中复制为以分号分隔的参数=值对列表，进入SDP“a=fmtp”属性。
A sample SDP mapping for uncompressed video is as follows:
未压缩视频的SDP映射示例如下所示：
m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1
m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1
In this example, a dynamic payload type 112 is used for uncompressed video. The RTP sampling clock is 90 kHz. Note that the "a=fmtp:" line has been wrapped to fit this page, and will be a single long line in the SDP file.
在此示例中，动态有效负载类型112用于未压缩视频。RTP采样时钟为90 kHz。请注意，“a=fmtp:”行已被包装以适合此页面，并且将是SDP文件中的一条长行。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RTP] and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RTP]和任何适当RTP配置文件中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。
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.
这种有效负载类型在数据包处理的接收方计算复杂性方面没有表现出任何显著的不均匀性，从而导致潜在的拒绝服务威胁。
It is important to note that uncompressed video can have immense bandwidth requirements (up to 270 Mbps for standard-definition video, and approximately 1 Gbps for high-definition video). This is sufficient to cause potential for denial-of-service if transmitted onto most currently available Internet paths.
需要注意的是，未压缩视频可能具有巨大的带宽需求（标准清晰度视频高达270 Mbps，高清晰度视频约为1 Gbps）。如果传输到大多数当前可用的Internet路径上，这足以导致拒绝服务的可能性。
Accordingly, if best-effort service is being used, users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission
因此，如果正在使用尽力而为服务，则此有效负载格式的用户必须监视分组丢失，以确保分组丢失率在可接受的参数内。如果通过相同网络路径并经历相同网络条件的TCP流将实现在合理时间尺度上测量的平均吞吐量，即不小于RTP流所实现的平均吞吐量，则认为丢包是可接受的。通过实施拥塞控制机制来适应传输，可以满足这一条件
rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
速率（或为分层多播会话预订的层数），或者如果丢失率高得令人无法接受，则安排接收器离开会话。
This payload format may also be used in networks that provide quality-of-service guarantees. If enhanced service is being used, receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
这种有效载荷格式也可用于提供服务质量保证的网络中。如果正在使用增强服务，则接收方应监控数据包丢失，以确保所请求的服务实际正在交付。如果不是，那么他们应该假设他们正在接受尽力而为的服务，并相应地采取行动。
In comparison with RFC 2431, this memo specifies support for a wider variety of uncompressed video, in terms of frame size, color sub-sampling and sample sizes. Although [BT656] can transport up to 4096 scan lines and 2048 pixels per line, our payload type can support up to 32768 scan lines and pixels per line. Also, RFC 2431 only address 4:2:2 YCbCr data, while this memo covers YCbCr, RGB, RGBA, BGR, BGRA, and most common color sub-sampling schemes. Given the variety of video types that we cover, this memo also assumes out-of-band signaling for sample size and data types (RFC 2431 uses in band signaling).
与RFC 2431相比，本备忘录规定支持更多种类的未压缩视频，包括帧大小、颜色子采样和样本大小。尽管[BT656]最多可传输4096条扫描线和2048个像素，但我们的有效负载类型最多可支持32768条扫描线和像素。此外，RFC 2431仅处理4:2:2 YCbCr数据，而本备忘录涵盖YCbCr、RGB、RGBA、BGR、BGRA和最常见的颜色子采样方案。鉴于我们讨论的视频类型的多样性，本备忘录还假设样本大小和数据类型为带外信号（RFC 2431使用带内信号）。
RFC 3497 [292RTP] specifies a RTP payload format for encapsulating SMPTE 292M video. The SMPTE 292M standard defines a bit-serial digital interface for local area High-Definition Television (HDTV) transport. As a transport medium, SMPTE 292M utilizes 10-bit words and a fixed 1.485 Gbps (and 1.485/1.001 Gbps) data rate. SMPTE 292M is typically used in the broadcast industry for the transport of other video formats such as SMPTE 260M, SMPTE 295M, SMPTE 274M, and SMPTE 296M.
RFC 3497[292RTP]指定用于封装SMPTE 292M视频的RTP有效负载格式。SMPTE 292M标准定义了用于本地高清晰度电视（HDTV）传输的位串行数字接口。作为传输介质，SMPTE 292M使用10位字和固定的1.485 Gbps（和1.485/1.001 Gbps）数据速率。SMPTE 292M通常用于广播行业传输其他视频格式，如SMPTE 260M、SMPTE 295M、SMPTE 274M和SMPTE 296M。
RFC 3497 defines a circuit emulation for the transport of SMPTE 292M over RTP. It is very specific to SMPTE 292 and has been designed to be interoperable with existing broadcast equipment with a constant rate of 1.485 Gbps.
RFC 3497定义了通过RTP传输SMPTE 292M的电路仿真。它非常专用于SMPTE 292，设计为可与现有广播设备以1.485 Gbps的恒定速率进行互操作。
This memo defines a flexible native packetization scheme that can packetize any uncompressed video, at varying data rates. In addition, unlike RFC 3497, this memo only transports active video pixels (i.e., horizontal and vertical blanking are not transported).
此备忘录定义了一个灵活的本机打包方案，可以以不同的数据速率打包任何未压缩的视频。此外，与RFC 3497不同，此备忘录仅传输活动视频像素（即，不传输水平和垂直消隐）。
The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan Wenger, and Dave Singer for their feedback.
作者感谢菲利普·金特里克、查克·哈里森、斯蒂芬·温格和戴夫·辛格的反馈。
This memo is based upon work supported by the U.S. National Science Foundation (NSF) under Grant No. 0230738. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NSF.
该备忘录是基于美国国家科学基金会（NSF）在第0230738号授权下支持的工作。本材料中表达的任何意见、发现和结论或建议均为作者的意见、发现和结论或建议，不一定反映NSF的观点。
Normative References
规范性引用文件
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[601] International Telecommunication Union, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", Recommendation BT.601, October 1995.
[601]国际电信联盟，“标准4:3和宽屏幕16:9纵横比的数字电视演播室编码参数”，建议BT.601，1995年10月。
[709] International Telecommunication Union, "Parameter Values for HDTV Standards for Production and International Programme Exchange", Recommendation BT.709-2
[709]国际电信联盟，“制作和国际节目交换用HDTV标准的参数值”，建议BT.709-2
[240] Society of Motion Picture and Television Engineers, "Television - Signal Parameters - 1125-Line High-Definition Production", SMPTE 240M-1999.
[240]电影和电视工程师学会，“电视-信号参数-1125线高清制作”，SMPTE 240M-1999。
Informative References
资料性引用
[274] Society of Motion Picture and Television Engineers, "1920x1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
[274]电影和电视工程师学会，“1920x1080多画面速率扫描、模拟和并行数字接口”，SMPTE 274M-1998。
[296] Society of Motion Picture and Television Engineers, "1280x720 Scanning, Analog and Digital Representation and Analog Interfaces", SMPTE 296M-1998.
[296]电影和电视工程师学会，“1280x720扫描、模拟和数字表示以及模拟接口”，SMPTE 296M-1998。
[372] Society of Motion Picture and Television Engineers, "Dual Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE 372M-2002.
[372]电影和电视工程师学会，“1920 x 1080图像光栅的双链接292M接口”，SMPTE 372M-2002。
[ALF] Clark, D. D., and Tennenhouse, D. L., "Architectural Considerations for a New Generation of Protocols", In Proceedings of SIGCOMM '90 (Philadelphia, PA, Sept. 1990), ACM.
[ALF]Clark，D.D.和Tennenhouse，D.L.，“新一代协议的架构考虑”，载于SIGCOMM'90会议录（宾夕法尼亚州费城，1990年9月），ACM。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[BT656] Tynan, D., "RTP Payload Format for BT.656 Video Encoding", RFC 2431, October 1998.
[BT656]Tynan，D.，“BT.656视频编码的RTP有效载荷格式”，RFC 2431，1998年10月。
[292RTP] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, March 2003.
[292RTP]Gharai，L.，Perkins，C.，Goncher，G.，和A.Mankin，“电影电视工程师学会（SMPTE）292M视频RTP有效载荷格式”，RFC 3497，2003年3月。
[656] International Telecommunication Union, "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)", Recommendation BT.656, April 1998.
[656]国际电信联盟，“在建议ITU-R BT.601（A部分）的4:2:2级别上运行的525线和625线电视系统中的数字分量视频信号接口”，建议BT.656，1998年4月。
Authors' Addresses
作者地址
Ladan Gharai USC Information Sciences Institute 3811 N. Fairfax Drive, #200 Arlington, VA 22203 USA
Ladan Gharai USC信息科学研究所美国弗吉尼亚州阿灵顿费尔法克斯大道北3811号，邮编22203
EMail: ladan@isi.edu
EMail: ladan@isi.edu
Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ United Kingdom
柯林帕金斯格拉斯哥大学计算科学系17 LIYBANK花园格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。