Network Working Group D. Singer
Request for Comments: 5484 Apple Computer Inc.
Category: Standards Track March 2009
Network Working Group D. Singer
Request for Comments: 5484 Apple Computer Inc.
Category: Standards Track March 2009
Associating Time-Codes with RTP Streams
将时间码与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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself.
本文档描述了一种机制，用于以独立于媒体流本身的RTP有效负载格式的方式将时间码（由电影和电视工程师协会（SMPTE）定义）与媒体流相关联。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Design Goals ....................................................3
4. Requirements and Constraints ....................................4
5. Signaling Information ...........................................4
6. In-Stream Information ...........................................6
6.1. Compact Format of the Time-Code ............................6
6.2. Full Format of the Time-Code ...............................7
6.3. Associations in RTCP .......................................8
6.4. Associations in RTP ........................................9
7. Implementation Note (Informative) ..............................10
8. Discussion (Informative) .......................................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................11
11. Acknowledgments ...............................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Design Goals ....................................................3
4. Requirements and Constraints ....................................4
5. Signaling Information ...........................................4
6. In-Stream Information ...........................................6
6.1. Compact Format of the Time-Code ............................6
6.2. Full Format of the Time-Code ...............................7
6.3. Associations in RTCP .......................................8
6.4. Associations in RTP ........................................9
7. Implementation Note (Informative) ..............................10
8. Discussion (Informative) .......................................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................11
11. Acknowledgments ...............................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
First a brief background on time-codes [SMPTE-12M].
首先简要介绍时间码[SMPTE-12M]的背景。
The time-code system in common use is defined by the Society of Motion Picture and Television Engineers (SMPTE); in it, time-codes count frames. A common form of the display looks like a normal clock value (hh:mm:ss.frame). When the frame rate is truly integral, then this can be a normal clock value, in that seconds tick by at the same rate as the seconds we know and love.
常用的时间编码系统由美国电影电视工程师协会（SMPTE）定义；在它里面，时间码计算帧数。一种常见的显示形式类似于正常的时钟值（hh:mm:ss.frame）。当帧速率是真正的整数时，这可以是一个正常的时钟值，即秒以与我们知道和喜爱的秒相同的速率滴答地过去。
However, NTSC video infamously runs slightly slower than 30 frames per second (fps). Some people call it 29.97, which isn't quite right; to be accurate, a frame takes 1001 ticks of a 30000 tick/ second clock. Be that as it may, SMPTE time-codes count 30 of these frames and deem that to make a second.
然而，众所周知，NTSC视频的运行速度略低于每秒30帧（fps）。有些人称之为29.97，这并不完全正确；准确地说，一帧需要每秒30000个时钟中的1001个时钟。尽管如此，SMPTE时间码计算这些帧中的30帧，并认为这是一秒。
This causes an SMPTE time-code display to 'run slow' compared to real-time. To ameliorate this, sometimes a format called drop-frame is used. Some of the frame numbers are skipped, so that the counter periodically 'catches up' (so some time-code seconds actually only have 28 frames in them).
这导致SMPTE时间代码显示与实时显示相比“运行缓慢”。为了改善这种情况，有时会使用一种称为drop frame的格式。跳过一些帧编号，以便计数器周期性地“赶上”（因此一些时间代码秒实际上只有28帧）。
It is worth noting that in neither case is the SMPTE time-code an accurate clock; in the first case, it runs slow, and in the second, the adjustments are abrupt and periodic -- and still not quite accurate. Hence the rest of this document tries to be clear when referring to a second in a time-code as a 'time-code second'.
值得注意的是，在这两种情况下，SMPTE时间码都不是精确的时钟；在第一种情况下，它运行缓慢，而在第二种情况下，调整是突然的、周期性的——但仍然不太准确。因此，本文档的其余部分在将时间代码中的秒称为“时间代码秒”时，试图澄清这一点。
However, SMPTE time-codes do run in real-time when used with systems with integral fps (e.g., film content at 24 fps or PAL video).
但是，SMPTE时间代码在与具有积分fps（例如，24 fps或PAL视频的电影内容）的系统一起使用时确实实时运行。
This specification defines how to carry time-codes in RTP and RTCP (RTP Control Protocol), associate them with a media stream, and synchronize them with the RTP timestamps. It uses the general RTP header extension mechanism [RFC5285].
本规范定义了如何在RTP和RTCP（RTP控制协议）中携带时间代码，将它们与媒体流关联，并将它们与RTP时间戳同步。它使用通用RTP报头扩展机制[RFC5285]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
What we desire is a system that allows us to associate an SMPTE time-code with some media in an RTP [RFC3550] stream. Since in RTP all media has a clock already, we can often leverage that fact. If we treat the media as having 'segments' of time in which the time-code is simply counting up, then the time-code anywhere within a segment can be calculated if you know:
我们需要的是一个系统，它允许我们将SMPTE时间代码与RTP[RFC3550]流中的某些媒体相关联。因为在RTP中，所有媒体都已经有了时钟，所以我们通常可以利用这一事实。如果我们将媒体视为具有时间段，其中时间代码只是简单地计数，那么可以计算段内任何位置的时间代码，前提是您知道：
o the RTP timestamp of the start of the segment;
o 段开始的RTP时间戳；
o the time-code of the start of the segment;
o 段开始的时间代码；
o the counting rate and other parameters of the time-code;
o 时间码的计数率等参数；
o the RTP timestamp where you want to know the time-code.
o 要知道时间代码的RTP时间戳。
There are two cases to consider:
有两种情况需要考虑：
1. the time-codes are piece-wise continuous with only occasional discontinuities;
1. 时间码是分段连续的，只有偶尔的间断；
2. the continuity of the time-codes is not certain (or not known).
2. 时间代码的连续性不确定（或未知）。
The first can be handled by providing details of the time-code axis and an initial mapping from RTP time to time-code time as well as periodic mappings in RTCP packets. This is defined in Section 6.3.
第一个问题可以通过提供时间码轴的详细信息和RTP时间码时间的初始映射以及RTCP数据包中的周期映射来处理。第6.3节对此进行了定义。
The second requires in-band signaling within the RTP packets themselves. This is defined in Section 6.4.
第二种方法需要RTP数据包本身内的带内信令。第6.4节对此进行了定义。
There are applications where the transport of all 8 bytes of the SMPTE 12M time-code are important (e.g., when the date of the time-code must be known or when the RTP transport is used as a transparent pipe). On the other hand, there are cases (e.g., when time-codes are used with compressed audio) when bandwidth is also important. To support both use cases, provision is made for both compact and full forms of the time-code.
在某些应用中，SMPTE 12M时间码的所有8个字节的传输都很重要（例如，必须知道时间码的日期或RTP传输用作透明管道时）。另一方面，在某些情况下（例如，当时间码与压缩音频一起使用时），带宽也很重要。为了支持这两种用例，提供了紧凑和完整形式的时间代码。
Receivers MUST support time-codes in both RTCP and RTP as well as both forms (compact and full) of the time-code. Senders, of course, are free to choose.
接收机必须同时支持RTCP和RTP以及两种形式（紧凑型和完整型）的时间码。当然，发件人可以自由选择。
Note that the compact form allows frame numbers greater than the full form (a field of 6 bits vs. a full binary-coded decimal (BCD) digit and a 2-bit BCD digit, which gives a maximum transmitted value of 29). In some cases, the color frame flag (bit 11) is used to 'extend' the "tens of frames" field from 2 to 3 bits; however, such practices are outside the scope of this specification.
请注意，紧凑形式允许帧编号大于完整形式（一个6位的字段与一个完整的二进制编码十进制（BCD）数字和一个2位BCD数字相比，其最大传输值为29）。在某些情况下，颜色帧标志（位11）用于将“十帧”字段从2位“扩展”到3位；但是，此类实践不在本规范的范围内。
In the case that a presentation contains more than one stream, senders MUST continue to send the standard RTP synchronization information in RTCP, even if the streams carry SMPTE time-codes that could be used for synchronization. In fact, when time-codes are carried by more than one stream, this document does not constrain the time-codes: at a given point in time, they may be the same, or they may differ (e.g., if they carry the original time-codes of different source material that was edited together).
在演示文稿包含多个流的情况下，发送方必须继续在RTCP中发送标准RTP同步信息，即使这些流包含可用于同步的SMPTE时间代码。事实上，当时间代码由多个流携带时，本文档不限制时间代码：在给定的时间点，它们可能相同，也可能不同（例如，如果它们携带的是一起编辑的不同源材料的原始时间代码）。
If the recipient must ever calculate time-codes based on the RTP times, then some setup information is needed. This MUST be sent out-of-band -- for example, in a SIP offer/answer exchange [RFC3264]. Since this specification is a general header extension [RFC5285], when the Session Description Protocol (SDP) is used, the 'extmap' attribute defined by the extension mechanism is also used.
如果收件人必须根据RTP时间计算时间代码，则需要一些设置信息。这必须在带外发送——例如，在SIP提供/应答交换[RFC3264]中。由于此规范是通用头扩展[RFC5285]，因此在使用会话描述协议（SDP）时，也会使用扩展机制定义的“extmap”属性。
The setup information should include:
设置信息应包括：
1. the duration, in the RTP timescale, of a single frame-count in the 'frames' portion of the time-code (frame_duration)
1. 在RTP时间刻度中，时间代码“帧”部分中单个帧计数的持续时间（帧持续时间）
2. the number of those frames that make a time-code second (frames_per_tc_second); framecounter values may be between 0 and (frames_per_tc_second - 1)
2. 使时间代码变为秒的帧数（每秒帧数）；帧计数器值可能介于0和（每秒帧数-1）之间
3. the drop-frame indication, is-NTSC-drop-frame, which indicates whether the usual drop-frame behavior should be applied or not
3. 下降帧指示为NTSC下降帧，指示是否应应用通常的下降帧行为
Note that other information we need to do the calculation (e.g., the clock rate of the RTP timestamp) is supplied already and assumed to be available.
请注意，我们需要进行计算的其他信息（例如，RTP时间戳的时钟速率）已经提供并假设可用。
For example, if associated with a video stream with the common time-scale of 90000 ticks per second, then a frame_duration of 3003 and frames-per-tc-second of 30 would yield a 'normal' SMPTE time-code for NTSC video. Similarly, values of 3750 and 24 yield a time-code for 24 fps film content, and so on.
例如，如果与公共时间标度为每秒90000个滴答声的视频流相关联，则帧_持续时间为3003，帧/tc秒为30将产生NTSC视频的“正常”SMPTE时间码。类似地，3750和24的值产生24 fps胶片内容的时间码，依此类推。
Note also that we supply explicitly the frame duration and fps, even though they are obviously closely related. This removes any ambiguity of what the counter values should be in the case of drop-frame counting. These three values MUST correspond with each other.
还要注意，我们明确提供了帧持续时间和fps，尽管它们显然密切相关。这消除了在丢弃帧计数的情况下计数器值应该是什么的任何模糊性。这三个值必须相互对应。
When the SDP is used, these three parameters are transmitted as extensionattributes, as defined in the header extension specification [RFC5285], with the following ABNF syntax [RFC5234]. The form of the extension attributes is 'owned' by the extension name. These parameters to the extension do not need registration action beyond their documentation here. Note that the parameters are supplied as extension attributes, suitable for in-line use in RTP, even if in a given stream only the RTCP mapping is used.
使用SDP时，这三个参数作为ExtensionAttribute传输，如标头扩展规范[RFC5285]中所定义，使用以下ABNF语法[RFC5234]。扩展属性的形式由扩展名“拥有”。扩展的这些参数不需要在此处的文档之外进行注册操作。请注意，参数作为扩展属性提供，适合在RTP中联机使用，即使在给定流中仅使用RTCP映射。
digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9"
digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9"
integer = 1*digit
integer = 1*digit
frame-duration-length = integer
frame-duration-length = integer
timestamp-rate = integer
timestamp-rate = integer
frame-duration = frame-duration-length "@" timestamp-rate
帧持续时间=帧持续时间长度“@”时间戳速率
frames-per-tc-second = integer
frames-per-tc-second = integer
drop = "/drop"
drop=“/drop”
extensionattributes = frame-duration "/" frames-per-tc-second [drop]
extensionattributes=帧持续时间“/”帧/tc秒[下降]
The frame duration is specified as a count of ticks of a clock that has timestamp-rate ticks per second. It is recommended that the timestamp-rate be the same as the clock rate of the RTP stream in which the extension is embedded, to avoid the loss of accuracy in conversion of timestamps. If the payload type changes during a stream, especially between payloads with different clock rates, it is strongly recommended that the header extension be included on the first packet(s) of the new payload, to set the mapping for the new clock rate explicitly.
帧持续时间指定为具有每秒时间戳速率的时钟的计时计数。建议时间戳速率与嵌入扩展的RTP流的时钟速率相同，以避免时间戳转换中的精度损失。如果有效负载类型在流期间改变，特别是在具有不同时钟速率的有效负载之间，则强烈建议在新有效负载的第一个分组上包括报头扩展，以明确地设置新时钟速率的映射。
If '/drop' is specified, then the first two frame numbers are omitted from the count of each minute, except for minutes 00, 10, 20, 30, 40, and 50, as documented in Section 4.2.2 of SMPTE specification [SMPTE-12M]. (Note that this usually only applies to NTSC video.)
如果指定了“/drop”，则每分钟的计数中会忽略前两个帧编号，但SMPTE规范[SMPTE-12M]第4.2.2节中记录的00、10、20、30、40和50分钟除外。（请注意，这通常仅适用于NTSC视频。）
The URI used for the signaling is
用于信令的URI为
"urn:ietf:params:rtp-hdrext:smpte-tc".
“urn:ietf:params:rtp hdrext:smpte tc”。
This URI signals the possible presence of associations in RTCP or RTP, as defined below.
此URI表示RTCP或RTP中可能存在关联，定义如下。
An example in the SDP, for film material, on a stream with a timescale of 600, might be:
SDP中的一个示例，对于时间刻度为600的流上的胶片材料，可以是：
a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
Another example, for drop-frame NTSC, on a stream with a timescale of 600, might be:
对于时间刻度为600的流上的丢弃帧NTSC，另一个示例可能是：
a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 20@600/30/drop
a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 20@600/30/drop
A compact binary SMPTE time-code in this design occupies 24 bits. It is NOT formatted in the BCD system, but uses binary fixed-width fields. It has the following structure:
在这种设计中，紧凑的二进制SMPTE时间码占用24位。它不在BCD系统中格式化，而是使用二进制固定宽度字段。其结构如下：
sign(1) -- 1 for negative, 0 for positive
符号（1）——1表示负，0表示正
hours (5 bits) -- 0 to 23; the values 24-31 are reserved
小时（5位）--0到23；保留值24-31
minutes (6 bits) -- 0 to 59; 60-63 are reserved
分钟（6位）--0到59；60-63人保留
seconds (6 bits) -- 0 to 59; 60-63 are reserved
秒（6位）--0到59；60-63人保留
frames(6 bits) -- 0 to (frames-per-tc-second - 1)
frames(6 bits) -- 0 to (frames-per-tc-second - 1)
Note that these fields are larger than the provision in SMPTE 12M, where BCD (binary-coded decimal) is used (and notably, where only two bits are provided for the tens digit of the frame-count, so frame numbers above 39 cannot be represented).
请注意，这些字段比SMPTE 12M中的规定要大，SMPTE 12M中使用BCD（二进制编码的十进制数）（值得注意的是，在SMPTE 12M中，只有两位用于帧计数的十位数，因此不能表示39以上的帧编号）。
A full SMPTE time-code occupies 64 bits. It is formatted exactly as defined in Sections 7 and 8 of SMPTE 12M [SMPTE-12M], without the 16-bit syncword. The value of the "drop frame flag" MUST agree with the use of the "drop" indicator in the signaling.
一个完整的SMPTE时间码占用64位。它的格式完全符合SMPTE 12M[SMPTE-12M]第7节和第8节的定义，没有16位同步字。“下降帧标志”的值必须与信号中“下降”指示器的使用一致。
Here are the bit assignments from SMPTE 12M, for information:
以下是SMPTE 12M的位分配，以供参考：
0--3 Units of frames
0--3帧单位
4--7 First binary group
4-7第一二进制群
8--9 Tens of frames
8-9十帧
10 Drop frame flag
10下降帧标志
11 Color frame flag
11色帧标志
12--15 Second binary group
12-15秒二进制群
16--19 Units of seconds
16-19秒的单位
20--23 Third binary group
20-23第三二进制群
24--26 Tens of seconds
24-26几十秒
27 Polarity correction
27极性校正
28--31 Fourth binary group
28--31第四二进制群
32--35 Units of minutes
32-35分钟单位
36--39 Fifth binary group
36-39第五二进制群
40--42 Tens of minutes
40-42十分钟
43 Binary group flag BGF0
43二进制组标志BGF0
44--47 Sixth binary group
44--47第六二进制群
48--51 Units of hours
48-51小时单位
52--55 Seventh binary group
52--55第七二进制群
56--57 Tens of hours
56-57十小时
58 Binary group flag BGF1
58二进制组标志BGF1
59 Binary group flag BGF2
59二进制组标志BGF2
60--63 Eighth binary group
60-63第八二进制群
When the time-codes are piece-wise continuous, we then supply in RTCP packets an RTP timestamp and an SMPTE time-code for the start of each run of calculable time-codes. This establishes the time-code for all RTP times greater than or equal to the one given, until a subsequent RTCP packet reestablishes the mapping.
当时间码分段连续时，我们在RTCP数据包中提供RTP时间戳和SMPTE时间码，用于每次可计算时间码运行的开始。这将为大于或等于给定时间的所有RTP时间建立时间代码，直到后续RTCP数据包重新建立映射。
Note that the RTP timestamp in the RTCP mapping may not match the timestamp of any frame in the media stream. For video, it normally would; but a timestamp transition may happen part-way through a decoded audio frame. Since they share the same clock, the timing of that transition and the timing of the audio stream itself have the same accuracy.
注意，RTCP映射中的RTP时间戳可能与媒体流中任何帧的时间戳不匹配。对于视频，它通常会；但时间戳转换可能在解码音频帧的部分过程中发生。因为它们共享相同的时钟，所以该转换的定时和音频流本身的定时具有相同的精度。
The RTCP packets need not use the same RTP timestamp as the sender report (or transmission time) in the same RTCP packet. They can be sent 'ahead of need' if possible (e.g., for stored content, when the server can look ahead) or 'just-in-time'. For example, packets sent 'just-in-time' may be sent as early feedback packets, following the rules in [RFC4585], after a discontinuity in the time-code is detected. Such packets allow media-buffering in the client the chance to 'catch' the RTCP before the matching RTP packet is processed and displayed.
RTCP数据包不需要使用与同一RTCP数据包中的发送方报告（或传输时间）相同的RTP时间戳。如果可能的话，它们可以“提前”发送（例如，对于存储内容，服务器可以提前发送）或“及时发送”。例如，在检测到时间码的不连续性之后，按照[RFC4585]中的规则，发送的“及时”数据包可以作为早期反馈数据包发送。这样的数据包允许在处理和显示匹配的RTP数据包之前，客户端中的媒体缓冲有机会“捕获”RTCP。
The association is a new RTCP Control Packet Type, using the value 194 (see Section 10). This control packet has one of the two following forms, differentiated by its length.
关联是一种新的RTCP控制数据包类型，使用值194（见第10节）。此控制数据包具有以下两种形式之一，根据其长度进行区分。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC |PT=SMPTETC=194 | length=3 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|S| hours | minutes | seconds | frames | reserved=0 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC |PT=SMPTETC=194 | length=3 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|S| hours | minutes | seconds | frames | reserved=0 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 1: RTCP Short Form Packet
图1:RTCP短格式数据包
The fields S (sign), hours, minutes, seconds, and frames are defined in Section 6.1.
第6.1节定义了字段S（符号）、小时、分钟、秒和帧。
For this short form, the length takes the fixed value 3, indicating a control packet of 4 32-bit words.
对于这种简短形式，长度采用固定值3，表示由4个32位字组成的控制包。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC |PT=SMPTETC=194 | length=4 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Full 8-byte |
| SMPTE 12M time-code |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC |PT=SMPTETC=194 | length=4 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Full 8-byte |
| SMPTE 12M time-code |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 2: RTCP Full Form Packet
图2:RTCP完整格式数据包
For this full time-code (long form), the length takes the fixed value 4, indicating a control packet of 5 32-bit words.
对于这个全时代码（长格式），长度取固定值4，表示由5个32位字组成的控制包。
When the time-codes are not known to be piece-wise continuous, or absolute surety of mapping is desired, then the mapping can be placed into some or all of the RTP packets. This is a less desirable route; it uses the RTP header extension [RFC5285], which some terminals may find problematic. And clearly placing mapping information in every packet uses more bandwidth.
当不知道时间码是分段连续的，或者需要绝对保证映射时，则可以将映射放入部分或全部RTP分组中。这是一条不太理想的路线；它使用RTP报头扩展[RFC5285]，一些终端可能会发现该扩展有问题。显然，在每个数据包中放置映射信息会占用更多带宽。
In as many RTP packets as needed (possibly all), an RTP header extension is used [RFC5285] to associate an RTP time to an SMPTE time-code.
在所需的尽可能多的RTP数据包（可能全部）中，使用RTP报头扩展[RFC5285]将RTP时间与SMPTE时间代码相关联。
There are two forms of this header extension, again differentiated by their length. The short form associates a compact time-code with the RTP timestamp of the packet. The long form allows associates a full time-code with a timestamp offset from the RTP timestamp of the packet.
此标题扩展有两种形式，同样根据其长度进行区分。缩写形式将紧凑的时间代码与数据包的RTP时间戳相关联。长格式允许将全时代码与来自分组的RTP时间戳的时间戳偏移相关联。
The short form has a length of 3 bytes (24 bits). The long form has a length of 12 bytes (96 bits) and consists of a full SMPTE 12M time-code, followed by a signed 32-bit offset D from the RTP timestamp. If the packet has timestamp T, this establishes an RTP to time-code association for the RTP time T+D.
短格式的长度为3字节（24位）。长格式的长度为12字节（96位），由完整的SMPTE 12M时间码组成，后跟RTP时间戳的有符号32位偏移量D。如果数据包具有时间戳T，这将为RTP时间T+D建立RTP到时间代码的关联。
This section contains a suggestion on how to calculate both a time-code for a time T2, given an initial code at time T1, and the frame duration.
本节包含关于如何计算时间T2的时间代码（给定时间T1的初始代码）和帧持续时间的建议。
It might seem that when drop-frame is used, there is a 'fence post' problem: how many minutes in which frame-numbers are dropped have passed since the initial time-code? However, this can be avoided if all calculations are 'zero-based'; then the number of 'fence posts' is known.
当使用drop frame时，似乎存在一个“篱笆柱”问题：从初始时间代码开始，删除帧号的时间已经过去了多少分钟？但是，如果所有计算都是“基于零”的，则可以避免这种情况；那么“栅栏柱”的数量是已知的。
framesSinceTCzero := TimeCodeToFrameCount( initialTimeCode );
framesSinceMapping := floor( (T2-T1)/frameDuration );
totalFrames := framesSinceTCzero + framesSinceMapping;
timeCode := FrameCountToTimeCode( totalFrames );
framesSinceTCzero := TimeCodeToFrameCount( initialTimeCode );
framesSinceMapping := floor( (T2-T1)/frameDuration );
totalFrames := framesSinceTCzero + framesSinceMapping;
timeCode := FrameCountToTimeCode( totalFrames );
The SMPTE engineering guideline [SMPTE-EG40] contains all the appropriate equations, constants, etc. for performing these and other conversions.
SMPTE工程指南[SMPTE-EG40]包含执行这些和其他转换的所有适当方程式、常数等。
This design has the advantage of not requiring the introduction of new IP packets into the sessions or new data into the main data channel by using low-bandwidth (vanishingly low in the case of streams with no discontinuities), and it is independent of the design of the RTP packets themselves: the RTP profile (including possibly encryption) and the RTP payload format. SMPTE time-codes can be associated with any RTP stream, including those with existing payload formats.
这种设计的优点是，不需要通过使用低带宽（在没有中断的流的情况下，带宽非常低）将新的IP包引入会话或将新数据引入主数据通道，并且它独立于RTP包本身的设计：RTP配置文件（可能包括加密）以及RTP有效负载格式。SMPTE时间码可以与任何RTP流相关联，包括具有现有有效负载格式的RTP流。
It might be argued that we could set the initial mapping also in the SDP, since RTCP packets might get lost. But this means that the SDP now has to have knowledge of the RTP random offset, which is nasty; also, if one puts this RTCP packet into all sender reports, that's probably good enough. Then if you don't have time-codes, you don't have audio-video-sync either.
有人可能会说，我们也可以在SDP中设置初始映射，因为RTCP数据包可能会丢失。但这意味着SDP现在必须知道RTP随机偏移量，这是令人讨厌的；此外，如果将此RTCP数据包放入所有发送方报告中，可能就足够了。如果你没有时间码，你也没有音频视频同步。
This specification associates the time-code with a particular media stream. An alternative would be to make it an RTP stream in its own right; however, the data rate is so low, this seems egregious. By packing it inline, we can do this backwards-compatible for gateways, etc., that already handle dual-stream.
此规范将时间代码与特定媒体流相关联。另一种选择是使其本身成为RTP流；然而，数据速率如此之低，这似乎令人震惊。通过内联打包，我们可以为已经处理双流的网关等实现向后兼容。
There is no way described in this document to detect that an RTCP packet has been lost and that a mapping may be being used outside its intended range.
本文档中描述的方法无法检测RTCP数据包是否丢失以及映射是否在其预期范围之外使用。
The design assumes that clients will hold mappings until they are superseded, and that a client may need to buffer some number of upcoming mappings.
该设计假设客户机将保留映射，直到它们被取代，并且客户机可能需要缓冲一些即将到来的映射。
SMPTE time-codes are only informative and there are no known security considerations from associating them with media streams.
SMPTE时间码仅提供信息，将其与媒体流关联时没有已知的安全注意事项。
The RTCP packet type used for SMPTE time-codes has been registered, in accordance with Section 15 of [RFC3550]. IANA has added a new value to the RTCP Control Packet types sub-registry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
根据[RFC3550]第15节的规定，已注册SMPTE时间码所用的RTCP数据包类型。IANA已根据以下数据向实时传输协议（RTP）参数注册表的RTCP控制数据包类型子注册表添加了一个新值：
abbrev. name value Reference
--------- ----------------------- ------ ---------
SMPTETC SMPTE time-code mapping 194 RFC 5484
abbrev. name value Reference
--------- ----------------------- ------ ---------
SMPTETC SMPTE time-code mapping 194 RFC 5484
Additionally, IANA has registered a new extension URI to the RTP Compact Header Extensions sub-registry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
此外，IANA已根据以下数据向实时传输协议（RTP）参数注册表的RTP Compact Header Extensions子注册表注册了一个新的扩展URI：
Extension URI: urn:ietf:params:rtp-hdrext:smpte-tc
Description: SMPTE time-code mapping
Contact: singer@apple.com
Reference: RFC 5484
Extension URI: urn:ietf:params:rtp-hdrext:smpte-tc
Description: SMPTE time-code mapping
Contact: singer@apple.com
Reference: RFC 5484
Both Brian Link and John Lazzaro provided helpful comments on an initial draft. Colin Perkins was helpful in reviewing and dealing with the details. Ladan Gharai provided a thoughtful final review.
Brian Link和John Lazzaro都对初稿提出了有益的意见。科林·帕金斯在审查和处理细节方面很有帮助。Ladan Gharai提供了深思熟虑的最终审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
[SMPTE-12M] Society of Motion Picture and Television Engineers, "SMPTE Standard for Television -- Time and Control Code", SMPTE 12M-1-2008.
[SMPTE-12M]电影和电视工程师学会，“SMPTE电视标准——时间和控制代码”，SMPTE 12M-1-2008。
[SMPTE-EG40] SMPTE, "Conversion of Time Values Between SMPTE 12M Time Code, MPEG-2 PCR Time Base and Absolute Time", SMPTE EG40-2002, August 2002.
[SMPTE-EG40]SMPTE，“SMPTE 12M时间码、MPEG-2 PCR时基和绝对时间之间的时间值转换”，SMPTE EG40-2002，2002年8月。
Author's Address
作者地址
David Singer Apple Computer Inc. 1 Infinite Loop Cupertino, CA 95014 US
David Singer苹果计算机公司1无限循环库珀蒂诺，加利福尼亚州95014美国
Phone: +1 408 996 1010
EMail: singer@apple.com
Phone: +1 408 996 1010
EMail: singer@apple.com