[要約] RFC 4175は、非圧縮ビデオのRTPペイロード形式を定義しています。その目的は、高品質のビデオストリームを効率的に伝送することです。
Network Working Group L. Gharai
Request for Comments: 4175 USC/ISI
Category: Standards Track C. Perkins
University of Glasgow
September 2005
RTP Payload Format for Uncompressed Video
非圧縮ビデオの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 (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed.
このメモは、非圧縮ビデオをリアルタイム転送プロトコル（RTP）のペイロード形式にカプセル化するためのパケット化スキームを指定します。 ITU BT.601などの一般的なテレビ形式や、SMPTE 274MやSMPTE 296MなどのSociety of Motion Picture and Television Engineers（SMPTE）の標準を含む、さまざまな標準および高精細ビデオ形式をサポートしています。この形式は、新しいビデオ形式が開発されたときに適用および拡張できるように設計されています。
This memo defines a scheme to packetize uncompressed, studio-quality video streams for transport using RTP [RTP]. It supports a range of standard and high-definition video formats, including ITU-R BT.601 [601], SMPTE 274M [274] and SMPTE 296M [296].
このメモは、RTP [RTP]を使用して転送するために、非圧縮のスタジオ品質のビデオストリームをパケット化するスキームを定義しています。 ITU-R BT.601 [601]、SMPTE 274M [274]、SMPTE 296M [296]など、さまざまな標準および高解像度ビデオフォーマットをサポートしています。
Formats for uncompressed standard definition television are defined by ITU Recommendation BT.601 [601] along with bit-serial and parallel interfaces in Recommendation BT.656 [656]. These formats allow both 625-line and 525-line operation, with 720 samples per digital active line, 4:2:2 color sub-sampling, and 8- or 10-bit digital representation.
非圧縮標準解像度テレビのフォーマットは、ITU勧告BT.601 [601]と、勧告BT.656 [656]のビットシリアルおよびパラレルインターフェイスによって定義されています。これらのフォーマットは、625ラインと525ラインの両方の動作を可能にし、デジタルアクティブラインあたり720サンプル、4：2：2カラーサブサンプリング、8ビットまたは10ビットデジタル表現を備えています。
The representation of uncompressed high-definition television is specified in SMPTE standards 274M [274] and 296M [296]. SMPTE 274M defines a family of scanning systems with an image format of 1920x1080 pixels with progressive and interlaced scanning, while SMPTE 296M defines systems with an image size of 1280x720 pixels and progressive scanning. In progressive scanning, scan lines are displayed in sequence from top to bottom of a full frame. In interlaced scanning, a frame is divided into its odd and even scan lines (called fields) and the two fields are displayed in succession. SMPTE 274M and 296M define images with aspect ratios of 16:9, and define the digital representation for RGB and YCbCr components. In the case of YCbCr components, the Cb and Cr components are horizontally sub-sampled by a factor of two (4:2:2 color encoding).
非圧縮ハイビジョンテレビの表現は、SMPTE規格274M [274]および296M [296]で指定されています。 SMPTE 274Mは、1920x1080ピクセルの画像フォーマットでプログレッシブスキャンとインターレーススキャンを使用するスキャンシステムのファミリを定義し、SMPTE 296Mは、画像サイズが1280x720ピクセルでプログレッシブスキャンのシステムを定義します。プログレッシブスキャンでは、走査線がフレーム全体の上から下に順に表示されます。インターレーススキャンでは、フレームが奇数および偶数のスキャンライン（フィールドと呼ばれます）に分割され、2つのフィールドが連続して表示されます。 SMPTE 274Mおよび296Mは、アスペクト比が16：9の画像を定義し、RGBおよびYCbCrコンポーネントのデジタル表現を定義します。 YCbCrコンポーネントの場合、CbおよびCrコンポーネントは水平方向に2倍にサブサンプリングされます（4：2：2カラーエンコーディング）。
Although these formats differ in their details, they are structurally very similar. This memo specifies a payload format to encapsulate these and other similar video formats for transport within RTP.
これらの形式は詳細が異なりますが、構造的には非常に似ています。このメモは、RTP内での転送のためにこれらおよび他の同様のビデオ形式をカプセル化するペイロード形式を指定します。
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 [2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [2119]で説明されているように解釈されます。
Each scan line of digital video is packetized into one or more RTP packets. If the data for a complete scan line exceeds the network MTU, the scan line SHOULD be fragmented into multiple RTP packets, each smaller than the MTU. A single RTP packet MAY contain data for more than one scan line. Only the active samples are included in the RTP payload: inactive samples and the contents of horizontal and vertical blanking SHOULD NOT be transported. In instances where ancillary data is being transmitted, the sender and receiver can disambiguate between ancillary and video data via scan line numbers. That is, the ancillary data will use scan line numbers that are not within the scope of the video frame.
デジタルビデオの各スキャンラインは、1つ以上のRTPパケットにパケット化されます。完全なスキャンラインのデータがネットワークMTUを超える場合、スキャンラインは、それぞれがMTUより小さい複数のRTPパケットにフラグメント化されるべきです（SHOULD）。単一のRTPパケットには、複数のスキャンラインのデータが含まれる場合があります。 RTPペイロードにはアクティブなサンプルのみが含まれます。非アクティブなサンプルと水平および垂直ブランキングの内容は転送しないでください。補助データが送信されている場合、送信側と受信側は、スキャンライン番号を介して補助データとビデオデータを区別できます。つまり、補助データは、ビデオフレームのスコープ内にないスキャンライン番号を使用します。
Scan line numbers are included in the RTP payload header, along with a field identifier for interlaced video.
スキャンライン番号は、インターレースビデオのフィールド識別子とともにRTPペイロードヘッダーに含まれています。
For SMPTE 296M format video, valid scan line numbers are from 26 through 745, inclusive. For progressive scan SMPTE 274M format video, valid scan lines are from scan line 42 through 1121, inclusive. For interlaced scan SMPTE 274M format video, valid scan line numbers for field one (F=0) are from 21 to 560 and valid scan line numbers for the second field (F=1) are from 584 to 1123. For ITU-R BT.601 format video, the blanking intervals defined in BT.656 are used: for 625 line video, lines 24 to 310 of field one (F=0) and 337 to 623 of the second field (F=1) are valid; for 525 line video, lines 21 to 263 of the first field, and 284 to 525 of the second field are valid. Other formats (e.g., [372]) may define different ranges of active lines.
SMPTE 296M形式のビデオの場合、有効なスキャンライン番号は26〜745です。プログレッシブスキャンSMPTE 274Mフォーマットのビデオの場合、有効なスキャンラインはスキャンライン42から1121までです。インターレーススキャンSMPTE 274Mフォーマットのビデオの場合、フィールド1（F = 0）の有効なスキャンライン番号は21〜560で、2番目のフィールド（F = 1）の有効なスキャンライン番号は584〜1123です。ITU-RBTの場合.601形式のビデオ、BT.656で定義されたブランキング間隔が使用されます。625ラインビデオの場合、フィールド1（F = 0）のライン24〜310および2番目のフィールド（F = 1）の337〜623が有効です。 525ラインのビデオの場合、最初のフィールドの21〜263行目、および2番目のフィールドの284〜525行目が有効です。他のフォーマット（[372]など）は、アクティブラインの異なる範囲を定義する場合があります。
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 the payload format to accommodate high data rates without ambiguity. This is necessary as the 16-bit RTP sequence number will roll over very quickly for high data rates. For example, for a 1-Gbps video stream with packet sizes of at least 1000 octets, the standard RTP packet will roll over in 0.5 seconds, which can be a problem for detecting loss and out-of-order packets particularly in instances where the round-trip time is greater than half a second. The extended 32-bit number allows for a longer wrap-around time of approximately nine hours.
ペイロードヘッダーには、標準の16ビットRTPシーケンス番号への16ビット拡張が含まれているため、シーケンス番号が32ビットに拡張され、ペイロード形式が曖昧さなく高いデータレートに対応できるようになります。これは、16ビットのRTPシーケンス番号が高いデータレートで非常に速くロールオーバーするために必要です。たとえば、パケットサイズが1000オクテット以上の1 Gbpsビデオストリームの場合、標準のRTPパケットは0.5秒でロールオーバーされます。これは、特にパケットの損失や順序の乱れを検出する場合に問題になる可能性があります往復時間が0.5秒を超えています。拡張された32ビットの数値により、約9時間という長いラップアラウンド時間が可能になります。
Each scan line comprises an integer number of pixels. Each pixel is represented by a number of samples. Samples may be coded as 8-, 10-, 12-, or 16-bit values. A sample may represent a color component or a luminance component of the video. Color samples may be shared between adjacent pixels. The sharing of color samples between adjacent pixels is known as color sub-sampling. This is typically done in the YCbCr color space for the purpose of reducing the size of the image data.
各走査線は整数のピクセルを含む。各ピクセルは、いくつかのサンプルによって表されます。サンプルは、8、10、12、または16ビット値としてコード化できます。サンプルは、ビデオの色成分または輝度成分を表すことができる。カラーサンプルは隣接するピクセル間で共有できます。隣接するピクセル間でのカラーサンプルの共有は、カラーサブサンプリングと呼ばれます。これは通常、画像データのサイズを縮小する目的でYCbCr色空間で行われます。
Pixels that share sample values MUST be transported together as a "pixel group". If 10-bit or 12-bit samples are used, each pixel may also comprise a non-integer number of octets. In this case, several pixels MUST be combined into an octet-aligned pixel group for transmission. These restrictions simplify the operation of receivers by ensuring that the complete payload is octet aligned, and that samples relating to a single pixel are not fragmented across multiple packets [ALF].
サンプル値を共有するピクセルは、「ピクセルグループ」として一緒に転送する必要があります。 10ビットまたは12ビットのサンプルが使用される場合、各ピクセルは非整数のオクテットを含むこともあります。この場合、いくつかのピクセルは送信のためにオクテット整列ピクセルグループに結合されなければなりません。これらの制限により、完全なペイロードがオクテットに揃えられ、単一のピクセルに関連するサンプルが複数のパケットにわたってフラグメント化されないようにすることで、レシーバーの操作が簡素化されます[ALF]。
For example, in YCbCr video with 4:1:1 color sub-sampling, each group of 4 adjacent pixels comprises 6 samples, Y1 Y2 Y3 Y4 Cr Cb, with the Cr and Cb values being shared between all 4 pixels. If samples are 8-bit values, the result is a group of 4 pixels comprising 6 octets. If, however, samples are 10-bit values, the resulting 60-bit group is not octet aligned. To be both octet aligned and appropriately framed, two groups of 4 adjacent pixels must be collected, thereby becoming octet aligned on a 15-octet boundary. This length is referred to as the pixel group size ("pgroup").
たとえば、4：1：1カラーサブサンプリングを使用するYCbCrビデオでは、4つの隣接するピクセルの各グループは6つのサンプルY1 Y2 Y3 Y4 Cr Cbで構成され、CrとCbの値は4つのピクセルすべてで共有されます。サンプルが8ビット値の場合、結果は6オクテットで構成される4ピクセルのグループになります。ただし、サンプルが10ビット値の場合、結果の60ビットグループはオクテットアラインされません。オクテット配置と適切なフレーム化の両方を行うには、4つの隣接するピクセルの2つのグループを収集する必要があります。これにより、15オクテットの境界でオクテット配置になります。この長さは、ピクセルグループサイズ（ "pgroup"）と呼ばれます。
Formally, the "pgroup" parameter is the size in octets of the smallest grouping of pixels such that 1) the grouping comprises an integer number of octets; and 2) if color sub-sampling is used, samples are only shared within the grouping. When packetizing digital active line content, video data MUST NOT be fragmented within a pgroup.
形式的には、「pgroup」パラメータは、1）グループ化がオクテットの整数で構成されるような、ピクセルの最小グループ化のオクテット単位のサイズです。 2）カラーサブサンプリングを使用する場合、サンプルはグループ内でのみ共有されます。デジタルアクティブラインコンテンツをパケット化する場合、pgroup内でビデオデータをフラグメント化しないでください。
Video content is almost always associated with additional information such as audio tracks, time code, etc. In professional digital video applications, this data is commonly embedded in non-active portions of the video stream (horizontal and vertical blanking periods) so that precise and robust synchronization is maintained. This payload format requires that applications using such synchronized ancillary data SHOULD deliver it in separate RTP sessions that operate concurrently with the video session. The normal RTP mechanisms SHOULD be used to synchronize the media.
ビデオコンテンツは、ほとんどの場合、オーディオトラック、タイムコードなどの追加情報に関連付けられています。プロ用のデジタルビデオアプリケーションでは、このデータは通常、ビデオストリームの非アクティブ部分（水平および垂直ブランキング期間）に埋め込まれるため、正確かつ正確に堅牢な同期が維持されます。このペイロード形式では、そのような同期された補助データを使用するアプリケーションが、ビデオセッションと同時に動作する個別のRTPセッションでそれを配信する必要があります。メディアを同期するには、通常のRTPメカニズムを使用する必要があります（SHOULD）。
The standard RTP header is followed by a 2-octet payload header that extends the RTP Sequence Number, and by a 6-octet payload header for each line (or partial line) of video included. One or more lines, or partial lines, of video data follow. This format makes the payload header 32-bit aligned in the common case, where one scan line (or fragment) of video is included in each RTP packet.
標準のRTPヘッダーの後には、RTPシーケンス番号を拡張する2オクテットのペイロードヘッダーと、含まれるビデオの各行（または部分的な行）の6オクテットのペイロードヘッダーが続きます。ビデオデータの1つ以上の行、または部分的な行が続きます。この形式では、ペイロードヘッダーが32ビットに揃えられます。一般的なケースでは、ビデオの1つのスキャンライン（またはフラグメント）が各RTPパケットに含まれます。
For example, if two lines of video are encapsulated, the payload format will be as shown in Figure 1.
たとえば、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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Line No |C| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |F| Line No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Offset | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Two (partial) lines of video data .
. .
+---------------------------------------------------------------+
Figure 1: RTP Payload Format showing two (partial) lines of video
図1：ビデオの2つの（部分的な）行を示すRTPペイロード形式
The fields of the fixed RTP header have their usual meaning, with the following additional notes:
固定RTPヘッダーのフィールドには通常の意味があり、次の追加の注記があります。
Payload Type (PT): 7 bits
ペイロードタイプ（PT）：7ビット
A dynamically allocated payload type field that designates the payload as uncompressed video.
ペイロードを非圧縮ビデオとして指定する動的に割り当てられたペイロードタイプフィールド。
Timestamp: 32 bits
タイムスタンプ：32ビット
For progressive scan video, the timestamp denotes the sampling instant of the frame to which the RTP packet belongs. Packets MUST NOT include data from multiple frames, and all packets belonging to the same frame MUST have the same timestamp.
プログレッシブスキャンビデオの場合、タイムスタンプは、RTPパケットが属するフレームのサンプリングの瞬間を示します。パケットには複数のフレームからのデータを含めてはならず（MUST NOT）、同じフレームに属するすべてのパケットは同じタイムスタンプを持つ必要があります。
For interlaced video, the timestamp denotes the sampling instant of the field to which the RTP packet belongs. Packets MUST NOT include data from multiple fields, and all packets belonging to the same field MUST have the same timestamp. Use of field timestamps, rather than a frame timestamp and field indicator bit, is needed to support reverse 3-2 pulldown.
インターレースビデオの場合、タイムスタンプは、RTPパケットが属するフィールドのサンプリングの瞬間を示します。パケットには複数のフィールドからのデータを含めてはならず（MUST NOT）、同じフィールドに属するすべてのパケットは同じタイムスタンプを持つ必要があります。逆3-2プルダウンをサポートするには、フレームタイムスタンプとフィールドインジケータビットではなく、フィールドタイムスタンプを使用する必要があります。
A 90-kHz timestamp SHOULD be used in both cases. If the sampling instant does not correspond to an integer value of the clock (as may be the case when interleaving), the value SHALL be truncated to the next lowest integer, with no ambiguity.
どちらの場合も、90 kHzのタイムスタンプを使用する必要があります。サンプリングの瞬間がクロックの整数値に対応しない場合（インターリーブの場合のように）、値はあいまいさのない次の最も低い整数に切り捨てられる必要があります（SHALL）。
Marker bit (M): 1 bit
マーカービット（M）：1ビット
If progressive scan video is being transmitted, the marker bit denotes the end of a video frame. If interlaced video is being transmitted, it denotes the end of the field. The marker bit MUST be set to 1 for the last packet of the video frame/field. It MUST be set to 0 for other packets.
プログレッシブスキャンビデオが送信されている場合、マーカービットはビデオフレームの終わりを示します。インターレースビデオが送信されている場合、それはフィールドの終わりを示します。ビデオフレーム/フィールドの最後のパケットでは、マーカービットを1に設定する必要があります。他のパケットの場合は0に設定する必要があります。
Sequence Number: 16 bits
シーケンス番号：16ビット
The low-order bits for RTP sequence number. The standard 16-bit sequence number is augmented with another 16 bits in the payload header in order avoid problems due to wrap-around when operating at high rate rates.
RTPシーケンス番号の下位ビット。標準の16ビットシーケンス番号は、ペイロードヘッダー内の別の16ビットで拡張され、高レートで動作するときのラップアラウンドによる問題を回避します。
Extended Sequence Number: 16 bits
拡張シーケンス番号：16ビット
The high order bits of the extended 32-bit sequence number, in network byte order.
拡張32ビットシーケンス番号の上位ビット（ネットワークバイト順）。
Length: 16 bits
長さ：16ビット
Number of octets of data included from this scan line, in network byte order. This MUST be a multiple of the pgroup value.
このスキャンラインから含まれるデータのオクテット数（ネットワークバイト順）。これはpgroup値の倍数でなければなりません。
Line No.: 15 bits
行番号：15ビット
Scan line number of encapsulated data, in network byte order. Successive RTP packets MAY contains parts of the same scan line (with an incremented RTP sequence number, but the same timestamp), if it is necessary to fragment a line.
カプセル化されたデータの行番号をネットワークバイト順でスキャンします。連続するRTPパケットには、ラインをフラグメント化する必要がある場合、同じスキャンラインの一部が含まれる場合があります（RTPシーケンス番号は増加しますが、タイムスタンプは同じです）。
Offset: 15 bits
オフセット：15ビット
Offset of the first pixel of the payload data within the scan line. If YCbCr format data is being transported, this is the pixel offset of the luminance sample; if RGB format data is being transported, it is the pixel offset of the red sample; if BGR format data is being transported, it is the pixel offset of the blue sample. The value is in network byte order. The offset has a value of zero if the first sample in the payload corresponds to the start of the line, and increments by one for each pixel.
スキャンライン内のペイロードデータの最初のピクセルのオフセット。 YCbCr形式のデータが転送されている場合、これは輝度サンプルのピクセルオフセットです。 RGB形式のデータが転送されている場合、それは赤いサンプルのピクセルオフセットです。 BGR形式のデータが転送されている場合、それは青のサンプルのピクセルオフセットです。値はネットワークバイト順です。ペイロードの最初のサンプルが行の先頭に対応する場合、オフセットの値は0で、ピクセルごとに1ずつ増加します。
Field Identification (F): 1 bit
フィールド識別（F）：1ビット
Identifies which field the scan line belongs to, for interlaced data. F=0 identifies the first field and F=1 the second field. For progressive scan data (e.g., SMPTE 296M format video), F MUST always be set to zero.
インターレースデータの場合、スキャンラインが属するフィールドを識別します。 F = 0は最初のフィールドを識別し、F = 1は2番目のフィールドを識別します。プログレッシブスキャンデータ（SMPTE 296M形式のビデオなど）の場合、Fは常にゼロに設定する必要があります。
Continuation (C): 1 bit
継続（C）：1ビット
Determines if an additional scan line header follows the current scan line header in the RTP packet. Set to 1 if an additional header follows, implying that the RTP packet is carrying data for more than one scan line. Set to 0 otherwise. Several scan lines MAY be included in a single packet, up to the path MTU limit. The only way to determine the number of scan lines included per packet is to parse the payload headers.
追加のスキャンラインヘッダーがRTPパケットの現在のスキャンラインヘッダーの後に続くかどうかを決定します。追加のヘッダーが続く場合は1に設定されます。これは、RTPパケットが複数のスキャンラインのデータを運ぶことを意味します。それ以外の場合は0に設定します。パスMTUの制限まで、複数のスキャンラインを1つのパケットに含めることができます。パケットごとに含まれるスキャンラインの数を決定する唯一の方法は、ペイロードヘッダーを解析することです。
Depending on the video format, each RTP packet can include either a single complete scan line, a single fragment of a scan line, or one (or more) complete scan lines and scan line fragments. The length of each scan line or scan line fragment MUST be an integer multiple of the pgroup size in octets. Scan lines SHOULD be fragmented so that the resulting RTP packet is smaller than the path MTU.
ビデオ形式に応じて、各RTPパケットには、単一の完全な走査線、走査線の単一のフラグメント、または1つ（または複数）の完全な走査線と走査線フラグメントを含めることができます。各スキャンラインまたはスキャンラインフラグメントの長さは、オクテット単位のpgroupサイズの整数倍でなければなりません。結果のRTPパケットがパスMTUよりも小さくなるように、スキャンラインをフラグメント化する必要があります（SHOULD）。
It is possible that the scan line length is not evenly divisible by the number of pixels in a pgroup, so the final pixel data of a scan line does not align to either an octet or a pgroup boundary. Nonetheless, the payload MUST contain a whole number of pgroups; the sender MUST fill the remaining bits of the final pgroup with zero and the receiver MUST ignore the fill data. (In effect, the trailing edge of the image is black-filled to a pgroup boundary.)
スキャンラインの長さがpgroupのピクセル数で割り切れない可能性があるため、スキャンラインの最終的なピクセルデータは、オクテットまたはpgroupの境界に整列しません。それにもかかわらず、ペイロードには整数のpgroupが含まれている必要があります。送信者は最後のpgroupの残りのビットをゼロで埋めなければならず（MUST）、受信者は埋められたデータを無視しなければなりません（MUST）。 （実際には、画像の後縁はpgroup境界まで黒で塗りつぶされます。）
For RGB format video, samples are packed in order Red-Green-Blue. For BGR format video, samples are packed in order Blue-Green-Red. For both formats, if 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15- octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms a separate 6-octet pgroup.
RGB形式のビデオの場合、サンプルは赤、緑、青の順にパックされます。 BGR形式のビデオの場合、サンプルは青、緑、赤の順にパックされます。どちらの形式でも、8ビットのサンプルが使用される場合、pgroupは3オクテットです。 10ビットのサンプルが使用される場合、4つの隣接するピクセルからのサンプルは15オクテットのpgroupを形成します。 12ビットのサンプルが使用される場合、2つの隣接するピクセルからのサンプルは9オクテットのpgroupを形成します。 16ビットのサンプルが使用される場合、各ピクセルは個別の6オクテットpgroupを形成します。
For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. For BGRA format video, samples are packed in order Blue-Green-Red-Alpha. For 8-, 10-, 12-, or 16-bit samples, each pixel forms its own pgroup, with octet sizes of 4, 5, 6, and 8, respectively.
RGBA形式のビデオの場合、サンプルはRed-Green-Blue-Alphaの順にパックされます。 BGRA形式のビデオの場合、サンプルはBlue-Green-Red-Alphaの順にパックされます。 8、10、12、または16ビットのサンプルの場合、各ピクセルは独自のpgroupを形成し、オクテットサイズはそれぞれ4、5、6、および8です。
If the video is in YCbCr format, the packing of samples into the payload depends on the color sub-sampling used.
ビデオがYCbCrフォーマットの場合、ペイロードへのサンプルのパッキングは、使用されるカラーサブサンプリングによって異なります。
For YCbCr 4:4:4 format video, samples are packed in order Cb-Y-Cr for both interlaced and progressive frames. If 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15-octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms a separate 6-octet pgroup.
YCbCr 4：4：4フォーマットのビデオの場合、サンプルはインターレースフレームとプログレッシブフレームの両方でCb-Y-Crの順にパックされます。 8ビットのサンプルが使用される場合、pgroupは3オクテットです。 10ビットのサンプルが使用される場合、4つの隣接するピクセルからのサンプルは15オクテットのpgroupを形成します。 12ビットのサンプルが使用される場合、2つの隣接するピクセルからのサンプルは9オクテットのpgroupを形成します。 16ビットのサンプルが使用される場合、各ピクセルは個別の6オクテットpgroupを形成します。
For YCbCr 4:2:2 format video, the Cb and Cr components are horizontally sub-sampled by a factor of two (each Cb and Cr sample corresponds to two Y components). Samples are packed in order Cb0- Y0-Cr0-Y1 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from two adjacent pixels (4, 5, 6, or 8 octets, respectively).
YCbCr 4：2：2フォーマットのビデオの場合、CbおよびCrコンポーネントは水平方向に2倍にサブサンプリングされます（各CbおよびCrサンプルは2つのYコンポーネントに対応します）。サンプルは、インターレーススキャンラインとプログレッシブスキャンラインの両方でCb0- Y0-Cr0-Y1の順序でパックされます。 8、10、12、または16ビットのサンプルの場合、pgroupは2つの隣接するピクセル（それぞれ4、5、6、または8オクテット）から形成されます。
For YCbCr 4:1:1 format video, the Cb and Cr components are horizontally sub-sampled by a factor of four (each Cb and Cr sample corresponds to four Y components). Samples are packed in order Cb0- Y0-Y1-Cr0-Y2-Y3 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from four adjacent pixels (6, 15, 9, or 12 octets, respectively).
YCbCr 4：1：1フォーマットのビデオの場合、CbおよびCrコンポーネントは水平方向に4倍にサブサンプリングされます（各CbおよびCrサンプルは4つのYコンポーネントに対応します）。インターレーススキャンラインとプログレッシブスキャンラインの両方について、サンプルはCb0- Y0-Y1-Cr0-Y2-Y3の順序でパックされます。 8、10、12、または16ビットのサンプルの場合、pgroupは4つの隣接するピクセル（それぞれ6、15、9、または12オクテット）から形成されます。
For YCbCr 4:2:0 video, the Cb and Cr components are sub-sampled by a factor of two both horizontally and vertically. Therefore, chrominance samples are shared between certain adjacent lines. Figure 2 shows the composition of luminance and chrominance samples for a 6x6 pixel grid of 4:2:0 YCbCr video. The pixel group is a group of four pixels arranged in a 2x2 matrix. The octet size of the pgroup for progressive scan 4:2:0 video with samples sizes of 8, 10, 12, and 16 bits is 6, 15, 9, and 12 octets, respectively. For interlaced 4:2:0 video, the corresponding pgroups are 4, 5, 6, and 8 octets.
YCbCr 4：2：0ビデオの場合、CbおよびCrコンポーネントは、水平および垂直の両方で2倍にサブサンプリングされます。したがって、クロミナンスサンプルは特定の隣接するライン間で共有されます。図2は、4：2：0 YCbCrビデオの6x6ピクセルグリッドの輝度サンプルとクロミナンスサンプルの構成を示しています。ピクセルグループは、2x2マトリックスに配置された4つのピクセルのグループです。サンプルサイズが8、10、12、16ビットのプログレッシブスキャン4：2：0ビデオのpgroupのオクテットサイズは、それぞれ6、15、9、12オクテットです。インターレース4：2：0ビデオの場合、対応するpgroupは4、5、6、および8オクテットです。
line 0: Y00 Y01 Y02 Y03 Y04 Y05 Cb00 Cr00 Cb01 Cr01 Cb02 Cr02 line 1: Y10 Y11 Y12 Y13 Y14 Y15
ライン0：Y00 Y01 Y02 Y03 Y04 Y05 Cb00 Cr00 Cb01 Cr01 Cb02 Cr02ライン1：Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20 Y21 Y22 Y23 Y24 Y25 Cb10 Cr10 Cb11 Cr11 Cb12 Cr12 line 3: Y30 Y31 Y32 Y33 Y34 Y35
ライン2：Y20 Y21 Y22 Y23 Y24 Y25 Cb10 Cr10 Cb11 Cr11 Cb12 Cr12ライン3：Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40 Y41 Y42 Y43 Y44 Y45 Cb20 Cr20 Cb21 Cr21 Cb22 Cr22 line 5: Y50 Y51 Y52 Y53 Y54 Y55
ライン4：Y40 Y41 Y42 Y43 Y44 Y45 Cb20 Cr20 Cb21 Cr21 Cb22 Cr22ライン5：Y50 Y51 Y52 Y53 Y54 Y55
Figure 2: Chrominance/luminance composition in 4:2:0 YCbCr video
When packetizing progressive scan 4:2:0 YCbCr video, samples from two consecutive scan lines are included in each packet. The scan line number in the payload header is set to that of the first scan line of the pair:
プログレッシブスキャン4：2：0 YCbCrビデオをパケット化する場合、2つの連続するスキャンラインからのサンプルが各パケットに含まれます。ペイロードヘッダーのスキャンライン番号は、ペアの最初のスキャンラインの番号に設定されます。
line 0/1: Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01 Y04-Y05-Y14-Y15-Cb02-Cr02
行0/1：Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01 Y04-Y05-Y14-Y15-Cb02-Cr02
line 2/3: Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11 Y24-Y25-Y34-Y35-Cb12-Cr12
2/3行目：Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11 Y24-Y25-Y34-Y35-Cb12-Cr12
line 4/5: Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21 Y44-Y45-Y54-Y55-Cb22-Cr22
4/5行目：Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21 Y44-Y45-Y54-Y55-Cb22-Cr22
Figure 3: Packetization of progressive 4:2:0 YCbCr video
For interlaced transport, chrominance samples are transported with every other line. The first set of chrominance samples may be transported with either the first line of field 0, or the first line of field 1. Figure 4 illustrates the transport of chrominance samples starting with the first line of field 0 (signaled by the "top-field-first" MIME parameter).
インターレース転送の場合、クロミナンスサンプルは1本おきに転送されます。クロミナンスサンプルの最初のセットは、フィールド0の最初のラインまたはフィールド1の最初のラインで転送できます。図4は、フィールド0の最初のラインで始まるクロミナンスサンプルの転送を示しています（「トップフィールド-first "MIMEパラメータ）。
field 0: line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02 line 2: Y20-Y21 Y22-Y23 Y24-Y25 line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
フィールド0：行0：Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02行2：Y20-Y21 Y22-Y23 Y24-Y25行4：Y40-Y41-Cb20-Cr20 Y42 -Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
field 1: line 1: Y10-Y11 Y12-Y13 Y14-Y15 line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12 line 5: Y50-Y51 Y52-Y53 Y54-Y55
フィールド1：行1：Y10-Y11 Y12-Y13 Y14-Y15行3：Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12行5：Y50-Y51 Y52-Y53 Y54-Y55
Figure 4: Packetization of interlaced 4:2:0 YCbCr video with top-field-first.
図4：トップフィールドファーストのインターレース4：2：0 YCbCrビデオのパケット化。
Chrominance values may be sampled with different offsets relative to luminance values. For instance, in Figure 2, chrominance values are sampled at the same distance from neighboring luminance samples. It is also possible for a chrominance sample to be co-sited with a luminance sample, as in Figure 5:
クロミナンス値は、ルミナンス値に対して異なるオフセットでサンプリングできます。たとえば、図2では、クロミナンス値は、隣接する輝度サンプルから同じ距離でサンプリングされています。図5のように、クロミナンスサンプルを輝度サンプルと同じ場所に配置することもできます。
line 0: Y00-C Y01 Y02-C Y03 Y04-C Y05
行0：Y00-C Y01 Y02-C Y03 Y04-C Y05
line 1: Y10 Y11 Y12 Y13 Y14 Y15
行1：Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25
2行目：Y20-C Y21 Y22-C Y23 Y24-C Y25
line 3: Y30 Y31 Y32 Y33 Y34 Y35
3行目：Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45
4行目：Y40-C Y41 Y42-C Y43 Y44-C Y45
line 5: Y50 Y51 Y52 Y53 Y54 Y55
5行目：Y50 Y51 Y52 Y53 Y54 Y55
Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C designates a CbCr pair
図5：CがCbCrペアを指定する4：2：0 YCbCrビデオでの共存ビデオサンプリング
In general, chrominance values may be placed between luminance samples or co-sited. Positions can be designated by an integer numbering system starting from left to right and top to bottom. The position matrices shown in Figures 6, 7, and 8 apply for 4:2:0, 4:2:2, and 4:1:1 video, respectively:
一般に、クロミナンス値は、輝度サンプルの間に配置するか、共存させることができます。位置は、左から右、上から下の整数の番号付けシステムで指定できます。図6、7、および8に示す位置行列は、それぞれ4：2：0、4：2：2、および4：1：1ビデオに適用されます。
line N: Y[0] [1] Y[2] Y[0] [1] Y[2]
[3] [4] Y[5] [3] [4] [5]
line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8]
Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3] line N+1: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]
ラインN：Y [0] [1] Y [2] [3] Y [0] [1] Y [2] [3]ラインN + 1：Y [0] [1] Y [2] [3] AND [0] [1] AND [2] [3]
Figure 7: Chrominance position matrix for 4:2:2 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[4] [5] Y[6] line N+1: Y[0] [1] Y[2] [3] Y[4] [5] Y[6]
ラインN：Y [0] [1] Y [2] [3] Y [4] [5] Y [6]ラインN + 1：Y [0] [1] Y [2] [3] Y [4 ] [5] AND [6]
Figure 8: Chrominance position matrix for 4:1:1 YCbCr video
Although these positions do not affect the packetization order of chrominance and luminance samples, the information is needed for interpolation prior to display and therefore should be signaled to the receiver.
これらの位置は、クロミナンスと輝度サンプルのパケット化の順序に影響を与えませんが、情報は表示前の補間に必要であるため、受信側に通知する必要があります。
RTCP SHOULD be used as specified in RFC 3550 [RTP]. It is to be noted that the sender's octet count in SR packets and the cumulative number of packets lost will wrap around quickly for high data rate streams. This means that these two fields may not accurately represent octet count and number of packets lost since the beginning of transmission, as defined in RFC 3550. Therefore, for network monitoring purposes, other means of keeping track of these variables SHOULD be used.
RTCPは、RFC 3550 [RTP]で指定されているとおりに使用する必要があります（SHOULD）。 SRパケットの送信者のオクテットカウントと失われたパケットの累積数は、高データレートストリームの場合、すぐに循環します。これは、RFC 3550で定義されているように、これらの2つのフィールドが送信の開始以降に失われたオクテット数とパケット数を正確に表していない可能性があることを意味します。
The IANA has registered one new MIME subtype along with an associated RTP Payload Format, and has created two sub-parameter registries, as described in the following.
IANAは、関連するRTPペイロード形式とともに1つの新しいMIMEサブタイプを登録し、次に説明するように、2つのサブパラメータレジストリを作成しました。
MIME media type name: video
MIMEメディアタイプ名：ビデオ
MIME subtype name: raw
MIMEサブタイプ名：raw
Required parameters:
必須パラメーター：
rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000.
rate：RTPタイムスタンプクロックレート。このペイロード形式を使用するアプリケーションは、90000の値を使用する必要があります（SHOULD）。
sampling: Determines the color (sub-)sampling mode of the video stream. Currently defined values are RGB, RGBA, BGR, BGRA, YCbCr-4:4:4, YCbCr-4:2:2, YCbCr-4:2:0, and YCbCr-4:1:1. New values may be registered as described in section 6.2 of RFC 4175.
サンプリング：ビデオストリームのカラー（サブ）サンプリングモードを決定します。現在定義されている値は、RGB、RGBA、BGR、BGRA、YCbCr-4：4：4、YCbCr-4：2：2、YCbCr-4：2：0、およびYCbCr-4：1：1です。 RFC 4175のセクション6.2で説明されているように、新しい値が登録される場合があります。
width: Determines the number of pixels per line. This is an integer between 1 and 32767.
幅：1行あたりのピクセル数を決定します。これは1〜32767の整数です。
height: Determines the number of lines per frame. This is an integer between 1 and 32767.
高さ：フレームあたりの行数を決定します。これは1〜32767の整数です。
depth: Determines the number of bits per sample. This is an integer with typical values including 8, 10, 12, and 16.
depth：サンプルあたりのビット数を決定します。これは、8、10、12、16などの典型的な値を持つ整数です。
colorimetry: This parameter defines the set of colorimetric specifications and other transfer characteristics for the video source, by reference to an external specification. Valid values and their specification are:
測色：このパラメーターは、外部仕様を参照して、ビデオソースの測色仕様とその他の転送特性のセットを定義します。有効な値とその仕様は次のとおりです。
BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240]
New values may be registered as described in section 6.2 of RFC 4175.
RFC 4175のセクション6.2で説明されているように、新しい値を登録できます。
Optional parameters:
オプションのパラメーター：
Interlace: If this OPTIONAL parameter is present, it indicates that the video stream is interlaced. If absent, progressive scan is implied.
インターレース：このOPTIONALパラメーターが存在する場合、ビデオストリームがインターレースされていることを示します。存在しない場合、プログレッシブスキャンが暗示されます。
Top-field-first: If this OPTIONAL parameter is present, it indicates that chrominance samples are packetized starting with the first line of field 0. Its absence implies that chrominance samples are packetized starting with the first line of field 1.
Top-field-first：このOPTIONALパラメーターが存在する場合、これは、クロミナンスサンプルがフィールド0の最初の行からパケット化されることを示します。これがない場合、クロミナンスサンプルはフィールド1の最初の行からパケット化されます。
chroma-position: This OPTIONAL parameter defines the position of chrominance samples relative to luminance samples. It is either a single integer or a comma separated pair of integers. Integer values range from 0 to 8, as specified in Figures 6-8 of RFC 4175. A single integer implies that Cb and Cr are co-sited. A comma separated pair of integers designates the locations of Cb and Cr samples, respectively. In its absence, a single value of zero is assumed for color-subsampled video (chroma-position=0).
chroma-position：このOPTIONALパラメータは、輝度サンプルに対するクロミナンスサンプルの位置を定義します。単一の整数またはカンマで区切られた整数のペアのいずれかです。 RFC 4175の図6-8で指定されているように、整数値の範囲は0〜8です。単一の整数は、CbとCrが同じ場所にあることを意味します。コンマで区切られた整数のペアは、CbおよびCrサンプルの場所をそれぞれ指定します。存在しない場合、カラーサブサンプリングされたビデオ（chroma-position = 0）に対してゼロの単一の値が想定されます。
gamma: An OPTIONAL floating point gamma correction value.
gamma：オプションの浮動小数点ガンマ補正値。
Encoding considerations:
エンコードに関する考慮事項：
Uncompressed video is only transmitted over RTP as specified in RFC 4175. No file format media type has been defined to go with this transmission media type at this time.
非圧縮ビデオは、RFC 4175で指定されているRTPを介してのみ送信されます。現時点では、この送信メディアタイプに対応するファイル形式メディアタイプは定義されていません。
Security considerations: See section 9 of RFC 4175.
セキュリティに関する考慮事項：RFC 4175のセクション9をご覧ください。
Interoperability considerations: NONE.
相互運用性に関する考慮事項：なし。
Published specification: RFC 4175.
公開された仕様：RFC 4175。
Applications which use this media type: Video communication.
このメディアタイプを使用するアプリケーション：ビデオ通信。
Additional information: None
追加情報：なし
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Ladan Gharai <ladan@isi.edu> IETF Audio/Video Transport working group.
Ladan Gharai <ladan@isi.edu> IETFオーディオ/ビデオトランスポートワーキンググループ。
Intended usage: COMMON
使用目的：COMMON
Author: Ladan Gharai <ladan@isi.edu>
Change controller: IETF AVT Working Group
delegated from the IESG
New values of the "sampling" parameter MAY be registered with the IANA provided they reference an RFC or other permanent and readily available specification (the Specification Required policy of RFC 2434 [2434]). A new registration MUST define the packing order of samples and a valid combinations of color and sub-sampling modes.
「サンプリング」パラメータの新しい値は、RFCまたは他の永続的ですぐに利用可能な仕様（RFC 2434 [2434]の仕様必須ポリシー）を参照する場合、IANAに登録できます（MAY）。新しい登録では、サンプルのパッキング順序と、カラーとサブサンプリングモードの有効な組み合わせを定義する必要があります。
New values of the "colorimetry" parameter MAY be registered with the IANA provided they reference an RFC or other permanent and readily available specification if colorimetric parameters and other applicable transfer characteristics (the Specification Required policy of RFC 2434 [2434]).
「測色」パラメーターの新しい値は、測色パラメーターおよびその他の適用可能な転送特性（RFC 2434 [2434]の仕様必須ポリシー）の場合にRFCまたはその他の永続的ですぐに利用可能な仕様を参照する場合、IANAに登録できます（MAY）。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [SDP], which is commonly used to describe RTP sessions. When SDP is used to specify sessions transporting uncompressed video, the mapping is as follows:
MIMEメディアタイプ仕様で伝達される情報には、Session Description Protocol（SDP）[SDP]のフィールドへの特定のマッピングがあり、RTPセッションの記述に一般的に使用されます。 SDPを使用して非圧縮ビデオを転送するセッションを指定する場合、マッピングは次のようになります。
- The MIME type ("video") goes in SDP "m=" as the media name.
- MIMEタイプ（「ビデオ」）は、メディア名としてSDP「m =」に入ります。
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
- MIMEサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"に入ります。
- Remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメータは、MIMEメディアタイプの文字列からセミコロンで区切られたparameter = valueペアのリストとして直接コピーすることにより、SDPの「a = fmtp」属性に入ります。
A sample SDP mapping for uncompressed video is as follows:
非圧縮ビデオのサンプルSDPマッピングは次のとおりです。
m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1
In this example, a dynamic payload type 112 is used for uncompressed video. The RTP sampling clock is 90 kHz. Note that the "a=fmtp:" line has been wrapped to fit this page, and will be a single long line in the SDP file.
この例では、動的ペイロードタイプ112が非圧縮ビデオに使用されます。 RTPサンプリングクロックは90 kHzです。 「a = fmtp：」行はこのページに合わせて折り返されており、SDPファイルでは単一の長い行になることに注意してください。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RTP] and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption.
この仕様で定義されているペイロード形式を使用するRTPパケットは、RTP仕様[RTP]および適切なRTPプロファイルで説明されているセキュリティの考慮事項に従います。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。
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.
このペイロードタイプは、パケット処理がサービス拒否の脅威を引き起こす可能性があるため、受信側の計算の複雑さに大きな不均一性はありません。
It is important to note that uncompressed video can have immense bandwidth requirements (up to 270 Mbps for standard-definition video, and approximately 1 Gbps for high-definition video). This is sufficient to cause potential for denial-of-service if transmitted onto most currently available Internet paths.
非圧縮ビデオの帯域幅要件は非常に大きくなる可能性があることに注意してください（標準解像度ビデオの場合は最大270 Mbps、高解像度ビデオの場合は約1 Gbps）。これは、現在利用可能なほとんどのインターネットパスに送信される場合、サービス拒否の可能性を引き起こすのに十分です。
Accordingly, if best-effort service is being used, users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and 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. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
したがって、ベストエフォートサービスが使用されている場合、このペイロード形式のユーザーは、パケット損失を監視して、パケット損失率が許容可能なパラメータ内であることを確認する必要があります。パケット損失は、同じネットワークパス上のTCPフローがあり、同じネットワーク条件が発生した場合、RTPフローが達成するよりも少なくない、平均スループットが妥当なタイムスケールで測定される場合に許容可能と見なされます。この条件は、輻輳制御メカニズムを実装して伝送速度（またはレイヤードマルチキャストセッションにサブスクライブするレイヤーの数）を適合させるか、または損失率が許容できないほど高い場合にレシーバーがセッションを離れるようにすることで満たすことができます。
This payload format may also be used in networks that provide quality-of-service guarantees. If enhanced service is being used, 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.
このペイロード形式は、サービス品質を保証するネットワークでも使用できます。拡張サービスが使用されている場合、レシーバーはパケット損失を監視して、要求されたサービスが実際に配信されていることを確認する必要があります（SHOULD）。そうでない場合、彼らはベストエフォートのサービスを受けていると想定し、それに応じて行動するべきです（SHOULD）。
In comparison with RFC 2431, this memo specifies support for a wider variety of uncompressed video, in terms of frame size, color sub-sampling and sample sizes. Although [BT656] can transport up to 4096 scan lines and 2048 pixels per line, our payload type can support up to 32768 scan lines and pixels per line. Also, RFC 2431 only address 4:2:2 YCbCr data, while this memo covers YCbCr, RGB, RGBA, BGR, BGRA, and most common color sub-sampling schemes. Given the variety of video types that we cover, this memo also assumes out-of-band signaling for sample size and data types (RFC 2431 uses in band signaling).
RFC 2431と比較して、このメモは、フレームサイズ、カラーサブサンプリング、およびサンプルサイズの観点から、さまざまな非圧縮ビデオのサポートを指定しています。 [BT656]は最大4096スキャンラインとラインあたり2048ピクセルを転送できますが、ペイロードタイプは最大32768スキャンラインとラインあたりのピクセルをサポートできます。また、RFC 2431は4：2：2 YCbCrデータのみを扱いますが、このメモはYCbCr、RGB、RGBA、BGR、BGRA、および最も一般的なカラーサブサンプリングスキームをカバーしています。カバーするさまざまなビデオタイプを考慮して、このメモはサンプルサイズとデータタイプのアウトオブバンドシグナリングも想定しています（RFC 2431はバンドシグナリングで使用しています）。
RFC 3497 [292RTP] specifies a RTP payload format for encapsulating SMPTE 292M video. The SMPTE 292M standard defines a bit-serial digital interface for local area High-Definition Television (HDTV) transport. As a transport medium, SMPTE 292M utilizes 10-bit words and a fixed 1.485 Gbps (and 1.485/1.001 Gbps) data rate. SMPTE 292M is typically used in the broadcast industry for the transport of other video formats such as SMPTE 260M, SMPTE 295M, SMPTE 274M, and SMPTE 296M.
RFC 3497 [292RTP]は、SMPTE 292Mビデオをカプセル化するためのRTPペイロード形式を指定しています。 SMPTE 292M標準は、ローカルエリアの高解像度テレビ（HDTV）トランスポート用のビットシリアルデジタルインターフェイスを定義します。 SMPTE 292Mは、トランスポートメディアとして、10ビットワードと固定の1.485 Gbps（および1.485 / 1.001 Gbps）のデータレートを利用します。 SMPTE 292Mは、SMPTE 260M、SMPTE 295M、SMPTE 274M、SMPTE 296Mなどの他のビデオ形式のトランスポートのために放送業界で通常使用されます。
RFC 3497 defines a circuit emulation for the transport of SMPTE 292M over RTP. It is very specific to SMPTE 292 and has been designed to be interoperable with existing broadcast equipment with a constant rate of 1.485 Gbps.
RFC 3497は、RTPを介したSMPTE 292Mの転送のための回線エミュレーションを定義しています。これはSMPTE 292に非常に固有であり、既存のブロードキャスト機器と相互運用できるように設計されており、一定のレートは1.485 Gbpsです。
This memo defines a flexible native packetization scheme that can packetize any uncompressed video, at varying data rates. In addition, unlike RFC 3497, this memo only transports active video pixels (i.e., horizontal and vertical blanking are not transported).
このメモは、さまざまなデータレートで非圧縮ビデオをパケット化できる柔軟なネイティブパケット化スキームを定義します。さらに、RFC 3497とは異なり、このメモはアクティブなビデオピクセルのみを転送します（つまり、水平および垂直のブランキングは転送されません）。
The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan Wenger, and Dave Singer for their feedback.
著者は、フィードバックを提供してくれたPhilippe Gentric、Chuck Harrison、Stephan Wenger、Dave Singerに感謝しています。
This memo is based upon work supported by the U.S. National Science Foundation (NSF) under Grant No. 0230738. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NSF.
このメモは、助成金番号0230738に基づいて米国国立科学財団（NSF）によってサポートされた作業に基づいています。この資料に記載されている意見、調査結果、結論または推奨事項は著者の意見であり、必ずしもNSFの見解を反映しているわけではありません。
Normative References
引用文献
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[601] International Telecommunication Union, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", Recommendation BT.601, October 1995.
[601]国際電気通信連合、「標準4：3およびワイドスクリーン16：9アスペクト比のデジタルテレビのスタジオエンコーディングパラメータ」、勧告BT.601、1995年10月。
[709] International Telecommunication Union, "Parameter Values for HDTV Standards for Production and International Programme Exchange", Recommendation BT.709-2
[709]国際電気通信連合、「制作および国際プログラム交換のためのHDTV規格のパラメーター値」、勧告BT.709-2
[240] Society of Motion Picture and Television Engineers, "Television - Signal Parameters - 1125-Line High-Definition Production", SMPTE 240M-1999.
[240] Society of Motion Picture and Television Engineers、「Television-Signal Parameters-1125-Line High-Definition Production」、SMPTE 240M-1999。
Informative References
参考引用
[274] Society of Motion Picture and Television Engineers, "1920x1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
[274] Society of Motion Picture and Television Engineers、「1920x1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picture Rate」、SMPTE 274M-1998。
[296] Society of Motion Picture and Television Engineers, "1280x720 Scanning, Analog and Digital Representation and Analog Interfaces", SMPTE 296M-1998.
[296] Society of Motion Picture and Television Engineers、「1280x720スキャン、アナログおよびデジタル表現とアナログインターフェイス」、SMPTE 296M-1998。
[372] Society of Motion Picture and Television Engineers, "Dual Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE 372M-2002.
[372] Society of Motion Picture and Television Engineers、「Dual Link 292M Interface for 1920 x 1080 Picture Raster」、SMPTE 372M-2002。
[ALF] 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.
[ALF] Clark、D. D.およびTennenhouse、D. L.、「新世代プロトコルのアーキテクチャに関する考慮事項」、Procedings in SIGCOMM '90（Philadelphia、PA、Sept. 1990）、ACM。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP] Handley、M。およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[BT656] Tynan, D., "RTP Payload Format for BT.656 Video Encoding", RFC 2431, October 1998.
[BT656] Tynan、D。、「RTP Payload Format for BT.656 Video Encoding」、RFC 2431、1998年10月。
[292RTP] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, March 2003.
[292RTP] Gharai、L.、Perkins、C.、Goncher、G。、およびA. Mankin、「Social for Motion Picture and Television Engineers（SMPTE）292M Video」のRTPペイロード形式、RFC 3497、2003年3月。
[656] International Telecommunication Union, "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)", Recommendation BT.656, April 1998.
[656]国際電気通信連合、「4：2：2レベルの勧告ITU-R BT.601（パートA）で動作する525ラインおよび625ラインのテレビシステムにおけるデジタルコンポーネントビデオ信号のインターフェース」、勧告BT。 656、1998年4月。
Authors' Addresses
著者のアドレス
Ladan Gharai USC Information Sciences Institute 3811 N. Fairfax Drive, #200 Arlington, VA 22203 USA
Ladan Gharai USC Information Sciences Institute 3811 N. Fairfax Drive、＃200 Arlington、VA 22203 USA
EMail: ladan@isi.edu
Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ United Kingdom
コリンパーキンスグラスゴー大学コンピューティングサイエンス学科17 Lilybank GardensグラスゴーG12 8QQイギリス
EMail: csp@csperkins.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。