[要約] RFC 2431は、BT.656ビデオエンコーディングのためのRTPペイロード形式に関する規格です。このRFCの目的は、ビデオデータのエンコードと転送を効率的に行うための標準化を提供することです。
Network Working Group D. Tynan
Request for Comments: 2431 Claddagh Films
Category: Standards Track October 1998
RTP Payload Format for BT.656 Video Encoding
BT.656ビデオエンコーディングの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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.
このドキュメントでは、RTP（Real-Time Transport Protocol）でITU勧告BT.656-3ビデオストリームをカプセル化するためのRTPペイロード形式を指定しています。各RTPパケットには、ITU勧告BT.601-5で定義されている1本のスキャンラインのすべてまたは一部が含まれ、フラグメント化、デコード、および位置情報が含まれています。
This document describes a scheme to packetize uncompressed, studio-quality video streams as defined by BT.656 for transport using RTP [1]. A BT.656 video stream is defined by ITU-R Recommendation BT.656-3 [2], as a means of interconnecting digital television equipment operating on the 525-line or 625-line standards, and complying with the 4:2:2 encoding parameters as defined in ITU-R Recommendation BT.601-5 (formerly CCIR-601) [3], Part A.
このドキュメントでは、RT。[1]を使用して転送するために、BT.656で定義されている非圧縮のスタジオ品質のビデオストリームをパケット化するスキームについて説明します。 BT.656ビデオストリームは、525ラインまたは625ライン規格で動作し、4：2に準拠するデジタルテレビ機器を相互接続する手段として、ITU-R勧告BT.656-3 [2]によって定義されています。 ITU-R勧告BT.601-5（以前のCCIR-601）[3]、パートAで定義されている2つのエンコーディングパラメータ。
RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The complete specification of RTP for a particular application requires the RTP protocol document [1], a profile specification document [4], and a payload format specification. This document is intended to serve as the payload format specification for studio-quality video streams.
RTPはInternet Engineering Task Force（IETF）によって定義され、マルチキャストまたはユニキャストネットワークサービスを介してリアルタイムデータを送信するアプリケーションに適したエンドツーエンドのネットワーク転送機能を提供します。特定のアプリケーション用のRTPの完全な仕様には、RTPプロトコルドキュメント[1]、プロファイル仕様ドキュメント[4]、およびペイロードフォーマット仕様が必要です。このドキュメントは、スタジオ品質のビデオストリームのペイロード形式の仕様として機能することを目的としています。
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 RFC 2119 [5].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [5]で説明されているように解釈されます。
For the purposes of this document, the following definitions apply:
このドキュメントでは、次の定義が適用されます。
Y: An 8-bit or 10-bit coded "luminance" sample. Luminance in this context refers to the BT.601-5 [3] definition which is not the same as a true CIE luminance value. The value of "luminance" refers specifically to video luma. However, in order to avoid confusion with the BT.656 and BT.601 standards, the video luma value is referenced in this document as luminance. Each value has 220 quantization levels with the black level corresponding to level 16 and the peak white level corresponding to 235.
Y：8ビットまたは10ビットのコード化された「輝度」サンプル。このコンテキストでの輝度は、BT.601-5 [3]の定義を指します。これは、真のCIE輝度値とは異なります。 「輝度」の値は特にビデオ輝度を指します。ただし、BT.656およびBT.601規格との混同を避けるため、このドキュメントではビデオの輝度値を輝度として参照しています。各値には、黒のレベルがレベル16に対応し、ピークの白レベルが235に対応する220の量子化レベルがあります。
Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per BT.601-5). Each color-difference value has 225 quantization levels in the centre part of the quantization scale with a color-difference of zero having an encoded value of 128.
Cb、Cr：8ビットまたは10ビットのコード化された色差サンプル（BT.601-5による）。各色差値は、量子化スケールの中央部分に225の量子化レベルを持ち、0の色差は128のエンコード値を持っています。
True Black: BT.601-5 defines a true black level as the quad-sample sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values of 128 (0x80) and a luminance value of 16 (0x10).
トゥルーブラック：BT.601-5は、トゥルーブラックレベルを4つのサンプルシーケンス0x80、0x10、0x80、0x10として定義し、128（0x80）の色差値と16（0x10）の輝度値を表します。
SAV, EAV: Video timing reference codes which appear at the start and end of a BT.656 scan line.
SAV、EAV：BT.656スキャンラインの最初と最後に表示されるビデオタイミング参照コード。
ITU Recommendation BT.656-3 defines a schema for the digital interconnection of television video signals in conjunction with BT.601-5 which defines the digital representation of the original analog signal. While BT.601-5 refers to images with or without color subsampling, the interconnection standard (BT.656-3) specifically requires 4:2:2 subsampling. This specification also requires 4:2:2 subsampling such that the luminance stream occupies twice the bandwidth of each of the two color-difference streams. For normal 4:3 aspect ratio images, this results in 720 luminance samples per scan line, and 360 samples of each of the two chrominance channels. The total number of samples per scan line in this case is 1440. While this payload format specification can accomodate various image sizes and frame rates, only those in accordance with BT.601-5 are currently supported.
ITU勧告BT.656-3は、元のアナログ信号のデジタル表現を定義するBT.601-5と組み合わせて、テレビビデオ信号のデジタル相互接続のスキーマを定義しています。 BT.601-5はカラーサブサンプリングの有無にかかわらず画像を参照しますが、相互接続標準（BT.656-3）は特に4：2：2サブサンプリングを必要とします。この仕様では、輝度ストリームが2つの色差ストリームのそれぞれの帯域幅の2倍を占めるように、4：2：2サブサンプリングも必要です。通常の4：3アスペクト比の画像の場合、これにより、スキャンラインごとに720の輝度サンプルと、2つのクロミナンスチャネルのそれぞれの360サンプルが生成されます。この場合、スキャンラインあたりのサンプルの総数は1440です。このペイロード形式の仕様では、さまざまな画像サイズとフレームレートに対応できますが、現在サポートされているのはBT.601-5に準拠したものだけです。
Due to the lack of any form of video compression within the payload and sampling-rate compliance with BT.601-5, the resultant video stream can be considered "studio quality". However, such a stream can require approximately 20 megabytes per second of network bandwidth. In order to maximize packet size within a given MTU, and to optimize scan line decoding, each video scan line is encoded within one or more RTP packets.
ペイロード内にビデオ圧縮の形式がなく、サンプリングレートがBT.601-5に準拠しているため、結果のビデオストリームは「スタジオ品質」と見なすことができます。ただし、このようなストリームには、毎秒約20メガバイトのネットワーク帯域幅が必要になる場合があります。特定のMTU内のパケットサイズを最大化し、スキャンラインのデコードを最適化するために、各ビデオスキャンラインは1つ以上のRTPパケット内にエンコードされます。
To allow for scan line synchronization, each packet includes certain flag bits (as defined in BT.656-3) and a unique scan line number. The SAV and EAV timing reference codes are removed. Furthermore, no line blanking samples are included, so no ancillary data can be included in the line blanking period. It is the responsibility of the receiver to generate the timing reference codes, and to insert the correct number of line blanking samples.
スキャンラインの同期を可能にするために、各パケットには特定のフラグビット（BT.656-3で定義）と一意のスキャンライン番号が含まれています。 SAVおよびEAVタイミング基準コードが削除されました。さらに、ラインブランキングサンプルが含まれていないため、ラインブランキング期間に補助データを含めることはできません。タイミング基準コードを生成し、正しい数のラインブランキングサンプルを挿入するのはレシーバーの責任です。
Similarly, there is no requirement that the frame blanking samples be provided. However, it is possible to include frame blanking samples if such samples contain relevant information, such as a vertical-interlace time code (VITC), or teletext data. In the absence of frame blanking samples, the receiver MUST generate true black levels as defined above, to complete the correct number of scan lines per field. If frame blanking samples are provided, they MUST be copied without modification into the resultant BT.656-3 stream.
同様に、フレームブランキングサンプルを提供する必要はありません。ただし、サンプルに垂直インタレースタイムコード（VITC）やテレテキストデータなどの関連情報が含まれている場合は、フレームブランキングサンプルを含めることができます。フレームブランキングサンプルがない場合、レシーバーは、フィールドごとに正しい数のスキャンラインを完了するために、上記で定義された真の黒レベルを生成する必要があります。フレームブランキングサンプルが提供されている場合は、それらを変更せずに、結果のBT.656-3ストリームにコピーする必要があります。
Scan lines MUST be sent in sequential order. Error concealment for missing scan lines or fragments of scan lines is at the discretion of the receiver.
スキャンラインは順番に送られなければなりません。欠落した走査線または走査線の断片に対するエラー隠蔽は、受信者の裁量に任されています。
Both 8-bit and 10-bit quantization types as defined by BT.601-5 are supported. 10-bit samples are considered to have two extra bits of fixed-point precision such that a binary value of 10111110.11 represents a sample value of 190.75. Using 8-bit quantization, this would give a sample value of 190. An application receiving 8-bit samples for a 10-bit device MUST consider the sample as reflecting the most-significant 8 bits. The two least-significant bits SHOULD be set to zero. Similarly, an application sending 8-bit samples from a 10-bit device MUST drop the two least-significant bits. For a 10- bit quantization payload, each pair of samples MUST be encoded into a 40-bit word (five octets) prior to transmission, as specified in Section 6.
BT.601-5で定義されている8ビットと10ビットの両方の量子化タイプがサポートされています。 10ビットのサンプルは、2進数の値10111110.11がサンプル値190.75を表すように、固定小数点精度の2ビットが追加されていると見なされます。 8ビットの量子化を使用すると、サンプル値は190になります。10ビットデバイスの8ビットサンプルを受信するアプリケーションは、サンプルを最上位の8ビットを反映していると見なす必要があります。最下位2ビットはゼロに設定する必要があります（SHOULD）。同様に、10ビットデバイスから8ビットサンプルを送信するアプリケーションは、2つの最下位ビットをドロップする必要があります。セクション6で指定されているように、10ビットの量子化ペイロードの場合、サンプルの各ペアは、送信前に40ビットワード（5オクテット）にエンコードされる必要があります。
To allow for scan lines with octet lengths larger than the path maximum transmission unit (MTU), a scan offset field is included in the packet header. Applications SHOULD attempt path MTU discovery [6] and fragment scan lines into multiple packets no larger than the MTU.
パスの最大転送単位（MTU）より長いオクテット長のスキャンラインを可能にするために、スキャンオフセットフィールドがパケットヘッダーに含まれています。アプリケーションは、パスMTUディスカバリ[6]を試み、スキャン行をMTU以下の複数のパケットにフラグメント化する必要があります（SHOULD）。
Fragmentation MUST occur on a sample-pair boundary, such that the chrominance and luminance values are not split across packets. For 8-bit quantization this gives a four-octet alignment, and a five-octet alignment for 10-bit quantization. As a result, the scan offset refers not to the byte offset within the payload, but the sample-pair offset.
フラグメンテーションは、サンプルペアの境界で発生する必要があるため、クロミナンスとルミナンスの値がパケット間で分割されません。 8ビットの量子化では、これにより4オクテットのアライメントと、10ビットの量子化では5オクテットのアライメントが得られます。その結果、スキャンオフセットは、ペイロード内のバイトオフセットではなく、サンプルペアオフセットを参照します。
Due to the unreliable nature of the RTP protocol, and the lack of an orderly delivery mechanism, each packet contains enough information to form a single scan line without reference to prior scan lines or prior frames. In addition to the RTP header, a fixed length payload header is included in each packet. This header is four octets in length.
RTPプロトコルは信頼性が低く、秩序だった配信メカニズムがないため、各パケットには、以前のスキャンラインやフレームを参照せずに単一のスキャンラインを形成するのに十分な情報が含まれています。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for BT.656-3 encapsulation:
各RTPパケットは、固定RTPヘッダーで始まります。 RTP固定ヘッダーの次のフィールドは、BT.656-3カプセル化に使用されます。
Marker bit (M): The Marker bit of the RTP header is set to 1 for the last packet of a frame (or the last fragment of the last scan line if fragmented), and set to 0 on all other packets.
マーカービット（M）：RTPヘッダーのマーカービットは、フレームの最後のパケット（または断片化されている場合は最後のスキャンラインの最後のフラグメント）に対して1に設定され、他のすべてのパケットでは0に設定されます。
Payload Type (PT): The Payload Type indicates the use of the payload format defined in this document. A profile MAY assign a payload type value for this format either statically or dynamically as described in RFC 1890 [4].
ペイロードタイプ（PT）：ペイロードタイプは、このドキュメントで定義されているペイロード形式の使用を示します。 RFC 1890 [4]で説明されているように、プロファイルはこの形式のペイロードタイプ値を静的または動的に割り当てることができます（MAY）。
Timestamp: The RTP Timestamp encodes the sampling instant of the video frame currently being rendered. All scan line packets within the same frame will have the same timestamp. The timestamp SHOULD refer to the 'Ov' field synchronization point of the first field. For the payload format defined by this document, the RTP timestamp is based on a 90kHz clock.
タイムスタンプ：RTPタイムスタンプは、現在レンダリングされているビデオフレームのサンプリングインスタントをエンコードします。同じフレーム内のすべてのスキャンラインパケットは同じタイムスタンプを持ちます。タイムスタンプは、最初のフィールドの「Ov」フィールド同期ポイントを参照する必要があります（SHOULD）。このドキュメントで定義されているペイロード形式の場合、RTPタイムスタンプは90kHzクロックに基づいています。
The payload header is a fixed four-octet header broken down as follows:
ペイロードヘッダーは、次のように分解された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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1 bit When 0, indicates the first field of a frame (line 4 through 265 inclusive for Type=0 or 2, and line 1 through 312 inclusive for Type=1 or 3). Any other scan line is considered a component of the second field, and the F bit will be set to 1. This bit is copied directly from the BT.656-compliant stream by the transmitter, and inserted into the stream by the receiver.
F：1ビット0の場合、フレームの最初のフィールドを示します（Type = 0または2の場合はライン4〜265、Type = 1または3の場合はライン1〜312）。他のスキャンラインは2番目のフィールドのコンポーネントと見なされ、Fビットは1に設定されます。このビットは、トランスミッターによってBT.656準拠のストリームから直接コピーされ、レシーバーによってストリームに挿入されます。
V: 1 bit When 1, indicates that the scan line is part of the vertical interval. Should always be 0 unless frame blanking data is sent. In which case, the V bit SHOULD be set to 1 for scan lines which do not form an integral part of the image. This bit is copied directly from the BT.656-compliant stream by the transmitter, and inserted into the stream by the receiver. For receivers which do not receive scan lines during the vertical interval, BT.656 vertical interval data MUST be generated by repeating the quad-sample sequence 0x80, 0x10, 0x80, 0x10, representing a true black level.
V：1ビット1の場合、走査線が垂直間隔の一部であることを示します。フレームブランキングデータが送信されない限り、常に0である必要があります。その場合、画像の不可欠な部分を形成しない走査線については、Vビットを1に設定する必要があります（SHOULD）。このビットは、トランスミッタによってBT.656準拠のストリームから直接コピーされ、レシーバによってストリームに挿入されます。垂直間隔中にスキャンラインを受信しない受信機の場合、BT.656垂直間隔データは、真の黒レベルを表すクワッドサンプルシーケンス0x80、0x10、0x80、0x10を繰り返すことによって生成する必要があります。
Type: 4 bits This field indicates the type of frame encoding within the payload. It MUST remain unchanged for all scan lines within the same frame. Currently only four types of encoding are defined. These are as follows;
タイプ：4ビットこのフィールドは、ペイロード内のフレームエンコーディングのタイプを示します。同じフレーム内のすべてのスキャンラインで変更しないでください。現在、4種類のエンコーディングのみが定義されています。これらは次のとおりです。
0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields
per second; 525 lines per frame)
1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields
per second; 625 lines per frame)
2 - High Definition NTSC (18MHz sample rate; 1144 samples per
line; 60 fields per second; 525 lines per frame)
3 - High Definition PAL (18MHz sample rate; 1152 samples per
line; 50 fields per second; 625 lines per frame)
Further encodings can only be defined through the Internet Assigned Numbers Authority (IANA). For more information refer to Section 8, "IANA Considerations".
それ以上のエンコーディングは、Internet Assigned Numbers Authority（IANA）を通じてのみ定義できます。詳細については、セクション8「IANAに関する考慮事項」を参照してください。
P: 1 bit Indicates the required sample quantization size. When 0, the payload is comprised of 8-bit samples. Otherwise, it carries 10-bit samples. This bit MUST remain unchanged for all scan lines within the same frame.
P：1ビット必要なサンプル量子化サイズを示します。 0の場合、ペイロードは8ビットのサンプルで構成されます。それ以外の場合は、10ビットのサンプルを伝送します。このビットは、同じフレーム内のすべてのスキャンラインで変更されないままでなければなりません。
Z: 2 bits Reserved for future use. Must be set to zero by the transmitter and ignored by the receiver.
Z：2ビット将来使用するために予約されています。トランスミッタによってゼロに設定され、レシーバによって無視される必要があります。
Scan Line (SL): 12 bits Indicates the scan line encapsulated in the payload. Valid values range from 1 through 625 inclusive. If no frame blanking data is being transmitted, only scan lines 23 through 310 inclusive, and lines 336 through 623 inclusive SHOULD be sent in the case of Type=1 or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263 inclusive and lines 273 through 525 SHOULD be transmitted.
スキャンライン（SL）：12ビットペイロードにカプセル化されたスキャンラインを示します。有効な値の範囲は1〜625です。フレームブランキングデータが送信されていない場合、23行目から310行目までをスキャンし、Type 1または3の場合は336行目から623行目までを含めてください（SHOULD）。525/ 60エンコーディング（Type = 0または2）の場合は、 10行目から263行目まで、および273行目から525行目までを送信する必要があります（SHOULD）。
If a receiver is generating a BT.656-3 data stream directly from this packet, the F and V bits MUST be copied from the header rather than being generated implicitly from the scan line number. In the event of a conflict, the F and V bits have precedence.
レシーバーがこのパケットから直接BT.656-3データストリームを生成している場合、FおよびVビットは、スキャンライン番号から暗黙的に生成されるのではなく、ヘッダーからコピーする必要があります。競合が発生した場合は、FビットとVビットが優先されます。
Scan Offset (SO): 11 bits Indicates the offset within the scan line for application-level fragmentation. After doing PMTU discovery, if the path MTU is less than the required size for one complete scan line, the data SHOULD be fragmented such that a given RTP packet does not exceed the allowable MTU. The offset for the first packet of a scan line MUST be set to zero. The scan offset refers to the sample-pair offset within the scan such that for a scan line width of 720, the maximum scan offset is 359.
スキャンオフセット（SO）：11ビットアプリケーションレベルの断片化のスキャンライン内のオフセットを示します。 PMTUディスカバリを実行した後、パスMTUが1つの完全なスキャンラインに必要なサイズよりも小さい場合、データはフラグメント化して、特定のRTPパケットが許容MTUを超えないようにする必要があります。スキャンラインの最初のパケットのオフセットはゼロに設定する必要があります。スキャンオフセットとは、スキャン内のサンプルペアオフセットを指し、スキャンライン幅が720の場合、最大スキャンオフセットは359になります。
In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, each pair of color-difference samples will be intermixed with two luminance samples. As per BT.656, the format for transmission SHALL be Cb, Y, Cr, Y. The following is a representation of a 720 sample packet with 8-bit quantization:
BT.656とBT.601の4：2：2カラーサブサンプリングに合わせて、色差サンプルの各ペアは2つの輝度サンプルと混合されます。 BT.656に従い、送信フォーマットはCb、Y、Cr、Yである必要があります。以下は、8ビットの量子化を使用した720サンプルパケットの表現です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb0 | Y0 | Cr0 | Y1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb1 | Y2 | Cr1 | Y3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb359 | Y718 | Cr359 | Y719 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1144 and 1152 sample packets SHOULD increase the packet size accordingly while maintaining the sample order.
1144および1152サンプルパケットは、サンプルの順序を維持しながら、それに応じてパケットサイズを増やす必要があります。
For 10-bit quantization, each group of four samples MUST be encoded into a 40-bit word (five octets) prior to transmission. The sample order is identical to that for 8-bit quantization. The following is a representation of a 720 sample packet with 10-bit quantization:
10ビット量子化の場合、4つのサンプルの各グループは、送信前に40ビットワード（5オクテット）にエンコードされる必要があります。サンプルの順序は、8ビット量子化の場合と同じです。以下は、10ビット量子化を使用した720サンプルパケットの表現です。
0 1 2 3
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
+---------+---------+---------+---------+
| Cb0 | Y0 | Cr0 | Y1 |
+---------+---------+---------+---------+
| Cb1 | Y2 | Cr1 | Y3 |
+---------+---------+---------+---------+
.
.
.
+---------+---------+---------+---------+
| Cb359 | Y718 | Cr359 | Y719 |
+---------+---------+---------+---------+
(Note that the word width is 40 bits)
+-------+-------+-------+-------+-------+
Octets: | 0 | 1 | 2 | 3 | 4 |
+-------+-------+-------+-------+-------+
The octets shown in these diagrams are transmitted in network byte order, that is, left-to-right as shown.
これらの図に示されているオクテットは、ネットワークのバイト順、つまり左から右に送信されます。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This implies that confidentiality of the media streams is achieved by encryption. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[1]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。ペイロード形式はエンドツーエンドで配置されているため、暗号化はカプセル化の後に実行される場合があり、2つの操作間で競合は発生しません。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
このペイロードタイプは、パケット処理がサービス拒否の脅威を引き起こす可能性があるため、受信側の計算の複雑さに大きな不均一性はありません。
The four encoding types defined by this document relate to specific schema defined by ITU-R Recommendation BT.656-3. Future revisions of the recommendation may create further encoding types which need to be supported over RTP. The "Type" field is four bits wide allowing for a total of up to sixteen possible encodings, with twelve currently reserved for future use. Due to the small number of possible encodings and given that it is very unlikely that future revisions of BT.656 will introduce any new schema, requests to extend the Type field MUST be vetted by the Internet Assigned Numbers Authority. Furthermore, implementors SHOULD check the IANA repository for new definitions of the Type field in order to comply with this document.
このドキュメントで定義されている4つのエンコーディングタイプは、ITU-R勧告BT.656-3で定義されている特定のスキーマに関連しています。推奨事項の将来の改訂により、RTPでサポートする必要があるエンコードタイプがさらに作成される可能性があります。 「タイプ」フィールドは4ビット幅であり、合計で最大16の可能なエンコーディングが可能です。現在、12は将来の使用のために予約されています。可能なエンコーディングの数が少ないため、BT.656の将来のリビジョンで新しいスキーマが導入される可能性は非常に低いため、Typeフィールドを拡張するリクエストは、Internet Assigned Numbers Authorityによって検査される必要があります。さらに、実装者は、このドキュメントに準拠するために、Typeフィールドの新しい定義についてIANAリポジトリを確認する必要があります（SHOULD）。
Applications for a new Type value MUST be submitted to the IANA and include the requestors name and contact information, the reason for requesting a new Type and references to appropriate standards, such as an updated version of ITU-R Recommendation BT.656. Furthermore, in the unlikely event that the new Type will lessen the security of a compliant implementation, such security risk MUST be detailed in the application. The application will be reviewed by a Designated Expert and if appropriate, a new Type will be assigned. This type will be listed in the IANA repository for future implementations.
新しいタイプ値のアプリケーションはIANAに提出する必要があり、要求者の名前と連絡先情報、新しいタイプを要求する理由、およびITU-R勧告BT.656の更新バージョンなどの適切な標準への参照を含める必要があります。さらに、新しいTypeが準拠した実装のセキュリティを低下させるというまれなイベントでは、そのようなセキュリティリスクをアプリケーションで詳細に説明する必要があります。申請は指定専門家によって検討され、適切な場合は新しいタイプが割り当てられます。このタイプは、将来の実装のためにIANAリポジトリにリストされます。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
[2] Interfaces for Digital Component Video Signals in 525-Line and 625-Line Television Systems operating at the 4:2:2 Level of Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation BT.656-3, 1995.
[2] 4：2：2レベルの勧告ITU-R BT.601（パートA）、ITU-R勧告BT.656-3、1995で動作する525ラインおよび625ラインテレビシステムのデジタルコンポーネントビデオ信号のインターフェイス。
[3] Studio Encoding Parameters of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation BT.601-5, 1995.
[3] 標準4：3およびワイドスクリーン16：9アスペクト比のデジタルテレビのスタジオエンコーディングパラメータ、ITU-R勧告BT.601-5、1995。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conference with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne、H。、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、RFC 1890、1996年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6] Mogul、J。、およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
Dermot Tynan Claddagh Films Limited 3 White Oaks Clybaun Road Galway Ireland
Dermot Tynan Claddagh Films Limited 3 White Oaks Clybaun Road Galway Ireland
EMail: dtynan@claddagh.ie
Phone: +353 91 529944
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。