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.
このメモは、映画テレビ技術者協会（SMPTE）標準、SMPTE 292Mで定義されている非圧縮の高精細度テレビ（HDTV）をカプセル化するためのRTPペイロード形式を指定します。 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]は、ビデオ機器（カメラ、エンコーダ、のVTRなど）の様々なタイプの間で圧縮されていない高精細テレビ（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.
専用のシリアル相互接続の使用は、スタジオ環境で適切であるが、SMPTE 292Mコンテンツの効率的な広域配信を可能にし、高帯域幅のIP接続の広範な可用性を活用することが望ましいです。したがって、このメモは、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は、高度テレビジョン標準委員会の完全文書A / 53に記載されているMPEG-2の部分集合[9]、[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テレビラインは2つのインターリーブストリーム、輝度（Y）サンプル、他のクロミナンス（CRCB）値を含むものを含みます。クロミナンスが水平サブサンプルであるため、（4：2：2の符号化）は、2つのストリームが一致の長さ（[1] SMPTE 292Mの図3を参照）。各ストリームは、4つの部分（図1）に分割される：ストリームはまた、同一の構造を有する同じ長さであることに加えて、アクティブビデオタイミング基準（SAV）の（1）開始。 （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は、フラグの数を運ぶ、0x3FF $ 000 $ 000の定数値と（図2のXYZとして示される）追加のワードで、3つの10ビットワードで構成されています。これはまた、どのフィールド（1又は2）ラインが輸送され、フィールドブランキングを示すVフラグを指定Fフラグとを含みます。表1は、さらに、SAVとEAVのコード値が表示されます。 EAV後、SMPTE 292Mラインの11ビットの行番号を運ぶ二つの単語、LN0とLN1（表2）です。巡回冗長検査、CRCは、また、図2にCR0及びCR1として示した2つのワード値です。
+------------+-----------------------+-----+---------------------+
| | 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 ----->
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 |
+---------------------------------------------------------+
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". |
+---------------------------------------------------------+
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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パケットにパケット化されます。これは、すべてのタイミング信号、ブランキングレベル、アクティブライン及び/又は補助データを含みます。 SMPTE 292Mデコーダは走査線の開始を検出するためにそれらを使用するように、アクティブビデオ（SAV）およびアクティブビデオ（EAV + LN + CRC）信号の終わりの開始は、パケットを横切って断片化してはいけません。
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.
ペイロードヘッダは、それによって32ビットのシーケンス番号を拡張し、HDTVの高いデータレートに対応するためにRTPを可能にする、標準的な16ビットRTPシーケンス番号に16ビットの拡張を含んでいます。シーケンス番号がラップアラウンドする前に、少なくとも千オクテットのパケットサイズと1.485 Gbpsの、32ビットでおおよそ6時間を可能にします。明確損失を検出するために、注文のパケットのうちの十分されていない、同じ仮定が与えられると、標準的な16ビットのRTPシーケンス番号が（336ミリ秒）、1秒未満でラップアラウンド。
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.
148.5メガヘルツ（または148.5 / 1.001 MHzの）タイムスタンプは、RTPタイムスタンプとして使用されます。これは、受信機は、ソースフォーマット（例えば、SMPTE 274MまたはSMPTE 296M）の正確なタイプの知識がなくても、SMPTE 292Mストリームのタイミングを再構築することを可能にします。このタイムスタンプと、各パケットの最初のサンプルの位置を一意SMPTE 292Mストリームにおいて識別することができます。 148.5 MHzで、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部は、それによって15オクテット境界に整列オクテットになって、4つのピクセルの2基を表さなければなりません。この長さは、画素群またはPGROUPと呼ばれ、それはSDPパラメータに搬送されます。表3は、様々なカラーサンプリング用PGROUP値を表示します。 2：一般的なソースフォーマットが4使用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以内に断片化されるべきではありません。 1のPGROUP（これはソースフォーマットが知られていないインスタンスに適用可能である）データは、任意のオクテット境界で分割されてもよいことを示しています。 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 |
+-----------+-------+--------+-------------------+------+
Table 3. Color subsampling and pgroups.
表3色のサブサンプリングとpgroups。
The standard RTP header is followed by a 4 octet payload header, and the payload data, as shown in Figure 3.
図3に示すように、標準的なRTPヘッダは、4オクテットのペイロードヘッダに続いて、ペイロードデータです。
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は：RTPパケットは、SMPTE 292Mのヘッダとペイロードを示します
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トランスポートストリーム32個のビットは、タイムスタンプフィールドは、それぞれ、148.5メガヘルツ（または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シーケンス番号は、SMPTE 292Mの1.485 Gbpsのデータレートに対応するために、ペイロードヘッダ内の別の16ビットに拡張されます。
Sequence Number (high bits): 16 bits The high order bits for the 32 bit RTP sequence counter, in network byte order.
シーケンス番号（高ビット）：32ビットRTPシーケンスカウンタ16ビットの上位ビットを、ネットワークバイト順です。
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タイミング信号で定義されている（表1参照）をFビットをビット。 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：SMPTE 292Mタイミング信号（表1参照）で定義されるように1は、Vビットをビット。フィールドブランキングの間に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で指定されるようにRFC 1889が使用されるべきである[3]、RTCPパケットレート上の2つの制限を指定する：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で定義されたように、これらの2つのフィールドが正確にネットワーク監視目的や送信者のオクテット数とパケットの累積数を必要とする他のアプリケーションのために、オクテット数と、送信の開始以来、失われたパケットの数を表すことができないことを意味します送信の開始以来、失われた、アプリケーション自体はカウンターを経由して、これらのフィールドのロールオーバーの数を追跡する必要があります。
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タイムスタンプのクロックレートを評価します。クロックは1.485億ヘルツまたは1.485億/ 1.001 Hzのどちらかで動作します。後者の速度が使用される場合148351648のタイムスタンプを使用しなければなりません、そして受信機は1.485億/ 1.001ヘルツとしてこれを解釈しなければなりません。
Optional parameters: pgroup The RECOMMENDED grouping for aligning 10 bit words and octets. Defaults to 1 octet, if not present.
オプションのパラメータ：10ビット・ワードとオクテットを整列させるための推奨グループ化をPGROUP。 1つのオクテットデフォルトは、存在しない場合。
Encoding considerations: SMPTE292M video can be transmitted with RTP as specified in RFC 3497.
エンコードの考慮事項：RFC 3497で指定されているようSMPTE292Mビデオは、RTPで送信することができます。
Security considerations: see RFC 3497 section 9.
セキュリティの考慮事項：RFC 3497のセクション9を参照してください。
Interoperability considerations: NONE
相互運用性に関する注意事項：NONE
Published specification: SMPTE292M RFC 3497
公開された仕様：SMPTE292MのRFC 3497
Applications which use this media type: Video communication.
ビデオ通信：このメディアタイプを使用するアプリケーション。
Additional information: None
追加情報：なし
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): None
ファイルの拡張子（秒）：なし
Macintosh File Type Code(s): None
Macintoshのファイルタイプコード（S）：なし
Person & email address to contact for further information: Ladan Gharai <ladan@isi.edu> IETF AVT working group.
人と詳細のために連絡する電子メールアドレス：ラダンGharai <ladan@isi.edu> IETF AVTワーキンググループ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Ladan Gharai <ladan@isi.edu>
著者/変更コントローラ：ラダン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 =ビデオ30000 RTP / AVP 111 = rtpmap：111 SMPTE292M /1.485億=の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タイムスタンプは1.485億ヘルツであり、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.
このペイロード形式の帯域幅は、最も現在利用可能なインターネットパス上に送信された場合にサービス拒否の可能性を引き起こす（RTPオーバーヘッド無し1.485 Gbps）の十分に高いです。輻輳制御フローをRTP上SMPTE 292Mのために不可能であるので、ペイロードの使用は狭く、適切に接続されたネットワーク・エンドポイントへ、または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.
私たちは、彼の洞察に満ちたコメントや文書への貢献のためのデビッド・リチャードソンに感謝したいと思います。我々はまた、彼の入力をし、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、フレデリック、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年から1160年高精細生産システム、SMPTE 260M-1999。
[6] Society of Motion Picture and Television Engineers, 1920x1080 50Hz, Scanning and Interface, SMPTE 295M-1997.
[6]映画テレビ技術、1920×1080の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]映画テレビ技術者協会、1920×1080のスキャンとアナログおよび複数の画像の料金のためのパラレルデジタルインターフェイス、SMPTE 274M-1998。
[8] Society of Motion Picture and Television Engineers, 1280x720 Scanning, Analog and Digital Representation and Analog Interfaces, SMPTE 296M-1998.
[8]映画テレビ技術者協会、1280×720のスキャン、アナログとデジタル表示とアナログインタフェース、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デジタルテレビ標準文書A / 53、1995年9月、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]ホフマン、D.、フェルナンド、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]クラーク、D. D.、およびTennenhouse、D. L.、SIGCOMM '90の議事録で、 "プロトコルの新世代のための建築に関する注意事項"、（フィラデルフィア、PA、1990年9月）、ACM。
[14] Handley, H. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[14]ハンドリー、H.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
Ladan Gharai USC/ISI 3811 Fairfax Dr. Arlington VA 22203
ラダンGharai RSL / ISI 3811フェア博士アーリントンVA 22203
EMail: ladan@isi.edu
メールアドレス：ladan@isi.edu
Colin Perkins USC/ISI 3811 Fairfax Dr. Arlington VA 22203
コリンパーキンスUSC / ISI 3811フェア博士アーリントンVA 22203
EMail: csp@csperkins.org
メールアドレス：csp@csperkins.org
Allison Mankin Bell Labs, Lucent Corporation
アリソンマンキンベル研究所、ルーセント株式会社
EMail: mankin@psg.com
メールアドレス：mankin@psg.com
Gary Goncher Tektronix, Inc. P.O. Box 500, M/S 50-480 Beaverton, OR 97077
ゲイリーGoncherテクトロニクス株式会社私書箱ボックス500、M / S 50から480ビーバートン、OR 97077
EMail: Gary.Goncher@tek.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。