JP7135067B2 - ゲーム－生成された動きベクトルのためのシステムおよび方法 - Google Patents

Description

本出願は、２０１７年４月２１日に出願された米国仮出願第６２／４８８，５２６号および２０１７年１２月８日に出願された米国仮出願第６２／５９６，３２５号の利益を主張する。

サーバ側のゲームがクライアント側のプレイヤによって制御されるリモートゲーミングアプリケーションは、既存のまたはカスタマイズされたエンコーダを使用し、リアルタイムで３Ｄグラフィックスエンジン（ｇｒａｐｈｉｃｓ ｅｎｇｉｎｅ）からのビデオ出力をエンコードすることを試みていた。しかし、ビデオゲームの会話形式特性、特に、ビデオ出力とプレイヤ入力との間のプレイヤフィードバックルーフ（ｐｌａｙｅｒ ｆｅｅｄｂａｃｋ ｌｏｏｐ）は、ゲームビデオストリーミングの待機時間（ｌａｔｅｎｃｙ）が一般的なビデオストリーミングよりも極めて長い。既存のビデオコーディング方法は、エンコード時間を減らすために計算能力（ｃｏｍｐｕｔａｔｉｏｎａｌ ｐｏｗｅｒ）を交換することができるが、その他の方法はない。エンコードプロセスをビデオレンダリングプロセスに統合するための新たな方法は、エンコード時間を著しく減らすことはできるが、計算能力を低め、エンコードされたビデオの品質を改善し、既存のハードウェアデバイスの相互運用性を維持するためにオリジナルビットストリームデータ形式（ｏｒｉｇｉｎａｌ ｂｉｔｓｔｒｅａｍ ｄａｔａ ｆｏｒｍａｔ）を維持するようになる。

既存のビデオコーディング標準は、ビデオエンコード時間、サイズ、または品質を向上させるために、イメージシーケンスに含まれる色相および時間情報だけを有していた。ＭＰＥＧ標準シリーズのようないくつかのコーディング標準は、ビデオに含まれるカラーデータを基盤としてオブジェクト移動（ｏｂｊｅｃｔ ｍｏｖｅｍｅｎｔ）を近似化するために、計算集約的ブロック基盤の動き推定方法を利用している。このようなブロック基盤の動き推定方法は、エンコードされたビデオのサイズを大幅に減らすことはできるが、リアルタイムビデオストリーミング環境では相当な待機時間を発生させる原因になっている。
エンコードプロセスをビデオレンダリングプロセスに統合させることは、エンコード向上のために活用される追加のデータソースへのアクセス（ａｃｃｅｓｓ）を提供する。例えば、ゲームエンジンに含まれるようないくつかの３Ｄグラフィックスエンジンは、各ビデオフレームで各ピクセルの移動を完全に説明する動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を生成することができる。最終的にレンダリングされたフレームを提供し、適切にフォーマット化された（ｆｏｒｍａｔｔｅｄ）動きベクトルデータをエンコーダに注入することにより、ビデオエンコーダでは、最も計算が複雑でありながら時間消耗のある段階である動き推定が各インタ（ｉｎｔｅｒ）フレームごとにスキップ（ｓｋｉｐ）されるようになる。これに加え、グラフィックスエンジンによって供給される動きベクトルは、ブロック基盤の動き推定アルゴリズムによって近似化されたものよりも正確であるはずであり、これはエンコードされたビデオ品質の向上に繋がるであろう。

このような２つのドメイン（ｄｏｍａｉｎ）、すなわち、ビデオエンコードおよびリアルタイムグラフィックスレンダリングは、分離されて独立的に運営されることが一般的であった。それぞれの長所を活用するために、グラフィックスエンジンとエンコーダを統合することにより、エンコードの待機時間に極めて左右されるストリーミングアプリケーションの支援を十分に短縮することが可能となった。

本発明のこれらの利点および他の利点は、技術の欠点を考慮しながら以下で明確に説明する。

例えば、米国特許公開出願第２０１５／０２２８１０６ Ａ１号（「‘１０６公開」）では、ビデオイメージのデコードされたブロックのシーケンスを生成するためのビデオデータデコードに関する技術を開示している。この技術は、デコードされたブロックがコーデックエンジン（ｃｏｄｅｃ ｅｎｇｉｎｅ）によって生成されるとき、ビデオイメージのそれぞれのデコードされたブロックを幾何学的（ｇｅｏｍｅｔｒｉｃ）表面の対応する多角形（ｐｏｌｙｇｏｎ）に対する別途のテクスチャ（ｔｅｘｔｕｒｅ）として使用することができるようにする。‘１０６公開技術は、マッピングされるビデオイメージを生成するために、エンコードされたビデオデータをデコードするコーデックエンジンと、ビデオイメージの幾何学的表面へのテクスチャマッピングを実行することによって部分的にディスプレイピクチャ（ｄｉｓｐｌａｙ ｐｉｃｔｕｒｅ）をレンダリングする３Ｄグラフィックスエンジンとの統合を説明している。しかし、このような技術は、少なくともビデオコーデックエンジンへの注入のために、最終的にレンダリングされたフレームと適切にフォーマット化された動きベクトルデータの両方を提供するグラフィックスエンジンを開示するか使用しないため、本発明に比べて不足であり、したがって、ビデオコーデックエンジンは、リモートクライアントコーディングエンジンにエンコードされたビデオデータを送信する前に動き推定を実行する必要がない。これとは対照的に、本発明のコンピュータ技術に対する改善は、エンコード時間と計算能力の減少と、エンコードされたビデオ品質の向上を提供し、相互運用性を保つためにオリジナルビットストリームデータ形式を維持する。
米国特許公開出願第２０１１／０２６１８８５ Ａ１号（「‘８８５公報」）では、動き推定およびマクロブロック（ｍａｃｒｏ ｂｌｏｃｋ）エンコードの統合による帯域幅減少に関するシステムおよび方法を開示している。このようなシステムにおいて、動き推定は、動きベクトルを含む動き推定関連情報を生成するために、フェッチ（ｆｅｔｃｈｅｄ）ビデオデータを使用して実行されるようになる。このような動きベクトルは、バッファにキャッシュされた（ｃａｓｈｅｄ）対応するビデオデータを使用するが、これは現在のマクロブロックに対応する。言い換えれば、‘８８５公開技術は、少なくともビデオコーデックエンジンへの注入のために、最終的にレンダリングされたフレームと適切にフォーマット化された動きベクトルデータの両方を提供するグラフィックスエンジンを開示するか使用しないため、本発明に比べて不足であり、したがって、ビデオコーデックエンジンは、リモートクライアントコーディングエンジンにエンコードされたビデオデータを送信する前に、いかなる動き推定も実行する必要がない。したがって、‘８８５公報の技術は、エンコード時間と計算能力の減少、および本発明が提供するエンコードされたビデオ品質の向上を提供することができない。

上述したように、このような技術における最新技術に関する説明によって明らであるが、ゲーム環境でのビデオエンコードと関連する現在のコンピュータ技術に対する改善が、本技術分野において必要である。

したがって、本文書で開示する例示的な実施形態は、該当の技術分野の課題を解決するものであって、エンコードされたビデオデータを送信するために、グラフィックスエンジン、ビデオコーデックエンジン、およびリモートクライアントコーディングエンジンを実行するネットワークサーバアーキテクチャを使用することにより、グラフィックスエンジンがビデオコーデックエンジンへの注入のために最終的にレンダリングされたフレームと適切にフォーマット化された動きベクトルデータの両方を提供する、グラフィックス生成のためのシステムおよび方法を提供することを目的とする。

本発明は、ビデオコーデックエンジンがリモートクライアントコーディングエンジンにエンコードされたビデオデータを送信する前に、動き推定を実行する必要がない、グラフィックス生成のためのシステムおよび方法を提供することを他の目的とする。

本発明は、グラフィックスエンジンがピクセルあたり（ｐｅｒ－ｐｉｘｅｌ）の動きベクトルをブロックあたり（ｐｅｒ－ｂｌｏｃｋ）の動きベクトルに変換する、グラフィックス生成のためのシステムおよび方法を提供することを他の目的とする。

本発明は、ピクセルあたりの結果を取得するために、ピクセルあたりの動きベクトルをカメラ速度（ｃａｍｅｒａ ｖｅｌｏｃｉｔｙ）に追加するように、ピクセルあたりの動きベクトルがコンピュータシェーダ（ｃｏｍｐｕｔｅ ｓｈａｄｅｒ）によって生成され、ピクセルあたりの結果は動きベクトルバッファに格納される、グラフィックス生成のためのシステムおよび方法を提供することを他の目的とする。

本発明は、ブロックあたりの動きベクトルデータがクロマサブサンプリングされた（ｃｈｒｏｍａ ｓｕｂｓａｍｐｌｅｄ）ビデオフレームと同時に、グラフィックスエンジンによってビデオエンコードエンジンにリアルタイムで注入される、グラフィックス生成のためのシステムおよび方法を提供することをさらに他の目的とする。

添付の図面は、後述する詳細な説明を参照することでより適切に理解することができるため、本発明の完全な理解およびこれによる多くの利点を容易に得ることができるであろう。

エンコードおよびクライアントへの送信のためにビデオをレンダリングする３Ｄグラフィックスエンジンを示したブロック図である。 ３Ｄグラフィックスエンジンによって生成された動きベクトルの、図４の修正されたエンコードプロセスへの注入による待機時間の減少のために必要な段階を示したフローチャートである。 エンコードエンジンへの注入のために、グラフィックスエンジンで生成されたピクセルあたりの動きベクトルをマクロブロックあたりの動きベクトルに変換する様子を示した図である。 図１で使用されたビデオエンコードプロセスに求められる変更を示したフローチャートである。

図面に示す発明の好ましい実施形態を説明するにあたり、明確化のために、特定の用語に依存することがある。しかし、本発明は、このように選択された特定の用語に限定されることを意図しておらず、それぞれの特定の用語は、類似の目的を達成するために類似の方式で作動するすべての技術的等価物を含むものと理解されなければならない。本発明の好ましい実施形態は、例示の目的として記載されているが、本発明は、図面に具体的に示されていない他の形態によっても実現可能であることが理解されなければならない。

３Ｄグラフィックスエンジンがエンコードされてリアルタイムで送信されるビデオをレンダリングするアプリケーションにおいて、グラフィックスエンジンとエンコーダは、計算時間と計算オーバヘッドを減らすために緊密に結合されることがある。エンコードプロセスのうちでも最も複雑かつ計算集約的な段階である動き推定段階を避けるために、各ビデオフレームに対してグラフィックスエンジンによって既に生成されたピクセルあたりの動きベクトルデータは、ブロックあたりの動きベクトルデータに変換されてコーデックエンジンに注入されてよい。妥当な（ｐｌａｕｓｉｂｌｅ）動きブロー方法のための再構成フィルタを使用するグラフィックスエンジンにおいて、ピクセルあたりの動きベクトルは、各ビデオフレームに対して既に計算されている。ピクセルあたりの動きベクトルからブロックあたりの動きベクトルへの変換は、１６×１６ピクセルの各マクロブロックに対する平均ベクトル（ｍｅａｎ ｖｅｃｔｏｒ）を見つけ出すことによって実行されてよい。変換は３Ｄグラフィックスエンジンで実行されるため、本来の動きベクトルデータの一部が３Ｄグラフィックスエンジンからコーディングエンジンに伝達されなければならない。また、これは、グラフィックスエンジンとコーディングエンジンがメモリを共有しない場合には、メモリ帯域幅の消費を減らすために役立つであろう。ブロックあたりの動きベクトルは、エンコードプロセスの残りを大きく修正することなく、動き推定段階を完全にスキップしてコーデックエンジンに注入される。

図１～４は、３Ｄグラフィックスエンジンがビデオフレームをレンダリングするプロセスでなされる動きベクトルデータを生成するビデオストリーミングアプリケーションにおけるビデオエンコードの改善のための例示的な技術を示している。

図１は、ビデオがリモートクライアント１１６への送信のためにレンダリングされてエンコードされるシステムの例を示している。いくつかのサーバアーキテクチャ１２０のメモリ１０６で実行される３Ｄグラフィックスエンジン１００は、ビデオおよびレンダリングされたビデオフレームに対する追加の（ｓｕｐｐｌｅｍｅｎｔａｌ）動きベクトル情報をクライアントコンピュータシステム１１６に送信するためにエンコードされたビットストリーム１０８を生成するコーデックエンジン（本文書ではコーデックまたはエンコーダとする）１０２に伝達する。サーババアーキテクチャ１２０は、グラフィックスエンジンとコーデックエンジンの両方の機能を支援することのできるハードウェアまたはソフトウェアのいずれかの組み合わせである。与えられた例において、グラフィックスエンジン１００は、例えば、コンピュータ読み取り可能なメモリ１０６にロードされるビデオゲームソフトウェア１０４を実行するＧＰＵとして実現されてよく、コーデックエンジン１０２は、ビデオエンコードソフトウェアを実行するＣＰＵとして実現されてよい。コーディングエンジン１０２は、リモートコーディングエンジン（コーデック）１１０を含むいくつかのリモートクライアントコンピュータシステム１１６への送信のためのエンコードされたビデオデータ１０８を生成し、リモートコーディングエンジン（コーデック）１１０は、ディスプレイコントローラ１１２によって駆動されるディスプレイ１１４での再生のためのビットストリームをデコードする。リモートクライアントコンピュータシステム１１６は、エンコードされたビットストリーム１０８のデコードおよびディスプレイを可能にするハードウェア、デバイス、またはソフトウェアのいずれかの組み合わせである。

図２は、ビデオエンコードプロセスでレンダリングプロセスからの既存の追加データを再使用することによって迅速なエンコード時間を達成するために求められる段階を示している。段階２０２において、追加データは、先ず、サーバ１２０に位置するグラフィックスエンジン１００の正常動作の特徴として生成されなければならない。ＧＰＵがさらに強力かつ普遍的になることにより、リアルタイムのピクセルあたりの動きベクトルの生成は、現在のビデオゲームエンジンの共通の特徴となった。３Ｄシーン（ｓｃｅｎｅ）から２Ｄビデオフレームのレンダリングの間、３Ｄグラフィックスエンジンは、以後のポストプロセスパス（ｐａｓｓ）のための入力として使用されるように、カラー生成プロセス中に補助（ａｎｃｉｌｌａｒｙ）出力を生成してよい。補助出力は、蓄積、色相、または速度バッファに対して記録された情報、それぞれのピクセルの深さ、ピクセルカラー、およびピクセル移動に関する情報を一時格納するために割り当てられた３つのメモリ位置を含んでよい。

一般的に使用される、妥当な（ｐｌａｕｓｉｂｌｅ）動きブローのための再構成フィルタと呼ばれる動きブローの実現において、速度バッファからのピクセルあたりの速度は、先ず、より少ない数のタイル（ｔｉｌｅ）にダウンサンプリングされるようになるが、ここで、各タイルは、ピクセルグループでの最大速度と仮定する。この後、タイルは、蓄積バッファでピクセルあたりの深さを利用してマスキングされ（ｍａｓｋｅｄ）、その結果が動きブローを生成するためにカラーバッファにおいてピクセルあたりのカラーに適用される。正確度（ｆｉｄｅｌｉｔｙ）、性能、またはこの両方を向上させる再構成フィルタ方法に対する多くの変形が存在するが、その概念は類似しており、速度バッファは、２つの隣接するフレーム間のピクセルあたりの動きを含む。「速度」、グラフィックスエンジン技術で使用される用語であって、「動きベクトル」はビデオエンコード技術で使用される用語であるが、この用語は機能的に等しく、ピクセルあたりの速度はピクセルあたりの動きベクトルと同じ意味をもつ。速度バッファは、ビデオエンコードプロセスで再使用されるピクセルあたりの動きベクトルの形態で追加データを含む。

段階２０４で、サーバ１２０に位置するグラフィックスエンジン１００は、エンコードに使用されるマクロブロックサイズを基盤に、ピクセルあたりの動きベクトルをブロックあたり動きのベクトルに変換する。Ｈ．２６４コーデックは、デフォルト（ｄｅｆａｕｌｔ）で１６×１６ピクセルマクロブロックを使用し、さらに細分化するためのオプション（ｏｐｔｉｏｎ）を有する。２５６個のピクセルあたりの動きベクトルは、ブロックあたりの動きベクトルとして機能する単一平均ベクトルを提供するためにともに平均化されてよい。このようなプロセスは、図３を参照しながらさらに詳しく説明する。

段階２０６で、マクロブロックあたりの動きベクトル情報は、動き推定段階を避け、サーバ１２０に位置するコーディングエンジン／エンコーダ１０２に注入される。エンコーダのソフトウェア実現において、動き推定段階は完全に非活性されてよく、これによりＣＰＵ計算時間が大幅に節約される。ＣＰＵにおける時間節約は、ＧＰＵで平均ベクトルを計算し（段階２０４で）、ＣＰＵにこれを送信するために要求される追加時間を相殺する以上とならなければならない。

段階２０８で、グラフィックスエンジン１００によって供給されるブロックあたりの動きベクトルは、一般的な動き推定段階で計算されるものと交換可能であるため、エンコードは動き補償段階から始める（段階２０８）。残りのビデオエンコードプロセスは、図４を参照しながらさらに詳しく説明するが、動き推定技術を使用するエンコード標準によって実行される、一般的な動き補償、残余計算、およびエンコード段階と大きな違いがないことは明らかである。

図３は、グラフィックスエンジン１００で実行される、ピクセルあたりの動きベクトルからマクロブロックあたりの動きベクトルへの変換をさらに詳しく示した図である。カラー生成フェーズ（ｐｈａｓｅ）の間、サーバ１２０に位置する３Ｄグラフィックスエンジン１００は、ピクセルあたりの動きベクトルを生成し、サーバ１２０に位置する速度バッファ３００にデータを格納するであろう。速度バッファ３００は、プレイヤ（ｐｌａｙｅｒ）のカメラ移動によって付与された動き情報を除外し、動的オブジェクトに対するデータのみを含んでよい。イメージ空間から各ピクセルに対する動きベクトル情報を取得するために、コンピュータシェーダ（ｃｏｍｐｕｔｅ ｓｈａｄｅｒ）は、速度バッファ３００の速度を速度バッファにまだ含まれていないすべての静的オブジェクトに対するカメラ速度と結合させ、動き速度バッファ３０４にピクセルあたりの結果を格納するであろう。カメラ速度は、フレーム間の回転および並進（ｔｒａｎｓｌａｔｉｏｎａｌ）のカメラ移動の２Ｄ映写（ｐｒｏｊｅｃｔｉｏｎ）である。特定のグラフィックスエンジンは、全体スクリーン空間に対してこのようなピクセルあたりの動きベクトルを計算するために異なる方法を使用することもあるが、その概念は類似する。

Ｈ．２６４エンコーダは、１６×１６のデフォルトマクロブロックサイズを使用するが、４×４までのさらに小さなサイズに細分化されてよい。図３の例において、４×４のマクロブロック３０６は単純化された場合に使用されるが、その方法は、エンコーダで使用されるマクロブロックサイズと一致するように推論されなければならない。４×４のマクロブロックブロック３０６の場合、動きベクトルバッファ３０４に１６個のピクセルあたりの動きベクトル３０８が格納されている。このようなピクセルあたりの動きベクトル３０８は、図４に示した動き補償での使用のためにエンコーダに注入されることのできる単一マクロブロックあたりの動きベクトル３１０に変換３１２されなければならない。ピクセルあたりのベクトル３０８セットの算術平均（ａｒｉｔｈｍｅｔｉｃ ｍｅａｎ）は、低い計算複雑度と短い計算時間を有する変換３１２方法である。

追加される計算複雑度または能力の対価によって品質を向上させるために、算術平均変換３１２に対する選択的な修正が実行されてよい。例えば、マクロブロックあたりの動きベクトル３１０がマクロブロック３０６で大部分のピクセルを現わすことを保障するために、算術平均計算の前に、マクロブロックのベクトルフィールド（ｖｅｃｔｏｒ ｆｉｅｌｄ）から不連続性を除去するように、ベクトル中間フィルタリング技術が適用されてよい。結果的なマクロブロックあたりの動きベクトルは、周知のオブジェクト移動データを基盤として本来の計算されたピクセルの完全（ｐｅｒｆｅｃｔ）な動きベクトルから導き出されるため、このようなマクロブロックあたりの動きベクトルは、ピクセルカラーデータを基盤として移動（ｍｏｖｅｍｅｎｔ）のみを導き出すことのできる既存のブロック基盤の動き推定アルゴリズムによって計算されたものよりも正確な表現となるであろう。
図４は、図１のサーバ１２０のグラフィックスエンジン１００で生成された動きベクトルを図１のサーバ１２０のコーディングエンジン１０２に注入することにより、計算的に複雑である動き推定プロセスをスキップするための方法を示している。後述するように、エンコードされたビデオデータ１０８の結果ビットストリームは、リモートクライアントコンピュータシステム１１６に送信される。図４に示す方法は、単一インタ（ｉｎｔｅｒ）フレーム、特に、ビデオコーデック標準のＭＰＥＧファミリ（ｆａｍｉｌｙ）によって定義されるようなＰフレームのためのエンコードプロセスを示している。動き補償４０６は、イントラ（ｉｎｔｒａ）フレーム（Ｉフレーム）生成では実行されないため、Ｉフレームは変更されない。クロマサブサンプリングされた（ｃｈｒｏｍａ ｓｕｂｓａｍｐｌｅｄ）ビデオフレーム４０２およびブロックあたりの動きベクトルデータ４０４は、利用可能なグラフィックスエンジン１００から即時に送信されるであろう。ゲーム－生成された（ｇａｍｅ－ｇｅｎｅｒａｔｅｄ）動きベクトル４０４は、Ｈ．２６４／ＭＰＥＧ－４ＡＶＣ標準に示されるように、一般的な動き推定４２６段階で実行される動きベクトル生成を避けるために使用される。動き推定４２６段階はスキップされるようになり、コーディングエンジンのソフトウェアの実現で非活性化されてよい。ブロック基盤の動き推定４２６段階のスキップは、エンコード時間の相当な減少をもたらすようになるが、これは、図３を参照しながら説明したように、速度バッファデータを適切な形式に変換するのにかかる時間を相殺する以上となるであろう。

適切なマクロブロックサイズに変換された動きベクトル４０４は、動き補償４０６に対して変更されることなく、即時に使用されてよい。動き補償４０６の結果は、入力されたクロマサブサンプリングされたビデオフレーム４０２と結合し、既存のハードウェアまたはソフトウェアビデオエンコーダ内で一般的に実行される残余変換およびスケーリング４０８、量子化４１０、およびスキャン４１２によって処理される残像４３０を形成する。
非ブロック化（ｄｅｂｌｏｃｋｉｎｇ）段階は、実現で選択されたデコード標準が求められると、実行されなければならない。非ブロック化設定４２０と非ブロック化されたイメージ４２８は、逆量子化４１４、逆変換およびスケーリング４１６に続き、非ブロック化４１８に対するコーディング標準のアルゴリズムを適用することによって計算される。スキャンされた係数（ｃｏｅｆｆｉｃｉｅｎｔ）４１２は、ビットストリーム１０８として、リモートクライアントコンピュータシステムのコーデック１１０でのデコードのために、リモートクライアントコンピューターシステム１１６に送信される前に、非ブロック化設定４２０と結合し、エントロピコーダ（ｅｎｔｒｏｐｙ ｃｏｄｅｒ）４２２でエンコードされる。非ブロック化されたイメージ４２８は、次のフレームの動き補償４０６のための入力となる。ビットストリーム（エンコードされたビデオデータを含む）１０８は、Ｈ．２６４／ＭＰＥＧ－４ＡＶＣのような実現で使用されるエンコード標準によって定義されるものと同一の形式を維持する。このような例示は、Ｈ．２６４／ＭＰＥＧ－４ＡＶＣ標準に固有し、一般的に動き推定４２６と動き補償４０６技術を使用する類似のコーディング標準のために使用されてよい。

例１：エンコード時間の減少を示すベンチマーキングテスト
一般的なＨ．２６４互換コーディングにおいて、動き推定段階は、最も計算的に複雑でありながら時間が消耗的な段階である。本文書で開示するように、ゲーム－生成された動きベクトルを再使用することは、エンコード時間の相当な減少をもたらすことができる。
テスト環境において、グラフィックスエンジンは、１秒あたり６０フレームで１２８０×７２０の解像度で出力を生成した。エンコード時間は、単一スレッド（ｔｈｒｅａｄｅｄ）を実行する×２６４エンコーダからキャプチャされた（ｃａｐｔｕｒｅｄ）。エンコーダが単一スレッドを実行することは、実際の使用よりも長いエンコード時間を生成するはずであるため、１つのコア（ｃｏｒｅ）で測定値を正規化し、これらが互いに直接に比較可能となるであろう。エンコード時間は、先ず、エンコーダ内で修正されていない動き推定によって測定された後、活性化されたゲーム－生成された動き推定の特徴を使用して同一環境で再測定された。

低い動き領域（ｌｏｗ ｍｏｔｉｏｎ ａｒｅａ）がプレイヤの手、武器、および固定壁のような１人称プレイヤビュー（ｆｉｒｓｔ－ｐｅｒｓｏｎ ｐｌａｙｅｒ ｖｉｅｗ）を含んで選択された。相対的に狭いスペース空間で少ない量のピクセル動きを生成するために、プレイヤの手と武器は、多少の「ボビング（ｂｏｂｂｉｎｇ）」アニメーションによって循環するようになる（ｃｙｃｌｅ）。このようなテストの結果を下記の表１に示した。これは、本文書で説明した、ゲーム－生成された動き推定技術の有無による待機時間の結果を示している。ゲーム－生成された動き推定が非活性化された低い強度で、修正されていないエンコード時間は１２ｍｓであった。ゲーム－生成された動き推定が活性化されたとき、エンコード時間は、９ｍｓのエンコード時間で約３ｍｓが減少した。類似の待機時間の減少が平均および高い動き強度のシナリオで現れたし、平均の動き強度シナリオでは１７．６％の待機時間の減少を、高い待機時間シナリオでは１５～３０％の待機時間の減少を示した。このような結果は、ゲーム－生成された動き推定が活性化されるとき、待機時間の著しく優れた減少を示すものである。

さらに、テスト環境は、ゲーム－生成されたピクセルあたりの動きベクトルをエンコーダのためのマクロブロックあたりの動きベクトルに変換するとき、追加の費用が発生することが明らかになっている。しかし、このような費用は、以前のセクションで説明したエンコード時間の減少よりは少ない。１２８０×７２０の解像度でビデオを生成するグラフィックスエンジンにより、ピクセルあたりからマクロブロックあたりの動きベクトルの変換には０．０２ｍｓがかかった。測定されたエンコード時間の節約は、エンコードのためにゲーム－生成された動きベクトルを使用して追加された費用より３倍も大きい。

上述した説明および図面は、本発明の原理を例示するためのものに過ぎない。本発明は、好ましい実施形態によって制限されるように意図されてはならず、該当の技術分野において通常の知識を有する者にとって明白である、多様な方式で実現されるであろう。本発明の多数の応用は、該当の技術分野において通常の知識を有する者によって容易に実現されるであろう。したがって、開示された特定の例示または図に示されて説明された正確な構成と動作によって本発明を制限することは好ましくない。むしろ、すべての適切な修正および均等物が、本発明の範囲内に属するものと理解されなければならない。
〔付記１〕
段階を含むグラフィックスを生成するためのコンピュータで実現される方法であって、
段階は、
１つ以上のピクセルあたり（ｐｅｒ－ｐｉｘｅｌ）の動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を生成する段階、
グラフィックスエンジン（ｇｒａｐｈｉｃｓ ｅｎｇｉｎｅ）において、前記１つ以上のピクセルあたりの動きベクトルを１つ以上のブロックあたり（ｐｅｒ－ｂｌｏｃｋ）の動きベクトルに変換する段階、および
前記ブロックあたりの動きベクトルをビデオエンコードエンジンに注入する段階
を含み、
前記ビデオエンコードエンジンは、
リモートクライアントコーディングエンジンへの送信のために、前記１つ以上のブロックあたりの動きベクトルをエンコードされたビデオデータに変換する、方法。
〔付記２〕
前記１つ以上のピクセルあたりの動きベクトルは、
変換の前に、速度バッファ（ｖｅｌｏｃｉｔｙ ｂｕｆｆｅｒ）に格納される、
付記１に記載の方法。
〔付記３〕
前記１つ以上のピクセルあたりの動きベクトルの生成は、
ピクセルあたりの結果を取得するために、コンピュータシェーダ（ｃｏｍｐｕｔｅ ｓｈａｄｅｒ）において、前記１つ以上のピクセルあたりの動きベクトルをカメラ速度（ｃａｍｅｒａ ｖｅｌｏｃｉｔｙ）に結合する段階、および
前記ピクセルあたりの結果を動きベクトルバッファに格納する段階
を含む、付記１に記載の方法。
〔付記４〕
グラフィックスエンジンは、
ブロックあたりの動きベクトルデータを１つ以上のクロマサブサンプリングされた（ｃｈｒｏｍａｓｕｂ ｓａｍｐｌｅｄ）ビデオフレームと同時に、前記ビデオエンコードエンジンにリアルタイムで注入する、
付記１に記載の方法。
〔付記５〕
前記エンコードされたビデオデータは、
リモートクライアントコンピュータシステムでの再生のためにデコードされる、
付記１に記載の方法。
〔付記６〕
前記ビデオエンコードエンジンは、
前記１つ以上のブロックあたりの動きベクトルをエンコードされたビデオデータに変換するために、動き補償（ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ）および残余変換（ｒｅｓｉｄｕａｌ ｔｒａｎｓｆｏｒｍａｔｉｏｎ）を実行する、
付記１に記載の方法。
〔付記７〕
前記エンコードされたビデオデータは、
１つ以上の逆量子化アルゴリズム（ｉｎｖｅｒｓｅ ｑｕａｎｔｉｚａｔｉｏｎ ａｌｇｏｒｉｔｈｍ）、逆変換（ｉｎｖｅｒｓｅ ｔｒａｎｓｆｏｒｍ）およびスケーリング（ｓｃａｌｅ）、および／または非ブロック化（ｄｅｂｌｏｃｋｉｎｇ）を適用することにより、前記リモートクライアントコーディングエンジンへの送信のために備える、
付記１に記載の方法。
〔付記８〕
前記１つ以上のピクセルあたりのベクトルは、
算術平均（ａｒｉｔｈｍｅｔｉｃ ｍｅａｎ）を適用する変換方法を使用して１つ以上のブロックあたりの動きベクトルに変換される、
付記１に記載の方法。
〔付記９〕
１つ以上のグラィックスエンジンとビデオコーデックエンジンからなる、コンピュータで実現されるグラフィックス生成システムであって、
前記グラフィックスエンジンは、
１つ以上のピクセルあたりの動きベクトルを生成し、前記ピクセルあたりの動きベクトルを１つ以上のブロックあたりの動きベクトルに変換し、前記ブロックあたりの動きベクトルを前記ビデオコーデックエンジンに直接に注入し、
前記ビデオコーデックエンジンは、
前記ブロックあたりの動きベクトルをエンコードされたビデオデータに変換し、前記エンコードされたビデオデータをリモートクライアントコンピューターシステムで実行されるリモートクライアントコーディングエンジンに送信する、
システム。
〔付記１０〕
前記１つ以上のピクセルあたりの動きベクトルは、
変換の前に、速度バッファに格納される、
付記９に記載のシステム。
〔付記１１〕
前記１つ以上のピクセルあたりの動きベクトルは、
ピクセルあたりの結果を取得するために、コンピュータシェーダにおいて、前記１つ以上のピクセルあたりの動きベクトルをカメラ速度に追加し、前記ピクセルあたりの結果を動きベクトルバッファに格納することによって生成される、
付記９に記載のシステム。
〔付記１２〕
前記グラフィックスエンジンは、
ブロックあたりの動きベクトルデータを１つ以上のクロマサブサンプリングされたビデオフレームと同時に、前記ビデオコーデックエンジンにリアルタイムで注入する、
付記8に記載のシステム。
〔付記１３〕
前記ビデオコーデックエンジンは、
前記１つ以上のブロックあたりの動きベクトルをエンコードされたビデオデータに変換するために、動き補償および残余変換を実行する、
付記９に記載のシステム。
〔付記１４〕
前記エンコードされたビデオデータは、
１つ以上の逆量子化アルゴリズム、逆変換およびスケーリング、および／または非ブロック化を適用することにより、前記リモートクライアントコーディングエンジンへの送信のために備える、
付記９に記載のシステム。
〔付記１５〕
前記エンコードされたビデオデータは、
デコードされ、ディスプレイコントローラ（ｄｉｓｐｌａｙ ｃｏｎｔｒｏｌｌｅｒ）によって駆動されるディスプレイで再生されるように構成される、
付記９に記載のシステム。
〔付記１６〕
前記グラフィックスエンジンは、
算術平均を適用する変換方法を使用し、前記１つ以上のピクセルあたりのベクトルを１つ以上のブロックあたりの動きベクトルに変換する、
付記９に記載のシステム。
〔付記１７〕
段階を含むグラフィックスを生成するためのコンピュータで実現される方法であって、
段階は、
グラフィックスエンジンにおいて、１つ以上のピクセルあたりの動きベクトルを１つ以上のブロックあたりの動きベクトルに変換する段階（ブロックあたりの動きベクトルデータは、受信時にコーデックエンジンに送信される）、および
グラフィックスエンジンにおいて、１つ以上のクロマサブサンプリングされたビデオフレームを受信する段階（前記クロマサブサンプリングされたビデオフレームは、受信時に前記コーデックエンジンに送信される）を含み、
前記コーデックエンジンは、リモートクライアントコンピュータシステムへの送信のためにビデオデータをエンコードするために、前記ブロックあたりの動きベクトルデータと前記クロマサブサンプリングされたビデオフレームとを結合し、
動き推定計算は、前記ビデオデータのエンコードの間に非活性化される、
方法。
〔付記１８〕
前記結合されたブロックあたりの動きベクトルデータとクロマサブサンプリングされたビデオフレームは、
残像（ｒｅｓｉｄｕａｌ ｉｍａｇｅ）を形成する、
付記１７に記載の方法。
〔付記１９〕
前記残像は、
エンコードの前に、残余変換およびスケーリング、量子化、および／またはスキャン（ｓｃａｎｎｉｎｇ）によってさらに処理される、
付記１８に記載の方法。
〔付記２０〕
逆量子化、逆変換、およびスケーリングを計算する段階、および
前記残像を非ブロック化する段階
をさらに含む、付記１８に記載の方法。

Claims (10)

1. 段階を含むグラフィックスを生成するためのコンピュータで実現される方法であって、
   段階は、
   １つ以上のピクセルあたり（ｐｅｒ－ｐｉｘｅｌ）の動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を生成する段階、
   前記１つ以上のピクセルあたりの動きベクトルを１つ以上のブロックあたり（ｐｅｒ－ｂｌｏｃｋ）の動きベクトルに変換する段階、および
   前記ブロックあたりの動きベクトルをビデオエンコードエンジンに注入する段階
   を含み、
   前記ビデオエンコードエンジンは、
   前記１つ以上のブロックあたりの動きベクトルをエンコードされたビデオデータに変換し、
   前記１つ以上のピクセルあたりの動きベクトルの生成は、
   ピクセルあたりの結果を取得するために、コンピュータシェーダ（ｃｏｍｐｕｔｅ ｓｈａｄｅｒ）において、動的オブジェクトに対する１つ以上のピクセルあたりの動きベクトルを、静的オブジェクトに対するカメラ速度（ｃａｍｅｒａ ｖｅｌｏｃｉｔｙ）に結合する段階、および
   前記ピクセルあたりの結果を動きベクトルバッファに格納する段階
   を含む、方法。
2. 前記１つ以上のピクセルあたりの動きベクトルは、
   変換の前に、速度バッファ（ｖｅｌｏｃｉｔｙ ｂｕｆｆｅｒ）に格納される、
   請求項１に記載の方法。
3. グラフィックスエンジンは、
   ブロックあたりの動きベクトルデータを１つ以上のクロマサブサンプリングされた（ｃｈｒｏｍａｓｕｂ ｓａｍｐｌｅｄ）ビデオフレームと同時に、前記ビデオエンコードエンジンにリアルタイムで注入する、
   請求項１に記載の方法。
4. 前記エンコードされたビデオデータは、
   １つ以上の逆量子化アルゴリズム（ｉｎｖｅｒｓｅ ｑｕａｎｔｉｚａｔｉｏｎ ａｌｇｏｒｉｔｈｍ）、逆変換（ｉｎｖｅｒｓｅ ｔｒａｎｓｆｏｒｍ）およびスケーリング（ｓｃａｌｅ）、および／または非ブロック化（ｄｅｂｌｏｃｋｉｎｇ）を適用することにより、リモートクライアントコーディングエンジンへの送信のために備える、
   請求項１に記載の方法。
5. 前記１つ以上のピクセルあたりのベクトルは、
   算術平均（ａｒｉｔｈｍｅｔｉｃ ｍｅａｎ）を適用する変換方法を使用して１つ以上のブロックあたりの動きベクトルに変換される、
   請求項１に記載の方法。
6. グラフィックスエンジンとビデオコーデックエンジンとを含むコンピュータで実現されるグラフィックス生成システムであって、
   前記グラフィックスエンジンは、
   １つ以上のピクセルあたりの動きベクトルを生成し、前記ピクセルあたりの動きベクトルを１つ以上のブロックあたりの動きベクトルに変換し、前記ブロックあたりの動きベクトルを前記ビデオコーデックエンジンに直接に注入し、
   前記ビデオコーデックエンジンは、
   前記ブロックあたりの動きベクトルをエンコードされたビデオデータに変換し、前記エンコードされたビデオデータをリモートクライアントコンピューターシステムに送信し、
   前記１つ以上のピクセルあたりの動きベクトルは、
   ピクセルあたりの結果を取得するために、コンピュータシェーダにおいて、動的オブジェクトに対する１つ以上のピクセルあたりの動きベクトルを、静的オブジェクトに対するカメラ速度に追加し、前記ピクセルあたりの結果を動きベクトルバッファに格納することによって生成される、
   システム。
7. 前記１つ以上のピクセルあたりの動きベクトルは、
   変換の前に、速度バッファに格納される、
   請求項６に記載のシステム。
8. 前記グラフィックスエンジンは、
   ブロックあたりの動きベクトルデータを１つ以上のクロマサブサンプリングされたビデオフレームと同時に、前記ビデオコーデックエンジンにリアルタイムで注入する、
   請求項６に記載のシステム。
9. 前記ビデオコーデックエンジンは、
   前記１つ以上のブロックあたりの動きベクトルをエンコードされたビデオデータに変換するために、動き補償および残余変換を実行する、
   請求項６に記載のシステム。
10. 前記エンコードされたビデオデータは、
    デコードされ、ディスプレイコントローラ（ｄｉｓｐｌａｙ ｃｏｎｔｒｏｌｌｅｒ）によって駆動されるディスプレイで再生されるように構成される、
    請求項６に記載のシステム。

Images