Microsoft DirectX 8.0 |
要約 : この文書では、DVD サブピクチャなどに対応するためのアルファ ブレンディングのサポートを含め、デジタル ビデオのデコード処理をハードウェアでアクセラレーションするためのアプリケーション プログラミング インターフェイス (API) およびそれに対応するデバイス ドライバ インターフェイス (DDI) について説明する。特に MPEG-2 の "メイン プロファイル" ビデオ (以前の ITU-T MPEG-2 | ISO/IEC 13818-2) のサポートに焦点を当ててインターフェイスを解説するが、ほかの主要なビデオ CODEC (ITU-T 勧告 H.263 および H.261、ならびに MPEG-1 および MPEG-4 など) もサポートする。
この文書では、DVD サブピクチャなどに対応するためのアルファ ブレンディングのサポートを含め、デジタル ビデオのデコード処理をアクセラレーションするためのアプリケーション プログラミング インターフェイス (API) およびそれに対応するデバイス ドライバ インターフェイス (DDI) について説明する。特に MPEG-2 の "メイン プロファイル" ビデオ (以前の ITU-T MPEG-2 | ISO/IEC 13818-2) のサポートに焦点を当ててインターフェイスを解説するが、ほかの主要なビデオ CODEC (ITU-T 勧告 H.263 および H.261、ならびに MPEG-1 および MPEG-4など) もサポートする。ここで解説する設計は現時点ではデコードに限定されているが、将来インターフェイスがさらに拡張される際には、エンコード機能も定義される予定である。このインターフェイスは、各種 CODEC の設計の中で、多量の計算を要する最も基礎的な部分を抜き出し、ハードウェア内でのそれらのアクセラレーションをサポートするよう設計されている。
グラフィック ハードウェア ドライバは、グラフィック ハードウェア実装のアクセラレーション機能に対する共通のアクセス方式を提供するため、このインターフェイスをサポートしたほうがよい。過去に、グラフィック ハードウェア メーカー数社から、これとよく似た機能が自社製品専用のものとして定義されたことがあった。しかし、この仕様の目的は、ソフトウェア アプリケーション プログラムと高度なグラフィック アクセラレーション機能の間に、ベンダーに依存しない共通インターフェイスを確立することである。共通インターフェイスの確立により、ビデオをサポートするコンピューティング システムの能力が拡大され、この機能を提供するソフトウェア アプリケーションの需要が増加し、ハイパフォーマンスなグラフィック機能への需要が増加することが期待される。
この仕様で定義されているインターフェイスは、ITU-T の H.26x シリーズおよび ISO/IEC JTC1 の MPEG-x シリーズを含め、現在の主な標準動き補償ビデオ CODEC をサポートすることができる。当初は、現在最も商業的に優勢なビデオ CODEC である MPEG-2 (厳密には ITU-T 勧告 MPEG-2 または ISO/IEC 13838-2) をサポートするよう設計された。
この文書で定義している構文は、この標準規格を非常に直接的にサポートするよう設計されているため、標準規格の構文をここで定義されたフォーマットに変換する際には、わずかな "翻訳" しか必要ない。ほかの標準規格を最大限に一貫した方法でサポートするために必要な機能も追加された。また暗号化を必要とするアプリケーションのために、暗号化もサポートされている。このインターフェイスでは、各種の標準規格に共通の中心的な基本処理を抽出し、また規格固有のいくつかの処理をホスト CPU に限定している。これにより、規格に依存しない高い柔軟性を持ちながら、アクセラレーション ハードウェアに対する規格ごとのカスタマイズも最小限で済むビデオ CODEC ハードウェア アクセラレーションのサポートを可能にしている。
この仕様は、1 つ以上のステージを 1 つ以上のデバイス間で分割できるようにするビデオ デコーダ アクセラレーションの言語を定義している。現在この文書では、ITU-T H.261、MPEG-1 (ISO/IEC 11172-2)、MPEG-2 (ISO/IEC 13818-2 | ITU-T 勧告 MPEG-2)、ITU-T H.263、および MPEG-4 (ISO/IEC 14496-2) の一部の、動き補償予測 (MCP : motion-compensated prediction) および逆離散コサイン変換 (IDCT : inverse discrete-cosine transform) ステージを実行するハードウェア アクセラレータと、ホスト CPU との区分を説明している。総合的な目的は、CPU リソースを浪費する、簡単で、しかも頻繁に実行される処理を、専用の目的のために設計された低コストなアクセラレータにオフロードし、ビットストリーム解析や可変長デコード (VLD : variable-length decoding) といった、複雑で、あまり頻繁に実行されない処理をホスト CPU に残すことである。
ここで説明している仕様は、単一のビデオ ストリームのデコードに対してのみ有効である。複数のビデオ ストリームは、Microsoft® DirectX® VA API では明示的にはサポートされていない。このため、複数のビデオ ストリームをサポートするには、ビデオ ストリームごとに個別の DirectX® VA セッション処理が必要となる (例 : フィルタ グラフ処理での使用に、ビデオ デコーダとアクセラレーション ドライバに個別の出力ピンおよび入力ピンのセット)。
この仕様書に記載されたインターフェイスを使用するすべてのアクセラレータ ドライバについて、この仕様書の内容に準拠していることを確認する必要がある。確認内容は次のとおり。
Microsoft では、これらが検証されていない実装は、あくまでテスト目的に使用すべきであり、この文書で指定しているインターフェイスを公開するドライバに配備すべきではないと考える。
中期的将来には、デコーダおよびグラフィック アクセラレータの実装の認可に、このインターフェイスのサポート、およびサポートのためのパフォーマンス検証が必要となる。厳密なテスト スイートおよびパフォーマンス測定方法はまだ定義されていない。この文書で述べている中期的将来の必要条件は、ハードウェア ビデオ デコード アクセラレーションをサポートするすべてのグラフィック アクセラレーション ハードウェア、およびそれらのグラフィック アクセラレーション ハードウェア サポートを使用するすべてのソフトウェア デコーダについて、2001 年の半ばにおけるすべての Microsoft Windows® オペレーティング システム (Windows 2000、Windows Millennium Edition、および Windows 2000 "Whistler") に適用される条件として定義される予定である。この文書で述べている長期的将来の必要条件は、中期的な必要条件のおよそ 1 年後に適用される条件として定義されている。この期待される要件のデッドライン日付は進行状況によって調整され得る。
暗号化、構成、および制限モード サポートの必要条件については、暗号化サポート、構成、および制限モードに関する以降の各セクションで解説する。ピクセル フォーマット サポートの必要条件については、ここで解説する。
DirectX VA で作成されたデコード済み非圧縮ピクチャをアプリケーションで使用するには、それらのピクチャが認識可能なフォーマットで作成されている必要がある。DirectX VA アクセラレータがサポートする非圧縮ピクセル フォーマットのリストには、次のピクセル フォーマット リストのメンバが 1 つ以上含まれていなければならない (「YUV フォーマット」を参照)。
これらのフォーマットを定義する第 1 の目的は、使用されるフォーマットを文書化し、圧縮解除されたビデオをその後の処理に使用できるようにすることである (この処理では、ビデオを DirectDraw サーフェス テクスチャとして操作する)。第 2 の目的は、フォーマットの種類が増えることを防いで、ソフトウェア処理を単純化する (多種類のフォーマットを使うことによって同じ機能が重複することを避ける) ことである。
インターフェイスの操作中にレース コンディションが予期せぬ出来事を引き起こさないようにするための基本的な負担はハードウェア アクセラレータではなく、ホスト ソフトウェア デコーダ上にある。これに関してアクセラレータに負わされた要求は、非圧縮サーフェスの表示が停止しているか実行中かを問われたときに正しくレポートできる事と、要求された操作が完了したかどうかを問われたときに正しくレポートすることである。
ここでは、デコード処理において連続処理が確実に正しく実行されるよう、特定の必要条件が課せられている。これらの条件は、デコードおよび表示の際の、非圧縮サーフェスの取り扱いに関するものである。ここで挙げる例は、ブロック解除フィルタを使わない、一般的な I、B、および P 構造化ビデオ フレームのピクチャ デコードの取り扱いについての例である。ほかの状況でも、おおむね同じ原則が適用される。
原則は、次のように単純なものである : 参照や表示に必要なものにオーバーライドしないこと、レース コンディションを避けること。これは、次の 2 つのルールに分解できる。
これは次のの要件となる、ソフトウェア デコーダはアクセラレータの状態を問い合わせ レース コンディションを避けなければならない、そしてデコーダは十分な数の非圧縮サーフェスを使ってそのスペースがすべての必要な操作で利用可能でなければならない。
この結果、I、B、P ピクチャの処理には 4 つ以上の非圧縮ピクチャ サーフェスが必要となる。(より多い数が通常は期待されており、フロントエンド アルファ ブレンディングに使うようないくつかの操作では、より多くの数が必要である。)
以下の 2 つのサブセクションでは、B ピクチャのビデオ デコードにおける 4 つ以上の非圧縮サーフェスの使用について記述し、通常は 4 つ以上の非圧縮サーフェスが必要であり、ディレイを最小限に抑える必要がないアプリケーションでは 5 つ以上が推奨されることを結論付ける。追加サーフェスを使うことにより、解決しなければならない操作による待ち状態を著しく軽減させることができる。
圧縮バッファは圧縮サーフェスと同様に、割り当てられたバッファと同じものあるいはその同じサブセットを再利用するより、一般的にはすべての有効なすべてのバッファを繰り返し使った方が良いことに注意。それは不必要な依存性を待つために追加されたディレイを要求するボトルネックがおきる可能性があるからである。いくつかの場合、ドライバによる複数バッファの割り当てはダブルバッファやトリプルバッファの繰り返し使用が予期せぬ表示なしで操作する正しい方法であることを示す。(これは特にアルファ ブレンディング データ読み込みに適用する。)
1.3.3.1 デコードに 4 つの非圧縮サーフェスを使用する
図 1 に、特定の状況を仮定したビデオ デコーダを示す。このデコーダは、各ピクチャのデコードに 1 フレーム タイム要し、また P ピクチャの組の間に (最初の I ピクチャの後にある 0 個の B ピクチャから始まって) 増加し続ける B ピクチャを含むビットストリームをデコードしている。この例では、I、B、P の文字が各ピクチャのタイプを、下付き文字が各ピクチャの一時的な表示順序を、上付き文字がピクチャを保持するバッファを、それぞれ示している。各 B ピクチャをデコードするには、ビットストリーム順序で先行する 2 つのピクチャが必要である。その結果、デコーダは、2 番目のピクチャがデコードされるまで (デコードの 3 番目のタイム スライスに入るまで)、正しいタイミングでピクチャを表示し始めることができない。この 3 番目のタイム スライスのどこかで、正しいタイミングでのピクチャ表示を開始できる。
ピクチャ表示の開始は、通常、ピクチャが画面に現れるのと同時には実行されない。その代わり、新しいピクチャへの切り替えに適した時が来るまで、表示するよう命令されたピクチャに先行する別のピクチャが表示され続ける。このため、パフォーマンスを最適化するには、サーフェス 0 (最初の I ピクチャを保持する) はたとえ I ピクチャが必要なくても、3 フレームタイム後に来る B ピクチャによってオーバーライドされるべきではない。そうではなく、4 番目のサーフェス (サーフェス 3) は理想的には B ピクチャを保持するために用いられるべきだ。これによって B ピクチャをデコードする前に、最初の I ピクチャの表示ピリオドが完了してしまったかどうかをチェックする必要が無くなる。
上で与えられた 2 つのルールの応用は最初の 3 つのデコードされたピクチャが別のサーフェスに置かれなければならないということである、なぜならそのどれもが 3 番目のピリオド (ピリオド 2) の間には表示されてしまわないからである。次に4番目のデコードされたピクチャは理想的には4番目のサーフェスに置かれるべきである、なぜなら最初に表示されたピクチャは4番目のピリオド (ピリオド 3) の間には終了していないかもしれないからである。
図1 で起こり得る処理中の大きなボトルネックは、1 行に 2 つ以上の B ピクチャを持つ結果として、10番目のデコードされたピクチャ (B19) で起きる。連続シーケンスの 3 番目あるいはその次の B ピクチャが来たとき、1 つの B ピクチャの表示と次のデコードされた B ピクチャを保持するサーフェス使用の間のタイムラグ許容値は排除される。この状態では、ホスト デコーダは前のピリオドで表示された B ピクチャのディスプレイ状態 (この場合は、B17)をチェックしてディスプレイから削除されたことを確かめなければならない (必要ならこれを待つ)、次にすぐに同じサーフェスを使って次の B ピクチャ (この場合は、 B19 に使われているサーフェス 1) をデコードしなければならない。参照 I ピクチャあるいは P ピクチャ(この場合は、サーフェス 0 と 2、これらは P06 と P210 に使われている) を保持するために使われてるどちらのサーフェスでも新しい B ピクチャをデコードすることはできない、そして同じインターバル タイム注に表示されているサーフェス (この場合、 B38 に使われているサーフェス 3 ) で新しい B ピクチャをデコードはできない。従って直前のピリオドで表示されたサーフェスを使わなければならない (この場合は、サーフェス 1)。
デコード処理 | I00 | P11 | P23 | B32 | P06 | B14 | B35 | P210 | B17 | B38 | B19 | P015 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
表示処理 | I00 | P11 | B32 | P23 | B14 | B35 | P06 | B17 | B38 | B19 | ||
デコードされたフレーム* | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 |
デコード処理 | B311 | B112 | B313 | B114 | P221 | B316 | B117 | B318 | B119 | B320 | P028 | ... |
表示処理 | P210 | B311 | B112 | B313 | B114 | P221 | B316 | B117 | B318 | B119 | B320 | ... |
デコードされたフレーム* | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | ... |
* インターバルの開始点。 |
図 1 -- 4 フレーム デコーダ バッファリング (右上の数字はバッファ ナンバー、右下の数字はディスプレイ インデックス)
1.3.3.2 デコードに 5 つ以上の非圧縮サーフェスを使用する
バッファを 5 つ以上使用できるため、バッファの表示開始と同バッファへの新しい書き込みの時間差を、最低 1 表示周期から 2 以上に広げることができる。これにより、デコード処理のタイミングにより大きなジッタを許可することができる。また、デコード済みピクチャの出力処理で、表示処理の一環として 3 フィールドの非インターレース処理を実行できる (現在のピクチャだけでなく前のピクチャも表示に利用可能なので、前のピクチャを使って、コンテキストを提供したり、実際の表示処理で 1 フィールドのディレイを許したりすることができるため)。それはまた誤って設計されたハードウェア ドライバに対していくつかの免責を提供する、それはピクチャが実際にまだ表示されているかそうではないのかを正しく認識しないで書かれているドライバである (そのような状態を提示しないハードウェア ドライバに正しくは依存するべきではないけれども)。B ピクチャに DirectX VA を効率よく使用するには、バッファが少なくとも 4 つあれば足りると考えられる。ただし、ディレイの抑制が要件とされない場合には、5 つ以上のバッファの使用を推奨する。I、B、P 構造化されたビデオ デコーディング用のDirectX VA デコーダはそれゆえ、非圧縮サーフェスを割り当てるとき、その最小と最大の要求可能な非圧縮サーフェス割り当て数を少なくともそれぞれ 4 と 5 に設定すべきである。1 つ以上の追加非圧縮サーフェスを使うことはスムースで、信頼性高く、ティア フリーの操作を得る良い方法であることが多い。
' ' 2 進値 (左のビットが MSB)
" " 10 進値
0x 16 進値
LSB 最下位ビット (Least Significant Bit)
MSB 最上位ビット (Most Significant Bit)
// 0 と逆方向に丸める区切り
/ 0 方向に切り捨てる区切り
この仕様書では、ビット番号を Microsoft で普及している規則に従って表現する。この規則では、LSB がビット 0 、MSB がビット N-1 となる (ビット数が N の場合)。
注 : ビデオ コーディング規格には、最も若い番号のビットが MSB とされるものがあり、その場合はこの番号付け規則とは異なる。
ただし、この文書で構造体内に 8 ビット未満のフィールドのシーケンスが現れる場合、その順序はビデオ コーディング規格で使用されている規則に従う。つまり、最初にリストされる要素が MSB に最も近い位置にあるものと見なされる。たとえば、単一ビットの配列要素 5 つを構造記述内に並べる場合には、構造記述内にインデックスが減少する順序で各要素がリストされる。
このアプローチに見られる分裂的現象は、このインターフェイス仕様の各ビットがどこに位置するのかを決める最終的な権限が、この文書でなく、このインターフェイスに関連付けられる ".h" ファイルにあるものと見なしたほうがよいことを意味する。
参照ブロック - 参照フレーム バッファから抽出されたブロック領域。
予測ブロック - 参照ブロックからフィルタされたブロック。
予測プレーン - マクロブロック予測を結合する前に形成されるサンプルの配列。各プレーンは、通常 1 つのフレーム ロケーションから集められた、一連の予測ブロックを表す。プレーンが結合されて、単一のマクロブロック予測を形成する。
予測マクロブロック - すべての色チャンネルを含むマクロブロック予測。
成分 - 3 つの色チャンネル {Y, Cb, Cr } の 1 つ。
ホスト CPU - ビデオ デコードの機能全体 (上位処理) を制御する、プログラム可能なプロセッサ。
アクセラレータ - IDCT、MCP、表示フォーマット変換といった、単純だが頻繁に実行される処理を実行する機能単位。
動きベクトル計算 - 動きベクトルを予測ブロック アドレスに変換する処理。
予測アドレス - 実装固有の設計の中で、予測ブロックのある位置。
合成予測ブロック - 属性が輝度と色光度の両方に適用される予測ブロック。
成分予測ブロック - 属性が輝度か色光度のどちらかに適用される予測ブロック。
イントラ (フレーム内) - デコード済みのピクチャを参照した予測を行わないピクチャ コンテンツの表現。
インター (フレーム間) - まずデコード済みのピクチャを使ってピクチャの 1 領域の予測をエンコードし、その後必要に応じて予測からの偏差を表す信号を追加するピクチャ コンテンツの表現。
残差デコード - 必要に応じて、動き補償予測後に残っている信号を表現するため、エンコードされた誤差信号を表す波形をデコードすること。この結果、非予測波形の "イントラ" 表現だけが使用される場合と、予測後の "インター" 差異が使用される場合がある。
ReservedBits - この仕様で名前または名前の一部に ReservedBits が含まれているフィールドは、現在この仕様では使用されていないため、値は 0 でなければならない。
〜ほうがよい - 推奨される (必須ではない) 動作の記述に使用される表現。
〜ならない - 必須 (または禁止された) 動作の記述に使用される表現。
次の図に示すステージは、MCP および IDCT アクセラレータで構成されている。
図 2 -- デコーダのステージ
すべてのピクチャ バッファは、MPEG-2 仕様どおり、フレームで構成されたバッファを保持していると見なされる。アドレス単位は、特に指定がない限りフレーム座標で設定しなければならない。フレーム座標で記述された予測ブロックを、実装固有の変換レイヤを使って、損失なしにフィールド座標に変換することができる。たとえば、単一フレームの動き予測は、上下 2 つの個別のマクロブロック部分予測に分割できる。
3 つのビデオ成分チャンネル {Y, Cb, Cr} は、この仕様で定義されたインターフェイスによってアクセスされる。2 つの色光度成分の動きベクトルは、輝度成分に送られたベクトルから派生する。これらの動きベクトルは、アクセラレータによって別の座標システムに変換される。
図 3 -- ホストおよびアクセラレータのシステム
以下に、H.261、MPEG-1、MPEG-2 (MPEG-2)、H.263、および MPEG-4 の基本処理を年代順にリストし、この仕様を使ってどのように実現できるかを簡単に説明する。
正式には "Video CODEC for Audiovisual Services at px64 kbit/s" と呼ばれる ITU-T 勧告 H.261 は、比較的高い圧縮率を持つ実用的な設計としては最初のデジタル ビデオ コーディング標準規格であった (最初のデジタル ビデオ コーディング標準規格である H.120 は既に忘れられている)。また、Y、Cb、Cr 成分を使った 8 ビット サンプル、4:2:0 サンプリング、16×16 "マクロブロック" ベースの動き補償、8×8 IDCT、係数のジグザグ逆スキャン、スカラー量子化、値 0 の RLE (run-lengths) および量子化インデックス値の組み合わせに基づく係数の可変長コーディングといった、ほかのビデオ CODEC 標準で後に使用されるのと同様の基本設計が使用されていた。すべての H.261 予測ブロックは、先行するピクチャから順方向のみの予測を使用する。H.261 はハーフサンプル精度の予測フィルタを持たないが、その代わりに "ループ フィルタ" と呼ばれる低パス フィルタの一種を使用する (H.261 仕様のセクション 3.2.3)。このフィルタは、各マクロブロックの動き補償予測中にオン/オフできる。
補遺 D グラフィック : H.261 は後に、"補遺 D グラフィック転送" と呼ばれる興味深いトリック モードを取り入れた。このアクセラレータ インターフェイスでは、この機能に対する特別なサポートは提供されていない。この仕様を使ってこの機能をサポートするには、デコードされた 4 つのピクチャをアクセラレータからホストに読み戻し、そこでインターリーブして、高解像度のグラフィック ピクチャとして表示することができる。
正式には ISO/IEC 11172-2 と呼ばれる MPEG-1 ビデオは、H.261 からほどなくして、H.261 の設計の多くを取り入れて設計された。ループ フィルタはなく、その代わりに、フレーム間のサブピクセルの動きを解決するためのシンプル ハーフサンプル フィルタを持つ。追加された双方向予測モードおよび逆方向予測モードでは、参照フレームが 1 つ余分にバッファされる必要がある。双方向予測は、順方向に予測された予測ブロックと逆方向に予測された予測ブロックの平均を取る。順方向と逆方向の予測ブロックを平均化する計算は、ハーフサンプルされた "補間" 予測ブロックの作成に似ている。その他の基本構造は H.261 と同様である。
正式には "Information Technology - Generic Coding of Moving Pictures and Associated Audio Information : Video" ITU-T 勧告 MPEG-2 | ISO/IEC 13818-2 と呼ばれる MPEG-2 は、非常に下位の層から見れば、既存の MPEG-1 のツールに、基本的な 16×8 形状を追加しただけの仕様である。少し上位の層から見れば、MPEG-2 には、インターレース ビデオの特性を取り扱うために、複数のフィールドから参照した予測を組み合わせる多くの方法が追加されている。
MPEG-2 フレーム構造化ピクチャ :
MPEG-2 フィールド構造化ピクチャ :
正式には "Video Coding for Low Bit Rate Communication" と呼ばれる ITU-T 勧告 H.263 は、H.261、MPEG-1、MPEG-2 と比較して圧縮パフォーマンスが向上した、比較的新しいビデオ コーダである。H.263 の最も基本的なフォーマットだけをサポートする、"ベースライン" モード処理を含む。また、各種の目的に使用できる多数のオプション拡張モード処理も含む。(1995 年後半に承認された初期バージョンでは、オプション モードは 5 つであったが、1997 年に技術的に完成した 2 番目のバージョンではいくつかのモードが追加され、2000 年にはさらにいくつかが追加される。) このインターフェイスでは、ベースライン H.263 予測は MPEG-1 機能のサブセットを使って動作する。ベースライン モードには順方向予測のみが含まれる。双方向予測は含まれていない。
丸め制御 : H.263 オプション モードの中には、丸め制御を必要とするものがある。この仕様では、丸め制御は bRcontrol フラグによってサポートされる。
H.263 補遺 D で定義されているように、H.263 オプション モードの中には、ピクチャの境界の外にアドレスする動きベクトルを許可するものがある。この仕様では、この機能は、アクセラレータがそのような動きをサポートする必要があるかどうか指定する bPicExtrapolation フラグによってサポートされる。そのような動きをサポートするには、2 つの基本的な方法がある : 1) 各サンプル フェッチのアドレスの値をクリッピングし、ピクチャの境界内に収まるようにする。2) 複製したサンプルをピクチャにパディングし、ピクチャの各境界にわたるマクロブロックの幅と高さによって使用されている実際のメモリ領域を広げる。結果はどちらも同じであるため、アクセラレータはどちらの方法でも使用できる。
双方向動き予測 : いくつかのオプション H.263 予測処理で使用されている双方向動き予測では、MPEG-1 とは異なり、丸め演算子として、丸めでなく切り捨ての区切りが使用される。この仕様では、この機能は、bBidirectionalAveragingMode フラグによってサポートされる。
4 MV 動き補償 (4MV) : H.263 の各マクロブロックのサイズは 16×16 であるが、補遺 F および J といったいくつかの H.263 のオプション モードでは、単一のマクロブロックに 4 つの動きベクトルが送信されることを許可する (マクロブロック内の各 8×8 輝度ブロックに 1 マクロブロック)。対応する 8×8 色光度領域は、派生した単一の動きベクトルを使用する。
重複ブロック動き補償 (OBMC : Overlapped Block Motion Compensation) : H.263 の 補遺 F は、4MV サポートのほかに、輝度サンプルの OBMC も含んでいる。この仕様では、OBMC 予測は、12 の動きベクトルをマクロブロックの順方向予測に送信することを許可することによってサポートされている。
OBMC 予測ブロックは、この仕様で与えられたツールによって、3 つのプレーンに構成された予測の組合せとしてハードウェア内で実現される。3 つのプレーンとは、現在のプレーン ("0")、上/下プレーン ("1")、および 左/右プレーン ("2") である。3 つのプレーンは、H.263 セクション F.3 で定義された q(x,y)、r(x,y)、および s(x,y) ブロックの一時記憶域として使用される。3 つのプレーンの 4 ブロックすべてが埋められると、H.263 セクション F.3 の式に従って結合され、H.263 の 図 F.2、F.3、F.4 で示された個々の H 行列によって重みが付けられる。
たとえば、OBMC 輝度マクロブロック予測は、8×4 形状の上/下予測ブロック 8 つ、4x8 形状の 左/右ブロック 8 つ、および 8×8 形状の現在のブロック 4 つで構成される。4 つのプレーン 0 動きベクトルが同じ動きベクトルを持っている場合 (4MV マクロブロックでない場合) は、単一の 16×16 マクロブロック予測を使って 16×16 プレーン 0 全体を埋めることができる。
この仕様での OBMC 処理の表現に関しては、10 個の動きベクトルがマクロブロックに送られる。最初の 4 つは現在のマクロブロックの Y0、Y1、Y2、Y3 ブロック用である。次にマクロブロックの上側の左半分および右半分のリモート ベクトルが送られる。その後マクロブロックの左側の上半分および下半分のリモート ベクトル、最後にマクロブロックの右側の上半分と下半分のリモート ベクトル、と続く。(H.263 では、マクロブロック下側の左半分と右半分に別個のリモート ベクトルが使用されず、現在のマクロブロックのベクトルが再利用される。)
図 4 -- OBMC 予測プレーン内の 1 つの 8×8 ブロックの H.263 登録
P-B フレーム (補遺 G & M) : このモードでは、P フレームおよび擬似 B フレームのマクロブロックは、まとめて一意の "PB フレーム" ピクチャ コーディング タイプに多重化される。各マクロブロックの B フレーム部分は、マクロブロックの P フレーム部分用にエンコードされた情報を取り入れる。B 部分の順方向および逆方向動きベクトルは、P 部分のベクトルからスケールされ、再構築された P 部分のマクロブロックは、B 部分の逆方向参照として使用される。逆方向マクロブロックは同じ PB マクロブロックに含まれる再構築された P マクロブロックしか参照できないため、PB には擬似 B フレームだけが含まれる。ただし従来の B フレーム セマンティクスと同様、PB フレーム内の B マクロブロックは、順方向参照フレーム内のどの場所でも参照できる。
逆方向参照に関するこの制限により、H.263 図 G.2 に示されているような、小さなサイズの逆方向予測ブロック形状が作成される。この仕様では、PB フレームを、2 つの動きベクトルを持つ個別のマクロブロック タイプとしてラベリングすることによってサポートしている。
ブロック解除フィルタ (補遺 J) : この仕様には、ブロック解除フィルタをアクセラレーションするための特別なコマンドが定義されている。このコマンドは、補遺 J と同様にループ内で使用するか、または H.261 ピクチャや H.263 ベースライン ピクチャの場合のようにループ外で使用する。ホスト CPU は、GOB またはスライス セグメントを監視するブロック解除コマンドを、必要に応じて作成しなければならない。
参照ピクチャ選択 (補遺 N および U) : 各予測ブロックのピクチャ インデックス選択フィールドを使うアクセラレータによって、複数の参照フレームがサポートされる。
スケーラビリティ (補遺 O) : この仕様のツールでは、一時スケーラビリティ、SNR スケーラビリティ、および空間スケーラビリティがサポートされる。この仕様の H.263 空間スケーラビリティ B フレームは、MPEG-1 の B フレームに非常に似ている。空間スケーラビリティでは、下位層の参照ピクチャをアップサンプルしたうえで、アップサンプルされたピクチャを参照として使用する必要がある (ほかのすべての側面では、SNR スケーラビリティおよび一時スケーラビリティと基本的に同一である)。H.263 の切り捨てには、適切な双方向平均化丸め制御を設定したほうがよい (MPEG-1 および MPEG-2 は上方バイアス平均化を使用し、H.263 は下方切り捨て平均化を使用する)。
参照ピクチャの再サンプリング (補遺 P) : この補遺の単純なフォーマットが、参照バッファの再サンプリングによってサポートされている。より豊富なフォーマットの補遺 P 再サンプリングについては、参照フレームとして使用される再構築されたフレームが、外的方法によって再サンプリングされ、アクセラレータからアドレス可能な参照フレーム バッファとして格納される必要がある。
解像度低減更新 (Reduced-Resolution Update) モード (補遺 Q) : H.263 の解像度低減更新モードでは、ブロック解除フィルタの別フォーマットおよび高度予測 OBMC (Advanced Prediction OBMC) の別フォーマットである、あまり一般的でない残余アップサンプリング条件が要求されるため、この仕様では現在サポートされていない。ただし、ブロック解除フィルタ (Deblocking Filter) モードがアクティブで、高度予測 (Advanced Prediction) モードがアクティブでない状態での処理は、ホストベースの IDCT 処理によって、このインターフェイスでもサポートできる可能性がある。
独立セグメント デコード (補遺 R) : 独立セグメント境界の下位およびアクセラレータ対応は存在しない。補遺 R のいくつかのフォーマットは、特別な処理なしにサポート可能である (ベースラインと 補遺 R の組み合わせなど)。ピクチャ セグメントの外挿を必要とする補遺 R のフォーマットは、各セグメントをピクチャとしてデコードし、その後それらの小さなピクチャから完全な出力ピクチャを構築することによってサポート可能である。
その他の H.263 オプション機能 : その他の H.263 オプション機能は、アクセラレータのインターフェイスに影響を与えることなくサポート可能である。たとえば、補遺 I、K、S、および T は、ホスト側の処理を変更することで、アクセラレータに影響を与えずに簡単に処理できる。
特定の IDCT : このインターフェイスでは、新しい H.263 オプション機能として近い将来追加されると思われる、特定の IDCT のサポート仕様が考慮されている。
MPEG-4 は、プログレッシブ スキャン コーディングについては H.263 の規格、インターレースおよび 4:2:0 以外のカラー サンプリング フォーマットのサポートについては MPEG-2 の規格を大幅に取り入れている。この仕様にある、H.263 および MPEG-2 をサポートする機能は、MPEG-4 をサポートするために使用できる。1 ピクセルに対して 8 ビット以上をサポートするために、BPP パラメータが用意されている。シェープ コーディング、オブジェクト回転、フェース モデリング、メッシュ オブジェクト、スプライトといった MPEG-4 に固有の機能は、現在のインターフェイスではサポートされない。ただし、将来開発されるバリエーションで追加される可能性がある。
ブロック動き補償予測 (MCP) は、MPEG および H.26x ファミリの CODEC に、JPEG のような純粋な静止フレーム コーディング方法にはない利点を提供する基本ツールである。一般的な予測の例は、CODEC のさまざまなステージにあるが、MCP は最も多くの処理を必要とする。動きベクトル、DCT 係数、その他 MCP 処理の直接の一部でない要素も、転送後の状態をよりコンパクトにするために予測を利用する。これらの予測の例は、この仕様では解説しない。またこれらは、ホスト CPU プロセッサまたはビットストリーム パーサー/可変長デコード装置で実行されるものと見なす。
一般的な予測コーディング スキームでは、先に転送およびデコードされた要素が、現在の要素の予測として使用され、予測値と現在の要素の実際値との差異が予測誤差として送られる。転送された差異情報によって、正しい値、または必要とされる値に十分近い値 (MCP の場合) に、予測が更新される。先にデコードされたフレームは、将来のフレームがどのように見えたほうがよいかを予測 ("推測") するために使用される。その後差異データ (予測誤差) が推測を修正し、予測と予測誤差を組み合わせた (再構築された) イメージを、圧縮前のオリジナルの将来のフレームにできるだけ近付けようとする。
再構築が終わった現在の要素は、格納され、将来の要素の予測に使用される。この繰り返しのループは、予測される要素固有の各種のリセットによって壊される場合がある。リセットは、デコード処理のセマンティクスによって記述される。たとえば、動きベクトルや DC 係数予測はスライスでリセットされ、一時フレーム予測チェーン全体は、イントラ リフレッシュ フレームによってリセットされる。一時基本予測ループはこの記述に適合するが、予測として使用されるフレーム全体から取り出された修正データと共に動作する。予測として使用される参照フレームからのデータは、動きや、その他時間と共に生ずる変更内容に合わせて修正される。
図 5 -- 一般的な MCP 信号の流れ
この仕様書の目的上、MCP によるマクロブロック予測の構造は、それぞれ独立した一連のフェーズとして説明しなければならない。この点を認識していると、この仕様書での MCP 処理に関する記述のフォーマットが理解しやすくなる。
図 6 -- MoComp3 予測ブロックの信号の流れ
ステージ 1. 参照フレームの形成
注 : 必要に応じて入力ピクチャの再サンプリングが含まれる場合がある。
図 7 -- MCP での予測データの進化
ステージ 2. 参照ブロック
参照ブロックは、予測ブロックと同じであるとは限らず、予測フィルタリング ステージで必要となる追加サンプルで構成される場合が多い。参照ブロックは、実装固有のピクチャ バッファ保持方法を反映した性質を持つことが多いため、この仕様書では定義していない。メモリ単位内でハーフサンプル フィルタリングが実行されない限り、16×16 ハーフサンプル フィルタされたマクロブロックの参照ブロックは、17x17 の形状を持つ。参照ブロックのサイズは、予測ブロックの大きさの関数でもあり、予測ブロックのフィルタ属性でもある。この仕様書では、参照ブロックは、動き補償予測 (MCP) で使用するために、参照フレーム バッファから抽出されたデータのブロックを参照しなければならない。
ステージ 3. 予測ブロック
フィルタされた参照ブロックの結果。
ステージ 4. 結合されたマクロブロック予測
1 つまたは複数の予測ブロックの平均化処理の結果。
マクロブロックは、さまざまな性質を持つ領域を区分するために、通常のセグメントに分割される。
図 8 -- 基本的なマクロブロック分割スキーム
MPEG-2 では、マクロブロックの上部分と下部分が、時間的に離れた (最大 1/50 秒) インスタンスからキャプチャされた 2 つの異なるフィールドからのラインを表す。このため、マクロブロックの担当部分であるフレーム領域の 2 つのフィールド間に大きな動きがあった場合は、上部分と下部分に、相互関連性がまったくない内容が入る場合がある。予測の垂直方向の細分度を細かくするため、フィールド構造化ピクチャに 16×8 スキームが追加される。
図 9 -- MPEG-2 マクロブロックの 2 つの 16×8 部分
マクロブロックのパーティション分割によっても予測の細分度が細かくなり、動きの速度が異なる場合でも、エッジや小さなオブジェクトがより適切に表現される。予測ブロック自体は、未完成な、近似された形状であり、予測ブロックが表現するマクロブロックの部分に属するすべてのサンプルについての、ある種の平均的動きベクトルを表現している。サンプルまたはサブサンプルが各自の動きベクトルを持つことが理想的であるが、そうすると非常に大量のビットを消費し、処理のオーバーヘッドも増加する。予測ブロックは適切な程度の近似状態を維持する。
予測ブロックは、マクロブロックの 1 つの部分のみに対して働く。予測ブロック全体は、マクロブロックの 16×16 領域を担当する。これは、すべての H.261 および MPEG-1 予測で共通である。MPEG-2 では、マクロブロックのデュアル フィールド/フレームという性質に対応するため、16×8 予測形状が採用された。MPEG-2 フィールド構造化ピクチャで使用して予測の細分度を細かくするために、16×8 形状も取り入れられた。8×8 形状は H.263 (高度予測)、H.264、および MPEG-4 で使用されている。現在最も細分度が細かいのは、将来の "H.26L" 4×4 予測ブロック形状のドラフトである。
通常色光度予測ブロックは、対応する輝度予測ブロックに比べ、水平方向にも垂直方向にも半分のサイズであり、輝度に使用されたのと同じベクトルを共有する。これは、この仕様書で扱っている標準規格では、動きを常に成分平面に共存するものとしているためである。このため、それぞれの輝度および色光度サンプルのディメンションの違いを調整するため、色光度ベクトルは、何らかの手段によって輝度ベクトルからスケールされる。MPEG-2 の 16×8 輝度予測ブロックには、対応する 8×4 色光度形状がある。輝度予測ブロックが小さくなりすぎると、例外が多々発生する。たとえば、H.263 の高度予測モードでは、色光度予測ブロックの形状は 8×8 のままで、色光度動きベクトルは、4 つの 8×8 輝度動きベクトルの平均から派生する。この文書の多くの部分では、予測ブロック、プレーン、およびマクロブロックの、輝度の範囲のみについて述べる。特に明記しない限り、色光度については類推すること。
図 10 -- MPEG-2 マクロブロック予測プレーン
上の図は、最終的なマクロブロック予測を形成する前に存在する、概念的なマクロブロック予測プレーンを示している。MPEG-2 には、順方向および逆方向 (双方向予測)、または同パリティおよび逆パリティ (デュアル プライム) の 2 つのプレーンがある。MPEG-1 および MPEG-2 では、単純な平均化処理によってプレーンが結合される。H.263 の重複ブロック動き補償予測 (Overlapped Block Motion Compensation Prediction) といった、より洗練された予測スキームの場合は、3 つのプレーンがある。将来は、最大 8 またはそれ以上の予測プレーンを、より洗練されたフィルタを使って結合するコーディング方法が採用される可能性がある。
アプリケーションのセキュリティ要求によっては、ビデオのデコードに使用されるデータの一部の暗号化が必要になる場合がある。そのようなアプリケーションをサポートするため、この仕様では、Direct VA データの暗号化が、その処理に定義された次の 3 つのデータ構造体に適用できるようになっている。
ただし暗号化は、DirectX VA 処理の、中期的将来に向けたオプションである。すべてのアクセラレータは、暗号化を使用せずに処理を実行できなければならない。いくつかの暗号化プロトコルは、長期的将来には必要条件となる予定である。
内容を保護するためには、クリアテキスト データ処理のためのホストベースのソフトウェアとデータをわかりにくくすること、および暗号化処理を実行することが重要である。このような保護は、アクセラレータ側の暗号解読処理についても同様に重要である (暗号解読がハードウェアベースの処理である場合も同様)。
ホスト デコーダ ソフトウェアが暗号化を利用するには、アクセラレータがどのタイプの暗号化をサポートしているかを判断する必要がある。アクセラレータがサポートしている暗号化のタイプに関する基本情報は、ビデオ アクセラレータ タイプ GUID としてホストに供給される暗号化タイプ GUID のリストに含まれている。("暗号なし" の GUID である DXVA_NoEncrypt は、そのサポートが暗黙な必須条件になっているため、このリストで送信してはならない。)
ホストが、適用する暗号化プロトコルのタイプを選択し、セクション 3.2 で記述したように、GUID を通じてその選択肢をアクセラレータに指示する。典型的な暗号化の処理では、暗号化データを正しく転送するために、転送前にさらに次の 2 つの手順を実行する必要がある。
暗号化プロトコルを初期化するのに必要な手順の正確な数は、使用される暗号化のタイプによって異なる。暗号化処理の初期化のためにホストとアクセラレータの間で交換される各データ セットには、データの暗号化タイプを区別するため、暗号化プロトコル タイプ GUID が接頭辞として付いていなければならない (あるタイプの暗号化をあるタイプの DirectX VA バッファに使用し、ほかのタイプの暗号化をほかのタイプの DirectX VA バッファに使用する場合など)。
暗号化データ セットは、次によって指定される、実行されている処理が暗号化プロトコルであるという指示と交換される。
DXVA_EncryptProtocolFunc {
EncryptProtocolFlag, // 24b
bDXVA_Func // 8b
}
EncryptProtocolFlag : 実行されている処理が暗号化プロトコル トランザクションであることを、24 ビットで示す。EncryptProtocolFlag は、ホスト ソフトウェア デコーダにより送信されるときには 0xFFFF00 と等しく、アクセラレータにより送信されるときには 0xFFFF08 でなければならない。
bDXVA_Func : 暗号化プロトコルを適用する DirectX VA の bDXVA_Func 機能を示す。現在この文書で定義されているように、暗号化サポートを要求する bDXVA_Func の値は 1 だけである。
ホストとアクセラレータの間でやり取りされる実際のデータ セットには、次のヘッダー情報が含まれていなければならない。
DXVA_EncryptProtocolHeader {
dwFunction, // 指示された処理
dwReservedBits[3], // 3 * 32b アラインメント
guidEncryptProtocol // 128b
}
dwFunction : 内容が暗号化プロトコルに関するものであることを示す DXVA_EncryptProtocolFunction が含まれる。
guidEncryptProtocol : 暗号化プロトコルに関連付けられた GUID が含まれる。
デコーダがこの API を使って動作するためには、デコーダとビデオ アクセラレータの間で、処理における次の 2 つの側面について共通の認識が成り立っている必要がある :
DirectX VA のグローバル接続パラメータは、次の接続制限モードである。
DXVA_ConnectMode {
guidMode, // 128b
wRestrictedMode // 16b
}
guidMode : 使用される制限モード プロファイルに関連付けられた GUID。
wRestrictedMode : 接続制限モードを示す数値による識別子 (セクション 4 を参照)。
構成を必要とする個々の DirectX VA 機能 (bDXVA_Func の特定値) の構成を確立する処理は、次のように実行される。
特定構成サポートのプローブは、構成をプローブする特定 bDXVA_Func に対応するプローブ コマンドを、アクセラレータに送信することによって実行される。プローブ コマンドと共に、プローブでサポートの有無を判断する構成を記述する (DXVA_Func の値に固有の) 構成データ構造体が送信される。アクセラレータは、指定された構成をサポートしているかどうかを示す S_OK または S_FALSE を返す。さらに、代替として提案される構成も返す場合がある。
特定構成へのロックは、その構成にロックする特定 bDXVA_Func に対応するロック コマンドを、アクセラレータに送信することにより実行される。ロック コマンドと共に、サポートされている場合にロックする構成を記述する (bDXVA_Func の値に固有の) 構成データ構造体が送信される。アクセラレータは、指定された構成をアクセラレータがサポートしているかどうかを示す S_OK または S_FALSE を返す。S_OK の場合は、使用に備え、指定された構成にロックされる。S_FALSE の場合は、代替として提案される構成が返される。
デコーダは、指定された構成を調べるプローブ コマンドを事前に送信せずに、ロック コマンドを送信する可能性がある。アクセラレータは、特定の構成を調べるプローブ コマンドに S_OK を返した場合は、同じ構成へのロック コマンドにも、特に明記されていない限り S_OK を返さなければならない。
ロック コマンドを送信し、許可を示す結果が返されて使用が認められると、指定した構成にロックされる。これ以後、同じ値の bDXVA_Func に対応するプローブ コマンドまたはロック コマンドが、デコーダから送信されてはならない。
すべての DirectX VA ソフトウェア デコーダが、すべての DirectX VA アクセラレータと共に動作できるように、特定の bDXVA_Func を使用するあらゆるソフトウェア デコーダがサポートしなければならないすべての構成のセットとして、最小限の相互動作性構成セットが定義される。bDXVA_Func のサポートを示すすべてのアクセラレータは、関連付けられたビデオ アクセラレータの GUID を公開することにより、最小限の相互動作性構成セットのうち少なくとも 1 つのメンバをサポートしなければならない。場合によっては、補足的な推奨構成セットも定義される可能性がある。
プローブおよびロックは、プローブ コマンドまたはロック コマンドで送信されるデータ構造体の最初のメンバとして渡される DXVA_ConfigQueryOrReplyFunc により制御される。
DXVA_ConfigQueryOrReplyFunc {
QueryOrReplyFlag, // 24b
bDXVA_Func // 8b
}
QueryOrReplyFlag : 指定する照会または応答のタイプ。以下のように定義される。
bDXVA_Func : 同時に送信された構成が適用される bDXVA_Func 機能。
DirectX VA は主として、データのバッファをホストからアクセラレータに渡すことによって動作する。DXVA 機能のパラメータ (bDXVA_Func) により、渡される可能性があるバッファのタイプ、および実行される DXVA タスクが決定する。次のような各種バッファ タイプがここに定義されている。
バッファの 1 セットがホストからアクセラレータに渡されるとき、それらのバッファに関する追加データも渡される。この追加データのことを、バッファ記述リストと呼ぶ。バッファ記述リストは、順序付きリストで構成されている。このリストは、先に列挙した最初のタイプの最初のバッファで始まり、次は同タイプの次のバッファと続き、その後次のタイプの最初のバッファ、というように移っていく。リストの各メンバは、次のように定義されたデータ構造体で構成されている。
DXVA_BufferDescription {
dwTypeIndex, // 32b
dwBufferIndex, // 32b
dwDataOffset, // 32b
dwDataSize, // 32b
dwFirstMBaddress, // 32b
dwNumMBsInBuffer, // 32b
dwWidth, // 32b
dwHeight, // 32b
dwStride, // 32b
dwReservedBits // 32b
}
dwTypeIndex : このセクションで前述したリストにある、該当するバッファのタイプ番号。
dwBufferIndex : 同じバッファ記述リスト内で渡される同じタイプのバッファ内でのバッファのシーケンス番号。
dwDataOffset : バッファの先頭からの該当データのオフセット (バイト単位)。0 でなければならない。
dwDataSize : バッファ内の該当データの量 (バイト単位)。つまり、バッファ内容の最後のバイトの位置は、dwDataOffset + dwDataSize - 1 で与えられる。
dwFirstMBaddress : ラスタ スキャン順序で表した、バッファ内の最初のマクロブロックのマクロブロック アドレス (0 は左上マクロブロックのアドレス、PicWidthInMBminus1 は右上マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB は左下マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB + PicWidthInMBminus1 は右下マクロブロックのアドレスとなる)。データ バッファが、ピクチャ デコード パラメータ、逆量子化行列、スライス コントロール、ビットストリーム データ、AYUV、IA44/AI44、DPXD、ハイライト、DCCMD のいずれかのタイプである場合は、0 でなければならない。もしそのデータ バッファが残差ブロック バッファなら、dwFirstMBaddress は対応するマクロブロック コントロール コマンド バッファと同じ値を持つべきである。
dwNumMBsInBuffer : バッファ内のデータのマクロブロック数。データ バッファが、ピクチャ デコード パラメータ、逆量子化行列、AYUV、IA44/AI44、DPXD、Highlight、DCCMD のいずれかのタイプである場合は、0 でなければならない。データバッファがマクロブロック コントロール バッファなら、dwNumMBsInBuffer は MBskipsFollowing の値とマクロブロック コントロール ブロック バッファ内のマクロブロック コントロール コマンドの総数の和と等しいべきである。データバッファが残差ブロック データ バッファなら、dwNumMBsInBuffer は対応するマクロブロック コントロール コマンド バッファと同じ値を持つべきである。データバッファがスライス コントロール コマンド バッファなら、dwNumMBsInBuffer はスライスコントロールバッファ内の wNumberMBsInSlice の総数と等しいべきである。データバッファがビットストリーム データ バッファなら、dwNumMBsInBuffer は対応するスライス コントロール コマンドバッファと同じ値を持つべきである。
dwWidth、dwHeight、dwStride : バッファ内のデータの幅、高さ、およびストライド。データ バッファが IA44/AI44 または DPXD のいずれかのタイプでない限り、0 でなければならない。適用されるバッファ タイプに対しては、アクセラレータが実行するバッファ割り当てセットアップによって dwStride が決定される。
注: デコーダは IA44/AI44 あるいは DPXD に指定されているストライドを守ることに必ず注意しなければならない。
DirectX VA 処理のために定義された最初の関数タイプは、圧縮ピクチャの一部または全部のデコードである。
圧縮ピクチャをデコードするための DirectX VA 接続構成データ構造体は、次のように定義されなければならない。
DXVA_ConfigPictureDecode { dwFunction, // 指定された処理 32b dwReservedBits[3], // 3 * 32b アラインメント guidConfigBitstreamEncryption, // 暗号化タイプの GUID 128b guidConfigMBcontrolEncryption, guidConfigResidDiffEncryption, bConfigBitstreamRaw, // ビットストリーム処理 8b bConfigMBcontrolRasterOrder, // マクロブロック制御 8b bConfigResidDiffHost, // ホスト残差 8b bConfigSpatialResid8, // 8b bConfigResid8Subtraction, // 8b bConfigSpatialHost8or9Clipping, // 8b bConfigSpatialResidInterleaved, // 8b bConfigIntraResidUnsigned, // 8b bConfigResidDiffAccelerator, // アクセラレータ残差 8b bConfigHostInverseScan, // 8b bConfigSpecificIDCT, // 8b bConfig4GroupedCoefs // 8b }
dwFunction : 構成データの構造を記述する DXVA_ConfigQueryOrReplyFunc を含む。
guidConfigBitstreamEncryption : ビットストリーム データ バッファの暗号プロトコル タイプに関連付けられた GUID を表す。DXVA_NoEncrypt という値 (関連付けられたヘッダー ファイル内に定義された GUID 名) は、暗号が適用されていないことを意味する。bConfigBitstreamRaw が "0" の場合は、DXVA_NoEncrypt でなければならない。
guidConfigMBcontrolEncryption : マクロブロック制御データ バッファの暗号プロトコル タイプに関連付けられた GUID を表す。DXVA_NoEncrypt という値 (関連付けられたヘッダー ファイル内に定義された GUID 名) は、暗号が適用されていないことを意味する。bConfigBitstreamRaw が "1" の場合は、DXVA_NoEncrypt でなければならない。
guidConfigResidDiffEncryption : 残差デコード データ バッファ (空間領域データ、またはアクセラレータベース IDCT の変換領域係数セットを含むバッファ) の暗号プロトコル タイプに関連付けられた GUID を表す。DXVA_NoEncrypt という値 (関連付けられたヘッダー ファイル内に定義された GUID 名) は、暗号が適用されていないことを意味する。bConfigBitstreamRaw が "1" の場合は、DXVA_NoEncrypt でなければならない。
bConfigBitstreamRaw : 値 "1" は、ピクチャのデータが、生のビットストリーム コンテンツとしてビットストリーム バッファ内に送信されることを示す。値 "0" は、ピクチャ データがマクロブロック制御コマンド バッファを使って送信されることを示す。bConfigResidDiffHost が "1" の場合、または bConfigResidDiffAccelerator が "1" の場合は、"0" でなければならない。中期的な条件は、"0" をサポートすることである。さらに "1" がサポートすることが望ましい。
bConfigMBcontrolRasterOrder : 値 "1" は、各マクロブロック制御コマンド バッファ内のマクロブロック制御コマンドが、ラスタスキャンの順になっていなければならないことを示す。値 "0" は、任意の順であることを示す。ビットストリームのタイプによっては、ラスタ順序を強制すると、処理が必要なマクロブロック制御バッファの数が非常に増えたり、制御情報をホスト側で並べ替える必要が生じたりする。このため、任意の順序をサポートすることは、デコード処理に有利である。たとえば、H.261 CIF 解像度のデコードでは、各バッファ内がラスタスキャンの順序になっている必要がある場合は、1 ピクチャごとに 36 のマクロブロック制御バッファが要る (H.263 補遺 K の任意スライス順序および矩形スライス モードでも同様の影響がある)。中期的な条件は、"0" をサポートすることである。短期的には "1" のサポートも容認されるが、低レベルの機能であり、あまり推奨されない。
bConfigResidDiffHost : 値 "1" は、いくつかの残差デコード データが、空間領域内のブロックとしてホストから送信される可能性があることを示す。値 "0" は、空間領域データが送信されないことを示す。bConfigBitstreamRaw が "1" の場合は、"0" でなければならない。中期的な条件は、"1" をサポートすることである。これは推奨される値である。
bConfigSpatialResid8: ホストベースの残差デコードを使うとき (ie. bConfigResidDiffHost が "1" のとき) 、予測される (ie 非イントラ) ピクチャの残差空間領域ブロックに用いる WORD サイズを示す。
bConfigSpatialResid8 が "1" かつ bConfigResidDiffHost が "1" なら次のことを示す、ホストは符号付き 8 ビットサンプルを使用する非イントラ マクロブロックについては残差空間領域ブロックを送り、フォーマットが bConfigIntraResidUnsigned に依存する予測される (ie. 非イントラ) ピクチャのイントラ マクロブロックについては次のようになる :
bConfigSpatialResid8 が "0" かつ bConfigResidDiffHost が "1" なら次のことを示す、ホストは符号付き 16 ビットサンプルを使用する非イントラ マクロブロックについては残差空間領域ブロックを送り、フォーマットが bConfigIntraResidUnsigned に依存する予測される (ie. 非イントラ) ピクチャのイントラ マクロブロックについては次のようになる :
bConfigResidDiffHost が "0" なら bConfigSpatialResid8 は "0" であるべきである。このスペックは bConfigResidDiffHost が "1" のとき、bConfigSpatialResid8 が持つべき値の参照を持たない。
注 : 非予測 (イントラ) ピクチャの場合、空間領域ブロックは、BPP = 8 の場合は常に 8 ビット サンプルを使って送信され、BPP > 8 の場合は 16 ビット サンプルを使って送信されなければならない。bConfigIntraResidUnsigned が "0" なら、これらのサンプルは一定参照値 2(BPP-1) に相対した符号付き整数値として送られ、ConfigIntraResidUnsigned が "1" なら、一定参照値 0 に相対した符号なし整数値として送られる。
bConfigResid8Subtraction : bConfigSpatialResid8 が "1" の場合に、値 "1" は、8 ビット差異のオーバーフロー ブロックが加算でなく減算されることを示す。bConfigSpatialResid8 が "1" でない場合は、"0" でなければならない。"1" の場合、これはあらゆるオーバーフロー ブロックが加算でなく減算されることを示す。中期的な条件は、bConfigSpatialResid8 が "1" の場合の "1" をサポートすることである。差異を加算するのでなく減算できることによって、8 ビット差異デコードが、ビデオ デコーダの仕様で必要となる値の全範囲である ±255 に完全に対応できる。これは、2 つの符号付き 8 ビット数値の加算で +255 を表現することはできないが、2 つの符号付き 8 ビット数値の差異を使えば ±255 の範囲のあらゆる数値を表現できるためである (+255 = +127 マイナス -128)。
bConfigSpatialHost8or9Clipping : bConfigSpatialResid8 = "0" かつ bConfigResidDiffHost = "1" の場合、値 "1" は、イントラ マクロブロックの空間領域ブロックがホスト上の 8 ビット範囲にクリップされ、非イントラ マクロブロックの空間領域ブロックがホスト上の 9 ビット範囲にクリップされなければならないことを示す。値 "0" は、ホストによってそのようなクリッピングが実行される必要がないことを示す。bConfigSpatialResid8 = "0" で bConfigResidDiffHost = "1" でない限り、"0" でなければならない。中期的な条件は、"0" をサポートすることである。短期的には "1" のサポートも容認されるが、低レベルのアクセラレータ機能であり、あまり推奨されない。
bConfigSpatialResidInterleaved : bConfigResidDiffHost が "1" で、YUV フォーマットが "NV12" または "NV21" のときにこの値が "1" の場合は、すべての空間領域残差データが、YUV フォーマットのクロマ インターリーブ パターンに一致するクロマインターリーブ フォーマットで送信されなければならないことを示す。bConfigResidDiffHost が "1" で YUV フォーマットが "NV12" または "NV21" でない限り、"0" でなければならない。中期的な条件は、"0" をサポートすることである。短期的には "1" のサポートも容認されるが、低レベルのアクセラレータ機能であり、あまり推奨されない。
bConfigIntraResidUnsigned: ホストベースの残差デコードを使うとき (ie. bConfigResidDiffHost が "1" のとき) 、イントラ ブロックに関する残差空間領域ブロック表示のメソッドを示す。
bConfigIntraResidUnsigned が "0" かつ bConfigResidDiffHost が "1"なら次のことを示す、イントラ マクロブロックの空間領域残差データ ブロックは以下のように送られる :
bConfigIntraResidUnsigned が "1" かつ bConfigResidDiffHost が "1" なら、イントラ マクロブロックの空間領域残差データ ブロックは以下のように送られる :
bConfigResidDiffHost が "1" でなければ、bConfigIntraResidUnsigned は "0" であるべきだ。"1" と等しい bConfigIntraResidUnsigned により近いタームのサポートは許可されるが、"0" と等しい bConfigIntraResidUnsigned がより好ましく、アクセラレータ能力のレベルが低いと解釈される。
bConfigResidDiffAccelerator : 値 "1" は、係数データの変換領域ブロックが、アクセラレータベースの IDCT のためにホストから送信される可能性があることを示す。値 "0" は、アクセラレータベースの IDCT が使用されないことを示す。bConfigResidDiffHost および bConfigResidDiffAccelerator の両方が "1" の場合は、マクロブロックレベル制御コマンドで示されたように、残差デコードの一部がホスト上で実行され、一部がアクセラレータ上で実行されることを示す。bConfigBitstreamRaw が "1" の場合は、"0" でなければならない。bConfigResidDiffAccelerator = "1" のサポートが必要であるが、このサポートに関しては、中期的な条件は設定されない。bConfigResidDiffAccelerator が "1" であり、bConfigResidDiffHost も "1" である場合がサポートされるということは、残差デコードが、マクロブロックごとに、ホストとアクセラレータの間で共有できることを示す。これは、bConfigResidDiffAccelerator が "1" であり bConfigResidDiffHost が "0" である場合よりも高いアクセラレータ機能であると見なされる
bConfigHostInverseScan : 値 "1" は、変換領域ブロック処理の逆スキャンがホスト上で実行され、変換係数の代わりに絶対インデックスが送信されることを示す。値 "0" は、逆スキャンがアクセラレータ上で実行されることを示す。bConfigResidDiffAccelerator が "0" の場合は、"0" でなければならない。bConfig4GroupedCoefs が "0" の場合は、"1" でなければならない。中期的な条件は、bConfigResidDiffAccelerator が "1" の場合に "1" をサポートすることである。短期的には bConfig4GroupedCoefs が "1" の場合に "0" をサポートすることも容認されるが、あまり推奨されない。これは、低レベルのアクセラレータ機能であり、任意のスキャン パターンをサポートする柔軟性に欠け、ホストでの逆スキャンによるホスト ソフトウェア デコーダ処理の負担増はほとんどないと考えられるためである。
bConfigSpecificIDCT : 値 "1" は、ITU-T 勧告 H.263 の補遺 W で定義された IDCT が使用されることを示し、値 "0" は、オフホストの IDCT に、あらゆる準拠 IDCT が使用できることを示す。(注 : ドラフト段階にある参照先の補遺は、まだ ITU-T の最終承認を受けていない。ITU 内で変更があった場合、このビットはドラフト バージョンでなく最終バージョンを参照する。また、参照先ドラフトは MPEG-2 正誤表 2 にある IDCT の条件を満たさず、したがって MPEG-2 ビデオに使用する場合に bConfigSpecificIDCT を 1 としてはならない点にも注意したほうがよい) bConfigResidDiffAccelerator が "0" の場合は、0 でなければならない (純粋にホストベースの残差デコードであることを示す)。中期的な条件は、bConfigResidDiffAccelerator が "1" の場合に "0" がサポートされることである。さらに "1" がサポートされることが望ましい。これら以外の値も将来定義される可能性がある。
bConfig4GroupedCoefs : 値 "1" は、オフホストの IDCT 用の変換係数が、DXVA_TCoefSingle データ構造体でなく DXVA_TCoef4Group データ構造体を使って送信されることを示す。bConfigResidDiffAccelerator が "0" の場合、または bConfigHostInverseScan が "1" の場合は、"0" でなければならない。中期的な条件は、bConfigResidDiffAccelerator が "1" の場合に "0" がサポートされることである。短期的には bConfigHostInverseScan が "0" の場合に "1" をサポートすることも容認されるが、低レベルのアクセラレータ機能であり、あまり推奨されない。
設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットに属する少なくとも 1 つの接続構成メンバと共に動作できる必要がある。最小限の相互動作性セットは次のように定義される。
ソフトウェア デコーダでは、いくつかの補足的構成をサポートすることを推奨する。これは、量産されるハードウェアにこれらの構成が存在し、これらの構成は最小限の構成セットより圧倒的に高いパフォーマンスを提供しうると考えられるからである。推奨構成セットは以下のとおり。
推奨構成セットの最初のメンバをサポートするアクセラレータは、そのアクセラレーション能力の使い方に柔軟性を持たせるため、2 番目のメンバもサポートすることを強く推奨する。
ピクチャ 1 つにつき、次の変数が 1 回送信されなければならない。
DXVA_PictureParameters { wDecodedPictureIndex // 16b wDeblockedPictureIndex // 16b wForwardRefPictureIndex // 16b wBackwardRefPictureIndex // 16b wPicWidthInMBminus1 // 16b wPicHeightInMBminus1 // 16b bMacroblockWidthMinus1 // 8b bMacroblockHeightMinus1 // 8b bBlockWidthMinus1 // 8b bBlockHeightMinus1 // 8b bBPPminus1 // 8b bPicStructure // 8b bSecondField // 8b bPicIntra // 8b bPicBackwardPrediction // 8b bBidirectionalAveragingMode // 8b bMVprecisionAndChromaRelation // 8b bChromaFormat // 8b bPicScanFixed // 8b bPicScanMethod // 8b bPicReadbackRequests // 8b bRcontrol // 8b bPicSpatialResid8 // 8b bPicOverflowBlocks // 8b bPicExtrapolation // 8b bPicDeblocked // 8b bPicDeblockConfined // 8b bPic4MVallowed // 8b bPicOBMC // 8b bPicBinPB // 8b bMV_RPS // 8b bReservedBits // 8b (アラインメント) wBitstreamFcodes // 16b wBitstreamPCEelements // 16b bBitstreamConcealmentNeed // 8b bBitstreamConcealmentMethod // 8b }
wDecodedPictureIndex : デコードされたマクロブロックの宛先フレーム バッファを指定する。
wDeblockedPictureIndex : bPicDeblocked が "1" の場合に、ブロック解除された出力ピクチャの宛先フレーム バッファを指定する。bPicDeblocked が "0" の場合は意味がなく、"0" でなければならない。wDecodedPictureIndex と同じになる場合がある。
wForwardRefPictureIndex : 現在のピクチャの "順方向予測" の参照ピクチャとして使用されるピクチャのフレーム バッファ インデックスを指定する。wDecodedPictureIndex と同じにしてはならない。bPicIntra が "1" なら 0xFFFF となるべきである。
wBackwardRefPictureIndex : 現在のピクチャの "逆方向予測" の参照ピクチャとして使用されるピクチャのフレーム バッファ インデックスを指定する。逆方向参照動き予測が使用される場合は、wDecodedPictureIndex と同じにしてはならない。bPicBackwardPrediction が "0" なら 0xFFFF となるべきである
wPicWidthInMBminus1 : クロブロックの単位で表した、現在のピクチャの幅マイナス 1 を指定する。派生語である PicWidthInMB は、PicWidthInMBminus1 に 1 を足したものである。
wPicHeightInMBminus1 : マクロブロックの単位で表した、現在のピクチャの高さマイナス 1 を指定する。派生語である PicHeightInMB は、PicHeightInMBminus1 に 1 を足したものである。
bMacroblockWidthMinus1 : マクロブロックの宛先輝度サンプルの幅を指定する。MPEG-1、MPEG-2、H.263、MPEG-4 の場合は "15" となる。派生語である MacroblockWidth は、bMacroblockWidthMinus1 に 1 を足したものである。
bMacroblockHeightMinus1 : マクロブロックの宛先輝度サンプルの高さを指定する。MPEG-1、MPEG-2、H.261、H.263、MPEG-4 の場合は "15" となる。派生語である MacroblockHeight は、bMacroblockHeightMinus1 に 1 を足したものである。
bBlockWidthMinus1 : 残差ブロックのブロック幅を指定する。MPEG-1、MPEG-2、H.261、H.263、MPEG-4 の場合は "7" となる。bConfig4GroupedCoefs が "1" の場合は、"7" でなければならない。マクロブロック内の残差ブロックは、MPEG-2 図 6-10、6-11、6-12 で指定された順に送信される (ラスタスキャン順の Y、ラスタスキャン順の Cb の全 4:2:0 ブロック、Cr の 4:2:0 ブロック、Cb の 4:2:2 ブロック、Cr の 4:2:2 ブロック、Cb の 4:4:4 ブロック、Cr の 4:4:4 ブロックの順)。派生語である WT は、BlockWidthMinus1 に 1 を足したものである。
bBlockHeightMinus1 : IDCT ブロックのブロックの高さを指定する。MPEG-1、MPEG-2、H.261、H.263、MPEG-4 の場合は "7" となる。bConfig4GroupedCoefs が "1" の場合は、"7" でなければならない。派生語である HT は、BlockHeightMinus1 に 1 を足したものである。
bBPPminus1 : ビデオ サンプル値の、ピクセルごとのビット数を指定する。最小でも、8 ビット ピクセルを表す "7" でなければならない。MPEG-1、MPEG-2、H.261、H.263 の場合は "7" となる。MPEG-4 のいくつかの処理モードでは、1 ピクセルごとのビット数を多くできる。派生語である BPP は、bBPPminus1 に 1 を足したものである。
bPicStructure : このパラメータは、MPEG-2 の セクション 6.3.10 および表 6-14 で定義されている picture_structure パラメータと同じ意味を持ち、現在のピクチャが、上フィールド ピクチャ (値 '01')、下フィールド ピクチャ (値 '10')、フレーム ピクチャ (値 '11') のどれであるのかを示す。H.261 のようなプログレッシブスキャン フレーム構造化コーディングの場合、bPicStructure は '11' でなければならない。bPicStructure が '10' (下フィールド) でない限り、派生パラメータである PicCurrentField は "0" として定義され、その場合このパラメータは "1" となる。
bSecondField : フィールド構造化コーディング (bPicStructure が '01' または '10' のとき) の場合に、現在のフィールドがピクチャの 2 番目のフィールドであるかどうかを示す。これは、動き補償予測のために逆パリティ ラインの参照として使用される逆パリティ フィールドが、参照ピクチャの逆パリティ フィールドか、または現在のピクチャの逆パリティ フィールドかを決定するのに使用される。bSecondField が "1" の場合、現在のフィールドは、ピクチャの第 2 フィールドであり、動き補償のために逆パリティ ラインの参照として使用されるフィールドは、現在のピクチャの逆パリティ ラインである。(どちらの場合も、動き補償のために同パリティ ラインの参照として使用されるフィールドは、参照ピクチャの同パリティ ラインである。) それ以外の場合、bSecondField は "0" でなければならない。
bPicIntra : このピクチャに対して動き補償予測が必要かどうかを指定する。bPicIntra が "1" の場合は、すべてのマクロブロックは IntraMacroblock は "1" で送信される (つまり、そのピクチャに関して動き補償予測は実行されない)。それ以外の場合、ピクチャの一部マクロブロックが IntraMacroblock が "0" となる可能性がある。
bPicBackwardPrediction : 現在のピクチャに逆方向予測を含むマクロブロックかあるかどうかを示す。bPicIntra が "1" の場合、bPicBackwardPrediction は "0" でなければならない。それ以外の場合、bPicBackwardPrediction が "0" であれば、ピクチャの全マクロブロックで MotionBackward が "0" でなければならない。bPicBackwardPrediction が "1" であれば、ピクチャの全マクロブロックで MotionBackward が "1" でなければならない。
bBidirectionalAveragingMode : このフラグは、双方向動き補償で予測プレーンを組み合わせる際の丸め方法を指定する (B ピクチャおよびデュアルプライムの動きに使用される)。値 "0" は MPEG-1 と MPEG-2 の丸め平均化 (//2)、および "1" は H.263 の切り捨て平均化 (/2) を含む。双方向平均化が必要ない場合は、bBidirectionalAveragingMode は "0" でなければならない。
bMVprecisionAndChromaRelation : この 2 ビット フィールドは、輝度動きベクトルの精度と、輝度動きベクトルから色光度動きベクトルが派生されなければならない方法を示す。
'00' は、輝度動きベクトルの精度がハーフサンプルであり、色光度動きベクトルが MPEG-2 の規則に従って輝度動きベクトルから派生されることを示す。
'01' は、輝度動きベクトルの精度がハーフサンプルであり、色光度動きベクトルが H.263 の規則に従って輝度動きベクトルから派生されることを示す。
'10' は、輝度動きベクトルの精度がフルサンプルであり、色光度動きベクトルが H.261 セクション 3.2.2 の規則 (2 で除算し、フルサンプル値まで 0 方向に切り捨て) に従って輝度動きベクトルから派生されることを示す。
'11' は予約されている。
bChromaFormat : アクセラレータによって予期される予測エラー ブロックの数に影響を与える。この変数は、MPEG-2 のセクション 6.3.5 および表 6-5 で定義されている。MPEG-1、MPEG-2 "メイン プロファイル"、H.261、H.263 ビットストリームの場合、この値は常に "4:2:0" フォーマットを示す '01' に設定されなければならない。'10' の場合は "4:2:2"、'11' の場合は "4:4:4" サンプリングを示す。bConfig4GroupedCoefs が "1" なら、'01' とするべきである。(なぜなら bConfig4GroupedCoefs は 4:2:2 と 4:4:4 フォーマットの係数データに必要とされている EOB 指示を含んでいないので。)
注 : H.261、H.263、および MPEG-1 と、MPEG-2 および MPEG-4 では水平方向のクロマ配置が若干異なる。この差異は、無視できる程度に小さなものであると想定される。
bPicScanFixed : 残差ブロックのアクセラレータベース IDCT 処理を使用する際、このフラグの値が "1" の場合は、逆スキャン方法がピクチャ内のすべてのマクロブロックについて同じであることを示す。値が "0" の場合は同じでないことを示す。bConfigHostInverseScan が "1"、または bConfigResidDiffAccelerator が "0" の場合、この値は "1" でなければならない。
bPicScanMethod : bPicScanFixed が "1" の場合、このフィールドは、ピクチャの固定逆スキャン方法を指定する。bPicScanFixed が "0" の場合は、このフィールドは意味がなく、'00' でなければならない。bPicScanFixed が "1" の場合、このフィールドは次のいずれかの値でなければならない。
bPicReadbackRequests : デコードされた (wDecodedPictureIndex と等しい wDeblockedPictureIndex でブロック解除が適用される場合には、ブロックも解除された) 最終ピクチャ内のマクロブロックの値を読み戻すために、現在のピクチャについて読み戻し制御要求が実行されるかどうか指定する。値 "1" は、読み戻し要求があることを示す。値 "0" は要求がないことを示す。
bRcontrol : このフラグは、H.263 セクション 6.1.2 に定義されており、ハーフサンプル動き補償に使われる丸め方法を指定する。値 "0" は、MPEG-1、MPEG-2、および最初のバージョンの H.263 のハーフサンプル丸め方法が使われることを示す。値 "1" は、H.263 および MPEG-4 のいくつかのオプション モードで選択できる、下方平均化バイアスを含む丸め方法が使われることを示す。H.261 にはハーフサンプル動き補償がないため、このフラグは H.261 では意味を持たない。すべての MPEG-1、および MPEG-2 のビットストリームの場合、これらの規格で定義されている丸め演算子に準拠するためには、この値が "0" に設定されなければならない。
bPicSpatialResid8 : 値 "1" は、ホストベースの残差デコードの空間領域差異ブロックが、8 ビット サンプルを使って送信できることを示す。値 0 は送信できないことを示す。bConfigResidDiffHost が "0"、または BPP > 8 の場合は、この値は "0" でなければならない。BPP = 8 で bPicIntra = 1 で、bConfigResidDiffHost が "1" の場合は、"1" でなければならない。bPicSpatialResid8 が 1 の場合は、空間領域イントラ マクロブロックが、定数値 2(BPP-1) に対応する符号付き 8 ビット差異値として送信され、空間領域非イントラ マクロブロック差異が、動き補償予測に対応する符号付き 8 ビット差異値として送信されることを示す。bPicSpatialResid8 は、ビデオ シーケンス全体に対してグローバルに指定するのではなく、特定のピクチャに関してのみ指定するという点で、bConfigSpatialResid8 と異なる。BPP が "8" であるイントラ ピクチャのような場合は、bConfigSpatialResid8 が "0" であっても bPicSpatialResid8 は "1" となる。
bPicOverflowBlocks : 値 1 は、ピクチャのホストベース残差デコードのための空間領域差異ブロックが、"オーバーフロー" ブロックを使って送信される可能性があることを示し、値 0 はその可能性がないことを示す。bConfigResidDiffHost が 0 か、bConfigSpatialResid8 が "0" か、または BPP > 8 の場合は、"0" でなければならない。bPicOverflowBlocks は、特定のピクチャに対応するオーバーフロー ブロックが存在する可能性があるかどうかを示す。BPP が "8" のイントラ ピクチャでは、この場合にオーバーフロー ブロックは不要なため、bPicOverflowBlocks は "0" でなければならない。
bPicExtrapolation : このフラグは、H.263 補遺 D および MPEG-4 で定義されているように、ピクチャ境界を越える動きベクトルが許可されるかどうかを指定する。これを実行するには、デコードされるピクチャのサイズよりも幅が 2 マクロブロック分広く (左右にそれぞれ余分のマクロブロック)、高さが 2 マクロブロック分高い (上下にそれぞれ余分のマクロブロック) ピクチャ プレーンを割り当てるか、またはピクチャ境界内で個々のピクセルがアクセスするアドレスをクリッピングする必要がある。この仕様でのマクロブロック アドレスは、ピクチャ内部のマクロブロック用であり、パディングを含まない。
bPicDeblocked : ブロック解除された出力ピクチャを wDeblockedPictureIndex で指定されたピクチャ バッファ内に作成するために、ブロック解除コマンドがこのピクチャ用に送信されるかどうかを示す。bPicDeblocked が "1" の場合は、ブロック解除コマンドが送信され、ブロック解除フレームが生成されなければならない。bPicDeblocked が "0" の場合は、ブロック解除コマンドが送信されず、ブロック解除ピクチャが生成されてはならない。
bPicDeblockConfined : ブロック解除フィルタ処理の効力を、バッファに格納されているのと同一のマクロブロック セット内に限定するコマンドを、ブロック解除フィルタ コマンド バッファに含めるかどうか指定する。
bPic4MVallowed : H.263 補遺 F および J で使用されているように、マクロブロックごとに 4 つの順方向参照動きベクトルが許可されるかどうかを指定する。
bPicOBMC : 現在のピクチャの動き補正が、H.263 補遺 F で定義されているように、重複ブロック動き補償 (OBMC) を使って動作するかどうかを指定する。bPic4MVallowed が 0 の場合は、0 でなければならない。
bPicBinPB : ピクチャ内の双方向予測マクロブロックが "PB 内の B" 動き補償を使用するかどうか指定する。この動き補償は、H.263 の補遺 G および M で定義されているように、各マクロブロックについて、双方向に予測された領域を、逆参照ピクチャ内の対応するマクロブロックのリージョンに限定する。
bMV_RPS : 動きベクトル参照ピクチャ選択の使用方法を指定する。"1" の場合は、ピクチャ全体としての順方向および (場合によっては) 逆方向動きピクチャ インデックスだけでなく、各動きベクトルについて参照ピクチャ インデックスが送信されることを示す。bMV_RPS が "1" の場合は、パラメータ wForwardRefPictureIndex および wBackwardRefPictureIndex は意味がなく、"0" でなければならない。
wBitstreamFcodes : bConfigBitstreamRaw が "1" の場合、このパラメータは、MPEG-2 に定義されているように 4 つの動きベクトル f_code 値を持つ。各 f_code 値は 4 ビットを取る。これらの値は、MPEG-2 と同様、次のような 16 ビット ワードにパックされる。
ビット 12 〜 15 (MSB) : f_code[0][0] : 順方向水平 f_code
ビット 8 〜 11 : f_code[0][1] : 順方向垂直 f_code
ビット 7 〜 4 : f_code[1][0] : 逆方向水平 f_code
ビット 0 〜 3 (LSB) : f_code[1][1] : 逆方向垂直 f_code
ビットストリーム データの構造上の理由のため、または bConfigBitstreamRaw = 0 であるため、または該当するビデオ コーディング ビットストリーム構文 (H.261 や H.263 など) で f_code パラメータが必要ないために、いずれかの f_code 値が不要または関係ない場合は、その f_code 値は 0xF でなければならない。
注 : MPEG-1 ビットストリームは、この情報を別のフォーマットで提供する。このため、MPEG-1 ビットストリームの場合は、f_code[0][0] および f_code[0][1] は MPEG-1 の forward_f_code、f_code[1][0] および f_code[1][1] は MPEG-1 の backward_f_code と同じでなければならない。
wBitstreamPCEelements : bConfigBitstreamRaw が "1" の場合、このパラメータには、MPEG-2 ビデオのビットストリーム デコード処理に必要な一連のフラグが含まれる。bConfigBitstreamRaw が "0" で、非 MPEG-2 ビデオの場合は、このパラメータは使用されず、値は "0" でなければならない。このパラメータ内のビットは、次のように、MPEG-2 ピクチャ コーディング エクステンションのビットストリーム要素との対応によって定義される。
ビット 14 および 15 : IntraDCprecision = intra_dc_precision
ビット 12 および 13 : AnotherPicStructure = picture_structure (bPicStructure と同じでなければならない)
ビット 11 : TopFieldFirst = top_field_first
ビット 10 : FrameDCTprediction = frame_pred_frame_dct
ビット 9 : ConcealmentMVs = concealment_motion_vectors
ビット 8 : QuantScaleType = q_scale_type
ビット 7 : IntraVLCformat = intra_vlc_format
ビット 6 : AlternateScan = alternate_scan
ビット 5 : RepeatFirstField = repeat_first_field (アクセラレータはこれを必要としない)
ビット 4: Chroma420type = chroma_420_type (アクセラレータには不要であり、MPEG-2 により progressive_frame と等しい値に制限される)
ビット 3 : ProgressiveFrame = progressive_frame
ビット 0、1、および 2 (LSB) : ReservedBits
bBitstreamConcealmentNeed : bConfigBitstreamRaw が "1" の場合、ビットストリーム データにエラーが含まれている可能性が大きいかどうかを示す。bConfigBitstreamRaw が "0" の場合は、この値は "0" でなければならない。ビデオ アクセラレータは、与えられたデータの内容にかかわらず、クラッシュしたりロックアップしたりしないように設計される必要がある。しかし、ビデオ アクセラレータが、ビットストリームのデコード処理を遅らせる、より複雑なエラー隠匿アルゴリズムを呼び出せるようにする必要があるかどうかを決定する際、構文エラーの可能性をホストがどのよう評価しているかを認識することは役立つ。このパラメータに使用できる値は次のとおり (これ以外の値はすべて予約されている)。
"0" : ビットストリームの構文上のフォーマットに、大量のエラーが含まれている可能性が低いことを示す。
"1" : ビットストリームにいくつかのエラーが含まれている可能性があるが、それらが頻繁に現れない (1 時間に 1 〜 2 回) ことを示す。
"2" : ビットストリームにエラーが含まれており、ユーザーの使用状況に影響を及ぼす程度の頻度で発生する可能性が高く (5 〜 10 分にいくつかのエラー)、しかしそれらのエラーが一定には存在していないことを示す。
"3" : ビットストリームに、比較的重大、深刻、かつ頻繁な構文フォーマット エラーが含まれていることを示す (1 分間に 1 回以上)。
bBitstreamConcealmentMethod : bConfigBitstreamRaw が "1" の場合、推奨されるエラー隠匿処理のデフォルト方法を示す。bConfigBitstreamRaw が "0" の場合は、"0" でなければならない。このパラメータに使用できる値は次のとおり (これ以外の値はすべて予約されている)。
0 : 推奨される隠匿方法が未知である、または指定されていない。
1 : 推奨される隠匿方法は、ピクチャ内での、空間イントラピクチャ隠匿の使用である。
2 : 推奨される隠匿方法は、インターピクチャ隠匿の順方向動き参照ピクチャの使用である (対応する逆方向動き参照ピクチャよりも順方向動き参照ピクチャに一時的に近くなっている P ピクチャまたは B ピクチャ内で最も一般的に使用される)。
3 : 推奨される隠匿方法は、インターピクチャ隠匿の逆方向動き参照ピクチャの使用である (対応する順方向動き参照ピクチャよりも逆方向動き参照ピクチャに一時的に近くなっている B ピクチャ内で最も一般的に使用される)。
デコードされたピクチャにビットストリーム データ バッファが含まれていない場合は、1 つまたは複数のマクロブロック制御コマンド バッファが含まれていなければならない。すべてのマクロブロックのデコード処理は、使用される各タイプのバッファ内で1 度だけアドレスされなければならない。すべてのマクロブロック制御コマンド バッファについて、同じマクロブロックのセットを持つ、対応する IDCT 残余コーディング バッファが存在しなければならない。1 つまたは複数のブロック解除フィルタ制御バッファが送信される場合、各ブロック解除フィルタ制御バッファ内のマクロブロック セットは、対応するマクロブロック制御バッファおよび IDCT 残余コーディング バッファ内のマクロブロック セットと同一でなければならない。
ピクチャを処理するには、各マクロブロックの動き予測が、IDCT 残余データの追加に先行する必要がある。これを実行するには、まず動き予測コマンドを処理してから、IDCT 残余コーディング コマンドの処理中に、このデータを宛先ピクチャ バッファから読み戻すか、またはこれらの 2 つのバッファを、統合して処理する (結果を宛先ピクチャ バッファに書き込む前に、残余データを予測に追加する)。各マクロブロックの動き予測コマンドと IDCT 残余コーディング コマンドは、そのマクロブロック内の矩形リージョンのみに影響する。
マクロブロックのブロック解除フィルタ コマンドは、現在のマクロブロックの上および左に隣接するサンプルの 2 行 2 列の再構築された値、および現在のマクロブロック内の再構築された値を読み込むためのアクセスを必要とする場合がある。その結果、現在のマクロブロックの上および左に隣接するサンプルの、1 行 1 列、および現在のマクロブロック内の最大 3 行 3 列が修正される場合がある。このため、特定のマクロブロックのフィルタリング処理を実行するために、事前にほかのマクロブロックの再構築が必要になる場合がある。ここでは、2 つの異なるタイプのブロック解除フィルタ バッファが定義されている。1) 現在のバッファの外にあるマクロブロックの、再構築されたサンプルの値に対するアクセスおよび値の修正を必要とするバッファ タイプ (bPicDeblockConfined が "0" の場合)、および 2) それらを必要としないバッファ タイプ (bPicDeblockConfined が "1" の場合) である。1) のタイプのブロック解除コマンド バッファを処理するには、現在のバッファ内でブロック解除コマンドを処理する前に、現在のバッファのマクロブロックの左および上にあるマクロブロックに影響するすべてのバッファの再構築が完了していることを、アクセラレータが確認する必要がある。2) のタイプを処理する場合は、現在のバッファ内の値が事前に再構築されていればよい。ブロック解除のポストプロセッシングを行うには、まずバッファ全体またはフレームに対して動き予測と IDCT 残余コーディング コマンドを処理し、次にいくつかのサンプルの値を読み戻し、ブロック解除フィルタ処理の結果としてそれらを修正するか、またはブロック解除コマンド バッファを、IDCT 残余コーディング バッファと統合して処理する (最終出力値を宛先ピクチャ バッファに書き込む前に、ブロック解除を実行する)。ブロック解除されたピクチャの宛先ピクチャ バッファは、ブロック解除の前に再構築されたピクチャのバッファとは異なる場合がある。これは、ポストプロセッシングとして、次のピクチャの予測に使われるサンプル値に影響を与えない "ループ外" ブロック解除をサポートするためである。
if (bPicIntra) NumMV = 0; else if (PicOBMC) { NumMV = 10; if (bPicBinPB) NumMV++; } else { NumMV = 4; if (bPicBinPB && bPic4MVallowed) NumMV++; } DXVA_MB_Control { // 16 バイトに整列 // 一般マクロブロック情報 wMBaddress // 16b どのマクロブロックか wMBtype // 16b 制御ビット MBskipsFollowing // 8b // 残差情報 MBdataLocation // 24b バッファ内の位置 wPatternCode // 16b コードされたブロック if(bPicOverflowBlocks==1 && IntraMacroblock==0){ wPC_Overflow // 16b wPatternCode ごと dwReservedBits2 // 32b } else if(HostResidDiff) ReservedBits3 // 48b else if (bChromaFormat == '01') for (i = 0; i < 6; i++) bNumCoef[i] // 8b * 6 blocks = 48b else { wTotalNumCoef // 16b ReservedBits3 // 32b } if (bPicIntra != 0) { // 動き予測情報 for(i=0; i<NumMV; i++) { MVector[i].horz // 16b * NumMV ベクトル MVector[i].vert // 16b * NumMV ベクトル } if(bMV_RPS) for(i=0; i<NumMV; i++) bRefPicSelect[i] // 8b * NumMV ベクトル ReservedBits4 // 16b バイト整列 } }
wMBaddress : 現在のマクロブロックのマクロブロック アドレスをラスタ スキャン順序で指定する (0 は左上マクロブロックのアドレス、PicWidthInMBminus1 は右上マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB は左下マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB + PicWidthInMBminus1 は右下マクロブロックのアドレス)。
wMBtype : 処理されるマクロブロックのタイプを指定する。指定方法は次のとおり。
0
の場合、MBscanMethod は次の値でなければならない。bConfigHostInverseScan = 1 の場合、MBscanMethod は次と等しくなければならない。
MBskipsFollowing : 現在のマクロブロックに続いて生成される、"スキップされるマクロブロック" の数を指定する。スキップされる各マクロブロックは、wMBaddress の値を増加させ、その後同じマクロブロック制御コマンドを反復するのと同等の計算方法で生成されなければならない。
MBskipsFollowing の値が "0" でないマクロブロック制御コマンドはすべて、スキップされる各マクロブロックごとに動き補償予測がどのように実行されるかに関する明示的な指定を含み、また (MBskipsFollowing の値を除いて)、スキップされる一連のマクロブロックの最初のマクロブロックの生成に関する明示的な "非スキップ" 指定と同等である。このため、MBskipsFollowing が "0" でない場合は常に、次のパラメータがすべて "0" と等しくなければならない。
さらに、後に続くスキップされるマクロブロックの生成は、ピクチャ内のマクロブロックの新しい行への "折り返し" を含まないよう、デコーダによって制限されなければならない。つまり、マクロブロックの各行の最初の (しかし最後である必要はない) マクロブロックを生成するために、個別のマクロブロック制御コマンドが送信される必要がある。
注 :
MBdataLocation : IDCT 残余コーディング ブロック データ バッファへのインデックス。現在のマクロブロック内のブロックの残差データ位置を、32 ビットの倍数で示す。マクロブロック制御コマンド バッファの最初のマクロブロックの場合は、"0" でなければならない。
wPatternCode : ホストベース残差デコードを使用する場合、wPatternCode (ビット 0 が LSB) の ビット 11-i は、ブロック i の残差ブロックが送信されるかどうかを示す。ここで、i は、図 6-10、6-11、および 6-12 で指定されたマクロブロック内のブロックのインデックスである (ラスタスキャン順の Y、ラスタスキャン順の Cb の 4:2:0 ブロック、Cr の 4:2:0 ブロック、Cb の 4:2:2 ブロック、Cr の 4:2:2 ブロック、Cb の 4:4:4 ブロック、Cr の 4:4:4 ブロックの順)。コードされたブロックのデータ (ビット 11-i が 1 であるブロック) は、同じインデックス順序 (増分 i) の残余コーディング バッファにある。4:2:0 MPEG-2 データの場合、wPatternCode の値は、デコードされた CBP の値を左に 6 ビット位置シフトしたものに対応する (これらの下位ビット位置は、4:2:2 および 4:4:4 クロマ フォーマットで使用される)。
bConfigSpatialResidInterleaved が "1" の場合、ホストベースの残差は、使用されている YUV ピクセル フォーマットに一致するクロマインターリーブ フォーマットで送信される。この場合、Cb および 空間的に対応する Cr のブロックの各組は、単一の残差データ構造単位として扱われる。これにより wPatternCode の値や意味が変更されることはないが、Cb および Cr データ ブロックのどちらかが wPatternCode に対応するビット セットを持っていれば、これらのデータ ブロックの各組の両方のメンバが常に送信されることを意味する。特定のデータ ブロックの wPatternCode のビットが 0 の場合、この組が、wPatternCode ビットが 0 であるブロックの残差データ ブロックの送信を必要とするときは常に、対応する残差データ値が 0 として送信されなければならない。
wPC_Overflow : bPicOverflowBlocks が 1、IntraMacroblock が 0 (8-8 オーバーフロー方式) でホストベースの残差デコードを使用する場合、wPC_Overflow には、wPatternCode と同じ方法で指定されたオーバーフロー ブロックのパターン コードが含まれる。コードされたオーバーフロー ブロックのデータ (ビット 11-i が 1 であるブロック) は、同じインデックス順序 (増分 i) の残余コーディング バッファにある。
bNumCoef[i] : マクロブロックの各ブロック i の、残余コーディング ブロック データ バッファ内の係数の数を示す。ここで、i は、MPEG-2 の 図 6-10、6-11、および 6-12 で指定されたマクロブロック内のブロックのインデックスである(Y のラスタ スキャン順、Cb に続く、Cr に続く)。 HostResidDiff が "0" で bChromaFormat が '01' (4:2:0) のときのみ使用される。(4:2:2 か 4:2:0 フォーマットで使用されると、典型的なマクロブロック コントロール コマンドのサイズが増加して、クリティカル メモリ割り当て境界を越えてしまう、そのため非 4:2:0 の場合各ブロックの係数の数を決めるのに EOB だけが使用される。) これらの係数のデータは同じ順の残差バッファ内にある。
wTotalNumCoef: 全マクロブロックの残差データバッファ内の係数の全数を示す。HostResidDiff が "0" かつ bChromaFormat が '01'以外のとき (4:2:0) のみ使用される。
MVector[i].horz、MVector[i].vert : 水平方向および垂直方向の動きベクトルの値を指定する。これら 2 つの値を 2 次元に統合した値は、MVvalue[i] と呼ばれる。各動きベクトルの各方向には、ハーフサンプル単位の符号付き整数動きオフセットが含まれる。bMVprecisionAndChromaRelation が '10' (整数サンプル オフセットだけをサポートしている H.261 フォーマットの動き) の場合は、どちらの要素も偶数でなければならない。
bRefPicSelect[i] : 動きベクトル参照ピクチャ選択が使用中の場合は、MVvalue[i] の予測に使用される参照ピクチャ バッファを指定する。
IntraMacroblock、MotionForward、MotionBackward、PicMotionType、MvertFieldSel、および MVector[i] の有効な組み合わせを、下の表 1 に示す。表内で指定された値は、H261LoopFilter、Motion4MV、および bPicOBMC がすべて 0 であることを前提としている。
表 1 - 各種動きタイプにおけるマクロブロック パラメータの使用
IntraMacroblock、 MotionForward、 MotionBackward |
MotionType (意義はピクチャ タイプによる) |
MVector[0]
MvertFieldSel[0] (1st, dir1) |
MVector[1]
MvertFieldSel[1] (1st, dir2) |
MVector[2]
MvertFieldSel[2] (2nd, dir1) |
MVector[3]
MvertFieldSel[3] (2nd, dir2) |
フレーム構造化ピクチャ (bPicStructure = '11') | |||||
1,0,0 (intra) | '00' (intra) | -
- |
-
- |
-
- |
-
- |
0,0,0 (no motion) | '10' (no motion) | 0
- |
-
- |
-
- |
-
- |
0,1,0 | '10' (frame MC) | PMV[0][0]
- |
-
- |
-
- |
-
- |
0,0,1 | '10' (frame MC) | -
- |
PMV[0][1]
- |
-
- |
-
- |
0,1,1 | '10' (frame MC) | PMV[0][0]
- |
PMV[0][1]
- |
-
- |
-
- |
0,1,0 | '01' (field MC) | PMV[0][0]
sel[0][0] |
-
- |
PMV[1][0]
sel[1][0] |
-
- |
0,0,1 | '01' (field MC) | -
- |
PMV[0][1]
sel[0][1] |
-
- |
PMV[1][1]
sel[1][1] |
0,1,1 | '01' (field MC) | PMV[0][0]
sel[0][0] |
PMV[0][1]
sel[0][1] |
PMV[1][0]
sel[1][0] |
PMV[1][1]
sel[1][1] |
0,1,0 | '11' (dual-prime) | PMV[0][0]
0 (top) |
vector'[2][0][0], vector'[2][0][1]<<1 1 (bot) |
PMV[0][0]
1 |
vector'[3][0][0], vector'[3][0][1]<<1 0 |
フィールド構造化ピクチャ (bPicStructure == '01' or '10') | |||||
1,0,0 (intra) | '00' (intra) | -
- |
-
- |
-
- |
-
- |
0,0,0 (no motion) | '01' (no motion) | 0
PicCurrentField |
-
- |
-
- |
-
- |
0,1,0 | '01' (field MC) | PMV[0][0]
sel[0][0] |
-
- |
-
- |
-
- |
0,0,1 | '01' (field MC) | -
- |
PMV[0][1]
sel[0][1] |
-
- |
-
- |
0,1,1 | '01' (field MC) | PMV[0][0]
sel[0][0] |
PMV[0][1]
sel[0][1] |
-
- |
-
- |
0,1,0 | '10' (16×8 MC) | PMV[0][0]
sel[0][0] |
-
- |
PMV[1][0]
sel[1][0] |
-
- |
0,0,1 | '10' (16×8 MC) | -
- |
PMV[0][1]
sel[0][1] |
-
- |
PMV[1][1]
sel[1][1] |
0,1,1 | '10' (16×8 MC) | PMV[0][0]
sel[0][0] |
PMV[0][1]
sel[0][1] |
PMV[1][0]
sel[1][0] |
PMV[1][1]
sel[1][1] |
0,1,0 | '11' (dual-prime) | PMV[0][0]
PicCurrentField |
vector'[2][0]
!PicCurrentField |
-
- |
-
- |
注 :
このほかの可能な組み合わせは次のとおり。
H261LoopFilter == 1 && bPicOBMC == 0 && Motion4MV == 0 : 順方向動きベクトルの 1 個が MVector[0] に送信され、マクロブロックの順方向予測に対して、H.261 のセクション 3.2.3 で指定された H.261 ループ フィルタがアクティブであることを示す。この場合、MotionForward は 1、IntraMacroblock と MotionBackward の両方は "0" でなければならない。
bPicOBMC == 0 && Motion4MV == 1 : 4 個の順方向動きベクトルが MVector[0, 1, 2, 3] に送信されることを示す。この場合、MotionForward が 1、IntraMacroblock が "0" でなければならない。MotionBackward が "1" の場合、5 番目の動きベクトルが逆方向予測のために MVector[4] に送信される。
bPicOBMC == 1 && Motion4MV == 0 : 10 個の順方向動きベクトルが OBMC の動き指定のために MVector[0, 1, 2, ..., 9] に送信され、これら動きベクトルの最初の 4 個の値がすべて同じであることを示す。MotionBackward が "1" の場合、11 番目の動きベクトルが逆方向予測のために MVector[10] に送信される。
bPicOBMC == 1 && Motion4MV == 1 : 10 個の順方向動きベクトルが OBMC 動きの指定のために MVvalue[0, 1, 2, ..., 9] に送信され、これら動きベクトルの最初の 4 個の値がすべて異なる可能性があることを示す。MotionBackward が 1 の場合、11 番目の動きベクトルが逆方向予測のために MVvalue[10] に送信される。
注 : H.263 標準規格の現在の構成では、bPicOBMC == 1、Motion4MV == 1、MotionBackward == 1 という組み合わせは使用されない。
PB 内の H.263 の OBMC、4MV、B、EP、B 間の関連についてのいくつかの詳細は有効であろう :
a) OBMC は H.263 B あるいは EP ピクチャ内では使用できない (H.263 セクション 5.1.4.5 第 2 項)。
b) OBMC は H.263 PB ピクチャの B パート内では使用できない (H.263 セクション F.1 第 1 段落)。
c) 4MV は H.263 B あるいは EP ピクチャ内には送ることができない (構文ダイアグラムの MVFW と MVBW 1 つだけ、H.263 表 O.1 と O.2 内の 4MV マクロブロック タイプはない)。
d) H.263 B ピクチャの "直接"予測の詳細の参照マクロブロックとして使用される H.263 P ピクチャのマクロブロックで 4MV が使用されるなら、OBMC は直接予測には使用されない、なぜなら 4 つのモーション ベクトルが H.263 Annex M にしたがって使用されるからである、これは OBMC を適用しない H.263 Annex G のようにそれを用いる (H.263 セクション O.4 第 2 段落と第 2 項目)。それゆえ、H.263 は OBMC も逆予測も同時には要求しない、そして逆方向にも 4MV を使わない。
注 : MPEG-1、MPEG-2 ハーフサンプル予測フィルタリング、双方向平均化、およびデュアル プライムの同パリティと逆パリティの組み合わせのいずれにおいても、平均演算子は算術的には同じ ((s1+s2)//2) である。この演算子は、C 言語の式 (s1+s2+1)>>1 と同じである。H.263 双方向平均化演算子は、ダウンシフトに先行して "+1" オフセットでシードしない。bBidirectionalAveragingMode パラメータは、これらのどの方法を使うかを決定する。
3.5.5.2 逆量子化、IDCT 前飽和、ミスマッチ制御、イントラDCオフセット、IDCT、ピクチャ再構築、および再構築クリッピング
このインターフェイスは、IDCT 処理のための、3 つの下位レベルの方法をサポートする。どの場合でも、基本的な逆量子化処理、IDCT 前の範囲飽和、MPEG-2 ミスマッチ制御 (必要に応じて)、およびイントラ DC オフセット (必要に応じて) はホスト側で実行され、最終的なピクチャの再構築および再構築クリッピングはアクセラレータ側で実行される。最初の方法は、変換係数のマクロブロックを、外部の IDCT、ピクチャ再構築、および再構築クリッピングのためにアクセラレータに渡すことである。2 番目と 3 番目の方法では、IDCT をホスト上で実行し、外部のピクチャ再構築および再構築クリッピングのために空間領域結果のブロックを渡す。
逆量子化、IDCT 前飽和、ミスマッチ制御、イントラ DC オフセット、IDCT、ピクチャの再構築、および再構築クリッピングの処理は、次のように定義される。
各記号の意味 :
C(u) は、u = 0 の場合は 1、それ以外の場合はC(v) は、v = 0 の場合は 1、それ以外の場合は
x および y は、ピクセル領域内の水平および垂直空間座標
u および v は、変換領域の水平および垂直周波数座標
WT および HT は、変換 ブロックの幅および高さ (通常はどちらも 8)
注 : この IDCT 処理の精度は、H.261&3 および MPEG-1&2&4 ビデオ コーディング標準規格で求められるもの (ほぼ同様) に準拠しなければならない。
オフホスト IDCT 処理のための、マクロブロック IDCT 係数データの転送には、インデックスのバッファと値の情報が含まれる。インデックス情報は 16 ビット ワードとして送信され (ただし 8×8 変換 ブロックに本当に必要なのは 6 ビットのみ)、変換係数値情報は符号付き 16 ビット ワードとして送信される (ただし通常の 8×8 変換 ブロックの場合で BPP=8 の場合は、必要なのは 12 ビット のみ)。
変換係数は、DXVA_TCoefSingle または DXVA_TCoef4Group のどちらかのデータ構造体で送信される。bConfig4GroupedCoefs が "0" の場合、係数は DXVA_TCoefSingle 構造体を使って別々に送信される。bConfig4GroupedCoefs が "1" の場合、係数は DXVA_TCoef4Group 構造体を使って 4 つずつ送信される。これら二者択一のデータ構造体には、以下に定義する 2 つの似通った基本要素が含まれる。
TCoefIDX : bConfigHostInverseScan から決定されたとおりに、ブロック内の係数のインデックスを指定する。TCoefIDX の使用には、次の基本的な 2 つの方法がある。
TCoefIDX は、WT·HT 以上になってはならない。
TCoefValue : ブロック内の係数の値。TCoefValue は、係数値を逆 DCT 処理のためにアクセラレータに渡す前に、前述のセクション 3.4.2 で示したように、ホスト側で適切な範囲にクリップしなければならない。必要に応じて、MPEG-2 ミスマッチ制御も、アクセラレータでなくホストによって実行される (このために、0 でない余分な "幽霊" 係数の作成が必要になる場合がある)。
DXVA_TCoefSingle データ構造体は、bConfig4GroupedCoefs が "0" の場合に必ず使用され、次のように定義される。
DXVA_TCoefSingle {
TCoefIDX 15 /* 8×8 に本当に必要なのは 6 のみ */
TCoefEOB 1
TCoefValue 16 /* ホスト上で飽和 */
}
TCoefEOB : 現在の変換係数が、係数の現在のブロックに関連付けられた最後の係数かどうかを示す。値 "1" は、現在の係数がブロックの最後の 1 つであることを示す。値 "0" は、そうでないことを示す。
3.5.5.2.1.2 グループ化された 4 係数のデータ フォーマット
DXVA_TCoef4Group データ構造体は、bConfig4GroupedCoefs が "1"、bConfigHostInverseScan が "0" の場合のみに使用され、次のように定義される。
DXVA_TCoef4Group {
TCoefIDX[4] 4*8 /* 8x8 に本当に必要なのは 6 のみ */
TCoefValue[4] 4*16
}
DXVA_TCoef4Group データ構造体では、グループ化された 4 つの変換係数が、RLE (Run-length) 値と共に一括送信される。DXVA_TCoef4Group 内の各配列のi 番目の要素には実際のの係数か実行長リストの要素 3-i が入る (それゆえ、最初の係数あるいはインデックスは要素 3 になる、要素 2 に次...)。送信すべき 0 でない係数の数 NC が 4 より少ない場合、i=NC 〜 3 について、TCoefIDX[i] は 63 (16進の 0x3F)、TCoefValue[i] は TCoefValue[NC-1] でなければならない。
IDCT はホスト上で実行することもできる。この場合、結果は API を使って渡される。結果送信のスキームとしては、16 ビットと 8-8 オーバーフローの 2 つの方法がサポートされる。どちらが使用されるかは、bConfigSpatialResid8 に示される。
16 ビット方式を使って 16 ビットデータを送信する場合は、データのブロックは連続的に送信される。空間領域データの各ブロックは、DXVA_Sample16
の WT·HT 値で構成される。
A DXVA_Sample16 は 16 ビットの符号付き整数である。BPP が "8" より大きい場合は、16 ビット方式だけが使用できる。bPicIntra が "1" で BPP が "8" の場合は、16 ビット方式は使用できない。IntraMacroblock が "0" なら、16 ビット サンプルはモーション圧縮された予測値に関する符号付きの数として送られる。IntraMacroblock が "1" なら、16 ビット サンプルは以下のように送られる :
データのブロックは、MSB から LSB に 1 バリュー ビットのスキャンにより指定された wPatternCode 順に、シーケンシャルに送られる。
注 :
BPPが "8" の場合は、8 ビット差異方式が使用できる。bPicIntra が "1" で BPP が "8" の場合は、この方式を使用する必要がある。その場合、各空間領域差異値は、8 ビットだけを使って表現される。この場合、各空間領域差分値は 8 ビットだけを使って表現される。8 ビットメソッドを使ってデータを送るとき、8 ビットデータのブロックはシーケンシャルに送られる。8 ビット空間領域残差データの各ブロックは DXVA_Sample8 の WTxHT 値から構成される。
IntraMacroblock が 1 の場合は、8 ビット サンプルはモーション圧縮予測に応じて加算あるいは減算 (bConfigResid8Subtraction と、サンプルが最初のパス ブロックとオーバーフロー ブロックのどちらにあるかにより決定) される符号付き差異である。IntraMacroblock が 0 でブロック内のあるピクセルを表現する差異が8ビットを使う表現にとって大きすぎるなら、サンプルの 2 つ目の"オーバーフロー" ブロックが送られ得る。
IntraMacroblock が "1" なら、8 ビットサンプルは次のように設定される :
データのブロックは、MSB から LSB に 1 バリュー ビットのスキャンにより指定された wPatternCode 順に、シーケンシャルに送られ、次にすべての必要な 8 ビット オーバーフロー ブロックが wPC_Overflow に指定されたとして送られる。bConfigResid8Subtraction が "1" なら、このようなオーバーフロー ブロックは加算ではなく減算される。
各非イントラ マクロブロックの 8 ビット差異の最初のパスが追加される。bPicOverflowBlocks が "0" あるいは IntraMacroblock が "1" なら、2 つ目のパスはない。bPicOverflowBlocks が "1"、IntraMacroblock が "0" で、bConfigResid8Subtraction が "1" なら、各非イントラ マクロブロックの 8 ビット 差異の 2 番目のパスが追加される。
元の 8 ビット ブロックおよび対応する 8 ビット オーバーフロー ブロックの両方で、いずれかのサンプルが 0 でない場合、次のようになる。
これにより、2 つのパスのそれぞれの後に、結果の 8 ビット クリッピングと共に、サンプルを予測ピクチャに追加できる。
注 : IntraMacroblock が 0 の場合、ビデオ コーディング標準規格に厳密に準拠しなくなるので、8+8 方式では +255 の残差値を表現できない。しかし、ここではこのフォーマットはサポートされている。その理由は、このフォーマットが、1) いくつかの既存の実装で使われている、2) ピクチャを表現するために必要なデータ量という点で効率的である、3) 通常はビデオ品質を有意に悪化させる結果にならないと考えられる、という理由による。
ブロック解除フィルタ制御コマンドが存在する場合、このコマンドは、マクロブロック内の各輝度ブロックに対して送信され、色光度ブロックの各組に対して 1 度ずつ送信される。コマンドは、マクロブロック内のラスタ スキャン順序で送信される。色光度のブロックの前に輝度のすべてのブロックが送信され、次に、色光度 4:2:0 コマンド 1 つ、必要に応じて色光度 4:2:2 コマンド 1 つ、次に必要に応じて色光度 4:4:4 コマンド 2 つと続く (両方の色光度成分に同じフィルタリングが適用される)。各ブロックのフィルタリングは、上端にかけて現れるブロック解除の仕様、およびそれに続く、左端にかけて現れるブロック解除の仕様によって指定される。色光度のブロック解除は一度だけ指定され、Cb 成分と Cr 成分の両方に同じブロック解除コマンドが使用される。たとえば、4:2:0 データを含む 16x16 のマクロブロックを、8x8 ブロックを使ってブロック解除する場合、輝度ブロック用に上下 2 つのエッジ フィルタリング コマンドを 4 セット送信し、次に色光度用に 2 つのエッジ フィルタリング コマンド 1 セットを送信することによって指定する。各ブロック解除エッジの指定のデータ構造は次のとおり。
DXVA_DeblockingEdgeControl {
EdgeFilterStrength 7 /* H.263 では 4b のみ必要 */
EdgeFilterOn 1
}
EdgeFilterStrength : このパラメータは、H.263 補遺 J で指定された、実行されるフィルタリングの強度を指定する。
EdgeFilterOn : このフラグは、エッジがフィルタされる場合は 1 となり、それ以外の場合は "0" でなければならない。
EdgeFilterOn が "1" と等しいエッジに対する実際のエッジ フィルタリングは、H.263 補遺 J に指定されているように、EdgeFilterStrength に指定された値で、範囲 [0, (2BPP)-1] への出力時のクリッピングを伴って、正確に実行されなければならない。H.263 補遺 J に指定されているように、すべてのブロックのすべての上エッジ フィルタリングは、どのブロックのどの左エッジ フィルタリングよりも "先に" 実行されなければならない (上エッジ フィルタリングに使われるサンプルの値は、左エッジ フィルタリングのどのブロック解除フィルタよりも先に再構築された値でなければならないという意味において)。
現在のブロック解除フィルタ コマンド バッファの外にあるマクロブロックのサンプル値が影響を受けないことが、バッファ タイプによって示されている場合は、バッファ内にブロック解除フィルタ コマンドを持つマクロブロックが担当するリージョンの左および上のすべてのエッジに対して、EdgeFilterOn パラメータは "0" でなければならない。
bPicReadbackRequests が "1" の場合は、読み戻しコマンド バッファが 1 つ存在し、これがアクセラレータに対して、結果の最終 (適応できるなら非ブロックの後で) ピクチャ マクロブロック データをホストに返すよう指令する。暗号化プロトコルを使用中なら、アクセラレータはガベージデータを返す、カプセルデータを返すなどのエラー指摘 (暗号化プロトコルによって指定される) を返して読み戻しリクエストに対応する場合がある。
アクセラレータに渡されるバッファには、読み取り対象のマクロブロック 1 つにつき 1 つのパラメータを含む読み戻しコマンドが含まれなければならない。
wMBaddress : (16 ビット) 現在のマクロブロックのマクロブロック アドレスをラスタ スキャン順序で指定する ("0" は左上マクロブロックのアドレス、PicWidthInMBminus1 は右上マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB は左下マクロブロックのアドレス、PicHeightInMBminus1 * PicWidthInMB + PicWidthInMBminus1 は右下マクロブロックのアドレス)。
BPP が "8" の場合は、データは符号なしの 8 ビット値 (したがって表面上、黒は Y=16、Cb=Cr=128 となり、白は Y=235、Cb=Cr=128 となる) で返されなければならない。BPP > 8 の場合は、データは符号なしの 16 ビット値で返されなければならない。
データは、アクセラレータからホストへ、次のフォーマットで返される。
生のビットストリーム データの可変長デコードがアクセラレータ上で実行される場合、ピクチャのデコードのためにホストによって送信されるデータは、次の 3 タイプのバッファに分割される。
逆量子化行列バッファは、オフホストでのビットストリーム デコード用に逆量子化行列を初期化するために送信される。逆量子化行列バッファは、新しい逆量子化行列バッファが供給されるまで、ビットストリーム内の、現在およびそれに続くすべてのビデオのデコード方法に関する情報を提供する。(この点で、逆量子化行列は固定的である。) ホストからアクセラレータに一度に複数の逆量子化行列バッファを送信してはならない。
DXVA_QmatrixData { for(i=0; i<4; i++) bNewQmatrix[i] // 8b for(i=0; i<4; i++) if(bNewQmatrix[i] == 1) Qmatrix[i] // WT・HT・16b }
bNewQmatrix[i] : タイプ i の新しい逆量子化行列がバッファ内に存在するかどうかを示す。bNewQmatrix[i] が "1" の場合は、逆量子化行列バッファ内にタイプ i の新しい逆量子化行列が続いている。タイプ i=0 はイントラ輝度量子化、i=1 はインター輝度量子化、i=2 はイントラ色光度量子化、i=3 はインター色光度量子化である。ホストから先行する値が送られていない場合、アクセラレータは逆量子化行列のデフォルト値を想定できない。i=0 および i=1 の両方について、bNewQmatrix[i] の値は 0 であってはならない。
i=2 または i=3 について bNewQmatrix[i] の値が "0" の場合は、次のようになる。
該当するビデオ コーディング仕様で逆量子化行列が必要とされない場合 (H.261 や H.263 など) は、逆量子化行列バッファを送信してはならない。該当するビデオ コーディング仕様で逆量子化行列が必要とされる場合は、ホストによって、ビデオ デコード処理の開始時に、いずれかのビットストリーム データ バッファの転送の前、または転送と協調して、これらの逆量子化行列のために値が提供される必要がある。
注 : ホストから先行する値が送られていない場合は、量子化行列のデフォルト値は設定されない。該当するビデオ コーディング仕様でデフォルトで使用できる値が含まれているとしても、量子化行列の値は、明示的に送信される必要がある。
Qmatrix[i] : 逆量子化行列。bNewQmatrix[i] が "1" の場合のみ存在する。行列は、WT・HT 符号なしワード (各ワードの下位の 8 ビットだけが有力なビデオ コーディング標準規格で使用される) で構成される。逆量子化行列内でのデータ値の順序は、該当するビデオ コーディング仕様の定義に従わなければならない。
注 : MPEG-2ビットストリームの場合、Qmatrix[i] 内のデータ値は、MPEG-2 の副節 7.3.1 および 図 7-2 で指定されているとおり、ジグザグ逆スキャン順序である。
オフホストでの VLD ビットストリーム処理を先導するため、スライス制御バッファが提供されなければならない。ホスト ソフトウェア デコーダは、ビットストリーム内の "スライスレベルの" 再同期化ポイントを決定しなければならない。スライスは、ビットストリーム データ内に再同期化ポイントを含むマルチマクロブロック レイヤとして定義される。H.261 ビットストリームでは、GOB をスライスと見なし、H.263 ビットストリームでは、GOB 開始コードに続く一連の GOB をスライスと見さなければならない。スライス制御バッファには、対応するビットストリーム データ バッファの内容に応じて、1 つ以上の DXVA_SliceInfo データ構造体が含まれていなければならない。
DXVA_SliceInfo { wHorizontalPosition //16b wVerticalPosition //16b dwSliceBitsInBuffer //32b dwSliceDataLocation //32b bStartCodeBitOffset // 8b bReservedBits // 8b wMBbitOffset //16b wNumberMBsInSlice //16b wQuantizerScaleCode //16b wBadSliceChopping //16b }
wHorizontalPosition、wVerticalPosition : スライスの最初のマクロブロックの水平位置および垂直位置を、マクロブロックの単位で表したもの、0 はピクチャの一番上または一番左のマクロブロックを意味する。
dwSliceBitsInBuffer : 現在のスライスのデータを含む、対応するビットストリーム データ バッファ内の合計ビット数。MPEG-1、MPEG-2、および MPEG-4 では、スライス開始コードがバイト整列されるため、この値は 8 の倍数でなければならない。
dwSliceDataLocation : ビットストリーム データ バッファ内の、スライスのデータを含む最初のバイトの位置 (スライス開始コードの位置など)。スライスの開始部分が、対応するビットストリーム データ バッファ内にない場合は、0 でなければならない。
bStartCodeBitOffset : スライスのデータを含まない、dwSliceDataLocation のバイトの MSB の数 (MPEG-1、MPEG-2、MPEG-4 では、スライス開始コードがバイト整列されるため、0 となるが、H.261 および H.263 では、GOB 開始コードのバイト整列を強制しないため、0 でない場合がある)。範囲は、0...7 でなければならない。スライスの開始部分が、対応するビットストリーム データ バッファ内にない場合は、0 でなければならない。bStartCodeBitOffset によって、現在のスライスに関係しないとマークされた MSB は、前のスライスのデータを含む場合がある。
bMBbitOffset : スライスの開始部分から、ビットストリーム バッファ内のマクロブロック レイヤ データの最初のビットへのビット数。たとえば、wMBbitOffset が 83 なら、スライスのマクロブロック レイヤ データはスライス ヘッダー データ 83 ビットから開始する。スライスの開始部分が、対応するビットストリーム データ バッファ内にない場合は、0 でなければならない。
wNumberMBsInSlice : スキップされるマクロブロックを含め、スライス内にあるデータのマクロブロックの数。ピクチャのヘッダー、およびビットストリーム内の現在と次のスライスのヘッダーと初期マクロブロック データから、H.263 のスライス モードの任意スライス順序サブモードのようにこの数がすぐに決定できない場合は、0 の場合がある。H.261、MPEG-1、MPEG-2、MPEG-4 あるいは H.263 でスライス構造化モードの矩形スライスか任意スライス サブ モードを使用していないとき、ゼロであってはならない。
wQuantizerScaleCode : それぞれのビデオ コーディング仕様で指定された、ビットストリームのスライス レベルからの量子化スケール コード (H.261、MPEG-2、H.263、MPEG-1、および MPEG-4 に対して "1" 〜 "31" の範囲)。
wBadSliceChopping : 次のように定義された値が入るパラメータ。
"0" : スライスのすべてのビットが、対応するビットストリーム データ バッファ内に位置する。
"1" : スライスの開始部分のビットが、対応するビットストリーム データ バッファ内にあり、スライスの終了部分のビットが (ビットストリーム データ バッファが一杯なため)、対応するビットストリーム データ バッファ内にない。
"2" : スライスの開始部分のビットが (前のビットストリーム データ バッファが一杯たなめ)、対応するビットストリーム データ バッファ内になく、スライスの終了部分のビットが、対応するビットストリーム データ バッファ内にある。
"3" : スライスの開始部分のビットが (前のビットストリーム データ バッファが一杯たなめ)、対応するビットストリーム データ バッファ内になく、また、スライスの終了部分のビットも (対応するビットストリーム データ バッファも一杯なため)、対応するビットストリーム データ バッファ内にない。
wBadSliceChopping が 0 以外の値になることは、通常、ホスト ソフトウェア デコーダ側で回避したほうがよい。
ビットストリーム バッファが使用される場合、可変長デコードでの下位ビットストリーム解析を含めたオフホストのデコードをサポートするため、バッファには単に、ビデオ ビットストリームからの生のバイトが含まれる。
意図された設計に沿った方法でビットストリーム データ バッファが使用されるよう、バッファの内容には一定の制限が課せられる。
デコーダでは、ビットストリーム データ バッファへの格納状況を、スライスが複数のバッファになるべくまたがらないように管理したほうがよい。
DirectX VA 機能の 2 番目のタイプは、ビデオ データとブレンドされるアルファ ブレンディング サーフェスを指定する情報のロードである。
アルファ ブレンド データをロードするための DirectX VA 接続構成データ構造体は、次のように定義しなければならない。
DXVA_ConfigAlphaLoad {
// 指定された処理
dwFunction //32b
dwReservedBits[3] // 3 * 32b 整列
bConfigDataType //8b
}
dwFunction : 構成データの構造を記述する DXVA_ConfigQueryOrReplyFunc が含まれる。
bConfigDataType : 使用されるアルファ ブレンド データのタイプを指定する。次のように定義される。
"0" : IA44 アルファ ブレンディング サーフェスと 16 エントリ YUV パレット
"1" : AI44 アルファ ブレンディング サーフェスと 16 エントリ AYUV パレット
"2" : DXPD、Highlight、および DCCMD データと 16 エントリ AYUV パレット
"3" : AYUV グラフィック サーフェス
短期的なアクセラレータ実装では bConfigDataType が "1" あるいは "2" のサポートが許されているが、ほかのフォーマットが望ましく、限定モードプロファイルがそれ以外を示さない限り、フォーマット "1" と "3" の両方が中期的には要求されると予想される
設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットの最低 1 つの接続構成メンバと共に動作できる必要がある。アルファ ブレンディング データをロードするための最小限の相互動作性構成セットは、bConfigDataType のすべての定義値から構成される。
AYUV アルファ ブレンディング サーフェスは、それぞれ 32 ビットのサンプルの配列として定義される。このサーフェスは、グラフィックとデコード済みビデオ ピクチャをブレンドする際に、ソースとして使用できる。
各 AYUV サンプルは次のように構成される。
DXVA_AYUVsample{
bSampleAlpha8 // 8b (MSB)
bY_Value // 8b
bCbValue // 8b
bCrValue // 8b (LSB)
}
bSampleAlpha8 : サンプルの不透明性。値 0 は、サンプルが透明であることを示す (つまり、ほかのエントリはブレンド後のピクチャに影響を与えない)。値 255 は、サンプルが不透明であることを示す (つまり、ほかのエントリがブレンド後のピクチャ サンプルの値を完全に決定する)。SampleAlpha8 の値が "0" でない場合、指定されたブレンドは、グラフィック値の (SampleAlpha8+1) 倍を、ピクチャ値の (255-SampleAlpha8) 倍および定数 128 に加算し、結果を 8 桁右シフトする。SampleAlpha8 の値が 0 の場合は、指定されたブレンドはピクチャ値をそのまま使用する。
bY_Value, bCbValue, bCrValue : 符号付き数量として指定される Y、Cb、Cr 色空間内の色 (ITU-T 勧告 601 による)。たとえば、BPP=8 の場合、表面上、黒は Y=16、Cb=Cr=128 で指定され、白は Y=235、Cb=Cr=128 で指定される。
AYUV アルファ ブレンディング サーフェスの幅と高さは、関連付けられたバッファ記述リスト内で指定される。
16 エントリ YUV パレットは、16 個の DXVA_AYUVsamples サンプルの配列として定義される。この場合、個々のサンプルの SampleAlpha8 は意味を持たないため、"0" でなければならない。
パレットは、グラフィックとデコード済みビデオ ピクチャをブレンドする際に、ソースを作成するために使用できる。このパレットは、以下のいずれかと共に、グラフィック ソースの作成に使用できる。
16 エントリ パレットのみをロードするのではなく、グラフィックの内容を指定する AYUV イメージとして、イメージ グラフィック全体を直接ロードできる。
インデックスアルファ 4-4 (IA44) アルファ ブレンディング サーフェスは、それぞれ次のように構成される 8 ビットのサンプルの配列として定義される。
DXVA_IA44sample{
SampleIndex4 // 4b (MSB)
SampleAlpha4 // 4b (LSB)
}
アルファインデックス 4-4 (AI44) アルファ ブレンディング サーフェスは、それぞれ次のように構成される 8 ビットのサンプルの配列として定義される。
DXVA_AI44sample{
SampleAlpha4 // 4b (MSB)
SampleIndex4 // 4b (LSB)
}
SampleIndex4 : サンプルの 16 エントリ パレットへのインデックス。
SampleAlpha4 : サンプルの不透明性。値 "0" は、サンプルが透明であることを示す (つまり SampleIndex4 のパレット エントリは、ブレンド後のピクチャに影響を与えない)。値 15 は、サンプルが不透明であることを示す (つまり SampleIndex4 のパレット エントリが、ブレンド後のピクチャの状態を完全に決定する)。SampleAlpha4 の値が 0 でない場合、指定されたブレンドは、グラフィック値の (SampleAlpha4+1) 倍を、ピクチャ値の (15-SampleAlpha4) 倍および定数 8 に加算し、結果を 4 桁右シフトする。SampleAlpha4 の値が 0 でない場合、指定されたブレンドはピクチャ値をそのまま使用する。
IA44 アルファ ブレンディング サーフェスの幅と高さは、関連付けられたバッファ記述リスト内で指定される。
デコードされる PXD (DPXD) アルファ ブレンディング サーフェスは、2 ビット サンプルのパックされたフレーム構造化配列として定義される。これらのサンプルはそれぞれ、ハイライトおよび DCCMD データによって決定された 4 色カラー テーブルへのインデックスとして使用される。DPXD、ハイライト、および DCCMD の組み合わせの結果は、IA44 サーフェスと同等であり、16 エントリ YUV パレットと共にブレンディングに使われる。バイトの配列として取り扱われる場合、最初の 2 ビット サンプルのインデックスは、DPXD データの最初のバイトの MSB に、次のサンプルは次の 2 ビットに、3番目のサンプルは次の 2 ビットに、4 番目のサンプルは LSB に、5 番目のサンプルは 次のバイトの MSB に、というように配置しなければならない。
DPXD アルファ ブレンディング サーフェスは、RLE (run-length) エンコード フォーマットの DVD 上の PXD 情報から作成することもできる。このため、DVD 上の PXD から DirectX VA のための DPXD を作成する場合、ホストが、ディスクからの生データの RLE (run-length) デコードを実行する必要がある。
サーフェスのストライドは、2 ビット サンプル単位でなく、バイト単位のストライドとして解釈されなければならない。ただし、幅と高さは 2 ビット サンプル単位でなければならない。
注 : DVD 上の PXD は、フィールド構造化インターレース フォーマットである。ここで定義されている DPXD アルファ ブレンディング サーフェスは、フィールド構造化インターレース フォーマットではない。このため、DVD の PXD データから DPXD を作成する場合は、ホストが、2 つのフィールドからデータをインターリーブする必要がある。
注 : DVD サブピクチャ定義およびデータ フィールド解釈の詳細については、「DVD Specifications for Read-Only Disk:Part 3 – Video Specification (v. 1.11, May '99)」を参照すること。
ハイライト データは、DVD ROM 仕様に準拠した方法でフォーマットされ、アルファ ブレンディング サーフェスを作成するため、DCCMD データと共に DPXD サーフェスに適用される。ハイライト データ バッファの内容は、次のように定義しなければならない。
DXVA_Highlight {
wHighlightActive // 16b
wHighlightIndices // 16b
wHighlightAlphas // 16b
HighlightRect // 128b
}
HighlightActive : 矩形ハイライト領域が現在アクティブになっているかどうかを示す ("0" は非アクティブを示し、"1" はアクティブを示す)。非アクティブの場合、ハイライト データがブレンド後のピクチャの内容に影響を与えてはならない。
HighlightIndices : DPXD 内の各 2 ビット インデックスに対し、サブピクチャ上でハイライトされた矩形領域の 4 ビット パレット インデックスを示す。4 つの MSB はインデックス 3、次の 4 ビットはインデックス 2、次の 4 ビットはインデックス 1、4 つの LSB はインデックス "0" に対応していなければならない。
HighlightAlphas : DPXD に使用される各 2 ビット インデックスに対し、サブピクチャ上でハイライトされた矩形領域の 4 ビット不透明性を示す。4 つの MSB はインデックス 3、次の 4 ビットはインデックス 2、次の 4 ビットはインデックス 1、4 つの LSB はインデックス 0 にしていなければならない。4 ビット不透明性の値は、上の SampleAlpha4 に関する説明と同様に解釈しなければならない。
HighlightRect : RECT データ タイプとしての、矩形ハイライト領域の定義を含む。
RECT パラメータには次の制限が適用される :
注 : DVD の仕様でサブピクチャ矩形領域を定義する方法と、Microsoft アプリケーションで通常使用されている方法には違いがあると見られる。 この仕様では Microsoft の慣例に従い、ピクチャの左上にある幅 10 高さ 10 の矩形を、Top = 0、Left = 0、Right = 10、Bottom = 10 と定義する。DVD の仕様の慣例では、Right = 9 および Bottom = 9 が使用される。
DCCMD (ディスプレイ制御コマンド) データは、DVD ROM 仕様に準拠した方法でフォーマットされ、アルファ ブレンディング サーフェスを作成するため、ハイライト データと共に DPXD サーフェスに適用される。DCCMD データ バッファの内容は、DVD ディスプレイ制御コマンド (DCCMD) のリストとしてフォーマットされたデータで構成しなければならない。
注 : DVD サブピクチャ定義およびデータ フィールド解釈の詳細については、「DVD Specifications for Read-Only Disk:Part 3 – Video Specification (v. 1.11, May '99)」を参照すること。
アルファ ブレンド コンビネーションでは、最後にロードされてたアルファ ブレンド ソース情報を参照ピクチャと組み合わせて、表示用のブレンド ピクチャを作成する。この処理は、アルファ ブレンド コンビネーション データ バッファを使って制御される。
アルファ ブレンド コンビネーションのための DirectX VA 接続構成データ構造体は、次のように定義しなければならない。
DXVA_ConfigAlphaCombine {
// Operation Indicated
dwFunction // 32b
dwReservedBits[3] // 3 * 32b アラインメント
bConfigBlendType // 8b
bConfigPictureResizing // 8b
bConfigOnlyUsePicDestRectArea //8b
bConfigGraphicResizing // 8b
bConfigWholePlaneAlpha // 8b
}
dwFunction : 構成データの構造を記述する DXVA_ConfigQueryOrReplyFunc が含まれる。
bConfigBlendType : 実行されるアルファ ブレンド コンビネーションのタイプを指定する。次のように定義される。
"0": フロントエンドのバッファ間ブレンド
"1": バックエンドのハードウェア ブレンド
短期的なアクセラレータ実装では bConfigBlendType = "1" のサポートが許されているが、中期的には bConfigBlendType = "0" のサポートが必要になるものと予想される。
bConfigPictureResizing: サブピクチャ ブレンディングの PictureSourceRect16thPel が違うかどうかを示す、PictureDestinationRect から (PictureSourceRect16thPel の 1/16th サンプル スケーリングで調整された) 幅と高さ、また PictureSourceRect16thPel のパラメータが16の倍数ではないかどうかを示す、それによってソース ピクチャにアクセラレータによる再サンプルを要求する。"1" は (リサイズ精度であれ、サブピクセル精度であれ) 再サンプルがサポートされていることを示し、"0" はサポートされていないことを示す。
bConfigOnlyUsePicDestRectArea: デコーダが PictureDestinationRect 外に落ちる生成されたデスティネーション ピクチャの出力範囲の値を指定するコマンド操作が可能かどうかを示す。"0" は PictureDestinationRect の外部エリアはブレンド コンビネーション コマンドで指定可能であることを示す。"1" はホスト デコーダは PictureDestinationRect が指定した外のブレンドされたサーフェスの値は信頼できず、そのリージョンは表示できないことを示す。
bConfigGraphicResizing: サブピクチャ ブレンディングの GraphicSourceRect が GraphicDestinationRect のサイズと違っているかどうかを示す、それによってアルファ ブレンディング グラフィックスをアクセラレータが再サンプルするかどうかを要求する。"1" はリサイズがサポートされていることを示し、"0" はサポートされていないことを示す。
bConfigWholePlaneAlpha : グラフィック データに全プレーン アルフファ パラメータを適用できるかどうかを指定する。"1" は全プレーンアルファが適用可能なことを示し、"0" は適用できないことを示す。
設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットの最低 1 つの接続構成メンバと共に動作できる必要がある。アルファ ブレンディング データをロードするための最小限の相互動作性構成セットは bConfigBlendType から構成される、それは DirectX VA 限定モード プロファイルによって決められた範囲の値を持つ。
アルファ ブレンド コンビネーション バッファは、ソース ピクチャと、アルファ ブレンディング情報を伴うグラフィック イメージからの、ブレンド ピクチャの生成を制御する。ソース ピクチャおよび宛先ピクチャが 4:4:4 フォーマットでない場合は、サブサンプリングされたソースの基準色情報に対して、グラフィック ブレンディング情報のサンプルが 1 つ置き (1、3、5 など) に、ブレンド結果を得るために適した方向 (垂直または水平) に適用されなければならない。
DXVA_BlendCombination {
wPictureSourceIndex //16b
wBlendedDestinationIndex //16b
PictureSourceRect16thPel //128b
PictureDestinationRect //128b
GraphicSourceRect //128b
GraphicDestinationRect //128b
wBlendDelay //16b
bBlendOn //8b
bWholePlaneAlpha //8b
OutsideYUVcolor //32b
}
wPictureSourceIndex : グラフィックと組み合わされるピクチャのインデックス。バックエンドのハードウェア アルファ ブレンディングが使用されている場合は、0xFFFF でなければならない。
wBlendedDestinationIndex : 作成される組み合わせピクチャのインデックス。バックエンドのハードウェア アルファ ブレンディングを使用している場合は、0xFFFF でなければならない。wPictureSourceIndex と同じであってはならない。
PictureSourceRect16thPel: グラフィックと組み合わされるソースピクチャの範囲は輝度コンポーネントの 1/16th サンプルの単位で RECT データ構造体として指定される。言い換えると、RECT データ 構造体のパラメータは固定小数点で表現される、バイナリ ポイント前 28 ビットと後 4 ビットである。(この 1/16th サンプル精度では PictureSourceRect16thPel はMPEG-2 の frame_centre_horizontal_offset と frame_centre_vertical_offset パン-スキャン パラメータと同じ精度を持つ) bConfigPictureResizing が "0" なら、PictureSourceRect16thPel のすべてのパラメータは 16 の整数倍でなければならない。
次の制限が PictureSourceRect16thPel の RECT パラメータに適用される :
たとえば、PictureSourceRect16thPel を使って全 MPEG-2 デコードされたピクチャを選択したら、PictureSourceRect16thPel パラメータは次のように計算される :
PictureDestinationRect : ソース ピクチャからの領域を保持する宛先ピクチャの領域。RECT データ構造体として指定する。bConfigPictureResizing が "0" の場合は、幅と高さが PictureSourceRect16thPel で指定された領域と同じでなければならない。PictureDestinationRect と PictureSourceRect16thPel のサイズが異なる場合、適用される再サンプリング方式は指定されないが、最低でもバイリニア再サンプリングと同等の品質を持っていたほうがよい。
次の制限が RECT パラメータに適用される :
GraphicSourceRect: ソース ピクチャと組み合わされるグラフィック ピクチャの領域。RECT データ構造体として指定する。アルファ ブレンド データ ローディングが bConfigDataType に "2" を使うなら、次の制限が GraphicSourceRect に適用される :
次の制限が RECT パラメータに適用される :
GraphicDestinationRect : グラフィック ピクチャからの領域を保持する宛先ピクチャの領域。RECT データ構造体として指定する。bConfigGraphicResizing が "0" の場合は、幅と高さが GraphicSourceRect で指定された領域と同じでなければならない。GraphicDestinationRect と GraphicSourceRect のサイズが異なる場合、グラフィックに適用される再サンプリング方式は指定されないが、最低でもブレンディング情報を表す AYUV サーフェスのバイリニア再サンプリングと同等の品質を持っていたほうがよい。
次の制限が GraphicDestinationRect の RECT パラメータに適用される :
アルファ ブレンド データ ローディングが bConfigDataType に "2" を使い、bConfigGraphicResizingに "0" を使うなら、次の制限が GraphicSourceRect に適用される :
注 : DVD の仕様でサブピクチャ矩形領域を定義する方法と、Microsoft アプリケーションで通常使用されている方法には違いがあると見られる。 この仕様では Microsoft の慣例に従い、ピクチャの左上にある幅 10 高さ 10 の矩形を、Top = 0、Left = 0、Right = 10、Bottom = 10 と定義する。DVD の仕様の慣例では、Right = 9 および Bottom = 9 が使用される。
wBlendDelay : バックエンドのハードウェア ブレンディングが使用されている場合、wBlendDelay には組み合わせ処理により効果が現れるまでのディレイ (ミリ秒数) が含まれる。フロントエンド ブレンディングが使用されている場合は、意味がないため、0 でなければならない。
bBlendOn : バックエンドのハードウェア ブレンディングが使用されている場合は、bBlendOn が "1" のブレンディング コンビネーション機能で指定された時間から、bBlendOn = 1 の新しいブレンディング コンビネーションで指定された実行時間までか、または bBlendOn が "0" のブレンディング コンビネーション機能によりブレンディングが無効になるまで、指定されたブレンディングが適用されなければならない。
bWholePlaneAlpha : グラフィックのアルファ チャンネルの不透明性を示す乗数が含まれる。値 "0" は、グラフィックが透明であることを示し (つまりグラフィックの内容がブレンド後のピクチャに影響を与えない)、値 "255" は、グラフィック内容がサンプルの不透明度を最大限使用することを示す。bWholePlaneAlpha の値が "0" でない場合、指定されたブレンドは、グラフィック内容の各位置の不透明度に (bWholePlaneAlpha+1)/256 を乗算する。bWholePlaneAlpha の値が "0" の場合、指定されたブレンドは、グラフィック内容で指定された不透明度をそのまま使用する。bConfigWholePlaneAlpha が "0" の場合は、"0" でなければならない。
OutsideYUVcolor: PictureDestinationRect 外の範囲がブレンディング 一定色を持つとして生成されるかどうかを示す識別子が入る、またその場合その一定色が入る。OutsideYUVcolor は DXVA_AYUVsample としてフォーマットされ、以下の決まりに従う :
bConfigStayInPicDestRectArea が "1" なら、OutsideYUVcolor の bSampleAlpha8 の値は "1" でなければならない。
OutsideYUVcolor の bSampleAlpha8 が "0" なら、ブレンドの影響を受けるデスティネーション サーフェスの範囲は PictureDestinationRect 内の部分である。OutsideYUVcolor の bSampleAlpha8 が "255" なら、PictureDestinationRect 外だが GraphicDestinationRect 内のデスティネーション サーフェスの範囲は OutsideYUVcolor の非アルファ パラメータに指定される色でブレンディングしたグラフィックによって生成され、PictureDestinationRect と GraphicDestinationRect 両方の外に落ちるデスティネーション サーフェスの全割り当て範囲は OutsideYUVcolor の非アルファ パラメータで指定された色に設定される。bConfigBlendType が "1" なら、OutsideYUVcolor パラメータは黒とのブレンディングを示す bSampleAlpha8 = 255, bY_Value = 16, bCbValue = bCrValue = 128 を指定しなければならない。
注 : bConfigBlendType が "1" (バックエンド ハードウェア ブレンド) なら、実際のブレンディング操作はここで説明したものとは少し異なる場合がある。しかし、表示結果は同じでなければならない。たとえば、ビデオ ピクチャをソースからデスティネーション サイズにマップするよう指定したリサイズは、逆の方法でグラフィック内容をソースビデオ ピクチャに従ってその正しい位置にマップするよう適用されるかもしれない、するとこの操作の違いに対応してブレンディング結果が表示される - しかし結果の最終視覚効果はブレンド コンビネーション コマンドで指定されなければならない。
たとえば、PictureSourceRect16thPel を使って MPEG-2 ビデオ パン - スキャン パラメータが指定する範囲を選択した場合、PictureSourceRect16thPel パラメータは次のように組み合われる (その計算された値が上の制限に反しないように提供される、MPEG-2 パン - スキャン パラメータの場合と 特に MPEG-2 DVD コンテンツの場合) :
次に PictureDestinationRect は通常次のように作成される :
たとえば、16:9 ピクチャで 4:3 パン スキャンを MPEG-2 DVD で使うと、パン スキャン パラメータは上記の制限を犯さない範囲に制限され、更にこの場合にはパン スキャン パラメータは次の制限に従う :
次に 3.7.3.1 章で説明されている公式がこの場合直接に適用される。
もう 1 つの例として、704 ワイド ピクチャで DVD MPEG-2 を使うとき、デコードされたピクチャの境界を拡張する 3.7.3.1 章を使うと (デコードされた horizontal_size を 704 に拡張するように display_horizontal_size に 720 を指定するなら)、転送元矩形を指定する。このような場合、ホスト ソフトウェア デコーダは転送元矩形を割り当てられたソース範囲の外まで届くようにクロップし、そのクロップに対してデスティネーション矩形の調整を管理する必要がある。この場合、2 つの基本的な場合がある。両方とも次のようなピクチャ 転送元矩形の指定を要件とする :
2 つの場合とは :
これらの 2 つの場合のうち多分 2 番目が優先される
もう 1 つの例は 325 ワイドピクチャの DVD 使用である、これはピクチャ 転送元矩形 (1/16th サンプル解像度) を使って 704 の幅に拡大する :
これらの 2 つの場合のうち多分 2 番目が優先される
かなり小さな例は 720 ワイド ピクチャの DVD MPEG-2 の使用である、(1/16 サンプル解像度で) ピクチャ 転送元矩形は次のとおりである :
もう 1 つの例はレターボックス フレーミングを持つ 4:3 ディスプレイでのDVD 16:9 ビデオの使用である。以下のピクチャ 転送元矩形を使うことによってサポートされる :
ピクチャの再サンプリング機能は、空間スケーラブル ビデオ コーディング、参照ピクチャの再サンプリング、またはアップサンプル ピクチャや表示ピクチャとして使用するための再サンプリングといった目的で定義される。
再サンプリングは、ピクチャのエッジでの "クリッピング" を使い、H.263 補遺 O 「空間スケーラビリティ (Spatial Scalability)」、または MPEG-2 および MPEG-4 の「空間スケーラビリティ (Spatial Scalability)」のいくつかのフォーマットと同じである H.263 補遺 P に定義されているように実行されなければならない。この場合、単純な 2 タップ分割可能フィルタリングが使用される。
ピクチャの再サンプリング制御に接続構成は不要である。この処理には適切な制限モード GUID のサポートのみが必要となる。
ピクチャの再サンプリング制御には接続構成が不要なため、この処理に最小限の相互動作性セットを定義する必要はない。
再サンプリング処理を制御するためのバッファタイプが 1 つ定義されている。
DXVA_PicResample {
wPicResampleSourcePicIndex // 16b
wPicResampleDestPicIndex // 16b
wPicResampleRcontrol // 8b
bPicResampleExtrapWidth // 8b
bPicResampleExtrapHeight
dwPicResampleSourceWidth // 32b
dwPicResampleSourceHeight // 32b
dwPicResampleDestWidth // 32b
dwPicResampleDestHeight // 32b
dwPicResampleFullDestWidth // 32b
dwPicResampleFullDestHeight // 32b
}
wPicResampleRcontrol : 再サンプリング処理の平均化丸めモードを指定する。H.263 補遺 O 「空間スケーラビリティ (Spatial Scalability)」の場合は、このパラメータは 1 でなければならない。(これは、H.263 補遺 O の空間スケーラビリティに必要なアップサンプリングと同等の、H.263 補遺 P の RCRPR の値に対応する。) H.263 補遺 P 「参照ピクチャ再サンプリング (Reference Picture Resampling)」の場合は、このパラメータは H.263 のパラメータ RCRPR と同じでなければならない。
bPicResampleExtrapWidth、bPicResampleExtrapHeight : 0 以外で、かつピクチャ境界上での動きベクトル使用のパディング方法がアクセラレータ上で使用されている場合は、再サンプリングに、再サンプルされたピクチャのパディングが含まれなければならない。また、このパディングは、実行される再サンプリング処理に関係なく、少なくとも、再サンプルされたピクチャの各エッジの周りに指定された幅および高さをカバーしなければならない。
dwPicResampleSourcePicIndex : 再サンプル対象の参照バッファを指定する。
dwPicResampleDestPicIndex : 参照ピクチャの再サンプリング処理の出力に使用されるバッファを指定する。
dwPicResampleSourceWidth、dwPicResampleSourceHeight : 宛先ピクチャに再サンプルされるソース ピクチャの領域の幅と高さ。
dwPicResampleDestWidth、dwPicResampleDestHeight : ソース ピクチャから再サンプルされたデータを格納する宛先ピクチャの領域の幅と高さ。
dwPicResampleFullDestWidth、dwPicResampleFullDestHeight : ソース ピクチャから再サンプルされたデータを格納する宛先ピクチャの領域全体の幅と高さ。ソース再サンプリング領域の外にサンプルを生成するには、クリッピングが使用されなければならない。(このパラメータは、輝度の幅または高さが 16 で除算できないカスタム ソース フォーマットに H.263 補遺 P サポートを提供するために必要となる。)
多くの制限モード プロファイルがこの章で定義される。これらの制限モード プロファイルによって、どの制限モード プロファイルをサポートしているかの指標が得られるので、デコーダはアクセラレータの性能を確認することができる。
ここで定義されているいくつかの制限モード プロファイルはここで定義される他の制限モード プロファイルの能力の単純なサブセットで定義される (たとえば、MPEG2_A プロファイルは MPEG2_B プロファイルの能力のサブセットである)。アクセラレータ能力決定の論理構造を強化するため次のことが要求される、ある個別の制限モード プロファイルをサポートするアクセラレータは、問題のそのプロファイルの能力のサブセットとして定義されるすべての制限モード プロファイルをもサポートしなければならない。たとえば、MPEG2_A プロファイルは MPEG2_B プロファイルの能力のサブセットとして定義されるので、MPEG2_B プロファイルをサポートするすべてのアクセラレータは MPEG2_A プロファイルをもサポートしなければならない。
以下に挙げる制限モード プロファイルは、将来広くサポートされると思われる機能の組み合わせを見越して定義された。Microsoft では、これら以外の、実用的かつ必要と思われる各種機能の組み合わせを含む新規プロファイル追加の提案を受け入れている。制限モード プロファイルは、デコードに必要な一連のビデオ コーディング "ツール" を確立するために、この仕様で定義されている。最も重要な点は、特定のビデオ データ フォーマットが、API を使って何らかの方法でデコードできるかどうかを決定することである。一連の "ツール" を確立することに加え、デコーダは、それらのツールを、API を使ってどのように操作するか認識している必要がある。これについては、続く構成情報のセクションで解説する。
この API/DDI が、以下に定義する制限モード プロファイルに厳密に準拠せずに使用される場合、wRestrictedMode フィールドは、制限がないことを示す値に設定されなければならない。
H261_A 制限プロファイルには、ITU-T 勧告 H.261 を最小限にサポートするのに必要な一連の機能が含まれる。H.261 補遺 D グラフィックのアクセラレーション サポートは除外される。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、次の一連の制限によって定義される。
H261_B 制限プロファイルには、ITU-T 勧告 H.261 をサポートするのに必要な一連の機能が含まれる。H.261 補遺 D グラフィックのアクセラレーション サポートは除外されるが、ブロック解除フィルタ ポストプロセッシングのサポートは含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H261_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
H263_A 制限プロファイルには、ITU-T 勧告 H.263、および少数の特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。
H263_B 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、H263_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
H263_C 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、長期的な必要条件である。この機能セットは、H263_B 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
H263_D 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、H263_C 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
注 : MotionForward が "1" で MotionBackward が "1" の場合、H.263 では bBidirectionalAveragingMode が "1" のサポートだけが必要となるが、H263_C 制限プロファイルでは、bBidirectionalAveragingMode = 0 も可能である。これは、H263_C 制限プロファイルが、H.263 ビデオに加え、MPEG-4 ビデオもサポートできるように意図して設計された。MPEG-4 は、MPEG-1/MPEG-2 フォーマットの双方向平均化を使用する。
H263_E 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H263_D 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
H263_F 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H263_E 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
MPEG1_A 制限プロファイルには、MPEG-1 ビデオをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。
MPEG2_A 制限プロファイルには、MPEG-2 ビデオ メイン プロファイルをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。
MPEG2_B 制限プロファイルには、MPEG-2 ビデオ メイン プロファイルおよび関連するフロントエンド バッファ トゥー バッファ サブピクチャ ブレンディングを使った DVD サブピクチャをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、MPEG2_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。
The MPEG2_C 制限プロファイルには MPEG-2 ビデオ メイン プロファイルをサポートするために必要な一連のフィーチャーが含まれる。このプロファイルのサポートは中期的要件である。このフィーチャー セットは上記の MPEG2_A 制限プロファイルにリストしたものと同じ制限によって定義される、ただし次の項目については異なる :
MPEG2_C 制限プロファイルは MPEG2_A プロファイルのアクセラレータ プロファイルを緩和することによって定義され (これによってアクセラレータは MPEG2_A の最小相互運用性セットのメンバをサポートせずに済む) 、MPEG2_A をサポートするすべてのアクセラレータは MPEG2_C プロファイルをサポートしなければならない。同様に、MPEG2_D プロファイルをサポートするすべてのアクセラレータは MPEG2_C プロファイルをサポートしなければならない。
MPEG2_D 制限プロファイルには MPEG-2 ビデオ メイン プロファイルのサポートに必要なフィーチャー セットと、バックエンド ハードウェア サブピクチャ ブレンディングを使った DVD サブピクチャを組み合わせるために必要なフィーチャー セットが含まれる。このフィーチャー セットは上記の MPEG2_B 制限プロファイルにリストしたものと同じ制限によって定義される、ただし次の項目については異なる :
MPEG2_D 制限プロファイルは MPEG2_B プロファイルのアクセラレータ プロファイル を緩和することによって定義され (これによってアクセラレータは MPEG2_B の最小相互運用性セットのメンバをサポートせずに済む)、MPEG2_B をサポートするすべてのアクセラレータは MPEG2_D プロファイルをサポートしなければならない。
IAMVideoAccelerator は、Windows 2000 内に DirectX VA 処理メカニズムを備えるためのインターフェイスである。このセクションでは、DirectX VA データ フォーマットがこのインターフェイスを介してどのように送信されなければならないかを説明する。
以下は、現在の Microsoft DirectShow® ドキュメント セットにある IAMVideoAccelerator の使用に関する概要説明を拡張、また向上させることを意図している。
注 : このインターフェイスは、Microsoft Windows® 2000 で利用可能である。
オーバーレイ ミキサーの入力ピンは IAMVideoAccelerator インターフェイスをサポートしており、デコーダの出力ピンは IAMVideoAcceleratorNotify インターフェイスをサポートしている。フィルタ ピン接続のイベントは次の順序で発生する。
初期化後の処理中の IAMVideoAccelerator の使用について次に解説する。
(しかしながら、DirectX VA 操作にはビットストリームの各ピクチャの処理には IAMVideoAccelerator::BeginFrame と IAMVideoAccelerator::EndFrame 呼び出しが必要だという要件がある、これについては後に説明する。)
DirectX VA でデコード可能なデータ タイプは多岐にわたるため、またこれらのデータ タイプそれぞれに対して DirectX VA では複数のデコード構成 (ビットストリーム バッファ、ホスト残差デコード、当該バッファ タイプごとに暗号ありまたは暗号なしのアクセラレータベースの IDCT など) がサポートされているため、個々のデータ タイプとデコード構成にそれぞれ一意の GUID を指定することはあまり良い方法とはいえない。個々に指定すると GUID の数が多くなりすぎ (DirectX VA のプロファイルが 16 個あり、それぞれに 16 個の構成があると仮定すると、256 個の GUID を定義する必要がある)、それらを保持するためだけに 4 KB のメモリをすべて使い果たしてしまう。DirectX VA を IAMVideoAccelerator にマップする方法を決定する際、この点は、非常に難しい問題である。これに対し、ほかの処理定義はきわめて単純と言える。結果として、我々は各データ タイプ (つまり各制限モード プロファイル) のみに対して一意の GUID を指定し、追加の GUID 1 つを、各暗号タイプに関連付けられるようにする。その後デコード構成は、デコーダとアクセラレータの間で、DirectX VA 機能の個々のタイプについて構成を確立するための、プローブおよびロック処理を使った下位従属ネゴシエーションによって確立される。
厳密な処理メカニズムは次のとおり。
いずれかのタイプの "深刻" な問題が示される場合、対策をとれない限り、ソフトウェア デコーダは機能の実行を止めたほうがよい。アクセラレータから返されるこのデータは、ピクチャのバッファ レンダリングが完了する前に、ホストから読み取ってはならない。バッファ レンダリングの完了は、IAMVideoAccelerator::QueryRenderStatus でテストできる。返される HRESULT は、インターフェイス処理が正常に動作していれば S_OK となり、プロトコル実行における深刻な問題があれば E_FAIL か E_INVALIDARG またはその他のエラーを示す HRESULT となる可能性がある。
ここでは、DirectX VA インターフェイスの動き補償デバイス ドライバの側面について解説する (「Windows 2000 DDK - Graphics Drivers - Design Guide - 3.0 DirectDraw DDI - 3.12 Motion Compensation」を参照)。次に、DD_MOTIONCOMPCALLBACKS 構造体を使ってアクセスされるエントリに関連する項目を列挙する。