JP4996603B2 - 事前符号化マクロブロックを使用するビデオゲームシステム - Google Patents

Description

発明の分野
本発明は、包括的にはインタラクティブビデオゲームシステムに関し、詳細には、事前符号化マクロブロックを使用するインタラクティブビデオゲームシステムに関する。

背景
ビデオゲームはエンターテインメントの人気のある形態である。２人以上の個人が共通の擬似環境内で同時にプレイするマルチプレーヤゲームは、特に、これまで以上に多くのユーザが、インターネットとも呼ばれるワールドワイドウェブ（ＷＷＷ）等のネットワークを使用して互いに対話することができるので、ますます一般的になりつつある。ビデオゲームをネットワーク化された環境で実施するには、いくつかの問題がある。

具体的には、ビデオゲーム、特に高品質グラフィックスを提供するビデオゲームは、ネットワークで利用可能なデータ速度通信容量のかなりの割合である最大データ速度を有するデータストリームを生成し得る。データ速度は、各ゲームのゲーム状態が変更又は更新される頻度に依存して、時間に応じて大きく変化もし得る。高データ速度と時間で変化するデータ速度とのこの組み合わせは、衛星システム、ケーブルテレビジョンシステム、又はインターネット等のネットワーク環境での費用効果的且つ効率的な資源の割り振りを難しくし得る。このようなネットワーク環境でのビデオゲームシステムは、性能が低下しないことを保証するために、追加の帯域幅オーバーヘッド並びにハードウェア及びソフトウェアの冗長性という形で追加のマージンを必要とし得る。こういったシステムの問題は、マルチプレーヤゲームの場合にさらに難しくなる。

動画像符号化専門家グループ（ＭＰＥＧ）により開発された圧縮規格の１つ等の既存の符号化手法を使用してビデオゲームシステムにおいてデータストリームを符号化しても、せいぜいこういった問題に対する部分的な解決策しか提供することができず、さらなる問題が生じる恐れもある。例えば、ＭＰＥＧ２は、デジタルビデオコンテンツの多く（最大で９５％）が冗長情報であり得ることを利用する柔軟性のある圧縮規格である。コンテンツのこういった部分の符号化は、対応するデータ速度を大幅に低減させ得る。しかし、コンテンツの他の部分の冗長性がはるかに低いことがある。従来のＭＰＥＧ２符号化では、これは、複雑な画像ほど高いデータ速度に繋がり得る。その結果として、ＭＰＥＧ２符号化データストリームは依然として、時間に応じて大きく変動するデータ速度を有し得る。さらに、ＭＰＥＧ２等の既存の符号化手法を使用してのリアルタイム又はオンザフライでの複数のデータストリームの符号化は、ビデオゲームシステムの複雑性、コスト、及び／又は消費電力を増大させ得る。

したがって、ネットワーク環境においてビデオゲームを実施する改良されたシステムが必要である。

概要
ビデオフレームを生成する方法及び関連するシステムが開示される。この方法では、要求が受信される。ビデオフレームが、複数の事前符号化マクロブロックを使用して生成される。ビデオフレームはＭＰＥＧ圧縮規格に準拠する。複数の事前符号化マクロブロックは、要求前に事前符号化される。いくつかの実施形態では、要求によりビデオゲームが開始される。

各事前符号化マクロブロックはピクセルセットに対応する。各事前符号化マクロブロックを事前符号化することは、離散コサイン変換演算、量子化演算、及びランレングス符号化演算を実施することを含む。事前符号化することは、１つ又は複数の動きベクトル及び／又は補正データを計算することも含み得る。ビデオフレームを生成することは、ビデオフレーム内の隣接する事前符号化マクロブロックを相互に関連付けることを含む。相互に関連付けることは、ルミナンス情報を含む第１のブロックの第１のＤＣ係数値、クロミナンス情報を含む第２のブロックの第２のＤＣ係数値、及びクロミナンス情報を含む第３のＤＣ係数値を決定することを含み得る。各ＤＣ係数値を決定することは、ビデオフレーム内の別の事前符号化マクロブロックに対する差を決定することを含み得る。

隣接する事前符号化マクロブロックを相互に関連付けることは、ビデオフレーム内の別の事前符号化マクロブロックの量子化係数に対する差を決定することを含み得る。これは、ビデオフレーム内の別の事前符号化マクロブロックの動きベクトル及び／又は圧縮データに対する差を決定することを含み得、ビデオフレーム内の別の事前符号化マクロブロックに所定の動きベクトル及び／又は圧縮データを選択することも含み得る。

いくつかの実施形態では、複数の事前符号化マクロブロックは、個々にアドレス指定可能な事前符号化マクロブロックのバンクに記憶される。各事前符号化マクロブロックはメタデータを含むことができ、このデータは量子化係数、所定の動きベクトル、及び／又は補正データを含み得る。いくつかの実施形態では、複数の事前符号化マクロブロックの第１のサブセットが、２つ以上のビデオゲーム間で、２つ以上のビデオフレーム間で、及び／又は２つ以上のビデオゲームインスタンス間で共用される。いくつかの実施形態では、記憶されている複数の事前符号化マクロブロックの第２のサブセットが、非圧縮ピクセル情報を含む。

いくつかの実施形態では、方法は、複数のマクロブロックを動的に生成することをさらに含む。動的に生成される複数のマクロブロックは、非圧縮ピクセル情報を含む事前符号化マクロブロックとオブジェクトに対応する画像情報との組み合わせを含む。この組み合わせを形成することは、事前符号化マクロブロックの非圧縮ピクセル情報とオブジェクトに対応する画像情報とをブレンドすることを含み得る。組み合わせは、ビデオフレームの領域へのオブジェクトに対応する画像情報の重ね合わせを含み得る。

代替の実施形態では、要求（例えば、ビデオゲームの実行を開始する）が受信され、コマンド（例えば、ビデオゲームのコンテキスト内でアクションを実行するユーザコマンド）が、要求よりも後の時間に受信される。ビデオフレームが、要求前に事前符号化される複数の事前符号化マクロブロック及び要求後且つコマンド前に符号化される複数の要求後符号化マクロブロックを使用して生成される。別法として、ビデオフレームは、要求前に事前符号化される複数の事前符号化マクロブロック、要求後且つコマンド前に符号化される複数の要求後符号化マクロブロック、及びコマンド後に符号化される複数の動的符号化マクロブロックを使用して生成される。

いくつかの実施形態では、複数の事前符号化マクロブロックはＭＰＥＧ圧縮規格に準拠する。複数の事前符号化マクロブロックは、個々にアクセス可能な事前符号化マクロブロックのバンクに記憶され、複数の別個のビデオフレームを生成する際に使用される。

ビデオフレームを生成する方法及び関連のシステムは、ネットワーク環境でのシングルプレーヤビデオゲーム及び／又はマルチプレーヤビデオゲームの実施に関連する上記問題のうちの少なくともいくつかを解消する。

本発明をよりよく理解するために、添付図面に関連して以下の詳細な説明を参照すべきである。

同様の参照番号は、図面全体を通して対応するパーツを指す。

実施形態の詳細な説明
実施形態をこれより詳細に参照し、実施形態の例を添付図面に示す。以下の詳細な説明では、本発明の完全な理解を提供するために多くの特定の詳細が述べられる。しかし、本発明がそういった特定の詳細なしで実施可能なことが当業者に理解されよう。場合によっては、周知の方法、手順、構成要素、回路については、実施形態の態様を不必要に曖昧にしないように、詳細に説明していない。

衛星システム、ケーブルテレビジョンシステム（ＣＡＴＶ）、インターネット、広域ネットワーク、ローカルエリアネットワーク、及び／又は電話システム等のネットワークを使用してインタラクティブビデオゲームを提供する改良された方法及び関連のシステムについて説明する。後述するように、この方法及びシステムは、ビデオゲーム画像のフレーム及び／又はフィールド（以下、ビデオフレームと呼ぶ）に対応するビデオゲームコンテンツの効率的なデジタル化を利用して、通信帯域幅を低減することにより、サポート可能なユーザ数又はプレーヤ数（以下、ユーザと呼ぶ）を増大させる。ビデオゲームなる用語は、ビデオゲーム、他の形のコンピュータ実施されるレクリエーションアプリケーションプログラム、並びにニュース、天気、及び／又はスポーツ等の非レクリエーションアプリケーションプログラムを含む。プレーヤ又はユーザは、１つ又は複数のビデオゲームに参加する１人又は複数の人間を指す。

具体的には、１つ又は複数のビデオゲーム（シングルプレーヤビデオゲーム及び／又はマルチプレーヤビデオゲームを含む）に対応するビデオ画像フレーム又は１つ又は複数のビデオフレームへの更新が、１つ又は複数のビデオゲームを開始する要求の前に符号化される複数の事前符号化タイル又はマクロブロックを使用して生成される。マクロブロックは、ピクセルセット、例えば、１６×１６ピクセルアレイを含む。ビデオフレームを生成することは、隣接するマクロブロック内のＤＣ係数を相互に関連付けること、隣接するマクロブロックに所定の動きベクトル及び補正データを選択すること、隣接するマクロブロックの動きベクトル及び補正データ、並びに／又は隣接するマクロブロックの量子化係数を計算することを含み得る。事前符号化マクロブロックを使用することは、ビデオゲームの中身のいくつか又はすべてが複数の連続したビデオフレームで変わらないままであり得る（例えば、ユーザアクションが中身のいくらか又はすべてを変えないままであり得る）ことを利用する。その結果として、中身のいくつか又はすべてを事前符号化することができる。これにより、例えば、インフラを簡易化し、且つ／又はビデオ画像フレームの生成に必要な計算資源を低減することにより、ネットワーク環境でのビデオゲームシステムの実施に関連する複雑性及び／又はコストを低減することができる。さらに、中身を符号化（圧縮）することによっても、ビデオフレームに対応するデータストリームでのデータ速度を低減することができる。

複数の事前符号化マクロブロックを生成し、個々にアドレス指定可能な事前符号化マクロブロックのバンクに記憶することができる。これにより、複数の事前符号化マクロブロックのサブセットを、例えば、２つ以上のビデオゲーム間で、２つ以上のビデオフレーム間で、及び／又は２つ以上のビデオゲームインスタンス間で共用することができるようになる。この共用によっても、ネットワーク環境でビデオゲームシステムを実施するコスト及び／又は複雑性を低減することができる。これにより、ビデオゲームシステムは、マルチプレーヤビデオゲームをより少ないインフラでサポートすることもできる。

いくつかの実施形態では、各ビデオフレームは、複数の事前符号化マクロブロックのサブセット及び基準グリッドを使用して生成される。基準グリッドは、マクロブロックへのインデックス及び／又はポインタを含み、基準グリッド内の各枠又はエントリが各ビデオフレーム内のロケーションに対応する。前のビデオフレームを各ビデオフレームと比較することにより、適当な事前符号化マクロブロックを基準グリッドに対応する適当なインデックス及び／又はポインタに位置決めすることにより、各ビデオフレームを生成することができる。この比較は、前のフレームタイルグリッドの対応し、且つ／又は隣接する位置にあるタイルインデックスを含み得る。したがって、この比較には、ビデオフレーム内の完全なピクセルセットではなくマクロブロックのインデックスが関わる。これは計算量の大きな低減に繋がり得る。

いくつかの実施形態では、複数のマクロブロックを１つ又は複数のビデオゲーム中に生成することもできる。ビデオゲーム要求を受信した後、これらマクロブロックのうちのいくつかを一度に生成してから、複数のビデオフレームで使用することができる。これは、例えば、テキスト（ユーザ名）又は単純なアニメーションに対応するもの等の、ビデオゲームが要求されるまで入手できない情報についてのマクロブロックを含み得る。より詳細に以下において説明するように、アニメーションに対応する動きベクトル及び／又は補正データも事前符号化することができる。他のマクロブロックは、ビデオゲーム中に１つ又は複数のユーザコマンドに応答して動的に生成することができる。１つ又は複数のユーザコマンドは、例えば、各ユーザ又は各組のユーザの各ユーザアクションに基づいて、ビデオゲームのゲーム状態の変更を決定することができる。このように動的に生成されるマクロブロックは、１つ又は複数のスプライト（例えば、可動オブジェクトブロックとも呼ばれるプログラム可能且つ移動可能な高解像度グラフィック画像）等のビデオゲーム内のオブジェクトに対応し得る。

いくつかの実施形態では、複数の事前符号化マクロブロックのサブセットは、非圧縮ピクセル情報並びに圧縮される事前符号化ピクセルデータを含み得る。１つ又は複数のビデオフレームの生成中、動的生成マクロブロックは、複数の事前符号化マクロブロックの非圧縮ピクセル情報と１つ又は複数のオブジェクトに対応する画像情報との組み合わせを含み得る。この組み合わせは、１つ又は複数のオブジェクトに対応する画像情報を非圧縮ピクセル情報とブレンドし、且つ／又は重ね合わせることを含み得る。

この方法及びシステムは、生成されたビデオゲームコンテンツをユーザ装置に送信し、ユーザ装置に表示させる。生成されたビデオゲームコンテンツは、ユーザ装置に送信された前のビデオゲームコンテンツに対する差分情報に対応することができる。システムは、複数組のユーザがビデオゲームの単一の実行可能コピーを同時に、且つ独立してプレイできるようにする。各組のユーザは１人又は複数のユーザを含み得る。各組のユーザは、ビデオゲームに各ゲーム状態を有し得る。このようにして、システムは資源利用効率及び全体のコスト効率を向上させる。

例示的な実施形態では、この方法及びシステムは、ＭＰＥＧ２を含むＭＰＥＧ圧縮規格に準拠する。この準拠により、この方法及びシステムを使用して生成された１つ又は複数のビデオフレームを、市販のチップセットを使用して表示することができる。

ビデオゲームシステム
図１は、１つ又は複数のビデオゲーム等のコンテンツ（マルチユーザビデオゲームを含む）に対する注文を受信し、注文されたコンテンツを１人又は複数のユーザに提供するケーブルテレビシステム１００の一実施形態を示すブロック図である。いくつかのコンテンツデータストリームを各加入者に送信することができ、各加入者は、サービスを注文するか、又はビデオゲームでのユーザアクションを送信することができる。アナログテレビジョン信号等の衛星信号は、衛星アンテナ１４４を使用して受信することができる。アナログ信号は、アナログヘッドエンド１４６で処理され、無線周波（ＲＦ）結合器１３４に連結され、ネットワーク１３６を介してセットトップボックス（ＳＴＢ）１４０に送信される。さらに、信号は衛星受信器１４８で処理し、マルチプレクサ（ＭＵＸ）１５０に連結され、直交振幅変調器（ＱＡＭ）１３２−２（２５６レベルＱＡＭ等）を使用してデジタルフォーマットに変換され、無線周波（ＲＦ）結合器１３４に連結され、ネットワーク１３６を介してＳＴＢ１４０に送信される。ビデオオンデマンド（ＶＯＤ）サーバ１１８が、注文された映画に対応する信号をスイッチ１２６−２に提供することができ、スイッチ１２６−２は信号をＱＡＭ１３２−１に連結してデジタルフォーマットに変換する。これらデジタル信号は無線周波（ＲＦ）結合器１３４に連結され、ネットワーク１３６を介してＳＴＢ１４０に送信される。ＳＴＢ１４０は、後述するビデオゲームコンテンツに対応する信号を含む１つ又は複数の信号をテレビジョン又は他の表示装置１３８に表示することができる。図１は１つの加入者ＳＴＢ１４０及びテレビジョン又は他の表示装置１３８を示すが、他の実施形態では、１つ又は複数のＳＴＢ及び／又はテレビジョンもしくは他の表示装置をそれぞれ有するさらなる加入者が存在してもよい。

ケーブルテレビジョンシステム１００は、アプリケーションサーバ１１４及び複数のゲームサーバ１１６を含むこともできる。アプリケーションサーバ１１４及び複数のゲームサーバ１１６は、ケーブルテレビジョンシステムのヘッドエンドに配置することができる。アプリケーションサーバ１１４の単一のインスタンス又はグループ及び複数のゲームサーバ１１６を図１に示すが、他の実施形態は、１つ又は複数のヘッドエンド内にさらなるインスタンスを含んでもよい。１つ又は複数のヘッドエンドにあるサーバ及び／又は他のコンピュータは、ウィンドウズ（Ｗｉｎｄｏｗｓ）、リナックス（Ｌｉｎｕｘ）、Ｕｎｉｘ（ユニックス）、又はソラリス（Ｓｏｌａｒｉｓ）等のオペレーティングシステムを実行することができる。

アプリケーションサーバ１１４及びゲームサーバ１１６のうちの１つ又は複数は、１人又は複数のユーザにより注文された１つ又は複数のビデオゲームに対応するビデオゲームコンテンツを提供することができる。ケーブルテレビジョンシステム１００には、各ユーザとビデオゲームのうちの１つの実行されるコピーとの間に多対一の対応性がある。アプリケーションサーバ１１４は、データベース内のゲーム関連情報にアクセスし、且つ／又はログを記録することができる。アプリケーションサーバ１１４は、報告及び価格付けに使用することもできる。ゲームサーバ１１６内の１つ又は複数のゲームエンジン（ゲームエンジンモジュールとも呼ばれる）１８４８（図１８）が、事前符号化ブロックを使用してビデオゲームコンテンツを動的に生成するように設計される。例示的な実施形態では、ゲームサーバ１１６はＭＰＥＧ圧縮規格に準拠する符号化を使用する。

ビデオゲームコンテンツはスイッチ１２６−２に結合され、ＱＡＭ１３２−１においてデジタルフォーマットに変換される。２５６レベルＱＡＭを用いる例示的な実施形態では、ナローキャストサブチャネル（およそ６ＭＨｚの帯域幅を有し、これはおよそ３８Ｍｂｐｓのデジタルデータに対応する）を使用して、１〜４Ｍｂｐｓを利用するビデオゲームの１０〜３０のビデオゲームデータストリームを送信することができる。

これらデジタル信号は無線周波（ＲＦ）結合器１３４に結合され、ネットワーク１３６を介してＳＴＢ１４０に送信される。アプリケーションサーバ１１４は、インターネット１１０を介して、マルチプレーヤサーバ１１２に記憶されるデータベース内の永久的なプレーヤデータ又はユーザデータにアクセスすることもできる。アプリケーションサーバ１１４及び複数のゲームサーバ１１６について、図１８を参照してさらに後述する。

ＳＴＢ１４０は、１つ又は複数のユーザアクションに対応する情報を受け取り、その情報をゲームサーバ１１６のうちの１つ又は複数に送信する、ゲーム１４２等のクライアントアプリケーションを含むことができる。ゲームアプリケーション１４２は、テレビジョン１３８上のビデオフレームを更新する前に、ビデオゲームコンテンツを記憶することもできる。テレビジョン１３８は、ＮＴＳＣフォーマット又はＰＡＬ若しくはＳＥＣＡＭ等の異なるフォーマットに準拠することができる。ＳＴＢ１４０について、図１８を参照してさらに後述する。

ケーブルテレビジョンシステム１００は、ＳＴＢ制御機構１２０、オペレーションサポートシステム１２２、及び課金システム１２４を含むこともできる。ＳＴＢ制御機構１２０は、帯域外（ＯＯＢ）サブチャネルを使用して受信される各ビデオゲームに関連するユーザアクション等の１つ又は複数のユーザアクションを、リターンパルス振幅（ＰＡＭ）復調器１３０及びスイッチ１２６−１を使用して処理することができる。２つ以上のＯＯＢサブチャネルがあってもよい。ＯＯＢサブチャネルの帯域幅は実施形態毎に可変であるが、一実施形態では、各ＯＯＢサブチャネルの帯域幅はおよそ１Ｍｐｂｓのビット速度又はデータ速度に対応する。オペレーションサポートシステム１２２は、各ビデオゲーム等の各サービスへの加入者注文を処理し、課金システム１２４を更新することができる。ＳＴＢ制御機構１２０、オペレーションサポートシステム１２２、及び／又は課金システム１２４は、スイッチ１２６−１及び信号をＯＯＢサブチャネルに適したフォーマットに変換するＯＯＢモジュール１２８を介して、ＯＯＢサブチャネルを使用して加入者と通信することもできる。別法として、オペレーションサポートシステム１２２及び／又は課金システム１２４は、インターネット接続又は電話システムにより提供される通信リンク等の別の通信リンクを介して加入者と通信してもよい。

ケーブルテレビジョンシステム１００で送受信される各種信号は、パケットベースのデータストリームを使用して通信することができる。例示的な実施形態では、パケットのうちのいくつかは、ユーザデータグラムプロトコル（ＵＤＰ）等のインターネットプロトコルを利用することができる。いくつかの実施形態では、ネットワーク１３６等のネットワーク及びケーブルテレビジョンシステム１００内の構成要素間の結合は、ワイヤレスエリアネットワーク、ローカルエリアネットワーク、伝送線（同軸ケーブル等）、陸線、及び／又は光ファイバの１つ又は複数のインスタンスを含むことができる。いくつかの信号は、一般電話サービス（ＰＯＴＳ）及び／又は総合デジタル通信網（ＩＳＤＮ）等のデジタル電話網を使用して通信することができる。ワイヤレス通信は、アナログ携帯電話システム（ＡＭＰＳ：Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ Ｓｙｓｔｅｍ）、汎欧州デジタル移動電話方式（ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、符号分割多元アクセス（ＣＤＭＡ）、及び／又は時分割多元アクセス（ＴＤＭＡ）を使用する携帯電話網、並びにＷｉＦｉとしても知られるＩＥＥＥ８０２．１１通信プロトコル及び／又はブルートゥース（Ｂｌｕｅｔｏｏｔｈ）通信プロトコルを使用するネットワークを含むことができる。

図１はケーブルテレビジョンシステムを示すが、記載のシステム及び方法は衛星ベースのシステム、インターネット、電話システム、及び／又は地上波テレビジョン放送システムで実施することもできる。ケーブルテレビジョンシステム１００は、追加の要素を含んでもよく、且つ／又は１つ又は複数の要素がなくてもよい。さらに、２つ以上の要素を１つの要素に組み合わせてもよく、且つ／又はケーブルテレビジョンシステム１００内の１つ又は複数の要素の位置を変更してもよい。

これより、事前符号化マクロブロックを使用して１つ又は複数のビデオフレームを生成する動作方法のいくつかの実施形態に注意を向ける。これら方法をケーブルテレビジョンシステム１００で実施して、１つ又は複数のビデオゲームを含むコンテンツを１人又は複数のユーザに提供することができる。上述したように、マクロブロックはピクセルセットに対応する。ＭＰＥＧ２等のＭＰＥＧ準拠圧縮規格を使用してマクロブロックを符号化する例示的な実施形態では、ブロックは８×８ピクセルアレイに対応することができ、マクロブロックは１６×１６ピクセルアレイに対応することができる。

１つ又は複数のビデオフレームの生成
図２は、ビデオフレームを生成するプロセス２００の一実施形態を示す流れ図である。要求が受信される（２１０）。要求はビデオゲームを開始することができる。ビデオフレームが、複数の事前符号化マクロブロック（すなわち、要求前に事前符号化されるマクロブロック）を使用して生成される（２１２）。プロセス２００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図３は、ビデオフレームを生成するプロセス３００の一実施形態を示す流れ図である。上述したプロセス２００と同様に、要求が受信される（２１０）。複数のマクロブロックが一度に、又は動的に生成される（３１０）。ビデオフレームが、複数の事前符号化マクロブロック（要求前に符号化される）及び複数の生成されたマクロブロックを使用して生成される（３１２）。プロセス３００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図４は、ビデオフレームを生成するプロセス４００の一実施形態を示す流れ図である。ここでも、プロセス４００は要求を受信すること（２１０）を含む。さらに、コマンドが受信される（４１０）。コマンドは、ビデオゲームでのユーザアクション又は１組のユーザのアクションに対応することができる。コマンドを受信した後、コマンドに応答して、ビデオフレームが、複数の事前符号化マクロブロック（要求前に符号化される）、複数の事後符号化マクロブロック（要求を受信した後且つコマンドを受信する前に符号化される）、及び複数の動的生成マクロブロック（コマンドを受信した後に符号化される）を使用して生成される（４１２）。プロセス４００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図５は、ビデオフレームを生成するプロセス５００の一実施形態を示す流れ図である。複数の事前符号化マクロブロックが生成される（５１０）。複数の事前符号化マクロブロックが、事前符号化マクロブロックのバンクに記憶される（５１２）。ビデオフレームが、少なくとも、複数の事前符号化マクロブロックのサブセットを使用して生成される（５１４）。プロセス５００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

実施形態５００での事前符号化マクロブロックは個々にアクセス可能であり、複数の事前符号化マクロブロックのサブセットを２つ以上のビデオゲーム間で、２つ以上のビデオフレーム間で、及び／又は２つ以上のビデオゲームインスタンス間で共用することができる。記憶される複数の事前符号化マクロブロックのサブセットは、非圧縮ピクセル情報を含み得る。図１０を参照して後述するように、非圧縮ピクセル情報も含む事前符号化マクロブロックを提供することにより、オブジェクトに対応する画像情報と１つ又は複数の事前符号化マクロブロックからの非圧縮ピクセル情報とを組み合わせた動的マクロブロックを生成することができる。

これより、ビデオフレームの生成に使用するマクロブロックの事前符号化生成、一度での生成、及び／又は動的な生成のいくつかの実施形態に注意を向ける。図６は、事前符号化マクロブロック６１２の１つ又は複数のバンク６１０及び二次元タイル、アレイ、又は基準グリッド６１４の一実施形態６００を示すブロック図である。バンク６１０に含まれる事前符号化マクロブロック６１２の数は、事前符号化マクロブロックを使用することになる各ビデオゲーム及びビデオゲームに関連する予測可能なアニメーションの量に依存し得る。したがって、単純なアニメーションを有する単純なゲームは、より多くのシーン、キャラクタ、及び予測可能アニメーションを有する複雑なゲームよりも書数の事前符号化マクロブロックを有する。例示的な実施形態では、およそ１６，０００、５０，０００、６０，０００、又は１００，０００の事前符号化マクロブロック６１２がある。基準グリッド６１４は、基準グリッド６１４を複数の枠に細分する複数の行６１６及び列６１８に構成される。各行６１６はビデオフレームのスライス６２０に対応する。グリッド６１４の各枠（グリッド内の各エントリ）は、ビデオフレーム生成時にマクロブロックを識別し位置決めするインデックス又はポインタを記憶する。複数のグリッドエントリが事前符号化マクロブロックを参照し得るが、グリッド６１４内の他のグリッドエントリは動的に生成されるマクロブロック（すなわち、ゲームユーザによる最新又は最近のコマンドに応答して生成されるマクロブロック等の、ゲーム実行開始後に生成されるマクロブロック）を参照する。換言すれば、グリッド６１４内の各枠は、各マクロブロック（少なくともそのうちのいくつかは事前符号化マクロブロック）へのポインタ又は参照を記憶し、グリッド６１４内の枠の位置は、ビデオフレーム内での識別されたマクロブロックの位置を識別する。例示的な実施形態では、マクロブロック（事前符号化マクロブロック６１２）はそれぞれ、１６×１６ピクセルアレイを表し、ＶＧＡビデオフレームに対応して、マクロブロック又はグリッドエントリの行６１６が３０あり、列６１８が４０ある。他の実施形態では、ＮＴＳＣのデジタル実施形態に対応して、マクロブロック又はグリッドエントリの行が３０あり、列が４５ある。

多くのビデオゲームでは、各ビデオフレーム内のコンテンツの少なくともサブセットが、前の又は後のビデオフレームに対して略変化しない可能性がある。この状況は、ユーザがコマンドをまだ入力（ユーザインタフェース装置を使用して命令を提供する等）していないため、すなわち、ユーザアクションがまだないためにビデオゲームにおいて発生し得る。別法として、各ビデオゲームに応じて、ユーザアドレス指定不可能な、すなわちユーザがコマンドを入力した場合であっても影響を受けないコンテンツのサブセット（例えば、ビデオフレームの背景にある画像）があり得る。この情報はゲーム開発者に提供され、ゲーム開発者はこの情報を利用して、どのマクロブロックを事前符号化すなわち圧縮し、どのマクロブロックを事前符号化し、且つ非圧縮ピクセル情報を記憶させるかを選択することができる。基準グリッド６１４により識別されたマクロブロックは、各ビデオゲームのゲーム状態に従って、すなわち、ユーザコマンドに従って変更することができる。各ゲームエンジン１８４８（図１８）内のシンセサイザモジュール１８５２（図１８）が、基準グリッド６１４の現在の状態を使用して、事前符号化マクロブロック６１２の適当なサブセットを選択し、且つ／又は適当なサブセットを基準グリッド６１４内の適当なインデックス（又は適当なポインタを使用して）に位置決めして、ビデオフレームを生成することができる。ゲーム資源の共用を可能にすると共に、この手法は、１つ又は複数のビデオゲームに対応するビデオフレームの生成に関連するインフラ及び／又はコストを低減することもできる。具体的には、ビデオフレームの生成は、対応するマクロブロック内の全ピクセルの比較ではなく、基準グリッド６１４の前の状態及び基準グリッド６１４の現在の状態に対応する２つのインデックス又はポインタ（マクロブロックへの）の比較を含むことができる。

図７は、少なくとも１つのビデオフレームを生成するプロセスの一実施形態７００を示す流れ図である。実施形態７００での動作は、事前符号化動作７１０及びビデオフレーム生成動作７２０にグループ化することができる。事前符号化動作７１０は、１つ又は複数のゲームサーバ１１６（図１）で実行してもよく、且つ／又はゲームアセットをケーブルテレビジョンシステム１００（図１）にロードする前にゲーム開発者又はゲーム配信者により実行されてもよい。事前符号化動作７１０は、１つ又は複数のマクロブロック（図６の事前符号化マクロブロック６１２等）及び／又は各マクロブロック内の１つ又は複数のブロックに対して二次元離散コサイン変換（ＤＣＴ）を実行すること（７１２）、量子化を実行すること（７１４）、及びランレングス符号化を実行すること（７１６）を含む。図８を参照してさらに後述するように、ＤＣＴ（７１２）により、マクロブロックについての画像情報に対応するいくつかのＤＣ係数及びいくつかのＡＣ係数セットが生成される。量子化（７１４）は、各マクロブロックの量子化係数を決定することを含む。ランレングス符号化（７１６）はハフマン符号化演算を含むことができる。

事前符号化動作７１０は、オプションとして、１つ又は複数の動きベクトル（再近傍ハーフセルに対する）及び／又は補正データ（７１８）を計算することを含んでもよく、動きベクトル及び／又は補正データは、動きベクトルのうちの１つに対応する変位後にマクロブロックに追加されて、ビデオフレームの最終マクロブロックを得る。マクロブロックの事前符号化は、ビデオゲームが、ビデオゲームの実行中に繰り返される既知のアニメーションシーケンスを含む場合に特に有用である。ビデオゲーム内のオブジェクトが異なるアニメーションシーケンス中に異なる方向に移動する場合、マクロブロックの２つ以上の動きベクトルを事前符号化することが有用であり得る。その結果として得られる１つ又は複数の動きベクトル及び／又は補正データは、対応するマクロブロック６１２（図６）のバンク６１０（図６）のうちの１つ又は複数に記憶することができる。動きベクトルの事前符号化（すなわち、１つ又は複数の動きベクトル及び／又は補正データの計算７１８）は、ＭＰＥＧ２等のＭＰＥＧ準拠圧縮で実施される動的動き推定（すなわち、オンザフライ動き推定）と異なることに留意する。

ビデオフレームの生成（７２０）中、隣接するマクロブロックが相互に関連付けられる（７２２）。相互関連付け動作（７２２）は、１つ又は複数のＤＣ係数を決定すること、各マクロブロックの１つ又は複数の動きベクトル、補正データ、及び／又は量子化係数の計算を完了することを含むことができる。その結果として得られるマクロブロックのデータストリームは、ＭＰＥＧ圧縮規格に準拠することができる。例示的な実施形態では、事前符号化７１０は、ＭＰＥＧ準拠ビデオフレームの生成に必要な符号化の略９０％を完了することができる。残りの１０％は、前又は後のマクロブロック内の情報に依存する相対的な情報を決定することを含み、これは、空間的且つ／又は時間的に隣接するマクロブロックを相互に関連付けること（７２２）により実現される。１つ又は複数のＤＣ係数を決定することについて、図８及び図９を参照してさらに後述し、量子化係数を決定することについて図９を参照してさらに後述し、１つ又は複数の動きベクトル及び／又は補正データの計算を完了することについても図１０を参照してさらに後述する。

流れ図７００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図８は、マクロブロック内のクロミナンスブロック及びルミナンスブロックの一実施形態８００を示すブロック図である。マクロブロックは、４つのルミナンス（Ｙ）ブロック８１０及び２つのクロミナンス（Ｕ及びＶ）ブロック８１２を含む。ブロック８１０及び８１２は、図７に示す事前符号化７１０に関連するＡＣ係数及びＤＣ係数を含む。例示的な実施形態では、ルミナンスブロック８１０は８×８ピクセルアレイに対応し、１つのクロミナンスブロック（クロミナンスブロック８１２−１等）はマクロブロックのＵ情報に対応し、１つのクロミナンスブロック（クロミナンスブロック８１２−２等）はマクロブロックのＶ情報に対応する。他の実施形態では、他の実施形態では、マクロブロックは、ＲＧＢ等のコンポジットビデオ情報に基づいて生成してもよく、実施形態８００でのブロックはそれに従って変更されてもよい。

図８中の各ルミナンスブロック８１０はＤＣ係数８１４を有し、各クロミナンスブロック８１２はＤＣ係数８１６を有する。ＤＣ係数８１４及び８１６は、マクロブロックの平均輝度及びクロミナンス（赤又は青）をそれぞれ指定する。ＤＣ係数８１４及び８１６は、隣接するブロックのＤＣ係数に相対する値としてマクロブロック８００内で表される。したがって、ＤＣ係数８１４＿２は、ルミナンスブロック８１０−２のＤＣ係数とルミナンスブロック８１０−１のＤＣ係数との差で表され、ＤＣ係数８１４＿３は、ルミナンスブロック８１０−３のＤＣ係数とルミナンスブロック８１０−２のＤＣ係数との差で表され、ＤＣ係数８１４＿４は、ルミナンスブロック８１０−４のＤＣ係数とルミナンスブロック８１０−３のＤＣ係数との差で表される。すなわち、これらＤＣ係数８１４はマクロブロック「内」で決定される。ＤＣ係数８１４＿１、ＤＣ係数８１６＿１、及びＤＣ係数８１６＿２は、隣接するマクロブロックに相対して決定される。これを、隣接するマクロブロックを相互に関連付ける一実施形態９００を示すブロック図である図９に示す。具体的には、ビデオフレーム９１０内の１つ又は複数の隣接するマクロブロック９１４を使用して、マクロブロック９１２の少なくとも３つのＤＣ係数を決定することができる。例示的な実施形態では、マクロブロック９１２のＤＣ係数の表現を計算する場合、マクロブロック９１４＿３が隣接するマクロブロックとして使用される。

マクロブロック９１２の量子化係数が、マクロブロック９１４＿３等の隣接するマクロブロックの量子化係数と異なる場合、図７の相互関連付け動作（７２２）は、量子化係数を、ビデオフレーム９１０に対応するデータストリーム内のマクロブロック９１２のヘッダに追加することを含むことができる。

上述したように、線形又は循環して所定のマクロブロックシーケンスを繰り返すアニメーションシーケンスは、ゲーム開発者にとって既知であるため、これらマクロブロックを、１つ又は複数の動きベクトル及び／又は補正データと共に事前符号化して記憶する（例えば、図６のバンク６１０のうちの１つ又は複数に）ことができる。事前符号化（７１０）（図７）中に計算された（７１８）（図７）動きベクトル及び／又は補正データは、相対的な情報を含む。その結果として、ビデオフレームが生成されるとき（７２０）（図７）に、その計算を完了することができる（すなわち、隣接するマクロブロックを相互に関連付けて、動きベクトル及び／又は補正データを完成することができる）。ＭＰＥＧ準拠の実施形態では、こういったアニメーションシーケンスの１つを含むビデオフレームが送信される場合、完全なイントラ符号化マクロブロックを送信するのではなく、動きベクトル及びデルタすなわちビデオの前のビデオフレームの領域に対する差分情報を含む予測可能マクロブロックを送信することができる。予測可能マクロブロック内の動きベクトルは、現在のビデオフレームのタイルを構築するための開始点として使用すべきピクセルアレイ（例えば、１６×１６ピクセルアレイ）のロケーションを示す。動きベクトルは、Ｔｘ＋Ｘピクセル及びＴｙ＋Ｙ等のタイルに相対する位置を示し、ここで、Ｔｘ、Ｔｙはタイルの位置であり、Ｘ、Ｙは動きベクトルにより指定される相対位置である。動きベクトルは、前のビデオフレームの２つ又は４つのタイルにかさなるアレイを指してもよい。動きベクトルがヌル値を有する場合、タイルの開始点は、前のビデオフレームでのタイルのピクセルアレイである。デルタすなわち差分情報は、現在のビデオフレーム内のタイルのピクセルアレイを生成するために、開始点ピクセルアレイをどのように変更すべきかを指定する。ＭＰＥＧ２等のＭＰＥＧ準拠圧縮には、数種類のマクロブロックがあることに留意する。イントラ符号化マクロブロックは自己完結型である。すなわち、ビデオフレーム内の対応するピクセルセットの画像情報を定義するために必要なすべての情報を含む。予測可能マクロブロックは、空のマクロブロック（ヘッダのみが送信される）から動きベクトル及びデルタすなわち差分情報（すなわち、相対情報）の両方を含むマクロブロックまでを範囲とするある部類の情報を含む。ＭＰＥＧ２圧縮及び各種マクロブロックについて、図１２〜図１４を参照してさらに後述する。

事前符号化（７１０）（図７）は、動きベクトル及び／又は補正データを計算する（７１８）（図７）ために、隣接するマクロブロックの動き探索を含むことができる。ビデオフレームの生成（７２０）（図７）中、各ゲームエンジン１８４８内のシンセサイザモジュール１８５２（図１８）は、事前符号化（７１０）（図７）中に計算された動き推定（動きベクトル及び／又は補正データ）が現在のゲーム状態に対して正確であるか（例えば、ダイアログボックスがアニメーションシーケンス内のマクロブロックに重なっていない）を検証することができる。これは、基準グリッド６１４（図６）内の、前のビデオフレーム内の１つ又は複数の予想ロケーションでの対応するマクロブロックインデックスの有無を調べることにより実現することができる。例示的な実施形態では、各アニメーションシーケンス内の１つの既知のオブジェクトが追跡される。ハーフピクセル精度を有する動きベクトルの場合、１６×１６ピクセルのソースアレイに重なる最高で４つの先行マクロブロック（又はマクロブロックロケーション）との比較を行うことができる。

図１０は、ビデオフレームを比較する一実施形態１０００を示すブロック図である。現在のビデオフレーム１０１２が前のビデオフレーム１０１０と比較されて、オブジェクト１０１６が識別される。この比較により、オブジェクト１０１６及び対応する変更領域１０１８を含む差分又はデルタ１０１４のマップが生成される。上述したように、このような比較は、事前符号化されたアニメーションシーケンスの動きを推定する際に使用することができる。後述するように、これは、図３及び図４において説明し、さらに後述するように、動的に生成又は符号化されるマクロブロックを使用してオブジェクト又はスプライトを含むビデオフレームを生成するために使用することもできる。

事前符号化マクロブロック及び動的生成マクロブロックの両方を使用するシステム及び方法の各種実施形態について説明するが、事前符号化マクロブロックと動的生成マクロブロックの各種の組み合わせを使用する多くのさらなる実施形態が可能である。ビデオゲームシステム（例えば、図１８に示すシステム）内のプロセッサの数及び速度に応じて、１つ又は複数のビデオフレーム内の画像情報を事前符号化することができる量は増減する。しかし、一般に、各ビデオゲーム内に、ユーザコマンドに応答するオブジェクトのサブセットがある。こういったオブジェクトの挙動は事前には分からないため、このようなオブジェクトは動的に符号化することができる。

事前符号化動作（７１０）（図７）中にエンコーダが利用できる追加時間がある場合、エンコーダは、ＤＣＴ（７１２）（図７）等の動作に浮動小数点演算を使用することができる。さらに、量子化演算（７１４）（図７）は、例えば、最高で３０個の候補値から各マクロブロックに最適な量子化係数を選択することができる。このような実施態様は優れた圧縮及び／又は画質を提供することができるが、時間がかかり得る。このため、オブジェクト又はスプライトの動的符号化は高速符号化を利用することができる。高速符号化は、ＤＣＴ演算（７１２）（図７）中に固定少数点（整数）乗算を含むことができる。さらに、各マクロブロックの量子化係数をより少数の組から選択してもよい。例えば、各（１６×１６）マクロブロックの量子化係数は、マクロブロック内の４つの８×８ブロックで最大の量子化係数であってもよい。その結果として得られるデータ速度が所望の上限を超える場合、所望の上限を実現する量子化係数を直接計算することができる。この量子化係数は部分最適（利用可能なすべてのビットが使用されることもあれば、使用されないこともある）であるが、事前符号化（７１０）（図７）中に使用される計算はより高速であることができる。したがって、動的符号化の場合、画質と符号化の全体時間とのトレードオフがあり得る。

１つ又は複数のオブジェクト又はスプライトに対応する１つ又は複数の動的生成マクロブロックは、１つ又は複数の事前符号化マクロブロックの少なくとも一部と組み合わせることができる。マクロブロック及びスプライトを組み合わせることは、ブレンドすなわち混合すること及び／又は重ね合わせることを含むことができる。例えば、ブレンドすることはアルファブレンドを含むことができ、この場合、オブジェクト又はスプライトの有効透明度がある範囲のピクセルにわたって変化する。重ね合わせは、事前符号化マクロブロックのどの部分が背景画像情報であるかを示すことができるクロマキーを利用することができる。事前符号化マクロブロック６１２（図６）のいくつかは、事前符号化ピクセル情報に加えて、組み合わせを容易にするために非圧縮ピクセル情報を含むことができる。例示的な実施形態では、ｍ×ｎサイズのマクロブロックのオブジェクト又はスプライトの動的生成マクロブロックは、変更領域１０１８（図１０）に対応し、ピクセル精度アラインメントによりｍ＋１×ｎ＋１マクロブロックアレイを含むことができる。組み合わせ中、オブジェクト又はスプライトは、ｎ＋１×ｍ＋１事前符号化マクロブロックアレイと組み合わせることができる。図１１は、ビデオフレーム１１１０内の事前符号化マクロブロック１１１２とオブジェクト１１１４とを組み合わせる一実施形態１１００を示すブロック図である。オブジェクト１１１４＿１がマクロブロック１１１２＿１に重ね合わせられる。オブジェクト１１１４＿２はマクロブロック１１１２＿２とブレンドされる。

上記説明に照らして、ビデオゲーム中、現在のビデオフレームは、基準グリッド６１４（図６）を使用して現在のゲーム状態に従って生成することができる。適当な事前符号化マクロブロック６１２（図６）を、基準グリッド６１４（図６）内の対応するインデックスに基づいて組み立てることができる。適当な事前符号化マクロブロックは、ビデオゲームの開始前及び／又はビデオゲームの開始時に（例えば、ユーザ名に対応するマクロブロック）符号化されている場合がある。適当な事前符号化マクロブロックを相互に関連付けることができる（７２２）（図７）。１つ又は複数のアニメーションシーケンスを現在のビデオフレームに含めることができる。１つ又は複数のアニメーションシーケンス内での１つ又は複数のマクロブロックの位置又はインデックスは、前のビデオフレームとの比較に基づいて、且つ／又は事前符号化動き推定（１つ又は複数の動きベクトル及び／又は補正データを含む）を使用して判断することができる。現在のビデオフレームが生成されるとき、事前符号化動き推定も相互に関連付ける（７２２）（図７）ことができる。ビデオゲームでのユーザコマンドに応答する、オブジェクト又はスプライトに対応する動的生成又は符号化マクロブロックは、オンザフライでリアルタイムに生成して、現在のビデオフレームに組み合わせることができる。組み合わせることは、動的生成マクロブロックを事前符号化マクロブロックの少なくとも一部にブレンドし、且つ／又は重ね合わせることを含むことができる。組み合わせを容易にするために、事前符号化マクロブロックのうちのいくつかを、非圧縮ピクセル情報と共に記憶することができる。

データストリーム
これより、ビデオゲームの１つ又は複数のビデオフレームに対応するピクチャグループ（ＧＯＰ：ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅ）及び関連データストリームの実施形態に注意を向ける。ＭＰＥＧ２等のＭＰＥＧ圧縮では、イントラ（Ｉ）フレーム及び予測可能（Ｐ）フレームを含む数種類のフレームがある。Ｉフレームは、フレーム内符号化マクロブロック（上述した）をそれぞれ含む複数のスライスを含む。Ｉフレーム内のマクロブロックはすべて存在しなければならない。Ｐフレームは複数のスライスを含む。スライスは、イントラ符号化マクロブロック及び予測可能マクロブロック（上述した）を含むことができる。各スライスは、少なくとも２つのマクロブロック（スライス内の最初と最後のマクロブロック）を有さなければならない。予測可能マクロブロックは空（すなわち、ヘッダのみが送信される）であってもよい。別法として、スライス内の１つ又は複数の予測可能マクロブロックをスキップしてもよい。後続するマクロブロックのアドレス増分により、何個のマクロブロックがスキップされたかを示す。４０列及び３０行を有するビデオフレームの例示的な実施形態では、３０個のスライスがある。Ｐフレームの場合、各スライスは、少なくとも、最初と最後のマクロブロックを有する。したがって、この実施形態での予測可能マクロブロックでのアドレス増分の範囲は１〜３９になる。

いくつかの実施形態では、ビデオゲームが開始されるとき、Ｉフレームが送信される。Ｉフレームは、結果として生じるデータ速度を上限未満に保つように、すべてのブラック画像に対応することができる。Ｉフレームが送信された後、ビデオゲーム中にデータストリームの残りの部分はＰフレームを利用することができる。Ｐフレームは、あるビデオフレームから次のビデオフレームへの相対すなわち差分情報を含むことができる。すなわち、Ｐフレームは更新情報を含むことができる（ＤＣ係数をＰフレーム内の前の符号化マクロブロックと相互に関連付ける必要がないことに留意する）。共通の事前符号化マクロブロックセット（前の段落で説明したように）を使用するビデオフレームが、略変わらないＡＣ係数（図７のＤＣＴ演算（７１２）に対応する）及び／又は略変わらない量子化係数（図７の量子化演算（７１４）に対応する）を有し得ることに留意する。

前のビデオフレームから変わらない現在のビデオフレーム内の画像情報は、送信しなくてもよい。これは、１つ又は複数の空の予測可能マクロブロック又はスキップされた予測可能マクロブロックを送信することにより実現することができる。ビデオフレーム全体が変わらないままである場合、スキップされた、又は空の予測可能マクロブロックを含むＰフレームを送信することができる。例示的な実施形態では、空のＰフレームは、２つの空の予測可能マクロブロックをそれぞれ含む３０個のスライスを有する。空のＰフレームの送信を利用して、ＳＴＢ１９００（図１９）内のデコーダ１９１４のアンダーフローを防ぐこともできる。Ｐフレームは、時間期間にわたって広がったスライスシーケンスとして送信することができる。これも、データ速度を上限未満にするのを助けることができる。このような制限付きデータ速度は、ケーブルテレビジョンシステム１００（図１）等のネットワーク環境での１つ又は複数のビデオゲームを１人又は複数のユーザに提供することに関連するインフラ及びコストを低減することができる。例えば、制限付きデータ速度は、１人又は複数のユーザの各データストリームが、一時的に、システム又はネットワーク１３６（図１）等のネットワークで利用可能な資源のかなりの割合を利用しないようにすることができる。例示的な実施形態では、上限は、Ｉフレームを含む対応するＭＰＥＧデータストリームの０．０３、０．１、０．０１６、０．２５、又は０．３３であってよい。データストリームは、毎秒３０個のＰフレームを含むことができる。いくつかの実施形態では、こういった技法の使用を通して実現される送信帯域幅の節減により、既存のビデオゲームシステムと比較して、１ゲームエンジン１８４８（図１８）当たり、ユーザ数又はユーザの組数を２０倍に増大することが可能になり得る。

上述したように、１つ又は複数のビデオフレーム内の事前符号化アニメーションシーケンスの場合、少なくとも動きベクトル及び／又は補正データをそれぞれ含むイントラ符号化マクロブロック又は予測可能符号化マクロブロックを使用することができる。マクロブロックの選択は、送信される情報量に依存し得る。そして、これは、１つ又は複数のビデオフレームの複雑性及び／又はビデオフレーム同士の差分又はデルタに依存し得る。いくつかの実施形態では、この選択はデータ速度に従う。シーケンスが実行される都度、すなわちシーケンスがデータストリームに含められる都度、アニメーションシーケンスに対応する事前符号化マクロブロックが、略変わらないＡＣ係数（図７のＤＣＴ演算（７１２）に対応する）及び／又は略変わらない量子化係数（図７の量子化演算（７１４）に対応する）を有することに留意する。

Ｐフレーム、特に予測可能マクロブロックの使用により、誤差が送信中及び／又は復号化中に発生した場合に問題が発生する恐れがある。このような誤差はあるビデオフレームから次のビデオフレームに伝搬し得る。無制限の伝搬を防ぐために、ローリングアップデートを使用することができる。イントラ符号化マクロブロックを含む１つ又は複数のスライス（すなわち、１つ又は複数のＩフレームスライス）を、時間間隔後にＰフレームに含めることができる。時間期間にわたり、いくつかのＰフレームを含め、完全なイントラ符号化マクロブロックセット（ビデオフレームのあらゆるタイル毎に少なくとも１つを含む）を送信することができ、それにより、現在のビデオフレームを既知の状態に「復元」することができる。例えば、Ｐフレーム速度が毎秒３０フレームであり、各フレームが３０個のスライスを含むシステムでは、各Ｐフレームは各Ｉフレームスライスを含むことができる。その結果として、ビデオフレームの全スライスが、毎秒に少なくとも１回復元される。別の実施形態では、１つ置きのＰフレームが各Ｉフレームスライスを含み、それにより、ビデオフレームの全スライスが２秒毎に１回復元される。本質的には、このようなローリングアップデートは、誤差修正の一形態として機能することができる。したがって、イントラ符号化マクロブロックの１つ又は複数のスライスは、ビデオフレームが略変わらない（例えば、ゲーム状態が略変わらない）ままであっても送信することができる。

図１２は、少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセス１２００の一実施形態を示す流れ図である。要求が受信される（１２１０）。例えば、要求は、ビデオゲームの実行要求であることができる。Ｉフレームを含む複数のマクロブロック（要求前に符号化される）が送信される（１２１２）。プロセス１２００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図１３は、少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセス１３００の一実施形態を示す流れ図である。要求が受信される（１２１０）。Ｉフレームを含む複数のマクロブロック（要求前に符号化される）が送信される（１２１２）。要求前に事前符号化されるサブセットを含む追加の複数のマクロブロックをそれぞれ含むＰフレームシーケンスが、送信される（１３１０）。Ｐフレームによっては、上述したように１つ又は複数のイントラ符号化スライスを含むものもあれば、１つ又は複数の空の、又はスキップされたマクロブロックを含むものもある。プロセス１３００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

図１４は、ビデオフレームシーケンスを含むデータストリーム１４００の一実施形態を示すブロック図である。Ｉフレーム１４１０及び複数のＰフレーム１４１４が送信される。Ｉフレーム１４１０は、複数のイントラ符号化マクロブロック１４１２を含む。Ｐフレーム１４１４−２等のいくつかのＰフレーム１４１４は、予測可能マクロブロック１４１６、１つ又は複数の空の予測可能マクロブロック１４１８、及び１つ又は複数のスキップされた予測可能マクロブロックを含む。予測可能マクロブロック内の１よりも大きなアドレス増分１４２２は、１つ又は複数の予測可能マクロブロックが予測可能マクロブロック１４１６−２等の予測可能マクロブロックの前に存在することを示す。Ｐフレーム１４１４−４等のいくつかのＰフレーム１４１４は、スライス１４２０等の１つ又は複数のスライスも含む。スライス１４２０はイントラ符号化マクロブロック１４１２を含む。

無限プレイフィールド
多くの既存のビデオゲームは、プレイフィールドに対応する大きなマップを含む。１人又は複数のユーザが、ユーザコマンドに従ってマップ内をスクロールする。しかし、１人又は複数のユーザは、随時、マップの小部分しか経験しない、又は見ない（例えば、ディスプレイ上で）。プレイフィールドが大きい（両方の次元で数千ピクセル）場合、随時必要とされるのが小部分のみであるにもかかわらず、相当量の情報がＳＴＢ１４０（図１）に伝達され得る。

既存のビデオゲームによっては、レジスタ及びゲーム状態を使用して現在のプレイフィールドを画定し、それにより、随時、ＳＴＢ１４０（図１）に伝達され得る情報量を低減することによりこの問題に対処するものがある。データストリーム１４００（図１４）等のＭＰＥＧ準拠データストリームの使用により、随時、ＳＴＢ１４０（図１）に伝達され得る情報量を低減しながら同時に、事実上、無限の範囲を有するプレイフィールドを実施する代替の手法を提供することができる。

具体的には、ＭＰＥＧ２は、ビデオフレームに対応するパケット化されたエレメンタリストリーム１６１４（図１６）に含めることができる２つの表示拡張ヘッダを定義している。シーケンス表示拡張（ＳＤＥ）が、表示される符号化情報量、すなわち表示サイズ又は倍率を定義し、ピクチャ表示拡張（ＰＤＥ）が各ビデオフレームのオフセットを定義する。

一実施形態では、ＳＤＥを使用して、符号化情報よりも小さなマクロブロックの可視部分を定義する。その結果として、有効プレイフィールドが、ＳＴＢ１４０に送信される完全なビデオフレームと比較して低減される。これを、ビデオフレーム１５００内の有効プレイフィールドの一実施形態を示すブロック図である図１５に示す。ビデオフレーム１５００はいくつかの行６１６及び列６１８を有するが、ＳＤＥ及びＰＤＥにより定義される表示画像１５１４は、ビデオフレーム１５００の各次元にガードバンド１５１０及び１５１２を有する。例示的な実施形態では、マクロブロックの行６１６が３０あり、マクロブロックの列６１８が４０あり、各ガードバンド１５１０、１５１２は１マクロブロック幅である。すなわち、随時、実際に表示される有効プレイフィールドは、２９マクロブロック×３０マクロブロックに対応するサイズを有する。

例えば、ユーザが、表示画像１５１４を右に移動するコマンドを発した場合、ＰＤＥの水平成分が１だけ増分される。ＰＤＥの水平成分が１５を超えた場合、すべてのマクロブロックをマクロブロック１個分、右にシフトした（ハーフピクセル３２個分の動きベクトル）ビデオフレームを再送信することができ、ＰＤＥが０にリセットされる。その後、ユーザが、表示画像１５１４を右に引き続き移動するコマンドを発した場合、ＰＤＥの水平成分が１５を超えたときに、ビデオフレームを再送信することができる。この例では、ビデオフレームの再送信は、Ｐフレーム内の一連のスライスを送信することを含み、各スライスは、動きベクトルを有する２つの予測可能マクロブロック及び表示画像１５１４にここで含まれた新画像情報（右側）に対応する１つのイントラ符号化マクロブロックを含む。このようにして、データストリーム１４００（図１４）のＭＰＥＧ準拠符号化により、ＳＴＢ１４０（図１）に送信される情報量が低減され、プレイフィールドが事実上無限の有効範囲を有することが可能になる。

待ち時間
データストリーム１４００（図１４）の符号化は、常に、結果として得られる画像の複雑性（データ速度）と品質とのトレードオフを表す。さらに、送信できる情報量は、あるビデオフレームから次のビデオフレームへの変化量及びデコーダ１９１４（図１９）でのデータバッファサイズの関数でもある。データバッファサイズは、ＳＴＢ１４０でのビデオフレームの復号化待ち時間に上限を設定する。

待ち時間は、データがデコーダ１９１４（図１９）に到来する時間とデータの復号化が開始される時間との間に差があることが多いため、発生する。通常、最大待ち時間は、等サイズのビデオフレームをデータバッファに送信する時間分である（復号化が開始されるときに、各ビデオフレームの送信が完了していなければならないため）。ＭＰＥＧ２圧縮を使用する既存のシステムでは、最大待ち時間は、通常、約３００ｍｓである。こういった既存のシステムは、多くの場合、この時間遅延を使用して、異なる量の情報（Ｉフレーム及び／又はＰフレーム）を必要に応じて送信する。すなわち、１つ又は複数のビデオフレームの送信を、この時間間隔中に拡張することができる。このようにして、既存のシステムはデータ速度を範囲内に保つことができる。

ビデオゲームは、この点に関してさらなる問題を課す。既存のＭＰＥＧエンコーダと異なり、ユーザコマンド（アクション）は事前に分からないため、データ速度は事前に割り振られない。すなわち、ビデオゲームエンコーダは先を見越すことができない。その結果として、最大待ち時間は非常に短く、例えば、１フレーム期間である。例示的な実施形態では、エンコーダでの待ち時間は５０ｍｓ未満（例えば、３０ｍｓ又は４０ｍｓ）であり、ゲームコントローラ１９２４（図１９）での遠隔制御に関連するあらゆる遅延を含む往復待ち時間は１００ｍｓ未満であり得る。待ち時間が短いことは、ビデオフレームを送信する時間が限られ（符号化が開始される前に）、したがって、データ速度を制限内に保つためにデータストリーム１４００（図１４）内の情報を分散させる時間窓が限られることを暗に示す。

上述した符号化手法は、この点に関していくつかの利点を提供する。特に、Ｐフレームの使用により、必要に応じて情報を分散させて、データレートを制限内に保ち、低待ち時間に対応することが可能になる。いくつかの実施形態では、ゲームエンジン１８４８（図１８）内のシンセサイザモジュール１８５２が、ビデオフレームへの更新のビット数が１フレーム期間の送信時間を超えると判断した場合、空及び／又はスキップされた予測可能マクロブロックのみ（又は別法として、空及び／又はスキップされた複数の予測可能マクロブロックを含む）１つ又は複数のＰフレームを、短時間期間（例えば、およそ３３．３３ミリ秒フレーム期間のうちの約１ミリ秒）中に送信し、それにより、デコーダ１９１４（図１９）のアンダーフローを防ぐことができる。次に、１フレーム期間を超える時間期間、場合によっては２つ以上のフレーム期間にわたって更新情報をＰフレームで送信することができる。例えば、３つの略空のＰフレーム（前のビデオフレームに対応する）を送信してから、更新情報を含むＰフレーム（すなわち、現在のビデオフレームに対応する）を、およそ３〜３．９フレーム期間にわたって送信し、それにより、データ速度を制限内に保つことができる。この手法が使用される場合、ＳＴＢ１４０（図１）は、画像変化及び／又は断続を低減する様式でテレビジョン１３８（図１）を更新することができる。例えば、ビデオフレームを増分的に更新してもよく（更新情報が受信されたときに）、又はすべての更新情報が受信された後に更新してもよい。

ＭＰＥＧデータストリームは、エンコーダとデコーダ１９１４（図１９）と同期をとれる（すなわち、待ち時間を定義できる）ようにするヘッダを含み、これらヘッダを使用して上記手法を実施し、データ速度を制限内に保つことができる。これを、データストリームの一実施形態１６００を示すブロック図を示す図１６に示す。プログラムクロックリファレンス（ＰＣＲ）時間１６１２と共にヘッダを含むトランスポートパケット１６１０が定期的に送信される（例えば、２００ｍｓ毎に）。ビデオフレームパケットのパケット化されたエレメンタリストリーム１６１４は、プレゼンテーションスタンプ時間（ＰＴＳ）１６１６を有するフレームヘッダ及び１つ又は複数のスライス１６１８を含む。各スライス１６１８は、２つ以上のマクロブロック１６２０を含む。ＰＣＲ時間は、デコーダ１９１４（図１９）でのデータの到来時間を定義する。ＰＴＳはＰＣＲ時間の時間基準内にある。すなわち、これは時間差又はデルタである。ＰＴＳは、デコーダでのビデオフレームの復号化及び提示の開始時間を定義する。通常、トランスポートパケット１６１０はおよそ１８８バイトを含み、パケット化されたエレメンタリストリーム１６１４はおよそ１０〜２００ｋＢを含む。

図１７は、少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセス１７００の一実施形態を示す流れ図である。ビデオフレームに対応するビット数が判断される（１７１０）。ビット数の送信に必要な時間長（送信時間）が判断される（１７１２）。送信時間がフレーム期間に対応する時間長を超えるか否かも判断される（１７１４）。送信時間がフレーム期間に対応する時間長を超える場合、複数の空又はスキップされたマクロブロックを含む１つ又は複数のＰフレームが送信される（１７１６）。プロセス１７００は、より少数の動作又は追加の動作を含んでもよい。さらに、２つ以上の動作を組み合わせてもよく、且つ／又は動作の順序を変更してもよい。

事前符号化ビデオ及びオーディオ
いくつかの実施形態では、１つ又は複数の事前符号化ビデオシーケンスを、合成されたビデオゲーム画像情報を含むビデオフレームと組み合わせることができる。例えば、ビデオゲームは、ビデオシーケンスが表示されるテレビジョン又は他の表示装置の画像を含むことができる。１つ又は複数の事前符号化ビデオシーケンスが、ビデオゲーム画像情報に対応する画像エリアの１つ又は複数のサブセットに含まれる場合、すなわち、ビデオフレームがビデオゲーム画像情報に対応し、事前符号化ビデオシーケンスを有する領域を含む場合、このような組み合わせは問題がより少ない。合成されたビデオゲーム画像情報は、ビデオシーケンスが占める１つ又は複数の矩形領域から除外することができる。しかし、ビデオゲーム情報が、事前符号化ビデオシーケンスに対応する画像エリアの１つ又は複数のサブセットに含まれる場合、すなわち、ビデオフレームが事前符号化ビデオシーケンスに対応し、ビデオゲーム画像情報を有する領域を含む場合、組み合わせはより困難であり得る。この場合、ビデオゲーム画像情報の符号化に使用される手法と互換性のある手法を使用して、事前符号化ビデオシーケンスを符号化することができる。したがって、事前符号化ビデオシーケンスは、ビデオゲーム情報と同じＧＯＰを有し、ひいては同じデータストリームフォーマットを有するように符号化することができる。これにより、ビデオシーケンスのビデオフレーム内の１つ又は複数のサブセットを、動き推定計算において動きソースとして使用されることから除外することができる。したがって、ビデオゲーム画像情報が事前符号化ビデオシーケンスを損なうことを回避しながら、２つのデータストリームを符号化領域で併合することができる。その結果として得られる各ビデオフレームのデータストリームは、ビデオシーケンスのマクロブロック及びビデオゲーム画像情報のマクロブロックを含むマクロブロックの組み合わせを有することになる。事前符号化ビデオゲームマクロブロックは、ビデオゲーム画像情報（複数のビデオフレームで略同じであり得る）よりも広範囲のＡＣ係数及び量子化値を有し得る。さらに、事前符号化ビデオシーケンスを有する１つ又は複数の領域内の動きベクトルは、ビデオゲーム画像情報を有する領域を参照せず、この逆も同様であり得る。

各ビデオゲーム内の１つ又は複数のビデオフレームは、オーディオ情報を含むこともできる。オーディオ情報は、事前圧縮ブロックを使用して生成することができる。各事前圧縮オーディオブロックは各ビデオフレームに対応することができる。すなわち、フレームベースで生成することができる。例示的な実施形態では、ドルビーオーディオ符号化−３（ＡＣ３）等のドルビーオーディオ符号化フォーマットを使用することができる。

いくつかの実施形態では、バックグラウンドサウンドを一時的に置き換えることにより、過渡音効果（ｔｒａｎｓｉｅｎｔ ｓｏｕｎｄ ｅｆｆｅｃｔ）を実施することができる。音楽等のバックグラウンドサウンドは、長時間にわたって複数のビデオフレーム中に提示することができる。過渡音効果は１つ又は複数のビデオフレームであるがバックグラウンドサウンドよりも短い時間間隔にわたって提示することができる。過渡音効果から元のバックグラウンドサウンドへの遷移をスムーズにするために、遷移中にいくつかのビデオフレームにわたってバックグラウンドサウンドを減衰させ、音量をゆっくりと上げることができる。

しかし、いくつかの実施形態では、バックグラウンドサウンド及び過渡音効果を一緒に混合することができる（すなわち、両方が略同時に存在することができる）。このような混合を実施する一方法は、事前符号化オーディオブロックを復号化し、混合を行い、次いでオーディオブロックを記録することである。代替の実施形態では、変更されたＡＣ３符号化フォーマットを使用することができる。既存のＡＣ３符号化は、５．１サラウンドサウンドチャネル（左前、右前、正面中央、左後、右後、及び低周波効果）に対応するオーディオを相互に関連付けて相互に混合する。代替の実施形態では、サラウンドサウンドチャネルのうちの１つ又は複数を含むチャネルの第１のサブセットがバックグラウンドサウンドに対応し、サラウンドサウンドチャネルのうちの１つ又は複数を含むチャネルの第２のサブセットが過渡音効果に対応することができる。チャネルの第１及び第２のサブセットは、別個に符号化することができる。これにより、オンザフライでの、すなわち符号化し、混合してから再び符号化することなく、バックグラウンドサウンドに対応する事前符号化ブロックと過渡音効果に対応する事前符号化ブロックとのブレンド又は混合を容易にすることができる。

ハードウェア及びデータ構造
これより、事前符号化マクロブロックを使用して１つ又は複数のビデオゲームに対応する１つ又は複数のビデオフレームを生成するハードウェアのいくつかの実施形態に注意を向ける。図１８は、ビデオゲームシステム１８００の一実施形態を示すブロック図である。ビデオゲームシステム１８００は、少なくとも１つのデータプロセッサ、ビデオプロセッサ、及び／又は中央演算処理装置（ＣＰＵ）１８１０と、１つ又は複数のオプションのユーザインタフェース１８１４と、他のコンピュータ、サーバ、及び／又は１つもしくは複数のＳＴＢ（図１のＳＴＢ１４０等）と通信するための通信インタフェース又はネットワークインタフェース１８２０と、メモリ１８２２と、これら構成要素を互いに結合する１つ又は複数の信号線１８１２と、を含むことができる。少なくとも、１つのデータプロセッサ、ビデオプロセッサ、及び／又は中央演算処理装置（ＣＰＵ）１８１０は、マルチスレッド又は並列処理に向けて構成されるか、又は構成可能であることができる。ユーザインタフェース１８１４は、１つ又は複数のキーボード１８１６及び／又はディスプレイ１８１８を有することができる。１つ又は複数の信号線１８１２は、１つ又は複数の通信バスを構成することができる。

メモリ１８２２は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、１つ又は複数のフラッシュディスクドライブ、１つ又は複数の光ディスクドライブ、及び／又は１つ又は複数の磁気ディスク記憶装置を含め、高速ランダムアクセスメモリ及び／又は不揮発性メモリを含むことができる。メモリ１８２２は、基本的なシステムサービスを処理し、ハードウェア依存タスクを実行するための手続き（又は命令セット）を含む、リナックス（ＬＩＮＵＸ）、ユニックス（ＵＮＩＸ）、又はウィンドウズ（ＷＩＮＤＯＷＳ）等のオペレーティングシステム１８２４を記憶することができる。メモリ１８２２は、通信手続き（又は命令セット）をネットワーク通信モジュール１８２６に記憶することもできる。通信手続きは、ＳＴＢ１４０（図１）等のＳＴＢを使用して１人又は複数のユーザと通信するため、且つビデオゲームシステム１８００内の他のサーバ及びコンピュータと通信するために使用される。

メモリ１８２２は、以下の要素又はこのような要素のサブセットもしくは上位セットを含むこともできる。すなわち、アプリケーションサーバモジュール１８２８（又は命令セット）、ゲームアセット管理システムモジュール１８３０（又は命令セット）、セッション資源管理モジュール１８３４（又は命令セット）、プレーヤ管理システムモジュール１８３６（又は命令セット）、セッションゲートウェイモジュール１８４２（又は命令セット）、マルチプレーヤサーバモジュール１８４４（又は命令セット）、１つ又は複数のゲームサーバモジュール１８４６（又は命令セット）、及びマクロブロックを記憶するバンク１８５６。ゲームアセット管理システムモジュール１８３０は、１つ又は複数のビデオゲームに対応する事前符号化ブロック及び実行可能コードを含むゲームデータベース１８３２を含むことができる。プレーヤ管理システムモジュール１８３６は、ユーザの氏名、アカウント情報、トランザクション情報、ＳＴＢ１４０（図１）でのビデオゲームの表示をカスタマイズするためのプリファレンス、プレイしたビデオゲームの高得点、プレイしたビデオゲームのランキング及び他のスキルレベル情報、及び／又は一時停止され、後で再開できるビデオゲームの永続的に保存されているゲーム状態等の情報を含むプレーヤ情報データベース１８４０を含むことができる。ゲームサーバモジュール１８４６の各インスタンスは、１つ又は複数のゲームエンジンモジュール１８４８、シンセサイザモジュール１８５２、及び１つ又は複数の圧縮エンジンモジュール１８５４を含むことができる。ゲームエンジンモジュール１８４８は、１つ又は複数のビデオゲームをプレイしている１組又は複数組のユーザに対応するゲーム状態１８５０を含むこともできる。バンク１８５６は、１つ又は複数のビデオゲームに対応する事前符号化マクロブロック１８５８、１つ又は複数のビデオゲームに対応するピクセル情報を有する事前符号化マクロブロック１８６０、及び／又は１つ又は複数のビデオゲームに対応する動的に生成又は符号化されるマクロブロック１８６２を含むことができる。

ゲームサーバモジュール１８４６は、ウィンドウズエクスプローラ（Ｗｉｎｄｏｗｓ Ｅｘｐｌｏｒｅｒ）、ネットスケープナビゲータ（Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ）、又はファイアフォックス（ＦｉｒｅＦｏｘ）からのモジラ（Ｍｏｚｉｌｌａ）等のブラウザアプリケーションを実行して、各ビデオゲームに対応する命令を実行することができる。しかし、ブラウザアプリケーションは、ゲームサーバモジュール１８４６内のビデオゲームコンテンツをレンダリングしないように構成されてもよい。コンテンツがゲームサーバにより表示されず、このようなレンダリングの回避により、各ゲームサーバが、レンダリングを回避しない場合で可能なよりも多くのゲーム状態を保持できるようになるため、ビデオゲームコンテンツのレンダリングは不必要であり得る。ゲームサーバモジュール１８４６は１つ又は複数のプロセッサを有することができる。ビデオゲームは複数のプロセッサにより並列に実行することができる。ゲームは、マルチスレッドオペレーティングシステムで実施することも可能である。

図１８は、いくつかの離散アイテムとしてビデオゲームシステム１８００を示しているが、本明細書において説明した実施形態の構造概略ではなく、むしろビデオゲームシステムに存在しうる各種特徴の機能的な説明を目的としている。実際には、当業者に認められるように、ビデオゲームシステム１８００の機能は、多数のサーバ又はコンピュータに分散してよく、この場合、各グループのサーバがこれら機能の特定のサブセットを実行する。図１８において別個に示されるアイテムを組み合わせてもよく、いくつかのアイテムを分けてもよい。例えば、図１８において別個に示されるいくつかのアイテムを１つのサーバで実施してもよく、１つのアイテムを１つ又は複数のサーバで実施してもよい。ビデオゲームシステム内の実際のサーバ数並びにゲームサーバモジュール１８４６及びゲームエンジンモジュール１８４８等の特徴がサーバにどのように割り振られるかは、実施態様毎に異なり、システムに記憶される情報量並びに／又はシステムがピーク使用期間中及び平均使用期間中に処理しなければならないデータトラフィック量に一部依存し得る。

図１９は、ＳＴＢ１４０（図１）等のセットトップボックス（ＳＴＢ）１９００の一実施形態を示すブロック図である。ＳＴＢ１９００は、ネットワーク１３６を使用して注文情報及びユーザアクションに対応する情報を送信し、ビデオゲームコンテンツを受信する。受信された信号はネットワークインタフェース１９１０を使用して処理されて、ビデオゲームコンテンツを含むデータストリーム内のヘッダ及び他の情報が取り除かれる。その結果得られる信号はチューナー１９１２において処理されて、１つ又は複数のサブチャネルに対応する周波数が選択され、そしてデコーダ１９１４において処理される。例示的な一実施形態では、デコーダ１９１４はＭＰＥＧ２デコーダである。他の実施形態では、デコーダ１９１４は、ＭＰＥＧ対応デコーダ又は別のビデオ圧縮規格のデコーダであってよい。デコーダ１９１４から出力されたビデオゲームコンテンツは、ディスプレイドライバ１９１６を使用してディスプレイ１９２２の駆動に適したフォーマットに変換される。ゲームコントローラ１９２４に入力されるユーザコマンド又はアクションは、デバイスインタフェース１９１８により受信され、ネットワークインタフェース１９１０に転送されて送信される。ＳＴＢ１９００は、オプションとして、キーボード、ボタン、及び／又は液晶ディスプレイもしくは他のディスプレイ等のユーザインタフェース１９２０を含むことができる。

ゲームコントローラ１９２４は、ソニープレイステーション（Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ）（登録商標）、任天堂（Ｎｉｎｔｅｎｄｏ）（登録商標）、セガ（Ｓｅｇａ）（登録商標）、及びマイクロソフトＸボックス（Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ）（登録商標）により提供されるもの等の専用ビデオゲームコンソール又はパーソナルコンピュータであることができる。ゲームコントローラ１９２４は、１つ又は複数のユーザアクションに対応する情報をゲームパッド、キーボード、ジョイスティック、マイクロホン、マウス、１つもしくは複数のリモコン、１つもしくは複数の追加のゲームコントローラ、又は音声認識技術を含むインタフェース等の他のユーザインタフェースから受け取ることができる。ディスプレイ１９２２は、テレビジョン、コンピュータ、又はビデオゲームコントローラ１９２４もしくは携帯電話等の携帯装置の陰極線管又は液晶ディスプレイであることができる。

ＳＴＢ１９００は、リナックス（Ｌｉｎｕｘ）、ＯＳ９、又はウィンドウズ（Ｗｉｎｄｏｗｓ）等の埋め込みオペレーティングシステム又は産業又は商用装置での使用に適したリアルタイムオペレーティングシステム（例えば、ウィンドリバーシステムズ社（Ｗｉｎｄ Ｒｉｖｅｒ Ｓｙｓｔｅｍｓ，Ｉｎｃ．）によるＶｘワークス（ＶｘＷｏｒｋｓ））を有することができる。

いくつかの実施形態では、ＳＴＢ１９００は、ビデオゲームコンテンツを表示する前に、受信したビデオゲームコンテンツに対してスムーズ化操作を実行することができる。いくつかの実施形態では、受信されたビデオゲームコンテンツは、受信されるとリアルタイムで復号化されてディスプレイ１９２２に表示される。他の実施形態では、ＳＴＢ１９００は、完全なビデオフレームを受信するまで、受信したビデオゲームコンテンツを記憶する。次に、完全なビデオフレームが復号化されてディスプレイ１９２２に表示される。

これより、事前符号化マクロブロックのバンク６１０（図６）の１つ等のデータ構造の一実施形態に注意を向ける。図２０は、事前符号化マクロブロックのバンク２０００内のデータ構造の一実施形態を示すブロック図である。バンク２０００は、事前符号化マクロブロック２０１２の複数のエントリ２０１０（イントラブロック及び予測ブロックの圧縮されたＡＣ係数及びイントラマクロブロックの第２、第３、及び第４のルミナンスブロックのＤＣ係数デルタ）、メタデータ２０１４、及びオプションの非圧縮ピクセル情報２０１６を含む。メタデータ２０１４は、量子化係数、１つ又は複数のＤＣ係数、及び／又はマクロブロックを比較することができる（１つ又は複数の動きベクトル及び／又は補正値を含む、動き推定を利用する事前符号化アニメーションシーケンスの場合に）最高で４つの他のマクロブロックに対応する情報を含むことができる。

記載のシステム及び方法は、ハードウェア及び／又はソフトウェアで実施することができる。命令は、高水準手続き型言語、オブジェクト指向プログラミング言語、アセンブリ言語、又は機械語で実施することができる。プログラミング言語は、コンパイラ型であってもよく、又はインタプリタ型であってもよい。さらに、汎用マイクロプロセッサ、特定用途マイクロプロセッサ、並びに特定用途向け集積回路を利用してよい。

本発明の特定の実施形態の上記説明は、例示及び説明のために提示されたものである。網羅的である、すなわち本発明を開示された厳密な形態に限定する意図はない。むしろ、多くの変更及び変形が上記教示に照らして可能であることを理解されたい。実施形態は、本発明及び当業者が意図する特定の用途に適した各種変更を有する各種実施形態を最良に利用できるように、本発明の原理及びその実際の応用を最良に説明するために選択され、説明されたものである。

ケーブルテレビジョンシステムの一実施形態を示すブロック図である。 少なくとも１つのビデオフレームを生成するプロセスの一実施形態を示す流れ図である。 少なくとも１つのビデオフレームを生成するプロセスの一実施形態を示す流れ図である。 少なくとも１つのビデオフレームを生成するプロセスの一実施形態を示す流れ図である。 少なくとも１つのビデオフレームを生成するプロセスの一実施形態を示す流れ図である。 事前符号化マクロブロックの１つ又は複数のバンク及び基準グリッドの一実施形態を示すブロック図である。 少なくとも１つのビデオフレームを生成するプロセスの一実施形態を示す流れ図である。 マクロブロック内のクロミナンスブロック及びルミナンスブロックの一実施形態を示すブロック図である。 隣接するマクロブロックを相互に関連付ける一実施形態を示すブロック図である。 ビデオフレームを比較する一実施形態を示すブロック図である。 事前符号化マクロブロックとビデオフレーム内のオブジェクトを結合する実施形態を示すブロック図である。 少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセスの一実施形態を示す流れ図である。 少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセスの一実施形態を示す流れ図である。 ビデオフレームシーケンスに対応するデータストリームの一実施形態を示すブロック図である。 ビデオフレーム内の有効プレイフィールドの一実施形態を示すブロック図である。 データストリームの一実施形態を示すブロック図である。 少なくとも１つのビデオフレームに対応するデータストリームを生成するプロセスの一実施形態を示す流れ図である。 ビデオゲームシステムの一実施形態を示すブロック図である。 セットトップボックスの一実施形態を示すブロック図である。 事前符号化マクロブロックのバンクのデータ構造の一実施形態を示すブロック図である。

Claims (16)

1. １つの又は複数のビデオゲームサーバ（１１６）を備えるビデオゲームシステムにおける方法であって、前記ビデオゲームサーバ（１１６）は、１つ又は複数の通信ネットワークによって前記ビデオゲームシステムに結合された複数のユーザ装置（１４０）にインタラクティブビデオゲームサービスを提供するように構成され、前記複数のユーザ装置（１４０）は、前記ビデオゲームシステムとは区別されており、前記複数のユーザ装置（１４０）のそれぞれは、ビデオデコーダと個別のディスプレイとを備えており、前記方法は、
   各ユーザ装置（１４０）から、ビデオゲームを開始する要求を受信する工程（２１０）と、
   前記各ユーザ装置（１４０）から、前記ビデオゲームにおける各ユーザのアクションに対応するコマンドを受信する工程と、
   前記ビデオゲームにおける各ユーザのアクションに対応するコマンドに応答して、複数の事前符号化マクロブロック（６１２）のバンク（６１０）に記憶された複数の事前符号化マクロブロック（６１２）を使用して前記ビデオゲームにおける各ユーザのアクションに対応する第１のビデオフレーム（９１０）を生成する工程（２１２）と、
   前記第１のビデオフレームを表示のために前記ユーザ装置（１４０）に送信する工程と、
   含む方法であって、
   前記第１のビデオフレーム（９１０）はＭＰＥＧ圧縮規格に準拠し、前記複数の事前符号化マクロブロック（６１２）は、前記ビデオゲームを開始する前記要求を受信する前に事前符号化され且つ前記バンク（６１０）に記憶される、方法。
2. 各事前符号化マクロブロックはピクセルセットに対応し、
   前記方法は、
   前記各事前符号化マクロブロックを事前符号化する工程（７１０）を含み、
   前記各事前符号化マクロブロックを事前符号化する工程（７１０）は、
   離散コサイン変換演算（７１２）、量子化演算（７１４）、及びランレングス符号化演算（７１６）を実行する工程を含み、
   前記生成する工程は、前記第１のビデオフレーム内の隣接する事前符号化マクロブロックを相互に関連付ける工程を含む、請求項１に記載の方法。
3. 前記事前符号化する工程は、動きベクトル及び補正データを計算する工程（７１８）を含む、請求項２に記載の方法。
4. 前記相互に関連付ける工程は、ルミナンス情報を含む第１のブロックの第１のＤＣ係数値（８１４）、クロミナンス情報を含む第２のブロックの第２のＤＣ係数値（８１６）、
   及びクロミナンス情報を含む第３のブロックの第３のＤＣ係数値（８１６）を決定する工程を含む、請求項２に記載の方法。
5. 前記複数の事前符号化マクロブロックのバンクは、個々にアドレス指定可能な事前符号化マクロブロックのバンクであり、
   前記複数の事前符号化マクロブロックのサブセットは、２つ以上のビデオゲーム間で共用される、請求項１に記載の方法。
6. 前記複数の事前符号化マクロブロックのサブセットは、２つ以上のビデオフレーム間で共用される、請求項１に記載の方法。
7. 前記複数の事前符号化マクロブロックは、ビデオゲームの２つ以上のインスタンス間で共用される、請求項１に記載の方法。
8. 前記第１のビデオフレームを生成する工程は、前記複数の事前符号化マクロブロックをグリッド（６１４）内の各位置に割り当てる工程をさらに含み、
   前記グリッドは、二次元アレイを含み、前記グリッド内の各位置には、ビデオフレームの生成時に対応するマクロブロックが割り当てられ、前記グリッド内の少なくとも複数の位置には、対応する事前符号化マクロブロックが割り当てられ、
   前記生成する工程は、前記グリッドの前の状態と前記グリッドの現在の状態とを比較する工程、及び該比較に従って、イントラマクロブロック及び予測可能マクロブロックを前記第１のビデオフレームに対応するデータストリームに選択的に含める工程を含む、請求項１に記載の方法。
9. 前記複数の事前符号化マクロブロックのサブセットは、非圧縮ピクセル情報を含む、請求項１又は８に記載の方法。
10. 複数のマクロブロックを動的に生成する工程をさらに含み、該動的に生成される複数のマクロブロックは、非圧縮ピクセル情報を含む前記記憶される複数の事前符号化マクロブロックのサブセットとオブジェクトに対応する画像情報との組み合わせを含む、請求項９に記載の方法。
11. 複数のユーザ装置（１４０）にインタラクティブビデオゲームサービスを提供するように構成された装置であって、前記複数のユーザ装置（１４０）は、１つ又は複数の通信ネットワークによって前記装置に結合され、前記装置とは区別されており、前記複数のユーザ装置（１４０）のそれぞれは、ビデオデコーダと個別のディスプレイとを備えており、前記装置は、
    メモリ（１８２２）と、
    プロセッサ（１８１０）と、
    前記メモリに記憶され、前記プロセッサにより実行されるように構成されるプログラム（１８４６）であって、各ユーザ装置（１４０）から、ビデオゲームを開始する要求を受信する（２１０）命令と、前記各ユーザ装置（１４０）から、前記ビデオゲームにおける各ユーザのアクションに対応するコマンドを受信する命令と、前記ビデオゲームにおける各ユーザのアクションに対応するコマンドに応答して、複数の事前符号化マクロブロック（６１２）のバンク（６１０）に記憶された複数の事前符号化マクロブロックを使用して前記ビデオゲームにおける各ユーザのアクションに対応する第１のビデオフレーム（９１０）を生成する（２１２）命令と、前記第１のビデオフレームを表示のために前記ユーザ装置（１４０）に送信する命令と、を含むプログラムと、
    を備え、
    前記第１のビデオフレーム（９１０）はＭＰＥＧ圧縮規格に準拠し、前記複数の事前符号化マクロブロック（６１２）は、前記ビデオゲームを開始する前記要求を受信する前に事前符号化され且つ前記バンク（６１０）に記憶される、装置。
12. 前記第１のビデオフレームを生成する命令は、前記複数の事前符号化マクロブロックをグリッド（６１４）内の各位置に割り当てる命令をさらに含む、請求項１１に記載の装置。
13. 前記ビデオゲームにおけるユーザアクションに対応するコマンドを受信する工程（４１０）と、
    前記要求を受信する前に事前符号化される複数の事前符号化マクロブロック、及び、前記要求を受信した後且つ前記コマンドを受信する前に符号化される複数の要求後符号化マクロブロックを使用して第２のビデオフレームを生成する工程（４１２）と、
    をさらに含む、請求項１に記載の方法。
14. 前記第２のビデオフレームを生成する工程（４１２）は、前記コマンドを受信した後に符号化される複数の動的符号化マクロブロックを使用する工程をさらに含む、請求項１３に記載の方法。
15. 前記ビデオゲームにおけるユーザアクションに対応するコマンドを受信する命令と、
    前記要求を受信する前に事前符号化される複数の事前符号化マクロブロック、及び、前記要求を受信した後且つ前記コマンドを受信する前に符号化される複数の要求後符号化マクロブロックを使用して第２のビデオフレームを生成する命令と、
    をさらに含む、請求項１１に記載の装置。
16. 前記第２のビデオフレームを生成する前記命令は、前記複数の事前符号化マクロブロック、前記複数の要求後符号化マクロブロック、及び前記コマンドを受信した後に符号化される複数の動的符号化マクロブロックを使用してビデオフレームを生成するようさらに構成される、請求項１５に記載の装置。

Images