[要約] RFC 4425は、VC-1ビデオコーデックのためのRTPペイロード形式を定義しています。このRFCの目的は、VC-1ビデオデータをRTPパケットに効率的にエンコードし、ネットワーク上での転送を容易にすることです。
Network Working Group A. Klemets
Request for Comments: 4425 Microsoft
Category: Standards Track February 2006
RTP Payload Format for Video Codec 1 (VC-1)
ビデオコーデック1（VC-1）のRTPペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このメモは、ビデオコーデック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ビットストリーム形式とデコードプロセスの仕様は、Society of Motion Picture and Television Engineers（SMPTE）によってSMPTE 421Mとして公開されています[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.)
VC-1は、高解像度テレビ（HDTV）ブロードキャストおよびデジタルシネマアプリケーションへの低ビットレートインターネットストリーミングアプリケーションに適しているため、幅広い適用性があります。VC-1の全体的なパフォーマンスは、MPEG-2と比較した場合、50％以上のビットレート節約が報告されるようなものです[9]。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.
VC-1は、WMV-9コーデックがVC-1標準に準拠しているため、Windows Media Video 9（WMV-9）[9]の形で、インターネット上の映画のダウンロードとストリーミングに広く使用されています。VC-1は最近、高解像度DVD形式のHD DVDおよびBLU-RAYの必須圧縮形式として採用されました。
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を使用するアプリケーションに応じて、一部のプロファイルは他のプロファイルよりも適している場合があります。たとえば、シンプルなプロファイルは、低ビットレートのインターネットストリーミングや、低複合性デコードのみを処理できるデバイスでの再生用に設計されています。高度なプロファイルは、デジタルTV、HD DVD、HDTVなどのブロードキャストアプリケーション向けに設計されています。高度なプロファイルは、インターレースのビデオフレームと非2乗ピクセルをサポートする唯一の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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
バイピクチャー：それ自体からのみ情報を使用してコーディングされるBピクチャー。他の画像を予測するためには、バイピクチャーを使用することはできません。
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）：BITストリームの開始コードプレフィックスのエミュレーションを防ぐために、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回の瞬間から始まり、連続した線を介してフレームの下部まで続くサンプルが含まれています。インターレースビデオの場合、フレームは2つのフィールド、トップフィールド、ボトムフィールドで構成されています。これらのフィールドの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.
インターレース：フレームの交互の行が時間内に異なるインスタンスを表すフレームのプロパティ。インターレースフレームでは、フィールドの1つが最初に表示されることを意図しています。
I-picture: A picture coded using information only from itself.
i-picture：それ自体からのみ情報を使用してコーディングされた画像。
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の構文の定義されたサブセットは、それに関連する特定のコーディングツール、アルゴリズム、および構文のセットを使用しています。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.
シーケンス：一連の1つ以上の写真のコード化された表現。VC-1 Advancedプロファイルでは、シーケンスは一連の1つ以上のエントリポイントセグメントで構成され、各エントリポイントセグメントは一連の1つ以上の写真で構成され、各エントリポイントセグメントの最初の画像が提供する場所ランダムアクセス。VC-1のシンプルおよびメインプロファイルでは、各シーケンスの最初の画像はi-pictureです。
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.
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.
非二乗ピクセルやインターレース画像のサポートなど、高い圧縮効率を実現するために使用できる特定の機能は、高度なプロファイルにのみ含まれています。高度なプロファイルでサポートされる最大ビットレートは135 Mbpsであり、HDTV信号のほぼロスレスエンコードに適しています。
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つあります。プロファイルとレベルの詳細なリストについては、SMPTE 421M [1]の付録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つ以上のコード化された写真で構成されています。高度なプロファイルでは、シーケンスは1つ以上のエントリポイントセグメントで構成され、各エントリポイントセグメントは一連の1つ以上の写真で構成され、各エントリポイントセグメントの最初の画像がランダムアクセスを提供します。写真はマクロブロックに分解されます。スライスは、マクロブロックの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-Pictureはランダムアクセスポイントです。
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-picture、p-picture、スキップされた画像、バイピクチャー、またはBピクチャーとしてコード化できます。これらの用語は、このドキュメントのセクション2およびSMPTE 421Mのセクション4.12で定義されています[1]。
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の開始は、Start Code（SC）と呼ばれる識別子によってシグナル伝達されます。シーケンスレイヤーヘッダーとエントリポイントヘッダーもBDUSであるため、開始コードで簡単に識別できます。開始コードの完全なリストについては、SMPTE 421M [1]の付録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番目のバイトはStart Code Suffix（SCS）と呼ばれ、STARTコードに続くBDUのタイプを示すために使用されます。たとえば、シーケンスレイヤーヘッダー（0x0F）のSCSは、エントリポイントヘッダー（0x0E）のSCSとは異なります。STARTコードは常にバイトアラインが付けられており、ネットワークバイトの順序で送信されます。
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 Advancedプロファイルでは、シーケンスレイヤーヘッダーには、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).
シーケンスレイヤーヘッダーのパラメーターには、高度なプロファイルレベル、コード化されたフレームの最大寸法、アスペクト比、インターレース情報、フレームレート、および仮説参照デコーダーの最大31漏れバケツパラメーターセットが含まれます（HRD）。
Section 6.1 of SMPTE 421M [1] provides the formal specification of the sequence layer header.
SMPTE 421M [1]のセクション6.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ピクチャと双斑の画像ヘッダーの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.
フレームは、Coded Bit StreamにBピクチャーまたはバイピクチャーが存在する場合を除き、キャプチャされるのと同じ順序で送信されます。Bi-Pictureは特別な種類のBピクチャーであり、このセクションの残りの部分では、BピクチャーとBフレームという用語もそれぞれ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のセクション5.4に記載されています[1]。要するに、コード化されたビットストリームにBピクチャーが存在する場合、仮説的なデコーダー実装が1つの追加のデコードされたフレームをバッファリングする必要があります。IフレームまたはPフレームを受信すると、フレームはすぐにデコードできますが、次のI-Frameまたは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ピクチャーがコード化されたビットストリームに存在する場合のフレームのキャプチャ、そのコード化された順序、およびデコードされたフレームの表示順序とのタイミング関係を示しています。この図は、フレームP4の表示がフレームP7を受信するまで遅延し、フレームB2とB3がすぐに表示されることを示しています。
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
図1. Bピクチャーが存在するときのフレームの並べ替え
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は1つのアクセスユニット（AU）に相当します。アクセスユニットは、AUヘッダー（セクション5.2で定義）として定義され、次に可変長さのペイロードが続き、セクション4.1および4.2で説明されているルールと制約が記載されています。図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フレームからのデータが常に異なるAUSにあることを意味します。ただし、単一のVC-1フレームを複数のAUSで断片化する可能性があります（セクション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つのフィールドで構成されています。2つの写真はまだ同じVC-1フレームに属します。
The following rules apply to the contents of each AU payload when VC-1 Advanced profile is used:
VC-1 Advancedプロファイルを使用すると、次のルールが各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の付録Eで定義されたバイトスタッフ型のカプセル化モードを使用する必要があります[1]）。
- 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ペイロードには、複数のEBDU、たとえば、シーケンスレイヤーヘッダー、エントリポイントヘッダー、フレーム（写真）ヘッダー、フィールドヘッダー、複数のスライス、および関連するユーザーデータが含まれる場合があります。ただし、すべてのスライスとそれらの対応するマクロブロックは、同じビデオフレームに属している必要があります。
- 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ペイロードに断片化されたフレームが含まれている場合を除き、AuペイロードはEBDU境界で開始する必要があります。この場合、セクション4.2のルールが適用されます。
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）のデータがOctet境界で終了しない場合、Octetアライメントを達成するために最大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に断片化する必要があります。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ペイロードの最初の3バイトを検査することにより、AuペイロードがEBDU境界で始まるかどうかを判断できます。Auペイロードは、最初の3バイトが開始コードプレフィックスと同一である場合、EBDU境界で開始します（つまり、0x00、0x00、0x01）。
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が含まれている場合、追加のAUSを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で説明したように、その後のフレームに依存するフレームがないことを意味します。ビデオフレームが単一の画像で構成されている場合、フレームのプレゼンテーション時間は写真のプレゼンテーション時間と同じです。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-Pictureは特別な種類のBピクチャーであり、このセクションの残りの部分では、BピクチャーとBフレームという用語もそれぞれ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フレーム：デコード時間は、コード化された順序で次のフレームのデコード時間より少なくとも1つのフレーム期間を短くする必要があります。フレーム期間は、変数フレームレートのビットストリームの場合、コード化されたビットストリームで使用されるフレームレートの逆（たとえば、フレームレートが1秒あたり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は非Bフレームであるため、デコード時間は3時間単位であるI0のプレゼンテーション時間に等しくなります。したがって、i0のデコード時間は、3未満のフレーム期間を少なくとも1つのフレーム期間でなければなりません。この例では、フレーム期間は1です。その結果、i0のデコード時間は2つの時間単位として選択されます。コード化された順序P4の3番目のフレームのデコード時間は4です。これは、コード化された順序P1の前の非Bフレームのプレゼンテーション時間に等しくなければならないためです。一方、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パケットが失われた場合、DTS Deltaフィールドを使用して、失われたRTPパケットのシーケンスに基準フレームが含まれているか、Bフレームのみが含まれているかどうかを判断することができます。これは、失われたシーケンスの前に受信した最後の参照フレームのプレゼンテーション時間に対して失われたシーケンスの後に受信した最初のフレームのデコードとプレゼンテーション時間を比較することで実行できます。
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で定義されている「config」メディアタイプパラメーターで伝達されます。
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-Pictureはランダムアクセスポイントです。
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に存在し、その値はランダムアクセスポイントごとに増加します（Modulo 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は、メディアタイプのパラメーターをSDP [5]にマッピングする方法を指定し、セクション6.3ではSDPオファー/回答モデルに固有のルールを定義し、セクション6.4は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レベル、コード化されたフレームの最大サイズ、およびオプションで最大フレームレートも指定します。メディアタイプのパラメーター「レベル」、「幅」、「高さ」、および「フレームレート」は、これらのパラメーターの上限を指定します。したがって、シーケンスレイヤーヘッダーは、メディアタイプパラメーター「レベル」、「幅」、「高さ」、または「フレームレート」の値よりも低い値を指定できますが、シーケンスレイヤーヘッダーはいずれの値を超えてはなりません。これらのメディアタイプパラメーター。
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レシーバーの「ヒント」として機能します。「Mode = 1」が信号が表示され、シーケンスレイヤーヘッダーがコード化されたビットストリームに存在する場合、「config」メディアタイプパラメーターで指定されたシーケンスレイヤーヘッダーと同一でなければなりません。
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で説明されている「モード= 1」の「モード= 3」に同じルールが適用されます。さらに、「Mode = 3」が信号が表示されている場合、RTP送信者は、RTPパケットにシーケンスレイヤーヘッダーとエントリポイントヘッダーを含めないことにより、コード化されたビットストリームを「圧縮」することができます。
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.
"mode = 3"が信号を受け、RTPレシーバーが完全なauまたはauの最初のフラグメントを受信し、raビットが1に設定されているが、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ヘッダーの形式はRFC 3550 [3]で指定されており、便利なため、図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
図3. RFC 3550による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フレームをコード化された順序で配信する必要があります。RTPパケット全体でVC-1フレームが断片化されている場合、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 kHzのクロックレートを使用する必要があります。
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
図4. Auヘッダーの構造
AU Control: 8 bits The usage of the AU Control field is defined in section 5.3.
AU制御：8ビットAU制御フィールドの使用法は、セクション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カウンターです。このフィールドの値は、AU制御フィールドのRAビットが1に設定される場合にAUが送信されるたびに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 Len：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の補数オフセット（DELTA）として指定します。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.
RTPタイムスタンプフィールドは、最初のAUのフレームのプレゼンテーション時間を指定するため、このフィールドはRTPパケットの最初のAUヘッダーに含めるべきではありません。このフィールドが含まれていない場合、フレームのプレゼンテーション時間は、RTPヘッダーのタイムスタンプフィールドによって指定されると想定されます。
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の補数オフセット（Delta）として指定します。プレゼンテーション時間がデコード時間よりも大きい場合、これによりゼロより大きいDTSデルタフィールドの値が得られることに注意してください。DTSデルタフィールドは、RTPヘッダーのタイムスタンプフィールドと同じクロックレートを使用する必要があります。このフィールドが含まれていない場合、フレームのデコード時間は、フレームのプレゼンテーション時間と同一であると想定されます。
The structure of the 8-bit AU Control field is shown in Figure 5.
8ビットAU制御フィールドの構造を図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:
フラグ：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-Pictureはランダムアクセスポイントです。
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ビットシーケンスレイヤーカウンター。このビットを切り替える必要があります。つまり、AUにシーケンスレイヤーヘッダーが含まれている場合、最近送信されたシーケンスレイヤーヘッダーとは異なる場合、0から1または1から0に変更する必要があります。それ以外の場合、このビットの値は、前の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 Deltaが存在します。AUヘッダーにPTS Deltaフィールドが含まれている場合、このビットは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 Deltaフィールドが含まれている場合、このビットは1に設定する必要があります。
R: 1 bit Reserved. This bit MUST be set to 0 and MUST be ignored by receivers.
R：1ビット予約。このビットは0に設定する必要があり、受信機は無視する必要があります。
This registration uses the template defined in RFC 4288 [7] and follows RFC 3555 [8].
この登録は、RFC 4288 [7]で定義されたテンプレートを使用し、RFC 3555 [8]に従います。
Type name: video
タイプ名：ビデオ
Subtype name: vc1 Required parameters:
サブタイプ名：VC1必要パラメーター：
profile: The value is an integer identifying the VC-1 profile. The following values are defined:
プロファイル：値は、VC-1プロファイルを識別する整数です。次の値が定義されています。
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:
高度なプロファイルの場合、有効な値は0〜4であり、これはそれぞれL0からL4レベルに対応します。シンプルでメインのプロファイルの場合、次の値が定義されています。
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.
config：値は、デコーダー初期化パラメーターを表すオクテット文字列のbase16 [6]（16進数）表現です。デコーダーの初期化パラメーターは、MSB-FirstベースでBase16 Octet Stringにマッピングされます。デコーダー初期化パラメーターの最初のビットは、最初のオクテットのMSBに配置する必要があります。デコーダーの初期化パラメーターが8ビットの倍数ではない場合、Octetアライメントを実現するには、最後のOctetに最大7つのゼロ値パディングビットを追加する必要があります。
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で定義されたカプセル化方法を使用する必要があります。
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).
幅：値はゼロより大きい整数であり、Lumaサンプル（Luma画像のピクセル）のコード化されたフレームの最大水平サイズを指定します。
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.
Bitrate：値はゼロより大きい整数であり、コード化されたビットストリームのピーク伝送速度が1秒あたりビットで指定されています。この数には、RTPカプセル化によって引き起こされるオーバーヘッドは含まれていません。つまり、AUヘッダー、またはRTP、UDP、またはIPヘッダーのいずれも含まれません。
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をミリ秒単位で指定する整数です。このパラメーターは、VC-1の仮説参照デコーダーモデル、SMPTE 421Mの付録Cで定義されています[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の付録Dの「BMAX」と「RMAX」の値を参照してください[1]。
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.
フレームレート：値はゼロより大きい整数であり、コード化されたビットストリームで1秒あたりの最大フレーム数を指定し、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と双斑の存在が存在する可能性があることを示しています。このパラメーターが存在し、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ビットストリームにbとbiのピクチャが存在しないことを示します。bピクチャーもバイピクチャーもコード化されたビットストリームに含まれていない場合、値を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.
このパラメーターは、シンプルでメインのプロファイルで使用してはなりません。メインプロファイルの場合、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：configパラメーターで指定されたシーケンスレイヤーヘッダーとエントリポイントヘッダーは変更されません。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-Width、Max-Height、Max-Bitrate、Max-Buffer、Max-Framerate：これらのパラメーターは、機能交換手順で使用するために定義されています。パラメーターは、コード化されたビットストリームのプロパティを信号するのではなく、「幅」、「高さ」、「ビットレート」、「バッファ」、および「フレームレート」パラメーターの上限または優先値を示します。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個のLumaサンプルの幅と288個のLumaサンプルの高さをサポートする必要があります。
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.
最大幅：値はゼロより大きい整数であり、コード化されたフレームの水平サイズをLUMAサンプル（LUMA画像のピクセル）に指定します。値がプロファイルとレベルで許可される最大水平サイズよりも少ない場合、値は優先される水平サイズを指定します。それ以外の場合は、サポートされている最大水平サイズを指定します。
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.
Max-Height：値はゼロより大きい整数であり、コード化されたフレームの垂直サイズを指定して、Lumaサンプル（徐々にコード化されたLuma画像のピクセル）です。値がプロファイルとレベルで許可される最大垂直サイズよりも少ない場合、値は優先される垂直サイズを指定します。それ以外の場合は、サポートされている最大垂直サイズを指定します。
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.
Max-Bitrate：値はゼロより大きい整数であり、コード化されたビットストリームのピーク伝送速度が1秒あたりビットで指定されています。この数には、RTPカプセル化によって引き起こされるオーバーヘッドは含まれていません。つまり、AUヘッダー、またはRTP、UDP、またはIPヘッダーのいずれも含まれません。
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-BUFFER：値は、漏れやすいバケツサイズB、Millisecondsで指定された整数であり、Max-Bitrateパラメーターによって指定された伝送速度で送信されるストリームを含めるために必要です。このパラメーターは、VC-1の仮説参照デコーダーモデル、SMPTE 421Mの付録Cで定義されています[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の付録Dの「BMAX」と「RMAX」の値を参照してください[1]。
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-FRAMERATE：値はゼロより大きい整数であり、コード化されたビットストリームの1秒あたりの複数のフレームを指定します。値は、フレームレートに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.
詳細については、個人とメールアドレスをお問い合わせください：Anders klemets <anderskl@microsoft.com> ietf AVTワーキンググループ。
Intended Usage: 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
著者：Anders Klemets
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：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 SDPの「m =」行のメディア名は、ビデオ（タイプ名）でなければなりません。
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.
o オプションのパラメーター "config"、 "width"、 "height"、 "bitrate"、 "buffer"、 "framerate"、 "bpic"、 "mode"、 "max-width"、 "max-height"、 "max-Bitrate "、" max-buffer "、および" max-framerate "が存在する場合は、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>]
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:
ユニキャスト使用に関する交渉のために、オファー/回答モデル[5]でSDPを使用してRTPを介してVC-1が提供される場合、次の規則と制限が適用されます。
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方向属性を指定し、回答がレベルパラメーターを格下げする場合、更新された「構成」パラメーターを指定するための新しいオファーが必要になる場合があります。「config」パラメーターを回答で指定されたレベルで使用できない場合、オファーは別のオファー/回答ラウンドを開始するか、メディア形式（ペイロードタイプ）を使用しない必要があります。
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 パラメーター「config」、「bpic」、「width」、「height」、「framerate」、「bitRate」、「バッファ」、および「モード」は、提供者または応答者が提供する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.
ユニキャストの使用の場合、およびオファーまたは回答の方向属性属性が登録されている場合、これらのパラメーターの解釈は未定義であり、使用してはなりません。
o The parameters "config", "width", "height", "bitrate", and "buffer" MUST be specified when the direction attribute is sendrecv or sendonly.
o 方向属性がsendrecvまたはsendonlyである場合、パラメーター「config」、「width」、「height」、「bitrate」、および "バッファー]を指定する必要があります。
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 パラメーター「最大幅」、「最大高さ」、「最大泡立」、「マックスビトレート」、および「マックスバッファ」は、申し出または回答で指定され、その解釈は次のとおりです。
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プロファイルのレベルで許可されているものよりも大きい場合、受信者が指定されたプロファイルとレベルで受け入れる値の上限として、およびより低いレベルで解釈されるものとします。同じプロファイルの。
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オファーが「プロファイル= 0; level = 1; max-bitrate = 48000」を指定する場合、48 kbpsは単純なプロファイルのすべてのレシーバー実装、低レベルの実装が必要であるため、推奨されるビットレートにすぎません。最大96 kbpsのビットレートをサポートします。オファーが受け入れられていると仮定すると、回答者は回答で「Bitrate = 48000」を指定する必要がありますが、96000までの価値は許可されています。ただし、オファーが「Max-Bitrate = 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 パラメーター "config"、 "bpic"、 "width"、 "height"、 "framerate"、 "bitrate"、 "buffer"、 "Mode"は、送信されるVC-1ビットストリームのプロパティを指定します。またはマルチキャストセッションで受信しました。方向属性がcvonlyであっても、パラメーターを指定することができます。
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-Width」、「Max-Height」、「Max-Framerate」、「Max-Bitrate」、および「Max-Buffer」は、SendRecvまたはRecvonlyとして宣言されたすべてのストリームの回答者によってサポートする必要があります。それ以外の場合、次のアクションのいずれかを実行する必要があります。メディア形式が削除されるか、セッションが拒否されます。
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:
RTSP [12]またはSAP [13]のように、宣言スタイルでSDPを使用してRTPを介してVC-1が提供される場合、次の規則と制限が適用されます。
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 パラメーター「config」、「width」、「height」、「bitrate」、および「バッファ」を指定する必要があります。
o The parameters "max-width", "max-height", "max-framerate", "max-bitrate", and "max-buffer" MUST NOT be used.
o パラメーター「Max-Width」、「Max-Height」、「Max-Framerate」、「Max-Bitrate」、および「Max-Buffer」を使用しないでください。
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
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プロファイルで説明されているセキュリティに関する考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。たとえば、SRTPの適用を通じて[11]。
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の混雑制御は、RFC 3550 [3]に従って、および該当するRTPプロファイルに従って使用するものとします。たとえば、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.
Best-Effortサービスが使用されている場合、このペイロード形式のユーザーは、パケットの損失を監視して、パケットの損失率が許容可能なパラメーター内にあることを確認する必要があります。同じネットワークパスを横切るTCPフローが同じネットワーク条件を経験すると、合理的なタイムスケールで測定された平均的なスループットが得られる場合、パケットの損失は許容されると見なされます。この条件は、輸送速度を適応させるための輻輳制御メカニズムを実装するか、損失率が容認できないほど高い場合にセッションを去るように配置することにより、満たすことができます。
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.
別の例として、同じコンテンツの異なる表現を切り替える場合、FRMCNTフィールドを変更することにより、または高度なプロファイルが使用されている場合、Entry-Point Headerのbroken_Linkフラグを1に設定することにより、不連続性を通知する必要がある場合があります。
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.
IANAは、セクション6.1で指定されているように、メディアタイプレジストリおよびRTPペイロード形式のMIMEタイプレジストリにメディアタイプ「ビデオ/VC1」と関連するRTPペイロード形式を登録しました。
[1] Society of Motion Picture and Television Engineers, "VC-1 Compressed Video Bitstream Format and Decoding Process", SMPTE 421M.
[1] Society of Motion Picture and Television Engineers、「VC-1圧縮ビデオビットストリーム形式とデコードプロセス」、SMPTE 421M。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley、M。and 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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[6] Josefsson、S.、ed。、「The Base16、Base32、およびBase64 Data Encodings」、RFC 3548、2003年7月。
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Freed、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] Srinivasan、S.、Hsu、P.、Holcomb、T.、Mukerjee、K.、Regunathan、S.L.、Lin、B.、Liang、J.、Lee、M。、およびJ. Ribas-Corbera、 "Windows Media Video9：概要とアプリケーション」、信号処理：画像通信、第19巻、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] Ribas-Corbera、J.、Chou、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.、McGrew、D.、Naslund、M.、Carrara、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.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[13] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、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.
レジス・クリノン、ミスカ・ハヌクセラ、コリン・パーキンス、シャンカール・レジュナサン、ゲイリー・サリバン、ステファン・ウェンガー、マグナス・ウェスターランドに感謝します。
Author's Address
著者の連絡先
Anders Klemets Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Anders Klemets Microsoft Corp. 1 Microsoft Way Redmond、WA 98052 USA
EMail: Anders.Klemets@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。