Network Working Group A. Klemets
Request for Comments: 4425 Microsoft
Category: Standards Track February 2006
RTP Payload Format for Video Codec 1 (VC-1)
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television.
このメモは、映画テレビ技術者協会（SMPTE）規格、SMPTE 421Mによって定義されるように、ビデオコーデック1（VC-1）圧縮されたビットストリームをカプセル化するためのRTPペイロードフォーマットを指定します。 SMPTEは、モーションイメージング業界における主要標準化体であり、SMPTE 421M規格は、テレビ用圧縮ビデオビットストリームフォーマットおよび復号プロセスを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Definitions and Abbreviations ...................................3
3. Overview of VC-1 ................................................5
3.1. VC-1 Bit Stream Layering Model .............................6
3.2. Bit-stream Data Units in Advanced Profile ..................7
3.3. Decoder Initialization Parameters ..........................7
3.4. Ordering of Frames .........................................8
4. Encapsulation of VC-1 Format Bit Streams in RTP .................9
4.1. Access Units ...............................................9
4.2. Fragmentation of VC-1 frames ..............................10
4.3. Time Stamp Considerations .................................11
4.4. Random Access Points ......................................13
4.5. Removal of HRD Parameters .................................14
4.6. Repeating the Sequence Layer Header .......................14
4.7. Signaling of Media Type Parameters ........................15
4.8. The "mode=1" Media Type Parameter .........................16
4.9. The "mode=3" Media Type Parameter .........................16
5. RTP Payload Format Syntax ......................................17
5.1. RTP Header Usage ..........................................17
5.2. AU Header Syntax ..........................................18
5.3. AU Control Field Syntax ...................................19
6. RTP Payload Format Parameters ..................................20
6.1. Media type Registration ...................................20
6.2. Mapping of media type parameters to SDP ...................28
6.3. Usage with the SDP Offer/Answer Model .....................29
6.4. Usage in Declarative Session Descriptions .................31
7. Security Considerations ........................................32
8. Congestion Control .............................................33
9. IANA Considerations ............................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................35
This memo specifies an RTP payload format for the video coding standard Video Codec 1, also known as VC-1. The specification for the VC-1 bit stream format and decoding process is published by the Society of Motion Picture and Television Engineers (SMPTE) as SMPTE 421M [1].
また、このメモはVC-1として知られている標準的なビデオコーデック1を、映像符号化のためのRTPペイロードフォーマットを指定します。 VC-1ビットストリームフォーマットおよび復号処理がSMPTE 421Mとして映画テレビ技術者協会（SMPTE）によって公開されているの仕様[1]。
VC-1 has a broad applicability, as it is suitable for low bit rate Internet streaming applications to High Definition Television (HDTV) broadcast and Digital Cinema applications with nearly lossless coding. The overall performance of VC-1 is such that bit rate savings of more than 50% are reported [9] when compared with MPEG-2. See [9] for further details about how VC-1 compares with other codecs, such as MPEG-4 and H.264/AVC. (In [9], VC-1 is referred to by its earlier name, VC-9.)
それはほぼロスレスコーディングで高精細度テレビ（HDTV）放送とデジタルシネマアプリケーションに低ビットレートのインターネットストリーミングアプリケーションに適しているとして、VC-1は、幅広い適用性を有します。 VC-1の全体的な性能は、[9] MPEG-2と比較して50％以上のビットレートの節約が報告されているようなものです。 VC-1は、MPEG-4及びH.264 / AVCのような他のコーデックと比較する方法についての詳細については、[9]を参照してください。 （[9]において、VC-1は、その以前の名前、VC-9によって参照されます。）
VC-1 is widely used for downloading and streaming movies on the Internet, in the form of Windows Media Video 9 (WMV-9) [9], because the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also recently been adopted as a mandatory compression format for the high-definition DVD formats HD DVD and Blu-ray.
WMV-9コーデックはVC-1規格に準拠しているので、VC-1は広く、[9] Windows Mediaビデオ9（WMV-9）の形で、インターネット上の動画をダウンロードやストリーミングのために使用されています。 VC-1はまた、最近の高精細DVDフォーマットのHD DVDとブルーレイのための必須の圧縮フォーマットとして採用されています。
SMPTE 421M defines the VC-1 bit stream syntax and specifies constraints that must be met by VC-1 conformant bit streams. SMPTE 421M also specifies the complete process required to decode the bit stream. However, it does not specify the VC-1 compression algorithm, thus allowing for different ways of implementing a VC-1 encoder.
SMPTE 421Mは、VC-1ビットストリーム構文を定義し、VC-1準拠のビットストリームで満たされなければならない制約を指定します。 SMPTE 421Mは、ビットストリームをデコードするために必要な完全なプロセスを指定します。しかし、こうしてVC-1エンコーダを実装するさまざまな方法を可能にする、VC-1の圧縮アルゴリズムを指定していません。
The VC-1 bit stream syntax has three profiles. Each profile has specific bit stream syntax elements and algorithms associated with it. Depending on the application in which VC-1 is used, some profiles may be more suitable than others. For example, Simple profile is designed for low bit rate Internet streaming and for playback on devices that can only handle low-complexity decoding. Advanced profile is designed for broadcast applications, such as digital TV, HD DVD, or HDTV. Advanced profile is the only VC-1 profile that supports interlaced video frames and non-square pixels.
VC-1ビットストリーム構文は、3つのプロファイルを持っています。各プロファイルは、特定のビットストリーム構文要素及びそれに関連するアルゴリズムを有します。 VC-1が使用される用途に応じて、いくつかのプロファイルが他のものより適切であり得ます。例えば、単純なプロファイルは低ビットレートのインターネット・ストリーミングのためにのみ低複雑デコーディングを扱うことができるデバイスで再生するために設計されています。高度なプロファイルは、デジタルテレビ、HDのDVD、またはHDTVなどの放送アプリケーション向けに設計されています。高度プロファイルは、インターレースビデオフレームと非正方形ピクセルをサポートする唯一のVC-1プロファイルです。
Section 2 defines the abbreviations used in this document. Section 3 provides a more detailed overview of VC-1. Sections 4 and 5 define the RTP payload format for VC-1, and section 6 defines the media type and SDP parameters for VC-1. See section 7 for security considerations, and section 8 for congestion control requirements.
第2節では、このドキュメントで使用する略語を定義します。第3節では、VC-1のより詳細な概要を提供します。セクション4及び5は、VC-1のためのRTPペイロードフォーマットを定義し、セクション6は、メディアタイプとVC-1のためのSDPのパラメータを定義します。セキュリティ上の考慮事項についてはセクション7、および輻輳制御の要件については、セクション8を参照してください。
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]。
This document uses the definitions in SMPTE 421M [1]. For convenience, the following terms from SMPTE 421M are restated here:
この文書では、SMPTE 421M [1]で定義を使用しています。便宜上、SMPTE 421Mからの以下の用語はここでは修正再表示されます。
B-picture: A picture that is coded using motion compensated prediction from past and/or future reference fields or frames. A B-picture cannot be used for predicting any other picture.
Bピクチャ：過去および/または将来の参照フィールドまたはフレームから動き補償予測を用いて符号化される画像。 Bピクチャは他のピクチャを予測するために使用することができません。
BI-picture: A B-picture that is coded using information only from itself. A BI-picture cannot be used for predicting any other picture.
BIピクチャ：のみ自体からの情報を使用して符号化されるBピクチャ。 BIピクチャは他のピクチャを予測するために使用することができません。
Bit-stream data unit (BDU): A unit of the compressed data which may be parsed (i.e., syntax decoded) independently of other information at the same hierarchical level. A BDU can be, for example, a sequence layer header, an entry-point header, a frame, or a slice.
ビットストリーム・データ・ユニット（BDU）：同じ階層レベルで独立他の情報（すなわち、シンタックスを復号）構文解析することができる圧縮されたデータの単位。 BDUは、例えば、配列層ヘッダ、エントリーポイントヘッダ、フレーム、またはスライスすることができます。
Encapsulated BDU (EBDU): A BDU that has been encapsulated using the encapsulation mechanism described in Annex E of SMPTE 421M [1], to prevent emulation of the start code prefix in the bit stream.
カプセル化されたBDU（EBDU）：ビット・ストリーム内の開始コードプレフィックスのエミュレーションを防止するために、SMPTE 421M [1]の付属書Eに記載のカプセル化メカニズムを使用してカプセル化されたBDU。
Entry-point: A point in the bit stream that offers random access.
エントリポイント：ランダムアクセスを提供していますビットストリーム内のポイント。
frame: A frame contains lines of spatial information of a video signal. For progressive video, these lines contain samples starting from one time instant and continuing through successive lines to the bottom of the frame. For interlaced video, a frame consists of two fields, a top field and a bottom field. One of these fields will commence one field period later than the other.
フレーム：フレームは、ビデオ信号の空間情報の行を含みます。プログレッシブ・ビデオのために、これらのラインは、一の時点から開始し、フレームの底部に連続するラインを介して継続的サンプルを含みます。インターレース映像の場合、フレームは、二つのフィールド、トップフィールドとボトムフィールドから成ります。これらのフィールドのうちの1つは、1つのフィールド期間後に他より開始いたします。
interlace: The property of frames where alternating lines of the frame represent different instances in time. In an interlaced frame, one of the fields is meant to be displayed first.
インターレース：フレームの交互のラインが時間的に異なるインスタンスを表すフレームのプロパティ。インターレース・フレームにおいて、フィールドのいずれかが最初に表示されることを意味します。
I-picture: A picture coded using information only from itself.
Iピクチャ：のみ自体からの情報を使用して符号化ピクチャ。
level: A defined set of constraints on the values that may be taken by the parameters (such as bit rate and buffer size) within a particular profile. A profile may contain one or more levels.
レベル：特定のプロファイル内に（例えば、ビットレート、バッファサイズなど）のパラメータによって取り得る値に対する制約の定義されたセット。プロファイルは、1つ以上のレベルを含むことができます。
P-picture: A picture that is coded using motion compensated prediction from past reference fields or frames.
Pピクチャ：過去の参照フィールドまたはフレームから動き補償予測を用いて符号化される画像。
picture: For progressive video, a picture is identical to a frame, while for interlaced video, a picture may refer to a frame, or the top field or the bottom field of the frame depending on the context.
画像：プログレッシブ・ビデオについて、ピクチャは、ピクチャ、フレーム、又はトップフィールドまたは文脈に応じてフレームのボトムフィールドを指すことができる、インターレースビデオのためながら、フレームと同一です。
profile: A defined subset of the syntax of VC-1 with a specific set of coding tools, algorithms, and syntax associated with it. There are three VC-1 profiles: Simple, Main, and Advanced.
プロファイル：それに関連した特定の符号化ツールのセット、アルゴリズム、およびシンタックスとVC-1の構文の定義されたサブセット。シンプル、メイン、およびAdvanced：3 VC-1プロファイルがあります。
progressive: The property of frames where all the samples of the frame represent the same instance in time.
プログレッシブ：フレームの全てのサンプルが時間的に同一のインスタンスを表すフレームのプロパティ。
random access: A random access point in the bit stream is defined by the following guarantee: If decoding begins at this point, all frames needed for display after this point will have no decoding dependency on any data preceding this point, and they are also present in the decoding sequence after this point. A random access point is also called an entry-point.
ランダムアクセス：以下の保証によって定義されたビットストリーム内のランダムアクセスポイントは：デコードがこの時点で始まっている場合、この時点の後に表示するために必要なすべてのフレームは、この点を先行する任意のデータには、復号化依存関係を持っていないだろう、と彼らはまた、存在していますこの時点の後の復号化順序インチランダムアクセスポイントは、エントリ・ポイントと呼ばれています。
sequence: A coded representation of a series of one or more pictures. In VC-1 Advanced profile, a sequence consists of a series of one or more entry-point segments, where each entry-point segment consists of a series of one or more pictures, and where the first picture in each entry-point segment provides random access. In VC-1 Simple and Main profiles, the first picture in each sequence is an I-picture.
シーケンス：一つ以上の一連の画像の符号化表現。 VC-1アドバンスドプロファイルでは、配列は、各エントリ・ポイント・セグメントは、1つまたは複数の画像の系列から成る一つ以上のエントリー・ポイントの一連のセグメントで構成され、ここで、各エントリ・ポイント・セグメント内の最初の画像が提供しますランダムアクセス。 VC-1シンプル、メインプロファイルでは、各シーケンスの最初の画像はIピクチャです。
slice: A consecutive series of macroblock rows in a picture, which are encoded as a single unit.
スライス：単一ユニットとして符号化されるピクチャ内のマクロブロック行の連続した一連。
start codes (SC): Unique 32-bit codes that are embedded in the coded bit stream and identify the beginning of a BDU. Start codes consist of a unique three-byte Start Code Prefix (SCP), and a one-byte Start Code Suffix (SCS).
スタートコード（SC）：符号化ビットストリームに埋め込まれ、BDUの開始を識別されたユニークな32ビットの符号。開始コードはユニークな3バイトのスタートコードプリフィックス（SCP）、および1バイトのスタートコードサフィックス（SCS）で構成されています。
The VC-1 bit stream syntax consists of three profiles: Simple, Main, and Advanced. Simple profile is designed for low bit rates and for low complexity applications, such as playback of media on personal digital assistants. The maximum bit rate supported by Simple profile is 384 kbps. Main profile targets high bit rate applications, such as streaming and TV over IP. Main profile supports B-pictures, which provide improved compression efficiency at the cost of higher complexity.
シンプル、メイン、およびAdvanced：VC-1ビットストリーム構文は、3つのプロファイルで構成されています。シンプルプロファイルは、低ビットレートのためにと、このようなパーソナル・デジタル・アシスタントのメディアの再生などの複雑性の低いアプリケーション向けに設計されています。シンプルプロファイルによってサポートされる最大ビットレートは384 kbpsです。そのようなIP上のストリーミングやテレビなどのメインプロファイルターゲット高ビットレートのアプリケーション、。メインプロファイルは、より高い複雑さのコストで改善圧縮効率を提供し、Bピクチャを、サポートしています。
Certain features that can be used to achieve high compression efficiency, such as non-square pixels and support for interlaced pictures, are only included in Advanced profile. The maximum bit rate supported by the Advanced profile is 135 Mbps, making it suitable for nearly lossless encoding of HDTV signals.
このような非正方形ピクセルと、インターレース映像のサポートなど、高い圧縮効率を達成するために使用することができる特定の機能は、詳細プロファイルに含まれています。高度プロファイルによってサポートされる最大ビットレートは、HDTV信号のほぼロスレス符号化に適して、135 Mbpsです。
Only Advanced profile supports carrying user-data (meta-data) in-band with the compressed bit stream. The user-data can be used for closed captioning support, for example.
唯一の高度プロファイルは、圧縮されたビットストリームでインバンドユーザデータ（メタデータ）を運ぶサポートしています。ユーザデータは、例えば、クローズド・キャプション・サポートのために使用することができます。
Of the three profiles, only Advanced profile allows codec configuration parameters, such as the picture aspect ratio, to be changed through in-band signaling in the compressed bit stream.
3つのプロファイルの、詳細プロファイルは、画像のアスペクト比とコーデック設定パラメータは、圧縮されたビットストリームにおけるシグナリング帯域内で変更することが可能になります。
For each of the profiles, a certain number of "levels" have been defined. Unlike a "profile", which implies a certain set of features or syntax elements, a "level" is a set of constraints on the values of parameters in a profile, such as the bit rate or buffer size. VC-1 Simple profile has two levels, Main profile has three, and Advanced profile has five. See Annex D of SMPTE 421M [1] for a detailed list of the profiles and levels.
プロファイルのそれぞれについて、「レベル」の特定の数が定義されています。特徴または構文要素の特定の集合を意味し、「プロファイル」とは異なり、「レベル」は、ビットレートやバッファサイズのようなプロファイルのパラメータの値に対する制約の集合です。 VC-1シンプルプロファイルは、2つのレベルがあり、メインプロファイルは3を持っており、高度なプロファイルは5を持っています。プロファイルとレベルの詳細なリストについては、[1] SMPTE 421Mの付属書Dを参照。
The VC-1 bit stream is defined as a hierarchy of layers. This is conceptually similar to the notion of a protocol stack of networking protocols. The outermost layer is called the sequence layer. The other layers are entry-point, picture, slice, macroblock, and block.
VC-1ビットストリームは、層の階層として定義されます。これは、ネットワークプロトコルのプロトコルスタックの概念と概念的に類似しています。最も外側の層は、シーケンス層と呼ばれています。他の層は、エントリ・ポイント、ピクチャ、スライス、マクロブロック、およびブロックです。
In Simple and Main profiles, a sequence in the sequence layer consists of a series of one or more coded pictures. In Advanced profile, a sequence consists of one or more entry-point segments, where each entry-point segment consists of a series of one or more pictures, and where the first picture in each entry-point segment provides random access. A picture is decomposed into macroblocks. A slice comprises one or more contiguous rows of macroblocks.
シンプルでメインプロファイルでは、シーケンス層のシーケンスは、一つ以上のコード化された一連の写真で構成されています。高度プロファイルでは、配列は、各エントリ・ポイント・セグメントは、1つまたは複数の画像の系列から成る一つ以上のエントリー・ポイントのセグメントからなり、各エントリ・ポイント・セグメント内の最初の画像は、ランダムアクセスを提供する場合。画像はマクロブロックに分解されます。スライスは、マクロブロックの一つ以上の連続した行を含みます。
The entry-point and slice layers are only present in Advanced profile. In Advanced profile, the start of each entry-point layer segment indicates a random access point. In Simple and Main profiles, each I-picture is a random access point.
エントリ・ポイントとスライス層は、高度なプロファイルにのみ存在しています。高度プロファイルでは、各エントリ・ポイント・レイヤ・セグメントの開始は、ランダムアクセスポイントを示しています。シンプルでメインプロファイルでは、各Iピクチャがランダムアクセスポイントです。
Each picture can be coded as an I-picture, P-picture, skipped picture, BI-picture, or as a B-picture. These terms are defined in section 2 of this document and in section 4.12 of SMPTE 421M [1].
各ピクチャは、Iピクチャ、Pピクチャとして符号化することができ、BIピクチャ、またはBピクチャとしてピクチャをスキップ。これらの用語は、このドキュメントのセクション2およびSMPTE 421M [1]のセクション4.12に定義されています。
In Advanced profile, each picture and slice is considered a Bit-stream Data Unit (BDU). A BDU is always byte-aligned and is defined as a unit that can be parsed (i.e., syntax decoded) independently of other information in the same layer.
高度なプロファイルでは、各画像スライスは、ビットストリームデータユニット（BDU）と考えられています。 BDUは常にバイト位置合わせされ、構文解析することができるユニットとして定義される独立して、同一層内の他の情報（すなわち、シンタックスは、復号化）。
The beginning of a BDU is signaled by an identifier called Start Code (SC). Sequence layer headers and entry-point headers are also BDUs and thus can be easily identified by their Start Codes. See Annex E of SMPTE 421M [1] for a complete list of Start Codes. Blocks and macroblocks are not BDUs and thus do not have a Start Code and are not necessarily byte-aligned.
BDUの始まりは、スタートコード（SC）と呼ばれる識別子によって通知されます。シーケンス層ヘッダとエントリ・ポイント・ヘッダもBDUsあり、したがって簡単にスタートコードによって同定することができます。スタートコードの完全なリストについては、[1] SMPTE 421Mの附属書Eを参照してください。ブロックとマクロブロックはBDUsではありませんので、スタートコードを持っていないと、必ずしもバイト整列ではありません。
The Start Code consists of four bytes. The first three bytes are 0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix (SCS) and it is used to indicate the type of BDU that follows the Start Code. For example, the SCS of a sequence layer header (0x0F) is different from the SCS of an entry-point header (0x0E). The Start Code is always byte-aligned and is transmitted in network byte order.
スタートコードは4バイトで構成されています。最初の3つのバイトは0x00で、0x00から0x01のです。 4番目のバイトは、スタートコードサフィックス（SCS）と呼ばれ、スタートコードを次のBDUの種類を示すために使用されます。例えば、シーケンス層のヘッダのSCS（0x0Fの）エントリポイントヘッダのSCS（0x0Eの）とは異なります。スタートコードは常にバイト境界で整列し、ネットワークバイト順で送信されます。
To prevent accidental emulation of the Start Code in the coded bit stream, SMPTE 421M defines an encapsulation mechanism that uses byte stuffing. A BDU that has been encapsulated by this mechanism is referred to as an Encapsulated BDU, or EBDU.
符号化ビットストリームにスタートコードの偶然のエミュレーションを防ぐために、SMPTE 421Mバイトスタッフィングを使用してカプセル化メカニズムを定義します。このメカニズムによってカプセル化されたBDUは封入BDU、またはEBDUと呼ばれます。
In VC-1 Advanced profile, the sequence layer header contains parameters that are necessary to initialize the VC-1 decoder.
VC-1アドバンスドプロファイルでは、シーケンス層のヘッダは、VC-1デコーダを初期化するために必要なパラメータが含まれています。
The parameters apply to all entry-point segments until the next occurrence of a sequence layer header in the coded bit stream.
パラメータは、符号化ビットストリームのシーケンス層のヘッダの次の発生まで、すべてのエントリ・ポイント・セグメントに適用されます。
The parameters in the sequence layer header include the Advanced profile level, the maximum dimensions of the coded frames, the aspect ratio, interlace information, the frame rate and up to 31 leaky bucket parameter sets for the Hypothetical Reference Decoder (HRD).
シーケンス層のヘッダのパラメータは、高度プロファイルレベル、符号化フレームの最大寸法、アスペクト比、インターレース情報、フレームレート及び仮想基準デコーダ（HRD）のために最大31のリーキーバケットパラメータセットを含みます。
Section 6.1 of SMPTE 421M [1] provides the formal specification of the sequence layer header.
SMPTE 421Mのセクション6.1 [1]配列層ヘッダの形式仕様を提供します。
A sequence layer header is not defined for VC-1 Simple and Main profiles. For these profiles, decoder initialization parameters MUST be conveyed out-of-band. The decoder initialization parameters for Simple and Main profiles include the maximum dimensions of the coded frames and a leaky bucket parameter set for the HRD. Section 4.7 specifies how the parameters are conveyed by this RTP payload format.
シーケンス層のヘッダは、VC-1シンプルメインプロファイルに定義されていません。これらのプロファイルのために、デコーダの初期化パラメータは、帯域外に搬送されなければなりません。シンプルメインプロファイルの復号器の初期化パラメータは、符号化されたフレームの最大寸法およびHRDのためのリーキーバケットパラメータセットを含みます。 4.7節は、パラメータは、このRTPペイロードフォーマットによって搬送される方法を指定します。
Each leaky bucket parameter set for the HRD specifies a peak transmission bit rate and a decoder buffer capacity. The coded bit stream is restricted by these parameters. The HRD model does not mandate buffering by the decoder. Its purpose is to limit the encoder's bit rate fluctuations according to a basic buffering model so that the resources necessary to decode the bit stream are predictable. The HRD has a constant-delay mode and a variable-delay mode. The constant-delay mode is appropriate for broadcast and streaming applications, while the variable-delay mode is designed for video-conferencing applications.
HRDのために設定された各リーキーバケットパラメータは、ピーク伝送ビットレート及びデコーダバッファの容量を指定します。符号化ビットストリームは、これらのパラメータによって制限されています。 HRDモデルは、デコーダによってバッファリングを強制しません。その目的は、ビットストリームをデコードするために必要なリソースが予測可能であるように、基本的なバッファリングモデルに従ってエンコーダのビットレートの変動を制限することです。 HRDは、一定の遅延モードと可変遅延モードを備えています。可変遅延モードはビデオ会議アプリケーション用に設計されている間、一定遅延モードは、放送やストリーミングアプリケーションに適しています。
Annex C of SMPTE 421M [1] specifies the usage of the hypothetical reference decoder for VC-1 bit streams. A general description of the theory of the HRD can be found in [10].
SMPTE 421M [1]の附属書Cは、VC-1ビットストリームの仮想基準デコーダの使用を指定します。 HRDの理論の一般的な説明は、[10]に見出すことができます。
For Simple and Main profiles, the current buffer fullness value for the HRD leaky bucket is signaled using the BF syntax element in the picture header of I-pictures and BI-pictures.
シンプルメインプロファイルについて、HRDリーキーバケットの現在バッファ占有量の値は、IピクチャおよびBIピクチャのピクチャ・ヘッダ内のBF構文要素を使用してシグナリングされます。
For Advanced profile, the entry-point header specifies current buffer fullness values for the leaky buckets in the HRD. The entry-point header also specifies coding control parameters that are in effect until the occurrence of the next entry-point header in the bit stream. The concept of an entry-point layer applies only to VC-1 Advanced profile. See Section 6.2 of SMPTE 421M [1] for the formal specification of the entry-point header.
高度プロファイルの、エントリポイントヘッダは、HRDにリーキーバケットの現在バッファ占有量の値を指定します。エントリ・ポイント・ヘッダは、ビットストリーム内の次のエントリポイントヘッダが発生するまで有効である符号化制御パラメータを指定します。エントリ・ポイントの層の概念は、VC-1アドバンスドプロファイルに適用されます。エントリポイントヘッダの正式な仕様についてはSMPTE 421M [1]のセクション6.2を参照。
Frames are transmitted in the same order in which they are captured, except if B-pictures or BI-pictures are present in the coded bit stream. A BI-picture is a special kind of B-picture, and in the remainder of this section the terms B-picture and B-frame also apply to BI-pictures and BI-frames, respectively.
フレームは、BピクチャまたはBIピクチャは、符号化ビットストリーム中に存在する場合を除いて、それらが捕捉されるのと同じ順序で送信されます。 BIピクチャは、Bピクチャ、およびこのセクションの残りの部分における用語Bピクチャ及びBフレームの特別な種類は、それぞれ、BIピクチャおよびBIフレームに適用されています。
When B-pictures are present in the coded bit stream, the frames are transmitted such that the frames that the B-pictures depend on are transmitted first. This is referred to as the coded order of the frames.
Bピクチャは、符号化ビットストリーム中に存在する場合、フレームがBピクチャが依存するフレームが最初に送信されるように送信されます。これは、フレームの符号化順と呼ばれます。
The rules for how a decoder converts frames from the coded order to the display order are stated in section 5.4 of SMPTE 421M [1]. In short, if B-pictures may be present in the coded bit stream, a hypothetical decoder implementation needs to buffer one additional decoded frame. When an I-frame or a P-frame is received, the frame can be decoded immediately but it is not displayed until the next I-or P-frame is received. However, B-frames are displayed immediately.
デコーダは、表示順に符号化順序からのフレームを変換する方法のためのルールは、SMPTE 421M [1]のセクション5.4に記載されています。 Bピクチャは、符号化ビットストリーム中に存在し得る場合要するに、仮想的なデコーダ実装は一つの追加のデコードされたフレームをバッファリングする必要があります。 IフレームまたはPフレームを受信した場合、フレームは直ちに復号化することができるが、それは、次のI又はPフレームが受信されるまで表示されません。しかし、Bフレームがすぐに表示されます。
Figure 1 illustrates the timing relationship between the capture of frames, their coded order, and the display order of the decoded frames, when B-pictures are present in the coded bit stream. The figure shows that the display of frame P4 is delayed until frame P7 is received, while frames B2 and B3 are displayed immediately.
図1は、Bピクチャは、符号化ビットストリームに存在するフレームのキャプチャ、その符号化順序、及び復号されたフレームの表示順、の間のタイミング関係を示す図です。図は、フレームP7が受信されるまで、フレームB2及びB3が直ちに表示されている間、フレームP4の表示は、遅延されることを示しています。
Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ...
|
Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ...
|
Display order: | I0 P1 B2 B3 P4 B5 B6 ...
|
|+---+---+---+---+---+---+---+---+---+--> time
0 1 2 3 4 5 6 7 8 9
Figure 1. Frame reordering when B-pictures are present
Bピクチャが存在している、図1のフレームの並べ替え
If B-pictures are not present, the coded order and the display order are identical, and frames can then be displayed without the additional delay shown in Figure 1.
Bピクチャが存在しない場合は、符号化順と表示順が同一であり、フレームは、図1に示されている追加の遅延なしに表示することができます。
Each RTP packet contains an integral number of application data units (ADUs). For VC-1 format bit streams, an ADU is equivalent to one Access Unit (AU). An Access Unit is defined as the AU header (defined in section 5.2) followed by a variable length payload, with the rules and constraints described in sections 4.1 and 4.2. Figure 2 shows the layout of an RTP packet with multiple AUs.
各RTPパケットは、アプリケーション・データ・ユニット（のADU）の整数を含んでいます。 VC-1フォーマットのビットストリームに対して、ADUは、一つのアクセスユニット（AU）と等価です。アクセスユニットは、セクション4.1および4.2に記載の規則および制約を、可変長ペイロードが続く（セクション5.2で定義された）AUのヘッダとして定義されます。図2は、複数のAUのRTPパケットのレイアウトを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| RTP | AU(1) | AU(2) | | AU(n) |
| Header | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 2. RTP packet structure
図2. RTPパケットの構造
Each Access Unit MUST start with the AU header defined in section 5.2. The AU payload MUST contain data belonging to exactly one VC-1 frame. This means that data from different VC-1 frames will always be in different AUs. However, it possible for a single VC-1 frame to be fragmented across multiple AUs (see section 4.2).
各アクセスユニットは、セクション5.2で定義されたAUのヘッダで始まる必要があります。 AUペイロードは、1つのVC-1フレームに属するデータを含まなければなりません。これは、異なるVC-1フレームからのデータは常に異なったAUになることを意味します。しかし、単一のVC-1フレームの可能が複数のAUを横切って断片化される（セクション4.2参照）。
In the case of interlaced video, a VC-1 frame consists of two fields that may be coded as separate pictures. The two pictures still belong to the same VC-1 frame.
インターレース映像の場合には、VC-1フレームは、別々のピクチャとして符号化することができる2つのフィールドで構成されています。二つの絵はまだ同じVC-1フレームに属しています。
The following rules apply to the contents of each AU payload when VC-1 Advanced profile is used:
VC-1アドバンスドプロファイルが使用されている場合には、次の規則が各AUペイロードの内容に適用されます。
- The AU payload MUST contain VC-1 bit stream data in EBDU format (i.e., the bit stream must use the byte-stuffing encapsulation mode defined in Annex E of SMPTE 421M [1].)
- AUペイロードはEBDU形式のVC-1ビットストリームデータを含まなければならない（すなわち、SMPTE 421M [1]の付録Eで定義されたバイトスタッフィングのカプセル化モードを使用しなければならないビットストリーム）。
- The AU payload MAY contain multiple EBDUs, e.g., a sequence layer header, an entry-point header, a frame (picture) header, a field header, and multiple slices and the associated user-data. However, all slices and their corresponding macroblocks MUST belong to the same video frame.
- AUペイロードは、例えば、配列層ヘッダ、エントリーポイントヘッダ、フレーム（ピクチャ）ヘッダ、フィールドヘッダ、および複数のスライスと関連付けられたユーザーデータを複数EBDUsを含むかもしれません。しかし、すべてのスライスとそれに対応するマクロブロックは、同じビデオフレームに属している必要があります。
- The AU payload MUST start at an EBDU boundary, except when the AU payload contains a fragmented frame, in which case the rules in section 4.2 apply.
- AUペイロードはAUペイロードセクション4.2のルールが適用される場合には、断片化フレームが、含まれている場合を除き、EBDU境界で開始しなければなりません。
When VC-1 Simple or Main profiles are used, the AU payload MUST start at the beginning of a frame, except when the AU payload contains a fragmented frame. Section 4.2 describes how to handle fragmented frames.
VC-1シンプルまたはメインプロファイルが使用されている場合は、AUペイロードはAUペイロードが断片化されたフレームが含まれている場合を除いて、フレームの先頭から開始しなければなりません。 4.2節は、断片化されたフレームを処理する方法について説明します。
Access Units MUST be byte-aligned. If the data in an AU (EBDUs in the case of Advanced profile and frame in the case of Simple and Main) does not end at an octet boundary, up to 7 zero-valued padding bits MUST be added to achieve octet-alignment.
アクセス単位はバイト整列させる必要があります。 AU（シンプルメインの場合に高度プロファイルとフレームの場合EBDUs）のデータがオクテットの境界で終了しない場合は、7までのゼロ値パディングビットは、オクテット整列を達成するために加えなければなりません。
Each AU payload SHOULD contain a complete VC-1 frame. However, if this would cause the RTP packet to exceed the MTU size, the frame SHOULD be fragmented into multiple AUs to avoid IP-level fragmentation. When an AU contains a fragmented frame, this MUST be indicated by setting the FRAG field in the AU header as defined in section 5.3.
各AUペイロードは、完全なVC-1フレームを含むべきです。これは、RTPパケットがMTUサイズを超えてしまう場合は、フレームは、IPレベルでの断片化を避けるために、複数のAUに断片化されるべきである（SHOULD）。 AUは、断片化されたフレームが含まれている場合、これはセクション5.3で定義されているAUのヘッダにおけるフラグ・フィールドを設定することによって示されなければなりません。
AU payloads that do not contain a fragmented frame or that contain the first fragment of a frame MUST start at an EBDU boundary if Advanced profile is used. In this case, for Simple and Main profiles, the AU payload MUST start at the beginning of a frame.
高度なプロファイルが使用されている場合は断片化されたフレームが含まれているか、そのフレームの最初のフラグメントが含まれていないAUペイロードはEBDU境界で開始しなければなりません。この場合は、シンプルでメインプロファイルのために、AUペイロードは、フレームの先頭から開始しなければなりません。
If Advanced profile is used, AU payloads that contain a fragment of a frame other than the first fragment SHOULD start at an EBDU boundary, such as at the start of a slice.
高度プロファイルが使用される場合、最初のフラグメント以外のフレームのフラグメントを含むAUペイロードは、スライスの開始時のように、EBDU境界で開始する必要があります。
However, slices are only defined for Advanced profile, and are not always used. Blocks and macroblocks are not BDUs (have no Start Code) and are not byte-aligned. Therefore, it may not always be possible to continue a fragmented frame at an EBDU boundary. One can determine if an AU payload starts at an EBDU boundary by inspecting the first three bytes of the AU payload. The AU payload starts at an EBDU boundary if the first three bytes are identical to the Start Code Prefix (i.e., 0x00, 0x00, 0x01).
しかし、スライスは詳細プロファイルのために定義されており、常に使用されていません。ブロックとマクロブロックは（何のスタートコードを持っていない）BDUsではなく、バイト整列ではありません。したがって、常にEBDU境界で断片化されたフレームを継続することが可能ではないかもしれません。 AUペイロードがAUペイロードの最初の3つのバイトを検査することによってEBDU境界で始まる場合は、1つは決定することができます。最初の3つのバイトは、スタートコードプリフィックス（すなわち、0x00で、0x00に、0×01）と同一である場合AUペイロードはEBDU境界から始まります。
In the case of Simple and Main profiles, since the blocks and macroblocks are not byte-aligned, the fragmentation boundary may be chosen arbitrarily.
ブロックおよびマクロブロックがバイト整列されていないので、シンプルでメインプロファイルの場合には、フラグメンテーション境界が任意に選択することができます。
If an RTP packet contains an AU with the last fragment of a frame, additional AUs SHOULD NOT be included in the RTP packet.
RTPパケットは、フレームの最後の断片とAUが含まれている場合は、追加のAUは、RTPパケットに含まれるべきではありません。
If the PTS Delta field in the AU header is present, each fragment of a frame MUST have the same presentation time. If the DTS Delta field in the AU header is present, each fragment of a frame MUST have the same decode time.
AUのヘッダにPTSデルタフィールドが存在する場合、フレームの各フラグメントは、同じプレゼンテーションの時間を持たなければなりません。 AUヘッダーのDTSデルタフィールドが存在する場合、フレームの各フラグメントは、同じ復号時間を持たなければなりません。
VC-1 video frames MUST be transmitted in the coded order. A coded order implies that no frames are dependent on subsequent frames, as discussed in section 3.4. When a video frame consists of a single picture, the presentation time of the frame is identical to the presentation time of the picture. When the VC-1 interlace coding mode is used, frames may contain two pictures, one for each field. In that case, the presentation time of a frame is the presentation time of the field that is displayed first.
VC-1ビデオフレームは、符号化順で送信されなければなりません。符号化順序は、セクション3.4で議論するようになしフレームは、後続のフレームに依存しないことを意味します。ビデオフレームは、1枚の画像で構成されている場合、フレームのプレゼンテーション時間は、画像のプレゼンテーション時間と同じです。 VC-1インタレース符号化モードを使用した場合、フレームは、二つのピクチャ、フィールドごとに1つを含んでいてもよいです。その場合、フレームの提示時刻が最初に表示されるフィールドのプレゼンテーション時間です。
The RTP timestamp field MUST be set to the presentation time of the video frame contained in the first AU in the RTP packet. The presentation time can be used as the timestamp field in the RTP header because it differs from the sampling instant of the frame only by an arbitrary constant offset.
RTPタイムスタンプフィールドは、RTPパケットの最初のAUに含まれるビデオフレームのプレゼンテーション時間に設定しなければなりません。それだけオフセット任意の定数によってフレームのサンプリング時点と異なるので、プレゼンテーション時間は、RTPヘッダ内のタイムスタンプ・フィールドとして使用することができます。
If the video frame in an AU has a presentation time that differs from the RTP timestamp field, then the presentation time MUST be specified using the PTS Delta field in the AU header. Since the RTP timestamp field must be identical to the presentation time of the first video frame, this can only happen if an RTP packet contains multiple AUs. The syntax of the PTS Delta field is defined in section 5.2.
AU内のビデオフレームは、RTPタイムスタンプフィールドとは異なるプレゼンテーション時間を有する場合、プレゼンテーション時間は、AUのヘッダにPTSデルタフィールドを使用して指定されなければなりません。 RTPタイムスタンプフィールドは、最初のビデオフレームのプレゼンテーション時間と同一でなければならないので、RTPパケットは、複数のAUが含まれている場合、これはのみ発生します。 PTSデルタフィールドの構文はセクション5.2で定義されています。
The decode time of a VC-1 frame is always monotonically increasing when the video frames are transmitted in the coded order. If neither B- nor BI-pictures are present in the coded bit stream, then the decode time of a frame SHALL be equal to the presentation time of the frame. A BI-picture is a special kind of B-picture, and in the remainder of this section the terms B-picture and B-frame also apply to BI-pictures and BI-frames, respectively.
ビデオフレームは、符号化順で送信される場合VC-1フレームのデコード時間は常に単調に増加しています。どちらB-もBIピクチャは、符号化ビットストリーム中に存在する場合、フレームの復号時間は、フレームのプレゼンテーション時間に等しくなければなりません。 BIピクチャは、Bピクチャ、およびこのセクションの残りの部分における用語Bピクチャ及びBフレームの特別な種類は、それぞれ、BIピクチャおよびBIフレームに適用されています。
If B-pictures may be present in the coded bit stream, then the decode times of frames are determined as follows:
Bピクチャは、符号化ビットストリーム中に存在することができる場合は、次のようにフレームのデコード時間が決定されます。
- B-frames: The decode time SHALL be equal to the presentation time of the B-frame.
- Bフレーム：デコード時間は、Bフレームのプレゼンテーション時間に等しくなければなりません。
- First non-B frame in the coded order: The decode time SHALL be at least one frame period less than the decode time of the next frame in the coded order. A frame period is defined as the inverse of the frame rate used in the coded bit stream (e.g., 100 milliseconds if the frame rate is 10 frames per seconds.) For bit streams with a variable frame rate, the maximum frame rate SHALL determine the frame period. If the maximum frame is not specified, the maximum frame rate allowed by the profile and level SHALL be used.
- 符号化された順序で最初の非Bフレーム：デコード時間は、符号化順で次のフレームの復号時間未満の少なくとも一つのフレーム期間でなければなりません。フレーム期間は、符号化ビットストリームで使用されるフレームレートの逆数として定義される（例えば、フレームレートが毎秒10のフレームである場合、100ミリ秒）のビットストリームのための可変フレームレートと、最大フレームレートを決定しなければなりませんフレーム期間。最大フレームが指定されていない場合、プロファイルとレベルにより許容される最大フレームレートを使用しなければなりません。
- Non-B frames (other than the first frame in the coded order): The decode time SHALL be equal to the presentation time of the previous non-B frame in the coded order.
- （符号化順序の最初のフレーム以外の）非Bフレーム：デコード時間は、符号化順で前の非Bフレームのプレゼンテーション時間に等しくなければなりません。
As an example, consider Figure 1 in section 3.4. To determine the decode time of the first frame, I0, one must first determine the decode time of the next frame, P1. Because P1 is a non-B frame, its decode time is equal to the presentation time of I0, which is 3 time units. Thus, the decode time of I0 must be at least one frame period less than 3. In this example, the frame period is 1, because one frame is displayed every time unit. Consequently, the decode time of I0 is chosen as 2 time units. The decode time of the third frame in the coded order, P4, is 4, because it must be equal to the presentation time of the previous non-B frame in the coded order, P1. On the other hand, the decode time of B-frame B2 is 5 time units, which is identical to its presentation time.
一例として、セクション3.4で図1を検討します。最初のフレームI0の復号時間を決定するためには、まず、次のフレーム、P1の復号時間を決定しなければなりません。 P1は、非Bフレームであるので、その復号時間は3時間単位であるI0のプレゼンテーション時間に等しいです。 I0の復号時間は、この例では3未満の少なくとも1つのフレーム期間でなければならない1つのフレーム毎時間単位表示されるので、このように、フレーム期間は、1です。従って、I0の復号時間は2時間単位として選択されます。それは符号化順序、P1に以前非Bフレームのプレゼンテーション時間に等しくなければならないので、符号化順序、P4、第三フレームのデコード時間は、4です。一方、BフレームB2の復号時間は、そのプレゼンテーション時間と同一で5時間単位です。
If the decode time of a video frame differs from its presentation time, then the decode time MUST be specified using the DTS Delta field in the AU header. The syntax of the DTS Delta field is defined in section 5.2.
ビデオフレームのデコード時間はそのプレゼンテーション時間と異なる場合は、その後、デコード時間は、AUヘッダにDTSデルタフィールドを使用して指定されなければなりません。 DTSデルタフィールドの構文はセクション5.2で定義されています。
Receivers are not required to use the DTS Delta field. However, possible uses include buffer management and pacing of frames prior to decoding. If RTP packets are lost, it is possible to use the DTS Delta field to determine if the sequence of lost RTP packets contained reference frames or only B-frames. This can be done by comparing the decode and presentation times of the first frame received after the lost sequence against the presentation time of the last reference frame received prior to the lost sequence.
レシーバは、DTSデルタフィールドを使用する必要はありません。しかしながら、可能な用途は、バッファ管理および復号の前フレームのペーシングを含みます。 RTPパケットが失われた場合、失われたRTPパケットのシーケンスは、参照フレームのみBフレームを含んでいたかどうかを決定するためにDTSデルタフィールドを使用することが可能です。これは、前に失われた配列に最初最後の参照フレームのプレゼンテーション時間に対する失われたシーケンスの後に受信されたフレーム受信のデコードおよび提示時間を比較することによって行うことができます。
Knowing if the stream will contain B-pictures may help the receiver allocate resources more efficiently and can reduce delay, as an absence of B-pictures in the stream implies that no reordering of frames will be needed between the decoding process and the display of the decoded frames. This may be important for interactive applications.
ストリームにBピクチャが存在しない場合は、フレームのない並べ替えは、復号処理と表示との間で必要とされないことを意味するようにストリームは、Bピクチャは、受信機がより効率的にリソースを割り当てることに役立つことができ、遅延を低減することができるが含まれますかどうかを知ります復号化されたフレーム。これは、インタラクティブなアプリケーションのために重要であるかもしれません。
The receiver SHALL assume that the coded bit stream may contain B-pictures in the following cases:
受信機は、符号化ビットストリームは、次の場合にBピクチャが含まれていてもよいことを想定しなければなりません。
- Advanced profile: If the value of the "bpic" media type parameter defined in section 6.1 is 1, or if the "bpic" parameter is not specified.
- 高度なプロフィール：セクション6.1で定義された「BPIC」メディアタイプパラメータの値が1である場合、または「BPIC」パラメータが指定されていない場合。
- Main profile: If the MAXBFRAMES field in STRUCT_C decoder initialization parameter has a non-zero value. STRUCT_C is conveyed in the "config" media type parameter, which is defined in section 6.1.
- メインプロファイル：STRUCT_Cデコーダ初期化パラメータでMAXBFRAMESフィールドが非ゼロ値を持つ場合。 STRUCT_Cはセクション6.1で定義されている「設定」メディアタイプパラメータに搬送されます。
Simple profile does not use B-pictures.
シンプルプロファイルは、Bピクチャを使用していません。
The entry-point header contains information that is needed by the decoder to decode the frames in that entry-point segment. This means that in the event of lost RTP packets, the decoder may be unable to decode frames until the next entry-point header is received.
エントリ・ポイント・ヘッダはそのエントリ・ポイント・セグメント内のフレームをデコードするためにデコーダによって必要とされる情報を含みます。これは、失われたRTPパケットの場合に、デコーダは、次のエントリ・ポイント・ヘッダが受信されるまでフレームを復号することができないことを意味します。
The first frame after an entry-point header is a random access point into the coded bit stream. Simple and Main profiles do not have entry-point headers, so for those profiles, each I-picture is a random access point.
エントリ・ポイント・ヘッダの後の最初のフレームは、符号化ビットストリームへのランダムアクセスポイントです。これらのプロファイルのために、各Iピクチャがランダムアクセスポイントであるように、シンプルでメインプロファイルは、エントリ・ポイント・ヘッダを持っていません。
To allow the RTP receiver to detect that an RTP packet that was lost contained a random access point, this RTP payload format defines a field called "RA Count". This field is present in every AU, and its value is incremented (modulo 256) for every random access point. For additional details, see the definition of "RA Count" in section 5.2.
RTP受信機が失われたRTPパケットがランダムアクセスポイントを含んでいたことを検出できるようにするために、このRTPペイロードフォーマットは、「RAカウント」と呼ばれるフィールドを定義します。このフィールドは、すべてのAU中に存在し、その値は、すべてのランダムアクセスポイントのために（モジュロ256）をインクリメントします。その他の詳細については、5.2節の「RAカウント」の定義を参照してください。
To make it easy to determine if an AU contains a random access point, this RTP payload format also defines a bit called the "RA" flag in the AU Control field. This bit is set to 1 only on those AU's that contain a random access point. The RA bit is defined in section 5.3.
AUがランダムアクセスポイントが含まれているかどうかを判断することが簡単にするために、このRTPペイロードフォーマットは、AU制御フィールドに「RA」フラグと呼ばれるビットを定義します。このビットは、唯一のランダムアクセスポイントを含むこれらのAU年代に1に設定されています。 RAビットは、セクション5.3で定義されています。
The sequence layer header of Advanced profile may include up to 31 leaky bucket parameter sets for the Hypothetical Reference Decoder (HRD). Each leaky bucket parameter set specifies a possible peak transmission bit rate (HRD_RATE) and a decoder buffer capacity (HRD_BUFFER). See section 3.3 for additional discussion about the HRD.
高度プロファイルのシーケンス層のヘッダは、仮想基準デコーダ（HRD）のために最大31のリーキーバケットパラメータセットを含んでもよいです。各リーキーバケットパラメータセットは、可能な最大伝送ビットレート（HRD_RATE）及びデコーダバッファ容量（HRD_BUFFER）を指定します。 HRDに関する追加的な議論のためのセクション3.3を参照してください。
If the actual peak transmission rate is known by the RTP sender, the RTP sender MAY remove all leaky bucket parameter sets except for the one corresponding to the actual peak transmission rate.
実際のピーク伝送速度は、RTP送信者によって知られている場合は、RTPの送信者は、実際のピーク伝送速度に対応するものを除くすべてのリーキーバケットパラメータセットを削除することができます。
For each leaky bucket parameter set in the sequence layer header, there is also a parameter in the entry-point header that specifies the initial fullness (HRD_FULL) of the leaky bucket.
シーケンス層のヘッダに設定された各リーキーバケットパラメータに、リーキーバケットの初期フルネス（HRD_FULL）を指定するエントリーポイントヘッダ内のパラメータもあります。
If the RTP sender has removed any leaky bucket parameter sets from the sequence layer header, then for any removed leaky bucket parameter set, it MUST also remove the corresponding HRD_FULL parameter in the entry-point header.
RTP送信機は、シーケンス層のヘッダから任意のリーキーバケットパラメータセットを削除した場合、任意の除去リーキーバケットパラメータセットのために、それはまた、エントリポイントヘッダに対応HRD_FULLパラメータを削除する必要があります。
Removing leaky bucket parameter sets, as described above, may significantly reduce the size of the sequence layer headers and the entry-point headers.
リーキーバケットパラメータセットを除去し、上記のように、大幅に配列層ヘッダとエントリ・ポイント・ヘッダのサイズを小さくすることができます。
To improve robustness against loss of RTP packets, it is RECOMMENDED that if the sequence layer header changes, it should be repeated frequently in the bit stream. In this case, it is RECOMMENDED that the number of leaky bucket parameters in the sequence layer header and the entry-point headers be reduced to one, as described in section 4.5. This will help reduce the overhead caused by repeating the sequence layer header.
RTPパケットの損失に対するロバスト性を向上させるためには、シーケンス層のヘッダが変更された場合、それはビットストリームに頻繁に繰り返されることが推奨されます。この場合には、セクション4.5で説明したように、シーケンス層のヘッダとエントリ・ポイント・ヘッダにおけるリーキーバケットパラメータの数が1に減少することが推奨されます。これは、シーケンス層のヘッダを繰り返すことによって生じるオーバーヘッドを減らすのに役立ちます。
Any data in the VC-1 bit stream, including repeated copies of the sequence header itself, must be accounted for when computing the leaky bucket parameter for the HRD. See section 3.3 for a discussion about the HRD.
シーケンスヘッダ自体の繰り返しコピーを含むVC-1ビットストリーム内の任意のデータは、HRDのためのリーキーバケットパラメータを計算するときに考慮しなければなりません。 HRDについての議論のためのセクション3.3を参照してください。
If the value of TFCNTRFLAG in the sequence layer header is 1, each picture header contains a frame counter field (TFCNTR). Each time the sequence layer header is inserted in the bit stream, the value of this counter MUST be reset.
シーケンス層ヘッダ内TFCNTRFLAGの値が1である場合、各ピクチャヘッダは、フレームカウンタフィールド（TFCNTR）を含みます。シーケンス層のヘッダは、ビットストリームに挿入されるたびに、このカウンタの値をリセットする必要があります。
To allow the RTP receiver to detect that an RTP packet that was lost contained a new sequence layer header, the AU Control field defines a bit called the "SL" flag. This bit is toggled when a sequence layer header is transmitted, but only if that header is different from the most recently transmitted sequence layer header. The SL bit is defined in section 5.3.
RTP受信機が失われたRTPパケットが新しいシーケンス層ヘッダを含んでいることを検出できるようにするために、AU制御フィールドは「SL」フラグと呼ばれるビットを定義します。このビットは、シーケンス層のヘッダが送信されるときにトグルが、そのヘッダは、最も最近送信されたシーケンス層のヘッダと異なっている場合にのみれます。 SLビットはセクション5.3で定義されています。
When this RTP payload format is used with SDP, the decoder initialization parameters described in section 3.3 MUST be signaled in SDP using the media type parameters specified in section 6.1. Section 6.2 specifies how to map the media type parameters to SDP [5], section 6.3 defines rules specific to the SDP Offer/Answer model, and section 6.4 defines rules for when SDP is used in a declarative style.
このRTPペイロードフォーマットをSDPと共に使用される場合、セクション3.3で説明したデコーダの初期化パラメータは、セクション6.1で指定されたメディアタイプパラメータを使用して、SDPでシグナリングされなければなりません。セクション6.2 [5]は、セクション6.3 SDPオファー/アンサーモデルに固有のルールを定義し、セクション6.4は、SDPを宣言スタイルで使用する場合のルールを定義するSDPのメディアタイプパラメータをマッピングする方法を指定します。
When Simple or Main profiles are used, it is not possible to change the decoder initialization parameters through the coded bit stream. Any changes to the decoder initialization parameters would have to be done through out-of-band means, e.g., by a SIP [14] re-invite or similar means that convey an updated session description.
単純またはメインプロファイルが使用される場合、符号化ビットストリームを介してデコーダの初期化パラメータを変更することはできません。デコーダの初期化パラメータの変更は、SIPにより、例えばアウトオブバンド手段を介して行われなければならない[14]再招待または更新されたセッション記述を搬送する同様の手段。
When Advanced profile is used, the decoder initialization parameters MAY be changed by inserting a new sequence layer header or an entry-point header in the coded bit stream.
高度プロファイルが使用される場合、デコーダの初期化パラメータは、新しいシーケンス層ヘッダ又は符号化ビットストリームにおけるエントリポイントヘッダを挿入することによって変更することができます。
The sequence layer header specifies the VC-1 level, the maximum size of the coded frames and optionally also the maximum frame rate. The media type parameters "level", "width", "height", and "framerate" specify upper limits for these parameters. Thus, the sequence layer header MAY specify values that are lower than the values of the media type parameters "level", "width", "height", or "framerate", but the sequence layer header MUST NOT exceed the values of any of these media type parameters.
シーケンス層のヘッダは、VC-1レベル、符号化フレームの最大サイズおよび任意に最大フレームレートを指定します。メディアタイプパラメータ「レベル」、「幅」、「高さ」、および「フレームレート」は、これらのパラメータの上限値を指定します。これにより、シーケンス層のヘッダは、メディアタイプパラメータ「レベル」、「幅」、「高さ」、又は「フレームレート」の値よりも低い値を指定MAYが、シーケンス層のヘッダは、任意の値を超えてはなりませんこれらのメディアタイプパラメータ。
In certain applications using Advanced profile, the sequence layer header never changes. This MAY be signaled with the media type parameter "mode=1". (The "mode" parameter is defined in section 6.1.) The "mode=1" parameter serves as a "hint" to the RTP receiver that all sequence layer headers in the bit stream will be identical. If "mode=1" is signaled and a sequence layer header is present in the coded bit stream, then it MUST be identical to the sequence layer header specified by the "config" media type parameter.
高度なプロファイルを使用して、特定のアプリケーションでは、シーケンス層のヘッダは変更されません。これは、メディアタイプパラメータ「モード= 1」と合図されるかもしれません。 （「モード」パラメータは、セクション6.1で定義されている。）「モード= 1」パラメータは、ビットストリーム内のすべてのシーケンス層のヘッダが同じになることをRTP受信機に「ヒント」として機能します。 「= 1モード」が通知され、シーケンス層のヘッダは、符号化ビットストリーム中に存在し、それは、「設定」メディアタイプパラメータによって指定されたシーケンス層のヘッダと同一でなければならない。場合
Since the sequence layer header never changes in "mode=1", the RTP sender MAY remove it from the bit stream. Note, however, that if the value of TFCNTRFLAG in the sequence layer header is 1, each picture header contains a frame counter field (TFCNTR). This field is reset each time the sequence layer header occurs in the bit stream. If the RTP sender chooses to remove the sequence layer header, then it MUST ensure that the resulting bit stream is still compliant with the VC-1 specification (e.g., by adjusting the TFCNTR field, if necessary.)
シーケンス層のヘッダが「= 1モード」に変化しないので、RTP送信機は、ビットストリームからそれを除去することができます。シーケンス層ヘッダ内TFCNTRFLAGの値が1である場合、各ピクチャヘッダは、フレームカウンタフィールド（TFCNTR）を含んでいること、しかし、注意してください。このフィールドは、シーケンス層のヘッダは、ビットストリームで発生するたびにリセットされます。 RTP送信機は、シーケンス層のヘッダを削除することを選択した場合、それは結果として得られるビットストリームは依然としてVC-1仕様に準拠することを保証しなければならない（必要であれば、TFCNTRフィールドを調整することにより、例えば、。）
In certain applications using Advanced profile, both the sequence layer header and the entry-point header never change. This MAY be signaled with the media type parameter "mode=3". The same rules apply to "mode=3" as for "mode=1", described in section 4.8. Additionally, if "mode=3" is signaled, then the RTP sender MAY "compress" the coded bit stream by not including sequence layer headers and entry-point headers in the RTP packets.
高度プロファイルを使用して特定の用途において、シーケンス層のヘッダとエントリポイントヘッダの両方変更することはありません。これは、メディアタイプパラメータ「モード= 3」と合図されるかもしれません。同じ規則が適用するセクション4.8に記載の「MODE = 1」の場合と「モード= 3」。 「= 3モード」が通知された場合に加え、次いで、RTP送信機は、シーケンス層ヘッダ及びRTPパケットのエントリ・ポイント・ヘッダを含めないことにより、符号化ビットストリームを「圧縮」MAY。
The RTP receiver MUST "decompress" the coded bit stream by re-inserting the entry-point headers prior to delivering the coded bit stream to the VC-1 decoder. The sequence layer header does not need to be decompressed by the receiver, as it never changes.
RTP受信機は、従来のVC-1デコーダに符号化ビットストリームを提供するエントリポイントヘッダを再挿入することにより符号化ビットストリームを「解凍」しなければなりません。シーケンス層のヘッダは、それが変化しないように、受信機によって圧縮解除される必要はありません。
If "mode=3" is signaled and the RTP receiver receives a complete AU or the first fragment of an AU, and the RA bit is set to 1 but the AU does not begin with an entry-point header, then this indicates that the entry-point header has been "compressed". In that case, the RTP receiver MUST insert an entry-point header at the beginning of the AU. When inserting the entry-point header, the RTP receiver MUST use the one that was specified by the "config" media type parameter.
「モード= 3」シグナリングされるとRTP受信機は、1に設定されている完全なAUまたはAUの最初のフラグメント、及びRAのビットを受信するが、エントリポイントヘッダで始まらないAUが、これはことを示す場合エントリ・ポイント・ヘッダが「圧縮」されています。その場合には、RTP受信機は、AUの先頭にエントリ・ポイント・ヘッダを挿入する必要があります。エントリ・ポイント・ヘッダを挿入するとき、RTP受信機は、「設定」メディアタイプパラメータによって指定されたものを使用しなければなりません。
The format of the RTP header is specified in RFC 3550 [3] and is reprinted in Figure 3 for convenience.
RTPヘッダのフォーマットは、[3] RFC 3550で指定されており、便宜上、図3に転載されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550
RFC 3550によれば、図3 RTPヘッダ
The fields of the fixed RTP header have their usual meaning, which is defined in RFC 3550 and by the RTP profile in use, with the following additional notes:
固定RTPヘッダーのフィールドは、以下の追加の注意事項で、RFC 3550で使用中のRTPプロファイルで定義されている彼らの通常の意味を、持っています：
Marker bit (M): 1 bit This bit is set to 1 if the RTP packet contains an Access Unit containing a complete VC-1 frame or the last fragment of a VC-1 frame.
マーカービット（M）：1ビットRTPパケットは、完全なVC-1フレーム又はVC-1フレームの最後の断片を含むアクセスユニットが含まれている場合、このビットが1に設定されています。
Payload type (PT): 7 bits This document does not assign an RTP payload type for this RTP payload format. The assignment of a payload type has to be performed either through the RTP profile used or in a dynamic way.
ペイロードタイプ（PT）：7ビットは、この文書では、RTPペイロード形式のためのRTPペイロードタイプを割り当てません。ペイロードタイプの割り当てが使用RTPプロファイルを介して、または動的な方法のいずれかで実行されなければなりません。
Sequence Number: 16 bits The RTP receiver can use the sequence number field to recover the coded order of the VC-1 frames. A typical VC-1 decoder will require the VC-1 frames to be delivered in coded order. When VC-1 frames have been fragmented across RTP packets, the RTP receiver can use the sequence number field to ensure that no fragment is missing.
配列番号：16ビットは、RTP受信機は、VC-1フレームの符号化順序を回復するためにシーケンス番号フィールドを使用することができます。 VC-1フレームを必要とする典型的なVC-1デコーダは、符号化された順序で配信されます。 VC-1フレームは、RTPパケットを横切って断片化されている場合、RTP受信機にはフラグメントが欠落していないことを保証するために、シーケンス番号フィールドを使用することができます。
Timestamp: 32 bits The RTP timestamp is set to the presentation time of the VC-1 frame in the first Access Unit. A clock rate of 90 kHz MUST be used.
タイムスタンプ：32ビットRTPタイムスタンプは、最初のアクセスユニットにおけるVC-1フレームの提示時刻に設定されています。 90キロヘルツのクロックレートを使用しなければなりません。
The Access Unit header consists of a one-byte AU Control field, the RA Count field, and 3 optional fields. All fields MUST be written in network byte order. The structure of the AU header is illustrated in Figure 4.
アクセスユニットヘッダは1バイトAU制御フィールド、RAカウントフィールド、及び3つのオプションのフィールドで構成されています。すべてのフィールドはネットワークバイトオーダーで記述する必要があります。 AUのヘッダの構造を図4に示されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Structure of AU header
AUヘッダの図4の構造
AU Control: 8 bits The usage of the AU Control field is defined in section 5.3.
AUコントロール：AU制御フィールドの8ビットの使用はセクション5.3で定義されています。
RA Count: 8 bits Random Access Point Counter. This field is a binary modulo 256 counter. The value of this field MUST be incremented by 1 each time an AU is transmitted where the RA bit in the AU Control field is set to 1. The initial value of this field is undefined and MAY be chosen randomly.
RA数：8ビット・ランダム・アクセス・ポイントのカウンターを。このフィールドは、バイナリモジュロ256カウンタです。このフィールドの値は1 AUはAU制御フィールドにおけるRAビットが1に設定されている場合、このフィールドの初期値は不定であり、ランダムに選択することができる送信されるたびにインクリメントされなければなりません。
AUP Len: 16 bits Access Unit Payload Length. Specifies the size, in bytes, of the payload of the Access Unit. The field does not include the size of the AU header itself. The field MUST be included in each AU header in an RTP packet, except for the last AU header in the packet. If this field is not included, the payload of the Access Unit SHALL be assumed to extend to the end of the RTP payload.
AUPレン：16ビットアクセスユニットのペイロード長。アクセスユニットのペイロードのサイズをバイト単位で指定します。フィールドは、AUのヘッダ自体の大きさを含んでいません。フィールドは、パケット内の最後のAUのヘッダを除いて、RTPパケットに各AUのヘッダに含まれなければなりません。このフィールドが含まれていない場合は、アクセスユニットのペイロードは、RTPペイロードの終わりまで延長すると仮定するものとします。
PTS Delta: 32 bits Presentation time delta. Specifies the presentation time of the frame as a 2's complement offset (delta) from the timestamp field in the RTP header of this RTP packet. The PTS Delta field MUST use the same clock rate as the timestamp field in the RTP header.
PTSデルタ：32ビットのプレゼンテーション時間デルタ。このRTPパケットのRTPヘッダ内のタイムスタンプフィールドからオフセット2の補数としてフレーム（デルタ）のプレゼンテーション時間を指定します。 PTSデルタフィールドは、RTPヘッダ内のタイムスタンプ・フィールドと同じクロックレートを使用しなければなりません。
This field SHOULD NOT be included in the first AU header in the
RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. If this field is not included, the presentation time of the frame SHALL be
assumed to be specified by the timestamp field in the RTP
header.
DTS Delta: 32 bits Decode time delta. Specifies the decode time of the frame as a 2's complement offset (delta) between the presentation time and the decode time. Note that if the presentation time is larger than the decode time, this results in a value for the DTS Delta field that is greater than zero. The DTS Delta field MUST use the same clock rate as the timestamp field in the RTP header. If this field is not included, the decode time of the frame SHALL be assumed to be identical to the presentation time of the frame.
DTSデルタ：32ビットは時間デルタをデコードします。プレゼンテーションの時間とデコード時間との間の2の補数オフセット（デルタ）として、フレームのデコード時間を指定します。プレゼンテーションの時間は、デコード時間よりも大きい場合、これはゼロよりも大きいDTSデルタフィールドの値の結果であることに留意ください。 DTSデルタフィールドは、RTPヘッダ内のタイムスタンプ・フィールドと同じクロックレートを使用しなければなりません。このフィールドが含まれていない場合は、フレームのデコード時間は、フレームのプレゼンテーション時間と同じでないとみなさなければなりません。
The structure of the 8-bit AU Control field is shown in Figure 5.
8ビットAU Controlフィールドの構造は、図5に示されています。
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field.
図5. AU制御フィールドの構文。
FRAG: 2 bits Fragmentation Information. This field indicates if the AU payload contains a complete frame or a fragment of a frame. It MUST be set as follows:
FRAG：2ビットフラグメンテーション情報。 AUペイロードが完全なフレームまたはフレームの断片を含んでいる場合、このフィールドは示します。それは以下のように設定しなければなりません。
0: The AU payload contains a fragment of a frame other than the first or last fragment. 1: The AU payload contains the first fragment of a frame. 2: The AU payload contains the last fragment of a frame. 3: The AU payload contains a complete frame (not fragmented.)
0：AUペイロードは、最初または最後のフラグメント以外のフレームのフラグメントを含みます。 1：AUペイロードは、フレームの最初のフラグメントを含みます。 2：AUペイロードはフレームの最後のフラグメントを含みます。 3：AUペイロードは完全なフレーム含有（断片化されていません。）
RA: 1 bit Random Access Point indicator. This bit MUST be set to 1 if the AU contains a frame that is a random access point. In the case of Simple and Main profiles, any I-picture is a random access point.
RA：1ビットのランダムアクセスポイントのインジケータ。 AUがランダムアクセスポイントであるフレームが含まれている場合、このビットは1に設定しなければなりません。シンプルでメインプロファイルの場合は、任意のIピクチャがランダムアクセスポイントです。
In the case of Advanced profile, the first frame after an
entry-point header is a random access point.
If entry-point headers are not transmitted at every random access point, this MUST be indicated using the media type parameter "mode=3".
エントリ・ポイント・ヘッダ毎ランダムアクセスポイントで送信されていない場合、これは「モード= 3」メディアタイプパラメータを使用して示さなければなりません。
SL: 1 bit Sequence Layer Counter. This bit MUST be toggled, i.e., changed from 0 to 1 or from 1 to 0, if the AU contains a sequence layer header and if it is different from the most recently transmitted sequence layer header. Otherwise, the value of this bit must be identical to the value of the SL bit in the previous AU.
SL：1ビットシーケンス層のカウンター。このビットは、すなわち、0から1に変更又は1から0に、AUは、シーケンス層のヘッダが含まれている場合、それは最も最近送信されたシーケンス層のヘッダと異なる場合、切り替えなければなりません。それ以外の場合、このビットの値は、前のAUでSLビットの値と同じでなければなりません。
The initial value of this bit is undefined and MAY be chosen
randomly.
The bit MUST be 0 for Simple and Main profile bit streams or if the sequence layer header never changes.
ビットが0シンプルメインプロファイルビットストリームまたはシーケンス層のヘッダは変更されない場合でなければなりません。
LP: 1 bit Length Present. This bit MUST be set to 1 if the AU header includes the AUP Len field.
LP：現在の1ビットの長さ。 AUのヘッダはAUP LENフィールドが含まれている場合、このビットは1に設定しなければなりません。
PT: 1 bit PTS Delta Present. This bit MUST be set to 1 if the AU header includes the PTS Delta field.
PT：1ビットPTSデルタプレゼント。 AUのヘッダはPTSデルタフィールドが含まれている場合、このビットは1に設定しなければなりません。
DT: 1 bit DTS Delta Present. This bit MUST be set to 1 if the AU header includes the DTS Delta field.
DT：1ビットDTSデルタプレゼント。 AUのヘッダはDTSデルタフィールドが含まれている場合、このビットは1に設定しなければなりません。
R: 1 bit Reserved. This bit MUST be set to 0 and MUST be ignored by receivers.
R：1ビットのReserved。このビットは0に設定しなければならなくて、受信機で無視しなければなりません。
This registration uses the template defined in RFC 4288 [7] and follows RFC 3555 [8].
この登録は、[7] RFC 4288で定義されたテンプレートを使用して、RFC 3555 [8]に従います。
Type name: video
型名：ビデオ
Subtype name: vc1
サブタイプ名：VC1
Required parameters:
必須パラメータ：
profile:
The value is an integer identifying the VC-1 profile. The
following values are defined:
0: Simple profile 1: Main profile 3: Advanced profile
0：シンプルプロファイル1：メインプロファイル3：高度プロファイル
If the profile parameter is used to indicate properties of a coded bit stream, it indicates the VC-1 profile that a decoder has to support when it decodes the bit stream.
プロファイルパラメータは、符号化ビットストリームの性質を示すために使用される場合、それは、デコーダが、ビットストリームをデコードする際サポートする必要があるVC-1プロファイルを示しています。
If the profile parameter is used for capability exchange or in a session setup procedure, it indicates the VC-1 profile that the codec supports.
プロファイルパラメータは、能力交換またはセッションセットアップ手順で使用されている場合は、コーデックがサポートするVC-1プロファイルを示しています。
level: The value is an integer that specifies the level of the VC-1 profile.
レベル：値は、VC-1プロファイルのレベルを指定する整数です。
For Advanced profile, valid values are 0 through 4, which correspond to levels L0 through L4, respectively. For Simple and Main profiles, the following values are defined:
高度プロファイルのために、有効な値は、それぞれ、L4を介してレベルL0に対応する、0〜4です。シンプルでメインプロファイルでは、次の値が定義されています。
1: Low Level 2: Medium Level 3: High Level (only valid for Main profile)
1：低レベル2：中レベル3：ハイレベル（メインプロファイルでのみ有効）
If the level parameter is used to indicate properties of a coded bit stream, it indicates the highest level of the VC-1 profile that a decoder has to support when it decodes the bit stream. Note that support for a level implies support for all numerically lower levels of the given profile.
レベルパラメータは符号化ビットストリームの性質を示すために使用される場合、それは、デコーダが、ビットストリームをデコードする際サポートする必要があるVC-1プロファイルの最高レベルを示しています。レベルのサポートは、特定のプロファイルのすべての数値の低いレベルのサポートを暗示することに留意されたいです。
If the level parameter is used for capability exchange or in a session setup procedure, it indicates the highest level of the VC-1 profile that the codec supports. See section 6.3 of RFC 4425 for specific rules for how this parameter is used with the SDP Offer/Answer model.
レベルパラメータは能力交換またはセッションセットアップ手順で使用されている場合は、コーデックがサポートするVC-1プロファイルの最高レベルを示しています。このパラメータは、SDPオファー/アンサーモデルを使用する方法のための特定のルールについては、RFC 4425のセクション6.3を参照してください。
Optional parameters:
オプションのパラメータ：
config:
The value is a base16 [6] (hexadecimal) representation of an
octet string that expresses the decoder initialization
parameters. Decoder initialization parameters are mapped
onto the base16 octet string in an MSB-first basis. The
first bit of the decoder initialization parameters MUST be
located at the MSB of the first octet. If the decoder
initialization parameters are not multiples of 8 bits, up to
7 zero-valued padding bits MUST be added in the last octet
to achieve octet alignment.
For Simple and Main profiles, the decoder initialization parameters are STRUCT_C, as defined in Annex J of SMPTE 421M [1].
シンプルメインプロファイルの場合、デコーダの初期化パラメータは、SMPTE 421Mの付属書Jで定義されるようSTRUCT_Cは、[1]。
For Advanced profile, the decoder initialization parameters are a sequence layer header directly followed by an entry-point header. The two headers MUST be in EBDU format, meaning that they must include their Start Codes and must use the encapsulation method defined in Annex E of SMPTE 421M [1].
高度プロファイルのために、デコーダの初期化パラメータを直接エントリポイントヘッダに続くシーケンス層ヘッダです。 2つのヘッダは彼らのスタートコードを含まなければならないことを意味し、EBDUフォーマットでなければならないし、SMPTE 421Mの付属書Eに定義されているカプセル化法を使用しなければならない[1]。
width: The value is an integer greater than zero, specifying the maximum horizontal size of the coded frames, in luma samples (pixels in the luma picture).
幅：値は、輝度サンプル中の符号化フレームの最大横サイズ（輝度画像の画素）を指定し、零より大きい整数です。
For Simple and Main profiles, the value SHALL be identical to the actual horizontal size of the coded frames.
シンプルメインプロファイルの場合、値は符号化されたフレームの実際の水平方向のサイズと同一でなければなりません。
For Advanced profile, the value SHALL be greater than, or equal to, the largest horizontal size of the coded frames.
高度プロファイルのために、値は、符号化されたフレームの最大横サイズより大きい、または等しいものでなければなりません。
If this parameter is not specified, it defaults to the maximum horizontal size allowed by the specified profile and level.
指定されたプロファイルとレベルで許可される最大横サイズにこのパラメータが指定されていない場合、それはデフォルト。
height: The value is an integer greater than zero, specifying the maximum vertical size of the coded frames, in luma samples (pixels in a progressively coded luma picture).
高さ：値が輝度サンプルで符号化されたフレーム、（漸進符号化された輝度画像の画素）の最大垂直方向のサイズを指定するゼロより大きい整数です。
For Simple and Main profiles, the value SHALL be identical to the actual vertical size of the coded frames.
シンプルメインプロファイルの場合、値は符号化されたフレームの実際の縦方向のサイズと同一でなければなりません。
For Advanced profile, the value SHALL be greater than, or equal to, the largest vertical size of the coded frames.
高度プロファイルのために、値は、符号化されたフレームの最大垂直寸法よりも大きい、またはそれに等しくなければなりません。
If this parameter is not specified, it defaults to the maximum vertical size allowed by the specified profile and level.
指定されたプロファイルとレベルで許可される最大垂直寸法にこのパラメータが指定されていない場合、それはデフォルト。
bitrate: The value is an integer greater than zero, specifying the peak transmission rate of the coded bit stream in bits per second. The number does not include the overhead caused by RTP encapsulation, i.e., it does not include the AU headers, or any of the RTP, UDP, or IP headers.
ビットレート：値は秒当たりのビットで符号化ビットストリームのピーク伝送レートを指定する、零より大きい整数です。数、すなわち、それはAUヘッダー、またはRTP、UDP、又はIPヘッダのいずれかを含んでいない、RTPカプセル化によって引き起こされるオーバーヘッドを含みません。
If this parameter is not specified, it defaults to the maximum bit rate allowed by the specified profile and level. See the values for "RMax" in Annex D of SMPTE 421M [1].
指定されたプロファイルとレベルで許可される最大ビットレートにこのパラメータが指定されていない場合、それはデフォルト。 SMPTE 421M [1]の付録Dの "RMAX" の値を参照してください。
buffer: The value is an integer specifying the leaky bucket size, B, in milliseconds, required to contain a stream transmitted at the transmission rate specified by the bitrate parameter. This parameter is defined in the hypothetical reference decoder model for VC-1, in Annex C of SMPTE 421M [1].
バッファ：値は、リーキーバケットサイズを指定する整数であり、Bは、ミリ秒単位で、ビットレートパラメータで指定された伝送レートで送信されたストリームを含むことが必要。このパラメータは、SMPTE 421Mの附属書Cに、VC-1のための仮想基準デコーダモデルで定義されている[1]。
Note that this parameter relates to the codec bit stream only, and does not account for any buffering time that may be required to compensate for jitter in the network.
このパラメータは、コーデックビットストリームに関し、ネットワークのジッタを補償するために必要とされ得る任意のバッファリング時間を考慮していないことに留意されたいです。
If this parameter is not specified, it defaults to the maximum buffer size allowed by the specified profile and level. See the values for "BMax" and "RMax" in Annex D of SMPTE 421M [1].
指定されたプロファイルとレベルにより許容される最大バッファサイズに、このパラメータを指定しない場合、それはデフォルト。 SMPTE 421M [1]の付録Dの "BMAX" および "RMAX" の値を参照してください。
framerate: The value is an integer greater than zero, specifying the maximum number of frames per second in the coded bit stream, multiplied by 1000 and rounded to the nearest integer value. For example, 30000/1001 (approximately 29.97) frames per second is represented as 29970.
フレームレート：値が1000と最も近い整数値に丸めを乗じた符号化ビットストリームにおける秒あたりのフレームの最大数を指定するゼロより大きい整数です。例えば、毎秒30000/1001（約29.97）フレームは29970として表されます。
This parameter can be used to control resource allocation at the receiver. For example, a receiver may choose to perform additional post-processing on decoded frames only if the frame rate is expected to be low. The parameter MUST NOT be used for pacing of the rendering process, since the actual frame rate may differ from the specified value.
このパラメータは、受信機におけるリソース割り当てを制御するために使用することができます。例えば、受信機は、フレームレートが低いと予想される場合にのみ、復号されたフレームに追加の後処理を実行することを選択することができます。実際のフレームレートが指定された値と異なるかもしれないのでパラメータは、レンダリング処理のペーシングのために使用してはいけません。
If the parameter is not specified, it defaults to the maximum frame rate allowed by the specified profile and level.
指定されたプロファイルとレベルにより許容される最大フレームレートのパラメータが指定されていない場合、それはデフォルト。
bpic: This parameter signals that B- and BI-pictures may be present when Advanced profile is used. If this parameter is present, and B- or BI-pictures may be present in the coded bit stream, this parameter MUST be equal to 1.
BPIC：高度なプロファイルを使用する場合はB-とBIピクチャが存在することができる。このパラメータ信号。このパラメータが存在し、B-またはBIピクチャは、符号化ビットストリーム中に存在し得る場合、このパラメータは1に等しくなければなりません。
A value of 0 indicates that B- and BI-pictures SHALL NOT be present in the coded bit stream, even if the sequence layer header changes. Inclusion of this parameter with a value of 0 is RECOMMENDED, if neither B- nor BI-pictures are included in the coded bit stream.
0の値は、B-およびBIピクチャは、符号化ビットストリーム中に存在してはならないことがあっても、シーケンス層のヘッダの変更を示しています。どちらB-もBIピクチャを符号化ビットストリームに含まれている場合は0の値でこのパラメータを含めることが推奨されます。
This parameter MUST NOT be used with Simple and Main profiles. For Main profile, the presence of B- and BI-pictures is indicated by the MAXBFRAMES field in STRUCT_C decoder initialization parameter.
このパラメータは、シンプルでメインプロファイルを使用してはいけません。メインプロファイルのために、B-およびBIピクチャの存在はSTRUCT_Cデコーダ初期化パラメータでMAXBFRAMESフィールドによって示されています。
For Advanced profile, if this parameter is not specified, a value of 1 SHALL be assumed.
このパラメータが指定されていない場合、高度なプロファイルについては、1の値が想定されるものとします。
mode: The value is an integer specifying the use of the sequence layer header and the entry-point header. This parameter is only defined for Advanced profile. The following values are defined:
モード：値は、シーケンス層のヘッダとエントリポイントヘッダの使用を指定する整数です。このパラメータは、高度なプロファイルのために定義されています。次の値が定義されています。
0: Both the sequence layer header and the entry-point header may change, and changed headers will be included in the RTP packets. 1: The sequence layer header specified in the config parameter never changes. The rules in section 4.8 of RFC 4425 MUST be followed. 3: The sequence layer header and the entry-point header specified in the config parameter never change. The rules in section 4.9 of RFC 4425 MUST be followed.
0：配列層ヘッダとエントリ・ポイント・ヘッダの両方が変更される可能性があり、そしてヘッダがRTPパケットに含まれる変更。 1：設定パラメータで指定されたシーケンス層ヘッダは変化しません。 RFC 4425のセクション4.8の規則に従わなければなりません。 3：配列層ヘッダと設定パラメータで指定されたエントリ・ポイント・ヘッダ変更しません。 RFC 4425のセクション4.9の規則に従わなければなりません。
If the mode parameter is not specified, a value of 0 SHALL be assumed. The mode parameter SHOULD be specified if modes 1 or 3 apply to the VC-1 bit stream.
モードパラメータを指定しない場合、0の値が想定されるものとします。モード1または3にVC-1ビットストリームに適用する場合はモードパラメータが指定されるべきです。
max-width, max-height, max-bitrate, max-buffer, max-framerate: These parameters are defined for use in a capability exchange procedure. The parameters do not signal properties of the coded bit stream, but rather upper limits or preferred values for the "width", "height", "bitrate", "buffer", and "framerate" parameters. Section 6.3 of RFC 4425 provides specific rules for how these parameters are used with the SDP Offer/Answer model.
最大幅、最大高さ、最大ビットレート、最大バッファ、MAX-フレームレート：これらのパラメータは、能力交換手順で使用するために定義されています。パラメータは、符号化ビットストリームの特性が、「幅」、「高さ」、「ビットレート」のではなく上限または好ましい値は、「緩衝液」、及び「フレームレート」パラメータをシグナリングしていません。 RFC 4425のセクション6.3には、これらのパラメータは、SDPオファー/アンサーモデルで使用されている方法のための特定の規則を提供します。
Receivers that signal support for a given profile and level MUST support the maximum values for these parameters for that profile and level. For example, a receiver that indicates support for Main profile, Low level, must support a width of 352 luma samples and a height of 288 luma samples, even if this requires scaling the image to fit the resolution of a smaller display device.
特定のプロファイル及びレベルのサポートを信号受信機は、そのプロファイル及びレベルに対するこれらのパラメータの最大値をサポートしなければなりません。例えば、メインプロファイル、低レベルのサポートを示している受信機は、これがより小さなディスプレイ装置の解像度に合うように画像をスケーリングする必要も、352個の輝度サンプルの幅及び288個のルマサンプルの高さをサポートしなければなりません。
A receiver MAY use any of the max-width, max-height, max-bitrate, max-buffer, and max-framerate parameters to indicate preferred capabilities. For example, a receiver may choose to specify values for max-width and max-height that match the resolution of its display device, since a bit stream encoded using those parameters would not need to be rescaled.
受信機は、好ましい性能を示すために、最大幅、最大高さ、最大ビットレート、最大バッファ、および最大フレームレートパラメータのいずれかを使用するかもしれません。例えば、受信機は、これらのパラメータを用いて符号化されたビットストリームを再スケーリングする必要がないので、その表示装置の解像度に合わせ最大幅及び最大高さの値を指定することを選択することができます。
If any of the max-width, max-height, max-bitrate, max-buffer, and max-framerate parameters signal a capability that is less than the required capabilities of the signaled profile and level, then the parameter SHALL be interpreted as a preferred value for that capability.
最大幅、最大高さ、最大ビットレート、最大バッファ、および最大フレームレートパラメータのいずれかがシグナリングプロファイル及びレベルの必要な機能よりも少ない機能を知らせる場合、パラメータは、として解釈されるものその機能のために好ましい値。
Any of the parameters MAY also be used to signal capabilities that exceed the required capabilities of the signaled profile and level. In that case, the parameter SHALL be interpreted as the maximum value that can be supported for that capability.
パラメータのいずれかはまた、シグナリングプロファイル及びレベルの必要な能力を超える能力を知らせるために使用されるかもしれません。その場合、パラメータはその能力のためにサポートされ得る最大値として解釈されるものとします。
When more than one parameter from the set (max-width, max-height, max-bitrate, max-buffer, and max-framerate) is present, all signaled capabilities MUST be supported simultaneously.
セット（最大幅、最大高さ、最大ビットレート、最大バッファ、および最大フレームレート）から複数のパラメータが存在する場合、すべてのシグナリング機能を同時にサポートしなければなりません。
A sender or receiver MUST NOT use these parameters to signal capabilities that meet the requirements of a higher level of the VC-1 profile than that specified in the "level" parameter, even if the sender or receiver can support all the properties of the higher level, except if specifying a higher level is not allowed due to other restrictions. As an example of such a restriction, in the SDP Offer/Answer model, the value of the level parameter that can be used in an Answer is limited by what was specified in the Offer.
送信者または受信者は送信者または受信者が高いのすべてのプロパティをサポートすることができたとしても、「レベル」パラメータで指定したものよりVC-1プロファイルのより高いレベルの要件を満たす能力を知らせるために、これらのパラメータを使用してはなりませんより高いレベルを指定すると、原因その他の制限のために許可されていない場合を除き、レベル、。そのような制限の一例として、SDPオファー/アンサーモデルにおいて、回答に使用することができるレベルパラメータの値は、オファーに指定されたものによって限定されます。
max-width: The value is an integer greater than zero, specifying a horizontal size for the coded frames, in luma samples (pixels in the luma picture). If the value is less than the maximum horizontal size allowed by the profile and level, then the value specifies the preferred horizontal size. Otherwise, it specifies the maximum horizontal size that is supported.
最大幅：値は、輝度サンプルで符号化されたフレーム、（輝度画像の画素）の水平方向のサイズを指定し、ゼロより大きい整数です。値は、プロファイルとレベルで許可される最大水平サイズよりも小さい場合、その値は、好ましい水平方向のサイズを指定します。それ以外の場合は、サポートされている最大の水平方向のサイズを指定します。
If this parameter is not specified, it defaults to the maximum horizontal size allowed by the specified profile and level.
指定されたプロファイルとレベルで許可される最大横サイズにこのパラメータが指定されていない場合、それはデフォルト。
max-height: The value is an integer greater than zero, specifying a vertical size for the coded frames, in luma samples (pixels in a progressively coded luma picture). If the value is less than the maximum vertical size allowed by the profile and level, then the value specifies the preferred vertical size. Otherwise, it specifies the maximum vertical size that is supported.
最大高さは：値が輝度サンプルで符号化されたフレーム、（漸進符号化された輝度画像の画素）についての垂直方向のサイズを指定し、ゼロより大きい整数です。値は、プロファイルとレベルで許可される最大縦サイズより小さい場合、その値は、好ましい垂直方向のサイズを指定します。それ以外の場合は、サポートされる最大垂直サイズを指定します。
If this parameter is not specified, it defaults to the maximum vertical size allowed by the specified profile and level.
指定されたプロファイルとレベルで許可される最大垂直寸法にこのパラメータが指定されていない場合、それはデフォルト。
max-bitrate: The value is an integer greater than zero, specifying a peak transmission rate for the coded bit stream in bits per second. The number does not include the overhead caused by RTP encapsulation, i.e., it does not include the AU headers, or any of the RTP, UDP, or IP headers.
最大ビットレート：値は秒当たりのビットで符号化ビットストリームのピーク伝送レートを指定する、零より大きい整数です。数、すなわち、それはAUヘッダー、またはRTP、UDP、又はIPヘッダのいずれかを含んでいない、RTPカプセル化によって引き起こされるオーバーヘッドを含みません。
If the value is less than the maximum bit rate allowed by the profile and level, then the value specifies the preferred bit rate. Otherwise, it specifies the maximum bit rate that is supported.
値は、プロファイルとレベルで許可される最大ビットレートよりも小さい場合、その値は、好ましいビットレートを指定します。それ以外の場合は、サポートされる最大ビットレートを指定します。
If this parameter is not specified, it defaults to the maximum bit rate allowed by the specified profile and level. See the values for "RMax" in Annex D of SMPTE 421M [1].
指定されたプロファイルとレベルで許可される最大ビットレートにこのパラメータが指定されていない場合、それはデフォルト。 SMPTE 421M [1]の付録Dの "RMAX" の値を参照してください。
max-buffer: The value is an integer specifying a leaky bucket size, B, in milliseconds, required to contain a stream transmitted at the transmission rate specified by the max-bitrate parameter. This parameter is defined in the hypothetical reference decoder model for VC-1, in Annex C of SMPTE 421M [1].
MAX-バッファ：値は、リーキーバケットサイズを指定する整数であり、Bは、ミリ秒単位で、最大ビットレートパラメータで指定された伝送レートで送信されたストリームを含むことが必要。このパラメータは、SMPTE 421Mの附属書Cに、VC-1のための仮想基準デコーダモデルで定義されている[1]。
Note that this parameter relates to the codec bit stream only and does not account for any buffering time that may be required to compensate for jitter in the network.
このパラメータは、コーデック・ビット・ストリームに関連し、ネットワークのジッタを補償するために必要とされ得る任意のバッファリング時間を考慮していないことに留意されたいです。
If the value is less than the maximum leaky bucket size allowed by the max-bitrate parameter and the profile and level, then the value specifies the preferred leaky bucket size. Otherwise, it specifies the maximum leaky bucket size that is supported for the bit rate specified by the max-bitrate parameter.
値は、最大ビットレートパラメータとプロファイル及びレベルにより許容される最大リーキーバケットサイズより小さい場合、その値は、好ましいリーキーバケットサイズを指定します。それ以外の場合は、最大ビットレートパラメータで指定されたビットレートでサポートされている最大のリーキーバケットサイズを指定します。
If this parameter is not specified, it defaults to the maximum buffer size allowed by the specified profile and level. See the values for "BMax" and "RMax" in Annex D of SMPTE 421M [1].
指定されたプロファイルとレベルにより許容される最大バッファサイズに、このパラメータを指定しない場合、それはデフォルト。 SMPTE 421M [1]の付録Dの "BMAX" および "RMAX" の値を参照してください。
max-framerate: The value is an integer greater than zero, specifying a number of frames per second for the coded bit stream. The value is the frame rate multiplied by 1000 and rounded to the nearest integer value. For example, 30000/1001 (approximately 29.97) frames per second is represented as 29970.
MAX-フレームレート：値は、符号化ビットストリームのための秒あたりのフレーム数を指定し、零より大きい整数です。値は、フレームレート1000で乗算され、最も近い整数値に丸められます。例えば、毎秒30000/1001（約29.97）フレームは29970として表されます。
If the value is less than the maximum frame rate allowed by the profile and level, then the value specifies the preferred frame rate. Otherwise, it specifies the maximum frame rate that is supported.
値は、プロファイルとレベルにより許容される最大フレームレート未満である場合、その値は、好ましいフレームレートを指定します。それ以外の場合は、サポートされる最大フレームレートを指定します。
If the parameter is not specified, it defaults to the maximum frame rate allowed by the specified profile and level.
指定されたプロファイルとレベルにより許容される最大フレームレートのパラメータが指定されていない場合、それはデフォルト。
Encoding considerations: This media type is framed and contains binary data.
エンコードの考慮事項：このメディアタイプは、フレームとバイナリデータが含まれています。
Security considerations: See Section 7 of RFC 4425.
セキュリティの考慮事項：RFC 4425のセクション7を参照してください。
Interoperability considerations: None.
相互運用性に関する注意事項：なし。
Published specification: RFC 4425.
公開された仕様：RFC 4425。
Applications that use this media type: Multimedia streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングおよび会議ツール。
Additional Information: None.
追加情報：なし。
Person & email address to contact for further information: Anders Klemets <anderskl@microsoft.com> IETF AVT working group.
人と詳細のために連絡する電子メールアドレス：アンダースKlemets <anderskl@microsoft.com> IETF AVTワーキンググループ。
Intended Usage: COMMON
意図した使用法：COMMON
Restrictions on usage: This media type depends on RTP framing; therefore, it is only defined for transfer via RTP [3].
使用に関する制限事項：このメディアタイプは、RTP縁どりによって、したがって、のみRTP [3]を介して転送するために定義されています。
Authors: Anders Klemets
著者：アンダースKlemets
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4]. If SDP is used to specify sessions using this payload format, the mapping is done as follows:
メディアタイプ仕様で搬送される情報は、セッション記述プロトコル（SDP）内のフィールドに特定のマッピングを持っている[4]。 SDPは、このペイロードフォーマットを使用してセッションを指定するために使用されている場合は、次のようにマッピングが行われます。
o The media name in the "m=" line of SDP MUST be video (the type name).
メディア名O「M =」SDPの行は、ビデオ（タイプ名）でなければなりません。
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the subtype name).
O SDPの「A = rtpmap」ラインでエンコーディング名は、VC1（サブタイプ名）でなければなりません。
o The clock rate in the "a=rtpmap" line MUST be 90000.
O「A = rtpmap」行のクロックレートは90000でなければなりません。
o The REQUIRED parameters "profile" and "level" MUST be included in the "a=fmtp" line of SDP.
O必要なパラメータ「プロファイル」と「レベル」は、SDPの「A =のfmtp」行に含まれなければなりません。
These parameters are expressed in the form of a semicolon separated list of parameter=value pairs.
これらのパラメータは、パラメータ=値のペアのセミコロンで区切られたリストの形式で表現されています。
o The OPTIONAL parameters "config", "width", "height", "bitrate", "buffer", "framerate", "bpic", "mode", "max-width", "max-height", "max-bitrate", "max-buffer", and "max-framerate", when present, MUST be included in the "a=fmtp" line of SDP.
オプションのパラメータ「設定」、「幅」、「高さ」、「ビットレート」、「バッファ」、「フレームレート」、「BPIC」、「モード」、「最大幅」、「最大高さ」、「最大O 「、 "-bitrate MAX-バッファ"、および "MAX-フレームレートSDPのA =のfmtp "線"、存在する場合、含まなければなりません"。
These parameters are expressed in the form of a semicolon separated list of parameter=value pairs:
これらのパラメータは、パラメータ=値のペアのセミコロンで区切られたリストの形式で表されます。
a=fmtp:<dynamic payload type> <parameter name>=<value>[,<value>][; <parameter name>=<value>]
=のfmtp：<ダイナミックペイロードタイプ> <パラメータ名> = <値>、<値>] [。 <パラメータ名> = <値>]
o Any unknown parameters to the device that uses the SDP MUST be ignored. For example, parameters defined in later specifications MAY be copied into the SDP and MUST be ignored by receivers that do not understand them.
O SDPを使用するデバイスへの任意の未知のパラメータを無視しなければなりません。例えば、後の仕様で定義されたパラメータは、SDPにコピーすることができ、それらを理解していない受信機で無視しなければなりません。
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5] for negotiation for unicast usage, the following rules and limitations apply:
VC-1は、ユニキャストの使用のためのネゴシエーションのためのオファー/アンサーモデル[5]でSDPを使用してRTPの上に提供される場合、以下の規則と制限が適用されます。
o The "profile" parameter MUST be used symmetrically, i.e., the answerer MUST either maintain the parameter or remove the media format (payload type) completely if the offered VC-1 profile is not supported.
O「プロファイル」パラメータは、すなわち、回答パラメータを維持しなければならないのいずれか、または提供されるVC-1プロファイルがサポートされていない場合、完全メディアフォーマット（ペイロードタイプ）を削除し、対称的に使用されなければなりません。
o The "level" parameter specifies the highest level of the VC-1 profile supported by the codec.
O「レベル」パラメータは、コーデックでサポートされているVC-1プロファイルの最高レベルを指定します。
The answerer MUST NOT specify a numerically higher level in the answer than that specified in the offer. The answerer MAY specify a level that is lower than that specified in the offer, i.e., the level parameter can be "downgraded".
回答は提供で指定されたものより答えで数値的により高いレベルを指定してはなりません。回答、すなわち、レベルパラメータが「格下げ」させることができる、オファーに指定されたより低いレベルを指定するかもしれません。
If the offer specifies the sendrecv or sendonly direction attribute and the answer downgrades the level parameter, this may require a new offer to specify an updated "config" parameter. If the "config" parameter cannot be used with the level specified in the answer, then the offerer MUST initiate another Offer/Answer round or not use media format (payload type).
オファーはSENDRECVまたはsendonlyの方向属性を指定し、答えはレベル・パラメータをダウングレードした場合、これは、更新され、「設定」のパラメータを指定するには、新しいプランが必要な場合があります。 「設定」パラメータが回答で指定されたレベルで使用することができない場合には、提供者は、別のオファー/アンサーラウンドを開始するか、またはメディアフォーマット（ペイロードタイプ）を使用してはなりません。
o The parameters "config", "bpic", "width", "height", "framerate", "bitrate", "buffer", and "mode", describe the properties of the VC-1 bit stream that the offerer or answerer is sending for this media format configuration.
Oパラメータ「設定」、「BPIC」、「幅」、「高さ」、「フレームレート」、「ビットレート」、「バッファ」、及び「モード」は、VC-1ビットストリームの特性を記述することオファーまたはアンサー側は、このメディア形式の設定のために送信されます。
In the case of unicast usage and when the direction attribute in the offer or answer is recvonly, the interpretation of these parameters is undefined and they MUST NOT be used.
ユニキャストの使用の場合との申し出または回答で方向属性ががrecvonlyであるとき、これらのパラメータの解釈は未定義であり、彼らが使用してはいけません。
o The parameters "config", "width", "height", "bitrate", and "buffer" MUST be specified when the direction attribute is sendrecv or sendonly.
方向属性がSENDRECVまたはsendonlyの場合にパラメータ「設定」、「幅」、「高さ」、「ビットレート」、および「バッファ」が指定されなければならないO。
o The parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MAY be specified in an offer or an answer, and their interpretation is as follows:
oをパラメータ「最大幅」、「最大高さ」、「MAX-フレームレート」、「最大ビットレート」、および「MAX-バッファは」申し出または回答に指定することができ、かつ、次のように彼らの解釈は次のとおりです。
When the direction attribute is sendonly, the parameters describe the limits of the VC-1 bit stream that the sender is capable of producing for the given profile and level, and for any lower level of the same profile.
方向属性がsendonlyの場合には、パラメータは、送信者が特定のプロファイル及びレベルに対して生成することが可能であり、そして同じプロファイルのいずれかより低いレベルのためのVC-1ビットストリームの制限を記述する。
When the direction attribute is recvonly or sendrecv, the parameters describe properties of the receiver implementation. If the value of a property is less than that allowed by the level of the VC-1 profile, then it SHALL be interpreted as a preferred value and the sender's VC-1 bit stream SHOULD NOT exceed it. If the value of a property is greater than what is allowed by the level of the VC-1 profile, then it SHALL be interpreted as the upper limit of the value that the receiver accepts for the given profile and level, and for any lower level of the same profile.
方向属性がrecvonlyで又はSENDRECVである場合、パラメータは、受信機の実装の特性を記述する。プロパティの値は、VC-1プロファイルのレベルで許可されているものよりも小さい場合、それは好ましい値として解釈されるものと、送信者のVC-1ビットストリームは、それを超えてはなりません。プロパティの値は、VC-1プロファイルのレベルで許可されるものよりも大きい場合、それは、受信機が特定のプロファイル及びレベルに対して受け入れ値の上限として解釈され、任意のより低いレベルのためすることがSHALL同じプロファイルの。
For example, if a recvonly or sendrecv offer specifies "profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a suggested bit rate, because all receiver implementations of Simple profile, Low level, are required to support bit rates of up to 96 kbps. Assuming that the offer is accepted, the answerer should specify "bitrate=48000" in the answer, but any value up to 96000 is allowed. But if the offer specifies "max-bitrate=200000", this means that the receiver implementation supports a maximum of 200 kbps for the given profile and level (or lower level). In this case, the answerer is allowed to answer with a bitrate parameter of up to 200000.
recvonlyで又はSENDRECVオファー「は、レベル= 1;プロファイル= 0 MAX-ビットレート= 48000」を指定した場合、例えば、シンプルプロファイル、Lowレベル、すべての受信機実装をする必要があるので、その後48 kbpsのは、単に提案ビットレートであります最大96 kbpsののサポートビットレート。オファーが受け入れられていると仮定すると、回答がその答えに「48000 =ビットレート」を指定する必要がありますが、96000までの任意の値が許可されます。オファーは「最大ビットレート= 200000」を指定する場合は、これは、受信機の実装は、特定のプロファイル及びレベル（又は低レベル）、200 kbpsの最大をサポートしていることを意味します。この場合、回答は200000までのビットレートパラメータに答えるために許可されています。
o If an offerer wishes to have non-symmetrical capabilities between sending and receiving, e.g., use different levels in each direction, then the offerer has to offer different RTP sessions. This can be done by specifying different media lines declared as "recvonly" and "sendonly", respectively.
提供者は、例えば、送信側と受信側の間で非対称能力を有する各方向で異なるレベルを使用したい場合は、O、次いで申出は、異なるRTPセッションを提供しています。これは、それぞれ、「recvonlyで」と「sendonlyで」と宣言した別のメディアラインを指定することによって行うことができます。
For streams being delivered over multicast, the following rules apply in addition:
マルチキャストを介して配信されるストリームの場合、次の規則がほかに適用されます。
o The "level" parameter specifies the highest level of the VC-1 profile used by the participants in the multicast session. The value of this parameter MUST NOT be changed by the answerer. Thus, a payload type can be either accepted unaltered or removed.
O「レベル」パラメータは、マルチキャストセッションの参加者が使用するVC-1プロファイルの最高レベルを指定します。このパラメータの値は、回答によって変更してはいけません。したがって、ペイロードタイプは、いずれかの不変受け入れ又は除去することができます。
o The parameters "config", "bpic", "width", "height", "framerate", "bitrate", "buffer", and "mode", specify properties of the VC-1 bit stream that will be sent and/or received on the multicast session. The parameters MAY be specified, even if the direction attribute is recvonly.
Oパラメータ「設定」、「BPIC」、「幅」、「高さ」、「フレームレート」、「ビットレート」、「バッファ」、および「モード」は、送信されるVC-1ビットストリームのプロパティを指定して/またはマルチキャストセッションで受信しました。パラメータは、方向属性ががrecvonlyであっても、指定することができます。
The values of these parameters MUST NOT be changed by the answerer. Thus, a payload type can be either accepted unaltered or removed.
これらのパラメータの値は、回答によって変更してはいけません。したがって、ペイロードタイプは、いずれかの不変受け入れ又は除去することができます。
o The values of the parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MUST be supported by the answerer for all streams declared as sendrecv or recvonly. Otherwise, one of the following actions MUST be performed: the media format is removed or the session is rejected.
Oパラメータ「最大幅」、「最大高さ」、「MAX-フレームレート」、「最大ビットレート」、および「MAX-バッファ」の値はrecvonlyでSENDRECV又はように宣言されたすべてのストリームの回答によってサポートされなければなりません。そうでない場合は、次のいずれかの操作を実行しなければなりません：メディアフォーマットが削除されるか、セッションが拒否されます。
When VC-1 is offered over RTP using SDP in a declarative style, as in RTSP [12] or SAP [13], the following rules and limitations apply:
VC-1 [13] RTSPのように、宣言的スタイルのSDPを使用してRTPの上に[12]、またはSAPに提供される場合、以下の規則と制限が適用されます。
o The parameters "profile" and "level" indicate only the properties of the coded bit stream. They do not imply a limit on capabilities supported by the sender.
Oパラメータの「プロファイル」と「レベル」符号化ビットストリームのプロパティのみを示しています。彼らは、送信側でサポートされている機能に制限を意味するものではありません。
o The parameters "config", "width", "height", "bitrate", and "buffer" MUST be specified.
Oパラメータ「設定」、「幅」、「高さ」、「ビットレート」、および「バッファ」が指定されなければなりません。
o The parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MUST NOT be used.
Oパラメータ "最大幅"、 "最大高さ"、 "MAX-フレームレート"、 "最大ビットレート"、および "MAX-バッファ" は使用してはいけません。
An example of media representation in SDP is as follows (Simple profile, Medium level):
（シンプルプロファイル、中レベル）を以下のようにSDP内のメディア表現の例です。
m=video 49170 RTP/AVP 98 a=rtpmap:98 vc1/90000 a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000; bitrate=384000;buffer=2000;config=4e291800
M =ビデオ49170 RTP / AVP 98 = rtpmap：98 VC1 / 90000 =のfmtp：98プロファイル= 0、レベル= 2;幅= 352;高さ= 288、フレームレート= 15000。ビットレート= 384000;バッファー= 2000;コンフィグ= 4e291800
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [4], and in any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption; for example, through the application of SRTP [11].
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[4]で説明したセキュリティ問題を受けることがあり、そして任意の適切なRTPプロファイルです。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。例えば、[11] SRTPのアプリケーションを介して。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological RTP packets into the stream that are complex to decode and that cause the receiver to be overloaded. VC-1 is particularly vulnerable to such attacks, because it is possible for an attacker to generate RTP packets containing frames that affect the decoding process of many future frames. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; for example, with SRTP [11].
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を使用してデータ・エンコーディングのために存在します。攻撃者が復号化する複雑であり、それは、受信機が過負荷させるストリームに病理学的なRTPパケットを注入することができます。 VC-1攻撃者が多くの将来のフレームの復号化処理に影響を与えるフレームを含むRTPパケットを生成することが可能であるので、そのような攻撃に対して特に脆弱です。したがって、少なくともRTPパケットのデータ発信元認証とデータ完全性保護の使用が推奨されます。例えば、SRTP [11]を有します。
Note that the appropriate mechanism to ensure confidentiality and integrity of RTP packets and their payloads is dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
RTPパケットとそのペイロードの機密性と完全性を確保するための適切なメカニズムは、アプリケーション上および使用する輸送とシグナリングプロトコルに依存していることに注意してください。 SRTPは、上記の例のように与えられているがこのように、他の可能な選択肢が存在します。
VC-1 bit streams can carry user-data, such as closed captioning information and content meta-data. The VC-1 specification does not define how to interpret user-data. Identifiers for user-data are required to be registered with SMPTE. It is conceivable for types of user-data to be defined to include programmatic content, such as scripts or commands that would be executed by the receiver. Depending on the type of user-data, it might be possible for a sender to generate user-data in a non-compliant manner to crash the receiver or make it temporarily unavailable. Senders that transport VC-1 bit streams SHOULD ensure that the user-data is compliant with the specification registered with SMPTE (see Annex F of [1].) Receivers SHOULD prevent malfunction in case of non-compliant user-data.
VC-1ビットストリームは、クローズド・キャプション情報及びコンテンツメタデータなどのユーザデータを運ぶことができます。 VC-1仕様では、ユーザデータを解釈する方法を定義していません。ユーザデータのための識別子は、SMPTEに登録される必要があります。これは、受信機によって実行されるようなスクリプトやコマンドなどのプログラムコンテンツを含むように定義されるべきユーザデータの種類が考えられます。送信者が受信機をクラッシュさせたり、それが一時的に使用不可にするために非準拠した方法でユーザデータを生成するためのユーザデータの種類に応じて、それは可能かもしれません。トランスポートVC-1ビットストリームは、ユーザデータがSMPTEに登録された仕様に準拠していることを保証しなければならないことを送信者（[1]の付録Fを参照。）レシーバは、非準拠のユーザデータの場合に誤動作を防止すべきです。
It is important to note that VC-1 streams can have very high bandwidth requirements (up to 135 Mbps for high-definition video). This causes a potential for denial-of-service if transmitted onto many Internet paths. Therefore, users of this payload format MUST comply with the congestion control requirements described in section 8.
VC-1のストリームは非常に高い帯域幅要件を持つことができることに注意してください（最大135 Mbpsの高精細ビデオのために）することが重要です。多くのインターネットの経路上に送信場合、これはサービス拒否の可能性を引き起こします。したがって、このペイロード形式のユーザは、セクション8に記載の輻輳制御要件を遵守しなければなりません。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3], and with any applicable RTP profile; e.g., RFC 3551 [15].
RTPのための輻輳制御[3]、及び該当RTPプロファイルにRFC 3550に従って使用しなければなりません。例えば、RFC 3551 [15]。
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 by arranging for a receiver to leave the session if the loss rate is unacceptably high.
ベストエフォート型のサービスが使用されている場合は、このペイロード形式のユーザーは、パケット損失率が許容パラメータの範囲内であることを保証するために、パケット損失を監視する必要があります。 TCPの同じネットワーク・パスを横切る流れと同じネットワーク条件を経験するが、合理的なタイムスケールで測定した平均スループットを達成する場合は、パケット損失が許容されると考えられる、すなわち、RTPフローが達成さ以上です。この条件は、伝送レートを適応させる輻輳制御メカニズムを実装することにより、または損失率が許容できないほど高い場合にセッションを終了するための受信機のために配置することによって満たすことができます。
The bit rate adaptation necessary for obeying the congestion control principle is easily achievable when real-time encoding is used. When pre-encoded content is being transmitted, bandwidth adaptation requires one or more of the following:
リアルタイム符号化が使用される場合、輻輳制御の原理に従うために必要なビットレート適合が容易に達成可能です。事前符号化されたコンテンツが送信されている場合、帯域幅適応は、以下の1つ以上を必要とします。
- The availability of more than one coded representation of the same content at different bit rates. The switching between the different representations can normally be performed in the same RTP session by switching streams at random access point boundaries.
- 異なるビットレートで同じコンテンツの複数の符号化表現の可用性。異なる表現間の切り替えが正常にランダムアクセスポイント境界でストリームを切り替えることにより、同一のRTPセッションで行うことができます。
- The existence of non-reference frames (e.g., B-frames) in the bit stream. Non-reference frames can be discarded by the transmitter prior to encapsulation in RTP.
- ビットストリームにおける非基準フレーム（例えば、Bフレーム）が存在します。非基準フレームは、RTPにカプセル化前に送信機によって廃棄することができます。
Only when non-downgradable parameters (such as the VC-1 "profile" parameter) are required to be changed does it become necessary to terminate and re-start the media stream. This may be accomplished by using a different RTP payload type.
（例えば、VC-1「プロファイル」パラメータのような）非ダウングレードパラメータは変更する必要がある場合にのみ、メディアストリームを終了し、再起動することが必要になるん。これは、異なるRTPペイロードタイプを使用することによって達成することができます。
Regardless of the method used for bandwidth adaptation, the resulting bit stream MUST be compliant with the VC-1 specification [1]. For example, if non-reference frames are discarded, then the FRMCNT syntax element (Simple and Main profile frames only) and the optional TFCNTR syntax element (Advanced profile frames only) must increment as if no frames had been discarded. Because the TFCNTR syntax element counts the frames in the display order, which is different from the order in which they are transmitted (the coded order), it will require the transmitter to "look ahead" or buffer some number of frames.
かかわらず、帯域幅適応のために使用される方法の、結果として得られるビットストリームは、VC-1仕様[1]に準拠しなければなりません。非基準フレームが破棄された場合、その後、FRMCNT構文要素（シンプルでメインプロファイルフレームのみ）とオプションのTFCNTR構文要素（唯一の高度なプロファイルフレームは）何のフレームが廃棄されなかったかのようにインクリメントする必要があります。 TFCNTR構文要素は、それらが送信される順序（符号化順序）と異なる表示順序でフレームをカウントしているので、それは「先読み」またはフレームの一部の数をバッファリングするために送信機が必要になります。
As another example, when switching between different representations of the same content, it may be necessary to signal a discontinuity by modifying the FRMCNT field, or if Advanced profile is used, by setting the BROKEN_LINK flag in the entry-point header to 1.
同じコンテンツの異なる表現を切り替えるときに、別の例として、または高度プロファイルが使用される場合、1エントリポイントヘッダ内broken_linkからフラグを設定することにより、FRMCNTフィールドを変更することにより、不連続性をシグナリングする必要があるかもしれません。
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.
このペイロード形式はまた、サービス品質保証を提供するネットワークで使用されてもよいです。拡張サービスが使用されている場合、受信機は、要求されたサービスが実際に配信されていることを保証するために、パケット損失を監視する必要があります。それがない場合、彼らはベストエフォート型のサービスを受けていることを前提とすべきであり、それに応じて動作します。
IANA has registered the media type "video/vc1" and the associated RTP payload format in the Media Types registry and in the RTP Payload Format MIME types registry, as specified in section 6.1.
6.1節で指定されているようIANAは、メディアタイプ「ビデオ/ VC1」とメディアタイプレジストリ内およびRTPペイロードフォーマットのMIMEタイプレジストリに関連するRTPペイロードフォーマットを登録しています。
[1] Society of Motion Picture and Television Engineers, "VC-1 Compressed Video Bitstream Format and Decoding Process", SMPTE 421M.
[1]映画テレビ技術者協会、「VC-1圧縮ビデオビットストリームフォーマットおよび復号化処理」、SMPTE 421M。
[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", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[6] Josefsson氏、S.、エド。、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 3548、2003年7月。
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[7]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[8] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[9] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan, S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera, "Windows Media Video 9: overview and applications", Signal Processing: Image Communication, Volume 19, Issue 9, October 2004.
[9]スリニヴァサン、S.、スー、P.、ホルコム、T.、Mukerjee、K.、Regunathan、SL、リン、B.、梁、J.、リー、M。、およびJ.リバス-コルベラ、 " Windows Mediaビデオ9：概要とアプリケーション」、信号処理：画像通信、19巻、9号、2004年10月。
[10] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A generalized hypothetical reference decoder for H.264/AVC", IEEE Transactions on Circuits and Systems for Video Technology, August 2003.
[10]リバス-コルベラ、J.、チョウ、P.A.、およびS.L. Regunathan、「H.264 / AVCのための一般的な仮想基準デコーダ」、ビデオ技術、2003年8月のための回路とシステムに関するIEEEトランザクション。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[11] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[12] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[13]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[15] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
Acknowledgements
謝辞
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar Regunathan, Gary Sullivan, Stephan Wenger, and Magnus Westerlund for providing detailed feedback on this document.
この文書に詳細なフィードバックを提供するためのレジスCrinon、Miska Hannuksela、コリンパーキンス、シャンカールRegunathan、ゲーリー・サリバン、ステファン・ベンゲル監督、およびマグヌスウェスターに感謝します。
Author's Address
著者のアドレス
Anders Klemets Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
それ以外の場合はKlemetsマイクロソフト株式会社1マイクロソフト道、レッドモンド、WA 98052 USA
EMail: Anders.Klemets@microsoft.com
メールアドレス：Anders.Klemets@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。