[要約] RFC 5484は、RTPストリームに時間コードを関連付けるための方法を提案しています。その目的は、異なるメディアストリーム間の同期を実現し、正確なタイミングでメディアを再生することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントでは、Motion Picture and Television Engineers（SMPTE）のSociety of Media Streamによって定義されているように、メディアストリーム自体のRTPペイロード形式に依存しない方法でメディアストリームを使用して、タイムコードを関連付けるメカニズムについて説明します。
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
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.
一般的な使用時のタイムコードシステムは、Motion Picture and Television Engineers（SMPTE）のSocietyによって定義されます。その中で、タイムコードはフレームをカウントします。ディスプレイの一般的な形式は、通常のクロック値のように見えます（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ビデオは、1秒あたり30フレーム（FPS）よりもわずかに遅く実行されます。一部の人々はそれを29.97と呼びますが、それはまったく正しくありません。正確にするために、フレームは30000ティック/ 2秒のクロックの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タイムコードディスプレイはリアルタイムと比較して「遅く実行」します。これを改善するために、ドロップフレームと呼ばれる形式が使用される場合があります。フレーム番号の一部はスキップされているため、カウンターが定期的に「追いつく」ことができます（実際、実際には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タイムコードが正確なクロックではないことは注目に値します。最初のケースでは、ゆっくりと動作し、2番目では調整が突然で周期的であり、それでもまったく正確ではありません。したがって、このドキュメントの残りの部分は、タイムコードの1秒を「タイムコード秒」と呼ぶときに明確にしようとします。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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:
私たちが望んでいるのは、RTP [RFC3550]ストリームでSMPTEタイムコードを一部のメディアに関連付けることができるシステムです。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:
考慮すべき2つのケースがあります。
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.
1つ目は、タイムコード軸の詳細と、RTCPパケットの定期マッピングと同様にRTP時間から時コードまでの初期マッピングを提供することで処理できます。これは、セクション6.3で定義されています。
The second requires in-band signaling within the RTP packets themselves. This is defined in Section 6.4.
2番目には、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ビットのフィールド対フルバイナリコード10進数（BCD）桁と2ビットBCD桁を2ビットのBCDディジットよりも大きいフレーム番号が許可することに注意してください。場合によっては、カラーフレームフラグ（ビット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).
プレゼンテーションに複数のストリームが含まれている場合、送信者は、同期に使用できるSMPTEタイムコードをストリームに運ぶ場合でも、RTCPで標準のRTP同期情報を引き続き送信する必要があります。実際、タイムコードが複数のストリームによって運ばれる場合、このドキュメントはタイムコードを制約しません。特定の時点で、それらは同じであるか、異なる場合があります（例えば、元のものを運ぶ場合一緒に編集された異なるソース素材の時間コード）。
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タイムスケールでの期間は、タイムコードの「フレーム」部分（Frame_Duration）の単一のフレームカウントの期間
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. タイムコードを2番目にするフレームの数（frames_per_tc_second）;framecounter値は0〜（frames_per_tc_second -1）の間である場合があります
3. the drop-frame indication, is-NTSC-drop-frame, which indicates whether the usual drop-frame behavior should be applied or not
3. ドロップフレームの表示、is-ntsc-dropフレーム。これは、通常のドロップフレームの動作を適用するかどうかを示す
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.
たとえば、1秒あたり90000ティックの一般的なタイムスケールを持つビデオストリームに関連付けられている場合、3003のフレームと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を明示的に供給することに注意してください。これにより、ドロップフレームカウントの場合にカウンター値がどうあるべきかについてのあいまいさが削除されます。これらの3つの値は互いに対応する必要があります。
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を使用すると、これらの3つのパラメーターは、次のABNF構文[RFC5234]を使用して、ヘッダー拡張仕様[RFC5285]で定義されているように、拡張アトリビュートとして送信されます。拡張属性の形式は、拡張名によって「所有」されます。拡張機能へのこれらのパラメーターでは、ここでのドキュメントを超えて登録アクションは必要ありません。特定のストリームでRTCPマッピングのみが使用されている場合でも、パラメーターはRTPでのインライン使用に適した拡張属性として提供されることに注意してください。
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
frame-duration-length = integer
timestamp-rate = integer
frame-duration = frame-duration-length "@" timestamp-rate
フレームデュレーション=フレームデューターレングス "@"タイムスタンプレート
frames-per-tc-second = integer
drop = "/drop"
drop = "/drop"
extensionattributes = frame-duration "/" frames-per-tc-second [drop]
extensionAttributes = frame-duration "/" frames-per-tc-second [drop]
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.
フレームの持続時間は、タイムスタンプレートのティックが1秒あたりの時計のティックのカウントとして指定されています。タイムスタンプレートは、タイムスタンプの変換の精度の損失を避けるために、拡張が埋め込まれている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仕様のセクション4.2.2で文書化されているように、数分、10、20、30、40、および50を除き、最初の2つのフレーム番号は毎分のカウントから省略されます。SMPTE-12M]。（これは通常、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
Another example, for drop-frame NTSC, on a stream with a timescale of 600, might be:
もう1つの例は、ドロップフレームNTSCの場合、タイムスケールの600のストリームで、次のようなものかもしれません。
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
seconds (6 bits) -- 0 to 59; 60-63 are reserved
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).
これらのフィールドは、BCD（バイナリコーディングされた小数）が使用されているSMPTE 12mのプロビジョニングよりも大きいことに注意してください（特に、フレームカウントの数十桁に2ビットしか提供されていないため、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ビットを占めています。16ビットの同期なしで、SMPTE 12m [SMPTE-12M]のセクション7および8で定義されているとおりにフォーマットされています。「ドロップフレームフラグ」の値は、シグナリングで「ドロップ」インジケーターの使用に同意する必要があります。
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 2番目のバイナリグループ
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 4番目のバイナリグループ
32--35 Units of minutes
32-35単位の分
36--39 Fifth binary group
36--39 5番目のバイナリグループ
40--42 Tens of minutes
40-42分
43 Binary group flag BGF0 44--47 Sixth binary group
43バイナリグループフラグBGF0 44--47 6番目のバイナリグループ
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 8番目のバイナリグループ
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タイムコードを計算可能なタイムコードの各実行の開始に供給します。これにより、後続のRTCPパケットがマッピングを再確立するまで、与えられたもの以下のすべてのRTPのタイムコードが確立されます。
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タイムスタンプを使用する必要はありません。可能であれば（必要に応じて」「必要に応じて」（たとえば、サーバーが先を見ることができるときのコンテンツなど）または「Just-in-time」を送信できます。たとえば、送信された「Just-in-Time」は、タイムコードの不連続性が検出された後、[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.
アソシエーションは、値194を使用して、新しいRTCPコントロールパケットタイプです（セクション10を参照）。このコントロールパケットには、その長さによって区別される2つのフォローフォームの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=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.
フィールドS（サイン）、時間、分、秒、およびフレームは、セクション6.1で定義されています。
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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.
このヘッダー拡張機能には2つの形式があり、再びそれらの長さによって区別されます。短いフォームは、コンパクトなタイムコードをパケットの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 Time 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.
このセクションには、時間T1の初期コードとフレームの持続時間が与えられた時間T2の時間コードの両方を計算する方法に関する提案が含まれています。
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.
ドロップフレームが使用されると、「フェンスポスト」の問題があるように思われるかもしれません。最初のタイムコード以来、フレーム番号が削除された時間は何分間ですか？ただし、すべての計算が「ゼロベース」である場合、これは回避できます。次に、「フェンスポスト」の数が既知です。
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ストリームに関連付けることができます。
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.
RTCPパケットが失われる可能性があるため、SDPにも初期マッピングを設定できると主張するかもしれません。しかし、これは、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は、次のデータに従って、RTCPコントロールパケットタイプにリアルタイムトランスポートプロトコル（RTP）パラメーターレジストリのサブレジストリに新しい値を追加しました。
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 Compact Header Extensionsのリアルタイムトランスポートプロトコル（RTP）パラメーターレジストリのサブレジストリに新しい拡張機能を登録しました。
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.
ブライアンリンクとジョンラザロは、最初のドラフトについて有益なコメントを提供しました。Colin Perkinsは、詳細のレビューと対処に役立ちました。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 3550、2003年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 4585、2006年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の増強」、STD 68、RFC 5234、2008年1月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]シンガー、D。およびH.デシネニ、「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 Standard-Time and Control Code」、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 Apple Computer Inc. 1 Infinite Loop Cupertino、CA 95014 US
Phone: +1 408 996 1010
EMail: singer@apple.com