RFC4425 日本語訳
4425 RTP Payload Format for Video Codec 1 (VC-1). A. Klemets. February 2006. (Format: TXT=84335 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Klemets Request for Comments: 4425 Microsoft Category: Standards Track February 2006
Klemetsがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4425年のマイクロソフトカテゴリ: 標準化過程2006年2月
RTP Payload Format for Video Codec 1 (VC-1)
ビデオコーデック1のためのRTP有効搭載量形式(VC-1)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television.
このメモはVideo Codec1(VC-1)の圧縮されたビットストリームを要約するのにRTPペイロード形式を指定します、映画テレビ技術者協会(SMPTE)規格、SMPTEによって421M定義されるように。 SMPTEは動きイメージ産業でボディーを標準化するメインです、そして、SMPTEの421Mの規格はテレビのために圧縮されたビデオビットストリーム形式と解読過程を定義します。
Klemets Standards Track [Page 1] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[1ページ]RFC4425RTP有効搭載量形式
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
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. 定義と略語…3 3. VC-1の概観…5 3.1. VC-1ビットストリームレイヤリングモデル…6 3.2. 高度なプロフィールのビットストリームデータ単位…7 3.3. デコーダ初期設定パラメタ…7 3.4. フレームを注文します…8 4. RTPのVC-1形式ビットストリームのカプセル化…9 4.1. ユニットにアクセスしてください…9 4.2. VC-1フレームの断片化…10 4.3. タイムスタンプ問題…11 4.4. ランダムアクセスは指します…13 4.5. HRDパラメタの取り外し…14 4.6. 系列を繰り返して、ヘッダーを層にしてください…14 4.7. メディアのシグナリングはパラメタをタイプします…15 4.8. 「モード=1インチのメディア型引数」…16 4.9. 「モード=3インチのメディア型引数」…16 5. RTP有効搭載量形式構文…17 5.1. RTPヘッダー用法…17 5.2. Auヘッダー構文…18 5.3. Au制御フィールド構文…19 6. RTP有効搭載量形式パラメタ…20 6.1. メディアはRegistrationをタイプします…20 6.2. SDPへのメディア型引数に関するマッピング…28 6.3. SDP申し出/答えモデルがある用法…29 6.4. 叙述的なセッション記述における用法…31 7. セキュリティ問題…32 8. 混雑コントロール…33 9. IANA問題…34 10. 参照…34 10.1. 標準の参照…34 10.2. 有益な参照…35
1. Introduction
1. 序論
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として知られている標準のVideo Codec1をコード化するビデオにRTPペイロード形式を指定します。 VC-1ビットストリーム形式と解読過程のための仕様はSMPTE421M[1]として映画テレビ技術者協会(SMPTE)によって発表されます。
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
VC-1には、広い適用性があります、それがほとんどlosslessコード化によってHigh Definition Television(HDTV)放送とDigitalシネマアプリケーションへの低いビット伝送速度インターネットストリーミング・アプリケーションに適しているので。 VC-1の総合的な性能はそのビット伝送速度にそのようなものです。
Klemets Standards Track [Page 2] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[2ページ]RFC4425RTP有効搭載量形式
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.)
[9] MPEG-2と比べると、50%以上の節約は報告されます。 VC-1がさらに詳しい明細についてはどうMPEG-4やH.264/AVCなどの他のコーデックと比較するかに関して[9]を見てください。 (VC-9、[9]では、VC-1は以前の名前によって言及されます。)
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はインターネットに関するダウンロードとストリーミングの映画に広く使用されます、WindowsメディアVideo9(WMV-9)[9]の形で、WMV-9コーデックがVC-1規格で言いなりになるので。 また、ハイデフィニッションDVDのための義務的な圧縮形式がHD DVDとBlu-光線をフォーマットするとき、VC-1は最近、採用されました。
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.
SMPTE421MはVC-1ビットストリーム構文を定義して、VC-1 conformantビットストリームで迎えなければならない規制を指定します。また、SMPTE421Mはビットストリームを解読するのに必要である完全な過程を指定します。 しかしながら、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が使用されているアプリケーションによって、いくつかのプロフィールが他のものより適当であるかもしれません。 例えば、Simpleプロフィールは低いビット伝送速度インターネットストリーミングと低複雑さ解読を扱うことができるだけである装置の上の再生のために設計されています。 高度なプロフィールはデジタルテレビ、HD DVD、またはHDTVなどの全面散布のために設計されています。 高度なプロフィールは交錯しているビデオフレームと非正方形の画素を支える唯一のVC-1プロフィールです。
Section 2 defines the abbreviations used in this document. Section 3 provides a more detailed overview of VC-1. Sections 4 and 5 define the RTP payload format for VC-1, and section 6 defines the media type and SDP parameters for VC-1. See section 7 for security considerations, and section 8 for congestion control requirements.
セクション2は本書では使用される略語を定義します。 セクション3はVC-1の、より詳細な概観を提供します。 セクション4と5はVC-1のためにRTPペイロード書式を定義します、そして、セクション6はVC-1のためのメディアタイプとSDPパラメタを定義します。 セキュリティ問題に関してセクション7を見て、輻輳制御要件のためにセクション8を見てください。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Definitions and Abbreviations
2. 定義と略語
This document uses the definitions in SMPTE 421M [1]. For convenience, the following terms from SMPTE 421M are restated here:
このドキュメントはSMPTE421M[1]との定義を使用します。 便利において、SMPTE421Mからの次の用語はここで言い直されます:
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-絵を使用できません。
Klemets Standards Track [Page 3] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[3ページ]RFC4425RTP有効搭載量形式
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-絵。 いかなる他の絵も予測するのにBI-絵を使用できません。
Bit-stream data unit (BDU):
A unit of the compressed data which may be parsed (i.e., syntax
decoded) independently of other information at the same
hierarchical level. A BDU can be, for example, a sequence
layer header, an entry-point header, a frame, or a slice.
ビットストリームデータ単位(BDU): 同じ階層レベルにおける他の情報の如何にかかわらず分析されるかもしれない(すなわち、構文は解読しました)圧縮されたデータのユニット。 例えば、BDUは系列層のヘッダー、エントリー・ポイントヘッダー、フレーム、または部分であるかもしれません。
Encapsulated BDU (EBDU):
A BDU that has been encapsulated using the encapsulation
mechanism described in Annex E of SMPTE 421M [1], to prevent
emulation of the start code prefix in the bit stream.
要約のBDU(EBDU): カプセル化メカニズムを使用することで要約されたBDUは、ビットストリームのスタートコード接頭語のエミュレーションを防ぐためにSMPTEのAnnex Eで421M[1]について説明しました。
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.
以下を縁どってください。 フレームはビデオ信号の空間的な情報の線を含んでいます。 進歩的なビデオに関しては、これらの線は連続した線を通してフレームの下部に、ある時間瞬間に始まって、続くサンプルを含んでいます。 交錯しているビデオに関しては、フレームは2つの分野、先頭の分野、およびボトムフィールドから成ります。 これらの分野の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-絵: 絵は単にそれ自体からの使用情報をコード化しました。
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-絵: 動きを使用することでコード化される絵は過去の参照分野かフレームから予測を代償しました。
Klemets Standards Track [Page 4] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[4ページ]RFC4425RTP有効搭載量形式
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 SimpleとMainプロフィールでは、各系列における最初の絵はI-絵です。
slice:
A consecutive series of macroblock rows in a picture, which are
encoded as a single unit.
以下を切ってください。 絵の連続したシリーズのmacroblock列。(その列は単一の単位としてコード化されます)。
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).
コード(サウスカロライナ)を開始させてください: コード化されたビットストリームに埋め込まれていて、BDUの始まりを特定するユニークな32ビットのコード。 スタートコードはユニークな3バイトのStart Code Prefix(SCP)、および1バイトのStart Code Suffix(SCS)から成ります。
3. Overview of VC-1
3. VC-1の概観
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
VC-1ビットストリーム構文は3個のプロフィールから成ります: 簡単で、主で、高度です。 簡単なプロフィールは低ビット伝送速度と低い複雑さアプリケーションのために設計されています、携帯情報端末の上のメディアの再生などのように。 Simpleプロフィールによって支持された最大のビット伝送速度
Klemets Standards Track [Page 5] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[5ページ]RFC4425RTP有効搭載量形式
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.
384キロビット毎秒はそうですか? 主なプロフィールは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.
高い圧縮効率を達成するのに使用できる交錯している絵の非正方形画素やサポートなどのある特徴はAdvancedプロフィールに含まれているだけです。 Advancedプロフィールによって支持された最大のビット伝送速度は135Mbpsです、それをほとんど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.
Advancedだけが圧縮されたビットストリームによるバンドの利用者データ(メタデータ)を運ぶサポートの輪郭を描きます。 例えば、閉じているキャプションサポートに利用者データを使用できます。
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個のプロフィールでは、Advancedプロフィールだけで、コーデック設定パラメータ、絵のアスペクトレシオとしてのそのようなものは圧縮されたビットストリームのバンドにおけるシグナリングを通して変化します。
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.
それぞれのプロフィールに関しては、ある数の「レベル」が定義されました。 「プロフィール」と異なって、「レベル」はプロフィールのパラメタの値における1セットの規制です、ビット伝送速度やバッファサイズのように。」はあるセットの特徴か構文要素を含意します。 VC-1 Simpleプロフィールには、2つのレベルがあります、そして、Mainプロフィールには、3があります、そして、Advancedプロフィールには、5があります。 プロフィールとレベルの詳細なリストに関してSMPTEのAnnex Dを421M[1]見てください。
3.1. VC-1 Bit Stream Layering Model
3.1. VC-1ビットストリームレイヤリングモデル
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ビットストリームは層の階層構造と定義されます。 これは概念的にネットワーク・プロトコルのプロトコル・スタックの概念と同様です。 最外の層は系列層と呼ばれます。 他の層は、エントリー・ポイントと、絵と、部分と、macroblockと、ブロックです。
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.
SimpleとMainプロフィールでは、系列層の系列は一連の1かさらにコード化された絵から成ります。 Advancedプロフィールでは、系列は1エントリー・ポイント以上のセグメントから成ります、それぞれのエントリー・ポイントセグメントが一連の1枚以上の絵から成って、それぞれのエントリー・ポイントセグメントにおける最初の絵がランダムアクセスを提供するところで。 絵はmacroblocksに分解されます。 部分はmacroblocksの1つ以上の隣接の列を包括します。
The entry-point and slice layers are only present in Advanced profile. In Advanced profile, the start of each entry-point layer segment indicates a random access point. In Simple and Main profiles, each I-picture is a random access point.
エントリー・ポイントと部分層は単にAdvancedプロフィールに存在しています。 Advancedプロフィールでは、それぞれのエントリー・ポイント層のセグメントの始まりはランダムアクセスポイントを示します。 SimpleとMainプロフィールでは、各I-絵はランダムアクセスポイントです。
Klemets Standards Track [Page 6] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[6ページ]RFC4425RTP有効搭載量形式
Each picture can be coded as an I-picture, P-picture, skipped picture, BI-picture, or as a B-picture. These terms are defined in section 2 of this document and in section 4.12 of SMPTE 421M [1].
I-絵、P-絵、スキップされた絵、BI絵として、または、B-絵として各絵をコード化できます。 これらの用語はこのドキュメントのセクション2とSMPTE421M[1]のセクション4.12で定義されます。
3.2. Bit-stream Data Units in Advanced Profile
3.2. 高度なプロフィールのビットストリームデータ単位
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.
Advancedプロフィールでは、各絵と部分はBit流れのData Unit(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(サウスカロライナ)と呼ばれる識別子によって合図されます。 系列層のヘッダーとエントリー・ポイントヘッダーを、また、BDUsであり、その結果、彼らのStart Codesは容易に特定できます。 Start Codesの全リストに関してSMPTEのAnnex Eを421M[1]見てください。 ブロックとmacroblocksはBDUsでなく、その結果、Start Codeを持たないで、必ずバイトによって並べられるというわけではありません。
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.
Start Codeは4バイトから成ります。 最初の3バイトは、0×00と、0×00と0×01です。 4番目のバイトはStart Code Suffix(SCS)と呼ばれます、そして、それは、Start Codeに続くBDUのタイプを示すのに使用されます。 例えば、系列ヘッダー(0x0F)層のSCSはエントリー・ポイントヘッダー(0x0E)のSCSと異なっています。 Start Codeはいつもバイトによって並べられて、ネットワークバイトオーダーで伝えられます。
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でStart Codeの偶然のエミュレーションを防ぐために、421Mはバイト詰め物を使用するカプセル化メカニズムを定義します。 このメカニズムによって要約されたBDUはEncapsulated BDU、またはEBDUと呼ばれます。
3.3. Decoder Initialization Parameters
3.3. デコーダ初期設定パラメタ
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).
系列層のヘッダーのパラメタはHypothetical Reference DecoderのためのAdvancedプロフィールレベル、コード化されたフレームの最大の寸法、アスペクトレシオ、インターレース情報、フレームレート、および最大31の水漏れするバケツパラメタセット(HRD)を含んでいます。
Section 6.1 of SMPTE 421M [1] provides the formal specification of the sequence layer header.
セクション6.1 SMPTE421では、M[1]は系列層のヘッダーに関する形式仕様を提供します。
Klemets Standards Track [Page 7] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[7ページ]RFC4425RTP有効搭載量形式
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 SimpleとMainプロフィールのために定義されません。 これらのプロフィールに関しては、デコーダ初期化パラメタをバンドの外に伝えなければなりません。 Simpleのためのデコーダ初期化パラメタとMainプロフィールはコード化されたフレームの最大の寸法を含んでいます、そして、水漏れするバケツパラメタは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].
SMPTE421M[1]の別館Cは仮定している参照デコーダの使用法をVC-1ビットストリームに指定します。[10]でHRDの理論の概説に当たることができます。
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.
SimpleとMainプロフィールに関しては、I-絵とBI-絵の絵のヘッダーでBF構文要素を使用することでHRD水漏れするバケツのための現在のバッファ充満価値は合図されます。
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.
Advancedプロフィールとして、エントリー・ポイントヘッダーは現在のバッファ充満値をHRDの水漏れするバケツに指定します。 また、エントリー・ポイントヘッダーはビットストリームにおける、次のエントリー・ポイントヘッダーの発生まで有効なコード化管理パラメータを指定します。 エントリー・ポイント層の概念はVC-1 Advancedプロフィールだけに適用されます。 エントリー・ポイントヘッダーの形式仕様に関してSMPTEのセクション6.2を421M[1]見てください。
3.4. Ordering of Frames
3.4. フレームの注文
Frames are transmitted in the same order in which they are captured, except if B-pictures or BI-pictures are present in the coded bit stream. A BI-picture is a special kind of B-picture, and in the remainder of this section the terms B-picture and B-frame also apply to BI-pictures and BI-frames, respectively.
フレームがB-絵であるのを除いて、それらが捕らえられる同次で伝えられるか、またはBI-絵はコード化されたビットストリームで存在しています。 BI-絵は特別な種類のB-絵です、そして、また、このセクションの残りでは、用語のB-絵とBフレームはそれぞれBI-絵とBI-フレームに適用されます。
When B-pictures are present in the coded bit stream, the frames are transmitted such that the frames that the B-pictures depend on are transmitted first. This is referred to as the coded order of the frames.
B-絵がコード化されたビットストリームで存在しているとき、フレームが伝えられるので、B-絵がよるフレームは最初に、伝えられます。 これはフレームのコード化された注文と呼ばれます。
Klemets Standards Track [Page 8] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[8ページ]RFC4425RTP有効搭載量形式
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.
デコーダがコード化されたオーダーから表示命令までどうフレームを変換するか規則はSMPTE421M[1]のセクション5.4で述べられています。 要するに、B-絵がコード化されたビットストリームで存在しているかもしれないなら、仮定しているデコーダ実現は、1個の追加解読されたフレームをバッファリングする必要があります。 I-フレームかPフレームがすぐに受け取られているとき、フレームを解読できますが、次のIかPフレームが受け取られているまで、それは表示されません。 しかしながら、すぐに、Bフレームを表示します。
Figure 1 illustrates the timing relationship between the capture of frames, their coded order, and the display order of the decoded frames, when B-pictures are present in the coded bit stream. The figure shows that the display of frame P4 is delayed until frame P7 is received, while frames B2 and B3 are displayed immediately.
図1はフレームの捕獲と、彼らのコード化された注文と、解読されたフレームの表示命令とのタイミング関係を例証します、B-絵がコード化されたビットストリームで存在しているとき。 図は、フレームP7が受け取られているまでフレームP4の表示が遅れるのを示します、すぐに、フレームの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
以下を捕らえてください。 |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9… | コード化されたオーダー: | I0 P1 P4 B2 B3 P7 B5 B6… | オーダーを表示してください: | I0 P1 B2 B3 P4 B5 B6… | |+---+---+---+---+---+---+---+---+---+-->時間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に示された追加遅れなしでフレームを表示できます。
4. Encapsulation of VC-1 Format Bit Streams in RTP
4. RTPのVC-1形式ビットストリームのカプセル化
4.1. Access Units
4.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パケットは整数のアプリケーションデータ単位(ADUs)を含んでいます。 VC-1形式ビットストリームにおいて、ADUは1Access Unit(AU)に同等です。 可変長ペイロードに応じてAUヘッダー(セクション5.2で、定義される)が後をつけた規則と規制についてセクション4.1と4.2で説明されている状態で、Access Unitは定義されます。 図2は複数のAUsとのRTPパケットのレイアウトを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| RTP | AU(1) | AU(2) | | AU(n) |
| Header | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+ | RTP| Au(1)| Au(2)| | Au(n)| | ヘッダー| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 2. RTP packet structure
図2。 RTPパケット構造
Klemets Standards Track [Page 9] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[9ページ]RFC4425RTP有効搭載量形式
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).
各Access Unitはセクション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ビットストリームデータを含まなければなりません。(すなわち、ビットストリームはカプセル化モードがSMPTE421のAnnex Eで定義したバイト詰め物のM[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ペイロードは例えば複数のEBDUs、系列層のヘッダー、エントリー・ポイントヘッダー、フレーム(絵)ヘッダー、分野ヘッダー、複数の部分、および関連利用者データを含むかもしれません。 しかしながら、すべての部分とそれらの対応するmacroblocksは同じビデオフレームに属さなければなりません。
- 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ペイロードは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 SimpleかMainプロフィールがフレームの始めに使用されているとき、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.
アクセスUnitsはバイトで並べなければなりません。 AU(SimpleとMainの場合における、Advancedプロフィールとフレームの場合におけるEBDUs)のデータが八重奏境界で終わらないなら、八重奏整列を達成するために無評価された最大7詰め物ビットを加えなければなりません。
4.2. Fragmentation of VC-1 frames
4.2. VC-1フレームの断片化
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ペイロードSHOULDは完全なVC-1フレームを含んでいます。 しかしながら、これがRTPパケットを引き起こすなら、MTUサイズ、フレームSHOULDを超えるには、IP-レベル断片化を避ける複数のAUsに断片化されてください。 AUが断片化しているフレームを含むとき、セクション5.3で定義されるようにAUヘッダーにFRAG分野をはめ込むことによって、これを示さなければなりません。
Klemets Standards Track [Page 10] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[10ページ]RFC4425RTP有効搭載量形式
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.
Advancedプロフィールが使用されているなら、断片化しているフレームを含まないか、またはフレームの最初の断片を含むAUペイロードはEBDU境界で始動しなければなりません。 この場合、SimpleとMainプロフィールに関して、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.
Advancedプロフィールが使用されているなら、最初の断片SHOULD以外のフレームの断片を含むAUペイロードがEBDU境界で始動します、1つの部分の始めなどのように。
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).
しかしながら、部分は、Advancedプロフィールのために定義されるだけであり、いつも使用されるというわけではありません。 ブロックとmacroblocksはBDUs(Start Codeを全く持っていない)でなく、またバイトによって並べられません。 したがって、EBDU境界で断片化しているフレームを続けているのはいつも可能であるかもしれないというわけではありません。 人は、AUペイロードがEBDU境界でAUペイロードの最初の3バイトを点検することによって出発するかどうか決定できます。 最初の3バイトがStart Code Prefix(すなわち、0×00、0×00、0×01)と同じであるなら、AUペイロードはEBDU境界で始動します。
In the case of Simple and Main profiles, since the blocks and macroblocks are not byte-aligned, the fragmentation boundary may be chosen arbitrarily.
SimpleとMainプロフィールの場合では、ブロックとmacroblocksがバイトによって並べられないので、断片化境界は任意に選ばれるかもしれません。
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パケットが含まれているコネがRTPパケットであったならフレームの最後の断片があるAU、追加AUs SHOULD NOTを含んでいるなら。
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デルタ分野が存在しているなら、フレームの各断片で、同じくらいは時間を解読しなければなりません。
4.3. Time Stamp Considerations
4.3. タイムスタンプ問題
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インターレースコード化モードが使用されているとき、フレームは2枚の絵、各分野あたり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パケットにおける最初のAUに含まれたビデオフレームのプレゼンテーション時間にRTPタイムスタンプ分野を設定しなければなりません。 任意定数だけでフレームの標本抽出の瞬間と異なっているのでRTPヘッダーのタイムスタンプ分野が相殺されたので、プレゼンテーション時間を使用できます。
Klemets Standards Track [Page 11] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[11ページ]RFC4425RTP有効搭載量形式
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パケットが複数のAUsを含んでいる場合にだけ、これは起こることができます。 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-絵もそうでないなら中にコード化されたビットストリームを提示してください、そしてプレゼンテーションへの同輩がフレームの時間であったならaフレームSHALLの時間を解読してください。 BI-絵は特別な種類のB-絵です、そして、また、このセクションの残りでは、用語のB-絵とBフレームはそれぞれBI-絵とBI-フレームに適用されます。
If B-pictures may be present in the coded bit stream, then the decode times of frames are determined as follows:
解読してください。B-絵がその時コード化されたビットストリームで存在しているかもしれない、フレームの倍は以下の通り断固としています:
- B-frames:
The decode time SHALL be equal to the presentation time of the
B-frame.
- Bフレーム: プレゼンテーションへの同輩がB-フレームの時間であったなら時間SHALLを解読してください。
- 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フレーム: 少なくともあるフレームの期間が、より少なかったなら時間SHALLを解読してください、コード化されたオーダーにおける、隣のフレームの時間を解読してください。 フレームの期間はコード化されたビットストリームに使用されるフレームレートの逆と定義されます(フレームが評価するなら、例えば、100ミリセカンドは1秒あたり10個のフレームです。)。 可変フレームレートがあるビットストリームのために、最大のフレームレートSHALLはフレームの期間を決定します。 最大のフレームが指定されないなら、最大のフレームレートはプロフィールとレベルでSHALLを許容しました。使用されます。
- 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フレームのプレゼンテーション時間までの同輩がコード化されたオーダーであったなら時間SHALLを解読してください。
As an example, consider Figure 1 in section 3.4. To determine the decode time of the first frame, I0, one must first determine the decode time of the next frame, P1. Because P1 is a non-B frame, its decode time is equal to the presentation time of I0, which is 3 time units. Thus, the decode time of I0 must be at least one frame period less than 3. In this example, the frame period is 1, because one frame is displayed every time unit. Consequently, the decode time of I0 is chosen as 2 time units. The decode time of the third frame in the coded order, P4, is 4, because it must be equal to the presentation time of the previous non-B frame in the coded order, P1. On the other hand, the decode time of B-frame B2 is 5 time units, which is identical to its presentation time.
例と、セクション3.4で図1を考えてください。 決定する、最初のフレームの時間を解読してください、とI0、最初に決定しなければならない、隣のフレーム(P1)の時間を解読してください。 解読してください。P1が非Bフレームであるのでそれ、時間はI0のプレゼンテーション時間と等しいです。(I0は3タイム・ユニットです)。 このようにして、少なくとも1回のフレームの期間が3未満であったに違いないならI0の時間を解読してください。 この例では、タイム・ユニット毎に1個のフレームを表示するので、フレームの期間は1です。 I0の時間を解読してください。その結果、2タイム・ユニットとして、選ばれています。 コード化された注文、P4の3番目のフレームの時間を解読して、それがコード化されたオーダー(P1)における、前の非Bフレームのプレゼンテーション時間と等しいに違いないので4です。 他方では、Bフレームでは、B2が5タイム・ユニットである時を解読してください。(それは、プレゼンテーション時間と同じです)。
Klemets Standards Track [Page 12] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[12ページ]RFC4425RTP有効搭載量形式
If the decode time of a video frame differs from its presentation time, then the decode time MUST be specified using the DTS Delta field in the AU header. The syntax of the DTS Delta field is defined in section 5.2.
解読、ビデオフレームの時間はプレゼンテーション時間と異なっています、そして指定された使用がAUヘッダーのDTSデルタ分野であったに違いないなら時間を解読してください。 DTSデルタ分野の構文はセクション5.2で定義されます。
Receivers are not required to use the DTS Delta field. However, possible uses include buffer management and pacing of frames prior to decoding. If RTP packets are lost, it is possible to use the DTS Delta field to determine if the sequence of lost RTP packets contained reference frames or only B-frames. This can be done by comparing the decode and presentation times of the first frame received after the lost sequence against the presentation time of the last reference frame received prior to the lost sequence.
受信機はDTSデルタ分野を使用する必要はありません。 しかしながら、可能な用途は解読の前にフレームのバッファ管理とペースを含んでいます。 RTPパケットが無くなるなら、無くなっているRTPパケットの系列が基準座標系かB-フレームだけを含んだかどうか決定するのにDTSデルタ分野を使用するのは可能です。 比較することによってこれができる、解読してください。そうすれば、最終プレゼンテーション時間に対する無くなっている系列の後に受け取られた最初のフレームのプレゼンテーション倍は無くなっている系列の前に受け取られたフレームに参照をつけます。
Knowing if the stream will contain B-pictures may help the receiver allocate resources more efficiently and can reduce delay, as an absence of B-pictures in the stream implies that no reordering of frames will be needed between the decoding process and the display of the decoded frames. This may be important for interactive applications.
流れがB-絵を含むかどうかを知っているのを、受信機が、より効率的にリソースを割り当てるのを助けるかもしれなくて、遅れを縮めることができます、流れにおける、B-絵の欠如が、フレームを再命令でないのが解読過程と解読されたフレームの表示の間で必要であることを含意するとき。 対話型アプリケーションに、これは重要であるかもしれません。
The receiver SHALL assume that the coded bit stream may contain B-pictures in the following cases:
受信機SHALLは、コード化されたビットストリームが以下の場合に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.
- 主なプロフィール: MAXBFRAMESがSTRUCTで_Cをさばくなら、デコーダ初期化パラメタには、非ゼロ値があります。 STRUCT_Cは「コンフィグ」メディア型引数を運ばれます。(それは、セクション6.1で定義されます)。
Simple profile does not use B-pictures.
簡単なプロフィールはB-絵を使用しません。
4.4. Random Access Points
4.4. ランダムアクセスポイント
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.
エントリー・ポイントヘッダーの後の最初のフレームはコード化されたビットストリームへのランダムアクセスポイントです。 簡単、そして、Mainプロフィールにはエントリー・ポイントヘッダーがないので、それらのプロフィールに関して、各I-絵はランダムアクセスポイントです。
Klemets Standards Track [Page 13] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[13ページ]RFC4425RTP有効搭載量形式
To allow the RTP receiver to detect that an RTP packet that was lost contained a random access point, this RTP payload format defines a field called "RA Count". This field is present in every AU, and its value is incremented (modulo 256) for every random access point. For additional details, see the definition of "RA Count" in section 5.2.
それを検出するためにRTP受信機を許容するために、無くなっているRTPパケットはランダムアクセスポイントを含んで、このRTPペイロード形式は「RAは数えます」と呼ばれる分野を定義します。 この分野はあらゆるAUに存在しています、そして、値はあらゆるランダムアクセスポイントに増加されます(法256)。 追加詳細に関しては、セクション5.2との「RAは数える」定義を見てください。
To make it easy to determine if an AU contains a random access point, this RTP payload format also defines a bit called the "RA" flag in the AU Control field. This bit is set to 1 only on those AU's that contain a random access point. The RA bit is defined in section 5.3.
AUがランダムアクセスポイントを含むかどうか決定するのを簡単にするように、また形式が定義するこのRTPペイロードはAu制御フィールドに"RA"旗を少し呼びました。 このビットはランダムアクセスポイントを含むAUのそれらのところだけの1へのセットです。 RAビットはセクション5.3で定義されます。
4.5. Removal of HRD Parameters
4.5. HRDパラメタの取り外し
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.
Advancedプロフィールの系列層のヘッダーはHypothetical Reference Decoder(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.
上で説明されるように水漏れするバケツパラメタセットを取り外すと、系列層のヘッダーとエントリー・ポイントヘッダーのサイズはかなり減少するかもしれません。
4.6. Repeating the Sequence Layer Header
4.6. 系列層のヘッダーを繰り返します。
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パケットの損失に対して丈夫さを改良するために、系列層のヘッダーが変化するなら、それがビットストリームで頻繁に繰り返されるべきであるのは、RECOMMENDEDです。 この場合、系列層のヘッダーとエントリー・ポイントヘッダーの水漏れするバケツパラメタの数が1まで減少するのは、RECOMMENDEDです、セクション4.5で説明されるように。 これは、系列層のヘッダーを繰り返すことによって引き起こされたオーバーヘッドを下げるのを助けるでしょう。
Klemets Standards Track [Page 14] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[14ページ]RFC4425RTP有効搭載量形式
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.
HRDのための水漏れするバケツパラメタを計算するとき、系列ヘッダー自体の繰り返されたコピーを含むVC-1ビットストリームのどんなデータも説明しなければなりません。 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 Controlは"SL"旗を少し呼びました。 系列層のヘッダーが伝えられるとき、そのヘッダーが最も最近伝えられた系列層のヘッダーと異なる場合にだけ、このビットは切り換えられます。 SLビットはセクション5.3で定義されます。
4.7. Signaling of Media Type Parameters
4.7. メディア型引数のシグナリング
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と共に使用されるとき、セクション6.1で指定されたメディア型引数を使用して、SDPでセクション3.3で説明されたデコーダ初期化パラメタに合図しなければなりません。 セクション6.2はメディア型引数をSDP[5]に写像する方法を指定します、そして、セクション6.3はSDP Offer/答えモデルに、特定の規則を定義します、そして、セクション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.
SimpleかMainプロフィールが使用されているとき、コード化されたビットストリームを通してデコーダ初期化パラメタを変えるのは可能ではありません。 デコーダ初期化パラメタへのどんな変化にもバンドの外を通した手段をしなければならないでしょう、例えば、アップデートされたセッション記述を伝える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.
Advancedプロフィールが使用されているとき、新しい系列層のヘッダーかエントリーポイントヘッダーをコード化されたビットストリームに挿入することによって、デコーダ初期化パラメタを変えるかもしれません。
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レベル、コード化されたフレームの最大サイズを指定します、また、最大のフレームが評価します。 メディア型引数の「レベル」、「幅」、「高さ」、および"framerate"はこれらのパラメタのための最大の限界を指定します。 したがって、系列層のヘッダーはメディア型引数の「レベル」、「幅」、「高さ」、または"framerate"の値より低い値を指定するかもしれませんが、系列層のヘッダーはこれらのメディア型引数のどれかの値を超えてはいけません。
Klemets Standards Track [Page 15] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[15ページ]RFC4425RTP有効搭載量形式
4.8. The "mode=1" Media Type Parameter
4.8. 「モード=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.
Advancedプロフィールを使用するあるアプリケーションでは、系列層のヘッダーは決して変化しません。 これは「モード=1インチ」というメディア型引数で合図されるかもしれません。 (「モード」パラメタはセクション6.1で定義されます。) 「ビットストリームのすべての系列層のヘッダーが同じになるというRTP受信機への「ヒント」としてのモード=1インチのパラメタサーブ。」 「モード=1インチは合図されます、そして、系列層のヘッダーがコード化されたビットストリームで出席している、「コンフィグ」メディア型引数によって指定された系列層のヘッダーには、次に、それは同じでなければならない」なら。
Since the sequence layer header never changes in "mode=1", the RTP sender MAY remove it from the bit stream. Note, however, that if the value of TFCNTRFLAG in the sequence layer header is 1, each picture header contains a frame counter field (TFCNTR). This field is reset each time the sequence layer header occurs in the bit stream. If the RTP sender chooses to remove the sequence layer header, then it MUST ensure that the resulting bit stream is still compliant with the VC-1 specification (e.g., by adjusting the TFCNTR field, if necessary.)
以来、系列層のヘッダーは「何モード=1インチも、RTP送付者はビットストリームからそれを取り除くかもしれないところ」で決して変化しません。 しかしながら、それぞれの絵のヘッダーが系列層のヘッダーのTFCNTRFLAGの値が1であるなら、フレームカウンタ分野(TFCNTR)を含むことに注意してください。 系列層のヘッダーがビットストリームで起こるたびにこの分野はリセットされます。 RTP送付者が、系列層のヘッダーを取り除くのを選ぶなら、それは結果として起こるビットストリームが確実にVC-1仕様でまだ対応するのになるようにしなければなりません。(必要なら例えば、TFCNTR分野を調整することによって。)
4.9. The "mode=3" Media Type Parameter
4.9. 「モード=3インチのメディア型引数」
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.
Advancedプロフィールを使用するあるアプリケーションでは、系列層のヘッダーとエントリー・ポイントヘッダーの両方が決して変化しません。 これは「モード=3インチ」というメディア型引数で合図されるかもしれません。 同じ規則が、当てはまる、「モードは「セクション4.8で説明されたモード=1インチ」のように何3インチも等しいです。 さらに、「モード=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.
「モード=3インチは合図されます、そして、RTP受信機は完全なAUかAUの最初の断片を受けます、そして、AUはエントリー・ポイントヘッダーと共に始まりません、そして、RAビットは1に設定されますが、次に、これはエントリー・ポイントヘッダーが「圧縮されたこと」を示す」なら。 その場合、RTP受信機はAUの始めにエントリー・ポイントヘッダーを挿入しなければなりません。 エントリー・ポイントヘッダーを挿入するとき、RTP受信機は「コンフィグ」メディア型引数によって指定されたものを使用しなければなりません。
Klemets Standards Track [Page 16] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[16ページ]RFC4425RTP有効搭載量形式
5. RTP Payload Format Syntax
5. RTP有効搭載量形式構文
5.1. RTP Header Usage
5.1. RTPヘッダー用法
The format of the RTP header is specified in RFC 3550 [3] and is reprinted in Figure 3 for convenience.
RTPヘッダーの形式は、RFC3550[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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550
図3。 RFC3550に従った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ヘッダーの分野には、RFC3550と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): RTPパケットが完全なVC-1フレームかVC-1フレームの最後の断片を含むAccess Unitを含んでいるなら、1ビットのThisビットは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.
有効搭載量タイプ(太平洋標準時の): Thisが記録する7ビットはこのRTPペイロード形式のためにRTPペイロードタイプを選任しません。 ペイロードタイプの課題は使用されるRTPプロフィールかダイナミックな方法で実行されなければなりません。
Sequence Number: 16 bits
The RTP receiver can use the sequence number field to recover
the coded order of the VC-1 frames. A typical VC-1 decoder
will require the VC-1 frames to be delivered in coded order.
When VC-1 frames have been fragmented across RTP packets, the
RTP receiver can use the sequence number field to ensure that
no fragment is missing.
一連番号: 16ビット、RTP受信機は、VC-1フレームのコード化された注文を回復するのに一連番号分野を使用できます。 典型的なVC-1デコーダは、VC-1フレームがコード化されたオーダーで届けられるのを必要とするでしょう。 VC-1フレームがRTPパケットの向こう側に断片化されたとき、RTP受信機は、どんな断片もなくならないのを保証するのに一連番号分野を使用できます。
Klemets Standards Track [Page 17] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[17ページ]RFC4425RTP有効搭載量形式
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タイムスタンプは最初のAccess UnitのVC-1フレームのプレゼンテーション時間に設定されます。 90kHzのクロックレートを使用しなければなりません。
5.2. AU Header Syntax
5.2. Auヘッダー構文
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.
Access Unitヘッダーは1バイトのAU Control分野、RA Count分野、および3つの任意の分野から成ります。 ネットワークバイトオーダーにすべての分野を書かなければなりません。 AUヘッダーの構造は図4で例証されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Au| RA| AUP| Pt| DTS| |コントロール| カウント| レン| デルタ| デルタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Control分野の用法はセクション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ビットのRandom Access Point Counter。 この分野は2進の法256カウンタです。 AUがAU Control分野のRAビットが1に設定されるところに送られるたびにこの分野の値を1つ増加しなければなりません。 この分野の初期の値は、未定義であり、手当たりしだいに選ばれるかもしれません。
AUP Len: 16 bits
Access Unit Payload Length. Specifies the size, in bytes, of
the payload of the Access Unit. The field does not include the
size of the AU header itself. The field MUST be included in
each AU header in an RTP packet, except for the last AU header
in the packet. If this field is not included, the payload of
the Access Unit SHALL be assumed to extend to the end of the
RTP payload.
AUPレン: 16ビットのAccess Unit有効搭載量Length。 Access Unitのペイロードのバイトで表現されるサイズを指定します。 分野はAUヘッダー自体のサイズを含んでいません。 RTPパケットのそれぞれのAUヘッダーに分野を含まなければなりません、パケットにおける最後のAUヘッダーを除いて。 この分野は含まれていません、ペイロード。Access Unit SHALLでは、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.
Ptデルタ: 32ビットのPresentation時間デルタ。 2補数がこのRTPパケットのRTPヘッダーのタイムスタンプ分野から(デルタ)を相殺したので、フレームのプレゼンテーション時間を指定します。 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
RTPタイムスタンプ分野がRTPパケットにおける最初のAUヘッダー最初のAUのフレームのプレゼンテーション時間を指定するので含まれていて、これはSHOULD NOTをさばきます。 この分野です。
Klemets Standards Track [Page 18] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[18ページ]RFC4425RTP有効搭載量形式
is not included, the presentation time of the frame SHALL be
assumed to be specified by the timestamp field in the RTP
header.
含まれていません、プレゼンテーションを調節します。フレームSHALLでは、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ビットのDecode時間デルタ。 そして、指定、a2がプレゼンテーション時間の間でオフセット(デルタ)の補足となるときフレームの時間を解読してください、時間を解読してください。 プレゼンテーション時間が、より大きいならそれに注意してください、a値でゼロ以上であるDTSデルタ分野に時間、この結果を解読してください。 DTSデルタ分野はRTPヘッダーのタイムスタンプ分野と同じクロックレートを使用しなければなりません。 フレームSHALLの時間を解読してください。この分野が含まれていないなら思う、フレームのプレゼンテーション時間と同じであると思われてください。
5.3. AU Control Field Syntax
5.3. Au制御フィールド構文
The structure of the 8-bit AU Control field is shown in Figure 5.
8ビットのAU Control分野の構造は図5で見せられます。
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+
0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ | 破片手榴弾で殺傷してください。| RA| SL| LP| 太平洋標準時| DT| R| +----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field.
図5。 AU Control分野の構文。
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ビットのFragmentation情報。 この分野は、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番目か最後の断片以外のフレームの断片を含んでいます。 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ビットのRandom Access Pointインディケータ。 AUがランダムアクセスポイントであるフレームを含んでいるなら、このビットを1に設定しなければなりません。 SimpleとMainプロフィールの場合では、どんなI-絵もランダムアクセスポイントです。
In the case of Advanced profile, the first frame after an
entry-point header is a random access point.
Advancedプロフィールの場合では、エントリー・ポイントヘッダーの後の最初のフレームはランダムアクセスポイントです。
Klemets Standards Track [Page 19] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[19ページ]RFC4425RTP有効搭載量形式
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ビットのSequence Layer Counter。 このビットは、1〜切り換えられて、すなわち、変えられた0〜1か0であるに違いありません、AUが系列層のヘッダーを含んでいて、それが最も最近伝えられた系列層のヘッダーと異なるなら。 さもなければ、このビットの価値は前のAUのSLビットの価値と同じであるに違いありません。
The initial value of this bit is undefined and MAY be chosen
randomly.
このビットの初期の価値は、未定義であり、手当たりしだいに選ばれるかもしれません。
The bit MUST be 0 for Simple and Main profile bit streams or if
the sequence layer header never changes.
SimpleとMainがビットストリームの輪郭を描くか、または系列層のヘッダーが決して変化しないなら、ビットは0であるに違いありません。
LP: 1 bit
Length Present. This bit MUST be set to 1 if the AU header
includes the AUP Len field.
LP: 1ビットのLength Present。 AUヘッダーがAUPレン分野を入れるなら、このビットを1に設定しなければなりません。
PT: 1 bit
PTS Delta Present. This bit MUST be set to 1 if the AU header
includes the PTS Delta field.
太平洋標準時: 1ビットのPTSデルタPresent。 AUヘッダーがPTSデルタ分野を入れるなら、このビットを1に設定しなければなりません。
DT: 1 bit
DTS Delta Present. This bit MUST be set to 1 if the AU header
includes the DTS Delta field.
DT: 1ビットのDTSデルタPresent。 AUヘッダーがDTSデルタ分野を入れるなら、このビットを1に設定しなければなりません。
R: 1 bit
Reserved. This bit MUST be set to 0 and MUST be ignored by
receivers.
R: 1ビットのReserved。 このビットを0に設定しなければならなくて、受信機で無視しなければなりません。
6. RTP Payload Format Parameters
6. RTP有効搭載量形式パラメタ
6.1. Media type Registration
6.1. メディアはRegistrationをタイプします。
This registration uses the template defined in RFC 4288 [7] and follows RFC 3555 [8].
この登録は、RFC4288[7]で定義されたテンプレートを使用して、RFC3555[8]に続きます。
Type name: video
型名: ビデオ
Subtype name: vc1
Subtypeは以下を命名します。 vc1
Klemets Standards Track [Page 20] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[20ページ]RFC4425RTP有効搭載量形式
Required parameters:
必要なパラメタ:
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:
Advancedプロフィールに関しては、有効値は、0〜4です。(その4はL4を通してそれぞれレベルL0に対応します)。 SimpleとMainプロフィールに関しては、以下の値は定義されます:
1: Low Level
2: Medium Level
3: High Level (only valid for Main profile)
1: 低レベル2: 中くらいのレベル3: 高いレベル(Mainプロフィールだけに有効)です。
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 Offer/答えモデルと共にどう使用されるかために特定の規則に関してRFC4425のセクション6.3を見てください。
Klemets Standards Track [Page 21] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[21ページ]RFC4425RTP有効搭載量形式
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.
コンフィグ: 値はデコーダ初期化パラメタを言い表す八重奏ストリングのbase16[6](16進)表現です。 デコーダ初期化パラメタは最初にMSB基礎でbase16八重奏ストリングに写像されます。 デコーダ初期化パラメタの最初のビットは最初の八重奏のMSBに位置しなければなりません。 デコーダ初期化パラメタが8ビットの倍数でないなら、八重奏整列を達成する最後の八重奏で無評価された最大7詰め物ビットを加えなければなりません。
For Simple and Main profiles, the decoder initialization
parameters are STRUCT_C, as defined in Annex J of SMPTE 421M
[1].
SimpleとMainプロフィールに関しては、デコーダ初期化パラメタはSMPTE421M[1]のAnnex Jで定義されるようにSTRUCT_Cです。
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].
Advancedプロフィールに関しては、デコーダ初期化パラメタはエントリーポイントヘッダーによって直接いうことになられた系列層のヘッダーです。 EBDU形式には2個のヘッダーがあるに違いありません、彼らが彼らのStart Codesを含まなければならなくて、SMPTE421M[1]のAnnex 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.
SimpleとMainプロフィール、値のSHALLにおいて、コード化されたフレームの実際の水平なサイズと同じにしてください。
For Advanced profile, the value SHALL be greater than, or
equal to, the largest horizontal size of the coded frames.
Advancedプロフィール、値のSHALL、 よりすばらしくいてください、等しい、コード化されたフレームの最も大きい水平なサイズ。
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).
高さ: 値はゼロ以上の整数です、コード化されたフレームの最大の垂直なサイズを指定して、lumaのサンプル(次第にコード化されたlumaの絵の画素)で。
For Simple and Main profiles, the value SHALL be identical
to the actual vertical size of the coded frames.
SimpleとMainプロフィール、値のSHALLにおいて、コード化されたフレームの実際の垂直なサイズと同じにしてください。
Klemets Standards Track [Page 22] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[22ページ]RFC4425RTP有効搭載量形式
For Advanced profile, the value SHALL be greater than, or
equal to, the largest vertical size of the coded frames.
Advancedプロフィール、値のSHALL、 よりすばらしくいてください、等しい、コード化されたフレームの最も大きい垂直なサイズ。
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: 値はゼロ以上の整数です、bpsにおける、コード化されたビットストリームのピーク通信速度を指定して。 数は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].
このパラメタが指定されないなら、それは指定されたプロフィールとレベルによって許容された最大のビット伝送速度をデフォルトとします。 "RMax"に関してSMPTE421M[1]のAnnex Dの値を見てください。
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、bitrateパラメタで指定された通信速度で伝えられた流れを含むのに必要であるミリセカンドで。 このパラメタはVC-1の仮定している参照デコーダモデル、SMPTE421M[1]のAnnex Cで定義されます。
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].
このパラメタが指定されないなら、それは指定されたプロフィールとレベルによって許容された最大のバッファサイズをデフォルトとします。 "BMax"と"RMax"に関してSMPTE421M[1]のAnnex Dの値を見てください。
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.
framerate: 値はゼロ以上の整数です、1000年までに掛けられて、最も近い整数値に一周したコード化されたビットストリームで1秒あたりのフレームの最大数を指定して。 例えば、1秒あたり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.
受信機で資源配分を制御するのにこのパラメタを使用できます。例えば、フレームレートが低いと予想される場合にだけ、受信機は、解読されたフレームに兼務処理を実行するのを選ぶかもしれません。 表現の過程を歩き回らせるのにパラメタを使用してはいけません、実際のフレームレートが規定値と異なるかもしれないので。
Klemets Standards Track [Page 23] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[23ページ]RFC4425RTP有効搭載量形式
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: このパラメタは、Advancedプロフィールが使用されているとき、BとBI-絵が存在しているかもしれないのを示します。 このパラメタが存在していて、BかBI-絵がコード化されたビットストリームで存在しているかもしれないなら、このパラメタは1と等しいに違いありません。
A value of 0 indicates that B- and BI-pictures SHALL NOT be
present in the coded bit stream, even if the sequence layer
header changes. Inclusion of this parameter with a value of
0 is RECOMMENDED, if neither B- nor BI-pictures are included
in the coded bit stream.
0の値は、BとBI-絵のSHALL NOTがコード化されたビットストリームで存在しているのを示します、系列層のヘッダーが変化しても。 0の値があるこのパラメタの包含はRECOMMENDEDです、BもBI-絵もコード化されたビットストリームに含まれていないなら。
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.
SimpleとMainプロフィールと共にこのパラメタを使用してはいけません。 Mainプロフィールに関しては、BとBI-絵の存在はSTRUCT_Cデコーダ初期化パラメタのMAXBFRAMES分野によって示されます。
For Advanced profile, if this parameter is not specified, a
value of 1 SHALL be assumed.
Advancedプロフィールに関しては、このパラメタが1SHALLの指定されたa値でないなら、想定されてください。
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:
モード: 値は系列層のヘッダーとエントリー・ポイントヘッダーの使用を指定する整数です。 このパラメタはAdvancedプロフィールのために定義されるだけです。 以下の値は定義されます:
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: コンフィグパラメタで指定された系列層のヘッダーは決して変化しません。 RFC4425のセクション4.8の規則に従わなければなりません。 3: コンフィグパラメタで指定された系列層のヘッダーとエントリー・ポイントヘッダーは決して変化しません。 RFC4425のセクション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.
モードパラメタが0SHALLの指定されたa値でないなら、想定されてください。 モードパラメタSHOULD、モード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
最大幅、最大高さ、最大-bitrate、最大バッファ、最大-framerate: これらのパラメタは能力交換手順における使用のために定義されます。 またはパラメタがコード化されたビットストリームの特性ではなく、むしろ最大の限界を示す。
Klemets Standards Track [Page 24] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[24ページ]RFC4425RTP有効搭載量形式
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.
「幅」、「高さ」、"bitrate"、「バッファ」、および"framerate"パラメタのための都合のよい値。 RFC4425のセクション6.3はこれらのパラメタがSDP Offer/答えモデルと共にどう使用されるかに特定の規則を提供します。
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.
与えられたプロフィールとレベルのサポートに合図する受信機はそのプロフィールとレベルのためのこれらのパラメタのために最大の値を支持しなければなりません。 例えば、Mainプロフィールのサポートを示す受信機(Lowレベル)は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.
受信機は、都合のよい能力を示すのに最大幅のどれか、最大高さ、最大bitrate、最大バッファ、および最大-framerateパラメタを使用するかもしれません。 例えば、受信機は、ディスプレイ装置の解決に合っている最大幅と最大高さに値を指定するのを選ぶかもしれません、それらのパラメタを使用することでコード化された流れは少し再スケーリングされる必要はないでしょう、したがって。
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.
いずれかであるなら、パラメタが能力を示す最大幅、最大高さ、最大-bitrate、最大バッファ、および最大-framerateでは、それは合図されたプロフィールとレベルの必要な能力、次に、パラメタSHALLよりその能力のための都合のよい値として解釈されていた状態で少ないです。
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.
また、パラメタのいずれも、合図されたプロフィールとレベルの必要な能力を超えている能力に合図するのに使用されるかもしれません。 その場合、パラメタSHALL、その能力のために支持できる最大値として、解釈されてください。
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.
セット(最大幅、最大高さ、最大-bitrate、最大バッファ、および最大-framerate)からの1つ以上のパラメタが同時に存在しているとき、すべての合図された能力を支持しなければなりません。
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 Offer/答えモデルでは、Answerで使用できる平らなパラメタの値はOfferで指定されたことによって制限されます。
Klemets Standards Track [Page 25] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[25ページ]RFC4425RTP有効搭載量形式
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.
最大高さ: 値はゼロ以上の整数です、コード化されたフレームに垂直なサイズを指定して、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.
最大-bitrate: 値はゼロ以上の整数です、bpsにおけるコード化されたビットストリームにピーク通信速度を指定して。 数は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].
このパラメタが指定されないなら、それは指定されたプロフィールとレベルによって許容された最大のビット伝送速度をデフォルトとします。 "RMax"に関してSMPTE421M[1]のAnnex Dの値を見てください。
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
最大バッファ: 値は水漏れするバケツサイズを指定する整数です、B、最大-bitrateによって指定された通信速度で伝えられた流れを含むのに必要であるミリセカンドで
Klemets Standards Track [Page 26] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[26ページ]RFC4425RTP有効搭載量形式
parameter. This parameter is defined in the hypothetical
reference decoder model for VC-1, in Annex C of SMPTE 421M
[1].
パラメタ。 このパラメタはVC-1の仮定している参照デコーダモデル、SMPTE421M[1]のAnnex Cで定義されます。
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.
値がサイズが最大-bitrateパラメタで許容した最大の水漏れするバケツとプロフィールより少なくて、平らであるなら、値は都合のよい水漏れするバケツサイズを指定します。 さもなければ、それは最大bitrateパラメタによって指定されたビット伝送速度のために支持される最大の水漏れするバケツサイズを指定します。
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].
このパラメタが指定されないなら、それは指定されたプロフィールとレベルによって許容された最大のバッファサイズをデフォルトとします。 "BMax"と"RMax"に関してSMPTE421M[1]のAnnex Dの値を見てください。
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.
最大-framerate: 多くの1秒あたりのフレームをコード化されたビットストリームに指定して、値はゼロ以上の整数です。 値は1000年までに掛けられて、最も近い整数値に四捨五入されたフレームレートです。 例えば、1秒あたり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.
問題をコード化します: このメディアタイプは、縁どられて、2進のデータを含んでいます。
Security considerations:
See Section 7 of RFC 4425.
セキュリティ問題: RFC4425のセクション7を見てください。
Interoperability considerations:
None.
相互運用性問題: なし。
Published specification:
RFC 4425.
広められた仕様: RFC4425。
Klemets Standards Track [Page 27] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[27ページ]RFC4425RTP有効搭載量形式
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.
詳細のために連絡する人とEメールアドレス: アンダース Klemets <anderskl@microsoft.com 、gt;、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
作者: アンダースKlemets
Change controller:
IETF Audio/Video Transport Working Group delegated from the
IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
6.2. Mapping of media type parameters to SDP
6.2. SDPへのメディア型引数に関するマッピング
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:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSession記述プロトコル(SDP)で[4]をさばきます。 このペイロード形式を使用することでセッションを指定するのにSDPを使用するなら、以下の通りマッピングをします:
o The media name in the "m=" line of SDP MUST be video (the type
name).
o 「m=」のメディア名はビデオが(型名)であったならSDP MUSTに立ち並んでいます。
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the
subtype name).
o コード化はvc1が(「副-タイプ」名)であったなら"a=rtpmap"でSDP MUSTの台詞を命名します。
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"線にパラメタが「輪郭を描い」て、「平らにする」REQUIREDを含まなければなりません。
These parameters are expressed in the form of a semicolon
separated list of parameter=value pairs.
これらのパラメタはパラメタ=値組のセミコロンの切り離されたリストの形で言い表されます。
Klemets Standards Track [Page 28] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[28ページ]RFC4425RTP有効搭載量形式
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 存在しているとき、SDPの"a=fmtp"線にOPTIONALパラメタの「コンフィグ」、「幅」、「高さ」、"bitrate"、「バッファ」、"framerate"、"bpic"、「モード」、「最大幅」、「最大高さ」、「最大-bitrate」、「最大バッファ」、および「最大-framerate」を含まなければなりません。
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>]
a=fmtp: ダイナミックな<の><パラメタ名前>ペイロードタイプ=<値>[<値の>][; <パラメタ名前>=<値>]
o Any unknown parameters to the device that uses the SDP MUST be
ignored. For example, parameters defined in later specifications
MAY be copied into the SDP and MUST be ignored by receivers that
do not understand them.
o どんな未知のパラメタ、もSDP MUSTを使用する装置に、無視されてください。 例えば、後の仕様に基づき定義されたパラメタを、SDPにコピーされるかもしれなくて、それらを理解していない受信機で無視しなければなりません。
6.3. Usage with the SDP Offer/Answer Model
6.3. 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:
ユニキャスト用法のための交渉にOffer/答えモデル[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プロフィールが支えられないなら、answererはパラメタを維持しなければならないか、またはメディア形式(ペイロードタイプ)を取り除かなければなりません。
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".
answererは答えにおける数の上で申し出で指定されたそれより高いレベルを指定してはいけません。 answererはすなわち、申し出、平らなパラメタで指定されたそれであることができるより「格下げされていた」状態で低いレベルを指定するかもしれません。
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指示属性を指定して、答えが平らなパラメタを格下げするなら、これはアップデートされた「コンフィグ」パラメタを指定するという新しい申し出を必要とするかもしれません。 答えで指定されるレベルと共に「コンフィグ」パラメタを使用できないなら、申出人は、ぐるりと別のOffer/答えを開始してはいけませんし、メディア形式(ペイロードタイプ)を使用してはいけません。
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer", and "mode", describe the properties of the
VC-1 bit stream that the offerer or answerer is sending for this
media format configuration.
o "bpic"、「幅」、「高さ」、"framerate"、"bitrate"、「バッファ」、および「モード」という「コンフィグ」というパラメタは、申出人かanswererがこのメディア形式のために構成を送るVC-1ビットストリームの特性について説明します。
Klemets Standards Track [Page 29] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[29ページ]RFC4425RTP有効搭載量形式
In the case of unicast usage and when the direction attribute in
the offer or answer is recvonly, the interpretation of these
parameters is undefined and they MUST NOT be used.
ユニキャスト用法に関するケースであって申し出か答えにおける指示属性がいつrecvonlyであるかときに、これらのパラメタの解釈は未定義です、そして、それらは使用されてはいけません。
o The parameters "config", "width", "height", "bitrate", and
"buffer" MUST be specified when the direction attribute is
sendrecv or sendonly.
o パラメタ「コンフィグ」、「幅」、「高さ」、"bitrate"、および「バッファ」は指示属性がsendrecvかsendonlyであるなら指定していなければなりません。
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 パラメタ「最大幅」、「最大高さ」、「最大-framerate」、「最大bitrate」、および「最大バッファ」は申し出か答えで指定されるかもしれません、そして、彼らの解釈は以下の通りです:
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プロフィールのレベルによって許容されたそれよりそれほど、次に、それは属性の価値であるならSHALLです。送付者のVC-1ビットストリームSHOULD NOTはそれを超えています。 特性はaの値であるならVC-1プロフィールのレベルによって許容されていることよりすばらしく、次に、それはSHALLです。受信機が与えられたプロフィールとレベル、および同じプロフィールのどんな下のレベルのためにも受け入れる価値の上限として、解釈されてください。
For example, if a recvonly or sendrecv offer specifies
"profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a
suggested bit rate, because all receiver implementations of Simple
profile, Low level, are required to support bit rates of up to 96
kbps. Assuming that the offer is accepted, the answerer should
specify "bitrate=48000" in the answer, but any value up to 96000
is allowed. But if the offer specifies "max-bitrate=200000", this
means that the receiver implementation supports a maximum of 200
kbps for the given profile and level (or lower level). In this
case, the answerer is allowed to answer with a bitrate parameter
of up to 200000.
例えば、recvonlyかsendrecv申し出が「プロフィール=0; レベル=1; 最大-bitrate=48000」を指定するなら、当時の48キロビット毎秒は単に提案されたビット伝送速度です、Simpleプロフィールのすべての受信機実現(Lowレベル)が最大96キロビット毎秒のビット伝送速度を支持するのに必要であるので。 申し出が受け入れられると仮定する場合、answererは答えで"bitrate=48000"を指定するはずですが、どんな値最大96000も許容されています。 しかし、申し出が「最大-bitrate=200000」を指定するなら、これは、受信機実現が与えられたプロフィールとレベル(または、下のレベル)のために最大200キロビット毎秒を支持することを意味します。 この場合、answererは最大200000のbitrateパラメタで答えることができます。
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する"であることができます。
Klemets Standards Track [Page 30] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[30ページ]RFC4425RTP有効搭載量形式
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プロフィールの最高水準を指定します。 このパラメタの値はanswererによって変えられてはいけません。 したがって、ペイロードタイプを非変更されていると受け入れるか、または外すことができます。
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer", and "mode", specify properties of the VC-1
bit stream that will be sent and/or received on the multicast
session. The parameters MAY be specified, even if the direction
attribute is recvonly.
o "bpic"、「幅」、「高さ」、"framerate"、"bitrate"、「バッファ」、および「モード」という「コンフィグ」というパラメタは、マルチキャストセッションのときに送る、そして/または、受け取られるVC-1ビットストリームの特性を指定します。 指示属性がrecvonlyであっても、パラメタは指定されるかもしれません。
The values of these parameters MUST NOT be changed by the
answerer. Thus, a payload type can be either accepted unaltered
or removed.
これらのパラメタの値はanswererによって変えられてはいけません。 したがって、ペイロードタイプを非変更されていると受け入れるか、または外すことができます。
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 answererはsendrecvかrecvonlyとして申告されたすべての流れのためにパラメタ「最大幅」、「最大高さ」、「最大framerate」、「最大-bitrate」、および「最大バッファ」の値を支持しなければなりません。 さもなければ、以下の動作の1つを実行しなければなりません: メディア形式を取り除くか、またはセッションを拒絶します。
6.4. Usage in Declarative Session Descriptions
6.4. 叙述的なセッション記述における用法
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:
叙述的なスタイルにSDPを使用することでRTPの上にVC-1を提供するとき、RTSP[12]やSAP[13]のように、以下の規則と制限は適用されます:
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 パラメタ「コンフィグ」、「幅」、「高さ」、"bitrate"、および「バッファ」を指定しなければなりません。
o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate", and "max-buffer" MUST NOT be used.
o パラメタ「最大幅」、「最大高さ」、「最大-framerate」、「最大bitrate」、および「最大バッファ」を使用してはいけません。
An example of media representation in SDP is as follows (Simple profile, Medium level):
SDPのメディア表現の例は以下の通りです(簡単なプロフィール、Mediumレベル):
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
ビデオ49170RTP/AVP98m=a=rtpmap: 98 vc1/90000 a=fmtp: 98 プロフィール=0; レベル=2; 幅は352; 高さ=288; framerate=15000と等しいです。 bitrate=384000; =2000をバッファリングしてください; コンフィグは4e291800と等しいです。
Klemets Standards Track [Page 31] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[31ページ]RFC4425RTP有効搭載量形式
7. Security Considerations
7. セキュリティ問題
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].
潜在的サービスの否定の脅威は、データencodingsのために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は流れの中への解読するために複雑であり、受信機を積みすぎる病理学的なRTPパケットを注入できます。 VC-1は特にそのような攻撃に傷つきやすいです、攻撃者が多くの将来のフレームの解読過程に影響するフレームを含むRTPパケットを発生させるのが、可能であるので。 したがって、データ起源認証の用法と少なくともRTPパケットのデータ保全保護はRECOMMENDEDです。 例えば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ビットストリームSHOULDを輸送する送付者が利用者データが確実に仕様がSMPTEに登録されている状態で対応するのになるようにします([1]のAnnex Fを見てください。)。 SHOULDが防ぐ受信機は不従順な利用者データの場合に誤動作します。
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の流れがまさしくその高帯域要件(ハイデフィニッションビデオのための最大135Mbps)を持つことができることに注意するのは重要です。 多くのインターネット経路に送られるなら、これはサービスの否定の可能性を引き起こします。 したがって、このペイロード形式のユーザはセクション8で説明される輻輳制御要件に応じなければなりません。
Klemets Standards Track [Page 32] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[32ページ]RFC4425RTP有効搭載量形式
8. Congestion Control
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 SHALLのために制御されます。RFC3550[3]、およびあらゆる適切なRTPプロフィールと共に使用されてください。 例えば、RFC3551[15]。
If best-effort service is being used, users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
ベストエフォート型サービスが利用されているなら、このペイロード形式のユーザは、許容できるパラメタの中にパケット損失率があるのを保証するためにパケット損失をモニターしなければなりません。 同じネットワーク経路と同じネットワーク状態を経験することの向こう側のTCP流動が妥当なスケールで測定された少なくとも流れが実現しているRTPである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 通信速度を適合させるために混雑制御機構を実行するか、または損失率が容認できないほど高いなら受信機がセッションを出発するように手配することによって、この状態を満たすことができます。
The bit rate adaptation necessary for obeying the congestion control principle is easily achievable when real-time encoding is used. When pre-encoded content is being transmitted, bandwidth adaptation requires one or more of the following:
リアルタイムのコード化が使用されているとき、輻輳制御原則に従うのに必要なビット伝送速度適合は容易に達成可能です。 あらかじめコード化された内容が伝えられているとき、帯域幅適合は以下の1つ以上を必要とします:
- The availability of more than one coded representation of the same
content at different bit rates. The switching between the
different representations can normally be performed in the same
RTP session by switching streams at random access point
boundaries.
- 1以上の有用性は異なったビット伝送速度で同じ内容の表現をコード化しました。 通常、異なった表現の間の切り換えは同じ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構文要素(簡単、そして、Mainプロフィールフレーム専用)と非基準座標系が捨てられるならまるでフレームが全く捨てられていないかのように(高度なプロフィールフレーム専用)が増加しなければならない任意のTFCNTR構文要素。 TFCNTR構文要素が表示命令(それらが伝えられるオーダー(コード化されたオーダー)と異なっている)でフレームを数えるので、何らかの数のフレームを「前を見る」か、またはバッファリングするのが送信機を必要とするでしょう。
Klemets Standards Track [Page 33] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[33ページ]RFC4425RTP有効搭載量形式
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分野を変更することによって不連続に合図するのが必要であるかもしれないか、またはAdvancedプロフィールが使用されているなら、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.
また、このペイロード形式はサービスの質保証を提供するネットワークに使用されるかもしれません。 高度サービスが使用されているなら、受信機SHOULDは、要求されたサービスが実際に提供されているのを保証するためにパケット損失をモニターします。 それはそうでなく、次に、それらはSHOULDです。彼らが受信のベストエフォート型サービスであり、それに従って、振る舞うと仮定してください。
9. IANA Considerations
9. IANA問題
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は「ビデオ/vc1"と関連RTPペイロードはセクション6.1で指定されるようにTypes登録とRTP有効搭載量Format MIMEの種類登録でメディアでフォーマットする」メディアタイプを示しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Society of Motion Picture and Television Engineers, "VC-1
Compressed Video Bitstream Format and Decoding Process", SMPTE
421M.
[1] 映画テレビ技術者協会、「VC-1はビデオBitstream形式と解読過程を圧縮した」SMPTE421M。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[6]Josefsson、S.、エド、「Base16、Base32、およびBase64データEncodings」、RFC3548、7月2003日
[7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[7]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、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の種類登録」、RFC3555、2003年7月。
Klemets Standards Track [Page 34] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[34ページ]RFC4425RTP有効搭載量形式
10.2. Informative References
10.2. 有益な参照
[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.、シュー、P.、ホルコム、T.、ムケルジー、K.、Regunathan、S.L.、リン、B.、梁、J.、リー、M.、およびJ.Ribas-Corbera、「Windowsメディア、ビデオ9:、」 「概観とアプリケーション」、Signal Processing: イメージコミュニケーション、第19巻は9、2004年10月を発行します。
[10] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A
generalized hypothetical reference decoder for H.264/AVC", IEEE
Transactions on Circuits and Systems for Video Technology,
August 2003.
[10]Ribas-CorberaとJ.と町とP.A.とS.L.Regunathanと「H.264/AVCのための一般化された仮定している参照デコーダ」とCircuitsの上のIEEE TransactionsとVideo Technology(2003年8月)のためのSystems。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[11]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[12]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[13] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
Acknowledgements
承認
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar Regunathan, Gary Sullivan, Stephan Wenger, and Magnus Westerlund for providing detailed feedback on this document.
おかげに、リージスCrinon、Miska Hannuksela、コリン・パーキンス、シャンカルRegunathan、ゲーリー・サリバン、シュテファンWenger、および提供するためのマグヌスWesterlundはこのドキュメントのフィードバックを詳しく述べました。
Author's Address
作者のアドレス
Anders Klemets Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
アンダースKlemets Microsoft Corp.1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: Anders.Klemets@microsoft.com
メール: Anders.Klemets@microsoft.com
Klemets Standards Track [Page 35] RFC 4425 RTP Payload Format for VC-1 February 2006
VC-2006年2月1日のKlemets標準化過程[35ページ]RFC4425RTP有効搭載量形式
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Klemets Standards Track [Page 36]
Klemets標準化過程[36ページ]
一覧
スポンサーリンク
