Microsoft DirectX 8.0

Microsoft DirectX VA : ビデオ アクセラレーション
API/DDI 仕様 (Rev 1.0)

注 : このスペックの最新版は Microsoft® Word® フォーマットで http://www.microsoft.com/hwdev/DirectX_VA/ からダウンロード可能である。

要約 :  この文書では、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 の設計の中で、多量の計算を要する最も基礎的な部分を抜き出し、ハードウェア内でのそれらのアクセラレーションをサポートするよう設計されている。

グラフィック ハードウェア ドライバは、グラフィック ハードウェア実装のアクセラレーション機能に対する共通のアクセス方式を提供するため、このインターフェイスをサポートしたほうがよい。過去に、グラフィック ハードウェア メーカー数社から、これとよく似た機能が自社製品専用のものとして定義されたことがあった。しかし、この仕様の目的は、ソフトウェア アプリケーション プログラムと高度なグラフィック アクセラレーション機能の間に、ベンダーに依存しない共通インターフェイスを確立することである。共通インターフェイスの確立により、ビデオをサポートするコンピューティング システムの能力が拡大され、この機能を提供するソフトウェア アプリケーションの需要が増加し、ハイパフォーマンスなグラフィック機能への需要が増加することが期待される。

1.1 要約

この仕様で定義されているインターフェイスは、ITU-T の H.26x シリーズおよび ISO/IEC JTC1 の MPEG-x シリーズを含め、現在の主な標準動き補償ビデオ CODEC をサポートすることができる。当初は、現在最も商業的に優勢なビデオ CODEC である MPEG-2 (厳密には ITU-T 勧告 MPEG-2 または ISO/IEC 13838-2) をサポートするよう設計された。

この文書で定義している構文は、この標準規格を非常に直接的にサポートするよう設計されているため、標準規格の構文をここで定義されたフォーマットに変換する際には、わずかな "翻訳" しか必要ない。ほかの標準規格を最大限に一貫した方法でサポートするために必要な機能も追加された。また暗号化を必要とするアプリケーションのために、暗号化もサポートされている。このインターフェイスでは、各種の標準規格に共通の中心的な基本処理を抽出し、また規格固有のいくつかの処理をホスト CPU に限定している。これにより、規格に依存しない高い柔軟性を持ちながら、アクセラレーション ハードウェアに対する規格ごとのカスタマイズも最小限で済むビデオ CODEC ハードウェア アクセラレーションのサポートを可能にしている。

1.2 目的および関連する標準規格

この仕様は、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 セッション処理が必要となる (例 : フィルタ グラフ処理での使用に、ビデオ デコーダとアクセラレーション ドライバに個別の出力ピンおよび入力ピンのセット)。

1.3 必要条件、パフォーマンス検証、スケジュール

この仕様書に記載されたインターフェイスを使用するすべてのアクセラレータ ドライバについて、この仕様書の内容に準拠していることを確認する必要がある。確認内容は次のとおり。

Microsoft では、これらが検証されていない実装は、あくまでテスト目的に使用すべきであり、この文書で指定しているインターフェイスを公開するドライバに配備すべきではないと考える。

中期的将来には、デコーダおよびグラフィック アクセラレータの実装の認可に、このインターフェイスのサポート、およびサポートのためのパフォーマンス検証が必要となる。厳密なテスト スイートおよびパフォーマンス測定方法はまだ定義されていない。この文書で述べている中期的将来の必要条件は、ハードウェア ビデオ デコード アクセラレーションをサポートするすべてのグラフィック アクセラレーション ハードウェア、およびそれらのグラフィック アクセラレーション ハードウェア サポートを使用するすべてのソフトウェア デコーダについて、2001 年の半ばにおけるすべての Microsoft Windows® オペレーティング システム (Windows 2000、Windows Millennium Edition、および Windows 2000 "Whistler") に適用される条件として定義される予定である。この文書で述べている長期的将来の必要条件は、中期的な必要条件のおよそ 1 年後に適用される条件として定義されている。この期待される要件のデッドライン日付は進行状況によって調整され得る。

暗号化、構成、および制限モード サポートの必要条件については、暗号化サポート、構成、および制限モードに関する以降の各セクションで解説する。ピクセル フォーマット サポートの必要条件については、ここで解説する。

1.3.1 非圧縮ピクチャ フォーマット

DirectX VA で作成されたデコード済み非圧縮ピクチャをアプリケーションで使用するには、それらのピクチャが認識可能なフォーマットで作成されている必要がある。DirectX VA アクセラレータがサポートする非圧縮ピクセル フォーマットのリストには、次のピクセル フォーマット リストのメンバが 1 つ以上含まれていなければならない (「YUV フォーマット」を参照)。

  1. 圧縮 4:2:2 ビデオのデコード :
    1. "YUY2" では、データを符号なし char 型の配列として取り扱うことができる。最初のバイトには Y の最初のサンプルが格納され、2 番目のバイトには Cb の最初のサンプル、3 番目のバイトには Y の 2 番目のサンプル、4 番目のバイトには Cr の最初のサンプル、というように続く (たとえば 2 つのリトル エンディアン WORD 型変数の配列としてアドレスされた場合は、最初の WORD には LSB に Y0 および MSB に Cb が格納され、2 番目の WORD には LSB に Y1 および MSB に Cr が格納される)。これは、推奨される DirectX VA 4:2:2 ピクセル フォーマットであり、4:2:2 ビデオをサポートする DirectX VA アクセラレータの中期的必要条件となる予定である。
    2. "UYVY" は、"YUY2" と同様だが、各ワードのバイト順序が逆になる (たとえば 2 つのリトル エンディアン WORD 型変数の配列としてアドレスされた場合は、最初の WORD には LSB に Cb および MSB に Y0 が格納され、2 番目の WORD には LSB に Cr および MSB に Y1 が格納される)。
  2. 圧縮 4:2:0 ビデオのデコード :
    1. "YUY2" は、上記と同様だが、実際の 4:2:0 Cb および Cr サンプルの各ラインに対して、2 ラインの出力 Cb および Cr サンプルが作成される。各組の 2 番目のラインは、1 番目の複製か、または 1 番目および 3 番目の平均値である。使用中のあらゆるフォーマットからこのフォーマットへ "フロントエンド" 変換する能力は、中期的必要条件となる予定である。
    2. "UYVY" は、上記と同様だが、実際の 4:2:0 Cb および Cr サンプルの各ラインに対して、2 ラインの出力 Cb および Cr サンプルが作成される。各組の 2 番目のラインは、1 番目の複製か、または 1 番目および 3 番目の平均値である。
    3. "YV12" では、すべての Y サンプルが、符号なし char 型配列としてメモリの最初に存在し (メモリのアラインメントのために、より大きなストライドになっている可能性あり)、その直後にすべての Cr サンプルが (Y ラインの半分のストライド、かつ半分のライン数で) 続き、その直後にすべての Cr サンプルが同様に続く。
    4. "IYUV" は、YV12 と同様だが、Cb および Cr プレーンの順序が逆になる。
    5. "NV12" (参照先 Web ページに記載なし) では、すべての Y サンプルが、符号なし char 型の偶数ラインの配列としてメモリの最初に存在し (メモリのアラインメントのために、より大きなストライドになっている可能性あり)、その直後に、Y サンプルと同じ合計ストライドで、インターリーブされた Cb および Cr サンプルを含む符号なし char 型の配列が続く (たとえば 1 つのリトル エンディアン WORD 型としてアドレスされた場合は、Cb は LSB に、Cr は MSB に入る)。これは推奨される 4:2:0 ピクセル フォーマットであり、4:2:0 ビデオをサポートする DirectX VA アクセラレータの中期的必要条件となる予定である。
    6. "NV21" (参照先 Web ページに記載されていない新語) は、NV12 と同様だが、Cb および Cr サンプルが逆になっており、符号なし char 型のクロマ配列で各サンプルが Cr、Cb の順に並ぶ (たとえば 1 つのリトル エンディアン WORD 型としてアドレスされた場合は、Cr は LSB に、Cb は MSB に入る)。
    7. "IMC1" (参照先 Web ページに記載されていない新語) は、YV12 と同様だが、Cb および Cr プレーンのストライドが Y プレーンでのストライドと同じである。また Cb および Cr プレーンは、16 ラインの倍数であるメモリ境界内に収まるよう制限されている (標準ではすべて 16×16 マクロブロックを使用するため、標準フォーマットではこの制限は意味を持たない)。
    8. "IMC2" (参照先 Web ページに記載されていない新語) は、IMC1 と同様だが、Cb および Cr ラインがハーフストライドの境界でインターリーブされる。つまり、色光度領域の各フルストライドのラインは、Cb のラインで始まり、次のハーフストライド境界から始まる Cr のラインが続く。(この場合、色光度のアドレス空間が半分になることで、合計アドレス空間が 25% 削減されるため、IMC1 よりもアドレス空間を効果的に利用できるフォーマットと言える。) これは NV12 より比較的優れているが、NV12 の方がより一般的であるとされる。
    9. "IMC3" (参照先 Web ページに記載されていない新語) は Cb と Cr のスワップ以外は IMC1 と同じである。
    10. "IMC4" (参照先 Web ページに記載されていない新語) は Cb と Cr のスワップ以外は IMC2 と同じである。

これらのフォーマットを定義する第 1 の目的は、使用されるフォーマットを文書化し、圧縮解除されたビデオをその後の処理に使用できるようにすることである (この処理では、ビデオを DirectDraw サーフェス テクスチャとして操作する)。第 2 の目的は、フォーマットの種類が増えることを防いで、ソフトウェア処理を単純化する (多種類のフォーマットを使うことによって同じ機能が重複することを避ける) ことである。

1.3.2 アクセラレータの連続性必要条件

インターフェイスの操作中にレース コンディションが予期せぬ出来事を引き起こさないようにするための基本的な負担はハードウェア アクセラレータではなく、ホスト ソフトウェア デコーダ上にある。これに関してアクセラレータに負わされた要求は、非圧縮サーフェスの表示が停止しているか実行中かを問われたときに正しくレポートできる事と、要求された操作が完了したかどうかを問われたときに正しくレポートすることである。

1.3.3 ソフトウェア デコーダの連続性必要条件

ここでは、デコード処理において連続処理が確実に正しく実行されるよう、特定の必要条件が課せられている。これらの条件は、デコードおよび表示の際の、非圧縮サーフェスの取り扱いに関するものである。ここで挙げる例は、ブロック解除フィルタを使わない、一般的な 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 つ以上の追加非圧縮サーフェスを使うことはスムースで、信頼性高く、ティア フリーの操作を得る良い方法であることが多い。

1.4 用語

1.4.1 略語と記号

' ' 2 進値 (左のビットが MSB)

" " 10 進値

0x 16 進値

LSB 最下位ビット (Least Significant Bit)

MSB 最上位ビット (Most Significant Bit)

// 0 と逆方向に丸める区切り

/ 0 方向に切り捨てる区切り

1.4.2 ビット番号付け規則

この仕様書では、ビット番号を Microsoft で普及している規則に従って表現する。この規則では、LSB がビット 0 、MSB がビット N-1 となる (ビット数が N の場合)。

注 :  ビデオ コーディング規格には、最も若い番号のビットが MSB とされるものがあり、その場合はこの番号付け規則とは異なる。

ただし、この文書で構造体内に 8 ビット未満のフィールドのシーケンスが現れる場合、その順序はビデオ コーディング規格で使用されている規則に従う。つまり、最初にリストされる要素が MSB に最も近い位置にあるものと見なされる。たとえば、単一ビットの配列要素 5 つを構造記述内に並べる場合には、構造記述内にインデックスが減少する順序で各要素がリストされる。

このアプローチに見られる分裂的現象は、このインターフェイス仕様の各ビットがどこに位置するのかを決める最終的な権限が、この文書でなく、このインターフェイスに関連付けられる ".h" ファイルにあるものと見なしたほうがよいことを意味する。

1.4.3 定義

参照ブロック - 参照フレーム バッファから抽出されたブロック領域。

予測ブロック - 参照ブロックからフィルタされたブロック。

予測プレーン - マクロブロック予測を結合する前に形成されるサンプルの配列。各プレーンは、通常 1 つのフレーム ロケーションから集められた、一連の予測ブロックを表す。プレーンが結合されて、単一のマクロブロック予測を形成する。

予測マクロブロック - すべての色チャンネルを含むマクロブロック予測。

成分 - 3 つの色チャンネル {Y, Cb, Cr } の 1 つ。

ホスト CPU - ビデオ デコードの機能全体 (上位処理) を制御する、プログラム可能なプロセッサ。

アクセラレータ - IDCT、MCP、表示フォーマット変換といった、単純だが頻繁に実行される処理を実行する機能単位。

動きベクトル計算 - 動きベクトルを予測ブロック アドレスに変換する処理。

予測アドレス - 実装固有の設計の中で、予測ブロックのある位置。

合成予測ブロック - 属性が輝度と色光度の両方に適用される予測ブロック。

成分予測ブロック - 属性が輝度か色光度のどちらかに適用される予測ブロック。

イントラ (フレーム内) - デコード済みのピクチャを参照した予測を行わないピクチャ コンテンツの表現。

インター (フレーム間) - まずデコード済みのピクチャを使ってピクチャの 1 領域の予測をエンコードし、その後必要に応じて予測からの偏差を表す信号を追加するピクチャ コンテンツの表現。

残差デコード - 必要に応じて、動き補償予測後に残っている信号を表現するため、エンコードされた誤差信号を表す波形をデコードすること。この結果、非予測波形の "イントラ" 表現だけが使用される場合と、予測後の "インター" 差異が使用される場合がある。

ReservedBits - この仕様で名前または名前の一部に ReservedBits が含まれているフィールドは、現在この仕様では使用されていないため、値は 0 でなければならない。

〜ほうがよい - 推奨される (必須ではない) 動作の記述に使用される表現。

〜ならない - 必須 (または禁止された) 動作の記述に使用される表現。

1.5 ステージ

次の図に示すステージは、MCP および IDCT アクセラレータで構成されている。

図 2 -- デコーダのステージ

1.6 フレーム バッファの構成

すべてのピクチャ バッファは、MPEG-2 仕様どおり、フレームで構成されたバッファを保持していると見なされる。アドレス単位は、特に指定がない限りフレーム座標で設定しなければならない。フレーム座標で記述された予測ブロックを、実装固有の変換レイヤを使って、損失なしにフィールド座標に変換することができる。たとえば、単一フレームの動き予測は、上下 2 つの個別のマクロブロック部分予測に分割できる。

3 つのビデオ成分チャンネル {Y, Cb, Cr} は、この仕様で定義されたインターフェイスによってアクセスされる。2 つの色光度成分の動きベクトルは、輝度成分に送られたベクトルから派生する。これらの動きベクトルは、アクセラレータによって別の座標システムに変換される。

現在の標準規格の処理

図 3 -- ホストおよびアクセラレータのシステム

以下に、H.261、MPEG-1、MPEG-2 (MPEG-2)、H.263、および MPEG-4 の基本処理を年代順にリストし、この仕様を使ってどのように実現できるかを簡単に説明する。

2.1 ITU-T H.261

正式には "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 つのピクチャをアクセラレータからホストに読み戻し、そこでインターリーブして、高解像度のグラフィック ピクチャとして表示することができる。

2.2 MPEG-1

正式には ISO/IEC 11172-2 と呼ばれる MPEG-1 ビデオは、H.261 からほどなくして、H.261 の設計の多くを取り入れて設計された。ループ フィルタはなく、その代わりに、フレーム間のサブピクセルの動きを解決するためのシンプル ハーフサンプル フィルタを持つ。追加された双方向予測モードおよび逆方向予測モードでは、参照フレームが 1 つ余分にバッファされる必要がある。双方向予測は、順方向に予測された予測ブロックと逆方向に予測された予測ブロックの平均を取る。順方向と逆方向の予測ブロックを平均化する計算は、ハーフサンプルされた "補間" 予測ブロックの作成に似ている。その他の基本構造は H.261 と同様である。

2.3 MPEG-2 (別名 MPEG-2)

正式には "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 フレーム構造化ピクチャ :

  1. フレーム MC : MPEG-1 予測と非常によく似た 16×16 の予測ブロック形状を持つ。これは、MPEG-2 では唯一、プログレッシブ フォーマットの動きである (MPEG-2 の motion_type パラメータで指定される)。MPEG-2 の macroblock_type パラメータの設定によって、1 つの予測プレーン (順方向のみ、または逆方向のみ) を持つか、または 2 つの予測プレーン (双方向) を持つ。参照ブロックは、フレーム バッファからの連続フレーム ラインで形成される。フレーム バッファは、デコード処理のセマンティクスによって選択される。ハーフサンプル補間 (MPEG-2 セクション 7.6.4) および双方向補間 (MPEG-2 セクション 7.6.7.1) の平均化処理は、MPEG-1 とまったく同じである。
  2. フィールド (16×8) MC : 順方向および逆方向の各プレーンは、上 16×8 予測ブロック、および下 16×8 予測ブロックで構成される。各予測ブロックに対応する参照ブロックは、参照フレームの上フィールドまたは下フィールドから抽出できる (MPEG-2 の motion_vertical_field_select[r][s] パラメータによって決定される)。1 つの予測プレーンに対して 2 つの予測ブロックが 1 セットある (順方向のみまたは逆方向のみ。この場合は 1 つのマクロブロックに合計 2 つの予測ブロックが存在する) 場合と、2 つの予測プレーンに対して複数のセットがある (双方向。この場合は、1 つのマクロブロックに合計 4 つの予測ブロックが存在する) 場合がある。
  3. デュアル プライム : 前記のフィールド MC と同様、各プレーン (パリティ) は、上下の 16×8 形状で構成される。同パリティ プレーンと逆パリティ プレーンは、1、2、4、5 の双方向補間と同様の平均化処理によって結合される。ほかの動きタイプ (1、2、4、5) と異なり、デュアル プライムのマクロブロックは、常に 2 セットの予測ブロック (同パリティおよび逆パリティ) で構成され、1 つのマクロブロックに合計 4 つの予測ブロックが存在する。

MPEG-2 フィールド構造化ピクチャ :

  1. フィールド (16×16) MC : 各予測が 16×16 形状を持つ点でフレーム MC に似ているが、参照ブロック データは、連続的な上または下のラインのみから形成される。プログレッシブ フォーマットの動きのように上下のラインが交互に混在することはない。フィールド構造化ピクチャのすべての動きタイプと同様、再構築されたマクロブロックも、連続的な上または下のラインのみの状態で、現在のフレーム バッファに格納される。上フィールドまたは下フィールドの宛先は、MPEG-2 の picture_structure 変数によって決定される。
  2. 16×8 MC : このタイプの動きの基本的な予測ブロック形状は、ほかの 16×8 形状 (2、3) と同一であるが、同じ方法でマクロブロックにパーティション分割されることはない。2 つのパーティションは、マクロブロック内の上下のフィールドでなく、マクロブロック予測プレーンの上半分と下半分に対応する (図 を参照)。下半分の 16×8 のアンカー ポイントは 16×8 下部分の左上であって、ほかのすべての動きタイプのようにマクロブロック全体の左上ではないという点には、特に注意したほうがよい。
  3. デュアル プライム : 最下層においては、デュアル プライムと、双方向予測のフィールド構造化フィールド動き補償の間に実質的な区別はない。違いは、参照ブロックの形成元となるフレーム バッファの選択に表れる。フィールド構造化ピクチャのデュアル プライム動きタイプは常に、2 つの 16×16 予測ブロック (同パリティ予測および逆パリティ予測) で構成される。

2.4 ITU-T H.263

正式には "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 のサポート仕様が考慮されている。

2.5 MPEG-4

MPEG-4 は、プログレッシブ スキャン コーディングについては H.263 の規格、インターレースおよび 4:2:0 以外のカラー サンプリング フォーマットのサポートについては MPEG-2 の規格を大幅に取り入れている。この仕様にある、H.263 および MPEG-2 をサポートする機能は、MPEG-4 をサポートするために使用できる。1 ピクセルに対して 8 ビット以上をサポートするために、BPP パラメータが用意されている。シェープ コーディング、オブジェクト回転、フェース モデリング、メッシュ オブジェクト、スプライトといった MPEG-4 に固有の機能は、現在のインターフェイスではサポートされない。ただし、将来開発されるバリエーションで追加される可能性がある。

2.6 予測の原理

ブロック動き補償予測 (MCP) は、MPEG および H.26x ファミリの CODEC に、JPEG のような純粋な静止フレーム コーディング方法にはない利点を提供する基本ツールである。一般的な予測の例は、CODEC のさまざまなステージにあるが、MCP は最も多くの処理を必要とする。動きベクトル、DCT 係数、その他 MCP 処理の直接の一部でない要素も、転送後の状態をよりコンパクトにするために予測を利用する。これらの予測の例は、この仕様では解説しない。またこれらは、ホスト CPU プロセッサまたはビットストリーム パーサー/可変長デコード装置で実行されるものと見なす。

一般的な予測コーディング スキームでは、先に転送およびデコードされた要素が、現在の要素の予測として使用され、予測値と現在の要素の実際値との差異が予測誤差として送られる。転送された差異情報によって、正しい値、または必要とされる値に十分近い値 (MCP の場合) に、予測が更新される。先にデコードされたフレームは、将来のフレームがどのように見えたほうがよいかを予測 ("推測") するために使用される。その後差異データ (予測誤差) が推測を修正し、予測と予測誤差を組み合わせた (再構築された) イメージを、圧縮前のオリジナルの将来のフレームにできるだけ近付けようとする。

再構築が終わった現在の要素は、格納され、将来の要素の予測に使用される。この繰り返しのループは、予測される要素固有の各種のリセットによって壊される場合がある。リセットは、デコード処理のセマンティクスによって記述される。たとえば、動きベクトルや DC 係数予測はスライスでリセットされ、一時フレーム予測チェーン全体は、イントラ リフレッシュ フレームによってリセットされる。一時基本予測ループはこの記述に適合するが、予測として使用されるフレーム全体から取り出された修正データと共に動作する。予測として使用される参照フレームからのデータは、動きや、その他時間と共に生ずる変更内容に合わせて修正される。

図 5 -- 一般的な MCP 信号の流れ

2.6.1 予測のステージ

この仕様書の目的上、MCP によるマクロブロック予測の構造は、それぞれ独立した一連のフェーズとして説明しなければならない。この点を認識していると、この仕様書での MCP 処理に関する記述のフォーマットが理解しやすくなる。

図 6 -- MoComp3 予測ブロックの信号の流れ

ステージ 1. 参照フレームの形成

注 :  必要に応じて入力ピクチャの再サンプリングが含まれる場合がある。

図 7 -- MCP での予測データの進化

ステージ 2. 参照ブロック

参照ブロックは、予測ブロックと同じであるとは限らず、予測フィルタリング ステージで必要となる追加サンプルで構成される場合が多い。参照ブロックは、実装固有のピクチャ バッファ保持方法を反映した性質を持つことが多いため、この仕様書では定義していない。メモリ単位内でハーフサンプル フィルタリングが実行されない限り、16×16 ハーフサンプル フィルタされたマクロブロックの参照ブロックは、17x17 の形状を持つ。参照ブロックのサイズは、予測ブロックの大きさの関数でもあり、予測ブロックのフィルタ属性でもある。この仕様書では、参照ブロックは、動き補償予測 (MCP) で使用するために、参照フレーム バッファから抽出されたデータのブロックを参照しなければならない。

ステージ 3. 予測ブロック

フィルタされた参照ブロックの結果。

ステージ 4. 結合されたマクロブロック予測

1 つまたは複数の予測ブロックの平均化処理の結果。

2.6.2 マクロブロック部分

マクロブロックは、さまざまな性質を持つ領域を区分するために、通常のセグメントに分割される。

図 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 輝度動きベクトルの平均から派生する。この文書の多くの部分では、予測ブロック、プレーン、およびマクロブロックの、輝度の範囲のみについて述べる。特に明記しない限り、色光度については類推すること。

2.6.3 予測プレーン

図 10 -- MPEG-2 マクロブロック予測プレーン

上の図は、最終的なマクロブロック予測を形成する前に存在する、概念的なマクロブロック予測プレーンを示している。MPEG-2 には、順方向および逆方向 (双方向予測)、または同パリティおよび逆パリティ (デュアル プライム) の 2 つのプレーンがある。MPEG-1 および MPEG-2 では、単純な平均化処理によってプレーンが結合される。H.263 の重複ブロック動き補償予測 (Overlapped Block Motion Compensation Prediction) といった、より洗練された予測スキームの場合は、3 つのプレーンがある。将来は、最大 8 またはそれ以上の予測プレーンを、より洗練されたフィルタを使って結合するコーディング方法が採用される可能性がある。

DirectX VA データ構造とプログラム構成

3.1 暗号化サポート

アプリケーションのセキュリティ要求によっては、ビデオのデコードに使用されるデータの一部の暗号化が必要になる場合がある。そのようなアプリケーションをサポートするため、この仕様では、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 が含まれる。

3.2 グローバル制限モードの情報

デコーダがこの API を使って動作するためには、デコーダとビデオ アクセラレータの間で、処理における次の 2 つの側面について共通の認識が成り立っている必要がある :

  1. デコードされるビデオ データ フォーマットのタイプ。これは、DXVA_ConnectMode データ構造体を使用してここに成文化される。
  2. API の処理がどのように構成されるか。つまり、どの中間データ フォーマットが使用され、処理のどの側面がホスト、どの側面がアクセラレータに属するか。これは、使用される DXVA 機能それぞれの接続構成のネゴシエーションによって確立される。

DirectX VA のグローバル接続パラメータは、次の接続制限モードである。

DXVA_ConnectMode {
            guidMode,        // 128b
            wRestrictedMode // 16b
            }

guidMode : 使用される制限モード プロファイルに関連付けられた GUID。

wRestrictedMode : 接続制限モードを示す数値による識別子 (セクション 4 を参照)。

3.3 構成をプローブおよびロックする

構成を必要とする個々の DirectX VA 機能 (bDXVA_Func の特定値) の構成を確立する処理は、次のように実行される。

  1. 必要に応じて、構成がアクセラレータに受け付けられるかどうかを判断するためにプローブする。
  2. 構成がサポートされていれば、その構成にロックする。

特定構成サポートのプローブは、構成をプローブする特定 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 : 指定する照会または応答のタイプ。以下のように定義される。

QueryOrReplyFlag の下位 4 ビットは、以下のように解釈できる。

bDXVA_Func : 同時に送信された構成が適用される bDXVA_Func 機能。

3.4 バッファ記述リスト

DirectX VA は主として、データのバッファをホストからアクセラレータに渡すことによって動作する。DXVA 機能のパラメータ (bDXVA_Func) により、渡される可能性があるバッファのタイプ、および実行される DXVA タスクが決定する。次のような各種バッファ タイプがここに定義されている。

  1. ピクチャ デコード パラメータ バッファ
  2. マクロブロック制御コマンド バッファ (残差ブロック データ バッファと深く関連し、それと 1:1 で対応する)
  3. 残差ブロック データ バッファ
  4. ブロック解除フィルタ制御コマンド バッファ (フィルタ効力の制限あり、または制限なし)
  5. 逆量子化行列バッファ (オフホストの VLD 処理でのみ使用)
  6. スライス制御バッファ (ビットストリーム データ バッファと深く関連している)
  7. ビットストリーム データ バッファ
  8. AYUV アルファ ブレンディング サンプル バッファ
  9. IA44/AI44 アルファ ブレンディング サーフェス バッファ
  10. DPXD アルファ ブレンディング サーフェス バッファ
  11. ハイライト データ バッファ
  12. DCCMD データ バッファ
  13. アルファ ブレンド コンビネーション バッファ
  14. ピクチャ再サンプリング制御バッファ
  15. 最終結果のピクチャのマクロブロックをホストに読み戻すコマンドを格納した読み戻しバッファ

バッファの 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 に指定されているストライドを守ることに必ず注意しなければならない。

3.5 圧縮ピクチャのデコード (bDXVA_Func=1)

DirectX VA 処理のために定義された最初の関数タイプは、圧縮ピクチャの一部または全部のデコードである。

3.5.1 接続構成

圧縮ピクチャをデコードするための 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" をサポートすることも容認されるが、低レベルのアクセラレータ機能であり、あまり推奨されない。

3.5.2 最小限の相互動作性構成セット

設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットに属する少なくとも 1 つの接続構成メンバと共に動作できる必要がある。最小限の相互動作性セットは次のように定義される。

  1. この最も基本的なセットのすべてのメンバは次の共通点を持つ。
    1. guidConfigBitstreamEncryption = DXVA_NoEncrypt
    2. guidConfigMBcontrolEncryption = DXVA_NoEncrypt
    3. guidConfigResidDiffEncryption = DXVA_NoEncrypt
    4. bConfigBitstreamRaw = 0
    5. bConfigHostInverseScan = 0
    6. bConfigSpecificIDCT = 0
  2. このセットの最初の 2 つのメンバ (ここに属するアクセラレータは、bConfigSpatialHost8or9Clipping = 0 のバリエーションをサポートすることを推奨される) は、次によって定義される。
    1. bConfigMBcontrolRasterOrder = 1
    2. bConfigResidDiffHost = 1
    3. bConfigSpatialResid8 = 0
    4. bConfigResid8Subtraction = 0
    5. bConfigSpatialHost8or9Clipping = 0 or 1
    6. bConfigSpatialResidInterleaved = 0
    7. bConfigIntraResidUnsigned = 0
    8. bConfigResidDiffAccelerator = 0
  3. セットの 3 番目のメンバ (アクセラレータ実装を特に推奨されない) は、次のとおり。
    1. bConfigMBcontrolRasterOrder = 1
    2. bConfigResidDiffHost = 1
    3. bConfigSpatialResid8 = 1
    4. bConfigResid8Subtraction = 0
    5. bConfigSpatialHost8or9Clipping = 0
    6. bConfigSpatialResidInterleaved = 1
    7. bConfigIntraResidUnsigned = 0
    8. bConfigResidDiffAccelerator = 0
  4. セットの 4 番目のメンバ (アクセラレータ実装を特に推奨されない) は、次のとおり。
    1. bConfigMBcontrolRasterOrder = 1
    2. bConfigResidDiffHost = 1
    3. bConfigSpatialResid8 = 0
    4. bConfigResid8Subtraction = 0
    5. bConfigSpatialHost8or9Clipping = 1
    6. bConfigSpatialResidInterleaved = 0
    7. bConfigIntraResidUnsigned = 1
    8. bConfigResidDiffAccelerator = 0
  5. このセットに含まれる残り 2 つのメンバ (ここに属するアクセラレータは、bConfigResid8Subtraction = 1 のバリエーションをサポートすることを推奨される) は、次によって定義される。
    1. bConfigMBcontrolRasterOrder = 1
    2. bConfigResidDiffHost = 1
    3. bConfigSpatialResid8 = 1
    4. bConfigResid8Subtraction = 0 or 1
    5. bConfigSpatialHost8or9Clipping = 0
    6. bConfigSpatialResidInterleaved = 0
    7. bConfigIntraResidUnsigned = 0
    8. bConfigResidDiffAccelerator = 0
  6. このセットに含まれる残り 1 つのメンバは4章に説明され、DXVA_ConnectMode に示されている MPEG2_C と MPEG2_D 限定モード プロファイル用にのみ定義される。他のプロファイルは最小インターオペラビリティ セットのこの構成には含まれない。この追加メンバは次によって定義される。
    1. bConfigMBcontrolRasterOrder = 1
    2. bConfigResidDiffHost = 0
    3. bConfigResidDiffAccelerator = 1
    4. bConfigHostInverseScan = 0
    5. bConfig4GroupedCoefs = 1

3.5.3 補足的な推奨構成セット

ソフトウェア デコーダでは、いくつかの補足的構成をサポートすることを推奨する。これは、量産されるハードウェアにこれらの構成が存在し、これらの構成は最小限の構成セットより圧倒的に高いパフォーマンスを提供しうると考えられるからである。推奨構成セットは以下のとおり。

  1. このセットのメンバすべてに共通の性質は以下のとおり。
    1. guidConfigBitstreamEncryption = DXVA_NoEncrypt
    2. guidConfigMBcontrolEncryption = DXVA_NoEncrypt
    3. guidConfigResidDiffEncryption = DXVA_NoEncrypt
    4. bConfigMBcontrolRasterOrder = 0
    5. bConfigResidDiffHost = 0
    6. bConfigSpatialResid8 = 0
    7. bConfigResid8Subtraction = 0
    8. bConfigSpatialHost8or9Clipping = 0
    9. bConfigSpatialResidInterleaved = 0
    10. bConfigSpecificIDCT = 0
  2. このセットの最初のメンバは、オフホストのビットストリーム処理のアクセラレーションを適切にサポートするため、次のように定義される。
    1. bConfigBitstreamRaw = 1
    2. bConfigResidDiffAccelerator = 0
    3. bConfigHostInverseScan = 0
    4. bConfig4GroupedCoefs = 0
  3. このセットの 2 番目のメンバは、オフホストの IDCT アクセラレーションを適切にサポートするため、次のように定義される。
    1. bConfigBitstreamRaw = 0
    2. bConfigResidDiffAccelerator = 1
    3. bConfigHostInverseScan = 1
    4. bConfig4GroupedCoefs = 0
  4. このセットの 3 番目のメンバ (2 番目のメンバと比較するとアクセラレータにはあまり推奨されない) は、一部の実装に見られると予想されるオフホスト IDCT をサポートするため、次のように定義される。
    1. bConfigBitstreamRaw = 0
    2. bConfigResidDiffAccelerator = 1
    3. bConfigHostInverseScan = 0
    4. bConfig4GroupedCoefs = 1

推奨構成セットの最初のメンバをサポートするアクセラレータは、そのアクセラレーション能力の使い方に柔軟性を持たせるため、2 番目のメンバもサポートすることを強く推奨する。

3.5.4 圧縮ピクチャのパラメータ

ピクチャ 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 ピクチャ内で最も一般的に使用される)。

3.5.5 ピクチャのマクロブロックのバッファ構造

デコードされたピクチャにビットストリーム データ バッファが含まれていない場合は、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 残余コーディング バッファと統合して処理する (最終出力値を宛先ピクチャ バッファに書き込む前に、ブロック解除を実行する)。ブロック解除されたピクチャの宛先ピクチャ バッファは、ブロック解除の前に再構築されたピクチャのバッファとは異なる場合がある。これは、ポストプロセッシングとして、次のピクチャの予測に使われるサンプル値に影響を与えない "ループ外" ブロック解除をサポートするためである。

3.5.5.1 マクロブロック制御コマンド

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 : 処理されるマクロブロックのタイプを指定する。指定方法は次のとおり。

MBskipsFollowing : 現在のマクロブロックに続いて生成される、"スキップされるマクロブロック" の数を指定する。スキップされる各マクロブロックは、wMBaddress の値を増加させ、その後同じマクロブロック制御コマンドを反復するのと同等の計算方法で生成されなければならない。

MBskipsFollowing の値が "0" でないマクロブロック制御コマンドはすべて、スキップされる各マクロブロックごとに動き補償予測がどのように実行されるかに関する明示的な指定を含み、また (MBskipsFollowing の値を除いて)、スキップされる一連のマクロブロックの最初のマクロブロックの生成に関する明示的な "非スキップ" 指定と同等である。このため、MBskipsFollowing が "0" でない場合は常に、次のパラメータがすべて "0" と等しくなければならない。

さらに、後に続くスキップされるマクロブロックの生成は、ピクチャ内のマクロブロックの新しい行への "折り返し" を含まないよう、デコーダによって制限されなければならない。つまり、マクロブロックの各行の最初の (しかし最後である必要はない) マクロブロックを生成するために、個別のマクロブロック制御コマンドが送信される必要がある。

注 :  

  1. この状況における、スキップされるマクロブロックの生成は、MPEG-2 のセクション 7.6.6 のものとはいくらか異なる。この仕様では、スキップされるマクロブロックが生成される方法は、先行する非スキップ マクロブロックおよびピクチャのタイプから導かれるのでなく、個別のマクロブロック制御コマンド内で指定される (たとえば、MPEG-2 では、スキップされるマクロブロックの生成方法は、ピクチャが P ピクチャであるか B ピクチャであるかに依存する)。この点を明確にするため、次のような例を用意した。MPEG-2 ビットストリームで、マクロブロック 0 が残差でコードされ、マクロブロック 1 がスキップされ、マクロブロック 2 が残差でコードされ、マクロブロック 3、4、5 がスキップされ、マクロブロック 6 が残差でコードされているとする。これら 7 つのマクロブロックは、少なくとも 5 つの DirectX VA マクロブロック制御コマンドの生成を必要とする。最小限の 5 つの制御コマンドは、次のように特徴付けられる。
    1. 最初のコマンドは wMBaddress = "0" および MBskipsFollowing = "0" となる
    2. 2 番目のコマンドは wMBaddress = "1" および MBskipsFollowing = "0" となる
    3. 3 番目のコマンドは wMBaddress = "2" および MBskipsFollowing = "0" となる
    4. 4 番目のコマンドは wMBaddress = "3" および MBskipsFollowing = "2" となる
    5. 5 番目のコマンドは wMBaddress = "6" および MBskipsFollowing = "0" となる
  2. 上記に指定したように、次の条件が必要となる。
    1. スキップされるマクロブロックが残差を保持していない
    2. スキップされるマクロブロックが、wMBaddress を増加させながらマクロブロック制御コマンド処理を反復することによって生成できる
    3. マクロブロックのスキップが、マクロブロックの新しい行に折り返さないよう制限されている
  3. 注 2 に挙げた 3 つの条件により、同じマクロブロック制御処理の MBskipsFollowing+1 反復ではなく、輝度成分の MacroblockWidth·(MBskipsFollowing+1) と同じ幅を持つ矩形 (および同様に指定された色光度成分の矩形) への指定された動きベクトルの適用として、アクセラレータが実際に動き補償を実現できる (Motion4MV が "0" の場合)。
  4. 高度予測モード (補遺 F) が有効となっている H.263 でスキップと示されたマクロブロックを生成する場合、それらのマクロブロック内で OBMC 効果を指定するには、この仕様を使って、いくつかの "スキップされた" マクロブロックを非スキップ マクロブロックとしてコーディングする必要がある。

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

-

-

-

-


注 :  

  1. この表は非常に重要である。よく検討して完全に理解する必要がある。経験上、表内の利用されるすべてのマクロブロック タイプ (特にフィールド構造化ピクチャまたはデュアル プライム動き) に適切な対応をしていないあらゆる実装には、バグが含まれていると思われる。
  2. 上の表に、生の動きベクトル値でなく値 PMV が使用されている箇所がある。これは、フレーム座標内にある PMV を、(ハーフ垂直解像度の) フィールド座標にある可能性がある動きベクトルと区別するためである。上のような PMV はすべて、現在の動きベクトルで更新した後の PMV 値を意味する。
  3. vector'[2][0] と vecotor'[3][0] の定義は MPEG-2 セクション 7.6.3.6 にある。シフト操作は垂直コンポーネントがフレーム座標に修正されることを示す。
  4. 上の "動きなし" (0,0,0) の両ケースでは、マクロブロック パラメータが、動きベクトルの値が 0 の順方向予測マクロブロック (0,1,0) をエミュレートする (MPEG-2 セクション 7.6.3.5 を参照)。

このほかの可能な組み合わせは次のとおり。

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、ピクチャの再構築、および再構築クリッピングの処理は、次のように定義される。

  1. エントロピーコード化された量子化インデックスから、一連の IDCT 係数値 を作成するために、必要に応じて逆量子化 (逆量子化重み付け行列の適用を含む) を実行する (ホストによって実行)。
  2. 制限された範囲内の値 を取得するために、変換係数ブロックの、再構築された各係数値 を飽和させる (ホストによって実行)。
  3. ミスマッチ制御 (MPEG-2 のみに必要で、ホストによって実行として説明する) は、マクロブロック内のすべての係数の飽和値を加算することによって実行される (LSB すべての XOR と同等)。合計が偶数になった場合は、 が奇数なら 1 を引き、 が偶数なら 1 を足すことにより (LSB の切り替えと同等)、最後の係数の飽和値 を修正しなければならない。(合計が奇数になった場合は、 の飽和値がそのまま使用される。) 飽和およびミスマッチ制御後の係数値は、ここで、 として表される。
  4. 注: MPEG-1 はミスマッチ制御に別のフォームを持つ、これはそうしないと逆量子化後遇数となる各係数に 1 を足すあるいは引くことで値を変えることによって構成される。H.263 は個々で記述されている意味でのミスマッチ制御を要求しない。いつでも、適用可能であれば、ミスマッチ制御はホストの責任である。
  5. 必要に応じてイントラ DC オフセットを追加する (ホストによって実行)。これは、空間参照予測値 2(BPP-1) への差異の追加にすべてのイントラ ブロックを対応させるためである。このようなオフセットは、HostResidDiff が "1" かつ bConfigIntraResidUnsigned が "1" のとき、すべての参照ビデオ コーディング標準規格 (H.261&3 および MPEG-1&2&4) で必要であり、どの場合でも という値を持つ (値は、BPP>8 が許可される MPEG-4 以外ではすべて 1024 となる)。
  6. 単一の分割可能な変換を実行する (ホストまたはアクセラレータによって実行)。

    各記号の意味 :

    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 ビデオ コーディング標準規格で求められるもの (ほぼ同様) に準拠しなければならない。

  7. ピクチャの再構築を行うため、空間領域残余情報を、非イントラ ブロックの場合は動き補償予測値に、イントラ ブロックの場合は定数参照値に追加する (この定数は HostResidDiff が "1" かつ bConfigIntraResidUnsigned が "1" のとき以外は 2(BPP-1) である、前述の場合は "0")。
  8. ピクチャ再構築を、最終結果のピクチャ サンプル値として保管するために、[0, (2BPP)-1] の範囲にクリッピングする (アクセラレータ上で実行)。

3.5.5.2.1 オフホストの IDCT

オフホスト 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 つの方法がある。

  1. RLE (Run-length) 順序 : bConfigHostInverseScan が "0" の場合、MBscanMethod は、ジグザグ、交互垂直、または交互水平逆スキャンを示す。この場合、TCoefIDX には、指定されたスキャン順序で現在の係数に先行し、ブロックに最後に送られた係数に続く (先行する係数がなければブロック先頭からの)、値 0 の係数の数が含まれる。
  2. 任意の順序 : bConfigHostInverseScan が "1" の場合、MBscanMethod は任意の順序を示す。この場合、TCoefIDX には、ブロック内の係数のラスタ インデックスだけが含まれる (つまり、TCoefIDX = u + v·WT)。

TCoefIDX は、WHT 以上になってはならない。

TCoefValue : ブロック内の係数の値。TCoefValue は、係数値を逆 DCT 処理のためにアクセラレータに渡す前に、前述のセクション 3.4.2 で示したように、ホスト側で適切な範囲にクリップしなければならない。必要に応じて、MPEG-2 ミスマッチ制御も、アクセラレータでなくホストによって実行される (このために、0 でない余分な "幽霊" 係数の作成が必要になる場合がある)。

3.5.5.2.1.1 単一係数のデータ フォーマット

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] でなければならない。

3.5.5.2.2 ホストベースの IDCT

IDCT はホスト上で実行することもできる。この場合、結果は API を使って渡される。結果送信のスキームとしては、16 ビットと 8-8 オーバーフローの 2 つの方法がサポートされる。どちらが使用されるかは、bConfigSpatialResid8 に示される。

3.5.5.2.2.1 16 ビット方式

16 ビット方式を使って 16 ビットデータを送信する場合は、データのブロックは連続的に送信される。空間領域データの各ブロックは、DXVA_Sample16WHT 値で構成される。

A DXVA_Sample16 は 16 ビットの符号付き整数である。BPP が "8" より大きい場合は、16 ビット方式だけが使用できる。bPicIntra が "1" で BPP が "8" の場合は、16 ビット方式は使用できない。IntraMacroblock が "0" なら、16 ビット サンプルはモーション圧縮された予測値に関する符号付きの数として送られる。IntraMacroblock が "1" なら、16 ビット サンプルは以下のように送られる :

データのブロックは、MSB から LSB に 1 バリュー ビットのスキャンにより指定された wPatternCode 順に、シーケンシャルに送られる。

注 :  

  1. bConfigSpatialHost8or9Clipping が "1" でない限り、ホスト上でこれらの値のクリッピングが行われたと見なすことはできない。空間領域差異データを適切に表現するには BPP+1 ビット範囲で足りるが、クリップされていない場合、一部の IDCT ではこの範囲を超える数値が出力される可能性がある。アクセラレータは、少なくとも 15 ビット範囲の値で正しく動作しなければならない。
  2. ビデオ コーディング標準規格では通常、差異値を予測値に追加する前に、差異値のクリッピングが指定される (1 サンプル 8 ビットのビデオで、 9 ビットのクリッピングなど) が、これはデコードされた出力ピクチャに何の影響も与えないため、このクリッピングは実際には必要ない。このため、bConfigSpatialHost8or9Clipping が "1" に設定されることによってアクセラレータ ハードウェアがクリッピングを必要としていることが明らかな場合以外は、クリッピングがここで発生すると仮定しない。

3.5.5.2.2.2 8-8 オーバーフロー方式

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 ビットサンプルは次のように設定される :

IntraMacroblock が "1" なら、オーバーフロー ブロックは送られるべきではない。

データのブロックは、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) 通常はビデオ品質を有意に悪化させる結果にならないと考えられる、という理由による。

3.5.5.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" でなければならない。

3.5.5.4 読み戻しバッファ

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 ビット値で返されなければならない。

データは、アクセラレータからホストへ、次のフォーマットで返される。

  1. 最初に読み戻しコマンド バッファ自体のコピー、その後次の 32 バイト整列境界へのパディング、そして
  2. 読み戻しコマンド バッファに送信された順序で返されたマクロブロック データ値。フォーマットは各マクロブロックの各ブロックに対して、ブロックごとに WHT サンプル。マクロブロック内の残差ブロックは、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 ブロックの順)。

3.5.6 オフホストの VLD ビットストリーム デコード処理

生のビットストリーム データの可変長デコードがアクセラレータ上で実行される場合、ピクチャのデコードのためにホストによって送信されるデータは、次の 3 タイプのバッファに分割される。

  1. 逆量子化行列バッファ。ビットストリーム データの逆量子化を行う方法についての情報を提供する。
  2. スライス制御バッファ。それぞれがビットストリーム データ バッファ内のスタート コードおよびデータの位置に関する情報を提供する。
  3. ビットストリーム データ バッファ。特定のビデオ コーディング仕様に基づいてエンコードされた生のデータ ストリームを含む。

3.5.6.1 逆量子化行列バッファ

逆量子化行列バッファは、オフホストでのビットストリーム デコード用に逆量子化行列を初期化するために送信される。逆量子化行列バッファは、新しい逆量子化行列バッファが供給されるまで、ビットストリーム内の、現在およびそれに続くすべてのビデオのデコード方法に関する情報を提供する。(この点で、逆量子化行列は固定的である。) ホストからアクセラレータに一度に複数の逆量子化行列バッファを送信してはならない。

DXVA_QmatrixData {
  for(i=0; i<4; i++)
    bNewQmatrix[i]      // 8b
  for(i=0; i<4; i++)
    if(bNewQmatrix[i] == 1)
      Qmatrix[i]        // WTHT・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" の場合は、次のようになる。

  1. bNewQmatrix[i-2] が "0" の場合、アクセラレータは引き続き i の直前の逆量子化行列を使用しなければならない。
  2. bNewQmatrix[i-2] が "1" の場合、i の逆量子化行列を、i-2 の新しい逆量子化行列と同じに設定しなければならない。

該当するビデオ コーディング仕様で逆量子化行列が必要とされない場合 (H.261 や H.263 など) は、逆量子化行列バッファを送信してはならない。該当するビデオ コーディング仕様で逆量子化行列が必要とされる場合は、ホストによって、ビデオ デコード処理の開始時に、いずれかのビットストリーム データ バッファの転送の前、または転送と協調して、これらの逆量子化行列のために値が提供される必要がある。

注 :  ホストから先行する値が送られていない場合は、量子化行列のデフォルト値は設定されない。該当するビデオ コーディング仕様でデフォルトで使用できる値が含まれているとしても、量子化行列の値は、明示的に送信される必要がある。

Qmatrix[i] : 逆量子化行列。bNewQmatrix[i] が "1" の場合のみ存在する。行列は、WTHT 符号なしワード (各ワードの下位の 8 ビットだけが有力なビデオ コーディング標準規格で使用される) で構成される。逆量子化行列内でのデータ値の順序は、該当するビデオ コーディング仕様の定義に従わなければならない。

注 :  MPEG-2ビットストリームの場合、Qmatrix[i] 内のデータ値は、MPEG-2 の副節 7.3.1 および 図 7-2 で指定されているとおり、ジグザグ逆スキャン順序である。

3.5.6.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 以外の値になることは、通常、ホスト ソフトウェア デコーダ側で回避したほうがよい。

3.5.6.3 ビットストリーム データ バッファの内容

ビットストリーム バッファが使用される場合、可変長デコードでの下位ビットストリーム解析を含めたオフホストのデコードをサポートするため、バッファには単に、ビデオ ビットストリームからの生のバイトが含まれる。

意図された設計に沿った方法でビットストリーム データ バッファが使用されるよう、バッファの内容には一定の制限が課せられる。

  1. 各ピクチャの最初のビットストリーム データ バッファは、ビットストリーム内における当該ピクチャ データの最初のバイトで始まらなければならない。
  2. MPEG-1 と MPEG-2 使用以外では、(前のピクチャの全データの終りにに続いて)それがビット ストリーム内の現在のピクチャの最初のスライス(シーケンス ヘッダー、ピクチャ ヘッダーなど) に先行するなら、各ピクチャのビットストリーム データ バッファはすべてのデータとともに開始しなければならない。
  3. MPEG-1 と MPEG-2 使用については、最各ピクチャの初のビットストリーム データ バッファはピクチャの最初のスライスのスライス開始コードで開始しなければならない (シーケンス ヘッダーやピクチャ ヘッダーなどはない、なぜならすべての関連データはこのスペックのパラメータで提供されるからである)。
  4. 、ビットストリーム データのスライスの先頭が、あるビットストリーム データ バッファ内に位置している場合、そのバッファが割り当てられたサイズまで一杯でない限り、スライスの末尾も同じデータ バッファ内に位置していなくてはならない。

デコーダでは、ビットストリーム データ バッファへの格納状況を、スライスが複数のバッファになるべくまたがらないように管理したほうがよい。

3.6 アルファ ブレンド データのロード (bDXVA_Func=2)

DirectX VA 機能の 2 番目のタイプは、ビデオ データとブレンドされるアルファ ブレンディング サーフェスを指定する情報のロードである。

3.6.1 接続構成

アルファ ブレンド データをロードするための 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" の両方が中期的には要求されると予想される

3.6.2 最小限の相互動作性構成セット

設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットの最低 1 つの接続構成メンバと共に動作できる必要がある。アルファ ブレンディング データをロードするための最小限の相互動作性構成セットは、bConfigDataType のすべての定義値から構成される。

3.6.3 AYUV アルファ ブレンディング サーフェスのロード

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 アルファ ブレンディング サーフェスの幅と高さは、関連付けられたバッファ記述リスト内で指定される。

3.6.3.1 16 エントリ AYUV パレットのロード

16 エントリ YUV パレットは、16 個の DXVA_AYUVsamples サンプルの配列として定義される。この場合、個々のサンプルの SampleAlpha8 は意味を持たないため、"0" でなければならない。

パレットは、グラフィックとデコード済みビデオ ピクチャをブレンドする際に、ソースを作成するために使用できる。このパレットは、以下のいずれかと共に、グラフィック ソースの作成に使用できる。

  1. IA44/AI44 アルファ ブレンディング サーフェス
  2. DPXD アルファ ブレンディング サーフェス、ハイライト バッファ、および DCCMD データ

3.6.3.2 AYUV サーフェスのロード

16 エントリ パレットのみをロードするのではなく、グラフィックの内容を指定する AYUV イメージとして、イメージ グラフィック全体を直接ロードできる。

3.6.4 IA44/AI44 アルファ ブレンディング サーフェスのロード

インデックスアルファ 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 アルファ ブレンディング サーフェスの幅と高さは、関連付けられたバッファ記述リスト内で指定される。

3.6.5 DPXD アルファ ブレンディング サーフェスのロード

デコードされる 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)」を参照すること。

3.6.6 ハイライト データのロード

ハイライト データは、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 が使用される。

3.6.7 DCCMD データのロード

DCCMD (ディスプレイ制御コマンド) データは、DVD ROM 仕様に準拠した方法でフォーマットされ、アルファ ブレンディング サーフェスを作成するため、ハイライト データと共に DPXD サーフェスに適用される。DCCMD データ バッファの内容は、DVD ディスプレイ制御コマンド (DCCMD) のリストとしてフォーマットされたデータで構成しなければならない。

注 :  DVD サブピクチャ定義およびデータ フィールド解釈の詳細については、「DVD Specifications for Read-Only Disk:Part 3 – Video Specification (v. 1.11, May '99)」を参照すること。

3.7 アルファ ブレンド コンビネーション (bDXVA_Func=3)

アルファ ブレンド コンビネーションでは、最後にロードされてたアルファ ブレンド ソース情報を参照ピクチャと組み合わせて、表示用のブレンド ピクチャを作成する。この処理は、アルファ ブレンド コンビネーション データ バッファを使って制御される。

3.7.1 接続構成

アルファ ブレンド コンビネーションのための 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" は適用できないことを示す。

3.7.2 最小限の相互動作性構成セット

設計上の条件として、すべての DirectX VA デコーダは、すべての DirectX VA アクセラレータと相互動作する必要がある。このためには、すべての DirectX VA デコーダが、接続構成セットのすべてのメンバと共に動作でき、すべての DirectX VA アクセラレータが、同セットの最低 1 つの接続構成メンバと共に動作できる必要がある。アルファ ブレンディング データをロードするための最小限の相互動作性構成セットは bConfigBlendType から構成される、それは DirectX VA 限定モード プロファイルによって決められた範囲の値を持つ。

3.7.3 アルファ ブレンド コンビネーション バッファ

アルファ ブレンド コンビネーション バッファは、ソース ピクチャと、アルファ ブレンディング情報を伴うグラフィック イメージからの、ブレンド ピクチャの生成を制御する。ソース ピクチャおよび宛先ピクチャが 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 に適用される :

  1. GraphicSourceRect の "top" と "left" パラメータはゼロでなければならない。
  2. GraphicSourceRect の "right" パラメータは "End X-coordinate" から 直前の DVD SET_DAREA DCCMD の "Start X-coordinate" を引いたものに 1 を加えたものと等しくなければならない、最後に加えた 1 は下の注に説明してあるように矩形補間の違いを調整するものである。
  3. GraphicSourceRect の "bottom" パラメータは "End Y-coordinate" から 直前の DVD SET_DAREA DCCMD の "Start Y-coordinate" を引いたものに 1 を加えたものと等しくなければならない、最後に加えた 1 は下の注に説明してあるように矩形補間の違いを調整するものである。

次の制限が RECT パラメータに適用される :

  1. "left" と "top" はゼロ以上でなければならない。
  2. "right" と "bottom" はそれぞれ "left" と "top" 以上でなければならない。
  3. "right" が "left" と同じ、あるいは "top" が "bottom" と同じなら、すべての RECT パラメータは値 "0" を持たなければならない、これはグラフィック ピクチャを使用しないことを示す。
  4. "right" と "bottom" はそれぞれグラフィック ソース サーフェスの幅と高さを越えてはならない。 bConfigDataType = "2" のとき、割り当てられた幅と高さはそれぞれ 720 と 576 である。

GraphicDestinationRect : グラフィック ピクチャからの領域を保持する宛先ピクチャの領域。RECT データ構造体として指定する。bConfigGraphicResizing が "0" の場合は、幅と高さが GraphicSourceRect で指定された領域と同じでなければならない。GraphicDestinationRect と GraphicSourceRect のサイズが異なる場合、グラフィックに適用される再サンプリング方式は指定されないが、最低でもブレンディング情報を表す AYUV サーフェスのバイリニア再サンプリングと同等の品質を持っていたほうがよい。

次の制限が GraphicDestinationRect の RECT パラメータに適用される :

  1. この要件が次のパラグラフと3.7.3.3 と 3.7.3.4 章で説明されている 8 サンプルによるグラフィックのオフセットの必要性と矛盾しない限りは、"left" と "top" はゼロ以上でなければならない。
  2. "right" と "bottom" はそれぞれ "left" と "top" 以上でなければならない。
  3. "right" が "left" と同じ、あるいは "top" が "bottom" と同じなら、すべての RECT パラメータは "0" を持たなければならない、GraphicSourceRect もすべてのパラメータが "0" を持つように指定しなければならない。
  4. bConfigBlendType = 0 なら、"right" と "bottom" はそれぞれ非圧縮デスティネーション サーフェスに割り当てられた幅と高さを越えてはならない。
  5. bConfigBlendType = 1 なら、"right" と "bottom" はそれぞれソース グラフィック サーフェスに割り当てられた幅と高さを越えてはならない。

アルファ ブレンド データ ローディングが bConfigDataType に "2" を使い、bConfigGraphicResizingに "0" を使うなら、次の制限が GraphicSourceRect に適用される :

  1. "top" は直前の DVD SET_DAREA DCCMD の "Start Y-coordinate" と等しくなければならない。
  2. "left" は直前の DVD SET_DAREA DCCMD の "Start X-coordinate" あるはその値引く 8 のどちらかと等しくなければならない (3.7.3.3 章と 3.7.3.4 章を参照すること)。
  3. GraphicDestinationRect の "right" パラメータは "left" プラス 直前の DVD SET_DAREA DCCMD の "End X-coordinate" マイナス "Start X-coordinate" プラス 1 と等しくなければならない。最後に加えた 1 は下の注に説明してあるように矩形補間の違いを調整するものである。
  4. GraphicDestinationRect の "bottom" パラメータは "top" プラス 直前の DVD SET_DAREA DCCMD の "End Y-coordinate" マイナス "Start Y-coordinate" プラス 1 と等しくなければならない。最後に加えた 1 は下の注に説明してあるように矩形補間の違いを調整するものである。

注 :  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 としてフォーマットされ、以下の決まりに従う :

  1. PictureDestinationRect 外の範囲がブレンディング一定色として生成されるなら、OutsideYUVcolor の bSampleAlpha8 の値は "255" でなければならない。
  2. 以下の 2 つの場合のどちらかであれば、OutsideYUVcolor の bSampleAlpha8 の値は "0" でなければならない :
    1. PictureDestinationRect 外の範囲がブレンディングによっては影響されない場合、あるいは
    2. PictureDestinationRect 外の範囲が使用され得ない (bConfigStayInPicDestRectArea が 値 "1" を持つ) 場合。
  3. OutsideYUVcolor の bSampleAlpha8 の他のすべての値は将来の使用のために予約されている。

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" (バックエンド ハードウェア ブレンド) なら、実際のブレンディング操作はここで説明したものとは少し異なる場合がある。しかし、表示結果は同じでなければならない。たとえば、ビデオ ピクチャをソースからデスティネーション サイズにマップするよう指定したリサイズは、逆の方法でグラフィック内容をソースビデオ ピクチャに従ってその正しい位置にマップするよう適用されるかもしれない、するとこの操作の違いに対応してブレンディング結果が表示される - しかし結果の最終視覚効果はブレンド コンビネーション コマンドで指定されなければならない。

3.7.3.1 例 : MPEG-2 パン - スキャン 操作

たとえば、PictureSourceRect16thPel を使って MPEG-2 ビデオ パン - スキャン パラメータが指定する範囲を選択した場合、PictureSourceRect16thPel パラメータは次のように組み合われる (その計算された値が上の制限に反しないように提供される、MPEG-2 パン - スキャン パラメータの場合と 特に MPEG-2 DVD コンテンツの場合) :

  1. left = 8×(horizontal_size - display_horizontal_size) - frame_centre_horizontal_offset
  2. top = 8×(vertical_size - display_vertical_size) - frame_centre_vertical_offset
  3. right = left + 16×display_horizontal_size
  4. bottom = top + 16×display_vertical_size

次に PictureDestinationRect は通常次のように作成される :

  1. left = 0 or 8 (3.7.3.3 章)
  2. top = 0
  3. right = left + display_horizontal_size
  4. bottom = top + display_vertical_size

3.7.3.2 例 : 16:9 ピクチャ での DVD 4:3 パン スキャン

たとえば、16:9 ピクチャで 4:3 パン スキャンを MPEG-2 DVD で使うと、パン スキャン パラメータは上記の制限を犯さない範囲に制限され、更にこの場合にはパン スキャン パラメータは次の制限に従う :

  1. horizontal_size = 720 or 704
  2. vertical_size = 480 or 576
  3. display_horizontal_size = 540
  4. display_vertical_size = vertical_size
  5. frame_centre_vertical_offset = 0
  6. frame_centre_horizontal_offset は次の絶対値を持つ
    1. horizontal_size = 720 に対して 1440 以下
    2. horizontal_size = 704 に対して 1312 以下

次に 3.7.3.1 章で説明されている公式がこの場合直接に適用される。

3.7.3.3 例: DVD 704 ワイド 非パン スキャン ピクチャ操作

もう 1 つの例として、704 ワイド ピクチャで DVD MPEG-2 を使うとき、デコードされたピクチャの境界を拡張する 3.7.3.1 章を使うと (デコードされた horizontal_size を 704 に拡張するように display_horizontal_size に 720 を指定するなら)、転送元矩形を指定する。このような場合、ホスト ソフトウェア デコーダは転送元矩形を割り当てられたソース範囲の外まで届くようにクロップし、そのクロップに対してデスティネーション矩形の調整を管理する必要がある。この場合、2 つの基本的な場合がある。両方とも次のようなピクチャ 転送元矩形の指定を要件とする :

2 つの場合とは :

  1. ピクチャ デスティネーション矩形が次のように設定され得るか :
    • left = (display_horizontal_size – horizontal_size) / 2 = 8
    • right = left + horizontal_size = 712
    この場合直進方式のグラフィックを使う。
  2. あるいはピクチャ デスティネーション矩形が次のように設定され得るか :
    • left = 0
    • right = left + horizontal_size = 704
    この場合グラフィック デスティネーション矩形はシフトされたピクチャ デスティネーションを補償する 8 サンプルで左に表示される。

これらの 2 つの場合のうち多分 2 番目が優先される

3.7.3.4 例 : DVD 352 ワイド ピクチャ操作

もう 1 つの例は 325 ワイドピクチャの DVD 使用である、これはピクチャ 転送元矩形 (1/16th サンプル解像度) を使って 704 の幅に拡大する :

  1. left = 0
  2. right = 16×(left + horizontal_size) = 5632
そして、ピクチャ デスティネーション矩形は 2 つの場合がある :
  1. ピクチャ デスティネーション矩形が次のように設定されるか :
    1. left = 8
    2. right = left + 2×horizontal_size = 712
    3. この場合直進方式のグラフィックを使う。
  2. あるいはピクチャ デスティネーション矩形が次のように設定され得るか :
    1. left = 0
    2. right = left + 2×horizontal_size = 704
    3. この場合グラフィック デスティネーション矩形はシフトされたピクチャ デスティネーションを補償する 8 サンプルで左に表示される。

これらの 2 つの場合のうち多分 2 番目が優先される

3.7.3.5 例 : DVD 720 ワイド ピクチャ操作

かなり小さな例は 720 ワイド ピクチャの DVD MPEG-2 の使用である、(1/16 サンプル解像度で) ピクチャ 転送元矩形は次のとおりである :

  1. left = 0
  2. right = left + 16×horizontal_size = 11520
デスティネーション矩形は通常以下のとおりである :
  1. left = 0
  2. right = left + horizontal_size = 720

3.7.3.6 例 : 4:3 ピクチャ操作における DVD 16:9 レターボックス高さ

もう 1 つの例はレターボックス フレーミングを持つ 4:3 ディスプレイでのDVD 16:9 ビデオの使用である。以下のピクチャ 転送元矩形を使うことによってサポートされる :

  1. top = 0
  2. bottom = top + 16×vertical_size = 7680 or 9216
そしてピクチャ デスティネーション矩形は以下のとおりである :
  1. top = vertical_size / 8 = 60 or 72
  2. bottom = 7 × vertical_size / 8 = 420 or 504

3.8 ピクチャ再サンプリング制御 (bDXVA_Func=4)

ピクチャの再サンプリング機能は、空間スケーラブル ビデオ コーディング、参照ピクチャの再サンプリング、またはアップサンプル ピクチャや表示ピクチャとして使用するための再サンプリングといった目的で定義される。

再サンプリングは、ピクチャのエッジでの "クリッピング" を使い、H.263 補遺 O 「空間スケーラビリティ (Spatial Scalability)」、または MPEG-2 および MPEG-4 の「空間スケーラビリティ (Spatial Scalability)」のいくつかのフォーマットと同じである H.263 補遺 P に定義されているように実行されなければならない。この場合、単純な 2 タップ分割可能フィルタリングが使用される。

3.8.1 接続構成

ピクチャの再サンプリング制御に接続構成は不要である。この処理には適切な制限モード GUID のサポートのみが必要となる。

3.8.2 最小限の相互動作性構成セット

ピクチャの再サンプリング制御には接続構成が不要なため、この処理に最小限の相互動作性セットを定義する必要はない。

3.8.3 ピクチャ再サンプリング制御バッファ

再サンプリング処理を制御するためのバッファタイプが 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 サポートを提供するために必要となる。)

4 制限モード

多くの制限モード プロファイルがこの章で定義される。これらの制限モード プロファイルによって、どの制限モード プロファイルをサポートしているかの指標が得られるので、デコーダはアクセラレータの性能を確認することができる。

ここで定義されているいくつかの制限モード プロファイルはここで定義される他の制限モード プロファイルの能力の単純なサブセットで定義される (たとえば、MPEG2_A プロファイルは MPEG2_B プロファイルの能力のサブセットである)。アクセラレータ能力決定の論理構造を強化するため次のことが要求される、ある個別の制限モード プロファイルをサポートするアクセラレータは、問題のそのプロファイルの能力のサブセットとして定義されるすべての制限モード プロファイルをもサポートしなければならない。たとえば、MPEG2_A プロファイルは MPEG2_B プロファイルの能力のサブセットとして定義されるので、MPEG2_B プロファイルをサポートするすべてのアクセラレータは MPEG2_A プロファイルをもサポートしなければならない。

4.1 新規制限プロファイルの追加

以下に挙げる制限モード プロファイルは、将来広くサポートされると思われる機能の組み合わせを見越して定義された。Microsoft では、これら以外の、実用的かつ必要と思われる各種機能の組み合わせを含む新規プロファイル追加の提案を受け入れている。制限モード プロファイルは、デコードに必要な一連のビデオ コーディング "ツール" を確立するために、この仕様で定義されている。最も重要な点は、特定のビデオ データ フォーマットが、API を使って何らかの方法でデコードできるかどうかを決定することである。一連の "ツール" を確立することに加え、デコーダは、それらのツールを、API を使ってどのように操作するか認識している必要がある。これについては、続く構成情報のセクションで解説する。

4.2 非制限処理

この API/DDI が、以下に定義する制限モード プロファイルに厳密に準拠せずに使用される場合、wRestrictedMode フィールドは、制限がないことを示す値に設定されなければならない。

  1. 接続モードと機能 :
    1. wRestrictedMode = 0xFFFF
    2. 定義済みの bDXVA_Func 値がすべて使用可能

4.3 H261_A 制限プロファイル

H261_A 制限プロファイルには、ITU-T 勧告 H.261 を最小限にサポートするのに必要な一連の機能が含まれる。H.261 補遺 D グラフィックのアクセラレーション サポートは除外される。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、次の一連の制限によって定義される。

  1. 接続モードと機能 :
    1. wRestrictedMode = "1"
    2. bDXVA_Func = 1
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • BPP = 8
      • bSecondField = 0
      • (MacroblockWidth, MacroblockHeight) = (16, 16)
      • (WT, HT) = (8, 8)
      • bChromaFormat = '01' (4:2:0)
      • bPicStructure = '11' (フレーム構造化)
      • bMVprecisionAndChromaRelation = '10' (H.261 整数サンプル動き)
      • bPicExtrapolation = 0
      • bPicDeblocked = 0
      • bPic4MVallowed = 0
      • bPicOBMC = 0
      • bMV_RPS = 0
      • bPicScanFixed = 1
    2. マクロブロックレベルの制限 :
      • MotionType = '10' (フレーム動き) (MotionForward = 1 の場合)
      • MBscanMethod = '00' (ジグザグ) (bConfigHostInverseScan = 0 の場合)
      • FieldResidual = 0 (フレーム残余)
      • MotionBackward = 0 (逆方向予測なし)
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、H.261 ビデオ フォーマットのデータを含んでいなければならない。
  3. 4.4 H261_B 制限プロファイル

    H261_B 制限プロファイルには、ITU-T 勧告 H.261 をサポートするのに必要な一連の機能が含まれる。H.261 補遺 D グラフィックのアクセラレーション サポートは除外されるが、ブロック解除フィルタ ポストプロセッシングのサポートは含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H261_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

    1. 接続モードと機能 :
      1. wRestrictedMode = "2"
    2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
      1. bPicDeblocked は 0 または 1
      2. bPicDeblocked が 1 の場合は、wDeblockedPictureIndex は wDecodedPictureIndex と同じであってはならない。

    4.5 H263_A 制限プロファイル

H263_A 制限プロファイルには、ITU-T 勧告 H.263、および少数の特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。

  1. 接続モードと機能 :
    1. wRestrictedMode = "3"
    2. bDXVA_Func = 1
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • BPP = 8
      • bSecondField = 0
      • (MacroblockWidth, MacroblockHeight) = (16, 16)
      • (WT, HT) = (8, 8)
      • bChromaFormat = '01' (4:2:0)
      • bPicStructure = '11' (フレーム構造化)
      • bRcontrol = 0
      • bMVprecisionAndChromaRelation = '01' (H.263 ハーフサンプル動き)
      • bPicExtrapolation = 0
      • bPicDeblocked = 0
      • bPic4MVallowed = 0
      • bPicOBMC = 0
      • bMV_RPS = 0
      • bPicScanFixed = 1
    2. マクロブロックレベルの制限 :
      • MotionType = '10' (フレーム動き) (MotionForward = 1 の場合)
      • MBscanMethod = '00' (ジグザグ) (bConfigHostInverseScan = 0 の場合)
      • FieldResidual = 0 (フレーム残余)
      • H261LoopFilter = 0 (H.261 ループ フィルタなし)
      • MotionBackward = 0 (逆方向動きおよび双方向動きなし)
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、"ベースライン" モードの H.263 ビデオ フォーマット データ (オプションなし、PLUSPTYPE なし) を含んでいなければならない。または無視する場合は、補遺 L 情報付きの H.263 ビデオ フォーマット データを含んでいなければならない。

4.6 H263_B 制限プロファイル

H263_B 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、H263_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = "4"
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • bPicDeblocked は 0 あるいは 1 でもよい
      • bPicDeblocked = 1 の場合、wDeblockedPictureIndex は wDecodedPictureIndex と同じでも同じでなくてもよい
      • bRcontrol は 0 または 1
      • bPicExtrapolation は 0 または 1
      • Pic4MV は 0 または 1
      • Motion4MV は 0 または 1
      • bPicScanFixed は 0 または 1
    2. マクロブロックレベルの制限 :
      • bConfigHostInverseScan = 0 の場合、MBscanMethod は、'00' (ジグザグ)、'01' (交互垂直)、または '10' (交互水平) のいずれでもかまわない
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、CPCF、CPFMT、および 補遺 D、I、N (出力ピクチャ 1 つにつき 1 つの順方向参照ピクチャ)、および T のサブセットと共に、H.263 ビデオ フォーマットのデータも含むことができる。

4.7 H263_C 制限プロファイル

H263_C 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、長期的な必要条件である。この機能セットは、H263_B 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = "5"
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • bPicDeblocked は 1 でもよい
      • bPicDeblocked = 1 の場合、wDeblockedPictureIndex は wDecodedPictureIndex と同じでも同じでなくてもよい
    2. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、CPCF、CPFMT、および 補遺 D、I、J、N (出力ピクチャ 1 つにつき 1 つの順方向参照ピクチャ)、および T のサブセットと共に、H.263 ビデオ フォーマットのデータも含むことができる。

4.8 H263_D 制限プロファイル

H263_D 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、H263_C 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = "6"
    2. bDXVA_Func は 1 (ピクチャのデコード) または 4 (ピクチャの再サンプリング)
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • bBidirectionalAveragingMode = 1 (H.263 双方向平均化) または 0 (MPEG-2 双方向平均化)
      • bMV_RPS は 0 または 1
    2. マクロブロックレベルの制限 :
      • MotionBackward は 0 または 1
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、補遺 K、O、P (一方向または両方向のクリッピングおよび 2 の因数によるサイズ変更)、S、および U のサブセットと共に、H.263 ビデオ フォーマットのデータも含むことができる。
  3. bDXVA_Func = 4 (ピクチャの再サンプリング) の制限 :
    1. PicResampleSourceWidth と PicResampleDestWidth は同じか、または 2 (または 1/2) の倍数で比例しなければならない。
    2. PicResampleSourceHeight と PicResampleDestHeight は同じか、または 2 (または 1/2) の倍数で比例しなければならない。
    3. PicResampleSourceHeight と PicResampleDestHeight が等しい場合は、PicResampleSourceWidth と PicResampleDestWidth は 2 (または 1/2) の倍数で比例しなければならない。PicResampleSourceHeight と PicResampleDestHeight がアップサンプリング処理を指定している場合は、PicResampleSourceWidth と PicResampleDestWidth はダウンサンプリング処理を指定してはならない。逆も同様。

注 :   MotionForward が "1" で MotionBackward が "1" の場合、H.263 では bBidirectionalAveragingMode が "1" のサポートだけが必要となるが、H263_C 制限プロファイルでは、bBidirectionalAveragingMode = 0 も可能である。これは、H263_C 制限プロファイルが、H.263 ビデオに加え、MPEG-4 ビデオもサポートできるように意図して設計された。MPEG-4 は、MPEG-1/MPEG-2 フォーマットの双方向平均化を使用する。

4.9 H263_E 制限プロファイル

H263_E 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H263_D 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = "7"
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • bPicOBMC は 0 または 1 のいずれか
    2. マクロブロックレベルの制限 :
      • bPicOBMC が 1 で Motion4MV が 1 の場合、MotionBackward は "0" でなければならない。
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、補遺 F を適用した H.263 ビデオ フォーマットのデータも含むことができる。

4.10 H263_F 制限プロファイル

H263_F 制限プロファイルには、ITU-T 勧告 H.263、および特定の拡張オプション機能をサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、H263_E 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = "8"
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • bPicBinPB may は 0 または 1
    2. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、補遺 G、M、V、W のサブセットと共に、H.263 ビデオ フォーマットのデータも含むことができる。

4.11 MPEG1_A 制限プロファイル

MPEG1_A 制限プロファイルには、MPEG-1 ビデオをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。

  1. 接続モードと機能 :
    1. wRestrictedMode = "9"
    2. bDXVA_Func = 1
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • BPP = 8
      • bSecondField = 0
      • (MacroblockWidth, MacroblockHeight) = (16, 16)
      • (WT, HT) = (8, 8)
      • bChromaFormat = '01' (4:2:0)
      • bPicStructure = '11' (フレーム構造化)
      • bRcontrol = 0
      • bBidirectionalAveragingMode = 0 (MPEG-2 双方向平均化)
      • bMVprecisionAndChromaRelation = '00' (MPEG-2 ハーフサンプル動き)
      • bPicExtrapolation = 0
      • bPicDeblocked = 0
      • bPic4MVallowed = 0
      • bPicOBMC = 0
      • bMV_RPS = 0
      • SpecificIDCT = 0
      • bPicScanFixed = 1
    2. マクロブロックレベルの制限 :
      • MotionType = '10' (フレーム動き)
      • MBscanMethod = '00' (ジグザグ) (bConfigHostInverseScan = 0 の場合)
      • FieldResidual = 0 (フレーム残余)
      • H261LoopFilter = 0 (H.261 ループ フィルタなし)
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、MPEG-1 メイン プロファイル ビデオ フォーマットのデータを含んでいなければならない。

4.12 MPEG2_A 制限プロファイル

MPEG2_A 制限プロファイルには、MPEG-2 ビデオ メイン プロファイルをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件である。この機能セットは、次の一連の制限によって定義される。

  1. 接続モードと機能 :
    1. wRestrictedMode = 0xA
    2. bDXVA_Func = 1
  2. bDXVA_Func = 1 (ピクチャのデコード) の制限 :
    1. フレームレベルの制限 :
      • wRestrictedMode = 0xA
      • BPP = 8
      • (MacroblockWidth, MacroblockHeight) = (16, 16)
      • (WT, HT) = (8, 8)
      • bChromaFormat = '01' (4:2:0)
      • bRcontrol = 0
      • bBidirectionalAveragingMode = 0 (MPEG-2 双方向平均化)
      • bMVprecisionAndChromaRelation = '00' (MPEG-2 ハーフサンプル動き)
      • bPicExtrapolation = 0
      • bPicDeblocked = 0
      • bPic4MVallowed = 0
      • bPicOBMC = 0
      • bMV_RPS = 0
      • SpecificIDCT = 0
      • bPicScanFixed = 1
    2. マクロブロックレベルの制限
      • bConfigHostInverseScan = 0 の場合、MBscanMethod は '00' (ジグザグ) または '01' (交互垂直) のどちらでもかまわない
      • H261LoopFilter = 0
    3. ビットストリーム バッファの制限 :
      • すべてのビットストリーム バッファの内容は、MPEG-2 メイン プロファイル ビデオ フォーマットのデータを含んでいなければならない。
      • bNewQmatrix[i] = 0 (i = 2 および 3)

4.13 MPEG2_B 制限プロファイル

MPEG2_B 制限プロファイルには、MPEG-2 ビデオ メイン プロファイルおよび関連するフロントエンド バッファ トゥー バッファ サブピクチャ ブレンディングを使った DVD サブピクチャをサポートするのに必要な一連の機能が含まれる。このプロファイルのサポートは、中期的な必要条件ではない。この機能セットは、MPEG2_A 制限プロファイルにリストしたものと同じ制限によって定義される。ただし次の項目については異なる。

  1. 接続モードと機能 :
    1. wRestrictedMode = 0xB
    2. bDXVA_Func = 1 (ピクチャのデコード)、2 (アルファ ブレンド データのロード)、または 3 (アルファ ブレンド コンビネーション) (これらのすべての値がサポートされなければならない)

4.14 MPEG2_C 制限プロファイル

The MPEG2_C 制限プロファイルには MPEG-2 ビデオ メイン プロファイルをサポートするために必要な一連のフィーチャーが含まれる。このプロファイルのサポートは中期的要件である。このフィーチャー セットは上記の MPEG2_A 制限プロファイルにリストしたものと同じ制限によって定義される、ただし次の項目については異なる :

  1. 接続モードと機能 :
    1. wRestrictedMode = 0xC
    2. 3.5.2 章で説明されている最小相互運用性について、bConfigResidDiffHost=0 と bConfigResidDiffAccelerator=1 を持つメンバが 1 つ追加される。

MPEG2_C 制限プロファイルは MPEG2_A プロファイルのアクセラレータ プロファイルを緩和することによって定義され (これによってアクセラレータは MPEG2_A の最小相互運用性セットのメンバをサポートせずに済む) 、MPEG2_A をサポートするすべてのアクセラレータは MPEG2_C プロファイルをサポートしなければならない。同様に、MPEG2_D プロファイルをサポートするすべてのアクセラレータは MPEG2_C プロファイルをサポートしなければならない。

4.15 MPEG2_D 制限プロファイル

MPEG2_D 制限プロファイルには MPEG-2 ビデオ メイン プロファイルのサポートに必要なフィーチャー セットと、バックエンド ハードウェア サブピクチャ ブレンディングを使った DVD サブピクチャを組み合わせるために必要なフィーチャー セットが含まれる。このフィーチャー セットは上記の MPEG2_B 制限プロファイルにリストしたものと同じ制限によって定義される、ただし次の項目については異なる :

  1. 接続モードと機能 :
    1. wRestrictedMode = 0xD
    2. 3.5.2 章で説明されている最小相互運用性について、bConfigResidDiffHost=0 と bConfigResidDiffAccelerator=1 を持つメンバが 1 つ追加される。
    3. bConfigBlendType は 0 か 1 のいずれか (アクセラレータが決定)
    4. bConfigDataType は任意の値 (アクセラレータが決定)

MPEG2_D 制限プロファイルは MPEG2_B プロファイルのアクセラレータ プロファイル を緩和することによって定義され (これによってアクセラレータは MPEG2_B の最小相互運用性セットのメンバをサポートせずに済む)、MPEG2_B をサポートするすべてのアクセラレータは MPEG2_D プロファイルをサポートしなければならない。

5 IAMVideoAccelerator 処理

IAMVideoAccelerator は、Windows 2000 内に DirectX VA 処理メカニズムを備えるためのインターフェイスである。このセクションでは、DirectX VA データ フォーマットがこのインターフェイスを介してどのように送信されなければならないかを説明する。

5.1 IAMVideoAccelerator インターフェイス

以下は、現在の Microsoft DirectShow® ドキュメント セットにある IAMVideoAccelerator の使用に関する概要説明を拡張、また向上させることを意図している。

注 :  このインターフェイスは、Microsoft Windows® 2000 で利用可能である。

オーバーレイ ミキサーの入力ピンは IAMVideoAccelerator インターフェイスをサポートしており、デコーダの出力ピンは IAMVideoAcceleratorNotify インターフェイスをサポートしている。フィルタ ピン接続のイベントは次の順序で発生する。

  1. フィルタ グラフ マネージャがデコーダの出力ピンの IPin::Connect を呼び出す。AM_MEDIA_TYPE はオプション パラメータである。
    • AM_MEDIA_TYPE は、メディア タイプを記述するデータ構造体である。この構造体には、メジャータイプ GUID (この場合は MEDIATYPE_Video)、サブタイプ GUID (この場合はビデオ アクセラレータ GUID)、およびその他さまざまなものが含まれる。その 1 つは、この場合なら非圧縮ビデオ ピクチャの幅と高さを含む、メディアについての情報を格納したフォーマット タイプ GUID である (多くの場合 MPEG1VIDEOINFOVIDEOINFOHEADERMPEG2VIDEOINFO、または VIDEOINFOHEADER2 構造体)。
    • AM_MEDIA_TYPE が存在する場合は、デコーダに、指定されたメディア タイプを使って動作するよう指示する。この指定は、"完全指定" の場合と "部分指定" の場合がある。"完全指定" の場合、デコーダは通常、そのメディア タイプを使って動作しようとする。"部分指定" の場合、"部分指定" メディア タイプと矛盾しない方法での接続に使用できる "完全指定" 互換動作モードを見つけようとする。
    • 接続に使用する "完全指定" メディア タイプを探す際は、通常、"部分指定" メディア タイプと互換性のある、出力ピンがサポートしているすべての "完全指定" メディア タイプを調べて、接続が成功するまで 1 つずつ試すという方法を使う。IPin::Connect 呼び出しに AM_MEDIA_TYPE が含まれておらず、しかしすべてのメディア タイプをチェックする必要のある出力ピンがある場合、同様の処理が行われる。
  2. デコーダ側で、特定の AM_MEDIA_TYPE (ビデオ アクセラレータ GUID を含む) がダウンストリーム入力ピンによってサポートされているかどうか調べる必要がある場合、そのピンの IPin::QueryAccept (AM_MEDIA_TYPE のサブタイプとしてビデオ アクセラレータ GUID を指定) を呼び出すか、または後述の項目 5 に解説するように、そのピンに接続を試みることによって調べることができる。
  3. デコーダ側で、ダウンストリーム入力ピンがどのビデオ アクセラレータ GUID をサポートしているかを認識しておらず、またダウンストリーム入力ピンの IPin::QueryAccept を呼び出すことによって特定のいくつかのビデオ アクセラレータ GUID だけを指名することを避けたい場合、デコーダは、IAMVideoAccelerator::GetVideoAcceleratorGUIDs を呼び出して、そのピンがサポートしているビデオ アクセラレータ GUID の一覧を取得することができる。
  4. いくつかの特定のビデオ アクセラレータ GUID については、デコーダはダウンストリーム入力ピンの IAMVideoAccelerator::GetUncompFormatsSupported を呼び出して、特定のビデオ アクセラレータ GUID の生成に使用できる DDPIXELFORMAT の一覧を取得することができる。返される一覧は、推奨の度合いが高いものから順にリストされている (最も推奨されるフォーマットが最初に記載される) ものと見なした方がよい。
  5. デコーダはダウンストリーム入力ピンの IPin::ReceiveConnection を呼び出す。その際、メディア タイプのサブタイプとして、適切なビデオ アクセラレータ GUID を指定した AM_MEDIA_TYPE を渡す。これにより、非圧縮出力サーフェスの作成を含め、動作に必要な接続が設定される。このサーフェスは、AM_MEDIA_TYPE にある幅と高さや、後述する呼び出しによって見つけられた、割り当てるサーフェスの数や、その他ビデオアクセラレータが保持していてサーフェス作成目的で使用したい情報 (ビデオ アクセラレータ GUID 自体など) を使って割り当てられる。ダウンストリーム入力ピンが、ビデオ アクセラレータ GUID、またはその他の接続に関する何らかの要素を拒否した場合、IPin::ReceiveConnection が失敗することがある。IPin::ReceiveConnection が失敗した場合は、返される HRESULT でそのことが示される。デコーダは、AM_MEDIA_TYPE にある別のビデオ アクセラレータ GUID を使うなどして、呼び出しを再試行することができる。
    • 注 :  IPin::ReceiveConnection を呼び出して接続を試行し、接続が成功したかどうかチェックするというのは、ダウンストリーム入力ピンがサポートしているメディア タイプをデコーダ側で調べるもう 1 つの方法であり、最も確実な方法でもある。
  6. IPin::ReceiveConnection の実行中、オーバーレイ ミキサーは、割り当てる非圧縮サーフェスの数を計算するため、デコーダの IAMVideoAcceleratorNotify::GetUncompSurfacesInfo を呼び出し、ビデオ アクセラレータ GUID と AMVAUncompBufferInfo 構造体を渡す。デコーダは、AMVAUncompBufferInfo 構造体を返す。
    • AMVAUncompBufferInfo データ構造体には、特定のタイプに割り当てられるサーフェス数の最大値と最小値、および割り当てられるサーフェスのピクセル フォーマットを記述した DDPIXELFORMAT 構造体が含まれる。
    • マイナーな注 :  実際に IAMVideoAcceleratorNotify::GetUncompSurfacesInfo の呼び出しでデコーダに渡されるのは、ビデオ アクセラレータ GUID のみである。
  7. オーバーレイ ミキサーはデコーダの IAMVideoAcceleratorNotify::SetUncompSurfacesInfo を呼び出す。その際デコーダに、実際に割り当てられた非圧縮サーフェスの数を渡す。
  8. オーバーレイ ミキサーは、ビデオ アクセラレータの初期化に必要なデータを取得するため、デコーダの IAMVideoAcceleratorNotify::GetCreateVideoAcceleratorData を呼び出す。
  9. デコーダは、一連の AMVACompBufferInfo データ構造体 (ビデオ アクセラレータ GUID に使用される圧縮データ バッファの各タイプごとに 1 つが対応する) を取得するため、IAMVideoAccelerator::GetCompBufferInfo を呼び出す。その際、ビデオ アクセラレータ GUID、AMVAUncompDataInfo 構造体、および圧縮バッファ タイプの数を渡す。
    • AMVAUncompDataInfo 構造体には、デコードされた非圧縮データの幅と高さをピクセルで表した値と、非圧縮ピクチャの DDPIXELFORMAT が含まれる。
    • 返される AMVACompBufferInfo データ構造体にはそれぞれ次の項目が含まれる。
      • 特定のタイプに必要な圧縮バッファの数。
      • 作成するサーフェスの幅と高さ (実際の意味を持つ、または持たないフィールド)。

        注 :  DirectDraw の圧縮バッファのサーフェス割り当て処理は、現在のところこれらのサーフェスの幅または高さが 215 以上になることを想定していない、ただしサーフェス アロケータはこの制限を犯しても明らかな失敗とはならない。このためドライバは、そのような極端なサイズを避けるように、圧縮バッファ メモリへの要求を構成したほうがよい。たとえば、幅 が "1" で高さが "65536" のバッファより、幅が "1024" で高さが "64" のバッファを要求したほうがよい。
      • サーフェスによって使用されるバイトの合計数。
      • DirectDrawSurface オブジェクトを定義し、圧縮データを格納するサーフェスの作成機能を記述した DDSCAPS2 タイプの構造体。
      • 圧縮データを格納するサーフェスの作成に使用するピクセル フォーマットを記述した DDPIXELFORMAT (実際の意味を持つ、または持たないフィールド)。
  10. 注 :  いくつかのデコーダの IAMVideoAcceleratorNotify インターフェイス メソッドへのオーバーレイ ミキサーの呼び出しは、オーバーレイ ミキサーの IPin::ReceiveConnection へのデコーダの呼び出し内で発生することが可能であり、通常そのように発生する。これは特に次の場合に当てはまる。
  11. 注 :  動的フォーマット変更をサポートするため、フィルタが接続され実行されている間、上記のメソッドによって IPin::ReceiveConnection およびその他のメソッドを呼び出すことができる。この機能は動的フォーマット変更をサポートするために用意されているが、ただしすべてのデータ セットが最初からもう一度開始されてすべての参照ピクチャ情報が失われる H.263 の動的フォーマット変更は対象とならない。

初期化後の処理中の IAMVideoAccelerator の使用について次に解説する。

  1. デコーダは、出力ピクチャの作成処理を開始するため、各非圧縮データ バッファに対して IAMVideoAccelerator::BeginFrame を呼び出す。その際、 AMVABeginFrameInfo 構造体を送信する。
    • AMVABeginFrameInfo 構造体には、宛先バッファのインデックス、ダウンストリームに送信するデータへのポインタ、およびデコーダが読み取るためにアクセラレータがデータを配置できる場所を示すポインタが含まれる。
    • 注 1 :  アクセラレータは実際には宛先バッファのインデックスを受け取らず、インデックスはダウンストリームへ行く前にオーバーレイ ミキサーによって変換される。
    • 注 2 :  IAMVideoAccelerator::BeginFrame は、IAMVideoAccelerator::EndFrame への呼び出しの間に何度でも呼び出すことができる。
    • 注 3 :  インターフェイス処理の中では、ビットストリーム内の個々のピクチャを処理するために、IAMVideoAccelerator::BeginFrame および IAMVideoAccelerator::EndFrame を呼び出す必要があるという前提はない。インターフェイスに関して IAMVideoAccelerator::BeginFrame が実行することは次の 2 つである。
      • オーバーレイ ミキサー内で、インデックスと非圧縮サーフェスとの間に関連付けを作成する。
      • デバイス ドライバ内で特定の関数を呼び出す手段を提供する (任意のデータをデコーダとデバイス ドライバの間でやり取りする手段のサポートを含む)。
  2. (しかしながら、DirectX VA 操作にはビットストリームの各ピクチャの処理には IAMVideoAccelerator::BeginFrameIAMVideoAccelerator::EndFrame 呼び出しが必要だという要件がある、これについては後に説明する。)

  3. 非圧縮データをアクセラレータに送信するため、デコーダは次のメソッドを呼び出す。
    • IAMVideoAccelerator::GetBuffer。指定されたバッファへのアクセスをロックおよび取得するため (アクセスを取得するためにこのメソッドを前に呼び出していない場合)。このメソッドの使い方として、IAMVideoAccelerator::BeginFrame の呼び出し対象となった最後の非圧縮出力ピクチャの内容のコピーを取得するのに使える特別な方法がある。ただしその宛先バッファ インデックスに対して IAMVideoAccelerator::EndFrame が呼び出されていないことが条件となる。IAMVideoAccelerator::GetBuffer を呼び出すために、デコーダは AMVACompBufferInfo データ構造からいくつかの情報が必要となる。これは、IAMVideoAccelerator::GetCompBufferInfo または IAMVideoAccelerator::GetInternalCompBufferInfo を呼び出すことで取得できる (どちらも同じ情報を取得するようである)。警告 :  デコーダが IAMVideoAccelerator::GetInternalCompBufferInfo を呼び出した結果、デバイス ドライバの DdMoCompGetInternalInfo が呼び出されることはない。
    • IAMVideoAccelerator::ExecuteAMVABUFFERINFO データ構造体の配列で指示された一連の圧縮バッファに含まれるデータを処理したほうがよいことを示す。この呼び出しでは、関数コード dwFunction がドライバに渡される。また、ダウンストリームに送信するデータへの lpPrivateInputData ポインタ、およびデコーダが読み取るためにダウンストリーム処理がデータを配置できる場所を指す lpPrivateOutputData ポインタも渡される。
    • IAMVideoAccelerator::ReleaseBuffer。デコーダが、指定されたバッファの使用を完了したため、当面はバッファへのロックされたアクセスが必要なくなったことを示す。(デコーダが引き続きバッファを使用したい場合は、バッファをそれ以上使用しないとはっきりするまで IAMVideoAccelerator::ReleaseBuffer を呼び出さないでおけば、IAMVideoAccelerator::GetBuffer を呼び出す必要性を回避できる。)
    • IAMVideoAccelerator::QueryRenderStatus。バッファが読み取りや書き込みの対象として安全かどうかを調べるため。
  4. デコーダは、宛先バッファの出力処理を完了するため、IAMVideoAccelerator::EndFrame を呼び出す。この呼び出しの際に任意のデータ ダウンストリームを渡すことができる (この呼び出しの結果実行されるのは、基本的にはこれだけである)。この呼び出しでは宛先バッファのインデックスは送信しないため、ここで渡す任意のデータ内で示さない限り、どの宛先バッファが完了したかをアクセラレータに正確に伝えることはできない。
  5. デコーダは、フレームを表示するため、表示するフレームのインデックスと、開始および終了のタイム スタンプを含む IMediaSample 構造体と共に、IAMVideoAccelerator::DisplayFrame を呼び出す。
  6. 最後に、デコーダは、すべての処理が完了したときに、IAMVideoAccelerator::EndFrame を呼び出すことによって、開始された残りの出力フレームがすべて完了したことを示し、未解放の各バッファに対して IAMVideoAccelerator::ReleaseBuffer を呼び出すことによって、ロックされたバッファをすべて解放した方がよい。

5.2 IAMVideoAccelerator への DirectX VA のマッピング

5.2.1 制限モード プロファイルと構成の設定

DirectX VA でデコード可能なデータ タイプは多岐にわたるため、またこれらのデータ タイプそれぞれに対して DirectX VA では複数のデコード構成 (ビットストリーム バッファ、ホスト残差デコード、当該バッファ タイプごとに暗号ありまたは暗号なしのアクセラレータベースの IDCT など) がサポートされているため、個々のデータ タイプとデコード構成にそれぞれ一意の GUID を指定することはあまり良い方法とはいえない。個々に指定すると GUID の数が多くなりすぎ (DirectX VA のプロファイルが 16 個あり、それぞれに 16 個の構成があると仮定すると、256 個の GUID を定義する必要がある)、それらを保持するためだけに 4 KB のメモリをすべて使い果たしてしまう。DirectX VA を IAMVideoAccelerator にマップする方法を決定する際、この点は、非常に難しい問題である。これに対し、ほかの処理定義はきわめて単純と言える。結果として、我々は各データ タイプ (つまり各制限モード プロファイル) のみに対して一意の GUID を指定し、追加の GUID 1 つを、各暗号タイプに関連付けられるようにする。その後デコード構成は、デコーダとアクセラレータの間で、DirectX VA 機能の個々のタイプについて構成を確立するための、プローブおよびロック処理を使った下位従属ネゴシエーションによって確立される。

5.2.2 DirectX VA IAMVideoAccelerator 処理仕様

厳密な処理メカニズムは次のとおり。

  1. ここで定義されている各制限モード プロファイルにはそれぞれ、ダウンストリーム入力ピンの IPin::QueryAcceptIPin::ReceiveConnection、および IAMVideoAccelerator::GetVideoAcceleratorGUIDs にリストされているメソッドによってサポート可能な DirectX VA GUID が 1 つ関連付けられている。
  2. 2)  同様に、DirectX VA で使用する各暗号プロトコル タイプにはそれぞれ、ダウンストリーム入力ピンの IPin::QueryAcceptIPin::ReceiveConnection、および IAMVideoAccelerator::GetVideoAcceleratorGUIDs にリストされているメソッドによってサポート可能な暗号プロトコル タイプ GUID が 1 つ関連付けられていなければならない。"暗号なし" GUID である DXVA_NoEncrypt のサポートは暗黙の必須条件であるため、このリストに送信されてはならない。
  3. 入力ピンへのダウンストリームに接続するための IPin::ReceiveConnection を呼び出した後で、デコーダの IAMVideoAcceleratorNotify::GetCreateVideoAcceleratorData はその接続の接続モード情報が入る DXVA_ConnectMode データ構造体へのポインタを返さなければならない。IAMVideoAccelerator::GetCompBufferInfo は *pdwNumTypesCompBuffers = 16 で呼び出されなければならず、圧縮されたバッファ情報を返さなければならない、この情報は 3.4 章で定義されているように各バッファのタイプ数が、返った AMVACompBufferInfo データ構造体の配列内でゼロから始まるインデックスで直接使用可能になっている。これは、使用されないバッファ タイプ (バッファ タイプ 0 を含む、なぜならそのバッファタイプには使用が定義いされないからである) については、アクセラレータ ドライバが AMVACompBufferInfo データ構造体をダミー パラメータ (ex. dwNumCompBuffers=0, dwWidthToCreate=0, dwHeightToCreate=0, and dwBytesToAllocate=0) 値の形で提供することを要求する。
  4. DXVA 機能の指示、および関連付けられたデータ バッファは、IAMVideoAccelerator::Execute を使って送信される。DXVA 機能は呼び出しの dwFunction パラメータで指示される。初期化にとって意味を持つ DXVA 機能は、DXVA_ConfigQueryOrReplyFunc および DXVA_EncryptProtocolFunc だけである。
    • dwFunction に DXVA_ConfigQueryOrReplyFunc が含まれる場合、この呼び出しでアクセラレータにデータを渡すための lpPrivateInputData ポインタは、構成データ構造体を指し、アクセラレータから情報を受け取るための lpPrivateOutputData ポインタは、代替または複製の構成データ構造体を格納できる領域を指していなければならない、AMVABUFFERINFO の配列の pamvaBufferInfo ポインタは NULL、dwNumBuffers はゼロでなければならない。返される HRESULT は、S_OK または S_FALSE となるか、またはプロトコル実行における深刻な問題があれば (無効な構成パラメータなど) E_FAIL かE_INVALIDARG あるいはその他のエラーを示す HRESULT となる。DXVA_ConfigQueryOrReplyFunc のすべての使用に対応する IAMVideoAccelerator::Execute の呼び出しは、ほかのすべての IAMVideoAccelerator::Execute 呼び出しより先に実行されなければならない。
    • dwFunction に DXVA_EncryptProtocolFunc が含まれる場合、この呼び出しでアクセラレータにデータを渡すためのポインタは、DXVA_EncryptProtocolHeader で始まる暗号化プロトコル データ構造体を指し、アクセラレータから情報を受け取るためのポインタは、暗号化プロトコルから返される、DXVA_EncryptProtocolHeader で始まるデータ (証明書など) を格納できる領域を、指していなければならない。返される HRESULT は、暗号化プロトコルが正常に動作していれば S_OK となり、プロトコル実行における深刻な問題があれば E_FAIL か E_INVALIDARG またはその他のエラーを示す HRESULT となる。
    上記のような処理の初期化が終わった後、実際のデコーダの処理は次のように進行する。
  5. IAMVideoAccelerator::BeginFrame は圧縮されたバッファ パラメータで bDXVA_Func を送る前に呼び出されなければならない、bDXVA_Func は非圧縮デスティネーション サーフェスへの書き込みを発生させる。DirectX VA における IAMVideoAccelerator::BeginFrame の目的は、デスティネーション サーフェスをインデックス値と結びつけ、目的のビデオ アクセラレータ ドライバにサーフェス書き込みの初期化を通知することである、これによってドライバはサーフェスがオーバーライドされる準備ができているかどうかを示して対応することができる。IAMVideoAccelerator::BeginFrame 内に渡される AMVABeginFrameInfo 構造体には IAMVideoAccelerator::BeginFrame (かつ dwSizeInputData は 2 でなければならない) 内に渡されるフレーム インデックスと適合する 1 WORD wBeginPictureIndex パラメータの pInputData ポインタが入る。これは圧縮バッファ内でサーフェスにコマンドを書き込むために用いられるインデックスである (ie. wDecodedPictureIndex、wDeblockedPictureIndex、wBlendedDestinationIndex、wPicResampleDestPicIndex として用いられる)。AMVABeginFrameInfo の pOutputData ポインタは NULL でなければならない (かつ dwSizeOutputData は "0" でなければならない)。IAMVideoAccelerator::BeginFrame が返す HRESULT は次のとおり :
    • S_OK : 非圧縮サーフェスが有効で使用準備完了。
    • E_PENDING : 非圧縮サーフェスはまだ有効ではないが、すぐに有効になる (ie. 非圧縮サーフェスは表示用に読み込まれており、サーフェスの読み込み、表示はまだ完了していない)。
    • E_FAIL あるいは E_INVALIDARG : データ フォーマットかプロところエラーが発生した場合にのみ示されるエラー (dwSizeInputData あるいは NULL 以外の pOutputData のような間違った値)。
  6. DXVA 機能の指示、および関連付けられたデータ バッファは、IAMVideoAccelerator::Execute を使って送信される。1 より大きい bDXVA_Func 値は IAMVideoAccelerator::Execute への同じ呼び出しで示される場合がある。bDXVA_Func 値は呼び出しの dwFunction パラメータ内にパックされなければならない。bDXVA_Func の 0xFF 値は、bDXVA_Func は 2 あるいは 4 バイト拡張されることを示す。2 番目のバイトも 0xFF なら、これは bDXVA_Func が 4 バイトに拡張されていることを示す。第 3 バイトの上位 4 ビットが 0xF または 0x0 の場合は、bDXVA_Func に DXVA_ConfigQueryOrReplyFunc または DXVA_EncryptProtocolFunc が含まれていることを示す。マルチバイト コマンドは、dwFunction 終了後の継続を指示してはならない。次のことにデコーダは注意を払わなければならない、IAMVideoAccelerator::Execute への同じ呼び出しに指定される異なった bDXVA_Func 値間にシーケンシャルな依存性がない事、そして連続的な IAMVideoAccelerator::Execute 呼び出しの前に IAMVideoAccelerator::BeginFrame と IAMVideoAccelerator::QueryRenderStatus の適切な呼び出しによってすべての潜在的な緊急条件 (ピクチャ デコーディング と サブピクチャ ブレンディングの間、サブピクチャ ローディングとサブピクチャ ブレンディングの間など) が避けられること。
  7. ピクチャ デコーディング パラメータ バッファは IAMVideoAccelerator::Execute の bDXVA_Func を "1" として使用したとき、各ピクチャのデコーディングに送られる最初のバッファになければならない、そしてビット ストリーム内のピクチャをデコードするすべてのバッファは次のピクチャをデコードするバッファの前に送られなければならない。マクロブロック制御コマンド バッファが送られると、対応する残差データ バッファが同じ IAMVideoAccelerator::Execute 呼び出しで (同じマクロブロックにデータを持って) 送られなければならない。
  8. IAMVideoAccelerator::EndFrame はすべての圧縮バッファが送られた後で呼び出されなければならない、それは指定した非圧縮サーフェス内の出力内容を作成する (ie. wDecodedPictureIndex、wDeblockedPictureIndex、wBlendedDestinationIndex、あるいは wPicResampleDestPicIndex に指定された操作の結果)。この IAMVideoAccelerator::EndFrame 呼び出しの目的は、ビデオ アクセラレータ ハードウェアに指定した操作に必要なすべてのデータは送られた事を知らせることである。IAMVideoAccelerator::EndFrame 経由でダウンストリームを送るデータへのポインタは終了しているフレームのインデックスを持つ 1 WORD wEndPictureIndex へのポインタでなければならない。このパラメータは 関連する圧縮バッファに送る前の IAMVideoAccelerator::BeginFrame 呼び出しに指定される wBeginPictureIndex 値と一致しなければならない。IAMVideoAccelerator::EndFrame 呼び出しに続いて、IAMVideoAccelerator::BeginFrame の別の呼び出しによってこれが発生させられ結果として S_OK が返るまでは、インデックス wEndPictureIndex の非圧縮サーフェスはピクチャの wDecodedPictureIndex、wDeblockedPictureIndex、wBlendedDestinationIndex、あるいは wPicResampleDestPicIndex 内にあってはならない。しかし、デスティネーション サーフェス インデックスは wForwardRefPictureIndex、wBackwardRefPictureIndex、wPicResampleSourcePicIndex、あるいは bRefPicSelect[i] のような続いて起きる読み込みアクセスコマンド内にもあるかもしれない。ある種のデータフォーマット エラーかプロトコル エラーがない限り、IAMVideoAccelerator::EndFrame によって返る HRESULT は S_OK でなければならない、上記のエラーの場合 E_FAIL か E_INVALIDARG あるいは他のエラー識別子となる。
  9. フィールド ベースの デコードの場合 (ex. MPEG-2 ビットストリーム)、ビットストリーム内機能ピクチャのアクセラレータ インターフェイスの非圧縮サーフェスへの 1 対 1 マッピングはない。MPEG-2 ビットストリームでフィールド ピクチャをデコードするとき、非圧縮サーフェスに 1 つの完全な出力をデコードして生成するための 2 つの"ピクチャ"がある。DirectX VA インターフェイス定義では、各フレームは wDecodedPictureIndex、wDeblockedPictureIndex、wBlendedDestinationIndex、あるいは wPicResampleDestPicIndex の各使用に対応する。それゆえ、出力非圧縮サーフェスにフィールドピクチャをデコードするには IAMVideoAccelerator::BeginFrameIAMVideoAccelerator::EndFrame への 2 つの呼び出しペアが必要である。
  10. dwFlags をゼロで IAMVideoAccelerator::QueryRenderStatus を呼び出すと、非圧縮サーフェスへのすべての書き込み操作が完了すれば S_OK を返し、その操作がまだ完了していなければ E_PENDING が返る。この呼び出しは個別の wEndPictureIndex で IAMVideoAccelerator::EndFrame を呼び出した後に起こる場合があり、wDecodedPictureIndex、wDeblockedPictureIndex、wBlendedDestinationIndex、あるいは wPicResampleDestPicIndex 内に wEndPictureIndex が設定されて送られたバッファの状態をチェックする。プロトコル エラーのイベントでは、E_FAIL か E_INVALIDARG あるいはエラー識別子が返る。

5.2.3 動き補償デバイス ドライバとの処理上の通信

ここでは、DirectX VA インターフェイスの動き補償デバイス ドライバの側面について解説する (「Windows 2000 DDK - Graphics Drivers - Design Guide - 3.0 DirectDraw DDI - 3.12 Motion Compensation」を参照)。次に、DD_MOTIONCOMPCALLBACKS 構造体を使ってアクセスされるエントリに関連する項目を列挙する。

  1. 当該処理の開始時に、ソフトウェア デコーダがビデオ アクセラレーション オブジェクトの使用を開始することをドライバに通知するため、デバイス ドライバの DdMoCompCreate が使用される。
  2. IAMVideoAccelerator::GetVideoAcceleratorGUIDs から受信される GUID は、デバイス ドライバの DdMoCompGetGUIDs から生じる。
  3. ダウンストリーム入力ピンの IAMVideoAccelerator::GetUncompFormatsSupported への呼び出しは、デバイス ドライバの DdMoCompGetFormats からのデータを返す。
  4. デコーダの IAMVideoAcceleratorNotify::GetCreateVideoAcceleratorData からの DXVA_ConnectMode データ構造体は、デバイス ドライバの DdMoCompCreate に渡される。
  5. IAMVideoAccelerator::GetCompBufferInfo から返されるデータは、デバイス ドライバの DdMoCompGetBuffInfo から生じる。
  6. IAMVideoAccelerator::Execute を使って送信されたバッファは、デバイス ドライバの DdMoCompRender によって受信される。
  7. IAMVideoAccelerator::QueryRenderStatus を使用すると、デバイス ドライバの DdMoCompQueryStatus が呼び出される。DdMoCompQueryStatus からの DDERR_WASSTILLDRAWING の戻り値をホスト デコーダは IAMVideoAccelerator::QueryRenderStatus からの E_PENDING の戻り値として見る。
  8. IAMVideoAccelerator::BeginFrame に送信されたデータは、デバイス ドライバの DdMoCompBeginFrame によって受信される。DdMoCompBeginFrame からの E_PENDING の戻り値をホスト デコーダは IAMVideoAccelerator::BeginFrame からの E_PENDING の戻り値として見る。
  9. IAMVideoAccelerator::EndFrame に送信されたデータは、デバイス ドライバの DdMoCompEndFrame によって受信される。
  10. 当該処理の最後に、現在のビデオ アクセラレーション オブジェクトがそれ以降使用されないため、ドライバが必要なクリーンアップを実行できることをドライバに通知するため、デバイス ドライバの DdMocompDestroy が使用される。