Network Working Group D. Singer
Request for Comments: 5484 Apple Computer Inc.
Category: Standards Track March 2009
Associating Time-Codes with RTP Streams
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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）の協会によって定義されます。これで、タイムコードはフレームを数えます。ディスプレイの一般的な形態は、通常のクロック値（：MM：ss.frame HH）のように見えます。フレームレートが真に不可欠である場合にはその秒は、我々が知っている秒と愛と同じ速度でによってティックで、これは、通常のクロック値にすることができます。
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タイムコード表示の原因となります。これを改善するために、ドロップフレームと呼ばれる時々フォーマットが使用されます。カウンタは、定期的に（ので、いくつかのタイムコードの秒が実際にそれらだけで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).
一体型FPS（24のFPSまたはPALビデオでは、例えば、映画コンテンツ）を持つシステムで使用する場合ただし、SMPTEタイムコードがリアルタイムで実行します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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;
セグメントの開始のRTPタイムスタンプO。
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.
あなたはタイムコードを知りたいRTPタイムスタンプO。
There are two cases to consider:
考慮すべき2つのケースがあります。
1. the time-codes are piece-wise continuous with only occasional discontinuities;
1.タイムコードは、ピース単位のみ時折不連続と連続しています。
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.
コンパクトなフォームが完全形（完全な2進化10進数（BCD）桁と29の最大送信値を与える2ビットのBCD桁、対6ビットのフィールド）よりフレーム番号が大きくできることに留意されたいです。いくつかの場合において、カラーフレームフラグ（ビット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]に。この仕様は、セッション記述プロトコル（SDP）が使用されている一般的なヘッダ拡張[RFC5285]であるため、拡張機構によって定義された「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.タイムコードの「フレーム」部分（frame_duration）における単一のフレームカウントの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タイムコード（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.ドロップフレーム指示、通常のドロップフレームの動作を適用すべきか否かを示し、-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のframe_duration及び30のフレーム当たりTC-第二は、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を使用する場合、次のABNF構文[RFC5234]と、ヘッダ拡張仕様[RFC5285]で定義されるように、これら3つのパラメータは、extensionattributesとして送信されます。拡張属性の形式は、拡張名によって「所有」されます。延長にこれらのパラメータは、ここではそのドキュメントを超えて登録アクションは必要ありません。パラメータが指定されたストリームにのみRTCPマッピングが使用されている場合でも、RTPにおけるインラインの使用に適した拡張属性として供給されることに留意されたいです。
digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9"
桁= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
integer = 1*digit
整数= 1 *桁
frame-duration-length = integer
フレーム期間長=整数
timestamp-rate = integer
タイムスタンプレート=整数
frame-duration = frame-duration-length "@" timestamp-rate
フレーム期間=フレーム期間の長さ「@」のタイムスタンプ・レート
frames-per-tc-second = integer
フレーム当たりTC秒=整数
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.)
「/ドロップ」が指定されている場合SMPTE仕様のセクション4.2.2に記載されているように、その後、第2フレーム番号が[分00、10、20、30、40、及び50を除いて、毎分のカウントから省略されています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
= extmap：4 URN：IETF：paramsは：RTP-hdrext：24分の600 @ SMPTE-TC 25
Another example, for drop-frame NTSC, on a stream with a timescale of 600, might be:
別の例では、ドロップフレームNTSCのために、600のタイムスケールを持つストリームで、次のようになります。
a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 20@600/30/drop
= extmap：4 URN：IETF：paramsは：RTP-hdrext：30分の600 /ドロップ@ SMPTE-TC 20
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 - 0（1）署名
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
分（6ビット） - 0〜59。 60~63は予約秒（6ビット）である - 0〜59。 60-63は予約されています
frames(6 bits) -- 0 to (frames-per-tc-second - 1)
フレーム（6ビット） - 0（フレーム当たりTC秒 - 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（2進化10進数）を使用するSMPTE 12Mの規定、（より大きいと、特にであることに注意してください、39以上のフレーム番号ができないように2つだけのビットが、フレームカウントの十の位のために提供されます）で表されます。
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ビットを占めます。セクション7及びSMPTE 12M [SMPTE-12M]の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.
タイムコードは区分的に連続しているとき、私たちはその後、計算可能時間コードの各実行の開始のためのRTPタイムスタンプおよびSMPTEタイムコードをパケットRTCPに供給しています。後続のRTCPパケットは、マッピングを再確立するまで、これは、より大きい又は所定の1に等しいすべての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タイムスタンプを使用する必要はありません。これらは、可能な場合（例えば、サーバーが先に見ることができたときに、保存されたコンテンツのために、「）先に必要の」送らや「ジャストインタイム」することができます。タイムコードの不連続が検出された後、例えば、「ジャストインタイム」で送信されるパケットは、[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（セクション10を参照）を使用して、新しいRTCP制御パケットタイプです。この制御パケットは、その長さによって区別次の二つの形態の一つを有します。
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.
この短い形態のために、長さが4の32ビットワードの制御パケットを示す、固定値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=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.
このフルタイムコード（長尺形態）のために、長さが5の32ビットワードの制御パケットを示す、固定値4をとります。
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ヘッダ拡張はSMPTEタイムコードにRTPタイムを関連付けるために[RFC5285]を使用します。
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タイムコードで構成され、符号付き32ビットに続くRTPタイムスタンプから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.
このセクションでは、時刻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の知識を持っている必要があることを意味します。 1はすべての送信者レポートには、この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:
SMPTEタイムコードに使用されるRTCPパケットタイプは、[RFC3550]のセクション15に応じて、登録されています。 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）パラメータレジストリのRTPコンパクトヘッダー拡張サブレジストリに新しい拡張URIを登録しています：
Extension URI: urn:ietf:params:rtp-hdrext:smpte-tc Description: SMPTE time-code mapping Contact: singer@apple.com Reference: RFC 5484
拡張URI：URN：IETF：のparams：RTP-hdrext：SMPTE-TC説明：SMPTEタイムコードマッピングお問い合わせ：singer@apple.com参考：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.
ブライアン・リンクとジョンラザロの両方が初期の草稿に役に立つコメントを提供しました。コリン・パーキンスは、見直しや詳細を扱うのに役立ちました。ラダンGharaiは思慮深い、最終的なレビューを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、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]歌手、D.およびH. Desineni、 "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標準 - 時間と制御コード」映画テレビ技術の[SMPTE-12M]社会、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
デビッド・シンガーアップルコンピュータ社1無限ループクパチーノ、CA 95014米国
Phone: +1 408 996 1010 EMail: singer@apple.com
電話：+1 408 996 1010 Eメール：singer@apple.com