JP2022141586A - 低遅延のために統合ｎｉｃと共有フレームバッファアクセスとを有するクラウドゲーミングｇｐｕ - Google Patents

Abstract

【課題】統合ネットワークインターフェースコントローラ（ＮＩＣ）と共有フレームバッファアクセスとを有するクラウドゲーミンググラフィックス処理ユニット（ＧＰＵ）のための方法及び装置を提供する。【解決手段】ＧＰＵは、統合されたエンコーダ／デコーダへの共有アクセスを提供する１つ以上のフレームバッファを含む。ＧＰＵはさらに、統合されたエンコーダ／デコーダに結合されている統合ＮＩＣと、１つ以上のフレームバッファに結合されている１つ以上のビデオ出力とを含む。ＧＰＵは、ビデオコーデックを使用して、又はゲームタイルエンコーダ及びデコーダを使用して、エンコード及びデコードされる、アウトバウンド及びインバウンドのゲーム画像コンテンツを処理するように構成されている。【選択図】図１

Description

クラウドゲーミングはオンラインゲームの一種で、データセンター（別名は「クラウド」）のリモートサーバ上でビデオゲームを実行し、ローカルクライアントソフトウェアを介して、ビデオコンテンツとしてプレーヤーのデバイスにストリーミングする。ローカルクライアントソフトウェアは、ビデオコンテンツをレンダリングし、リモートサーバにプレーヤーの入力を提供するために使用される。これは、ゲームがユーザのビデオゲームコンソール、パーソナルコンピュータ、又はモバイルデバイス上でローカルに実行される既存のゲーム手段とは対照的である。

遅延は、クラウドゲーミングの成功や、インタラクティブな家庭内ストリーミング（例えば、レンダリングにはＰＣ（パソコン）を使用するが、他の部屋のタブレットでプレイする）のために、最も重要な基準の１つである。今日使用されている１つのアプローチは、ビデオコンテンツをレンダリングし、グラフィックス処理ユニット（ＧＰＵ）を有する別個のグラフィックスカードを使用してストリーミングされるエンコードされた画像データを準備し、次いで、プラットフォームの中央処理ユニット（ＣＰＵ）及びネットワークカードを使用して、ネットワークを介してプレーヤーのデバイスに画像データをストリーミングすることである。しかし、ＧＰＵでレンダリング及び／又はエンコードされたデータは、まずメインＰＣ又はデバイスメモリにコピーされなければならず、次いで、送出される画像データのためにネットワークカードに転送されなければならないので、結果的にボトルネックとなる。

本発明は、装置であって、
グラフィックス処理ユニット（ＧＰＵ）を備え、グラフィックス処理ユニット（ＧＰＵ）は、
複数のフレームバッファと、
少なくとも１つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも１つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ／デコーダと、
統合されたエンコーダ／デコーダに結合されている統合ネットワークインターフェースコントローラ（ＮＩＣ）とを含む、装置を提供するものである。

また本発明は、統合ネットワークインターフェースコントローラ（ＮＩＣ）を有するグラフィックス処理ユニットＧＰＵを含むグラフィックスカードに実施される方法であって、
ビデオフレームコンテンツを生成し、ＧＰＵ上の１つ以上のフレームバッファにビデオフレームコンテンツをバッファリングするステップを備え、
ＧＰＵに統合されたビデオコーデックを使用して、ビデオフレームコンテンツをエンコードし、エンコードされたビデオコンテンツを生成するステップと、
統合ＮＩＣを使用して、エンコードされたビデオコンテンツをパケット化し、パケットのストリームを生成し、統合ＮＩＣ上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットのストリームを送信するステップと、
又は、
ＧＰＵに統合された画像タイルエンコーダを使用して、ビデオフレームコンテンツのタイルをエンコードし、エンコードされたビデオタイルを生成するステップと、
統合ＮＩＣを使用して、エンコードされたビデオタイルをパケット化し、パケットのストリームを生成し、統合ＮＩＣ上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットのストリームを送信するステップと
のうちの一方を備えている、方法を提供するものである。

さらに本発明は、クラウドゲームサーバであって、
複数の拡張スロット又はコネクタを有する第１ボードと、
第１ボード又は第２ボードに搭載されている中央処理ユニット（ＣＰＵ）であり、第２ボードは、拡張スロットにインストールされているか、又は第１ボード上の嵌合コネクタに結合されている、中央処理ユニット（ＣＰＵ）と、
ＣＰＵに通信接続されている１つ以上のメモリデバイスを含むメインメモリと、
ａ）それぞれの拡張スロットにインストールされている１つ以上のネットワークアダプタカード、又は、
ｂ）第１ボード又は第２ボードに搭載されている１つ以上のネットワークインターフェースコントローラ（ＮＩＣ）チップと、
それぞれの拡張スロットにインストールされている、又は第１ボード上の各嵌合コネクタに結合されている複数のグラフィックスカードとを備え、
各グラフィックスカードは、
グラフィックス処理ユニット（ＧＰＵ）を含み、グラフィックス処理ユニット（ＧＰＵ）は、
１つ以上のフレームバッファと、
少なくとも１つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも１つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ／デコーダと、
統合されたエンコーダ／デコーダに結合されている統合ネットワークインターフェースコントローラ（ＮＩＣ）と、
ＧＰＵに結合されているか、又はＧＰＵに統合されているグラフィックスメモリと、
統合ＮＩＣに結合されている少なくとも１つのネットワークポートと、
ＧＰＵに結合されている入出力（Ｉ／Ｏ）インターフェースと
を備えている、クラウドゲームサーバを提供するものである。

本発明の上述の態様、及び多くの付随する利点は、以下の詳細な説明を添付図面と併せて参照することによりさらによく解釈され、容易に理解されるものである。図面において特にことわらない限り、同様の符号は種々の図面の全体を通じて、同様の部分を指す。

一実施形態に係り、統合されたビデオコーデックと統合されたＮＩＣとを有するＧＰＵを含む、グラフィックスカードの概略図である。 一実施形態に係り、ＮＩＣに直接結合されている統合されたビデオコーデックを有するＧＰＵを含む、グラフィックスカードの概略図である。 一実施形態に係り、統合されたビデオコーデックを有するＧＰＵと、マルチチップモジュール上に組み合わされたＮＩＣとを含む、グラフィックスカードの概略図である。 一実施形態に係り、統合されたタイルエンコーダ／デコーダと統合されたＮＩＣとを有するＧＰＵを含む、グラフィックスカードの概略図である。 一実施形態に係り、ゲームサーバとゲームクライアントデバイスとでの図１のグラフィックスカードの使用を示す概略図である。 一実施形態に係り、ゲームサーバとゲームクライアントデバイスとでの図１ａのグラフィックスカードの使用を示す概略図である。 一実施形態に係り、ゲームサーバにおける図１のグラフィックスカードの使用を図示し、ＷｉＦｉチップと直接通信するための統合ネットワークインターフェースを備えたＧＰＵを含むゲームラップトップクライアントを図示する概略図である。 Ｉフレームと、Ｐフレームと、Ｂフレームとから構成される例示的なフレームエンコード及び表示方式を示す概略図である。 一実施形態に係り、ゲームサーバ２００とデスクトップゲームクライアント２０２との間のエンドツーエンドの画像データフローの例を示す概略図である。 一実施形態に係り、図５のエンドツーエンド画像データフロースキームを容易にするために実行される操作を示すフローチャートである。 一実施形態に係り、統合されたタイルエンコーダを有するＧＰＵを使用したゲームタイルの生成、エンコード及びストリーミングを示す図である。 一実施形態に係り、統合されたタイルデコーダを有するＧＰＵを使用したタイルデコード及び再生を含む、ゲームクライアントで受信されたゲームタイルのストリームの扱いを示す図である。 一実施形態に係り、複数のグラフィックスカードと、メインボードの拡張スロットにインストールされた１つ以上のネットワークカードとを含む、ゲームサーバの概略図である。 一実施形態に係り、ＮＩＣチップが搭載されたメインボードの拡張スロットにインストールされた複数のグラフィックスカードを含む、ゲームサーバの概略図である。 一実施形態に係り、複数のグラフィックスカードと、バックプレーン、ミッドプレーン、又はベースプレーンのスロット又は嵌合コネクタにインストールされたブレードサーバとを含む、ゲームサーバの概略図である。 一実施形態に係る統合ＮＩＣを示す概略図である。

一層低い遅延のために統合ネットワークインターフェースコントローラ（ＮＩＣ）と共有フレームバッファアクセスとを有する、クラウドゲーミングＧＰＵのための方法及び装置の実施形態を、ここで説明する。以下の記載では、本発明に係る実施形態の完全な理解をもたらすため、数多くの具体的で明細な詳細が説明される。しかし、当業者であれば、１つ以上の具体的な詳細を使用せずに、又は、他の方法、コンポーネント、材料などを使用して本発明が実施されてよいことを認識することである。本発明の態様を曖昧にすることを避けるため、他の例における、周知の構造、材料又は操作について図示又は詳述しないこととする。

本明細書を通じて、「一実施形態」又は「実施形態」へ言及することは、本発明の少なくとも１つの実施形態に、その実施形態に関連して述べられる特別な特徴、構造又は特質が含まれることを意味する。従って、本明細書を通してさまざまな箇所における表現「一実施形態での」又は「実施形態での」の全てが、必ずしも同一の実施形態に言及するわけではない。さらに、特別な特徴、構造又は特質は１つ以上の実施形態で任意の適当な方式で組み合わせられてよい。

明瞭にするために、本明細書中の図中の個別のコンポーネントは、特定の参照番号によってではなく、図中のそれらの標識付けによって参照される場合がある。さらに、（特定のコンポーネントとは対照的に）特定のタイプのコンポーネントを参照する参照番号は、参照番号の後に「典型的」を意味する「（ｔｙｐ）」を付けて示す場合がある。これらのコンポーネントの構成は、存在し得るが簡潔さ及び明快さのために図面には示されない類似のコンポーネントのうちで代表的であり、又は別個の参照番号で標識付けされない他に類似のコンポーネントのうちで代表的であることが、理解されるものである。反対に、「（ｔｙｐ）」は、その開示された機能、器具、目的などのために、コンポーネント、要素などが典型的に使用されることを意味するものと解釈されないものとする。

本明細書に開示される実施形態の態様によれば、統合されたエンコーダと統合されたＮＩＣとを有するＧＰＵが提供される。ＧＰＵは、統合されたエンコーダ／デコーダ及び他のＧＰＵコンポーネントへの共有アクセスを提供する１つ以上のフレームバッファを含む。ＧＰＵは、ビデオコーデックを使用して、又はゲームタイルエンコーダ及びデコーダを使用してエンコード及びデコードされる、アウトバウンド及びインバウンドのゲーム画像コンテンツを処理するように構成される。例えば、ローカルビデオゲームホストのクラウドゲームサーバに実施されると、ＧＰＵによって生成され、フレームバッファにバッファされたビデオゲームフレームは、統合されたエンコーダによってエンコードされ、メディアストリーミングプロトコルを使用してパケット化及びストリーミングされるために直接ＮＩＣに転送される。インバウンドでストリーミングされたメディアコンテンツは、ＮＩＣによってデパケット化され、統合されたデコーダによってデコードされ、統合されたデコーダは、デコードされたコンテンツをフレームバッファに書き込み、ゲームクライアントデバイス上でビデオゲームフレームを再生する。次に、ビデオゲームフレームがクライアントデバイスディスプレイに表示される。

一般に、ＧＰＵは、グラフィックスカードに実施してよく、又はラップトップ又はノートブックコンピュータ又はモバイルデバイスのようなゲームクライアントデバイスのメインボードに実施してよい。処理パスはＣＰＵとの間でエンコードされたデータを転送することを含まないので、グラフィックスカードは、アウトバウンドゲームコンテンツを生成するとき、及びインバウンドゲームコンテンツを処理するときのために、遅延を短縮する。

図１は、フレームバッファ１０４を有するＧＰＵ１０２を含むグラフィックスカード１００を示す。フレームバッファ１０４は、インターフェース１０８を介してＨ．２６４／Ｈ．２６５ビデオコーデック１０６によってアクセスされる。Ｈ．２６４／Ｈ．２６５ビデオコーデック１０６は、この実施形態ではＧＰＵ１０２に搭載されているＮＩＣ１１２に結合されたＩ／Ｏインターフェース１１０を含む。ＧＰＵ１０２は、図示の実施形態では、ＧＤＤＲ５メモリのようなグラフィックスメモリ１１４に結合されている。他のタイプのグラフィックメモリも同様に使用することができる。さらに、グラフィックスメモリの全部又は一部は、ＧＰＵ上に存在してよい。

ＧＰＵ１０２とグラフィックスカード１００とは、ＧＰＵ１０２に結合されたＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インターフェース１１６と、ＤｉｓｐｌａｙＰｏｒｔ又はＨＤＭＩポートなどの１つ以上のグラフィックスポート１２０に結合されたＧＰＵ１０２上のグラフィックス出力１１８と、ＮＩＣ１１２に結合されたイーサネット（登録商標）ポート１２２とを含む、追加のインターフェースを有する。データパス１２３によって示されるように、ＮＩＣ１１２はまた、ＰＣＩｅインターフェース１１６を介してホストＣＰＵ（図示せず）と通信してよい。

オンチップＮＩＣを有するＧＰＵを有することに加えて、図１ａのグラフィックスカード１００ａに示されるように、グラフィックスカードは、オフチップＮＩＣに結合されたＧＰＵを含んでよい。この構成の下では、ＧＰＵ１０２ａは、ＮＩＣ１１２ａに結合されたＩ／Ｏインターフェース１２４を含む。Ｉ／Ｏインターフェース１２４は、Ｈ．２６４／Ｈ．２６５ビデオコーデック１０６上のＩ／Ｏインターフェース１１０に結合されている。ＮＩＣ１１２ａはまた、リンク１２５によって示されるように、ＰＣＩｅインターフェース１１６に結合されている。

ＧＰＵ上にＮＩＣを統合すること（例えば、埋め込み回路として、及び／又はＧＰＵ回路と同じ基板上の回路ダイとして）に加えて、ＧＰＵチップとＮＩＣチップとを含むマルチチップモジュール又はパッケージを、さらに使用してよい。この一例が図１ｂに示され、グラフィックスカード１００ｂはＧＰＵ１０２ｂとＮＩＣ１１２ｂとを含み、これらはマルチチップモジュール１２６の一部である。

別の実施形態（図示せず）では、ＣＰＵ及びＧＰＵ１００又は１００ａは、システムオンチップ（ＳｏＣ）に統合されてよい。あるいは、ＣＰＵ、ＧＰＵ１００ｂ、及びＮＩＣ１１２ｂは、マルチチップモジュール又はパッケージ、又はＣＰＵ＋ＧＰＵ ＳｏＣで実施されてよく、ＮＩＣチップは、マルチチップモジュール又はパッケージで実施されてよい。

一般に、グラフィックスカード１００、１００ａ、及び１００ｂは、サーバなどのＰＣＩｅスロットにインストールされ、サーバのメザニンカードなどとして実施され、ブレードサーバ又はサーバモジュールのドーターボードとして実施される。以下に説明及び例示するように、ラップトップ、ノートブック、タブレット、及び携帯電話のような他の形態ファクタを有するデバイスのために、同様のコンポーネントをグラフィックスチップセットなどで実施してよい。

フレーム情報は、フレームの画素解像度、フレームバッファフォーマット（例えば、ＲＧＢＡ８ビット又はＲＧＢＡ３２ビットなど）、及びフレームバッファポインタへのアクセスのようなフレームバッファ１０４から取得してよい。これは、レンダリングのために二重又は三重のバッファリングが使用される場合に経時的に変化する可能性がある。さらに、いくつかの実施に対して、色データ情報に加えて、ＧＰＵバッファからの深度データを取得してよい。例えば、立体ゲーミングのようなシナリオでは、色データとともに深度データをクライアントにストリーミングすることが有利である場合がある。

図２は、ネットワーク２０４を介してデスクトップゲームクライアント２０２に結合されたゲームサーバ２００を含む、クラウドゲーミングの実施の一実施形態を示す。ゲームサーバ２００とデスクトップゲームクライアント２０２との各々は、グラフィックスカード１００－１及び１００－２によって示されるように、図１のグラフィックスカード１００のそれぞれのインスタンスを有する。ゲームサーバ２００は、メインメモリ２０８に結合されたマルチコアプロセッサからなるＣＰＵ２０６を含み、この中で、ゲームサーバソフトウェア２１０は、ＣＰＵ２０６の１つ以上のコア上で実行されるようにロードされる。ＣＰＵ２０６は、ＰＣＩｅインターフェース１１６を介してグラフィックカード１００－１に結合され、イーサネットポート１２２－１は、インターネットのような複数の相互接続されたネットワークを表すネットワーク２０４に結合される。

実際には、クラウドゲームサーバは、配信ネットワーク（ＣＤＮ）２２８を介してコンテンツを配信することができる。図２に示すように、ＣＤＮ２２８は、ゲームサーバ２００とネットワーク２０４との間に位置する。

デスクトップゲームクライアント２０２は、一般に、デスクトップコンピュータなどを使用して実現されてよい種々のタイプのゲームクライアントを示す。図示の実施形態では、グラフィックスカード１００－２は、デスクトップコンピュータのＰＣＩｅスロットにインストールされたＰＣＩｅグラフィックスカードである。場合によっては、デスクトップコンピュータ用の複数の拡張スロットを占有する１つのＰＣＩｅスロットを介して、ＰＣＩｅグラフィックスカードを接続してよい。デスクトップゲームクライアント２０２は、ＣＰＵ２１２を含み、これは、クライアント側のゲームソフトウェア２１６がロードされたメインメモリ２１４に結合されたマルチコアプロセッサであり、ＣＰＵ２１２上の１つ以上のコアによって実行される。グラフィックスカード１００－２のイーサネットポート１２２－２は、ネットワーク２０４に結合される。典型的なゲームプレーヤーの場合に、デスクトップゲームクライアント２０２は、ローカルエリアネットワーク（ＬＡＮ）に結合される。これはケーブルモデム又は類似のワイドエリアネットワーク（ＷＡＮ）アクセスデバイスに結合されるスイッチを含む。これはインターネットサービスプロバイダ（ＩＳＰ）ネットワーク２１８に結合される。これは次にネットワーク２０４に結合される。

図２ａは、ネットワーク２０４とＩＳＰネットワーク２１８とを介してデスクトップゲームクライアント２０２ａに結合された、ゲームサーバ２００ａを含むクラウドゲーミング実施の一実施形態を示す。ゲームサーバ２００ａとデスクトップゲームクライアント２０２ａとの各々は、グラフィックスカード１００ａ－１及び１００ａ－２として示された、図１ａのグラフィックスカード１００ａのそれぞれのインスタンスを有する。一般に、図２及び図２ａにおける同様の番号のコンポーネント及びブロックは、類似のものであり、類似の動作を行う。以下にさらに詳細に説明するように、図２及び図２ａのクラウドゲーミングの実施間の差は、出力の（ｏｕｔ）ビデオ制御入力であり、非画像データが処理される。同時に、図２及び図２ａの実施形態における画像データの処理及び転送は、類似する。

図３は、ＣＤＮ２２８と、ネットワーク３０３と、ＩＳＰネットワーク３１８とを介して、ラップトップゲームクライアント３０１に結合されたゲームサーバ２００を含む、クラウドゲーミングの実施を示す。ゲームサーバ２００は、上述のものと同じ、図２に示される構成を有する。任意には、ゲームサーバ２００は、図２のゲームサーバ２００ａによって置き換えられてよい。

ラップトップゲームクライアント３０１はメインボード３００を含み、これは、グラフィックスメモリ３１４に結合されたＧＰＵ３０２と、メインメモリ３２８及びＧＰＵ３０２に結合されたＣＰＵ３２６と、ＷｉＦｉ（登録商標）チップ３１５と、ＤｉｓｐｌａｙＰｏｒｔ及び／又はＨＤＭＩポート３２０と、ＵＳＢ－Ｃインターフェース３３２とを備えている。前と同様に、クライアント側のゲームソフトウェアは、メインメモリ３２８にロードされ、ＣＰＵ３２６上の１つ以上のコア上で実行される。ＧＰＵ３０２は、インターフェース３０８を介してＨ．２６４／Ｈ．２６５ビデオコーデック３０６によってアクセスされるフレームバッファ３０４を含む。Ｈ．２６４／Ｈ．２６５ビデオコーデック３０６は、ネットワークインターフェース３１３に結合されるＩ／Ｏインターフェース３１０を含み、これはハードウェアベースのネットワークスタック３１７に結合されている。概括的に、ハードウェアベースのネットワークスタック３１７は、ＷｉＦｉ（登録商標）チップ３１５上に統合されてよく、又は別のコンポーネントを含んでよい。概括的に、ＵＳＢ－Ｃ、ＵＳＢ３．０、ＵＳＢ２．０及びＰＣＩｅ相互接続などの様々な通信ポートとＩ／Ｏ相互接続とをサポートする、ＣＰＵ３２６に結合されたモバイルチップセット（図示せず）を、ラップトップゲームクライアントは含む。

ラップトップゲームクライアント３０１のための例示した構成の下では、無線アクセスポイント３２４とアンテナ３１９とによって無線通信が促進される。前述のように、無線アクセスポイントは、ＩＳＰネットワーク３１８に接続されるようにするケーブルモデム又は類似のＩＳＰアクセス手段に接続される。任意には、イーサネットアダプタをＵＳＢ－Ｃインターフェース３３２に接続してよく、ラップトップゲームクライアント３０１が、（イーサネットスイッチ及びケーブルモデムを介して）ＩＳＰネットワーク３１８へのイーサネットリンクを使用することを可能にする。

メインボード３００は、ディスプレイ３３４が結合されるラップトップハウジング内に収容される。概括的に、ＧＰＵ３０２に内蔵されているか、又はＬＣＤドライバ３３６によって示されるように、ＧＰＵ３０２に結合された個別のコンポーネント上に実施されている適用可能な回路によって、ディスプレイは駆動される。

本明細書の実施形態では、ＣＰＵ上で動作するソフトウェア（オペレーティングシステム及び／又はＮＩＣドライバなど）、プラットフォーム／サーバファームウェア、及び／又はＣＰＵ上で動作するソフトウェア又はプラットフォーム／サーバファームウェアから構成情報を受信するＧＰＵを介して、ＮＩＣは構成されてよい。例えば、いくつかの実施形態では、ＮＩＣは、ＰＣＩｅエンドポイントとして実施され、ＣＰＵによって管理されるＰＣＩｅ相互接続構造のＰＣＩｅ階層の一部である。他の実施形態では、ＧＰＵ上のソフトウェアは、ＮＩＣを構成する方法についての命令をＧＰＵに提供する。

ビデオエンコード及びストリーミングの手引書

本明細書に開示される実施形態の態様の下では、プレーヤー（別名はプレーヤーデバイス）によって操作されるエンドユーザデバイスに、遅延を減少させる方式でビデオゲーム画像データをストリーミングするための技術が提供される。フレームエンコード及びデコードを使用する場合のビデオゲーム画像データのストリーミングの態様は、ビデオストリーミングに使用されるのと同じコーデック（コーダ／デコーダ）を使用してよい。従って、実施形態がどのように実施されてよいかを一層よく理解するために、ビデオ圧縮及び解凍技術の基本的態様の説明が最初に提供される。本明細書の詳細に加えて、ビデオ圧縮及び解凍がどのように実施されるかに関するさらなる詳細は、多くのオンラインソースから入手可能である。これは、後述する説明の多くの情報源である、
http://www.eetimes.com/document.asp?doc_id=1275437
で入手可能な「ビデオ圧縮はどのように作用するか」と題するEE Times.comの記事を含む。

基本的なレベルでは、ストリーミングビデオコンテンツは、「フレーム」又は「ピクチャー」のシーケンスとしてディスプレイ上でプレイバックされる。各フレームは、レンダリングされると、プレイバック解像度に対応する寸法を有する画素のアレイから構成される。例えば、フルＨＤ（ハイビジョン）ビデオは、１９２０水平画素×１０８０垂直画素の解像度を有し、これは一般に１０８０ｐ（プログレッシブ）又は１０８０ｉ（インターレース）として知られている。次に、フレームはフレームレートで表示され、フレームのデータがフレームレートでリフレッシュ（該当する場合は、再レンダリング）される。長年にわたり、標準精細度（ＳＤ）テレビは、３０ｉ（毎秒３０フレーム（ｆｐｓ）インターレース）のリフレッシュレートを使用した。これは、１／３０秒毎に交互に、インターレースビデオコンテンツの２つのフィールドを更新することに相当する。これは、フレーム速度が毎秒６０フレームであるという錯覚を生じさせた。また、ＳＤコンテンツは歴史的にアナログビデオであり、画素ではなくラスタ走査をディスプレイに使用していたことにも留意するものとする。デジタルディスプレイ上のＳＤビデオの解像度は４８０ラインであり、数十年間使用されてきたアナログ信号は、実際には約５２５走査ラインを有していた。その結果、ＤＶＤコンテンツは歴史的に、米国などのＮＴＳＣ（全米テレビジョンシステム委員会）市場では、４８０ｉ又は４８０ｐでエンコードされてきた。

ケーブルテレビや衛星テレビのプロバイダは、ビデオコンテンツを光ケーブルや有線ケーブル、あるいは大気（長距離無線）を介してストリーミングする。地上波の放送も同様に、空気中で送信され、従来はアナログ信号として放送されていたが、２０１０年頃からは全ての大電力テレビ放送局がデジタル信号のみを使用して放送することが必要とされている。米国におけるデジタルテレビ放送信号は、一般的に４８０ｉ、４８０ｐ、７２０ｐ（１２８０×７２０画素解像度）、１０８０ｉを含む。

ブルーレイ（登録商標）ディスク（ＢＤ）ビデオコンテンツは、２００３年に日本で導入され、２００６年に正式にリリースされた。ブルーレイディスクは、最大１０８０ｐでビデオプレイバックをサポートする。これは、６０（５９．９４）ｆｐｓで１９２０×１０８０に相当する。ＢＤは６０ｆｐｓまでサポートするが、ＢＤコンテンツの多く（特に最近のＢＤコンテンツ）は、実際には２４ｆｐｓプログレッシブ（１０８０／２４ｐとしても知られる）でエンコードされる。これは、フィルム（映画）に歴史的に使用されてきたフレームレートである。２４ｆｐｓから６０ｆｐｓへの変換は、典型的には、３：２の「プルダウン」技術を使用して行われ、その下で、フレームコンテンツが３：２のパターンで繰り返され、これは、特に、多くの動きのあるコンテンツをプレイバックするときに、様々なタイプのビデオアーチファクトを生じる可能性がある。さらに新しい「スマート」テレビは、１２０Ｈｚ又は２４０Ｈｚのリフレッシュレートを有し、それぞれが２４の偶数倍の数である。その結果、これらのテレビは、ＨＤＭＩ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）デジタルビデオ信号を使用して２４ｆｐｓ「ムービー」又は「シネマ」モードをサポートし、抽出されたフレームコンテンツを５：５又は１０：１０プルダウンで繰り返して、２４ｆｐｓコンテンツを１２０ｆｐｓ又は２４０ｆｐｓで表示し、テレビのリフレッシュレートにマッチングさせる。さらに最近では、ソニーやサムスンなどのメーカーが出しているスマートテレビは、スムージング効果を作り出すために、実際の２４ｆｐｓフレームの間に複数の補間フレームを作るプレイバックモードをサポートしている。

Ｈ．２６２／ＭＰＥＧ－２ Ｐａｒｔ２，Ｈ．２６４／ＭＰＥＧ－４ ＡＶＣ，及びＶＣ－１の３種類のビデオエンコード規格をサポートする対応したブルーレイディスクプレイバックデバイスが必要である。これらのビデオエンコード規格の各々は、これらの規格の間にいくつかの相違点があることに注意して、以下に記載される同様の方式で動作する。

ＤＶＤやＢｌｕ－ｒａｙ（登録商標）Ｄｉｓｃでエンコードされたビデオコンテンツに加えて、ビデオストリーミング技術を使用して大量のビデオコンテンツが配信される。映画及びテレビ番組のようなストリーミングメディアに使用されるエンコード技術は、一般に、ＢＤコンテンツに使用されるものと同一であってよく、又は類似してよい。例えば、Ｎｅｔｆｌｉｘ（登録商標）とＡｍａｚｏｎ（登録商標）Ｉｎｓｔａｎｔ Ｖｉｄｅｏとは、それぞれ（プレイバックデバイスの機能に依存する他のストリーミング形式に加えて）ＶＣ－１を使用している。ＶＣ－１は、当初、Ｍｉｃｒｏｓｏｆｔが開発したプロプライエタリのビデオ形式で、２００６年にＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）ビデオコーデック規格としてリリースされた。一方、ＹｏｕＴｕｂｅ（登録商標）では、一般的にアップロードされたビデオコンテンツの記録に使用されるのと同じビデオエンコード規格の混合物を使用し、その大部分は、オリジナルのテレビコンテンツやいくつかの最近の（再送の）映画を記録するのに使用されるプロレベルの機器ではなく、消費者レベルのビデオ録画機器（例えば、ビデオカメラ、携帯電話やデジタルカメラ）を使用して記録される。

ビデオコンテンツがどれだけストリーミングされているかの一例を示すと、最近の測定では、ピークの消費期間の間では、Ｎｅｔｆｌｉｘストリーミングがコムキャストのケーブルインターネットサービスの帯域幅の３分の１以上を使用していたことが示されている。２０１１年以降のフルＨＤ（１０８０ｐ）ストリーミングに加えて、Ｎｅｔｆｌｉｘ，Ａｍａｚｏｎ，Ｈｕｌｕ（登録商標），また、Ｕｌｔｒａ－Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ又はＵＨＤとも呼ばれる４Ｋビデオ（３８４０×２１６０）での絶えず増え続けるビデオコンテンツのストリーミングが行われている。

さらに高度なスマートテレビは、ＩＥＥＥ８０２．１１ベースの無線ネットワーク（一般にＷｉＦｉ（登録商標）と称する）を介して配信されるストリーミングメディアのプレイバックを世界的にサポートする。さらに、新しいＢＤプレーヤーのほとんどは、全てのスマートフォンと同様に、ビデオコンテンツのＷｉＦｉ（登録商標）ストリーミングをサポートしている。これに加えて、最近の多くのスマートフォンやタブレットでは、ＷｉＦｉ（登録商標）ダイレクトや無線ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ－Ｄｉｒｅｃｔｉｏｎ Ｌｉｎｋ）や類似の規格を使用して、スマートフォンやタブレットによってプレイバックを行ってスマートテレビでビデオを見ることができる、無線ビデオストリーミング方式をサポートしている。さらに、ＬＴＥ（ロングタームエボリューション）と第５世代（５Ｇ）モバイルネットワーク上で利用可能なデータサービス帯域幅は、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）のようなサービスを、モバイルネットワークを介してテレビやその他のビデオコンテンツを見るための実行可能な手段にしている。

解像度１０８０では、各フレームは約２１０万画素を備えている。８ビット画素エンコードのみを使用することは、仮にビデオコンテンツが生画素データとして配信される場合に、たった１フレーム／秒であるフレームレートをサポートするために、ほぼ１，７００万ビット／秒（ｍｂｐｓ）のデータストリーミングレートが必要となる。これは非現実的となるため、ビデオコンテンツは高度に圧縮されたフォーマットでエンコードされる。

インターネットブラウザを使用して表示されるような静止画像は、典型的には、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）又はＰＮＧ（Ｐｏｒｔａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）エンコードを使用してエンコードされる。元のＪＰＥＧ規格は、デコードされた画像中の画素が元の画像と異なることがある「非可逆」圧縮方式を定義する。対照的に、ＰＮＧは「可逆」圧縮方式を使用している。可逆ビデオは多くのレベルでは非現実的であったので、最初のＭＰＥＧ－１圧縮標準（１９９３）を定義したＭｏｔｉｏｎ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔ Ｇｒｏｕｐ（ＭＰＥＧ）のような様々なビデオ圧縮標準化団体は、予測フレーム（「Ｐフレーム」）や双方向フレーム（「Ｂフレーム」）のような他のタイプのフレームを生成するために使用される動き予測技術と組み合わせて、イントラフレーム（「Ｉフレーム」）（「キー」フレームとしても知られる）の静止画像エンコードを含む非可逆圧縮技法を使用している。

デジタル化されたビデオコンテンツはフレームのシーケンスから構成されるので、ビデオ圧縮アルゴリズムは、静止画像圧縮に使用される概念及び技術を使用する。静止画像圧縮は、ブロックエンコードと高度な数学の組み合わせを使用して、画像をエンコードするために使用されるビットの数を実質的に減少させる。例えば、ＪＰＥＧは画像を８×８画素ブロックに分割し、離散コサイン変換（ＤＣＴ）を使用して各ブロックを周波数領域表現に変換する。一般に、８×８以外の他のブロックサイズと、ＤＣＴ以外のアルゴリズムとを、規格に基づくプロプライエタリの、他の圧縮方式のブロック変換演算に使用してよい。

ＤＣＴ変換は、周波数ベースの圧縮技術を容易にするために使用される。人の視覚は、高周波に含まれる情報（小さな特徴に対応する）よりも、低周波に含まれる情報（画像の大きな特徴に対応する）の方に敏感である。ＤＣＴは、知覚的に重要度の高い情報を、知覚的に重要度の低い情報と区別するのに役立つ。

ブロック変換の後、各ブロックの変換係数は、量子化と符号化とを使用して圧縮される。量子化は、バイアスされた方式で変換係数の精度を低下させる。即ち、一層多くのビットが低周波係数に使用され、一層少ないビットが高周波係数に使用される。これは、前述したように、人間の視覚は低周波情報の方に一層敏感であるという事実を利用しているため、高周波情報はより近似的である。

次に、量子化されたＤＣＴ係数を表現するために使用されるビット数は、係数の統計的性質のいくつかを利用する「符号化」によって低減される。量子化後、ＤＣＴ係数の多く（多くの場合に、高周波係数の大多数）はゼロである。「ランレングス符号化」（ＲＬＣ）と呼ばれる技術は、個別のゼロ値の係数をエンコードする代わりに、連続するゼロ値の係数（「ラン」）をグループ化し、係数の数（「レングス」）をエンコードすることによって、この事実を利用する。

ランレングス符号化は、典型的には、可変長符号化（ＶＬＣ）が後続する。可変長符号化において、一般的に発生するシンボル（量子化ＤＣＴ係数、又はゼロ値の量子化係数のランを表す）は、数ビットのみを含むコードワードを使用して表現されるが、一層一般的でないシンボルは、一層長いコードワードで表現される。最も一般的なシンボルに対して一層少ないビットを使用して、ＶＬＣは、シンボルをエンコードするために必要とされる平均ビット数を減少させ、それによって、画像の全体をエンコードするために必要とされるビット数を減少させる。

この段階では、前述の技術は全て、他のブロックとは独立して、各８×８ブロック上で動作する。画像は、典型的には、８×８ブロックよりもはるかに大きい特徴を含むので、画像内の隣接するブロック間の類似性を考慮することによって、より効率的な圧縮を達成することができる。このようなブロック間の類似性を利用するために、変換係数の量子化の前に予測ステップがしばしば追加される。このステップでは、コーデックは、周囲のブロックからの情報を使用してブロック内の画像情報を予測しようと試みる。いくつかのコーデック（ＭＰＥＧ－４など）は、ＤＣＴ係数を予測することによって、周波数領域でこのステップを実行する。他のコーデック（Ｈ．２６４／ＡＶＣなど）は、空間領域でこのステップを実行し、画素を直接予測する。後者のアプローチは「イントラ予測」と呼ばれる。

この演算では、エンコーダは、周囲のブロックの係数又は画素に基づいて、各ブロックのＤＣＴ係数（周波数領域で行われる場合）又は画素値（空間領域で行われる場合）のいくつかの値を予測しようと試みる。次に、エンコーダは、実際の値と予測値との差を計算し、実際の値ではなく差をエンコードする。デコーダにおいて、係数は、同じ予測を実行し、次いで、エンコーダによって伝送される差を加算することによって再構成される。この差は実際の係数値と比較して小さい傾向があるので、この技術はＤＣＴ係数を表すのに必要なビット数を減らす。

特定のブロックのＤＣＴ係数又は画素値を予測する際に、デコーダは、既にデコードされている周囲のブロックの値のみにアクセスする。従って、エンコーダは、以前にエンコードされた周囲のブロックからの値のみに基づいて、各ブロックのＤＣＴ係数又は画素値を予測しなければならない。ＪＰＥＧは、最も低い周波数係数（「ＤＣ係数」）のみが単純な微分符号化を使用して予測される、非常に基本的なＤＣＴ係数予測方式を使用する。ＭＰＥＧ－４ビデオは、８×８ブロックの各行及び各列の第１のＤＣＴ係数の予測を試行するために、一層精密にされた方式を使用する。

ＭＰＥＧ－４とは対照的に、Ｈ．２６４／ＡＶＣでは、予測は画素上で直接行われ、ＤＣＴのような整数変換は常に、動き推定又はイントラ予測のいずれかから、残差を処理する。Ｈ．２６４／ＡＶＣでは、画素値は、ＪＰＥＧ又はＭＰＥＧ－４のＩフレームのように、直接変換されることはない。その結果、デコーダは、予測画素に追加される残差を取得するために、変換係数をデコードして逆変換を実行しなければならない。

別の広く使用されているビデオコーデックは、Ｈ．２６５（本明細書で使用）及びＭＰＥＧ－Ｈ Ｐａｒｔ ２としても知られている高効率ビデオ符号化（ＨＥＶＣ）である。Ｈ．２６４／ＡＶＣと比較して、ＨＥＶＣは、同じレベルのビデオ品質で、２５％から５０％だけ一層よいデータ圧縮を提供し、又は同じビットレートで、実質的に向上したビデオ品質を提供する。８Ｋ ＵＨＤを含む８１９２×４３２０までの解像度をサポートし、主に８ビットＡＶＣとは異なり、ＨＥＶＣの高忠実度Ｍａｉｎ１０プロファイルはほぼ全てのサポートハードウェアに組み込まれている。ＨＥＶＣは４×４ないし３２×３２のブロックサイズの整数ＤＣＴ及びＤＳＴ変換を使用する。

カラー画像は、典型的には、いくつかの「色平面」を使用して表現される。例えば、ＲＧＢカラー画像は、赤色平面、緑色平面、及び青色平面を含む。重ね合わせて混合すると、３つの平面がフルカラー画像を構成する。カラー画像を圧縮するために、前述の静止画像圧縮技術を各色平面に順に適用してよい。

イメージングとビデオアプリケーションとは、しばしば、色平面が特定の色に対応しないカラースキームを使用する。その代わりに、１つの色平面はルミナンス情報（カラー画像の各画素の全体的な輝度）を含み、２つ以上の色平面は、ルミナンスと組み合わせたときに、各画像画素の赤、緑及び青の成分の特定のレベルを導出するために使用されてよい色（クロミナンス）情報を含む。このようなカラースキームは、人間の目がカラーよりもルミナンスに対して敏感であるので便利であり、そのため、クロミナンス平面は、ルミナンス情報よりも低い画像解像度で記憶及び／又はエンコードできる。多くのビデオ圧縮アルゴリズムにおいて、クロミナンス平面は、ルミナンス平面の水平解像度の半分と垂直解像度の半分とでエンコードされる。従って、ルミナンス平面内の１６画素×１６画素領域毎に、各クロミナンス平面は、１つの８画素×８画素ブロックを含む。典型的なビデオ圧縮アルゴリズムでは、「マクロブロック」は、４つの８×８のルミナンスブロックと２つの対応する８×８のクロミナンスブロックとを含むビデオフレーム内の１６×１６の領域である。

ビデオ圧縮アルゴリズムと静止画像圧縮アルゴリズムとは、多くの圧縮技術を共有するが、重要な相違点は、どのように動きを処理するかである。１つの極端なアプローチは、ＪＰＥＧ又は類似の静止画像圧縮アルゴリズムを使用して各フレームをエンコードし、次にプレーヤーで生成するＪＰＥＧフレームをデコードすることである。ＪＰＥＧ及び類似の静止画像圧縮アルゴリズムは、約１０：１の圧縮比で良好な品質の画像が生成できるが、高度な圧縮アルゴリズムは、３０：１の高い圧縮比で同様の品質が生成できる。１０：１及び３０：１は相当に大きな圧縮比であるが、ビデオ圧縮アルゴリズムは約２００：１までの圧縮比で良好な品質のビデオが提供できる。これは、静止画像圧縮技術と組み合わせて、動き推定及び動き補正のようなビデオ特有の圧縮技術を使用して達成される。

現在のフレーム内の各マクロブロックに対して、モーション推定は、すでにエンコードされたフレーム（「参照フレーム」と呼ばれる）内の、密接にマッチングする領域を見つけることを試みる。現在のブロックと参照フレームから選択されたブロックとの間の空間的オフセットを「動きベクトル」と称する。エンコーダは、参照フレームから選択されたブロックと現在のブロックとの間の画素毎の差を計算し、動きベクトルとともにこの「予測誤差」を送信する。ほとんどのビデオ圧縮規格では、エンコーダがマクロブロックについて良好なマッチングを見出さない場合に、モーションベースの予測をバイパスしてよい。この場合に、マクロブロック自体は予測誤差の代わりにエンコードされる。

参照フレームは、表示されたビデオフレームのシーケンスの中で必ずしも直前のフレームでないことに注意するものとする。むしろ、ビデオ圧縮アルゴリズムは、通常、それらが表示される順序とは異なる順序でフレームをエンコードする。エンコーダは、前方のいくつかのフレームをスキップし、将来のビデオフレームをエンコードし、その後、後方にスキップし、表示シーケンス内の次のフレームをエンコードしてよい。これは、エンコードされた将来のフレームを参照フレームとして使用して、動き推定を時間的に後方に実行できるように行われる。また、ビデオ圧縮アルゴリズムは、一般に、２つの参照フレーム、即ち、以前に表示されたフレームと、以前にエンコードされた将来のフレームの使用を可能にする。

ビデオ圧縮アルゴリズムは、以前にエンコードされたフレームに依存することなく、静止画像符号化技術のみを使用して周期的にイントラフレームをエンコードする。圧縮ビットストリーム内のフレームが誤差（例えば、ドロップされたパケット又は他の転送誤差）によって破壊された場合に、ビデオデコーダは、再構成のための参照フレームを必要としない次のＩフレームで「再始動」してよい。

図４は、Ｉフレーム４００と、Ｐフレーム４０２と、Ｂフレーム４０４とから構成される例示的なフレームエンコード及び表示方式を示す。上述のように、Ｉフレームは、静止画像と同様の方法で周期的にエンコードされ、他のフレームに依存しない。Ｐフレーム（予測フレーム）は、前のフレーム４０６によって示されるように、前に表示された参照フレームのみを使用してエンコードされる。一方、Ｂフレーム（双方向フレーム）は、前のフレーム４０８と将来のフレーム４１０とによって示されるように、将来及び前に表示された参照フレームの両方を使用してエンコードされる。

図４の下部は、例示的なフレームエンコードシーケンス（下向きに進行する）及び対応する表示プレイバック順序（右向きに進行する）を示す。この例では、Ｐフレームのそれぞれの後に、エンコード順序で３つのＢフレームが続く。一方、表示順序では、３つのＢフレームの後に各Ｐフレームが表示され、エンコード順序と表示順序が同じでないことが示される。さらに、Ｐフレーム及びＢフレームの発生は、一般に、取り込まれたビデオ中に存在する動きの量に依存して変化することに留意するものとする。ここで１つのＰフレームと続く３つのＢフレームとを使用することは、Ｉフレーム、Ｐフレーム及びＢフレームがどのように実施されるかを単純化し、かつ容易に理解するためである。

動き推定を複雑にする１つの要因は、参照フレームから現在のフレームへの物体の変位が非整数の画素である場合があることである。このような状況を取り扱うために、現代のビデオ圧縮規格は、動きベクトルが非整数値を有することを可能にし、例えば、１画素の２分の１又は４分の１の動きベクトル解像度をもたらす。部分画素変位におけるブロックマッチングの探索をサポートするために、エンコーダは、整数でない位置における参照フレームの画素値を推定するために補間を採用する。

部分的にはプロセッサの限界のために、動き推定アルゴリズムは、限定された数の有望な候補の動きベクトル（ほとんどの場合に、約１０～１００ベクトル）を選択し、これらの候補ベクトルに対応する１６×１６領域のみ（又はＨ．２６５の場合に、３２×３２領域まで）を評価するために、種々の方法を使用する。１つのアプローチは、いくつかの段階で候補の動きベクトルを選択し、後に、結果的に最良の動きベクトルを選択することである。別のアプローチは、現在のマクロブロック内の動きを予測しようとするために、現在及び以前のフレーム内の周囲のマクロブロックに対して以前に選択された動きベクトルを解析する。この解析に基づいて少数の候補動きベクトルを選択し、これらのベクトルのみを評価する。

探索領域を徹底的に走査する代わりに、少数の候補ベクトルを選択することによって、動き推定の計算上の要求を、ときには２桁以上の大きさだけ、かなり低減できる。しかし、処理負荷と画像品質又は圧縮効率との間にはトレードオフが存在する。一般に、一層多くの候補動きベクトルを探索することにより、エンコーダは、現在のフレーム内の各ブロックに一層よくマッチするブロックを参照フレーム内で見つけることができ、それにより予測誤差を低減する。予測誤差が小さいほど、画像をエンコードするのに必要なビット数は少なくなる。従って、候補ベクトルの数を増やすことは、一層多くの計算を実行するのと引き換えに、圧縮ビットレートの低減を可能にする。あるいは、圧縮されたビットレート定数を保持しながら候補ベクトルの数を増加させることにより、予測誤差を一層高い精度でエンコードすることができ、画像品質を向上させる。

いくつかのコーデック（Ｈ．２６４とＨ．２６５を含む）は、１６×１６マクロブロックをより小さなブロック（例えば、８×８、４×８、８×４、４×４ブロックの様々な組み合わせ）に細分化し、予測誤差を低くすることを可能にする。これらの小さなブロックのそれぞれは、それ自身の動きベクトルを有してよい。このような方式について動き推定探索は、１６×１６ブロック全体（又は３２×３２ブロック）の良好な位置を見つけることから始まる。マッチングが十分に近ければ、それ以上細分化する必要はない。しかし、マッチングが不十分な場合に、アルゴリズムは、これまでに見出された最良の位置から開始し、さらに、元のブロックを８×８ブロックに分割する。各８×８ブロックに対して、アルゴリズムは、１６×１６サーチによって選択された位置近傍の最良の位置をサーチする。よいマッチングがどれだけ速く見つかるかに依存して、アルゴリズムは８×４、４×８などの小さいブロックを使用してプロセスを続けてよい。

プレイバック中、ビデオデコーダは、各マクロブロックの画素を予測するために、圧縮ビットストリームにエンコードされた動きベクトルを使用してモーション補償を実行する。動きベクトルの水平成分及び垂直成分が両方とも整数値である場合に、予測されるマクロブロックは、単に、参照フレームの１６画素×１６画素領域のコピーである。動きベクトルのいずれかの成分が整数値でない場合に、補間が、非整数画素位置での画像を推定するために使用される。次に、実際のマクロブロック画素を再構成するために、予測誤差をデコードし、予測マクロブロックに加える。前述のように、Ｈ．２６４やＨ．２６５のようなコーデックの場合に、１６×１６（又は３２×３２まで）のマクロブロックは、独立した動きベクトルを持つ一層小さなセクションに分割されてよい。

理想的には、非可逆画像及びビデオ圧縮アルゴリズムは、知覚的に重要でない情報のみを捨て、その結果、再構成された画像又はビデオシーケンスは、人間の眼にとって、元の非圧縮画像又はビデオと同一であるように見える。しかしながら、実際には、いくつかのアーチファクトは、特に、シーンがパンされるときのように、一層大きな動きを有するシーンにおいて、可視的である可能性がある。これは、エンコーダの実施が不十分であること、エンコードが特に困難なビデオコンテンツ、又はビデオシーケンス、解像度、及びフレームレートに対して低すぎる選択されたビットレートに起因して、生じる可能性がある。後者の場合は、多くのアプリケーションがビデオ品質をストレージ及び／又は帯域幅の要求の低減と相殺するので、特に一般的である。

２種類のアーチファクト「ブロッキング」と「リンギング」が、ビデオ圧縮アプリケーションで一般的に生じる。ブロッキングアーチファクトは、圧縮アルゴリズムが各フレームを８×８ブロックに分割するという事実に起因する。各ブロックは、いくつかの小さな誤差で再構成され、ブロックのエッジにおける誤差は、しばしば、隣接するブロックのエッジにおける誤差と対照的であり、ブロック境界を可視化する。対照的に、リンギングアーチファクトは、画像特徴のエッジの周りに歪みとして現れる。リンギングアーチファクトは、高周波ＤＣＴ係数を量子化する際に、エンコーダが過度に多い情報を捨てることに起因する。

ブロッキングアーチファクト及びリンギングアーチファクトを低減するために、ビデオ圧縮アプリケーションは、しばしば、解凍後にフィルタを使用する。これらのフィルタリングステップは、それぞれ「デブロッキング」及び「デリンギング」として知られている。代わりに、デブロッキング及び／又はデリンギングを、ビデオ解凍アルゴリズムに統合してよい。このアプローチは、ときには「ループフィルタリング」と呼ばれ、将来のビデオフレームをデコードするための参照フレームとして、フィルタリングされた再構成フレームを使用する。例えば、Ｈ．２６４は、ときに「ループフィルタ」と称する、「ループ内」デブロッキングフィルタを含む。

エンドツーエンドの画像データフローの例

図５は、一実施形態による、ゲームサーバ２００とデスクトップゲームクライアント２０２との間のエンドツーエンドの画像データフローの例を示す。さらに、関連する動作を図６に示すフローチャート６００に示す。図５の例では、ゲームサーバ２００内のサーバグラフィックスカード１００－１と、デスクトップゲームクライアント２０２内のクライアントグラフィックスカード１００－２との通信を示す。一般に、図５に示す通信は、ゲーム画像コンテンツを生成する任意のタイプのデバイスと、クラウドゲームサーバとプレーヤーによって操作されるゲームデバイスとのような、ゲーム画像コンテンツを受信及び処理するクライアントを有する任意のタイプのデバイスとの間の通信であってよい。この例では、オーディオコンテンツは、サーバグラフィックスカード１００－１とクライアントグラフィックスカード１００－２との間で転送されるように描かれている。いくつかの実施では、オーディオコンテンツは、サーバ及び／又はクライアント（図示せず）上の別個のネットワークインターフェース（例えば、別個のＮＩＣ又はネットワークカード）を介して転送される。別個のネットワークインターフェースを使用するいくつかの実施では、ストリーミングセッション通信と制御通信とは、図５に示されていない別個の通信パスを介して送信される。

フローチャート６００のブロック６０２に示すように、プロセスは、サーバとクライアントとの間のストリーミングセッションを確立することによって開始する。一般に、既存及び将来のストリーミングセッションの任意のタイプが使用されてよく、本明細書に開示される教示及び原理は、一般に、ストリーミングセッションの特定のタイプにアグノスティック（ａｇｎｏｓｔｉｃ，非依存的）である。使用可能なストリーミングプロトコルのタイプは、限定はされないが、既存のストリーミングプロトコル、例えば、ＲＴＭＰ（リアルタイムメッセージングプロトコル），ＲＴＳＰ（リアルタイムストリーミングプロトコル）／ＲＴＰ（リアルタイムトランスポートプロトコル）など、及びＨＴＴＰベースの適応プロトコル、例えば、Ａｐｐｌｅ ＨＬＳ（ＨＴＴＰライブストリーミング），Ｌｏｗ－Ｌａｔｅｎｃｙ ＨＬＳ，ＭＰＥＧ－ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ），Ｌｏｗ－Ｌａｔｅｎｃｙ ＣＭＡＦ ｆｏｒ ＤＡＳＨ（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ ｆｏｒ ＤＡＳＨ），マイクロソフトスムーズストリーミング，Ａｄｏｂｅ ＨＤＳ（ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ）などを含む。さらに、ＳＲＴ（Ｓｅｃｕｒｅ Ｒｅｌｉａｂｌｅ Ｔｒａｎｓｐｏｒｔ）やｗｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ－Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）などの新しい技術も使用してよい。一実施形態では、ＨＴＴＰベースの適応プロトコルの１つをサポートするために、ＨＴＴＰ又はＨＴＴＰＳストリーミングセッションが確立される。

図５は、ＮＩＣ１１２－１とＮＩＣ１１２－２との間の２つのネットワーク通信を示す。ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続５００、及びＵＤＰ／ＩＰ（Ｕｎｉｖｅｒｓａｌ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ ＩＰ）ストリーム５０２である。簡単にするために、これらは一般にＴＣＰ及びＵＤＰと呼ばれる。ＴＣＰは信頼できる接続プロトコルであり、ＴＣＰパケット５０４は送信機から受信機に送信される。受信機は、受信に成功したフレームシーケンスを示すＡＣＫｎｏｗｌｅｄｇｍｅｎｔｓ（ＡＣＫｓ）５０６を送信することによって、パケットの受信を確認する。ときには、ＴＣＰパケット／フレームはドロップされるか、又はＴＣＰパケット５０８によって示されるように、他の方法でエラーを伴って受信される。欠落又は誤りのパケットの検出に応答して、受信機は、欠落又は誤りのパケットを識別する情報を含むネガティブＡＣＫ（ＮＡＣＫ）５１０を送信する。次いで、再送されたパケット５０８Ｒによって示されるように、欠落又は誤りのパケットが再送される。さらに示されるように、ＴＣＰ／ＩＰ接続５００は、デスクトップゲームクライアント２０２からのゲーム制御入力５１２を受信するために使用されてよい。

ＨＴＴＰストリーミングセッションは、ＴＣＰを使用してセットアップされる。しかし、ストリーミングプロトコルによっては、ビデオ及び／又はオーディオコンテンツがＵＤＰを使用してよい。ＵＤＰは、ライブストリーミングに広く使用され、コネクションレスであり、信頼性の低いプロトコルである。ＵＤＰは「ベストエフォート」トランスポートを使用する。これは、パケットがドロップされたり、誤りパケットが受信されたりする可能性があることを意味する。どちらの場合も、欠落又は誤りのパケットは受信機によって無視される。図５に示すＵＤＰパケット５１４のストリームは、ビデオ及び（任意に）オーディオコンテンツのパケットを図示するために使用されている。いくつかのハイブリッド媒体トランスポート方式は、ＴＣＰ及びＵＤＰトランスポートの組み合わせを採用している。

フローチャート６００に戻ると、ブロック６０４では、生のビデオフレームのシーケンスが、フレーム６０５によって示されるように、ゲームサーバ２００上でのゲームソフトウェアの実行を介して、サーバグラフィックスカード１００－１内のＧＰＵ１０２－１によって生成される。生のビデオフレームのシーケンスが生成されると、個別のフレームのコンテンツがフレームバッファ１０４にコピーされ、複数の個別のフレームが所定時点でフレームバッファ１０４に記憶される。ブロック６０６では、フレームは、適用可能なビデオコーデック、例えばＨ．２６４又はＨ．２６５コーデックを使用してエンコードされ、ビデオストリームを生成する。これは、Ｈ．２６４／Ｈ．２６５コーデック１０６－１によって実行され、このコーデックは、生のビデオフレームコンテンツをフレームバッファ１０４から読み込み、ビデオストリーム５１６によって図示されるように、エンコードされたビデオストリームを生成する。当業者には認識されるように、上述の手引書に記載されているように、生成されたビデオストリームは、デスクトップゲームクライアント２０２における生のビデオフレームコンテンツのデコード及びプレイバックを可能にするように順序付けられたＩ、Ｐ及びＢフレームのシーケンスに対応する圧縮及びエンコードされたコンテンツを含む。

図５のブロック６０７とオーディオストリーム生成ブロック５１８とで示されるように、ゲーム画像フレームの生成及びエンコードと並行して、ゲームオーディオコンテンツが、ストリーミング形式にエンコードされる。一般に、オーディオコンテンツは、ゲームサーバＣＰＵ上で実行されるゲームソフトウェアによって生成され、オーディオコンテンツのエンコードは、ソフトウェア又はハードウェアのいずれかを使用して実行されてよい。この例では、エンコードは、サーバグラフィックスカード１００－１の外部で実行される。いくつかの実施形態では、サーバグラフィックスカード１００－１（図示せず）上のＧＰＵ１０２－１又は他の回路のいずれかが、オーディオコンテンツをエンコードするために使用されてよい。

ブロック６０８では、ビデオストリームコンテンツはＮＩＣ１１２－１によってパケット化される。任意には、オーディオストリームはさらに、ＮＩＣ１１２－１によってパケット化されてよい。１つのアプローチでは、ビデオストリームとオーディオストリームとが別々のストリームとして（並列に）送信される。ゲームクライアントでのプレイバック機能を介してオーディオ及びビデオコンテンツを同期させるために使用されるストリームの１つの中に、情報が存在する。他のアプローチでは、ビデオコンテンツとオーディオコンテンツとが組み合わされ、単一のパケットストリームとして送信される。一般に、任意の既存又は将来のビデオ及びオーディオストリーミングパケット化方式が、使用されてよい。

ブロック６１０に示されるように、ＡＶ（オーディオ及びビデオ）コンテンツは、サーバグラフィックスカード１００－１からクライアントグラフィックスカード１００－２へ、ネットワークを介してストリーミングされる。図５に示すように、対応するコンテンツは、ＡＶコンテンツを送信するために使用される１つ以上のＵＤＰストリームを表すＵＤＰパケット５１４を介して、ストリーミングされる。

受信側の動作は、クライアントグラフィックスカード１００－２によって実行される。１つ以上のＵＤＰストリームが受信されると、オーディオ及びビデオのコンテンツは、ＮＩＣ１１２－２内の１つ以上のＵＤＰバッファ５２０内でバッファリングされ、その後、フローチャート６００内のブロック６１２によって示されるように、デパケット化される。フローチャート６００のブロック６１８、及び図５のオーディオデコード及び同期ブロック５２２によって示されるように、オーディオ処理がＧＰＵ又はクライアントのグラフィックスカードによって処理されない実施形態では、デパケット化されたオーディオコンテンツは、分離されてホストＣＰＵに転送され、オーディオコンテンツの処理及び出力を実行する。任意には、オーディオ処理は、クライアントグラフィックスカード１００－２上の適用可能な機能（図示せず）によって実行されてよい。

ブロック６１４では、ビデオ（ゲーム画像）フレームは、適用可能なビデオコーデックを使用してデコードされる。図５の例では、これはＨ．２６４／Ｈ．２６５コーデック１０６－２によって実行される。種々のメカニズムを使用して、ＮＩＣ１１２－２からＨ．２６４／Ｈ．２６５コーデック１０６－２上のＩ／Ｏインターフェース１１０（１１１）に、デパケット化されたエンコードされたビデオコンテンツを転送してよい。例えば、作業記述子の方式を使用してよい。これは、ＮＩＣがＧＰＵ１０２－２上のメモリロケーションに作業記述子を書き込み、次に対応する「作業」（例えば、エンコードされたビデオデータセグメント）をＧＰＵ１０２－２上のロケーション、又はクライアントグラフィックスカード１０２－２上のグラフィックスメモリ（図示せず）に書き込む。別の実施形態では、ＮＩＣ１１２－２が利用可能なエンコードされたビデオセグメントをデパケット化し、Ｈ．２６４／Ｈ．２６５コーデック１０６－２がＮＩＣ１１２－２からエンコードされたビデオセグメントを読み取った場合に、ドアベルをポストするか否かを問わず、「ドアベル」方式が使用されてよい。さらに、他のタイプのキューイングメカニズムも、使用されてよい。いくつかの実施形態で、円形の先入れ先出し（ＦＩＦＯ）バッファ又はキュー、例えば、円形のＦＩＦＯが、使用される。

図５に示すように、Ｈ．２６４／Ｈ．２６５コーデック１０６－２は、ビデオストリームデコード処理５２４及びフレーム生成（再生）５２６を、デコード及び再組み立てブロック５２７内で実行する。図６のブロック６１６及びビデオフレーム６０５によって示されるように、再生フレームは、ＧＰＵフレームバッファ１０４－２に書き込まれ、次いで、デスクトップゲームクライアント２０２のディスプレイに出力されてよい。例えば、ＧＰＵ１０２－２は、ゲーム画像フレームを生成し、モニタ又は他のタイプのディスプレイ上で見るための適用可能なビデオインターフェース（例えば、ＨＤＭＩ，ＤｉｓｐｌａｙＰｏｒｔ，ＵＳＢ－Ｃ）を介して、対応するビデオ信号を出力してよい。オーディオ／ビデオ出力ブロック５２８によって示されるように、オーディオ及びビデオのコンテンツはそれぞれ、デスクトップゲームクライアント２０２のためのスピーカとディスプレイとに出力される。

一般に、ＧＰＵ上に統合された、又はクライアントグラフィックスカード上のＧＰＵに結合されたＮＩＣがＴＣＰトラフィックを処理するために使用される場合に、受信されたＴＣＰパケットは、１つ以上のＴＣＰバッファ５３０内でバッファリングされる。以下に説明及び例示するように、ＮＩＣ１１２－１及びＮＩＣ１１２－２の各々は、ハードウェアにおいて完全なネットワークスタックを実施するための機能を有する。一般に、受信したＴＣＰパケットはパケット化され、さらに処理するためにホストＣＰＵに転送される。転送は、ＰＣＩｅ書き込みトランザクションを使用して、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）のような現行の手段によって行ってよい。

タイルベースのゲーム

多くの人気ゲームはタイルと関連タイルマップを採用している。これは、ビデオエンコード／デコード技術を使用する場合と比較すると、性能利得をもたらす可能性がある。

図７ａ及び図７ｂの図表７００ａ及び７００ｂは、それぞれ、一実施形態による、タイルベースのゲームのためのゲームサーバとゲームクライアントとで実行される操作を示す。図７ａに示すように、タイル７０２、フルフレーム画像は、Ｘ－Ｙグリッドに配置された複数のタイル７０２で構成される。ゲームプレイ中、ゲームサーバ上で実行されるゲームソフトウェアは、タイル生成ブロック７０４によって示されるように、タイルを生成する。タイルは、１つ以上のタイルバッファ７０５に書き込まれる。タイルエンコーダ７０６は、画像圧縮アルゴリズムを使用してタイルをエンコードし、エンコードされたタイル７０８を生成し、その後、エンコードされたタイル内の画像データは、ＮＩＣ７１０上のパケット化ロジック７１２によってパケット化される。次いで、ＮＩＣ７１０は、エンコードされたタイル７１４のストリームを、ゲームクライアントに配信されるネットワークに送信する。

次に、図７ｂの図表７００ｂを参照すると、ゲームクライアントは、ＮＩＣ７１６において、エンコードされたタイル７１４のストリームを受信する。ＮＩＣ７１６は、エンコードされたタイル７０８を出力するためにデパケット化７１８を実行する。次いで、エンコードされたタイルは、タイルバッファ７２０（又は、そうでなければ、ＧＰＵ上にあるいくらかのメモリ空間、又は、ＧＰＵにアクセス可能ないくらかのメモリ空間）に書き込まれる。タイルブロック７２２のデコード及び再生は、タイルバッファ７２０からエンコードされたタイルコンテンツを読み出し、エンコードされたタイルコンテンツをデコードして元のタイルを再生するために使用され、再生タイル７０２Ｒとして示される。

図１ｃは、図表７００ａ及び図表７００ｂに示すサーバ側及びクライアント側の動作をサポートするように構成された、ＧＰＵ１０２ｃを含むグラフィックスカード１００ｃの一実施形態を示す。図１及び１ｃの同じ番号のコンポーネント及びブロックによって示されるように、グラフィックスカード１００及び１００ｃの構成は類似する。相違点は、ＧＰＵ１０２ｃが、Ｉ／Ｏインターフェース１１１を有するタイルエンコーダ及びデコーダ７０６を含むことである。タイルエンコーダ及びデコーダは、図７ａのタイルエンコーダ７０６のエンコード動作、及び図７ｂのタイルブロック７２２をデコード及び再生するための少なくともデコード動作を実行するように構成される。一実施形態では、タイルブロック７２２をデコード及び再生するための完全なロジックは、タイルエンコーダ及びデコーダ７０６内に実施される。任意には、タイル再生ロジックの一部と、ゲームタイルの再組み立てに関連する他のロジックとは、別個のブロック（図示せず）で実施されてよい。

複数のグラフィックスカードを搭載したクラウド型ゲームサーバ

１つのアプローチでは、クラウドゲームサーバは、図８のクラウドゲームサーバ８００に示されるような複数のグラフィックスカードを含む。クラウドゲームサーバ８００は、ｍ個のグラフィックスカード１００（グラフィックスカード１００－１、１００－２、１００－３、１００－４、１００－ｍで示される）を含み、各々がサーバのメインボード上の各ＰＣＩｅスロット（別名は拡張スロット）を占有している。サーバのメインボードは、ゲームソフトウェア８１０がロードされるメインメモリ８０８に結合された１つ以上のＣＰＵ８０６をさらに含む。クラウドゲームサーバ８００は、さらに、それぞれのＰＣＩｅスロットにインストールされた１つ以上のネットワークアダプタカード８１２を含み、その各々は、ＮＩＣチップ８１４と、ＰＣＩｅインターフェース８１６と、イーサネットポート８１８及び８２０によって示されるような１つ以上のイーサネットポートとを含む。

図８ａのクラウドゲームサーバ８００ａの実施形態では、ＰＣＩｅインターフェース８１７を含むＮＩＣチップ８１５がサーバのメインボードに搭載され、適用可能な相互接続構造を介してＣＰＵ８０６に結合される。例えば、ＣＰＵ８０６は、ＰＣＩｅインターフェース８１７がＰＣＩｅリンク８２３を介して結合されたＰＣＩｅルートポート（ＲＰ）８２１を含んでよい。

図８ｂのクラウドゲームサーバ８００ｂの実施形態では、ＣＰＵ８０６と、メインメモリ８０８と、ＮＩＣチップ８１５とは、ＰＣＩｅインターフェース８２６を含むブレードサーバ８２４内のメインボードに搭載されている。クラウドゲームサーバ８００ｂは、スロット／コネクタ８３０及び８３２によって示されるように、複数の拡張スロット又はコネクタを有するバックプレーン、ミッドプレーン又はベースプレーン８２８を含む。ブレードサーバ８２４及びｍ個のグラフィックスカード１００－１、１００－２、１００－３、１００－４、１００－ｍの各々は、対応する拡張スロットにインストールされるか、又はバックプレーン、ミッドプレーン又はベースプレーン８２８上の嵌合コネクタに結合するコネクタを含む。

クラウドゲームサーバは、ゲーム制御入力を処理し、ストリーミング接続を設定及び管理するために、１つ以上のネットワークアダプタカード８１２又はＮＩＣ８１５を使用しながら、ゲーム画像データを生成及びストリーミングするためにグラフィックスカード１００を使用して、ゲームホスティング容量をスケーリングするように構成される。従って、グラフィックスカード１００上の統合ＮＩＣは、リアルタイム制御入力と、ストリーミング設定と、管理トラフィックとに関するＩ／Ｏトラフィックを処理する負荷を負わず、むしろ統合ＮＩＣは、アウトバウンド画像データトラフィックを処理する必要があるだけである。さらに、データパスは、画像データエンコーダ（この例では、Ｈ．２６４／Ｈ．２６５コーデックであるが、他の実施形態では、タイルエンコーダ／デコーダであってよい）から直接流れるので、遅延は低減される。さらに、ゲームのオーディオコンテンツは、ＮＩＣ８１５又はネットワークアダプタカード８１２を使用してストリーミングしてよい。他の実施形態では、上述のように、オーディオコンテンツはグラフィックスカード１００を使用してストリーミングされる。

図９は、一実施形態による、統合ＮＩＣ９００内に実施されたブロックレベルのコンポーネントを示す。ＮＩＣ９００は、メモリ９０４に結合されたＮＩＣプロセッサ９０２と、受信（ＲＸ）ポート９０８及び送信（ＴＸ）ポート９１０を含む１つ以上のネットワークポート９０６（例えば、イーサネットポート）と、ホストＩ／Ｏインターフェース９１２と、コーデックＩ／Ｏインターフェース９１４と、ネットワークスタック９１６を実施するための埋め込みロジックとを含む。ネットワークポート９０６は、開放型システム間相互接続（ＯＳＩ）モデルの物理層（ＰＨＹ層１）と、メディアアクセスチャネル（ＭＡＣ）（層２）とを実施するための回路及びロジックを含む。

ＲＸポート９０８及びＴＸポート９１０は、受信パケット（例えば、パケットＡ，Ｂ，Ｃ，Ｄ）及び送信されるべきパケット（例えば、パケットＱ，Ｒ，Ｓ，Ｔ）がバッファされるそれぞれのＲＸ及びＴＸバッファを含む。受信されたパケットは、インバウンドパケット処理ブロック９１８によって処理され、上流パケットキュー９２０内でバッファリングされる。アウトバウンドパケットは、下流パケットキュー９２２内でキューイングされ、アウトバウンドパケット処理ブロック９２４を使用して処理される。

フロー規則９２６はメモリ９０４に記憶され、受信パケットがどこで転送されるべきかを決定するために使用される。例えば、インバウンドビデオパケットはビデオコーデック又はタイルデコーダに転送され、一方、ゲーム制御及びセッション管理パケットはホストＣＰＵに転送されてよい。ＮＩＣ９００は、ＮＩＣがパケットデータをメインメモリに（ホストＩ／Ｏインターフェース９１２を介して）、及び／又はグラフィックスメモリに直接書き込むことを可能にする、任意であるＤＭＡロジック９２８を含んでよい。

ホストＩ／Ｏインターフェースは、入力ＦＩＦＯキュー９３０と出力ＦＩＦＯキュー９３２とを含む。同様に、コーデックＩ／Ｏインターフェース９１４は、入力ＦＩＦＯキュー９３４と出力ＦＩＦＯキュー９３６とを含む。ＧＰＵ又はグラフィックスカード上の相手のホストＩ／Ｏと、ビデオコーデック中の相手のコーデックＩ／Ｏインターフェースとは、類似の入力及び出力ＦＩＦＯキュー（図示せず）を含む。

一実施形態では、ＮＩＣ９００は、ＯＳＩモデルのネットワーク層３とトランスポート層４とを実施するための埋め込みロジックを含む。例えば、ネットワーク層３は、一般に、インターネットプロトコル（ＩＰ）に使用され、トランスポート層４は、ＴＣＰ及びＵＤＰプロトコルの両方に使用される。一実施形態では、セッション層５と、プレゼンテーション層６と、アプリケーション層７とを実施するために、ＮＩＣ９００は、さらに埋め込まれたロジックを含む。これにより、ＨＴＴＰ及びＨＴＴＰＳストリーミングセッションの確立、及び／又は上述の様々なメディアストリーミングプロトコルの実施など、これらの層に関連する機能を、ＮＩＣは容易にすることが可能になる。これらの操作がホストＣＰＵによって処理される実施では、セッション層５と、プレゼンテーション層６と、アプリケーション層７とを含める必要はない。

ＮＩＣプロセッサ９０２は、図９の様々なブロックによって示される機能を実行するためにファームウェア命令９３８を実行する。ファームウェア命令は、ＮＩＣ９００上の任意のファームウェア記憶ユニット９４０に記憶されてよく、又はＮＩＣの外部のどこかに記憶されてよい。例えば、ＮＩＣ９００が、グラフィックスカードに使用されるＧＰＵ上の統合ＮＩＣである場合に、グラフィックスカードは、ファームウェアがインストールされた記憶ユニット又はデバイスを含んでよい。他の構成、例えば、ゲームサーバにインストールされた場合に、ファームウェア命令の全部又は一部は、ブート操作中にホストからロードされてよい。

一般に、ＮＩＣ９００用に示されたブロックの機能性は、何らかの形式の埋め込みロジックを使用して実現してよい。埋め込みロジックは、一般に、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）を使用、又はプリプログラミング又は固定のハードウェアロジック（又は、プリプログラミング／ハードコード／プログラマブルであるロジックの組み合わせ）を使用するなどの、回路内で実施されるロジックと、１つ以上の埋め込みプロセッサ、プロセッサ要素、エンジン、マイクロコントローラなどで実行されるファームウェアとを含む。説明のために、ＮＩＣプロセッサ９０２上でのファームウェア実行の例を図９に示すが、これは限定的なものではない。ＮＩＣプロセッサ９０２は、コア又はマイクロエンジンなどの複数の処理要素を含んでよい埋め込みプロセッサの形態である。

また、ＮＩＣ９００は、フロー制御、暗号化、復号化などのパケット処理操作を実行するために使用される、埋め込まれた「アクセラレータ」ハードウェアなどを含んでよい。例えば、ＮＩＣ９００は、ＨＴＴＰＳトラフィックに関連して暗号化及び復号化を実行するように構成された１つ以上の暗号ブロックを含んでよい。また、ＮＩＣ９００は、パケットフロールックアップに関連して、ハッシュキーのマッチングを加速するためのハッシュユニットを含んでよい。

本明細書に示される実施形態では、Ｈ．２６４／Ｈ．２６５コーデックは、例示のために示され、非限定的である。一般に、既存及び将来のビデオコーデックは、ＧＰＵ上に統合され、図示されたものと同様に使用されてよい。Ｈ．２６４及びＨ．２６５に加えて、このようなビデオコーデックには、Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＶＶＣ）／Ｈ．２６６、ＡＯＭｅｄｉａ Ｖｉｄｅｏ（ＡＶ１）、ＶＰ８及びＶＰ９が含まれるが、これらに限定されない。

クラウドゲーミング環境での使用に加えて、本明細書に記載及び図示されたＧＰＵとグラフィックスカードとは、他のユースケースで使用されてよい。非限定的なユースケースとしては、以下が挙げられる。
－Ｔｗｉｔｃｈ（登録商標）によるライブゲームのストリーミング。ゲームの画像はグラフィックスカードから直接送出できるので、ゲームストリームの遅延は一層短い。
－さまざまなＹｏｕＴｕｂｅのライブストリームなど、他のビデオストリーミングタスクを高速化することができる。今日では、ビデオストリームはＣＰＵ又はＧＰＵのいずれかの上にエンコードされている。これは、特定のユースケースでは、どちらにより意味があるかに依存する。ＧＰＵ上でエンコードが行われる場合に、リードバック手順及びＰＣメモリを経由せずに、直接ＮＩＣを介してエンコードされたフレームが送出できる。
－Ｓｋｙｐｅ（登録商標）やＺｏｏｍ（登録商標）などのビデオテレフォニーアプリケーション。
－ＧＰＵは、通常、ＣＰＵと比較して浮動小数点演算に対してはるかに速く、よりよいスケーラビリティを有するため、汎用アクセラレータとして使用されることが多い。科学の世界や株式市場解析の分野では、ＧＰＵで計算が行われることが多い。例えば、株式市場ソフトウェアの売買の意思決定のために、他の場所で必要とされる場合に、データは、統合されたＮＩＣを使用して、より速くネットワークに送出できる。
－ＧＰＵをアクセラレータとして使用するプラットフォームのための暗号化コインマイニング。

本明細書に記載及び図示したＰＣＩインターフェース、相互接続、及びプロトコルの使用に加えて、他の相互接続構造とプロトコルとを使用してよい。これらは、Ｃｏｍｐｕｔｅ Ｅｘｐｒｅｓｓ Ｌｉｎｋ （ＣＸＬ），Ｃａｃｈｅ Ｃｏｈｅｒｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｆｏｒ Ａｃｃｅｌｅｒａｔｏｒｓ （ＣＣＩＸ），Ｏｐｅｎ Ｃｏｈｅｒｅｎｔ Ａｃｃｅｌｅｒａｔｏｒ Ｐｒｏｃｅｓｓｏｒ Ｉｎｔｅｒｆａｃｅ （ＯｐｅｎＣＡＰＩ），及びＧｅｎ－Ｚ相互接続を含むが、これらに限定されない。

特定の実施を参照していくつかの実施形態を説明したが、いくつかの実施形態によれば、他の実施も可能である。さらに、図面に図示され、及び／又は本明細書に説明される要素又は他の特徴の配置及び／又は順序は、図示及び説明される特定の方法で配置する必要はない。いくつかの実施形態によれば、多くの他の構成が可能である。

図中に示された各システムにおいて、要素はある場合に、表現された要素が異なる及び／又は類似していることを示唆するために、同一の参照番号又は異なる参照番号を有する場合がある。しかしながら、要素は、異なる実施を有し、ここに図示又は記載されたシステムのいくつか又は全てとともに動作するのに十分に柔軟であってよい。図中に示されている種々の要素は、同一であってよく、又は異なるものであってよい。いずれの１つが第１要素と呼ばれるか、いずれの１つが第２要素と呼ばれるは、任意である。

明細書及び請求項では、用語「結合された」及び「接続された」は、それらの派生物とともに使用されてよい。これらの用語は、互いに同義語として意図されたものではないことを理解するものとする。むしろ、特定の実施形態で、「接続された」は、２つ以上の要素が互いに直接的に物理的又は電気的に接触していることを示すために使用されてよい。「結合された」は、２つ以上の要素が直接的な物理的又は電気的接触の状態にあることを意味してよい。しかし、「結合された」はまた、２つ以上の要素が互いに直接接触していないが、やはり、互いに協働又は相互作用していることを意味してよい。さらに、「通信接続された」とは、互いに直接接触してよく、又は接触しなくてよい、２つ以上の要素が互いに通信することが可能にされることを意味する。例えば、コンポーネントＡがコンポーネントＢに接続され、これがコンポーネントＣに接続される場合に、コンポーネントＡは、コンポーネントＢを中間コンポーネントとして使用して、コンポーネントＣに通信接続される場合がある。

一実施形態は、本発明の実施又は例である。明細書中の「実施形態」、「一実施形態」、「ある実施形態」又は「他の実施形態」への言及は、実施形態に関連して記載された特定の特徴、構造、又は特性が、必ずしも全ての実施形態ではないが、本発明の少なくともいくつかの実施形態に含まれることを意味する。様々な外観の「一実施形態」、「１つの実施形態」、又は「ある実施形態」は、必ずしも全てが同じ実施形態を意味しているわけではない。

本明細書に記載及び図示された全てのコンポーネント、特徴、構造、特性などが、特定の実施形態又は複数の実施形態に含まれる必要はない。明細書で１つのコンポーネント、特徴、構造又は特性が「含まれてよい」、「含まれるかもしれない」、「含むことができる」、「含み得る」と記載されている場合に、例えば、その特定のコンポーネント、特徴、構造又は特性を含めることは必須でない。明細書又は請求項が「１つの（ａ）」又は「１つの（ａｎ）」要素に言及する場合に、それは、要素の１つのみが存在することを意味しない。本明細書又は請求項が「追加の」要素に言及する場合に、それは、追加の要素のうちの２つ以上が存在することを排除しない。

アルゴリズムは、ここにあり、そして一般的に、所望の結果を導く行為又は操作の矛盾のないシーケンスであると考えられる。これには物理量の物理的操作が含まれる。必須ではないが、通常、これらの量は、記憶され、移送され、組み合わされ、比較され、またそれ以外に処理されてよい電気信号又は磁気信号の形を取る。これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことは、主として一般的な用法の理由から、ときには便利であることが判明している。しかしながら、これらの用語及び類似の用語の全ては、適切な物理量に関連付けられるべきであり、これらの量に適用される単なる便利な標識付けであることを理解するものとする。

前述の詳細な説明における「ｍ」、「ｎ」などの（イタリック体の）アルファベットは整数を表すために使用され、特定の文字の使用は特定の実施形態に限定されない。さらに、別々の請求項では、別々の整数を表すために同一の文字を使用することもできるし、異なる文字を使用してよい。さらに、詳細な説明における特定の文字の使用は、詳細な説明における同一の主題事項に関連する請求項では使用される文字とマッチングしてよく、又はマッチングしなくてよい。

上述のように、本明細書における実施形態の様々な態様は、埋め込みプロセッサなどによって実行されるソフトウェア及び／又はファームウェアなどの、対応するソフトウェア及び／又はファームウェアのコンポーネントとアプリケーションとによって促進されてよい。従って、本発明の実施形態は、プロセッサ又はコア上で実行される仮想マシン内、又は、非一時的なコンピュータ可読又はマシン可読な記憶媒体の上又は中で実施又は実現される仮想マシン内で、何らかの形態のプロセッサ、プロセッサコア、又は埋め込みロジック上で実行されるソフトウェアプログラム、ソフトウェアモジュール、ファームウェア、及び／又は分散ソフトウェアとして、使用されてよく、又はこれらをサポートするために使用されてよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体は、マシン（例えば、コンピュータ）によって可読な形態で情報を記憶又は送信するための任意のメカニズムを含む。例えば、非一時的なコンピュータ可読又はマシン可読な記憶媒体は、コンピュータ又は計算機（例えば、コンピュータデバイス、電子システムなど）によってアクセス可能な形態で情報を提供する（即ち、記憶及び／又は送信する）任意のメカニズム、例えば、記録可能／非記録可能な媒体（例えば、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイスなど）などを含む。コンテンツは直接実行可能（「オブジェクト」又は「実行可能」形式）、ソースコード、又は差分コード（「デルタ」又は「パッチ」コード）であってよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体はまた、コンテンツがダウンロードできる記憶又はデータベースを含んでよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体はまた、販売又は配信時に記憶されたコンテンツを有するデバイス又は製品を含んでよい。従って、記憶されたコンテンツを有するデバイスを配信すること、又は通信媒体を介してダウンロードするためのコンテンツを提供することは、ここに記載されたそのようなコンテンツを有する非一時的なコンピュータ可読又はマシン可読な記憶媒体を含む製造物品を提供することとして理解されてよい。

本明細書に記載された種々のコンポーネントによって実行される操作及び機能は、処理要素上で実行されるソフトウェアによって、埋め込みハードウェアなど、又はハードウェアとソフトウェアとの任意の組み合わせによって実行されてよい。このようなコンポーネントは、ソフトウェアモジュール、ハードウェアモジュール、特殊目的のハードウェア（例えば、特定用途のハードウェア、ＡＳＩＣ、ＤＳＰなど）、埋め込みコントローラ、ハードウェア実現された回路、ハードウェアロジックなどとして実施してよい。ソフトウェアコンテンツ（例えば、データ、命令、構成情報など）は、非一時的なコンピュータ可読又はマシン可読な記憶媒体を含む製品を介して提供してよい。これは実行可能な命令を表すコンテンツを提供する。コンテンツは、結果として、本明細書に記載された種々の機能／操作を実行するコンピュータとなってよい。

本明細書中で使用される場合に、用語「の少なくとも１つ」によって結合される項目のリストは、リストされた用語の任意の組み合わせを意味してよい。例えば、語句「Ａ、Ｂ又はＣの少なくとも１つ」は、Ａ、又はＢ、又はＣ、又はＡ及びＢ、又はＡ及びＣ、又はＢ及びＣ、又はＡ、Ｂ及びＣを意味してよい。

本発明の例示的な実施形態についての上記記載は、要約書の記載も含めて、網羅的であることは意図せず、また、本発明を開示された通りの形態に限定することを意図しない。説明の目的のため、本発明の具体的な実施形態と例とがここに記載されているが、当業者が認識するように、本発明の範囲内で様々な同等の変形が可能である。

本発明へのこれらの変更は、上述の詳細な説明を踏まえてなされてよい。以下の請求項で使用される用語は、本明細書及び図面で開示される特定の実施形態に本発明を限定すると解釈されないものとする。正しくは、本発明の範囲は全体的に、請求項の解釈についての確立された原則に従って解釈されるべき後述の請求項により、定められるものである。

Claims (20)

1. グラフィックス処理ユニット（ＧＰＵ）を備えている装置であって、前記グラフィックス処理ユニット（ＧＰＵ）は、
   複数のフレームバッファと、
   少なくとも１つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも１つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ／デコーダと、
   統合された前記エンコーダ／デコーダに結合されている統合ネットワークインターフェースコントローラ（ＮＩＣ）とを含む、装置。
2. 装置は、入出力（Ｉ／Ｏ）インターフェースを有するグラフィックスカードを備え、前記統合ＮＩＣは、前記グラフィックスカード上の前記Ｉ／Ｏインターフェースに結合されているインターフェースを含み、
   前記統合ＮＩＣは、ネットワークを介して前記Ｉ／Ｏインターフェースから送信されるデータを受信し、ネットワークから前記Ｉ／Ｏインターフェースに受信されたデータを転送するように構成されている、請求項１記載の装置。
3. 前記統合ＮＩＣは、開放型システム間相互接続（ＯＳＩ）モデルの少なくとも層３及び４を実施する埋め込みロジックを含む、請求項１又は２記載の装置。
4. 前記統合ＮＩＣは、開放型システム間相互接続（ＯＳＩ）モデルの層３ないし７を実施する埋め込みロジックを含む、請求項１ないし３のいずれか１項に記載の装置。
5. 統合された前記エンコーダ／デコーダは、ビデオコーデックを含む、請求項１ないし４のいずれか１項に記載の装置。
6. 前記ＧＰＵは、
   ビデオゲームフレームコンテンツを生成し、１つ以上の前記フレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
   前記ビデオコーデックを使用して、前記ビデオゲームフレームコンテンツをエンコードし、エンコードされたビデオゲームコンテンツを生成し、
   前記統合ＮＩＣを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、ネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項５記載の装置。
7. 前記ＧＰＵはビデオ出力を含み、装置はさらにグラフィックスカードを備え、前記グラフィックスカードは、
   前記ＧＰＵに結合されているか、又は前記ＧＰＵに統合されているグラフィックスメモリと、
   前記統合ＮＩＣに結合されているネットワークポートと、
   前記ＧＰＵに結合されている入出力（Ｉ／Ｏ）インターフェースと、
   前記ＧＰＵで前記ビデオ出力に結合されているビデオポートとを含み、
   前記グラフィックスカードは、
   ストリーミングメディアコンテンツを含むパケットのストリームを、前記ネットワークポートに結合されたネットワークから受信し、
   前記統合ＮＩＣを使用して、パケットの前記ストリームをデパケット化し、エンコードされたビデオコンテンツを抽出するように構成され、
   ａ）デパケット化されたエンコードされたビデオコンテンツを、前記ビデオコーデックにアクセス可能なバッファに書き込むこと、又は、
   ｂ）前記統合ＮＩＣ上にバッファリングされた、デパケット化されたエンコードされたビデオコンテンツを、前記ビデオコーデックを介して読み取ること
   のうちの１つをするように構成され、
   前記グラフィックスカードは、
   前記ビデオコーデックを使用して、エンコードされた前記ビデオコンテンツをデコードし、ビデオゲームフレームコンテンツを再生し、
   少なくとも１つのフレームバッファに、再生された前記ビデオゲームフレームコンテンツをバッファリングし、
   前記ビデオポートを介してビデオゲームフレームを含むディスプレイコンテンツを出力するように構成されている、請求項５又は６記載の装置。
8. 統合された前記エンコーダ／デコーダは、画像タイルエンコーダ及びデコーダである、請求項１ないし７のいずれか１項に記載の装置。
9. 前記ＧＰＵは、
   ビデオゲームフレームコンテンツを生成し、１つ以上の前記フレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
   前記画像タイルエンコーダを使用して、ビデオゲームフレームコンテンツのタイルをエンコードし、エンコードされたビデオゲームタイルを生成し、
   前記統合ＮＩＣを使用して、エンコードされた前記ビデオゲームタイルをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のイーサネットポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項８記載の装置。
10. 前記ＧＰＵはビデオ出力を含み、装置はさらにグラフィックスカードを備え、前記グラフィックスカードは、
    前記ＧＰＵに結合されているか、又は前記ＧＰＵに統合されているグラフィックスメモリと、
    前記統合ＮＩＣに結合されているネットワークポートと、
    前記ＧＰＵに結合されている入出力（Ｉ／Ｏ）インターフェースと、
    前記ＧＰＵで前記ビデオ出力に結合されているビデオポートとを含み、
    前記グラフィックスカードは、
    ストリーミングされたビデオゲームタイルを含むパケットのストリームを、前記グラフィックスカード上のイーサネットポートに結合されたネットワークから受信し、
    前記統合ＮＩＣを使用して、パケットの前記ストリームをデパケット化し、エンコードされたビデオゲームタイルを抽出するように構成され、
    ａ）デパケット化されたエンコードされたビデオゲームタイルを、画像タイルデコーダにアクセス可能なバッファに書き込むこと、又は、
    ｂ）前記統合ＮＩＣ上にバッファリングされた、デパケット化されたエンコードされた画像タイルを、前記画像タイルデコーダを介して読み取ること
    のうちの１つをするように構成され、
    前記グラフィックスカードは、
    前記画像タイルデコーダを使用して、エンコードされた前記画像タイルをデコードし、ゲーム画像タイルを再生し、
    再生された前記ゲーム画像タイルをフレームバッファにアレイ配置し、ビデオゲームフレームを生成し、
    前記ビデオポートを介してビデオゲームフレームを含むディスプレイコンテンツを出力するように構成されている、請求項８又は９記載の装置。
11. 統合ネットワークインターフェースコントローラ（ＮＩＣ）を有するグラフィックス処理ユニットＧＰＵを含むグラフィックスカードに実施される方法であって、
    ビデオフレームコンテンツを生成し、前記ＧＰＵ上の１つ以上のフレームバッファに前記ビデオフレームコンテンツをバッファリングするステップを備え、
    前記ＧＰＵに統合されたビデオコーデックを使用して、前記ビデオフレームコンテンツをエンコードし、エンコードされたビデオコンテンツを生成するステップと、
    前記統合ＮＩＣを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、前記統合ＮＩＣ上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するステップと、
    又は、
    前記ＧＰＵに統合された画像タイルエンコーダを使用して、ビデオフレームコンテンツのタイルをエンコードし、エンコードされたビデオタイルを生成するステップと、
    前記統合ＮＩＣを使用して、エンコードされた前記ビデオタイルをパケット化し、パケットのストリームを生成し、前記統合ＮＩＣ上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するステップと
    のうちの一方を備えている、方法。
12. さらに、
    前記グラフィックスカードの入出力（Ｉ／Ｏ）インターフェースで、エンコードされたオーディオコンテンツを受信するステップと、
    前記Ｉ／Ｏインターフェースと前記統合ＮＩＣとを結合する前記ＧＰＵ上の相互接続を介して、エンコードされた前記オーディオコンテンツを転送するステップと、
    前記統合ＮＩＣを使用して、エンコードされた前記オーディオコンテンツをパケット化して、オーディオパケットのストリームを生成し、前記統合ＮＩＣの出力ポートを介して前記ネットワークにアウトバウンドでオーディオパケットの前記ストリームを送信するステップとを備えている、請求項１１記載の方法。
13. さらに、
    前記グラフィックスカードとクライアントデバイスとの間で、ストリーミングメディアセッションを確立するステップと、
    前記ストリーミングメディアセッションを使用して、前記ストリーミングメディアセッションに関連付けられた少なくとも１つのプロトコルの使用により、パケットの前記ストリームを前記クライアントデバイスに転送するステップとを備えている、請求項１１又は１２記載の方法。
14. 前記グラフィックスカードはホストにインストールされ、前記グラフィックスカード上の入出力（Ｉ／Ｏ）インターフェースを介して、前記ホストと通信され、前記ビデオフレームコンテンツはビデオゲームフレームコンテンツであり、さらに、
    前記ネットワークから、ビデオ制御入力データを受信するステップと、
    前記統合ＮＩＣを介して、前記ビデオ制御入力データが前記ホストに転送されることを検出するステップと、
    前記グラフィックスカードの前記統合ＮＩＣと前記入出力（Ｉ／Ｏ）インターフェースとの間に結合された相互接続を介して、ゲーム制御入力データを前記ホストに転送するステップとを備えている、請求項１１ないし１３のいずれか１項に記載の方法。
15. 前記ビデオフレームコンテンツはビデオゲームフレームコンテンツであり、さらに、
    前記グラフィックスカードの入出力（Ｉ／Ｏ）インターフェースで、ゲーム制御データを受信するステップと、
    前記Ｉ／Ｏインターフェースと前記統合ＮＩＣとを結合する前記ＧＰＵ上の相互接続を介して前記ゲーム制御データを転送し、信頼性のあるトランスポートプロトコルを使用して、前記ゲーム制御データをゲームクライアントデバイスに転送するステップとを備えている、請求項１１ないし１４のいずれか１項に記載の方法。
16. 複数の拡張スロット又はコネクタを有する第１ボードと、
    前記第１ボード又は第２ボードに搭載されている中央処理ユニット（ＣＰＵ）であり、前記第２ボードは、拡張スロットにインストールされているか、又は前記第１ボード上の嵌合コネクタに結合されている、中央処理ユニット（ＣＰＵ）と、
    前記ＣＰＵに通信接続されている１つ以上のメモリデバイスを含むメインメモリと、
    ａ）それぞれの拡張スロットにインストールされている１つ以上のネットワークアダプタカード、又は、
    ｂ）前記第１ボード又は前記第２ボードに搭載されている１つ以上のネットワークインターフェースコントローラ（ＮＩＣ）チップと、
    それぞれの拡張スロットにインストールされている、又は前記第１ボード上の各嵌合コネクタに結合されている複数のグラフィックスカードとを備え、
    各グラフィックスカードは、
    グラフィックス処理ユニット（ＧＰＵ）を含み、前記グラフィックス処理ユニット（ＧＰＵ）は、
    １つ以上のフレームバッファと、
    少なくとも１つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも１つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ／デコーダと、
    統合された前記エンコーダ／デコーダに結合されている統合ネットワークインターフェースコントローラ（ＮＩＣ）と、
    前記ＧＰＵに結合されているか、又は前記ＧＰＵに統合されているグラフィックスメモリと、
    前記統合ＮＩＣに結合されている少なくとも１つのネットワークポートと、
    前記ＧＰＵに結合されている入出力（Ｉ／Ｏ）インターフェースと
    を備えている、クラウドゲームサーバ。
17. 少なくとも１つのグラフィックスカードのための統合された前記エンコーダ／デコーダは、ビデオコーデックを含み、
    少なくとも１つの前記グラフィックスカードでの前記ＧＰＵは、
    ビデオゲームフレームコンテンツを生成し、前記ＧＰＵで１つ以上のフレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
    前記ビデオコーデックを使用して、前記ビデオゲームフレームコンテンツをエンコードし、エンコードされたビデオゲームコンテンツを生成し、
    前記ＧＰＵで前記統合ＮＩＣを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のネットワークポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項１６記載のクラウドゲームサーバ。
18. 統合された前記エンコーダ／デコーダは、画像タイルエンコーダ及びデコーダであり、
    少なくとも１つのグラフィックスカードの前記ＧＰＵは、
    ビデオゲームフレームコンテンツを生成し、前記ＧＰＵで１つ以上のフレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
    前記画像タイルエンコーダを使用して、ビデオゲームフレームコンテンツのタイルをエンコードし、エンコードされたビデオゲームタイルを生成し、
    前記統合ＮＩＣを使用して、エンコードされた前記ビデオゲームタイルをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のネットワークポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項１６又は１７記載のクラウドゲームサーバ。
19. クラウドゲームサーバ内の前記メインメモリと記憶デバイスとのうちの少なくとも１つに存在するゲームソフトウェアをさらに含み、前記ゲームソフトウェアを実行することは、クラウドゲームサーバが下記のステップ、即ち、
    少なくとも１つのネットワークアダプタカード又はＮＩＣを使用するネットワーク通信を使用して、ネットワークに結合された複数のゲームクライアントデバイスとともにストリーミングメディアセッションを確立するステップと、
    複数の前記ストリーミングメディアセッションを使用して、複数のグラフィックスカードの使用によりパケットのストリームを複数の前記ゲームクライアントデバイスに転送するステップとを実行することを可能にする、請求項１６ないし１８のいずれか１項に記載のクラウドゲームサーバ。
20. クラウドゲームサーバはさらに、クラウドゲームサーバ上にホストされるゲームのインスタンスのためのオーディオコンテンツを生成し、前記オーディオコンテンツを複数の前記ゲームクライアントデバイスにストリーミングするように、構成されている、請求項１９記載のクラウドゲームサーバ。

Images