Network Working Group L. Gharai
Request for Comments: 3497 C. Perkins
Category: Standards Track USC/ISI
G. Goncher
Tektronix
A. Mankin
Bell Labs, Lucent Corporation
March 2003
Network Working Group L. Gharai
Request for Comments: 3497 C. Perkins
Category: Standards Track USC/ISI
G. Goncher
Tektronix
A. Mankin
Bell Labs, Lucent Corporation
March 2003
RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video
电影电视工程师协会（SMPTE）292M视频的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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport.
本备忘录规定了用于封装未压缩高清晰度电视（HDTV）的RTP有效载荷格式，该格式由美国电影电视工程师协会（SMPTE）标准SMPTE 292M定义。SMPTE是运动成像行业的主要标准化机构，SMPTE 292M标准定义了用于本地HDTV传输的位串行数字接口。
The serial digital interface, SMPTE 292M [1], defines a universal medium of interchange for uncompressed High Definition Television (HDTV) between various types of video equipment (cameras, encoders, VTRs, etc.). SMPTE 292M stipulates that the source data be in 10 bit words and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps.
串行数字接口SMPTE 292M[1]定义了各种类型视频设备（摄像机、编码器、录像机等）之间未压缩高清晰度电视（HDTV）的通用交换媒介。SMPTE 292M规定源数据为10位字，总数据速率为1.485 Gbps或1.485/1.001 Gbps。
The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of SMPTE 292M content. Accordingly, this memo defines an RTP payload format for SMPTE 292M format video.
专用串行互连适用于studio环境，但需要利用高带宽IP连接的广泛可用性，以实现SMPTE 292M内容的高效广域传输。因此，本备忘录定义了SMPTE 292M格式视频的RTP有效负载格式。
It is to be noted that SMPTE 292M streams have a constant high bit rate and are not congestion controlled. Accordingly, use of this payload format should be tightly controlled and limited to private networks or those networks that provide resource reservation and enhanced quality of service. This is discussed further in section 9.
需要注意的是，SMPTE 292M流具有恒定的高比特率，并且不受拥塞控制。因此，应严格控制这种有效载荷格式的使用，并将其限制在专用网络或提供资源保留和提高服务质量的网络中。这将在第9节中进一步讨论。
This memo only addresses the transfer of uncompressed HDTV. Compressed HDTV is a subset of MPEG-2 [9], which is fully described in document A/53 [10] of the Advanced Television Standards Committee. The ATSC has also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [11]. Therefore RFC 2250 [12] sufficiently describes transport for compressed HDTV over RTP.
本备忘录仅涉及未压缩HDTV的传输。压缩HDTV是MPEG-2[9]的一个子集，高级电视标准委员会的文件a/53[10]对此进行了详细描述。ATSC还采用了MPEG-2传输系统（ISO/IEC 13818-1）[11]。因此，RFC 2250[12]充分描述了RTP上压缩HDTV的传输。
A SMPTE 292M television line comprises two interleaved streams, one containing the luminance (Y) samples, the other chrominance (CrCb) values. Since chrominance is horizontally sub-sampled (4:2:2 coding) the lengths of the two streams match (see Figure 3 of SMPTE 292M [1]). In addition to being the same length the streams also have identical structures: each stream is divided into four parts, (figure 1): (1) start of active video timing reference (SAV); (2) digital active line; (3) end of active video timing reference (EAV); and (4) digital line blanking. A SMPTE 292M line may also carry horizontal ancillary data (H-ANC) or vertical ancillary data (V-ANC) instead of the blanking level; Likewise, ancillary data may be transported instead of a digital active line.
SMPTE 292M电视线路包括两个交错流，一个包含亮度（Y）样本，另一个包含色度（CrCb）值。由于色度是水平亚采样（4:2:2编码），两个流的长度匹配（参见SMPTE 292M[1]的图3）。除了长度相同之外，流还具有相同的结构：每个流被分为四个部分（图1）：（1）活动视频定时基准（SAV）的开始；（2） 数字有源线路；（3） 活动视频定时基准（EAV）的结束；（4）数字线消隐。SMPTE 292M线路也可承载水平辅助数据（H-ANC）或垂直辅助数据（V-ANC），而不是消隐电平；同样，可以传输辅助数据而不是数字活动线路。
The EAV and SAV are made up of three 10 bit words, with constant values of 0x3FF 0x000 0x000 and an additional word (designated as XYZ in figure 2), carrying a number of flags. This includes an F flag which designates which field (1 or 2) the line is transporting and also a V flag which indicates field blanking. Table 1, further displays the code values in SAV and EAV. After EAV, are two words, LN0 and LN1 (Table 2), that carry the 11 bit line number for the SMPTE 292M line. The Cyclic Redundancy Check, CRC, is also a two word value, shown as CR0 and CR1 in figure 2.
EAV和SAV由三个10位字组成，其常量值为0x3FF 0x000 0x000和一个附加字（在图2中指定为XYZ），带有多个标志。这包括一个F标志，用于指定线路正在传输的字段（1或2），以及一个V标志，用于指示字段空白。表1进一步显示了SAV和EAV中的代码值。EAV之后是两个字LN0和LN1（表2），它们携带SMPTE 292M线的11位线号。循环冗余校验CRC也是一个两个字的值，如图2中的CR0和CR1所示。
+------------+-----------------------+-----+---------------------+
| | Digital Line Blanking | | Digital Active Line |
| EAV+LN+CRC | (Blanking level or | SAV | (Active Picture or |
| | Ancillary Data) | | Ancillary Data) |
+------------+-----------------------+-----+---------------------+
+------------+-----------------------+-----+---------------------+
| | Digital Line Blanking | | Digital Active Line |
| EAV+LN+CRC | (Blanking level or | SAV | (Active Picture or |
| | Ancillary Data) | | Ancillary Data) |
+------------+-----------------------+-----+---------------------+
Figure 1. The SMPTE 292M line format.
图1。SMPTE 292M行格式。
0 20 40 60 80 0 20 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|3FF| 0 | 0 |XYZ|LN1|LN2|CR0|CR1| |3FF| 0 | 0 |XYZ|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
<---- EAV -----> <- LN-> <- CRC-> <----- SAV ----->
0 20 40 60 80 0 20 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|3FF| 0 | 0 |XYZ|LN1|LN2|CR0|CR1| |3FF| 0 | 0 |XYZ|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
<---- EAV -----> <- LN-> <- CRC-> <----- SAV ----->
Figure 2. Timing reference format.
图2。定时参考格式。
+---------------------------------------------------------+
| (MSB) (LSB) |
| Word 9 8 7 6 5 4 3 2 1 0 |
+---------------------------------------------------------+
| 3FF 1 1 1 1 1 1 1 1 1 1 |
| 000 0 0 0 0 0 0 0 0 0 0 |
| 000 0 0 0 0 0 0 0 0 0 0 |
| XYZ 1 F V H P P P P P P |
+---------------------------------------------------------+
| NOTES: |
| F=0 during field 1; F=1 during field 2. |
| V=0 elsewhere; V=1 during field blanking. |
| H=0 in SAV; H=1 in EAV. |
| MSB=most significant bit; LSB=least significant bit.|
| P= protected bits defined in Table 2 of SMPTE 292M |
+---------------------------------------------------------+
+---------------------------------------------------------+
| (MSB) (LSB) |
| Word 9 8 7 6 5 4 3 2 1 0 |
+---------------------------------------------------------+
| 3FF 1 1 1 1 1 1 1 1 1 1 |
| 000 0 0 0 0 0 0 0 0 0 0 |
| 000 0 0 0 0 0 0 0 0 0 0 |
| XYZ 1 F V H P P P P P P |
+---------------------------------------------------------+
| NOTES: |
| F=0 during field 1; F=1 during field 2. |
| V=0 elsewhere; V=1 during field blanking. |
| H=0 in SAV; H=1 in EAV. |
| MSB=most significant bit; LSB=least significant bit.|
| P= protected bits defined in Table 2 of SMPTE 292M |
+---------------------------------------------------------+
Table 1: Timing reference codes.
表1：定时参考代码。
+---------------------------------------------------------+
| (MSB) (LSB) |
| Word 9 8 7 6 5 4 3 2 1 0 |
+---------------------------------------------------------+
| LN0 R L6 L5 L4 L3 L2 L1 L0 R R |
| LN1 R R R R L10 L9 L8 L7 R R |
+---------------------------------------------------------+
| NOTES: |
| LN0 - L10 - line number in binary code. |
| R = reserved, set to "0". |
+---------------------------------------------------------+
+---------------------------------------------------------+
| (MSB) (LSB) |
| Word 9 8 7 6 5 4 3 2 1 0 |
+---------------------------------------------------------+
| LN0 R L6 L5 L4 L3 L2 L1 L0 R R |
| LN1 R R R R L10 L9 L8 L7 R R |
+---------------------------------------------------------+
| NOTES: |
| LN0 - L10 - line number in binary code. |
| R = reserved, set to "0". |
+---------------------------------------------------------+
Table 2: Line number data.
表2：行号数据。
The number of words and the format for active lines and line blanking is defined by source format documents. Currently, source video formats transfered by SMPTE 292M include SMPTE 260M, 295M, 274M and 296M [5-8]. In this memo, we specify how to transfer SMPTE 292M over RTP, irrespective of the source format.
活动行和行空白的字数和格式由源格式文档定义。目前，SMPTE 292M传输的源视频格式包括SMPTE 260M、295M、274M和296M[5-8]。在本备忘录中，我们指定如何通过RTP传输SMPTE 292M，而不考虑源格式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Each SMPTE 292M data line is packetized into one or more RTP packets. This includes all timing signals, blanking levels, active lines and/or ancillary data. Start of active video (SAV) and end of active video (EAV+LN+CRC) signals MUST NOT be fragmented across packets, as the SMPTE 292M decoder uses them to detect the start of scan lines.
每个SMPTE 292M数据线被打包成一个或多个RTP数据包。这包括所有定时信号、消隐电平、活动线路和/或辅助数据。活动视频开始（SAV）和活动视频结束（EAV+LN+CRC）信号不得在数据包之间分段，因为SMPTE 292M解码器使用它们来检测扫描线的开始。
The standard RTP header is followed by a 4 octet payload header. All information in the payload header pertains to the first data sample in the packet. The end of a video frame (the packet containing the last sample before the EAV) is marked by the M bit in the RTP header.
标准RTP报头后面是4个八位字节的有效负载报头。有效载荷报头中的所有信息都与数据包中的第一个数据样本有关。视频帧（包含EAV之前最后一个样本的数据包）的结尾由RTP报头中的M位标记。
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 RTP to accommodate HDTV's high data rates. At 1.485 Gbps, with packet sizes of at least one thousand octets, 32 bits allows for an approximate 6 hour period before the sequence number wraps around. Given the same assumptions, the standard 16 bit RTP sequence number wraps around in less than a second (336 milliseconds), which is clearly not sufficient for the purpose of detecting loss and out of order packets.
有效负载报头包含对标准16位RTP序列号的16位扩展，从而将序列号扩展到32位，并使RTP能够适应HDTV的高数据速率。在1.485 Gbps的速率下，数据包大小至少为1000个八位字节，32位允许在序列号结束前大约6小时。在相同的假设下，标准的16位RTP序列号在不到一秒钟（336毫秒）的时间内完成，这显然不足以检测丢失和无序数据包。
A 148.5 MHz (or 148.5/1.001 MHz) time-stamp is used as the RTP timestamp. This allows the receiver to reconstruct the timing of the SMPTE 292M stream, without knowledge of the exact type of source format (e.g., SMPTE 274M or SMPTE 296M). With this timestamp, the location of the first sample of each packet can be uniquely identified in the SMPTE 292M stream. At 148.5 MHz, the 32 bit timestamp wraps around in 21 seconds.
RTP时间戳使用148.5 MHz（或148.5/1.001 MHz）的时间戳。这允许接收机重构SMPTE 292M流的定时，而不知道源格式的确切类型（例如，SMPTE 274M或SMPTE 296M）。利用该时间戳，可以在SMPTE 292M流中唯一地标识每个分组的第一个样本的位置。在148.5兆赫的频率下，32位时间戳在21秒内结束。
The payload header also carries the 11 bit line number from the SMPTE 292M timing signals. This provides more information at the application level and adds a level of resiliency, in case the packet containing the EAV is lost.
有效负载报头还携带来自SMPTE 292M定时信号的11位行号。这在应用程序级别提供了更多信息，并在包含EAV的数据包丢失的情况下增加了一个弹性级别。
The bit length of both timing signals, SAV and EAV+LN+CRC, are multiples of 8 bits, 40 bits and 80 bits, respectively, and therefore are naturally octet aligned.
两个定时信号SAV和EAV+LN+CRC的比特长度分别是8比特、40比特和80比特的倍数，因此自然是八位组对齐的。
For the video content, it is desirable for the video to both octet align when packetized and also adhere to the principles of application level framing, also known as ALF [13]. For YCrCb video, the ALF principle translates into not fragmenting related luminance and chrominance values across packets. For example, with the 4:2:0 color subsampling, a 4 pixel group is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb, and video content should be packetized such that these values are not fragmented across 2 packets. However, with 10 bit words, this is a 60 bit value which is not octet aligned. To be both octet aligned, and adhere to ALF, an ALF unit must represent 2 groups of 4 Pixels, thereby becoming octet aligned on a 15 octet boundary. This length is referred to as the pixel group or pgroup, and it is conveyed in the SDP parameters. Table 3 displays the pgroup value for various color samplings. Typical source formats use 4:2:2 sampling, and require a pgroup of 5 octets, other values are included for completeness.
对于视频内容，在打包时，希望视频与八位字节对齐，并遵守应用级帧的原则，也称为ALF[13]。对于YCrCb视频，ALF原理转化为不分割数据包中的相关亮度和色度值。例如，使用4:2:0颜色子采样，4像素组由6个值表示，Y1 Y2 Y3 Y4 Cr Cb，视频内容应打包，以使这些值不会在2个数据包中分段。但是，对于10位字，这是一个60位的值，它不是八位对齐的。要使八位元对齐并符合ALF，ALF单元必须表示2组4像素，从而在15个八位元边界上成为八位元对齐。该长度称为像素组或pgroup，并在SDP参数中传递。表3显示了各种颜色采样的pgroup值。典型的源格式使用4:2:2采样，并且需要5个八位字节的pgroup，为了完整性，还包括其他值。
The contents of the Digital Active Line SHOULD NOT be fragmented within a pgroup. A pgroup of 1 indicates that data may be split at any octet boundary (this is applicable to instances where the source format is not known). The SAV and EAV+LN+CRC fields MUST NOT be fragmented.
数字活动行的内容不应在pgroup中分割。pgroup为1表示可以在任何八位字节边界拆分数据（这适用于源格式未知的实例）。不得分割SAV和EAV+LN+CRC字段。
+-------------------------------------------------------+
| Color 10 bit |
|Subsampling Pixels words aligned on octet# pgroup|
+-----------+-------+--------+-------------------+------+
| 4:2:0 | 4 | 6*10 | 2*60/8 = 15 | 15 |
+-----------+-------+--------+-------------------+------+
| 4:2:2 | 2 | 4*10 | 40/8 = 5 | 5 |
+-----------+-------+--------+-------------------+------+
| 4:4:4 | 1 | 3*10 | 4*30/8 = 15 | 15 |
+-----------+-------+--------+-------------------+------+
+-------------------------------------------------------+
| Color 10 bit |
|Subsampling Pixels words aligned on octet# pgroup|
+-----------+-------+--------+-------------------+------+
| 4:2:0 | 4 | 6*10 | 2*60/8 = 15 | 15 |
+-----------+-------+--------+-------------------+------+
| 4:2:2 | 2 | 4*10 | 40/8 = 5 | 5 |
+-----------+-------+--------+-------------------+------+
| 4:4:4 | 1 | 3*10 | 4*30/8 = 15 | 15 |
+-----------+-------+--------+-------------------+------+
Table 3. Color subsampling and pgroups.
表3。颜色子采样和P组。
The standard RTP header is followed by a 4 octet payload header, and the payload data, as shown in Figure 3.
标准RTP报头后面是一个4个八位字节的有效负载报头，以及有效负载数据，如图3所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence# (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ssrc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence# (high bits) |F|V| Z | line no |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: SMPTE 292M 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# (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ssrc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence# (high bits) |F|V| Z | line no |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: SMPTE 292M data :
: :
| |
+---------------------------------------------------------------+
Figure 3: RTP Packet showing SMPTE 292M headers and payload
图3：显示SMPTE 292M报头和有效负载的RTP数据包
The following fields of the RTP fixed header are used for SMPTE 292M encapsulation (the other fields in the RTP header are used in their usual manner):
RTP固定报头的以下字段用于SMPTE 292M封装（RTP报头中的其他字段以通常方式使用）：
Payload Type (PT): 7 bits A dynamically allocated payload type field that designates the payload as SMPTE 292M.
有效负载类型（PT）：7位动态分配的有效负载类型字段，将有效负载指定为SMPTE 292M。
Timestamp: 32 bits For a SMPTE 292M transport stream at 1.485 Gbps (or 1.485/1.001 Gbps), the timestamp field contains a 148.5 MHz (or 148.5/1.001 MHz) timestamp, respectively. This allows for a unique timestamp for each 10 bit word.
时间戳：对于1.485 Gbps（或1.485/1.001 Gbps）的SMPTE 292M传输流，时间戳字段分别包含148.5 MHz（或148.5/1.001 MHz）时间戳。这允许每个10位字具有唯一的时间戳。
Marker bit (M): 1 bit The Marker bit denotes the end of a video frame, and is set to 1 for the last packet of the video frame and is otherwise set to 0 for all other packets.
标记位（M）：1位标记位表示视频帧的结束，对于视频帧的最后一个数据包设置为1，对于所有其他数据包设置为0。
Sequence Number (low bits): 16 bits The low order bits for RTP sequence counter. The standard 16 bit RTP sequence number is augmented with another 16 bits in the payload header in order to accommodate the 1.485 Gbps data rate of SMPTE 292M.
序列号（低位）：16位RTP序列计数器的低位。标准16位RTP序列号在有效负载报头中增加了另外16位，以适应SMPTE 292M的1.485 Gbps数据速率。
Sequence Number (high bits): 16 bits The high order bits for the 32 bit RTP sequence counter, in network byte order.
序列号（高位）：16位是32位RTP序列计数器的高位，以网络字节顺序排列。
F: 1 bit The F bit as defined in the SMPTE 292M timing signals (see Table 1). F=1 identifies field 2 and F=0 identifies field 1.
F:1位SMPTE 292M定时信号中定义的F位（见表1）。F=1表示字段2，F=0表示字段1。
V: 1 bit The V bit as defined in the SMPTE 292M timing signals (see Table 1). V=1 during field blanking, and V=0 else where.
V:1位SMPTE 292M定时信号中定义的V位（见表1）。在字段消隐期间V=1，在其他情况下V=0。
Z: 2 bits SHOULD be set to zero by the sender and MUST be ignored by receivers.
Z:2位应由发送方设置为零，接收方必须忽略。
Line No: 11 bits The line number of the source data format, extracted from the SMPTE 292M stream (see Table 2). The line number MUST correspond to the line number of the first 10 bit word in the packet.
行号：11位源数据格式的行号，从SMPTE 292M流中提取（见表2）。行号必须与数据包中第一个10位字的行号相对应。
RFC 1889 should be used as specified in RFC 1889 [3], which specifies two limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% of the data rate, and the minimum for the average of the randomized intervals between RTCP packets should be 5 seconds. Considering the high data rate of this payload format, the minimum interval is the governing factor in this case.
应按照RFC 1889[3]的规定使用RFC 1889，其中规定了RTCP数据包速率的两个限制：RTCP带宽应限制为数据速率的5%，RTCP数据包之间随机间隔的平均值的最小值应为5秒。考虑到这种有效负载格式的高数据率，在这种情况下，最小间隔是控制因素。
It should be noted that the sender's octet count in SR packets wraps around in 23 seconds, and that the cumulative number of packets lost wraps around in 93 seconds. This means these two fields cannot accurately represent the octet count and number of packets lost since the beginning of transmission, as defined in RFC 1889. Therefore, for network monitoring purposes or any other application that requires the sender's octet count and the cumulative number of packets lost since the beginning of transmission, the application itself must keep track of the number of rollovers of these fields via a counter.
应该注意的是，SR数据包中发送方的八位字节数在23秒内结束，而丢失的数据包的累积数在93秒内结束。这意味着这两个字段不能准确表示自传输开始以来丢失的八位字节数和数据包数，如RFC 1889中所定义。因此，对于需要发送方的八位组计数和自传输开始以来丢失的数据包的累积数量的网络监控目的或任何其他应用程序，应用程序本身必须通过计数器跟踪这些字段的翻滚次数。
This document defines a new RTP payload format and associated MIME type, SMPTE292M. The MIME registration form for SMPTE 292M video is enclosed below:
本文档定义了一种新的RTP有效负载格式和相关的MIME类型SMPTE292M。SMPTE 292M视频MIME注册表随附如下：
MIME media type name: video
MIME媒体类型名称：视频
MIME subtype name: SMPTE292M
MIME子类型名称：SMPTE292M
Required parameters: rate The RTP timestamp clock rate. The clock runs at either 148500000 Hz or 148500000/1.001 Hz. If the latter rate is used a timestamp of 148351648 MUST be used, and receivers MUST interpret this as 148500000/1.001 Hz.
所需参数：RTP时间戳时钟速率。时钟以148500000 Hz或148500000/1.001 Hz的频率运行。如果使用后一种速率，则必须使用148351648的时间戳，并且接收机必须将其解释为148500000/1.001 Hz。
Optional parameters: pgroup The RECOMMENDED grouping for aligning 10 bit words and octets. Defaults to 1 octet, if not present.
可选参数：pgroup用于对齐10位字和八位字节的建议分组。如果不存在，则默认为1个八位字节。
Encoding considerations: SMPTE292M video can be transmitted with RTP as specified in RFC 3497.
编码注意事项：SMPTE292M视频可以按照RFC 3497中的规定使用RTP传输。
Security considerations: see RFC 3497 section 9.
安全注意事项：见RFC 3497第9节。
Interoperability considerations: NONE
互操作性注意事项：无
Published specification: SMPTE292M RFC 3497
发布规范：SMPTE292M RFC 3497
Applications which use this media type: Video communication.
使用此媒体类型的应用程序：视频通信。
Additional information: None
其他信息：无
Magic number(s): None
幻数：无
File extension(s): None
文件扩展名：无
Macintosh File Type Code(s): None
Macintosh文件类型代码：无
Person & email address to contact for further information: Ladan Gharai <ladan@isi.edu> IETF AVT working group.
联系人和电子邮件地址，以获取更多信息：Ladan Gharai<ladan@isi.edu>IETF AVT工作组。
Intended usage: COMMON
预期用途：普通
Author/Change controller:
Ladan Gharai <ladan@isi.edu>
Author/Change controller:
Ladan Gharai <ladan@isi.edu>
Parameters are mapped to SDP [14] as follows:
参数映射到SDP[14]，如下所示：
m=video 30000 RTP/AVP 111
a=rtpmap:111 SMPTE292M/148500000
a=fmtp:111 pgroup=5
m=video 30000 RTP/AVP 111
a=rtpmap:111 SMPTE292M/148500000
a=fmtp:111 pgroup=5
In this example, a dynamic payload type 111 is used for SMPTE292M. The RTP timestamp is 148500000 Hz and the SDP parameter pgroup indicates that for video data after the SAV signal, it must be packetized in multiples of 5 octets.
在此示例中，动态有效负载类型111用于SMPTE292M。RTP时间戳为148500000 Hz，SDP参数pgroup表示，对于SAV信号之后的视频数据，必须以5个八位字节的倍数进行打包。
RTP sessions using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3] and any appropriate RTP profile (e.g., [4]).
使用本规范中定义的有效负载格式的RTP会话受RTP规范[3]和任何适当RTP配置文件（例如[4]）中讨论的安全注意事项的约束。
This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat for intended receivers.
这种有效载荷格式在数据包处理的接收方计算复杂性方面没有表现出任何显著的不均匀性，从而对预期的接收方造成潜在的拒绝服务威胁。
The bandwidth of this payload format is high enough (1.485 Gbps without the RTP overhead) to cause potential for denial-of-service if transmitted onto most currently available Internet paths. Since congestion control is not possible for SMPTE 292M over RTP flows, use of the payload SHOULD be narrowly limited to suitably connected network endpoints, or to networks where QoS guarantees are available.
此有效负载格式的带宽足够高（1.485 Gbps，无RTP开销），如果传输到大多数当前可用的Internet路径上，可能会导致拒绝服务。由于SMPTE 292Mover RTP流的拥塞控制是不可能的，所以有效负载的使用应严格限制在适当连接的网络端点，或QoS保证可用的网络。
If QoS enhanced service is used, RTP 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.
如果使用QoS增强的服务，RTP接收器应监控数据包丢失，以确保请求的服务实际正在交付。如果不是，那么他们应该假设他们正在接受尽力而为的服务，并相应地采取行动。
If best-effort service is being used, RTP receivers MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters and MUST leave the session if the loss rate is too high. The loss rate is considered acceptable if a TCP flow across the same network path, 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. Since congestion control is not possible for SMPTE 292M flows, this condition can only be satisfied if receivers leave the session if the loss rate is unacceptably high.
如果使用尽力而为服务，RTP接收器必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内，如果丢失率过高，则必须离开会话。如果在相同的网络路径上，经历相同的网络条件的TCP流将达到在合理的时间尺度上测量的平均吞吐量，即不小于RTP流所达到的平均吞吐量，则认为丢失率是可接受的。由于SMPTE 292M流不可能进行拥塞控制，因此只有在丢失率高得令人无法接受的情况下，如果接收器离开会话，才能满足此条件。
We would like to thank David Richardson for his insightful comments and contributions to the document. We would also like to thank Chuck Harrison for his input and for explaining the intricacies of SMPTE 292M.
我们要感谢David Richardson对该文件的深刻评论和贡献。我们还要感谢Chuck Harrison的投入，感谢他解释SMPTE 292M的复杂性。
[1] Society of Motion Picture and Television Engineers, Bit-Serial Digital Interface for High-Definition Television Systems, SMPTE 292M-1998.
[1] 电影和电视工程师学会，高清晰度电视系统的位串行数字接口，SMPTE 292M-1998。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[5] Society of Motion Picture and Television Engineers, Digital Representation and Bit-Parallel Interface - 1125/60 High-Definition Production System, SMPTE 260M-1999.
[5] 电影和电视工程师学会，数字表示和位并行接口-1125/60高清制作系统，SMPTE 260M-1999。
[6] Society of Motion Picture and Television Engineers, 1920x1080 50Hz, Scanning and Interface, SMPTE 295M-1997.
[6] 电影和电视工程师学会，1920x1080 50Hz，扫描和接口，SMPTE 295M-1997。
[7] Society of Motion Picture and Television Engineers, 1920x1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picture Rates, SMPTE 274M-1998.
[7] 电影和电视工程师学会，1920x1080多画面速率扫描、模拟和并行数字接口，SMPTE 274M-1998。
[8] Society of Motion Picture and Television Engineers, 1280x720 Scanning, Analog and Digital Representation and Analog Interfaces, SMPTE 296M-1998.
[8] 电影和电视工程师学会，1280x720扫描、模拟和数字表示以及模拟接口，SMPTE 296M-1998。
[9] ISO/IEC International Standard 13818-2; "Generic coding of moving pictures and associated audio information: Video", 1996.
[9] ISO/IEC国际标准13818-2；“运动图像和相关音频信息的通用编码：视频”，1996年。
[10] ATSC Digital Television Standard Document A/53, September 1995,
http://www.atsc.org
[10] ATSC Digital Television Standard Document A/53, September 1995,
http://www.atsc.org
[11] ISO/IEC International Standard 13818-1; "Generic coding of moving pictures and associated audio information: Systems",1996.
[11] ISO/IEC国际标准13818-1；“运动图像和相关音频信息的通用编码：系统”，1996年。
[12] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[12] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1998年1月。
[13] 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.
[13] Clark，D.D.和Tennenhouse，D.L.，“新一代协议的架构考虑”，载于SIGCOMM'90会议录（宾夕法尼亚州费城，1990年9月），ACM。
[14] Handley, H. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[14] Handley，H.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
Ladan Gharai USC/ISI 3811 Fairfax Dr. Arlington VA 22203
Ladan Gharai USC/ISI 3811费尔法克斯弗吉尼亚州阿灵顿博士22203
EMail: ladan@isi.edu
EMail: ladan@isi.edu
Colin Perkins USC/ISI 3811 Fairfax Dr. Arlington VA 22203
科林·帕金斯USC/ISI 3811费尔法克斯弗吉尼亚州阿灵顿博士22203
EMail: csp@csperkins.org
EMail: csp@csperkins.org
Allison Mankin Bell Labs, Lucent Corporation
朗讯公司Allison Mankin Bell实验室
EMail: mankin@psg.com
EMail: mankin@psg.com
Gary Goncher Tektronix, Inc. P.O. Box 500, M/S 50-480 Beaverton, OR 97077
Gary Goncher Tektronix，Inc.邮箱500，米/秒50-480比弗顿，或97077
EMail: Gary.Goncher@tek.com
EMail: Gary.Goncher@tek.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。