(57)【要約】【課題】ＣＵＤＡベースのＧＰＵを使用して、ビデオ復号などの複雑な連続タスクを高速化する方法を提供する。【解決手段】本方法は、ＣＰＵ上で、符号化されたビデオのヘッダおよびマクロブロックを復号し、逆量子化を（ＣＰＵまたはＧＰＵ上で）実施し、ピクチャデータをＧＰＵに転送し、ＧＰＵでデータがグローバルバッファに格納され、次いで、ＧＰＵ上で、逆量子化されたデータの逆波形変換を実施、動き補償の実施、復元ピクチャデータをＧＰＵグローバルバッファにバッファリング、復号されたピクチャデータが、もう１つのピクチャを復号する参照として使われるかどうか決定、並びに、参照として使われる場合、復号されたピクチャデータのＧＰＵグローバルバッファからＧＰＵテクスチャバッファへのコピーを含む。ＣＰＵとＧＰＵの間のデータ通信が最小限にされ、ＣＰＵおよびＧＰＵの作業負荷の釣合いがとられ、ＧＰＵにオフロードされるモジュールを、効率的に実現できる。【選択図】図３
2010130696.tif 000002
【特許請求の範囲】
【請求項１】
ＣＰＵおよびＧＰＵを備えたハードウェアアーキテクチャ上で、符号化されたビデオデータを復号する方法であって、前記ＧＰＵは、グローバルバッファである第１のバッファおよびテクスチャバッファである第２のバッファを有し、
前記ＣＰＵ上で、前記符号化されたビデオのヘッダおよびマクロブロックを復号するステップであって、復号されたピクチャデータが取得されるステップと、
前記復号されたピクチャデータに対して、任意選択で逆量子化を実施するステップと、
前記復号されたピクチャデータまたは前記逆量子化されたピクチャデータを、前記ＧＰＵの前記グローバルバッファに転送するステップとを備え、
前記ＧＰＵ上で実施される、
前記任意選択の逆量子化が前記ＣＰＵ上で実施されていない場合、前記転送されたデータを逆量子化するステップと、
前記逆量子化されたデータを波形変換するステップと、
動き補償を実施するステップであって、復元されたピクチャデータが取得され、１つのピクチャブロック中の１行にある全ピクセルを処理するのに１つのスレッドが使われ、一定数のピクチャブロックを処理するのに１つのスレッドブロックが使われるステップと、
前記復元されたピクチャデータを前記ＧＰＵの前記グローバルバッファにバッファリングするステップと、
前記復号されたピクチャデータが少なくとももう１つのピクチャを復号する参照として使われるかどうか判定し、参照として使われる場合、前記復号されたピクチャデータを前記グローバルバッファから前記テクスチャバッファにコピーするステップと、
前記復元ピクチャデータを前記グローバルまたはテクスチャバッファからディスプレイに転送するステップと
をさらに備えることを特徴とする方法。
【請求項２】
前記ＧＰＵ上で実施される逆量子化する前記ステップ、波形変換する前記ステップおよび動き補償を実施する前記ステップは、スレッド中で処理され、スレッドは、前記テクスチャバッファへの読取り専用アクセス、および前記グローバルバッファへの読出し書込みアクセスを有することを特徴とする請求項１に記載の方法。
【請求項３】
動き補償を実施する前記ステップにおいて、直前ピクチャからの参照データは、前記テクスチャバッファから読み出されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ピクチャデータは、複数の色空間フォーマットのうち１つのフォーマットの輝度および彩度成分（ＹＵＶ）を含み、前記ＧＰＵは、少なくとも２つの並列データ層に対して作用し、
前記ピクチャデータの前記色空間フォーマットを決定するステップと、
前記決定された色空間フォーマットに依存して、第１の色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を単一のデータ層に一緒に格納し処理し、異なる色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を２通りの別個のデータ層に格納し処理するステップと
をさらに備えることを特徴とする請求項１乃至３いずれかに記載の方法。
【請求項５】
前記ＧＰＵは少なくとも３つの並列データ層に対して作用し、残差ピクチャの前記輝度および彩度データは、３通りの別個のデータ層において格納され処理されることを特徴とする請求項４に記載の方法。
【請求項６】
前記ＧＰＵは、ＣＵＤＡアーキテクチャを用いることを特徴とする請求項１乃至５いずれかに記載の方法。
【請求項７】
前記ＧＰＵは、ＧＰＵネイティブ命令とプログラミング言語との間のアプリケーションプログラミングインタフェース（ＡＰＩ）に基づいて動作されることを特徴とする請求項１乃至５いずれかに記載の方法。
【請求項８】
波形変換を実施する前記ステップで、非ゼロとなるような係数のみが、そのそれぞれの係数行列インデックスとともに格納されることを特徴とする請求項１乃至７いずれかに記載の方法。
【請求項９】
波形変換をする前記ステップは、１つまたは複数のスレッド中で処理され、前記スレッドは、少なくともアドレスおよび長さ値を含む、一定長のデータセットを入力データとして受け取り、前記アドレスは、前記スレッド向けの実際の入力データが格納される前記グローバルバッファ内部の記憶場所をポイントし、前記長さは、前記スレッドに関する格納された入力データの量を示すことを特徴とする請求項１乃至８いずれかに記載の方法。
【請求項１０】
逆量子化、波形変換および動き補償の前記ステップは、共通スレッド中で一緒に処理されることを特徴とする請求項１乃至９いずれかに記載の方法。
【請求項１１】
波形変換ブロックを初期化するステップをさらに備え、前記初期化は、
残差ピクチャバッファを割り振るステップであって、残差ピクチャデータはグローバルメモリに割り振られるステップと、
ｉＤＣＴ算出のために定数行列を準備するステップと
を含むことを特徴とする請求項１乃至１０いずれかに記載の方法。
【請求項１２】
必要とされる波形変換に、どの定数行列が適しているか決定するステップと、
前記決定された定数行列を選択するステップと、
前記選択された行列に切り換えるステップと
をさらに備えることを特徴とする請求項１１に記載の方法。
【請求項１３】
現在の残差ピクチャのデータブロックの数を決定するステップと、
利用されるビデオ符号化標準に従って、データブロックの数がパラメータＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの整数倍になるまで、偽データブロックを追加するステップと
をさらに備えることを特徴とする請求項１乃至１２いずれかに記載の方法。
【請求項１４】
動き補償の前記ステップで、スレッド中で必要とされる全残差ピクチャデータは、１つの構造にパックされ、一度の値割当て動作で読み出されることを特徴とする請求項１乃至１３いずれかに記載の方法。
【請求項１５】
請求項１乃至１４いずれかに記載の方法を実施するのに適していることを特徴とする機器。
【請求項１６】
請求項１乃至１４いずれかに記載の方法をコンピュータに実施させる命令を格納したことを特徴とするコンピュータ読取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、最適化したビデオ復号を実施するために、ＣＰＵにグラフィックス処理ユニット（ＧＰＵ）サポートを提供する方法に関する。
【背景技術】
【０００２】
今日、汎用中央処理ユニット（ＣＰＵ）および特殊目的グラフィックス処理ユニット（ＧＰＵ）という少なくとも２通りの一般的手法が、処理ユニットの実装に利用されている。ＧＰＵは、表示用の２次元（２Ｄ）シーンにマップされるべき３次元（３Ｄ）シーンの算出に特化され、高度並列処理を可能にさせる並列アーキテクチャを有する。したがって、ＧＰＵは高い処理能力をもつ。ただし、共通プログラミングアプリケーションのほとんどは、ＣＰＵ上での連続処理向けに最適化されている。
【０００３】
したがって、ＧＰＵを使用してビデオ符号化および復号化を高速にすることが望ましい。従来、強力なＧＰＵの恩恵を被るために、計算タスク（たとえば画像またはビデオ処理など）は、３Ｄレンダリングタスクとなるように改変されなければならなくなり、その結果計算タスクのデータはグラフィックスデータとして編成され、グラフィックスＡＰＩ（アプリケーションプログラミングインタフェース）が使われることになる。その結果、ＧＰＧＰＵ（ＧＰＵ上での汎用計算：General-Purpose computation on GPU）が難しくなり、プログラムが複雑になる。
【０００４】
ＧＰＧＰＵの実現を容易にし改良するために、ＮＶＩＤＩＡ社が、ＧｅＦｏｒｃｅ８８００シリーズ以降のＧＰＵ向けに、「計算統合装置アーキテクチャ（Ｃｏｍｐｕｔｅ  Ｕｎｉｆｉｅｄ  Ｄｅｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）」（ＣＵＤＡ）を発表した。ＣＵＤＡは、データ並列コンピューティング装置としてのＧＰＵ上での計算を、グラフィックスＡＰＩにマップすることなく発行し管理するハードウェアおよびソフトウェアアーキテクチャである。ＣＵＤＡは、メモリアクセス効率も向上させる。
【０００５】
一般に、連続して動作される各プログラム、および並列プログラムの連続して動作される各分岐が、いわゆるスレッドである。スレッドは、その個々の入力データに対してかなり自律的に動作し、出力データを与える。入力データはバッファから読み出され、出力データはバッファに書き込まれる。ＧＰＵは、２つの基本タイプのメモリまたはバッファをもつ。ＧＰＵ上でのテクスチャ格納は一般に、より効率的なアクセスを可能にするために、他のメモリタイプとは異なる。本明細書において使われるＣＵＤＡ用語では、こうした基本メモリはいわゆるグローバルメモリおよびテクスチャメモリである。グローバルメモリは、全スレッドに対して読出し／書込みアクセスを与えるが、かなり遅く、テクスチャメモリは、スレッドに対して読取り専用アクセスを与えるが、速い。グローバルメモリにあるデータは、テクスチャメモリ内にコピーすることができる。この構造は、テクスチャマッピングなど、典型的なＧＰＵタスク向けに最適化されている。テクスチャは、３Ｄオブジェクトの表面にマップされる２Ｄパターンである。
【０００６】
ＣＵＤＡは、異なるデータ単位に対して同時に同じ計算タスクを行うための、多数のマルチプロセッサを提供する。また、一般的ＤＲＡＭメモリアドレス指定方法も提供し、ＤＲＡＭ内のどの場所でもデータを読み出し、書き込むための柔軟性をプログラマに与える。さらに、効率的なデータ共有をサポートするための、非常に速い一般的読出し／書込みアクセスを有する並列データキャッシュ（オンチップの共有メモリ）を特徴とする。ただし、ＤＲＡＭおよびキャッシュは、サイズが非常に制限され、多くのタスクにとって十分ではない。さらに、共有メモリは、ＧＰＵがＣＰＵのコプロセッサとして働くときは、ホスト関数、すなわちＣＰＵ上で稼動する関数によってアクセスすることができない。この場合、プログラムおよびデータは、制御がＧＰＵに進む前に、最初はＣＰＵによって管理されなければならなくなる。
【０００７】
ＧＰＵは、多数のデータ層に対して並列に作用することができる。一般に、ＧＰＵは、普通にはピクセル単位でＹＲＧＢデータ向けに使われる、４つのデータ層を有する。たとえば１つの入力ピクセルの４つの８ビット要素は、４Ｄ入力ベクトルとして格納し、次いで、それぞれ独立して同時に処理することができる。
【０００８】
ビデオはしばしば、ピクチャをマクロブロック（ＭＢ）にセグメント化し、ＭＢ行を連続して処理することを含むＭＰＥＧ−２標準に従って符号化される。それぞれの復号プロセスは、図１に示され、主として可変長復号１０１、逆走査１０２、逆量子化１０３、逆離散コサイン変換（ｉＤＣＴ）１０４および動き補償（ＭＣ）１０５を含む。動き補償は、先に復号されたピクチャを参照として用いる。こうしたピクチャはしたがって、フレームメモリ１０６に格納されたものである。最後に、ピクチャの復号されたサンプルが、ディスプレイに出力される。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】国際公開第２００４／０９５７０８号パンフレット
【特許文献２】米国特許第２００６／００５６５１３号明細書
【特許文献３】欧州特許出願公開第１６４１２７８Ａ２号明細書
【非特許文献】
【００１０】
【非特許文献１】Fang B., Shen G., Li S., Chen H.: Techniques for efficient DCT/iDCT implementation on generic GPU. In: Proceedings of IEEE International Symposium on Circuit and Systems (2005), pp. 1126-1129
【非特許文献２】Bo Han, Bingfeng Zhou, Efficient Video Decoding on GPUs by Point Based Rendering, In HWWS '06, Proceedings of the ACM SIGGRAPH/Eurographics conference on Graphics Hardware (Vienna, 2006)
【発明の概要】
【発明が解決しようとする課題】
【００１１】
１つの問題は、ビデオ復号などの複雑な連続タスク（sequential task）を、結合ＣＰＵ−ＧＰＵハードウェアプラットフォームに、特に上述のメモリ構造をもつＣＵＤＡ対応プラットフォームにどのようにしてマップするかである。たとえば、特許文献１は一般的手法を提供しているが、ＣＰＵ作業負荷およびＧＰＵ作業負荷の最適化バランスが達成されるように、このような複雑なプロセスの異なるモジュールを異なるハードウェア処理ユニット（ＣＰＵおよびＧＰＵ）に割り当てるのは依然として難しい。理想的には、時間コストは、ＣＰＵとＧＰＵとの間でほぼ等しくなるべきであり、すなわち、ＣＰＵもＧＰＵも、他方のユニットからの結果を待つ必要があるべきではない。
【課題を解決するための手段】
【００１２】
本発明は、少なくとも上述した問題を解決する。本発明は、ＣＰＵおよびＧＰＵプラットフォーム上に実装することができるビデオ復号システムを提供し、ＣＰＵの連続処理能力ならびにＧＰＵの並列処理能力およびメモリ構造両方が、最適化されて使用されるように、それぞれ単一の復号サブタスクが構造化される。有利には、本発明の実施において、ＣＰＵおよびＧＰＵ両方における処理負荷はほぼ等しくなる。
【００１３】
本発明の一態様によると、主処理ユニット（ＣＰＵ）およびグラフィックス処理ユニット（ＧＰＵ）を備えたハードウェアアーキテクチャであって、グラフィックス処理ユニットが第１のバッファ（テクスチャバッファ）および第２のバッファ（グローバルバッファ）を有するハードウェアアーキテクチャ上で符号化済みビデオデータを復号する方法は、主処理ユニット上で、符号化済みビデオのヘッダおよびマクロブロックを復号するステップであって、復号されたピクチャデータが取得されるステップと、復号されたピクチャデータに対して任意選択で逆量子化を実施するステップ（このステップは、後でＧＰＵ上で実施することもできるので、本発明において任意選択である）と、復号されたピクチャデータまたは逆量子化されたピクチャデータをＧＰＵに転送するステップであって、ＧＰＵにおいて、データがＧＰＵの第１の（グローバル）バッファに格納されるステップとを含み、次いで、ＧＰＵ上で、（主処理ユニットで前もって実施されていない場合）転送されたデータを逆量子化するステップと、逆量子化されたデータを波形変換する、たとえば逆ＤＣＴを実施するステップと、動き補償を実施するステップであって、復元ピクチャデータが取得されるステップと、復元ピクチャデータをＧＰＵの第１の（グローバル）バッファにバッファリングするステップと、復号されたピクチャデータが少なくとももう１つのピクチャの復号用の参照として使われるかどうか決定するステップと、復号されたピクチャデータが少なくとももう１つのピクチャの復号用の参照として使われる場合、復号されたピクチャデータを第１の（グローバル）バッファから第２の（テクスチャ）バッファにコピーするステップと、復元ピクチャデータを、第１のバッファまたは第２のバッファからディスプレイに転送するステップとを実施することを含む。
【００１４】
本発明の一実施形態は、コンピュータ、特に前述の方法の実施において協同する１つまたは複数のＣＰＵおよび１つまたは複数のＧＰＵを備えたコンピュータに前述の方法を実施させるのに適したソフトウェアに関する。
【００１５】
開示する解決法は、ＣＰＵ／ＧＰＵへのモジュール割当て、ピクチャ格納判定、および残差ピクチャに関する格納の決定を含む、実装に適したいくつかの特有の点を含む。残差ピクチャは、波形変換結果としてフォーマットすることができる。
【００１６】
ピクチャデータは、複数の色空間フォーマット（４：４：４、４：２：２、４：２：０など）の１つにおける輝度および彩度成分（ＹＵＶ）を含む。さらに、ＧＰＵは通常、少なくとも２つのデータ層（一般には、上述したように４つ）に対して並列に動作することができる。本発明の一実施形態において、符号化されたピクチャデータの色空間フォーマットが決定され、判定された色空間フォーマットに従って、第１の色空間フォーマット（４：４：４）の場合、輝度データ（Ｙ）および彩度データ（Ｕ、Ｖ）が単一のデータ層において一緒に処理され、少なくとも１つの他の色空間フォーマット（４：２：２、４：２：０）の場合、輝度データ（Ｙ）が別個の第１のデータ層において処理され、彩度データ（Ｕ、Ｖ）が別個の第２のデータ層において一緒に処理される。一実施形態では、上記色空間フォーマット依存格納および処理は、非残差ピクチャに対してのみ用いられ、残差ピクチャの場合は、３つの成分がそれぞれ、単一の別個の層において格納され処理される。
【００１７】
本発明の有利な実施形態を、従属請求項、以下の説明および図面において開示する。本発明の例示的な実施形態を、添付の図面を参照しながら説明する。
【図面の簡単な説明】
【００１８】
【図１】簡略化した従来のＭＰＥＧ−２ビデオ復号手順を示す図である。
【図２】ＣＵＤＡベースのビデオデコーダにおけるモジュール割当てを示す図である。
【図３】ＣＵＤＡベースのビデオ復号システムの例示的なアーキテクチャを示す図である。
【図４】ＣＵＤＡベースのビデオ復号システムを使用する例示的ビデオ復号手順を示す図である。
【図５】ＣＵＤＡベースのビデオ復号システムを使用する別の例示的ビデオ復号手順を示す図である。
【図６】ＧＰＵグラフィックスパイプラインを示す図である。
【図７】ＣＵＤＡにおけるスレッドのバッチ化の構造を示す図である。
【図８】色空間フォーマットによる異なるデータ平面の使用を示す図である。
【図９】スレッドの係数データ用のデータ構造を示す図である。
【図１０】ＩＱおよびｉＤＣＴカーネル用の入力データ構造を示す図である。
【図１１】波形変換カーネルの例示的な処理を示す図である。
【図１２】異なるタイプの動き補償カーネルを示す図である。
【図１３】ＭＣのためのグローバル初期化手順を示す図である。
【図１４】ＭＣカーネルの手順を示す図である。
【図１５】ＣＵＤＡベースのビデオ復号システムを使用する改良型の例示的ビデオ復号手順を示す図である。
【図１６】ＣＵＤＡベースのビデオ復号システムを使用する改良型の例示的ビデオ復号手順を示す図である。
【発明を実施するための形態】
【００１９】
図２は、本発明の一態様による、ＣＵＤＡベースのビデオデコーダにおける基本的なモジュール割当てを示す。可変長復号１０１および逆走査１０２が、ＣＰＵ上で実施される。逆量子化１０３は、ＣＰＵ上でもＧＰＵ上でも実施することができる。逆離散コサイン変換（ｉＤＣＴ）１０４ａおよび動き補償（ＭＣ）１０５ａが、ＧＰＵに割り当てられる。この割当ては、ＣＰＵおよびＧＰＵが計算集約的なタスクなので、特に有利である。動き補償のために必要とされる、予め復号された参照ピクチャが、ＧＰＵ内部のフレームメモリ１０６ａに格納される。最後に、ピクチャの復号済みサンプルｄ［ｙ］［ｘ］が、ディスプレイに出力される。「フレーム」は、本明細書において、ある一定の瞬間にインタレースまたはプログレッシブであり得るピクチャを表すことに留意されたい。
【００２０】
以下の問題点が、本発明によるデコーダフレームワークによって解決される。
１．図１に示した復号手順における異なる処理ステップ（すなわち、モジュール）をＣＰＵまたはＧＰＵに割り当てる。この割当てにより、ＣＰＵとＧＰＵとの間のデータ通信が最小限になり、ＣＰＵ−ＧＰＵパイプライン効果を最大限にするようにＣＰＵおよびＧＰＵの作業負荷のバランスがとられ、割り当てられたモジュールが効率的ＣＵＤＡ実現に確実に適合するようになる。
２．ピクチャデータをどこに格納するか、および残差ピクチャ（すなわち、波形変換結果）をどこに格納するか決定する。本発明は、アクセス労力を最小限にし、正確なサンプリングを達成する。
【００２１】
以下では、システムフローチャートについて説明し、次いで、主要ないくつかの態様についてさらに説明する。
【００２２】
システムフローチャート
図３は、ＣＵＤＡベースの高速ビデオ復号システム２０２の例示的なアーキテクチャを示す。システム２０２は、符号化されたビデオビットストリームを受信し、受信したデータを復号し、復号されたデータを表示装置２０４（ＴＶ、コンピュータモニタ、または他のこのような表示装置）に送信する。ビデオ復号システム２０２は、表示装置２０４の統合された構成要素として実装することもでき、その反対も可能であることに留意されたい。
【００２３】
ビデオ復号システム２０２は、ビデオデータを受信し、復号し、レンダリングするように構成されたパーソナルコンピュータ、ビデオゲームコンソール、または他のこのような装置内に実装することができる。システム２０２は、中央処理ユニットＣＰＵ２０６、ＣＵＤＡ対応グラフィックス処理ユニットＧＰＵ２０８、ＣＰＵ用プログラムおよびデータを格納するホストメモリ２１０、ならびにＧＰＵ用プログラムおよびデータを格納するデバイスメモリ２１２を含む。ホストメモリ２１０およびＣＰＵ２０６は、１つのデバイス（たとえば、チップ、ボードなど）内に統合することができ、デバイスメモリ２１２およびＧＰＵ２０８も統合することができるが、これは普通のケースである。
【００２４】
ホストメモリ２１０は、ＣＰＵプログラムによって必要とされ、ＣＰＵによってアクセス可能なデータ用のＣＰＵバッファ２１４と、ＣＰＵプログラムによって収集され、ＧＰＵにおけるＣＵＤＡカーネル実行によって必要とされるデータを格納する、ホスト上のカーネル入力データバッファ２１６と、ＣＰＵ上で稼動する復号プログラムであるビデオ復号アプリケーション２１８とを有する。他の１つまたは複数のアプリケーション２２０も、ホストメモリ内に存在し得る。ホスト上のピクチャバッファ２３４は、デバイスピクチャバッファ２２６のコピーを含む、ホストメモリ内の任意選択のブロックであることに留意されたい。
【００２５】
デバイスメモリ２１２は、ＧＰＵ上で稼動する復号プログラムであるカーネルプログラム２２２と、ホスト上のカーネル入力データバッファ２１６のＧＰＵコピー２０３である、デバイス上のカーネル入力データバッファ２２４（デバイスバッファ）と、参照ピクチャを含む復号されたピクチャを格納するピクチャバッファ２２６と、復号された残差ピクチャデータ（すなわち、波形変換結果）を格納する残差ピクチャバッファ２２８とを有する。他のアプリケーション用のプログラムおよびデータ２３０も、デバイスメモリ内に存在し得る。表示目的のためのピクチャを格納するディスプレイバッファ２３２は、任意選択のモジュールであることに留意されたい。あるいは、ピクチャバッファ２２６は、ディスプレイバッファとして振る舞うことができる。
【００２６】
図４は、ＣＵＤＡベースの高速ビデオ復号手順システム２０２における復号の全体的手順を示す図である。。ブロック３０２〜３１０は、ＣＰＵ２０６によって実施される処理を表し、ブロック３１２〜３２６は、ＧＰＵ２０８によって実施される処理を表す。
【００２７】
ブロック３０２で、ビデオ復号システム２０２は、符号化されたビデオビットストリームを受信する。記載する実装形態は、例示的には、ＭＰＥＧ−２プログレッシブビデオ形式に従って符号化されたビデオビットストリームに該当する。代替実装形態は、ＭＰＥＧ−２インタレース、ＭＰＥＧ−４およびＨ．２６ｘなど、他の形式に従って符号化されたビデオビットストリームを復号するように構成することができる。ブロック３０４で、たとえば様々なヘッダーの復号、ピクチャの全ＭＢ向け可変長復号の実施など、共通復号ステップが処理される。ブロック３０６で、ＭＢの可変長復号から取得された波形変換係数に対して、逆量子化が実施される。ブロック３０８で、復号されたピクチャデータがバッファリングされる。こうしたデータは、ＧＰＵにおけるカーネル実行のために必要とされる。こうしたデータは、（ＣＰＵ関連）ホストバッファ２１６内に存在し、次いで、（ＧＰＵ関連）デバイスバッファ２２４にコピーされる（２０３）。各ピクチャ単位（一般にＭＢまたはブロック）ごとのこのようなデータは、位置データまたは座標、逆量子化された波形変換係数、動きベクトルおよびＧＰＵにおけるプログラム実行に影響を与えるいくつかのフラグを含み得る。ブロック３１０で、バッファリングされたデータを、ホストバッファ２１６からデバイスバッファ２２４にコピーする。
【００２８】
ブロック３１２で、参照ピクチャが、いくつかの復元ピクチャに基づいて形成される。最適化された一実装形態では、復元ピクチャは、ＣＵＤＡのグローバルメモリに格納され、参照ピクチャとして直接使われる。最適化された別の実装形態では、復元ピクチャはグローバルメモリ内にあり、参照ピクチャはテクスチャメモリ内にあり、グローバルメモリにあるデータは、ブロック３１２においてテクスチャメモリにコピーされる。ピクチャをどこに格納するかという決定について、さらに詳細を後で示す。
【００２９】
ブロック３１４で、波形変換（たとえば、逆ＤＣＴ）が、ＧＰＵ上のＣＵＤＡカーネルとして実施されて、ＣＰＵ復号手順中に収集された一部のデータから残差ピクチャデータを取得する。このブロックについて、より詳細に後で説明する。
【００３０】
ブロック３１６で、動き補償（ＭＣ）がＧＰＵ上の１つまたはいくつかのＣＵＤＡカーネルとして実施されて、残差ピクチャデータと参照ピクチャデータを加算することによってピクチャを復元する。このブロックについて、より詳細に後で説明する。
【００３１】
ブロック３１８で、復元ピクチャは、ホストメモリへの任意選択の返送３２０、ディスプレイバッファへの任意選択の転送３２２、および任意選択の表示指向処理３２４（たとえば色空間コンバージョン、特殊効果作成など）など、さらに任意選択処理をするためにバッファリングすることができる。最後に、ピクチャは、ブロック３２６で表示装置に送られる。
【００３２】
図５は、ＣＵＤＡベースのＧＰＵ高速ビデオ復号システム２０２における復号のための全体的手順の別の変形形態を示す図である。本実施形態では、逆量子化もＧＰＵにオフロード（off load）され、ＧＰＵで、逆量子化を波形変換とともにブロック３１５で実施することができる。したがって、図４の逆量子化ブロック３０６は、図５では省いてある。
【００３３】
以下では、本発明のいくつかの主要な着想についてさらに説明する。
【００３４】
ＣＰＵ／ＧＰＵへのモジュール割当て
プログラミングの視点から、ＣＵＤＡ対応ＧＰＵ（本明細書ではデバイスと呼ぶ）は、非常に多数のスレッドを並列で実行することが可能な計算デバイスである。このＧＰＵは、主ＣＰＵ（ホストと呼ぶ）に対するコプロセッサとして動作し、アプリケーションの、データ並列な計算集約的部分を稼動する。このような部分（カーネルと呼ぶ）は、デバイスにダウンロードされ、ＧＰＵ上で多くの異なるスレッドとして実行される。１つのカーネルにあるスレッドのバッチは、スレッドブロックのグリッドとして編成される。最初に、スレッドブロックが、何らかの共有メモリを通してデータを効率的に共有しメモリアクセスを調整するように実行の同期をとることによって協同することができる複数のスレッドによって形成される。スレッドブロック中の各スレッドは、２または３成分アレイインデックスで良い、そのスレッドＩＤによって識別される。第２に、多数のスレッドブロックを、ブロックのグリッドの中に一緒にバッチすることができ、グリッド中では、各ブロックは２成分アレイインデックス（そのブロックＩＤ）によって識別される。スレッドバッチ化編成を、図７に示す。入力および出力データが問題なく編成されると、スレッドは、ブロックＩＤおよびスレッドＩＤに基づいて、１つ１つが異なるデータ部分にアクセスすることができるので、異なるデータに対する並列実行を達成することができる。
【００３５】
たとえばＤＣＴ、逆ＤＣＴなどの波形変換は、データ並列な計算集約的モジュールなので、ＣＵＤＡの実現に適している。動き補償も、ＣＰＵ−ＧＰＵデータ通信を最小限にするために、ＧＰＵに割り当てられる。したがって、全ピクチャ用のフレーム格納メモリが割り振られ、ＧＰＵ上で保持される。最後に、基本モジュール割当て結果を図２に示す。この割当てにより、ＣＰＵ−ＧＰＵ作業負荷の良好なバランス（ほぼ等しい時間コスト）が達成される。データ通信は非常に低くなる。一実施形態では、非ゼロ波形係数（たとえば、ＤＣＴ係数）、動きベクトルおよびブロックアドレスのみが、ＣＰＵからＧＰＵに送信される。
【００３６】
この基本割当ての変形形態が可能である。一実施形態では、逆量子化は、ＧＰＵ上で稼動するように変えることができ、そうすることによって、ＣＰＵ−ＧＰＵ作業負荷がわずかに調整される。一実施形態では、復号済みサンプルまたはピクチャは、たとえばＣＰＵ上での後処理などのアプリケーションのために、ＧＰＵからＣＰＵに送信することができる。
【００３７】
提案した、異なるハードウェアプラットフォーム（ＣＰＵまたはＧＰＵ）への異なるモジュールの割当てには、少なくとも以下の利点がある。
１．ＣＰＵとＧＰＵとの間のデータ通信が最小限にされる。
２．ＣＰＵおよびＧＰＵの作業負荷のバランスがとられる。
３．ＧＰＵ上にオフロードされるモジュールは、ＣＵＤＡを用いて効率的に実現することができる。すなわち、データ並列な計算集約的モジュールとなる。
【００３８】
ピクチャ格納（storage for pictures）の決定
ＧＰＵ上でのピクチャ格納に関して、少なくとも２つの問題点が解決されなければならない。すなわち、格納用のメモリ空間をどのようにして決定するか、およびＹ、Ｕ、Ｖ成分用のデータパッキング形式をどのようにして決定するか、である。
【００３９】
第１の問題点に関しては、ＣＵＤＡによってアクセスされるＧＰＵメモリは、レジスタ、ローカルメモリ、共有メモリ、グローバルメモリ、固定メモリおよびテクスチャメモリなど、異なる空間に割り振ることができる。こうした空間は、使用可能な全サイズ、アクセス許可（読取り専用／読出し書込み）、待ち時間、アクセス制限（たとえば、ＣＰＵまたはＧＰＵからアクセス可能）、同期サポートなどが大きく異なる。好ましい解決法は、スレッド向けに読取り専用であるテクスチャメモリを使うのではなく、スレッド中での読出し書込み動作をサポートするとともに大量のピクチャデータを扱うことができるグローバルメモリを使うことである。したがって、この解決法により、スレッドは読出しおよび書込み動作両方を実施することが可能になる。ただし、グローバルメモリの使用には、２つの短所がある。第１に、グローバルメモリデータの読出し動作は、テクスチャデータの場合よりはるかに遅く、第２に、補間計算が、参照ピクチャをサンプリングするスレッド中で明示的に管理されなければならなくなる。これは複雑かつ非効率であり、テクスチャメモリを使えば自動的に処理することができる。
【００４０】
本発明のこの態様は、新しいピクチャの復号用に参照としてピクチャが使われるとき、動き補償モジュールは読出し動作のみを実施し、ピクチャが復号されている最中は書込み動作のみが必要とされるという認識に基づく。つまり、ピクチャを復号する際、ある特定のピクチャのデータは、ただ一度の動作、すなわち読出し動作（ピクチャが参照ピクチャとして使われる場合）、または書込み動作（ピクチャが、復号中の結果ピクチャである場合）でアクセスされる。したがって、本発明の一態様は、復号されたピクチャを格納し、復号されたデータを、新しいピクチャ（参照ピクチャとして使われる場合）を復号する前にテクスチャメモリにコピーし、テクスチャメモリから参照画像にアクセスするために、グローバルメモリを使うものである。
【００４１】
一実施形態では、全ピクチャをテクスチャメモリにコピーすることができ、別の実施形態は、復号されたピクチャが参照ピクチャとして使われるかどうか決定し、そのピクチャが参照として使われる場合のみテクスチャメモリにコピーするステップを含む。ビデオ符号化に依存して、復号用に参照ピクチャとして機能するピクチャには、たとえばフラグで印をつけることができ、あるいは参照ピクチャのリストを受信することができる。テクスチャメモリへの書込み動作は、ホスト関数において許可されることに留意されたい。「ホスト関数」は、ＣＰＵによって起動される関数であるが、その影響は、たとえばグローバルメモリからテクスチャメモリへの、またはテクスチャメモリからグローバルメモリへのデータのコピーのように、ＧＰＵにも及び得る。本明細書において利用されるＣＵＤＡ用語では、「ホスト」はＣＰＵを意味し、「デバイス」はＧＰＵを意味する。ＧＰＵに関する他のホスト関数はたとえば、ＣＰＵ−ＧＰＵデータ通信、ＧＰＵ−ＧＰＵデータ通信、カーネル起動またはＧＰＵ機能照会である。「カーネル」は、ＧＰＵ上で実行される関数である。ただし、ＣＰＵは「カーネル起動」を実施し、この場合、コードはＧＰＵにコピーされ、ＧＰＵ資源がカーネル実行用に準備される。
【００４２】
このような方式により、グローバルメモリアクセスの上述した２つの短所（参照ピクチャをサンプリングするスレッド中で補間計算が管理される場合、読出し動作がより遅く、非効率である）が解決される。グローバルメモリからテクスチャメモリへのデータコピーの追加コストは、無視できる。
【００４３】
第２の問題点、すなわちＭＢのＹ、Ｕ、Ｖ成分用のデータパッキング形式をどのようにして決定するかに関しては、使われるクロマ形式に依存して、提案した解決法が適用可能である。ＧＰＵは一般に、頂点に対して作用する。頂点とは、ポリゴンのエッジである。各頂点は、ｘ，ｙ，ｚ座標系における位置だけでなく、テクスチャを頂点にマップする３つのテクスチャ座標ｕ，ｖ，ｗも有する。したがって、ＧＰＵアーキテクチャは、ｕ，ｖ，ｗテクスチャ座標用のいわゆる別個のチャネルまたは平面を提供する。頂点のテクスチャ座標ｕ，ｖ，ｗは、ピクチャのルマ／クロマ成分ＹＵＶとは区別されなければならないことに留意されたい。
【００４４】
図８に示す本発明の一態様によると、ＭＢのＹＵＶ成分は、利用されるクロマ形式に依存して、異なる構成平面８０１、８０２のいずれかに格納され処理され、または単一の３成分平面８０３にグループ化される。単一平面方式は実装を単純明快にし、３平面方式は、３つの成分を一度のメモリアクセスにより取り出すことができるので、より効率的である。ただし、広く使われるクロマ形式（４：２：０および４：２：２）の場合、Ｕ、Ｖデータは、Ｙデータと同じ解像度に達するようにアップサンプリングされる必要があり、このアップサンプリングは、追加処理ステップとなる。この結果、テクスチャ取出し（サンプリング）動作において正確さが犠牲になる。
【００４５】
効率および正確さ両方を最適化するために、図８のａ）に示すように、２平面データパッキング形式８０１、８０２が、４：２：０、４：２：２の色空間フォーマット４２０、４２２に対して利用される。より具体的には、Ｙデータが、１成分平面８０１として編成され、ＵおよびＶデータは、２成分平面８０２にパックされる。４：４：４クロマ形式４４４の場合、図８のｂ）に示すように、３成分方式８０３が採用される。
【００４６】
残差ピクチャの格納の決定
上述したピクチャ格納と同様に、残差ピクチャ（すなわち、それぞれの波形変換結果）の格納をどのようにして決定するかに関して、類似した２つの問題点が起こる。残差ピクチャとは、少なくとも１つの参照ピクチャに基づく予測の残余であり、すなわち、原則的には予測誤差である。受信側では、参照ピクチャ（群）は、復元ピクチャを求めるために、残差に追加されなければならない。
【００４７】
第１の問題点、すなわちどのメモリ空間が残差ピクチャの格納に使われるべきかをどのようにして決定するかに関して、状況および分析は、非残差ピクチャのケースと同様である。波形変換結果（ＷＴＲ：waveform transform results）をグローバルメモリにのみ格納し、そこから読み出すか、それともＷＴＲを最初に波形変換モジュール内部のグローバルメモリに格納し、次いで、ＷＴＲをテクスチャメモリにコピーし、次いで、ＷＴＲをテクスチャメモリから動き補償モジュールに読み出す（動き補償は、参照ピクチャデータとＷＴＲの加算を実施する）かという２つの選択肢がある。本発明の一態様によると、第１の方式が選択される。この方式には、グローバルメモリからテクスチャメモリへのデータコピーの追加コストを、低いものではあるが、抑えることができるという利点がある。上述の非残差ピクチャのケースとの間には、違いがある。すなわち、第１に、ＷＴＲをサンプリングする際に補間動作が必要とされない。第２に、動き補償モジュールのボトルネックはピクチャデータ書込み動作であり、ＷＴＲの読出しではないことが分かっている。したがって、ＷＴＲをグローバルメモリに格納し、テクスチャメモリにはコピーしないことが有益である。
【００４８】
残差のＹ、Ｕ、Ｖ成分用のデータパッキング形式の決定という問題点に関して、波形変換の入力データは、こうした成分に対して独立である。一実施形態では、３つの１成分平面が、残差ピクチャ用のパッキング形式として選択される。図８のａ）を参照されたい。
【００４９】
本発明の特に有利な点は、非常に効率的であり、同時に高いレベルの正確さをもたらすことにある。
【００５０】
波形変換（ＷＴ）
以下では、波形変換ブロックについてより詳細に説明する。波形変換は、デジタルビデオ処理において重要であり、広く用いられる変換である。波形変換は、たとえばＪＰＥＧ、ＪＰＥＧ２０００、ＭＰＥＧ−１、−２、−４、Ｈ．２６１、Ｈ．２６３、Ｈ．２６４など、様々な画像およびビデオ符号化標準のための主要な要素である。多数の波形変換が存在するが、非常に類似した計算公式を使っている。本開示では、ＤＣＴ（離散コサイン変換。「順方向ＤＣＴ」ともいう）および逆ＤＣＴ（ｉＤＣＴ）についてのみ例示的に説明するが、同じ考察を原則的に他の波形変換に適用することができる。
【００５１】
ＤＣＴは、エンコーダにおいて利用される。ＤＣＴは、ピクチャピクセルのグループを係数に変換する。係数の数は、入力データの数と同じである。次いで、逆ＤＣＴが、係数を変換してピクセル値に戻すデコーダにおいて利用される。最も一般的なケースは、８＊８ピクセルの２Ｄピクチャデータを変換／復元するためにＤＣＴ／ｉＤＣＴが適用されるものであり、この場合、ＤＣＴ公式は以下のようになる。
【００５２】
【数１】
2010130696.tif 000003
【００５３】
上式で、
８＊８ピクチャデータは、ｆ（ｘ，ｙ）：ｘ＝０，．．．，７かつｙ＝０，．．．，７であり、８＊８ＤＣＴ係数は、Ｆ（ｕ，ｖ）：ｕ＝０，．．．，７かつｖ＝０，．．．，７であり、
【００５４】
【数２】
2010130696.tif 000004
【００５５】
は定数である。
【００５６】
逆ＤＣＴ公式は、以下のようになる。
【００５７】
【数３】
2010130696.tif 000005
【００５８】
両方の変換（ＤＣＴおよびｉＤＣＴ）は、同じ形の行列乗算で表すことができる。ｉＤＣＴを例として使う。
【００５９】
Ｐｉｃｔ＝Ｂ＊Ｃｏｅｆｆ＊ＢT  （３）
全行列が８＊８次元であり、その要素は、以下のようになる。
【００６０】
【数４】
2010130696.tif 000006
【００６１】
上式で、
Ｂ＝［ｂ0  ｂ1．．．ｂ7］とすると、以下の等価行列表現を得る。
【００６２】
【数５】
2010130696.tif 000007
【００６３】
または、Ｍi,j＝ｂiｂjTとすると、以下を得る。
【００６４】
【数６】
2010130696.tif 000008
【００６５】
ＤＣＴおよびｉＤＣＴはとても重要なので、異なるプラットフォームにおいていくつかの種類のソフトウェア／ハードウェア実装がある。既存のＧＰＵベースの実現は、式３またはＪＰＥＧ  ＡＮＮ高速アルゴリズムに基づく（非特許文献１）。両方のタイプが、最適化ＣＰＵ実装に匹敵する性能を達成することができ、第１のタイプは（非特許文献１）、定常的メモリアクセスのおかげで、第２のタイプより高い性能を有する。もう１つの提案は（非特許文献２）、式５に基づくＧＰＵ実装であり、効率的ＧＰＵ解決法となる。ただし、この実装には依然として、何らかの短所がある。すなわち、全Ｍi,j行列、合計で６４＊６４個の小数値が、算出のために格納されている。これはメモリ空間の浪費であり、したがって、この手法は非効率的である。
【００６６】
本発明の一態様によると、波形変換（以下の説明のための例として、ｉＤＣＴを用いる）は、ＧＰＵ上で、ＣＵＤＡカーネル（群）として稼動する。カーネル、スレッド、スレッドブロック、およびグリッドなど、一部のＣＵＤＡ概念については上述した。
【００６７】
図３のシステム２０２において、ホスト上のカーネル入力データバッファ２１６、ビデオ復号アプリケーション２１８、カーネルプログラム２２２、デバイス上のカーネル入力データバッファ２２４および残差ピクチャバッファ２２８というブロックは、ｉＤＣＴタスクに関するものである。
【００６８】
カーネルプログラム２２２は、全カーネルを含む。多数の波形変換カーネルを、異なるデータブロック解像度および異なる定数行列（すなわち、式３の行列Ｂ）用に使うことができる。たとえば８×８のｉＤＣＴに対しては、１つのカーネルｋｅｒｎｅｌ＿ｉＤＣＴ＿８ｘ８を使えば十分である。ＣＵＤＡベースのｉＤＣＴカーネルが、複数のスレッドとして実行される。スレッドのバッチ化は、以下のようになる。１つのスレッドが、１行にある全データ要素を処理し、１つのスレッドブロックが、固定数（通常、ＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭとして記録された、１６または８個）の８×８データブロックを処理する。スレッドＩＤは２次元インデックスであり、データブロック内部の垂直位置用に１つの値、異なるデータブロック用にもう１つの値となる。ブロックＩＤは１次元であり、１つのＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭデータブロックごとに１だけ増加する。この方式には、データブロックの総数がＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの整数倍となることが必要であることに留意されたい。この問題点を解決するために、後で説明するように、「偽」データブロック（たとえば、空のデータブロック）が挿入される。
【００６９】
ＧＰＵ上でのｉＤＣＴ実行には、図３のカーネル入力データバッファ２１６、２２４に格納される、何らかの入力データが必要である。全係数（すなわち、式３の行列Ｃｏｅｆｆ中の全データ）を格納することが可能であるが、この方式は、ほとんどの係数がゼロの場合、多大なメモリおよびＣＰＵ／ＧＰＵ通信帯域幅を浪費する。本発明の一態様によると、より優れた方式は、非ゼロ係数のみを格納するものである。一実施形態では、非ゼロ係数値およびその座標（すなわち、この係数の、式３の行列Ｃｏｅｆｆでの場所）が格納される。この方式は、メモリ使用および帯域幅両方の点において、より効率的である。
【００７０】
非ゼロデータのみが格納される場合、非ゼロ係数の数は異なるデータブロックごとに異なるので、各データブロックの必要メモリサイズは可変である。図９に示した実施形態では、係数データは、メモリサイズを統一させるために、２つのデータ構造（たとえば、記憶域）に格納される。第１の共通データ構造９０４、９０４ａは、あるピクチャ中のすべての非ゼロ係数のための巨大な１次元（１Ｄ）テクスチャであり、値および座標両方を含む。第２のデータ構造９０２、９０２ａは、各データブロック用の統一サイズデータセットであり、１Ｄテクスチャにおける開始アドレスおよび非ゼロ係数の総数を含む。
【００７１】
第１のスレッド９０１は、予め定義された固定サイズおよびある特定の構造をもつ入力データ９０２を受け取る。入力データ９０２は、１Ｄテクスチャメモリ９０３内のある特定のデータ範囲９０４を識別するアドレスおよび長さ値を少なくとも含む。第２のスレッド９０１ａは、同じサイズおよび構造の、異なる入力データ９０２ａを受け取るが、アドレスおよび長さ値は、テクスチャメモリ９０３内の異なる範囲９０４ａを識別する。処理用の実際の非ゼロ係数およびその行列座標は、テクスチャメモリ９０３から取り出すことができる。図９のｂ）は、係数およびその座標を１Ｄデータ構造９０４、９０４ａ内でどのようにフォーマットすることができるかを例示的に示す。図を見ると分かるように、たとえば係数ｉ，ｊ＋１およびｉ，ｊ＋２はゼロなので、格納されない。座標用のビット数（たとえば、各々３ビット）は、行列サイズによる。全残差ピクチャブロックのスレッド入力データは、統一された記憶空間を有するので、カーネル中で容易にアクセスすることができるという利点を、本発明の本態様は有する。
【００７２】
一実施形態では、ｉＤＣＴ入力データは、図１０に示すデータ要素を含む。こうした要素は、ピクチャ用の全非ゼロ係数（値および座標両方を含む）を格納する、個別サイズの第１のブロック１８０２、ならびに図９のブロック９０２、９０２ａに対応する、各スレッド用の入力データを格納する統一サイズの第２のブロック１８０４である。ブロック１８０２には、図９のデータ構造９０４、９０４ａに対応して、１つのデータブロックにある係数およびその座標が、連続するアドレスの所に格納される。個別サイズのデータブロック１８０２は、ピクチャ一式（the complete picture）用の１つのデータリストであり、ブロック１８０４は、各データブロック用の独立データを有する。ブロック１８０２は、ＧＰＵ上でＣＵＤＡテクスチャとして割り振られることに留意されたい。
【００７３】
一実施形態では、ブロック１８０４は、１つのデータブロック中の非ゼロ係数の総数１８０６、リスト一式（the complete list）中の非ゼロ係数の開始アドレス１８０８、残差ピクチャ中のデータブロックの目標場所１８１０（すなわち、ｉＤＣＴ結果を書き込むところ）、およびＤＣＴタイプ（すなわち、フレームＤＣＴまたはフィールドＤＣＴ）を示す１ビットのフラグ１８１２のデータ要素を少なくとも含む。フラグ１８１２は、ピッチ値、すなわち、残差ピクチャ中の同じ水平座標をもつ隣接し合う行にある２つのピクセルの間の位置差に影響を与える。
【００７４】
ＧＰＵ上で逆量子化（ＩＱ）が実施されるとき、図１０のブロック１８１４に示すように、追加入力データがある。ブロック１８１４は、異なるビデオ標準による異なるＩＱ動作用に異なるデータ要素を有し得る。たとえば、ＭＰＥＧ−２用には、以下の要素を有し得る。
・量子化行列インデックス：ＩＱ用にどの量子化行列が使われるかを示す。全量子化行列は、ＩＱ手順において使われる定数値である。
・量子化スケールファクタ：イントラＤＣ値以外の全係数に対して逆量子化算術計算を実施するのに使われる。
・イントラＤＣ  ＩＱ用に使われる増倍率：この値は、イントラＤＣ  ＩＱがＣＰＵ上で実施される場合は省略することができる。
【００７５】
メモリを節約するために、いくつかの値を１つのデータ要素にパックすることができる。少なくとも、波形変換スレッド用のスレッド入力データとして使われるデータは、ＣＰＵ上での復号ステップ３０４中にカーネルデータ入力バッファブロック２１６に収集される。次いで、全データが、図４または図５のブロック３１０での特定のＣＵＤＡ  ＡＰＩコールにより、ＧＰＵ上でブロック２２４にコピーされる（２０３）。一実施形態では、１つまたは複数の「偽（fake）」データブロックを作成して、データの合計量をＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの倍数にすることができる。こうした偽ブロック中のデータは、対応するスレッドが無害な動作を行うようなものであるべきである。たとえば宛先アドレスは、残差ピクチャ範囲外に設定することができ、非ゼロ係数の数はゼロに設定することができる。
【００７６】
ｉＤＣＴは、すべてのピクチャ向けに実行される。ｉＤＣＴには、シーケンス全体に対して一度だけ実行されるグローバル初期化動作が必要である。この初期化は、残差ピクチャバッファを割り振るステップであって、残差ピクチャデータ（すなわち、ｉＤＣＴ結果）がグローバルメモリ内で割り振られ、上述の「偽」データブロックを取り扱うように追加メモリが割り振られ得るステップと、定数行列を準備するステップであって、式３の定数行列ＢがｉＤＣＴ算出のために準備されるステップとを含む。他のどの波形変換のためにも別の定数行列に切り換えることが可能であるとともに、同じ処理ステップを直接適用することができる。準備するステップは、適切な定数行列を選択することを含む。
【００７７】
残差ピクチャはＭＣおよびｉＤＣＴ両方において使われるので、残差ピクチャバッファを割り振るステップは、後で説明する動き補償において実施することもできる。各ピクチャ用のｉＤＣＴは、ＩＱも実施される場合、図４のブロック３１４、または図５のブロック３１５である。ｉＤＣＴのカーネルは、図１１に示す以下のステップとしてさらに分割することができる。
ブロック１００２で、統一サイズデータが読み出される。
ブロック１００４で、ｉＤＣＴ算出のための初期化ステップが実施される。式４は計算用に使われるので、合計結果はゼロに初期化される。
ブロック１００６、１００８、１０１０、１０１２で、ｉＤＣＴ計算が実施され、ここで全非ゼロ係数が連続して処理される。各係数を読み出した（１００８）後、ＩＱを任意選択で実施することができる（１０１０）。次いで、係数値は、式３の行列Ｂの適切な固定係数を使って乗算され、合計結果に加算される（１０１２）。最後に、全非ゼロ係数が処理された後、結果は、所与の範囲にクリップされ（１０１４）、残差ピクチャの記憶装置に出力される（１０１６）。ブロック１０１６で、クリップされた値は、後で「ＷＴカーネル設計」セクションで説明するように、書込みの前にパックされる。
【００７８】
ＷＴカーネルタスク仕様
ｉＤＣＴの場合、カーネルタスクは主として、式２が示すように、係数からピクチャデータを算出することである。ただし、アルゴリズムの選択は自明ではない。一実施形態では、式４が使われ、たとえば特許文献２や特許文献３で開示されているように、公知の方法より高速でより効率的に実現される。時間コストは、約５０％削減される。固定メモリ要件も、６４＊６４からわずか６４個の浮動小数点値まで、大きく削減される。
【００７９】
ＷＴデータ編成
データブロックに対するｉＤＣＴの実施に必要とされるデータについて上述し、詳細を図１０に示してある。一実施形態におけるデータ編成の特徴は、非ゼロ係数用に２つのデータ構造（ブロック８０２、８０４）を使用し、全係数をＣＵＤＡテクスチャバッファ内で編成することである。ただし、一部のケースでは、たとえば極度に高いビットレートをもつビデオシーケンスに対しては、全係数（ゼロおよび非ゼロ両方）を直接格納することが有利である。逆量子化（ＩＱ）がＣＰＵ上、それともＧＰＵ上で実施されるかによって、２つの要求入力データバージョンがある。いくつかの値を、１つのデータ要素にパックして、メモリを節約することができる。
【００８０】
ＷＴカーネル設計
上述したように、一実施形態におけるカーネル設計の主要ないくつかのポイントは、１つのスレッドを使って、１つのデータブロック中の１行にある全データを処理すること、「偽（fake）」データブロックを使うこと、およびパックされたデータを書込みに使うことである。１つのスレッドにある、復元された全残差ピクチャデータは、１つの構造にパックされ、一度の値割当て動作でメモリに書き込まれる。こうした発想は、互いとは独立している（すなわち、こうした発想はそれぞれ、使っても使わなくてもよい）。第１の発想、すなわち１つのスレッドを使って１つのデータブロック中の１行にある全データを処理することは、効率のためには最も重要な要素である。
【００８１】
カーネル実現の例では、ＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭは８である。この方式を適用して、たとえば、ＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６４など、他の標準で符号化されたビデオシーケンス向けにｉＤＣＴを実施することもできる。本発明は原則的に、エンコーダにおいて利用されるＤＣＴ演算向けに用いることもできる。たとえば、式３に同様の公式での他の波形変換が、このアルゴリズムを用いることができる。式３の行列次元は、８以外の整数でもよい。
【００８２】
動き補償（ＭＣ）
以下では、動き補償ブロックについてより詳細に説明する。
【００８３】
動き補償（ＭＣ）は、ビデオデコーダにおける根本的モジュールである。符号化されたビデオデータ（一般に、方形ブロックとして編成される）は、参照ピクチャ中の類似ブロックの位置を示す動きベクトルと、符号化されたブロックおよび参照ブロックの減算（あるいは、１つまたは複数の参照ブロックの補間結果）を符号化する残差ピクチャデータとを含む。ＭＣは、参照ブロックを発見し、適切なサンプリングおよび平均を実施し、残差ピクチャデータを加えてピクチャを復元することができる。ＭＣは、データがイントラ符号化であり参照が存在しないときにも、ピクチャ復元のために残差データを使うことができる。ＭＰＥＧ−２では、プログレッシブシーケンス用のＭＣモジュールは非常に単純である。予測モード（すなわち、参照ピクチャを使用するモード）は常にフレーム予測であり、Ｙ成分（輝度）データ用の完全な１６＊１６マクロブロックに動きベクトルが割り当てられる。
【００８４】
ただし、プログレッシブシーケンスは現実のアプリケーションにおいて極めて普通なので、このような単純ＭＣには、既に大きな実用的価値がある。さらに、インタレースシーケンスへの拡張は極めて容易である。というのは、１／２ピクセル単位のサンプリング、波形変換結果（すなわち、残差ピクチャデータ）の追加、および復号されたピクチャへの書込みなど、ＭＣのための全基本動作は、プログレッシブおよびインタレースビデオによって共有されるからである。さらに、プログレッシブビデオは、ＭＰＥＧ−２に全ピクチャコーディングタイプ（イントラ符号化、予測符号化および双方向予測符号化）を既に含んでいる。
【００８５】
動き補償を実施する際、以下の問題点が分析され解決される。
・動き補償の詳細なサブタスクをカーネルとして指定する。効率性を最適化するために、カーネルは、効率的に構造化されたデータ並列な計算集約的タスクを実施する。
・入力および出力データをカーネル実行用に編成する。データには、ＣＰＵおよびＧＰＵ関数中で容易にアクセスすることができ、ＣＰＵとＧＰＵとの間のデータ通信は最小限にされる。
・テクスチャ取出しにより参照ピクチャをサンプリングする。
【００８６】
本発明の一態様によると、ＭＣは、ＧＰＵ上の１つまたは複数のＣＵＤＡカーネルとして稼動する。図３において、ホスト上のカーネル入力データバッファ２１６、ビデオ復号アプリケーション２１８、カーネルプログラム２２２、デバイス上のカーネル入力データバッファ２２４、ピクチャバッファ２２６および残差ピクチャバッファ２２８というブロックは、ＭＣに関する。
【００８７】
カーネルプログラム２２２は、全カーネルを含む。図１２は、ＣＵＤＡ実行のための、全ＭＣカーネルの可能な実装を表す。ＭＣカーネル定義については、後でさらに説明する。
【００８８】
図１２のａ）で、１６×１６、８×１６および８×８は、異なるピクチャブロック解像度である。異なる参照ケースは、イントラ、前方、後方および双方向である。ブロック解像度と参照の各組合せが、別個のカーネル中で処理される。図１２のｂ）は、別のＭＣカーネル選択を示す。インターまたはイントラ予測のための前方、後方、双方向という３つの参照ケースがマージされ、「ｘｘｘｘ＿ｉｎｔｅｒ」カーネル４２６、４２８、４３０および「ｘｘｘｘ＿ｉｎｔｒａ」カーネル４０２、４１０、４１８において一緒に処理される。図１２のｃ）は、ＭＣカーネルの第３の選択を示し、ここでインターおよびイントラ予測のための全参照ケースがマージされ、１つのカーネル４３２、４３４、４３６において処理される。特に第２および第３のケースの場合、より大きいブロックを、より小さいブロックとして分割し処理することができる。
【００８９】
ＣＵＤＡでは、１つのＭＣカーネルが複数のスレッドとして実行される。カーネル設計は、利用されるスレッドバッチ化に依存する。一実施形態では、１つのスレッドが、１つのピクチャブロック中の１行にある全ピクセルを処理するのに使われ、１つのスレッドブロックが、一定数のピクチャブロック（通常、ＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭとして記録されている１６または８）を処理するのに使われる。
【００９０】
ＧＰＵ上でのＭＣ実行には、図３のカーネル入力データバッファブロック２１６、２２４に含まれる何らかの入力データが必要である。ＭＣ関連データ要素については、「ＭＣデータ編成」のセクションでさらに説明する。波形変換に関して上述したのと同様に、１つまたは複数の「偽」データブロックを作成して、データブロックの総数をＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの倍数にすることができる。
【００９１】
ＭＣは、すべてのピクチャ向けに実行される。ＭＣには、シーケンス全体に対して一度だけ実行される、何らかのグローバル初期化動作が必要である。初期化は、図１３に示すように、残差ピクチャバッファを割り振るステップ５０２、書込み用ピクチャバッファを割り振るステップ５０４および読出し用ピクチャバッファを割り振るステップ５０６を含む。
【００９２】
残差ピクチャバッファブロックの割振り５０２において、残差ピクチャデータ（すなわち、波形変換結果）がグローバルメモリ内で割り振られる。
【００９３】
「書込み用ピクチャバッファを割り振る」ブロック５０４で、書込み用ピクチャデータ（すなわち、復元ピクチャ）が、グローバルメモリ内で割り振られる。「偽」ピクチャブロックを取り扱うための追加メモリが割り振られる。
【００９４】
「読出し用ピクチャバッファを割り振る」ブロック５０６で、読出し用ピクチャデータ（すなわち、参照ピクチャ（群））が、テクスチャとして割り振られる。線形フィルタリングおよびデータ正規化用のフラグが有効にされる。これについては、「テクスチャ取出しによるピクチャサンプリング」のセクションにおいて後でさらに説明する。
【００９５】
各ピクチャ向けのＭＣは、図４のＭＣモジュール３１６内で行われる。このモジュールのカーネルは、図１４に示す以下のステップに従ってさらに分割することができる。このようなステップは、上で言及した全ＭＣカーネルに適用可能である。
【００９６】
残差ピクセルデータの読出しブロック６０２で、パックされたデータが、読出し用に使われて、メモリアクセス回数を削減するが、これについては後で「カーネル設計」のセクションでさらに説明する。
【００９７】
参照ピクセルデータの読出しブロック６０４で、テクスチャ取出しが、参照ピクチャのアクセスおよびサンプリングのために利用されるが、これについては後で「テクスチャ取出しによるピクチャサンプリング」のセクションで説明する。いくつかの参照タイプが１つのカーネルにマージされる場合、異なる参照タイプに対して異なる動作を実施するのに、条件つきチェックが用いられる。参照データと残差データの加算ブロック６０６で、参照データと残差データが加算される。参照タイプがゼロ参照ピクチャ（すなわち、イントラＭＢ）である場合、残差データがそのまま結果となる。クリッピングブロック６０８で、ブロック６０６からの加算結果が、適切な範囲までクリップされる。一般に、この範囲は［０，２５５］である。より具体的には、値が０未満の場合、値は０に設定され、２５５より大きい場合は、２５５に設定される。それ以外の場合、変更はない。ピクチャバッファへのクリップされたデータの書込みブロック６１０で、クリップされた値はパックされ、書込み用ピクチャバッファに書き込まれるが、これについては、後で「ＭＣカーネル設計」のセクションで説明する。
【００９８】
ＭＣカーネルタスク仕様
各ＭＣカーネル向けの基本動作は、図１３に示すように、参照ブロック（群）の発見、データサンプリング、残差ピクチャデータの読出し、および加算の実施である。いくつかの要素により、この手順が柔軟になる。ＭＰＥＧ−２プログレッシブシーケンスの場合、このような要素は、以下のものである。
・ピクチャブロックの解像度：Ｙ成分に対しては常に１６×１６であり、ＵおよびＶ成分に対しては、シーケンスのクロマ形式に依存して、１６×１６、８×１６、または８×８で良い。
・参照ブロック（群）：ゼロ参照ブロック、１つの前方参照ブロック、１つの後方参照ブロックおよび２つの参照ブロック（双方向）など、４つのケースがある。
・参照におけるサンプリング位置：やはり４つのケースがある。双方、水平および垂直座標は、整数または半位置（２つの隣接整数位置の中央）にあって良い。
【００９９】
一実施形態では、異なるケースが１つのカーネル内で処理される場合、各スレッド向けに条件つきチェックが実施される。これは、並行性（parallelism）が維持されるので、異なるスレッドが異なる分岐に進んだ場合よりはるかに優れている。
【０１００】
一実施形態では、サイズが統一され、異なる数のカーネルが異なる解像度に対して使われるように、大きなブロックが、いくつかの小ブロックに分割される。たとえば、１６×１６ブロックは、４つの８×８ブロック（または２つの８×１６ブロック）として分割し処理することができ、８×１６ブロックは、２つの８×８ブロックとして分割し処理することができる。
【０１０１】
参照における変化は、異なる状況に依存して、１つのカーネル中で処理してもしなくても良い。
【０１０２】
ピクチャ解像度が高く、かつ／またはビットレートが高い場合、異なる参照ケース向けに異なるカーネルを使うことが有利である。一実施形態では、それぞれ、ゼロ、１つの前方、１つの後方、および２つの参照に対応して、４：４：４クロマ形式向けに、合計で４つのカーネルがある。４：２：０および４：２：２形式向けには８つのカーネルがあり、Ｙ成分に４つ、およびＵＶ成分データに４つである。一部のピクチャでは、使用される参照タイプは、４未満である（たとえば、イントラ符号化ピクチャでは、全ピクチャブロックがゼロ参照タイプである）。したがって、実行されるカーネルは、理論値未満である。
上述した条件が満足されない場合、いくつかの参照タイプを１つのカーネルにマージし、異なるタイプ向けに分岐の条件つきチェックを用いることが有利である。参照タイプに合わせた種々の組合せスタイルが可能である。
【０１０３】
ＭＣデータ編成
動き補償のために必要とされるデータは、以下を含む。
・動き補償されるべきブロックの位置（左上のピクセル座標、またはこの点からの固定オフセットとして）。
・ゼロ、１つの前方、１つの後方、または２つの参照を示すフラグである参照タイプ。
・前方参照ブロックの位置（動きベクトルまたは絶対座標などで表すことができる）
・後方参照ブロックの位置（動きベクトルまたは絶対座標などで表すことができる）
一部のデータは、異なる参照タイプ向けに異なるカーネルが定義される場合は不要である。たとえば、各参照タイプが専用カーネルによって処理される場合、参照タイプおよび未使用参照ブロック位置は必要とされない。
【０１０４】
異なる参照タイプが１つのカーネル中で処理される際、同じ参照タイプをもつブロック用データが１つにパックされ、異なる分岐に進むスレッドの出現を最小限にする。
【０１０５】
このようなデータは、ＣＰＵ上で稼動する可変長復号手順の間に収集される。次いで、特定のＣＵＤＡ  ＡＰＩコールにより、全データがＧＰＵにコピーされる。最後に、カーネルが、マルチスレッド方式で、ＧＰＵ上で稼動し、こうしたデータを読み出し、ＭＣ動作を実施し、補償された値を復元ピクチャに書き込む。
【０１０６】
ＭＣカーネル設計
カーネル設計は、アルゴリズムの効率にとって重要である。簡単な実現法は、同じ算出が各ピクセル上で実施されるので、単一のピクセルを別個のスレッド中で処理することであろう。ただし、この解決法は、性能の面で非常に貧弱である。主たる問題は、ＭＣがメモリ集約的であって計算集約的ではなく、したがって、ＣＵＤＡ実装には必ずしも合わないことである。以下の措置により、効率が向上する。
・１つのスレッドを使って、１つのピクチャブロック中の１行にある全ピクセルを処理する。一実施形態では、１つのスレッドブロックが、固定数（通常、ＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭとして記録されている１６または８）のピクチャブロックを処理するのに使われ、スレッドＩＤには２Ｄインデックスを使うが、一方の値は垂直位置を指し、もう一方は異なるピクチャブロックを指す。
・パックされたデータを読出しに使う。一実施形態では、スレッド中で必要とされる全残差ピクチャデータが１つの構造にパックされ、一度の値割当て動作で読み出される。
・パックされたデータを書込みに使う。一実施形態では、１つのスレッドにある、動き補償された全ピクセルが１つの構造にパックされ、一度の値割当て動作でメモリに書き込まれる。
・追加メモリを使って、「偽」ピクチャブロックを取り扱う。
先に言及したように、ＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭピクチャブロックが、１つのスレッドブロック中で処理される。ピクチャブロックの総数がＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの倍数でない場合、偽ピクチャブロックに対応する一部のスレッドは、不正動作を行うことになる。簡単な解決法は、ブロックＩＤおよびスレッドＩＤに対して条件つきチェックを導入することである。ただし、この解決法は、効率的ではない。本発明の一態様によると、より優れた解決法は、いくつかの「偽」ピクチャブロックを作成して、総数をＰＩＣＴ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの倍数にすることである。こうした偽ブロックでは、対応するスレッドが無害な動作を実施する。たとえば、宛先アドレスは、オリジナルピクチャ範囲の外に設定され、そうすることによって、適切などのデータも乱されることはなく、参照位置はブロック位置と同じになる。この例では、こうした外部ピクセルを含むように、小規模追加メモリをピクチャデータ割振り段階で割り振ることができる。
【０１０７】
上述の措置は、互いに独立しており、すなわち、こうした措置はそれぞれ、使っても使わなくてもよいことに留意されたい。第１の措置（１つのスレッドを使用して、１つのピクチャブロック中の１行にある全ピクセルを処理する）が、効率のために最も重要な要素である。その結果、性能は大きく向上する。
【０１０８】
テクスチャ取出しによるＭＣピクチャサンプリング
参照ピクセル値は、動き補償中に残差ピクチャデータに加算される。このタスクは、テクスチャ取出しによって遂行される。目標位置（整数ｐｅｌまたは半ｐｅｌ）は、テクスチャ座標に設定され、ｔｅｘｆｅｔｃｈ、すなわちＣＵＤＡ  ＡＰＩコールを用いて、ピクセル値を取得することができる。サンプリング（補間）は、テクスチャ座標が半ｐｅｌ位置を示す場合、自動的に実施される。コードは、以下のようになる。
INT_TYPE pixel_val = texfetch (tex_ref_picture, x_coord, y_coord)*RANGE + ROUND  （６）
【０１０９】
図１５は、図３に示すものと同様の、ＣＵＤＡベースのビデオ復号システムを使用する、例示的なビデオ復号手順の改良を示す。ただし、いくつかのカーネルにあるタスクは、１つのカーネルにパックされる。特に、図１５に示す実施形態は、残差ピクチャバッファを持たない。代わりに、全ＧＰＵタスク（ＩＱ、波形変換、およびＭＣ）が一緒に実施され、そうすることによって有利には、中間格納が必要なくなり、残差ピクチャバッファのグローバル記憶空間が必要とされなくなる。
【０１１０】
図１６は、図４と同様に、ＣＵＤＡベースのビデオ復号システムを使用する、対応して改良された例示的なビデオ復号手順を示す。図１５に示す実施形態によると、ＧＰＵタスク（逆量子化ＩＱ、波形変換、およびＭＣ）は、単一のカーネル３１４ａ中で実施される。したがって、残差ピクチャバッファ用のグローバル記憶空間を節約することができる。
【０１１１】
本発明は、任意の１つまたは複数のＣＰＵおよび１つまたは複数のＣＵＤＡベースのＧＰＵを使って実装することができる。ただし、グラフィックス処理ユニット（ＧＰＵ）の１つまたは複数、あるいは全部を、ＧＰＵネイティブ命令とプログラミング言語との間のアプリケーションプログラミングインタフェース（ＡＰＩ）に基づいて操作することもできる。本発明は、１つまたは複数のＧＰＵおよびＣＰＵにタスクを割り当てるソフトウェアで実装することができる。このようなソフトウェアはしばしば、光ディスクなどのデータキャリア上に格納され分散される。本発明の一態様によると、コンピュータ可読媒体は、方法クレームの一項に開示した方法をコンピュータに実施させる命令を格納している。本発明の別の態様によると、製造品は、マシンによって実行されると、方法クレームの一項に開示した方法を含む動作をマシンに実施させる命令を提供するマシン読取り可能媒体を含む。
【０１１２】
さらに、本発明は、たとえばＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６４など、他のビデオ標準のビデオシーケンスの復号に適用することもできる。
【０１１３】
たとえばデジタルＴＶ（ケーブル、衛星、および地上波放送）、ビデオオンデマンド、デジタル多用途ディスク（ＤＶＤ）、パーソナルコンピューティング、カード支払い、テストおよび測定など、ＴＶ品質デジタルビデオ／オーディオアプリケーションにおいて広く用いられるビデオコーデックにおいて、デコーダを使うことができる。
【０１１４】
本発明は、純粋に例として説明され、本発明の範囲から逸脱することなく、細部の修正を行うことができることが理解されよう。
【０１１５】
説明ならびに（適切な場合は）特許請求の範囲および図面において開示した各特徴は、それぞれ独立に実現することも、どのように適切に組み合わせて実現することもできる。これらの特徴は、適切な場合、ハードウェア、ソフトウェア、またはこの２つの組合せで実装することができる。接続は、適用可能な場合、必ずしも直接または専用接続でなくても、無線接続または有線接続として実装することができる。特許請求の範囲に現れる参照番号は、例示のために過ぎず、請求項の範囲に対して限定的効果をもつものではない。
【図１】
2010130696.tif 000009
【図２】
2010130696.tif 000010
【図３】
2010130696.tif 000011
【図４】
2010130696.tif 000012
【図５】
2010130696.tif 000013
【図６】
2010130696.tif 000014
【図７】
2010130696.tif 000015
【図８】
2010130696.tif 000016
【図９】
2010130696.tif 000017
【図１０】
2010130696.tif 000018
【図１１】
2010130696.tif 000019
【図１２】
2010130696.tif 000020
【図１３】
2010130696.tif 000021
【図１４】
2010130696.tif 000022
【図１５】
2010130696.tif 000023
【図１６】
2010130696.tif 000024
【外国語明細書】
2010130696000001.pdf