JP5638230B2 - グラフィックス処理ユニットによってサポートされるビデオを復号する方法、機器およびコンピュータ読取り可能な記録媒体 - Google Patents

グラフィックス処理ユニットによってサポートされるビデオを復号する方法、機器およびコンピュータ読取り可能な記録媒体 Download PDF

Info

Publication number
JP5638230B2
JP5638230B2 JP2009268740A JP2009268740A JP5638230B2 JP 5638230 B2 JP5638230 B2 JP 5638230B2 JP 2009268740 A JP2009268740 A JP 2009268740A JP 2009268740 A JP2009268740 A JP 2009268740A JP 5638230 B2 JP5638230 B2 JP 5638230B2
Authority
JP
Japan
Prior art keywords
data
picture
gpu
buffer
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2009268740A
Other languages
English (en)
Other versions
JP2010130696A (ja
Inventor
フイ チャン
フイ チャン
リ ホア エリック チュー
リ ホア エリック チュー
ワン チャールズ
ワン チャールズ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of JP2010130696A publication Critical patent/JP2010130696A/ja
Application granted granted Critical
Publication of JP5638230B2 publication Critical patent/JP5638230B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本発明は、最適化したビデオ復号を実施するために、ＣＰＵにグラフィックス処理ユニット（ＧＰＵ）サポートを提供する方法に関する。
今日、汎用中央処理ユニット（ＣＰＵ）および特殊目的グラフィックス処理ユニット（ＧＰＵ）という少なくとも２通りの一般的手法が、処理ユニットの実装に利用されている。ＧＰＵは、表示用の２次元（２Ｄ）シーンにマップされるべき３次元（３Ｄ）シーンの算出に特化され、高度並列処理を可能にさせる並列アーキテクチャを有する。したがって、ＧＰＵは高い処理能力をもつ。ただし、共通プログラミングアプリケーションのほとんどは、ＣＰＵ上での連続処理向けに最適化されている。
したがって、ＧＰＵを使用してビデオ符号化および復号化を高速にすることが望ましい。従来、強力なＧＰＵの恩恵を被るために、計算タスク（たとえば画像またはビデオ処理など）は、３Ｄレンダリングタスクとなるように改変されなければならなくなり、その結果計算タスクのデータはグラフィックスデータとして編成され、グラフィックスＡＰＩ（アプリケーションプログラミングインタフェース）が使われることになる。その結果、ＧＰＧＰＵ（ＧＰＵ上での汎用計算：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）をグローバルメモリにのみ格納し、そこから読み出すか、それともＷＴＲを最初に波形変換モジュール内部のグローバルメモリに格納し、次いで、ＷＴＲをテクスチャメモリにコピーし、次いで、ＷＴＲをテクスチャメモリから動き補償モジュールに読み出す（動き補償は、参照ピクチャデータとＷＴＲの加算を実施する）かという２つの選択肢がある。本発明の一態様によると、第１の方式が選択される。この方式には、グローバルメモリからテクスチャメモリへのデータコピーの追加コストを、低いものではあるが、抑えることができるという利点がある。上述の非残差ピクチャのケースとの間には、違いがある。すなわち、第１に、ＷＴＲをサンプリングする際に補間動作が必要とされない。第２に、動き補償モジュールのボトルネックはピクチャデータ書込み動作であり、ＷＴＲの読出しではないことが分かっている。したがって、ＷＴＲをグローバルメモリに格納し、テクスチャメモリにはコピーしないことが有益である。
残差のＹ、Ｕ、Ｖ成分用のデータパッキング形式の決定という問題点に関して、波形変換の入力データは、こうした成分に対して独立である。一実施形態では、３つの１成分平面が、残差ピクチャ用のパッキング形式として選択される。図８のａ）を参照されたい。
本発明の特に有利な点は、非常に効率的であり、同時に高いレベルの正確さをもたらすことにある。
波形変換（ＷＴ）
以下では、波形変換ブロックについてより詳細に説明する。波形変換は、デジタルビデオ処理において重要であり、広く用いられる変換である。波形変換は、たとえばＪＰＥＧ、ＪＰＥＧ２０００、ＭＰＥＧ−１、−２、−４、Ｈ．２６１、Ｈ．２６３、Ｈ．２６４など、様々な画像およびビデオ符号化標準のための主要な要素である。多数の波形変換が存在するが、非常に類似した計算公式を使っている。本開示では、ＤＣＴ（離散コサイン変換。「順方向ＤＣＴ」ともいう）および逆ＤＣＴ（ｉＤＣＴ）についてのみ例示的に説明するが、同じ考察を原則的に他の波形変換に適用することができる。
ＤＣＴは、エンコーダにおいて利用される。ＤＣＴは、ピクチャピクセルのグループを係数に変換する。係数の数は、入力データの数と同じである。次いで、逆ＤＣＴが、係数を変換してピクセル値に戻すデコーダにおいて利用される。最も一般的なケースは、８＊８ピクセルの２Ｄピクチャデータを変換／復元するためにＤＣＴ／ｉＤＣＴが適用されるものであり、この場合、ＤＣＴ公式は以下のようになる。
Figure 0005638230
上式で、
８＊８ピクチャデータは、ｆ（ｘ，ｙ）：ｘ＝０，．．．，７かつｙ＝０，．．．，７であり、８＊８ＤＣＴ係数は、Ｆ（ｕ，ｖ）：ｕ＝０，．．．，７かつｖ＝０，．．．，７であり、
Figure 0005638230
は定数である。
逆ＤＣＴ公式は、以下のようになる。
Figure 0005638230
両方の変換（ＤＣＴおよびｉＤＣＴ）は、同じ形の行列乗算で表すことができる。ｉＤＣＴを例として使う。
Ｐｉｃｔ＝Ｂ＊Ｃｏｅｆｆ＊ＢT （３）
全行列が８＊８次元であり、その要素は、以下のようになる。
Figure 0005638230
上式で、
Ｂ＝［ｂ0 ｂ1．．．ｂ7］とすると、以下の等価行列表現を得る。
Figure 0005638230
または、Ｍi,j＝ｂiｂj Tとすると、以下を得る。
Figure 0005638230
ＤＣＴおよびｉＤＣＴはとても重要なので、異なるプラットフォームにおいていくつかの種類のソフトウェア／ハードウェア実装がある。既存のＧＰＵベースの実現は、式３またはＪＰＥＧ ＡＮＮ高速アルゴリズムに基づく（非特許文献１）。両方のタイプが、最適化ＣＰＵ実装に匹敵する性能を達成することができ、第１のタイプは（非特許文献１）、定常的メモリアクセスのおかげで、第２のタイプより高い性能を有する。もう１つの提案は（非特許文献２）、式５に基づくＧＰＵ実装であり、効率的ＧＰＵ解決法となる。ただし、この実装には依然として、何らかの短所がある。すなわち、全Ｍ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 （６）
図１５は、図３に示すものと同様の、ＣＵＤＡベースのビデオ復号システムを使用する、例示的なビデオ復号手順の改良を示す。ただし、いくつかのカーネルにあるタスクは、１つのカーネルにパックされる。特に、図１５に示す実施形態は、残差ピクチャバッファを持たない。代わりに、全ＧＰＵタスク（ＩＱ、波形変換、およびＭＣ）が一緒に実施され、そうすることによって有利には、中間格納が必要なくなり、残差ピクチャバッファのグローバル記憶空間が必要とされなくなる。
図１６は、図４と同様に、ＣＵＤＡベースのビデオ復号システムを使用する、対応して改良された例示的なビデオ復号手順を示す。図１５に示す実施形態によると、ＧＰＵタスク（逆量子化ＩＱ、波形変換、およびＭＣ）は、単一のカーネル３１４ａ中で実施される。したがって、残差ピクチャバッファ用のグローバル記憶空間を節約することができる。
本発明は、任意の１つまたは複数のＣＰＵおよび１つまたは複数のＣＵＤＡベースのＧＰＵを使って実装することができる。ただし、グラフィックス処理ユニット（ＧＰＵ）の１つまたは複数、あるいは全部を、ＧＰＵネイティブ命令とプログラミング言語との間のアプリケーションプログラミングインタフェース（ＡＰＩ）に基づいて操作することもできる。本発明は、１つまたは複数のＧＰＵおよびＣＰＵにタスクを割り当てるソフトウェアで実装することができる。このようなソフトウェアはしばしば、光ディスクなどのデータキャリア上に格納され分散される。本発明の一態様によると、コンピュータ可読媒体は、方法クレームの一項に開示した方法をコンピュータに実施させる命令を格納している。本発明の別の態様によると、製造品は、マシンによって実行されると、方法クレームの一項に開示した方法を含む動作をマシンに実施させる命令を提供するマシン読取り可能媒体を含む。
さらに、本発明は、たとえばＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６４など、他のビデオ標準のビデオシーケンスの復号に適用することもできる。
たとえばデジタルＴＶ（ケーブル、衛星、および地上波放送）、ビデオオンデマンド、デジタル多用途ディスク（ＤＶＤ）、パーソナルコンピューティング、カード支払い、テストおよび測定など、ＴＶ品質デジタルビデオ／オーディオアプリケーションにおいて広く用いられるビデオコーデックにおいて、デコーダを使うことができる。
本発明は、純粋に例として説明され、本発明の範囲から逸脱することなく、細部の修正を行うことができることが理解されよう。
説明ならびに（適切な場合は）特許請求の範囲および図面において開示した各特徴は、それぞれ独立に実現することも、どのように適切に組み合わせて実現することもできる。これらの特徴は、適切な場合、ハードウェア、ソフトウェア、またはこの２つの組合せで実装することができる。接続は、適用可能な場合、必ずしも直接または専用接続でなくても、無線接続または有線接続として実装することができる。特許請求の範囲に現れる参照番号は、例示のために過ぎず、請求項の範囲に対して限定的効果をもつものではない。
本発明は以下の態様を含む。
（付記１）
ＣＰＵおよびＧＰＵを備えたハードウェアアーキテクチャ上で、符号化されたビデオデータを復号する方法であって、前記ＧＰＵは、グローバルバッファである第１のバッファおよびテクスチャバッファである第２のバッファを有し、
前記ＣＰＵ上で、前記符号化されたビデオのヘッダおよびマクロブロックを復号するステップであって、復号されたピクチャデータが取得されるステップと、
前記復号されたピクチャデータに対して、任意選択で逆量子化を実施するステップと、
前記復号されたピクチャデータまたは前記逆量子化されたピクチャデータを、前記ＧＰＵの前記グローバルバッファに転送するステップとを備え、
前記ＧＰＵ上で実施される、
前記任意選択の逆量子化が前記ＣＰＵ上で実施されていない場合、前記転送されたデータを逆量子化するステップと、
前記逆量子化されたデータを波形変換するステップと、
動き補償を実施するステップであって、復元されたピクチャデータが取得され、１つのピクチャブロック中の１行にある全ピクセルを処理するのに１つのスレッドが使われ、一定数のピクチャブロックを処理するのに１つのスレッドブロックが使われるステップと、
前記復元されたピクチャデータを前記ＧＰＵの前記グローバルバッファにバッファリングするステップと、
前記復号されたピクチャデータが少なくとももう１つのピクチャを復号する参照として使われるかどうか判定し、参照として使われる場合、前記復号されたピクチャデータを前記グローバルバッファから前記テクスチャバッファにコピーするステップと、
前記復元ピクチャデータを前記グローバルまたはテクスチャバッファからディスプレイに転送するステップと
をさらに備えることを特徴とする方法。
（付記２）
前記ＧＰＵ上で実施される逆量子化する前記ステップ、波形変換する前記ステップおよび動き補償を実施する前記ステップは、スレッド中で処理され、スレッドは、前記テクスチャバッファへの読取り専用アクセス、および前記グローバルバッファへの読出し書込みアクセスを有することを特徴とする付記１に記載の方法。
（付記３）
動き補償を実施する前記ステップにおいて、直前ピクチャからの参照データは、前記テクスチャバッファから読み出されることを特徴とする付記１または２に記載の方法。
（付記４）
前記ピクチャデータは、複数の色空間フォーマットのうち１つのフォーマットの輝度および彩度成分（ＹＵＶ）を含み、前記ＧＰＵは、少なくとも２つの並列データ層に対して作用し、
前記ピクチャデータの前記色空間フォーマットを決定するステップと、
前記決定された色空間フォーマットに依存して、第１の色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を単一のデータ層に一緒に格納し処理し、異なる色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を２通りの別個のデータ層に格納し処理するステップと
をさらに備えることを特徴とする付記１乃至３いずれかに記載の方法。
（付記５）
前記ＧＰＵは少なくとも３つの並列データ層に対して作用し、残差ピクチャの前記輝度および彩度データは、３通りの別個のデータ層において格納され処理されることを特徴とする付記４に記載の方法。
（付記６）
前記ＧＰＵは、ＣＵＤＡアーキテクチャを用いることを特徴とする付記１乃至５いずれかに記載の方法。
（付記７）
前記ＧＰＵは、ＧＰＵネイティブ命令とプログラミング言語との間のアプリケーションプログラミングインタフェース（ＡＰＩ）に基づいて動作されることを特徴とする付記１乃至５いずれかに記載の方法。
（付記８）
波形変換を実施する前記ステップで、非ゼロとなるような係数のみが、そのそれぞれの係数行列インデックスとともに格納されることを特徴とする付記１乃至７いずれかに記載の方法。
（付記９）
波形変換をする前記ステップは、１つまたは複数のスレッド中で処理され、前記スレッドは、少なくともアドレスおよび長さ値を含む、一定長のデータセットを入力データとして受け取り、前記アドレスは、前記スレッド向けの実際の入力データが格納される前記グローバルバッファ内部の記憶場所をポイントし、前記長さは、前記スレッドに関する格納された入力データの量を示すことを特徴とする付記１乃至８いずれかに記載の方法。
（付記１０）
逆量子化、波形変換および動き補償の前記ステップは、共通スレッド中で一緒に処理されることを特徴とする付記１乃至９いずれかに記載の方法。
（付記１１）
波形変換ブロックを初期化するステップをさらに備え、前記初期化は、
残差ピクチャバッファを割り振るステップであって、残差ピクチャデータはグローバルメモリに割り振られるステップと、
ｉＤＣＴ算出のために定数行列を準備するステップと
を含むことを特徴とする付記１乃至１０いずれかに記載の方法。
（付記１２）
必要とされる波形変換に、どの定数行列が適しているか決定するステップと、
前記決定された定数行列を選択するステップと、
前記選択された行列に切り換えるステップと
をさらに備えることを特徴とする付記１１に記載の方法。
（付記１３）
現在の残差ピクチャのデータブロックの数を決定するステップと、
利用されるビデオ符号化標準に従って、データブロックの数がパラメータＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの整数倍になるまで、偽データブロックを追加するステップと
をさらに備えることを特徴とする付記１乃至１２いずれかに記載の方法。
（付記１４）
動き補償の前記ステップで、スレッド中で必要とされる全残差ピクチャデータは、１つの構造にパックされ、一度の値割当て動作で読み出されることを特徴とする付記１乃至１３いずれかに記載の方法。
（付記１５）
付記１乃至１４いずれかに記載の方法を実施するのに適していることを特徴とする機器。
（付記１６）
付記１乃至１４いずれかに記載の方法をコンピュータに実施させる命令を格納したことを特徴とするコンピュータ読取り可能媒体。

Claims (14)

  1. ＣＰＵおよびＧＰＵを備えたハードウェアアーキテクチャ上で、符号化されたビデオデータを復号する方法であって、前記ＧＰＵは、グローバルバッファである第１のバッファおよびテクスチャバッファである第２のバッファを有し、
    前記ＣＰＵ上で、前記符号化されたビデオのヘッダおよびマクロブロックを復号するステップであって、復号されたピクチャデータが取得される、ステップと、
    前記復号されたピクチャデータに対して、任意選択で逆量子化を実施するステップと、
    前記復号されたピクチャデータまたは前記逆量子化されたピクチャデータを、前記ＧＰＵの前記グローバルバッファに転送するステップと、
    を備え、
    前記ＧＰＵ上で実施される、
    前記任意選択の逆量子化が前記ＣＰＵ上で実施されていない場合、前記転送されたデータを逆量子化するステップと、
    前記逆量子化されたデータを波形変換するステップと、
    動き補償を実施するステップであって、復元されたピクチャデータが取得され、一定数のピクチャブロックを処理するのに１つのスレッドブロックが使われ、前記スレッドブロックの１つのスレッドが前記一定数のピクチャブロックにおけるピクセルの行における全てのピクセルを処理するために使用され、前記スレッドにおいて必要な全ての残差ピクチャデータは１つの構造にパックされ、一度の値割り当て動作で読み出される、ステップと、
    前記復元されたピクチャデータを前記ＧＰＵの前記グローバルバッファにバッファリングするステップと、
    前記復号されたピクチャデータが少なくとももう１つのピクチャを復号する参照として使われるかどうか判定し、参照として使われる場合、前記復号されたピクチャデータを前記グローバルバッファから前記テクスチャバッファにコピーするステップと、
    前記復元ピクチャデータを前記グローバルバッファまたはテクスチャバッファからディスプレイに転送するステップと、
    をさらに備える、前記方法。
  2. 前記ＧＰＵ上で実施される逆量子化する前記ステップ、波形変換する前記ステップおよび動き補償を実施する前記ステップは、スレッド中で処理され、スレッドは、前記テクスチャバッファへの読取り専用アクセス、および前記グローバルバッファへの読出し書込みアクセスを有する、請求項１に記載の方法。
  3. 動き補償を実施する前記ステップにおいて、直前ピクチャからの参照データは、前記テクスチャバッファから読み出される、請求項１または２に記載の方法。
  4. 前記ピクチャデータは、複数の色空間フォーマットのうち１つのフォーマットの輝度および彩度成分（ＹＵＶ）を含み、前記ＧＰＵは、少なくとも２つの並列データ層に対して作用し、
    前記ピクチャデータの前記色空間フォーマットを決定するステップと、
    前記決定された色空間フォーマットに依存して、第１の色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を単一のデータ層に一緒に格納し処理し、異なる色空間フォーマットが決定された場合、輝度データ（Ｙ）および彩度データ（ＵＶ）を２通りの異なる別個のデータ層に格納し処理するステップと、
    をさらに備える、請求項１乃至３いずれかに記載の方法。
  5. 前記ＧＰＵは少なくとも３つの並列データ層に対して作用し、残差ピクチャの前記輝度および彩度データは、３通りの異なる別個のデータ層において格納され処理される、請求項４に記載の方法。
  6. 前記ＧＰＵは、ＧＰＵネイティブ命令とプログラミング言語との間のアプリケーションプログラミングインタフェース（ＡＰＩ）に基づいて動作される、請求項１乃至５いずれかに記載の方法。
  7. 波形変換を実施する前記ステップで、非ゼロとなるような係数のみが、そのそれぞれの係数行列インデックスとともに格納される、請求項１乃至６いずれかに記載の方法。
  8. 波形変換をする前記ステップは、１つまたは複数のスレッド中で処理され、前記スレッドは、少なくともアドレスおよび長さ値を含む、一定長のデータセットを入力データとして受け取り、前記アドレスは、前記スレッド向けの実際の入力データが格納される前記グローバルバッファ内部の記憶場所をポイントし、前記長さは、前記スレッドに関する格納された入力データの量を示す、請求項１乃至７いずれかに記載の方法。
  9. 逆量子化、波形変換および動き補償の前記ステップは、単一のカーネル中で一緒に処理される、請求項１乃至８いずれかに記載の方法。
  10. 波形変換ブロックを初期化するステップをさらに備え、前記初期化は、
    残差ピクチャバッファを割り振るステップであって、残差ピクチャデータは前記グローバルバッファに割り振られる、ステップと、
    ｉＤＣＴ算出のために定数行列を準備するステップと、
    を含む、請求項１乃至９いずれかに記載の方法。
  11. 必要とされる波形変換に、どの定数行列が適しているか決定するステップと、
    前記決定された定数行列を選択するステップと、
    前記選択された行列に切り換えるステップと、
    をさらに備える、請求項１０に記載の方法。
  12. 現在の残差ピクチャのデータブロックの数を決定するステップと、
    利用されるビデオ符号化標準に従って、データブロックの数がパラメータＲＥＳＩＤＵＡＬ＿ＢＬＯＣＫ＿ＢＡＳＥ＿ＮＵＭの整数倍になるまで、偽データブロックを追加するステップと、
    をさらに備える、請求項１乃至１１いずれかに記載の方法。
  13. 請求項１乃至１２いずれかに記載の方法を実施するための機器。
  14. 請求項１乃至１２いずれかに記載の方法をコンピュータに実施させる命令を格納したコンピュータ読取り可能な記録媒体。
JP2009268740A 2008-11-28 2009-11-26 グラフィックス処理ユニットによってサポートされるビデオを復号する方法、機器およびコンピュータ読取り可能な記録媒体 Expired - Fee Related JP5638230B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08305871A EP2192780A1 (en) 2008-11-28 2008-11-28 Method for video decoding supported by Graphics Processing Unit
EP08305871.9 2008-11-28

Publications (2)

Publication Number Publication Date
JP2010130696A JP2010130696A (ja) 2010-06-10
JP5638230B2 true JP5638230B2 (ja) 2014-12-10

Family

ID=40711715

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009268740A Expired - Fee Related JP5638230B2 (ja) 2008-11-28 2009-11-26 グラフィックス処理ユニットによってサポートされるビデオを復号する方法、機器およびコンピュータ読取り可能な記録媒体

Country Status (4)

Country Link
US (1) US8542745B2 (ja)
EP (2) EP2192780A1 (ja)
JP (1) JP5638230B2 (ja)
CN (1) CN101754013B (ja)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010244095A (ja) * 2009-04-01 2010-10-28 Seiko Epson Corp データ処理装置、印刷システムおよびプログラム
US9354944B2 (en) * 2009-07-27 2016-05-31 Advanced Micro Devices, Inc. Mapping processing logic having data-parallel threads across processors
US20110194606A1 (en) * 2010-02-09 2011-08-11 Cheng-Yu Hsieh Memory management method and related memory apparatus
KR101373814B1 (ko) * 2010-07-31 2014-03-18 엠앤케이홀딩스 주식회사 예측 블록 생성 장치
US20130148717A1 (en) * 2010-08-26 2013-06-13 Freescale Semiconductor, Inc. Video processing system and method for parallel processing of video data
CN102158694B (zh) * 2010-12-01 2012-12-26 航天恒星科技有限公司 一种基于gpu的遥感图像解压缩方法
CN102023838B (zh) * 2010-12-17 2012-08-15 浪潮(北京)电子信息产业有限公司 Mrc图片文件的处理方法及系统
DE102011075261A1 (de) * 2011-05-04 2012-11-08 Robert Bosch Gmbh Verfahren zum Bearbeiten von Videodaten und eine Anordnung zur Durchführung des Verfahrens
CN102622723A (zh) * 2011-05-25 2012-08-01 上海大学 基于cuda及边缘检测的图像插值
US20130021350A1 (en) * 2011-07-19 2013-01-24 Advanced Micro Devices, Inc. Apparatus and method for decoding using coefficient compression
TWM430773U (en) * 2011-11-03 2012-06-01 Curelan Technology Co Ltd A device with high-speed filtering efficiency
CN102404576A (zh) * 2011-11-30 2012-04-04 国云科技股份有限公司 云终端解码器及其负载均衡算法和gpu的解码算法
CN102497550A (zh) * 2011-12-05 2012-06-13 南京大学 H.264编码中运动补偿插值的并行加速方法及装置
BR112014015171B1 (pt) * 2011-12-22 2020-10-06 Samsung Electronics Co., Ltd Aparelho de decodificação de vídeo
CN102547289B (zh) * 2012-01-17 2015-01-28 西安电子科技大学 基于gpu并行实现的快速运动估计方法
US8689233B2 (en) * 2012-01-25 2014-04-01 International Business Machines Corporation Distributed function execution for hybrid systems
CN104396244B (zh) * 2012-04-16 2019-08-09 诺基亚技术有限公司 用于视频编码和解码的装置、方法和计算机可读存储介质
CN103186366B (zh) * 2012-07-12 2017-05-03 深圳市康必达控制技术有限公司 基于cuda并行计算实现电力系统电磁暂态实时仿真测试方法
CN102789500B (zh) * 2012-07-17 2014-06-04 南京特雷多信息科技有限公司 一种音频比较方法
CN103108186A (zh) * 2013-02-21 2013-05-15 中国对外翻译出版有限公司 实现视频高清传播的方法
US10776532B2 (en) 2013-02-22 2020-09-15 Nvidia Corporation Modified effective mass for parallel rigid body simulation
US10614257B2 (en) 2013-02-22 2020-04-07 Navidia Corporation Parallel linear complementarity solver for rigid body dynamics
US20140257769A1 (en) * 2013-03-06 2014-09-11 Nvidia Corporation Parallel algorithm for molecular dynamics simulation
US9311721B1 (en) * 2013-04-04 2016-04-12 Sandia Corporation Graphics processing unit-assisted lossless decompression
JP6186429B2 (ja) 2013-04-12 2017-08-23 株式会社スクウェア・エニックス・ホールディングス 情報処理装置、制御方法、プログラム、及び記録媒体
US20140320592A1 (en) * 2013-04-30 2014-10-30 Microsoft Corporation Virtual Video Camera
US9078001B2 (en) * 2013-06-18 2015-07-07 Texas Instruments Incorporated Efficient bit-plane decoding algorithm
US9565454B2 (en) 2013-06-24 2017-02-07 Microsoft Technology Licensing, Llc Picture referencing control for video decoding using a graphics processor
WO2015021587A1 (en) * 2013-08-12 2015-02-19 Intel Corporation Techniques for low power image compression and display
US9405575B2 (en) 2013-09-09 2016-08-02 Apple Inc. Use of multi-thread hardware for efficient sampling
US9799087B2 (en) 2013-09-09 2017-10-24 Apple Inc. Shader program profiler
US9467399B2 (en) * 2013-10-17 2016-10-11 Marvell World Trade Ltd. Processing concurrency in a network device
US20150228106A1 (en) * 2014-02-13 2015-08-13 Vixs Systems Inc. Low latency video texture mapping via tight integration of codec engine with 3d graphics engine
US20150237356A1 (en) * 2014-02-18 2015-08-20 Microsoft Corporation Host encoder for hardware-accelerated video encoding
US9852522B2 (en) * 2014-03-17 2017-12-26 Sony Interactive Entertainment Inc. Image decoder, graphics processing system, image decoding method, and graphics processing method
CN105338358B (zh) * 2014-07-25 2018-12-28 阿里巴巴集团控股有限公司 对图像进行解码的方法及装置
CN105472384B (zh) * 2014-07-29 2018-12-07 浙江大华技术股份有限公司 一种视频图像编码方法和装置
US9674540B2 (en) 2014-09-25 2017-06-06 Microsoft Technology Licensing, Llc Processing parameters for operations on blocks while decoding images
CN105635740B (zh) * 2014-10-27 2019-05-28 阿里巴巴集团控股有限公司 对图像进行解码的方法及装置
CN105243351A (zh) * 2015-10-09 2016-01-13 宁波萨瑞通讯有限公司 一种基于移动终端的扫码方法
US10559112B2 (en) * 2016-03-11 2020-02-11 Intel Corporation Hybrid mechanism for efficient rendering of graphics images in computing environments
CN105843692A (zh) * 2016-03-18 2016-08-10 国家电网公司 一种异构计算系统
US10237566B2 (en) 2016-04-01 2019-03-19 Microsoft Technology Licensing, Llc Video decoding using point sprites
US10575007B2 (en) * 2016-04-12 2020-02-25 Microsoft Technology Licensing, Llc Efficient decoding and rendering of blocks in a graphics pipeline
US10157480B2 (en) 2016-06-24 2018-12-18 Microsoft Technology Licensing, Llc Efficient decoding and rendering of inter-coded blocks in a graphics pipeline
US10387991B2 (en) * 2016-07-01 2019-08-20 Intel Corporation Method and apparatus for frame buffer compression
US11197010B2 (en) 2016-10-07 2021-12-07 Microsoft Technology Licensing, Llc Browser-based video decoder using multiple CPU threads
CN106645868A (zh) * 2016-11-16 2017-05-10 南方电网科学研究院有限责任公司 一种短路电流的扫描方法及装置
CN106791861B (zh) * 2016-12-20 2020-04-07 杭州当虹科技股份有限公司 一种基于CUDA架构的DNxHD VLC编码方法
CN107135392B (zh) * 2017-04-21 2019-12-10 西安电子科技大学 基于异步模式的hevc运动搜索并行方法
US10872394B2 (en) * 2017-04-27 2020-12-22 Daegu Gyeongbuk Institute Of Science And Technology Frequent pattern mining method and apparatus
CN107231558B (zh) * 2017-05-23 2019-10-22 江苏火米互动科技有限公司 一种基于cuda的h.264并行编码器的实现方法
US10310830B2 (en) 2017-06-02 2019-06-04 Apple Inc. Shader profiler
US10614541B2 (en) 2017-06-29 2020-04-07 Nvidia Corporation Hybrid, scalable CPU/GPU rigid body pipeline
JP6377222B2 (ja) * 2017-07-31 2018-08-22 株式会社スクウェア・エニックス・ホールディングス 情報処理装置、制御方法、プログラム、及び記録媒体
CN107809643B (zh) * 2017-11-13 2020-11-20 苏州浪潮智能科技有限公司 一种图像的解码方法、装置及介质
CN107888924A (zh) * 2017-11-30 2018-04-06 江西洪都航空工业集团有限责任公司 一种无损视频加速分析方法
CN108965814A (zh) * 2018-07-27 2018-12-07 高新兴科技集团股份有限公司 一种基于cuda加速技术的视频混合解码渲染方法
CN111147926B (zh) * 2018-11-02 2022-05-06 杭州海康威视数字技术股份有限公司 一种数据转码方法及装置
CN109451313A (zh) * 2018-12-14 2019-03-08 深圳市网心科技有限公司 一种视频编码方法、系统及电子设备和存储介质
CN109739559A (zh) * 2019-01-08 2019-05-10 武汉中旗生物医疗电子有限公司 Cuda异构平台中的数据处理方法及设备
CN112019847A (zh) * 2019-05-28 2020-12-01 杭州海康威视数字技术股份有限公司 解码方法及电子设备
CN111402380B (zh) * 2020-03-12 2023-06-30 杭州小影创新科技股份有限公司 一种gpu压缩纹理处理方法
CN113518227B (zh) * 2020-04-09 2023-02-10 于江鸿 数据处理的方法和系统
CN112565603B (zh) * 2020-11-30 2022-05-10 维沃移动通信有限公司 图像处理方法、装置及电子设备
CN113553103B (zh) * 2021-06-03 2022-09-23 中国人民解放军战略支援部队信息工程大学 基于cpu+gpu异构处理平台的多核并行调度方法
CN113507610B (zh) * 2021-06-07 2023-03-24 翱捷智能科技(上海)有限公司 一种主从系统多路并发解码jpg图像的方法及装置
CN113538204A (zh) * 2021-06-30 2021-10-22 上海联影医疗科技股份有限公司 图像数据处理方法、装置、计算机设备和存储介质
US12062202B2 (en) 2021-09-24 2024-08-13 Argo AI, LLC Visual localization against a prior map
CN116483587B (zh) * 2023-06-21 2023-09-08 湖南马栏山视频先进技术研究院有限公司 一种基于图像分割的视频超分并行方法、服务器及介质
CN117440166B (zh) * 2023-09-19 2024-04-26 北京麟卓信息科技有限公司 基于内存访问特征分析的视频编码和解码方式检测方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7646817B2 (en) 2003-03-28 2010-01-12 Microsoft Corporation Accelerating video decoding using a graphics processing unit
US7558428B2 (en) 2004-09-13 2009-07-07 Microsoft Corporation Accelerated video encoding using a graphics processing unit
WO2007148355A1 (en) * 2006-06-22 2007-12-27 Stmicroelectronics S.R.L. A method and system for video decoding by means of a graphic pipeline, computer program product therefor

Also Published As

Publication number Publication date
JP2010130696A (ja) 2010-06-10
EP2192781A3 (en) 2015-07-08
CN101754013B (zh) 2014-02-19
US8542745B2 (en) 2013-09-24
CN101754013A (zh) 2010-06-23
EP2192780A1 (en) 2010-06-02
EP2192781A2 (en) 2010-06-02
US20100135418A1 (en) 2010-06-03

Similar Documents

Publication Publication Date Title
JP5638230B2 (ja) グラフィックス処理ユニットによってサポートされるビデオを復号する方法、機器およびコンピュータ読取り可能な記録媒体
US20140153635A1 (en) Method, computer program product, and system for multi-threaded video encoding
US11863769B2 (en) Bandwidth saving architecture for scalable video coding
US8106921B2 (en) Differential encoding using a 3d graphics processor
US7813570B2 (en) Accelerated video encoding using a graphics processing unit
Shen et al. Accelerate video decoding with generic GPU
CN101123723A (zh) 基于图形处理器的数字视频解码方法
US20140028703A1 (en) Render-assisted compression for remote graphics
WO2016153691A1 (en) Compaction for memory hierarchies
US20080301681A1 (en) Information processing apparatus, information processing method and computer program
Pieters et al. Motion estimation for H. 264/AVC on multiple GPUs using NVIDIA CUDA
Pieters et al. Performance evaluation of H. 264/AVC decoding and visualization using the GPU
Deng et al. GPU-based real-time decoding technique for high-definition videos
Hirvonen et al. H. 263 video decoding on programmable graphics hardware
Sun et al. CFU: Multi-purpose configurable filtering unit for mobile multimedia applications on graphics hardware
Jo et al. Flexible multi-core platform for a multiple-format video decoder
Young et al. Image processing and video algorithms with CUDA
de Medeiros Video coding on multicore graphics processors (GPUs)
Montero et al. Optimising lossless stages in a GPU-based MPEG encoder
Seitner et al. A high-level simulator for the H. 264/AVC decoding process in multi-core systems
Krajcevski Improved encoding for compressed textures
Pau et al. H. 264 video decoding compatible with Vector Graphics
Pastrnaka et al. Adaptive decoding of MPEG-4 sprites for memory-constrained embedded systems
Nguyen-Phuc et al. VLSI architecture of a MPEG-4 visual renderer
Van Rijsselbergen et al. GPU-driven recombination and transformation of YCoCg-R video samples

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20121004

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20121004

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131120

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131217

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140317

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140924

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141022

R150 Certificate of patent or registration of utility model

Ref document number: 5638230

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees