特許 7505134 レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-14

(45)【発行日】2024-06-24

(54)【発明の名称】レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整

(51)【国際特許分類】

   H04N 21/2385 20110101AFI20240617BHJP

   H04N 21/24 20110101ALI20240617BHJP

   H04N 19/126 20140101ALI20240617BHJP

   H04N 19/164 20140101ALI20240617BHJP

   H04N 19/177 20140101ALI20240617BHJP

   H04N 19/179 20140101ALI20240617BHJP

   A63F 13/35 20140101ALI20240617BHJP

【ＦＩ】

H04N21/2385

H04N21/24

H04N19/126

H04N19/164

H04N19/177

H04N19/179

A63F13/35

【請求項の数】 24

(21)【出願番号】P 2024017687

(22)【出願日】2024-02-08

(62)【分割の表示】P 2022520322の分割

【原出願日】2020-09-30

(65)【公開番号】P2024050857

(43)【公開日】2024-04-10

【審査請求日】2024-02-19

(31)【優先権主張番号】62/909,185

(32)【優先日】2019-10-01

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/909,182

(32)【優先日】2019-10-01

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/007,880

(32)【優先日】2020-08-31

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/008,030

(32)【優先日】2020-08-31

(33)【優先権主張国・地域又は機関】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】310021766

【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント

(74)【代理人】

【識別番号】100099324

【弁理士】

【氏名又は名称】鈴木 正剛

(72)【発明者】

【氏名】マーク イー． サーニー

(72)【発明者】

【氏名】ケルビン エム． ヨン

【審査官】富樫 明

(56)【参考文献】

【文献】特表２０１９－５０９０７８（ＪＰ，Ａ）

【文献】国際公開第２０１９／１８２７５２（ＷＯ，Ａ１）

【文献】国際公開第２０１８／１９５４４０（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００－２１／８５８

Ｈ０４Ｎ １９／００－１９／９８

Ａ６３Ｆ １３／３５

(57)【特許請求の範囲】

【請求項1】

クラウドゲーミング方法であって、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
前記ビデオゲームのための第１のビデオフレームに対してシーン変化を予測し、前記シーン変化は前記第１のビデオフレームが生成される前に予測され、
前記第１のビデオフレームが前記シーン変化である、シーン変化ヒントを生成し、
前記シーン変化ヒントをエンコーダに送信し、
前記第１のビデオフレームを前記エンコーダに配信し、前記第１のビデオフレームは、前記シーン変化ヒントに基づいてＩフレームとしてエンコードされるものであり、
クライアントの最大受信帯域幅を測定し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第２のビデオフレームをエンコードするかしないかの判定を行う、クラウドゲーミング方法。

【請求項2】

さらに、前記エンコーダにおいて、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整し、
前記ビデオフレームがエンコードされると、前記複数のビデオフレームを前記クライアントに伝送する、
請求項１に記載のクラウドゲーミング方法。

【請求項3】

前記第２のビデオフレームをエンコードするかしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第２のビデオフレームのエンコードをスキップする、
請求項１に記載のクラウドゲーミング方法。

【請求項4】

前記第２のビデオフレームをエンコードするかしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第２のビデオフレームを正常にエンコードする、
請求項１に記載のクラウドゲーミング方法。

【請求項5】

前記第２のビデオフレームをエンコードするかしないかの前記判定では、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第２のビデオフレームをより低い精度でエンコードする、
請求項４に記載のクラウドゲーミング方法。

【請求項6】

前記第１のビデオフレームに対する前記シーン変化の前記予測では、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて、前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行し、
前記第１のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行し、予測される前記シーン変化は、前記ゲームロジックの実行中に収集されたゲーム状態に基づき、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成し、
前記エンコーダが、前記第１のビデオフレームを受信する前に前記シーン変化ヒントを送信する、
請求項１に記載のクラウドゲーミング方法。

【請求項7】

前記シーン変化ヒントは、前記シーン変化ロジックからアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記エンコーダに配信される、
請求項６に記載のクラウドゲーミング方法。

【請求項8】

前記第２のビデオフレームは、前記第１のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、
請求項１に記載のクラウドゲーミング方法。

【請求項9】

クラウドゲーミング用のコンピュータプログラムを格納するコンピュータ可読媒体であって、
クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成するためのプログラム命令を有し、
前記ビデオゲームのための第１のビデオフレームに対してシーン変化を予測するためのプログラム命令を有し、前記シーン変化は前記第１のビデオフレームが生成される前に予測され、
前記第１のビデオフレームが前記シーン変化であるシーン変化ヒントを生成するためのプログラム命令を有し、
前記シーン変化ヒントをエンコーダに送信するためのプログラム命令を有し、
前記第１のビデオフレームを前記エンコーダに配信するためのプログラム命令を有し、前記第１のビデオフレームは、前記シーン変化ヒントに基づいてＩフレームとしてエンコードされ、
クライアントの最大受信帯域幅を測定するためのプログラム命令を有し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第２のビデオフレームをエンコードするかしないかを判定するためのプログラム命令を有する、
コンピュータ可読媒体。

【請求項10】

さらに、前記クライアントの前記最大受信帯域幅に基づいて、前記エンコーダでのエンコーダビットレート速度を動的に調整するためのプログラム命令を有し、
前記ビデオフレームがエンコードされると、前記複数のビデオフレームを前記クライアントに伝送するためのプログラム命令を有する、
請求項９に記載のコンピュータ可読媒体。

【請求項11】

前記第２のビデオフレームをエンコードするかエンコードしないかを判定するためのプログラム命令は、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第２のビデオフレームのエンコードをスキップするためのプログラム命令を有する、
請求項９に記載のコンピュータ可読媒体。

【請求項12】

前記第２のビデオフレームをエンコードするかエンコードしないかを判定するためのプログラム命令は、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第２のビデオフレームを正常にエンコードするためのプログラム命令を有する、
請求項９に記載のコンピュータ可読媒体。

【請求項13】

前記第２のビデオフレームをエンコードするかエンコードしないかを判定するためのプログラム命令は、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第２のビデオフレームをより低い精度でエンコードするためのプログラム命令を有する、
請求項１２に記載のコンピュータ可読媒体。

【請求項14】

前記第１のビデオフレームに対して前記シーン変化を予測するためのプログラム命令は、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行するためのプログラム命令を有し、
前記第１のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行するためのプログラム命令を有し、予測される前記シーン変化は、前記ゲームロジックの実行中に収集されたゲーム状態に基づき、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成するためのプログラム命令を有し、
前記エンコーダが前記第１のビデオフレームを受信する前に前記シーン変化ヒントを送信するためのプログラム命令を有する、
請求項９に記載のコンピュータ可読媒体。

【請求項15】

前記クラウドゲーミング用のコンピュータプログラムにおいて、前記シーン変化ヒントは、前記シーン変化ロジックからアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記エンコーダに配信される、
請求項１４に記載のコンピュータ可読媒体。

【請求項16】

前記クラウドゲーミング用のコンピュータプログラムにおいて、前記第２のビデオフレームは、前記第１のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、
請求項９に記載のコンピュータ可読媒体。

【請求項17】

コンピュータシステムであって、
プロセッサと、
前記プロセッサに結合され、その中に格納された命令を有しているメモリと、を有し、前記命令は、前記コンピュータシステムによって実行されると、前記コンピュータシステムにクラウドゲーミング方法を実行させ、前記クラウドゲーミング方法は、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
前記ビデオゲームのための第１のビデオフレームに対してシーン変化を予測し、前記シーン変化は前記第１のビデオフレームが生成される前に予測され、
前記第１のビデオフレームが前記シーン変化である、シーン変化ヒントを生成し、
前記シーン変化ヒントをエンコーダに送信し、
前記第１のビデオフレームを前記エンコーダに配信し、前記第１のビデオフレームは、前記シーン変化ヒントに基づいてＩフレームとしてエンコードされるものであり、
クライアントの最大受信帯域幅を測定し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第２のビデオフレームをエンコードするかエンコードしないかを判定する、コンピュータシステム。

【請求項18】

さらに、前記エンコーダにおいて、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整し、
前記ビデオフレームがエンコードされると、前記複数のビデオフレームを前記クライアントに伝送する、
請求項１７に記載のコンピュータシステム。

【請求項19】

前記クラウドゲーミング方法で、前記第２のビデオフレームをエンコードするかしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第２のビデオフレームのエンコードをスキップする、
請求項１７に記載のコンピュータシステム。

【請求項20】

前記クラウドゲーミング方法で、前記第２のビデオフレームをエンコードするかしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第２のビデオフレームを正常にエンコードする、
請求項１７に記載のコンピュータシステム。

【請求項21】

前記クラウドゲーミング方法で、前記第２のビデオフレームをエンコードするかしないかの判定では、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第２のビデオフレームをより低い精度でエンコードする、
請求項２０に記載のコンピュータシステム。

【請求項22】

前記クラウドゲーミング方法で、前記第１のビデオフレームに対する前記シーン変化の前記予測では、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて、前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行し、
前記第１のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行し、予測される前記シーン変化は、前記ゲームロジックの実行中に収集されたゲーム状態に基づき、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成し、
前記エンコーダが、前記第１のビデオフレームを受信する前に前記シーン変化ヒントを送信する、
請求項１７に記載のコンピュータシステム。

【請求項23】

前記シーン変化ヒントは、前記シーン変化ロジックからアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記エンコーダに配信される、
請求項２２に記載のコンピュータシステム。

【請求項24】

前記第２のビデオフレームは、前記第１のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、
請求項１７に記載のコンピュータシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ネットワークを介してコンテンツをストリーミングするように構成されたストリーミングシステムに関し、より具体的には、クラウドゲーミングシステム用の高性能エンコーダ及びデコーダ、ならびにネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダ調節のために構成されたストリーミングシステムに関連する。

【背景技術】

【0002】

近年、ネットワークを介して接続されたクラウドゲーミングサーバとクライアントとの間でストリーミングフォーマットのオンラインまたはクラウドゲーミングを可能にするオンラインサービスが継続的に推進されている。ストリーミングフォーマットは、オンデマンドでのゲームタイトルの利用可能性、マルチプレイヤーゲームのためにプレイヤー間をネットワークする機能、プレイヤー間での資産の共有、プレイヤー間及び／または観客間でのインスタントエクスペリエンスの共有、友人達が、友人がビデオゲームをプレイするのを見ることを可能にすること、友人が進行中のゲームプレイに参加する友人を有すること、などによって、増々人気が高まっている。
残念ながら、その需要はまた、ネットワーク接続の能力と、クライアントに配信されると高品質画像をレンダリングするのに十分な応答性を備えたサーバ及びクライアントにおいて実行される処理の制限と、に対しても押し上がっている。例えば、サーバで実行されるすべてのゲームアクティビティの結果は、最高のユーザエクスペリエンスのために、圧縮されて低いミリ秒のレイテンシでクライアントに戻すように伝送される必要がある。ラウンドトリップレイテンシは、ユーザのコントローラ入力とクライアントにおけるビデオフレームの表示との間の全体的な時間として定義されることができ、これは、コントローラからクライアントへの制御情報の処理と伝送と、クライアントからサーバへの制御情報の処理と伝送と、入力に応答するビデオフレームを生成するためのサーバでのその入力の使用と、ビデオフレームの処理とエンコーディングユニットへの転送（例えば、スキャンアウト）と、ビデオフレームのエンコードと、クライアントへ戻すエンコードされたビデオフレームの伝送と、ビデオフレームの受信とデコードと、表示前のビデオフレームの処理またはステージングのいずれかと、を含み得る。
一方向レイテンシは、ビデオフレームのサーバにあるエンコーディングユニットへの転送（例えば、スキャンアウト）の開始からクライアントにおけるビデオフレームの表示の開始までの時間で構成されるラウンドトリップレイテンシの一部として定義され得る。ラウンドトリップレイテンシ及び一方向レイテンシの一部分は、データストリームが、通信ネットワークを介してクライアントからサーバに送信され、サーバからクライアントに送信されるのにかかる時間に関連付けられている。別の部分は、クライアントとサーバでの処理に関連付けられており、フレームのデコードと表示に関する高度な方策などの、これらの動作での改善は、サーバとクライアント間のラウンドトリップレイテンシ及び一方向レイテンシの実質的な低減になり得、クラウドゲーミングサービスのユーザに高品質のエクスペリエンスを提供する。

【0003】

本開示の実施形態は、このような背景のもとになされたものである。

【発明の概要】

【0004】

本開示の実施形態は、ネットワークを介してコンテンツ（例えば、ゲーム）をストリーミングするように構成されたストリーミングシステムに関し、より具体的には、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するためにエンコーダ調節を提供するように構成されたストリーミングシステムに関し、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたＩフレームの数、シーン変化の数、及び／または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ（ＱＰ）値を含み得、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。

【0005】

本開示の実施形態は、クラウドゲーミングのための方法を開示する。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、複数のビデオフレームをエンコーダビットレートでエンコードすることを含み、圧縮された複数のビデオフレームが、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、ストリーマにおける複数のビデオフレームのエンコードを監視することを含んでいる。本方法は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節することを含んでいる。

【0006】

別の実施形態では、クラウドゲーミング用のコンピュータプログラムを格納する非一時的なコンピュータ可読媒体が開示されている。コンピュータ可読媒体は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに複数のビデオフレームを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、複数のビデオフレームをエンコーダビットレートでエンコードするためのプログラム命令を含んでおり、圧縮された複数のビデオフレームは、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。コンピュータ可読媒体は、クライアントの最大受信帯域幅を測定するためのプログラム命令を含んでいる。コンピュータ可読媒体は、ストリーマにおける複数のビデオフレームのエンコードを監視するためのプログラム命令を含んでいる。コンピュータ可読媒体は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節するためのプログラム命令を含んでいる。

【0007】

さらに別の実施形態では、コンピュータシステムは、プロセッサと、プロセッサに結合され、命令をその中に格納したメモリと、を含み、命令は、コンピュータシステムによって実行された場合、コンピュータシステムにクラウドゲーミングの方法を実行させる。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、複数のビデオフレームをエンコーダビットレートでエンコードすることを含み、圧縮された複数のビデオフレームが、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、ストリーマにおける複数のビデオフレームのエンコードを監視することを含んでいる。本方法は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節することを含んでいる。

【0008】

さらに別の実施形態では、クラウドゲーミングのための方法が開示されている。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、ビデオゲームの第１のビデオフレームのシーン変化を予測することを含んでおり、シーン変化は、第１のビデオフレームが生成される前に予測されている。本方法は、第１のビデオフレームがシーン変化である、シーン変化ヒントを生成することを含んでいる。本方法は、シーン変化ヒントをエンコーダに送信することを含んでいる。本方法は、第１のビデオフレームをエンコーダに送達することを含んでおり、第１のビデオフレームは、シーン変化ヒントに基づいてＩフレームとしてエンコードされている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて、エンコーダで受信された第２のビデオフレームをエンコードするかエンコードしないかを判定することを含んでいる。

【0009】

別の実施形態では、クラウドゲーミング用のコンピュータプログラムを格納する非一時的なコンピュータ可読媒体が開示されている。コンピュータ可読媒体は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに複数のビデオフレームを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、ビデオゲームの第１のビデオフレームのシーン変化を予測するためのプログラム命令を含んでおり、シーン変化は、第１のビデオフレームが生成される前に予測されている。コンピュータ可読媒体は、第１のビデオフレームがシーン変化であるシーン変化ヒントを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、シーン変化ヒントをエンコーダに送信するためのプログラム命令を含んでいる。コンピュータ可読媒体は、第１のビデオフレームをエンコーダに配信するためのプログラム命令を含んでおり、第１のビデオフレームは、シーン変化ヒントに基づいてＩフレームとしてエンコードされている。コンピュータ可読媒体は、クライアントの最大受信帯域幅を測定するためのプログラム命令を含んでいる。コンピュータ可読媒体は、エンコーダで受信した第２のビデオフレームをエンコードするかエンコードしないかをクライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて判定するためのプログラム命令を含んでいる。

【0010】

さらに別の実施形態では、コンピュータシステムは、プロセッサと、プロセッサに結合され、コンピュータシステムによって実行されると、コンピュータシステムにクラウドゲーミングの方法を実行させる命令をその中に格納したメモリと、を含む。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、ビデオゲームの第１のビデオフレームのシーン変化を予測することを含んでおり、シーン変化は、第１のビデオフレームが生成される前に予測されている。本方法は、第１のビデオフレームがシーン変化である、シーン変化ヒントを生成することを含んでいる。
本方法は、シーン変化ヒントをエンコーダに送信することを含んでいる。本方法は、第１のビデオフレームをエンコーダに送達することを含んでおり、第１のビデオフレームは、シーン変化ヒントに基づいてＩフレームとしてエンコードされている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて、エンコーダで受信された第２のビデオフレームをエンコードするかエンコードしないかを判定することを含んでいる。

【0011】

本開示の他の態様は、本開示の原理を例として示す、添付の図面と併せて取られる以下の詳細な説明から明らかになるであろう。

【0012】

本開示は、添付の図面と併せて以下の説明を参照することによって最もよく理解することができる。

【図面の簡単な説明】

【0013】

【図1A】本開示の一実施形態による、フレーム期間の開始時のＶＳＹＮＣ信号の図である。

【図1B】本開示の一実施形態による、ＶＳＹＮＣ信号の周波数の図である。

【図2A】本開示の一実施形態による、様々な構成において、１つ以上のクラウドゲーミングサーバと１つ以上のクライアントデバイスとの間でネットワークを介してゲームを提供するためのシステムの図であり、ＶＳＹＮＣ信号は、同期及びオフセットされ、一方向レイテンシを低減することができる。

【図2B】本開示の一実施形態による、２つ以上のピアデバイス間でゲームを提供するための図であり、ＶＳＹＮＣ信号は、同期及びオフセットされ、コントローラ及びデバイス間の他の情報の受信の最適なタイミングを達成することができる。

【図2C】本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のＶＳＹＮＣ信号の適切な同期及びオフセットから恩恵を得る様々なネットワーク構成を示す。

【図2D】本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のＶＳＹＮＣ信号の適切な同期及びオフセットから恩恵を得る、クラウドゲーミングサーバと複数のクライアントとの間のマルチテナンシ構成を示す。

【図3】本開示の一実施形態による、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときのクロックドリフトによるクラウドゲーミングサーバとクライアントとの間の一方向レイテンシの変動を示す。

【図4】サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときのクラウドゲーミングサーバとクライアントを含むネットワーク構成を示し、サーバとクライアントとの間のＶＳＹＮＣ信号は、同期かつオフセットされており、サーバ及びクライアントでの操作の重複を可能にし、サーバとクライアント間の一方向レイテンシを低減する。

【図5】本開示の一実施形態による、クラウドゲーミングの方法を示すフロー図であり、ビデオフレームのエンコードが、ネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダパラメータの調節を含む。

【図6】本開示の一実施形態による、アプリケーション層で動作するストリーマ構成要素によるクライアントの帯域幅の測定を示す図であり、ストリーマは、エンコーダを監視し、調節するように構成されており、圧縮されたビデオフレームが、クライアントの測定された帯域幅内の速度で伝送され得るようになっている。

【図7】Ａは本開示の一実施形態による、クライアントにおける品質及びバッファ利用を最適化するためのエンコーダの量子化パラメータ（ＱＰ）の設定を示す図、Ｂは本開示の一実施形態による、クライアントによってサポートされる真の目標フレームサイズを超えるＩフレームの発生を低減するための、目標フレームサイズ、最大フレームサイズ、及び／またはＱＰ（例えば、最小ＱＰ及び／または最大ＱＰ）エンコーダ設定の調節を示す図である。

【図8】本開示の一実施形態による、クラウドゲーミングの方法を示すフロー図であり、ビデオフレームのエンコードは、Ｉフレームをエンコードするときなど、エンコードが長い場合、または生成されているビデオフレームが大きい場合に、ビデオフレームをスキップするか、ビデオフレームのエンコード及び伝送を遅延させるかを決定することを含む。

【図9】Ａは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示しており、エンコーダは、クライアントのディスプレイの目標解像度に対してクライアント帯域幅が低いとき、Ｉフレームをエンコードした後にビデオフレームのエンコードをドロップし、Ｂは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示し、各シーケンスでは、ビデオフレームがＩフレームとしてエンコードされており、後続のビデオフレームも、クライアント帯域幅が、クライアントのディスプレイの目標解像度に対して中程度または高いときに、Ｉフレームのエンコードの遅延後にエンコードされ、Ｃは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示し、各シーケンスでは、ビデオフレームがＩフレームとしてエンコードされており、後続のビデオフレームも、クライアント帯域幅が、クライアントのディスプレイの目標解像度に対して中程度または高いときに、Ｉフレームのエンコードの遅延後にエンコードされている。

【図10】本開示の様々な実施形態の態様を実行するために使用されることができる例示的なデバイスの構成要素を示している。

【発明を実施するための形態】

【0014】

以下の詳細な説明は、例示の目的で多くの具体的な詳細を含むが、当業者は、以下の詳細に対する多くの変形及び変更が本開示の範囲内にあることを理解するであろう。従って、以下に説明する本開示の態様は、この説明に続く特許請求の範囲に対する一般性を失うことなく、また制限を課すことなく説明されている。

【0015】

一般的に言えば、本開示の様々な実施形態は、メディアコンテンツをストリーミングするとき（例えば、ビデオゲームからオーディオ及びビデオをストリーミングするとき）、ソースデバイスとターゲットデバイスとの間のレイテンシ及び／またはレイテンシの不安定性を低減するように構成された方法及びシステムを説明する。サーバにおいて複雑なフレーム（例えば、シーン変化）を生成するために必要になる追加の時間、サーバにおいて複雑なフレームのエンコード／圧縮にかかる時間増加、ネットワークを介した可変通信経路、及びクライアントにおいて複雑なフレームをデコードにかかる時間増加により、サーバとクライアント間の一方向レイテンシにレイテンシ不安定性が生じる可能性がある。レイテンシの不安定性はまた、サーバとクライアントのＶＳＹＮＣ信号の間にドリフトを生じさせるサーバとクライアントにおけるクロックの違いによっても導入され得る。
本開示の実施形態では、サーバとクライアントとの間の一方向レイテンシは、高性能のエンコード及びデコードを提供することによって、クラウドゲーミングアプリケーションにおいて低減され得る。ストリーミングメディア（例えば、ストリーミングビデオ、映画、クリップ、コンテンツ）を解凍するとき、解凍されたビデオのかなりの量をバッファリングすることが可能であり、従って、ストリーミングされたコンテンツを表示するときに、平均のデコード能力及びメトリクスに依存（例えば、６０Ｈｚで４Ｋメディアをサポートするには、デコードリソースの平均量に依存）することが可能である。
しかしながら、クラウドゲーミングでは、（単一フレームであっても）エンコード及び／またはデコード操作を実行する時間が長くなると、それに応じて一方向レイテンシがより高くなる。従って、クラウドゲーミングの場合、ストリーミングビデオアプリケーションの必要性と比較すると不要と見える強力なデコードリソース及びエンコードリソースを供給することが有益であり、リソースは、より長いか、または最も長い処理を必要とするフレームを処理する時間のために最適化される必要がある。本開示の他の実施形態では、クラウドゲーミングアプリケーションにおいてレイテンシとビデオ品質との間のトレードオフを改善するためにエンコーダ調節が実行され得る。
エンコーダ調節は、ネットワークの伝送速度と信頼性の認識、及び全体的なレイテンシ目標のなかで実行される。実施形態では、エンコードが長く実行されるか、または生成されたデータが大きい（例えば、圧縮されたＩフレームで両方の条件が発生し得る）場合、後続のフレームのエンコード及び伝送を遅延させるか、またはそれらをスキップするかどうかを判定するための方法が実行される。
実施形態では、量子化パラメータ（ＱＰ）値、目標フレームサイズ、及び最大フレームサイズの調節は、クライアントへの利用可能なネットワーク速度に基づいて実行されている。例えば、ネットワーク速度がより速い場合、ＱＰは低減され得る。
他の実施形態では、Ｉフレーム発生率の監視が実行され、ＱＰの設定に使用される。例えば、Ｉフレームの頻度が低い場合、ＱＰは低減されることができ（例えば、より高いエンコード精度、またはエンコードのより高い品質をもたらす）、ビデオ再生品質を犠牲にする一方で、一方向レイテンシを低く抑えるためにビデオフレームのエンコードがスキップされ得るようになっている。このように、高性能のエンコードとデコード、及びクラウドゲーミングアプリケーションのレイテンシとビデオ品質の間のトレードオフを改善するために実行されるエンコーダ調節は、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシの低減、よりスムーズなフレームレート、及びより信頼性の高い及び／または一貫した一方向レイテンシへと繋がる。

【0016】

上述の様々な実施形態の一般的な理解を伴って、実施形態の例示的な詳細が、様々な図面を参照して説明される。

【0017】

明細書全体を通して、「ゲーム」または「ビデオゲーム」または「ゲーミングアプリケーション」への言及は、入力コマンドの実行を通じて指示される任意タイプのインタラクティブアプリケーションを表すことを意味する。例示的目的としてだけに、インタラクティブアプリケーションは、ゲーム、ワードプロセッシング、ビデオプロセッシング、ビデオゲームプロセッシングなどのためのアプリケーションを含む。さらに、上記で紹介した用語は互換性があるものである。

【0018】

クラウドゲーミングは、サーバでビデオゲームを実行して、ゲームでレンダリングされたビデオフレームを生成することを含み、これらは、次いで表示のためにクライアントに送信される。サーバとクライアントの両方での操作のタイミングは、それぞれの垂直同期（ＶＳＹＮＣ）パラメータに関連付けられ得る。ＶＳＹＮＣ信号が、サーバ及び／またはクライアント間で適切に同期及び／またはオフセットされると、サーバで実行される操作（例えば、１つ以上のフレーム期間にわたるビデオフレームの生成と伝送）は、クライアントで実行される操作（例えば、フレーム期間に対応する表示フレームまたはリフレッシュレートでディスプレイにビデオフレームを表示する）と同期される。特に、サーバで生成されたサーバＶＳＹＮＣ信号とクライアントで生成されたクライアントＶＳＹＮＣ信号は、サーバとクライアントでの操作を同期させるために使用され得る。つまり、サーバとクライアントのＶＳＹＮＣ信号が同期及び／またはオフセットされると、サーバは、クライアントがそれらのビデオフレームを表示する方法と同期してビデオフレームを生成及び送信する。

【0019】

サーバとクライアントとの間でメディアコンテンツをストリーミングするときにビデオフレームを生成し、それらのビデオフレームを表示するために、ＶＳＹＮＣ信号と垂直帰線区間（ＶＢＩ）が組み込まれている。例えば、サーバは、対応するサーバＶＳＹＮＣ信号で規定された１つ以上のフレーム期間でゲーム用にレンダリングされたビデオフレームを生成しようとし（例えば、フレーム期間が１６．７ｍｓの場合、フレーム期間ごとにビデオフレームを生成すると、６０Ｈｚの操作になり、２つのフレーム期間ごとに１つのビデオフレームを生成すると、３０Ｈｚの操作になる）、その後、そのビデオフレームをエンコードしてクライアントに伝送する。クライアントでは、受信したエンコードされたビデオフレームがデコードされて表示され、クライアントは、対応するクライアントＶＳＹＮＣで始まる表示用にレンダリングされた各ビデオフレームを表示する。

【0020】

例示のために、図１Ａは、ＶＳＹＮＣ信号１１１が、フレーム期間の開始をどのように示し得るかを示しており、ここで、様々な操作が、サーバ及び／またはクライアントにおいて、対応するフレーム期間中に実行され得る。メディアコンテンツをストリーミングするとき、サーバは、ビデオフレームを生成及びエンコードするためにサーバＶＳＹＮＣ信号を使用することができ、クライアントは、ビデオフレームを表示するためにクライアントＶＳＹＮＣ信号を使用することができる。ＶＳＹＮＣ信号１１１は、図１Ｂに示されるように、規定されたフレーム期間１１０に対応する規定された周波数で生成される。さらに、ＶＢＩ１０５は、最後のラスターラインが、前のフレーム期間のためにディスプレイ上に描かれたときと、最初のラスターライン（例えば、上）が、ディスプレイに描かれたときとの間の期間を規定する。図示されるように、ＶＢＩ１０５の後、表示のためにレンダリングされたビデオフレームは、ラスタースキャンライン１０６を介して表示される（例えば、左から右へのラスターラインごとのラスターライン）。

【0021】

さらに、本開示の様々な実施形態は、メディアコンテンツ（例えば、ビデオゲームコンテンツ）をストリーミングするときなどの、ソースデバイスとターゲットデバイスとの間の一方向レイテンシ及び／またはレイテンシ不安定性を低減するために開示される。説明のみを目的として、一方向レイテンシ及び／またはレイテンシ不安定性を低減するための様々な実施形態が、サーバとクライアントのネットワーク構成の中で説明されている。しかしながら、図２Ａ～図２Ｄに示されるように、一方向レイテンシ及び／またはレイテンシ不安定性を低減するために開示された様々な技術は、他のネットワーク構成内で、及び／またはピアツーピアネットワーク上で実装され得ることが理解される。例えば、一方向レイテンシ及び／またはレイテンシ不安定性を低減するために開示される様々な実施形態は、（例えば、サーバとクライアント、サーバとサーバ、サーバと複数のクライアント、サーバと複数のサーバ、クライアントとクライアント、クライアントと複数のクライアント、など）様々な構成で１つ以上のサーバとクライアントデバイスとの間に実装され得る。

【0022】

図２Ａは、様々な構成で、ネットワーク２５０を介して１つ以上のクラウドゲーミングネットワーク２９０及び／またはサーバ２６０と１つ以上のクライアントデバイス２１０との間にゲームを提供するためのシステム２００Ａの図であり、本開示の一実施形態によれば、サーバ及びクライアントのＶＳＹＮＣ信号は同期及びオフセットされることができ、及び／または、動的バッファリングがクライアント上で実行されており、及び／または、サーバ上でのエンコード及び伝送操作が重複されることができ、及び／または、クライアントでの受信及びデコード操作が重複されることができ、及び／または、クライアント上でのデコード及び表示操作が重複され、サーバ２６０とクライアント２１０との間の一方向レイテンシを短縮することができる。
特に、本開示の一実施形態によれば、システム２００Ａは、クラウドゲームネットワーク２９０を介してゲームを提供し、ゲームは、ゲームをプレイしている対応するユーザのクライアントデバイス２１０（例えば、シンクライアント）から遠隔で実行されている。システム２００Ａは、シングルプレイヤーモードまたはマルチプレイヤーモードのいずれかで、ネットワーク２５０を介してクラウドゲームネットワーク２９０を通じて１つ以上のゲームをプレイする１人以上のユーザにゲーム制御を提供することができる。いくつかの実施形態では、クラウドゲーミングネットワーク２９０は、ホストマシンのハイパーバイザー上で実行される複数の仮想マシン（ＶＭ）を含み得、１つ以上の仮想マシンは、ホストマシンのハイパーバイザーに利用可能なハードウェアリソースを利用してゲームプロセッサモジュールを実行するように構成される。ネットワーク２５０は、１つ以上の通信技術を含み得る。いくつかの実施形態では、ネットワーク２５０は、高度な無線通信システムを有する第５世代（５Ｇ）ネットワーク技術を含み得る。

【0023】

いくつかの実施形態では、通信は、無線技術を使用して促進され得る。そのような技術は、例えば、５Ｇ無線通信技術を含み得る。５Ｇは、セルラーネットワーク技術の第５世代である。５Ｇネットワークは、デジタルセルラーネットワークであり、プロバイダーがカバーするサービスエリアは、セルと呼ばれる小さな地理的エリアに分割されている。音と画像を表すアナログ信号は、電話でデジタル化され、アナログ－デジタルコンバータによって変換され、ビットのストリームとして伝送される。セル内のすべての５Ｇ無線デバイスは、他のセルで再利用される周波数のプールからトランシーバによって割り当てられた周波数チャネルを介して、セル内のローカルアンテナアレイ及び低電力自動トランシーバ（伝送機及び受信機）を用いて電波で通信する。ローカルアンテナは、高帯域幅の光ファイバまたは無線バックホール接続によって電話網及びインターネットに接続される。他のセルネットワークと同様に、あるセルから別のセルに移動するモバイルデバイスは、新しいセルに自動的に転送される。５Ｇネットワークは、通信ネットワークの単なる一例示的タイプであり、本開示の実施形態は、５Ｇに続く後続世代の有線技術または無線技術と同様に、前世代の無線通信または有線通信を利用することができることを理解されたい。

【0024】

図示されるように、クラウドゲーミングネットワーク２９０は、複数のビデオゲームへのアクセスを提供するゲームサーバ２６０を含む。ゲームサーバ２６０は、クラウドで利用可能な任意タイプのサーバコンピューティングデバイスであり得、そして１つ以上のホスト上で実行される１つ以上の仮想マシンとして構成され得る。例えば、ゲームサーバ２６０は、ユーザのためにゲームのインスタンスをインスタンス化するゲームプロセッサをサポートする仮想マシンを管理することができる。このように、複数の仮想マシンに関連付けられたゲームサーバ２６０の複数のゲームプロセッサは、複数のユーザのゲームプレイに関連付けられた１つ以上のゲームの複数のインスタンスを実行するように構成されている。
そのようにして、バックエンドサーバサポートは、複数のゲームアプリケーションのゲームプレイのメディア（例えば、ビデオ、オーディオなど）のストリーミングを複数の対応するユーザに提供する。つまり、ゲームサーバ２６０は、ネットワーク２５０を介してデータ（例えば、対応するゲームプレイのレンダリングされた画像及び／またはフレーム）を対応するクライアントデバイス２１０にストリーミングして戻すように構成されている。そのようにして、計算が複雑なゲームアプリケーションは、クライアントデバイス２１０によって受信及び転送されたコントローラ入力に応答して、バックエンドサーバで実行され得る。各サーバは、画像やフレームをレンダリングすることができ、これらは次いでエンコード（例えば、圧縮）され、対応するクライアントデバイスに表示のためにストリーミングされ得る。

【0025】

例えば、複数のユーザは、ストリーミングメディアを受信するように構成された対応するクライアントデバイス２１０を使用して、通信ネットワーク２５０を介してクラウドゲームネットワーク２９０にアクセスすることができる。一実施形態では、クライアントデバイス２１０は、計算機能（例えば、ゲームタイトル処理エンジン２１１を含む）を提供するように構成されたバックエンドサーバ（例えば、クラウドゲームネットワーク２９０のゲームサーバ２６０）とのインターフェースを提供するシンクライアントとして構成され得る。
別の実施形態では、クライアントデバイス２１０は、ビデオゲームの少なくともいくつかのローカル処理のためのゲームタイトル処理エンジン及びゲームロジックで構成され得、バックエンドで実行されるビデオゲームによって生成されるストリーミングコンテンツを受信するために、または、バックエンドサーバサポートによって提供されるその他のコンテンツのためにさらに利用され得る。ローカル処理に対して、ゲームタイトル処理エンジンは、ビデオゲームを実行するための基本的なプロセッサベースの機能と、ビデオゲームに関連するサービスと、を含む。ゲームロジックは、ローカルクライアントデバイス２１０に格納され、ビデオゲームを実行するために使用される。

【0026】

特に、対応するユーザ（図示せず）のクライアントデバイス２１０は、インターネットなどの通信ネットワーク２５０を介してゲームへのアクセスを要求するように、及びゲームサーバ２６０によって実行されるビデオゲームによって生成される表示画像をレンダリングするように構成され、エンコードされた画像は、対応するユーザに関連付けて表示するためにクライアントデバイス２１０に配信されている。
例えば、ユーザは、クライアントデバイス２１０を介して、ゲームサーバ２６０のゲームプロセッサ上で実行されているビデオゲームのインスタンスと対話し得る。より具体的には、ビデオゲームのインスタンスは、ゲームタイトル処理エンジン２１１によって実行されている。ビデオゲームを実装する対応するゲームロジック（例えば、実行可能コード）２１５は、データストア（図示せず）に格納され、データストアを介してアクセス可能であり、ビデオゲームを実行するために使用されている。ゲームタイトル処理エンジン２１１は、複数のゲームロジックを使用して複数のビデオゲームをサポートすることができ、それらの各々がユーザによって選択可能である。

【0027】

例えば、クライアントデバイス２１０は、ゲームプレイを駆動するために使用される入力コマンドを介してなど、対応するユーザのゲームプレイに関連してゲームタイトル処理エンジン２１１と相互作用するように構成される。特に、クライアントデバイス２１０は、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラよってキャプチャされたジェスチャ、マウス、タッチパッドなどの様々なタイプの入力デバイスからの入力を受信することができる。
クライアントデバイス２１０は、ネットワーク２５０を介してゲームサーバ２６０に接続することができる少なくともメモリ及びプロセッサモジュールを有する任意タイプのコンピューティングデバイスであり得る。バックエンドゲームタイトル処理エンジン２１１は、レンダリングされた画像を生成するように構成され、レンダリングされた画像は、クライアントデバイス２１０に関連付けられた対応するディスプレイに表示するためにネットワーク２５０を介して配信される。
例えば、クラウドベースのサービスを通じて、ゲーム用にレンダリングされた画像は、ゲームサーバ２６０のゲーム実行エンジン２１１上で実行される対応するゲームのインスタンスによって配信され得る。つまり、クライアントデバイス２１０は、エンコードされた画像（例えば、ビデオゲームの実行を通じて生成されたゲームレンダリング画像からエンコードされた）を受信し、表示１１のためにレンダリングされた画像を表示するように構成される。一実施形態では、ディスプレイ１１は、ＨＭＤを含む（例えば、ＶＲコンテンツを表示する）。いくつかの実施形態では、レンダリングされた画像は、クラウドベースのサービスから直接的に、またはクライアントデバイス２１０（例えば、プレイステーション（登録商標）リモートプレイ）を介して、無線または有線でスマートフォンまたはタブレットにストリーミングされ得る。

【0028】

一実施形態では、ゲームサーバ２６０及び／またはゲームタイトル処理エンジン２１１は、ゲーム及びゲームアプリケーションに関連するサービスを実行するための基本的なプロセッサベースの機能を含む。例えば、プロセッサベースの機能は、２Ｄまたは３Ｄレンダリング、物理学、物理学シミュレーション、スクリプト、オーディオ、アニメーション、グラフィックス処理、ライティング、シェーディング、ラスター化、レイトレーシング、シャドウイング、カリング、変換、人工知能、等を含む。さらに、ゲームアプリケーションのサービスは、メモリ管理、マルチスレッド管理、サービス品質（ＱｏＳ）、帯域幅テスト、ソーシャルネットワーキング、ソーシャルフレンドの管理、フレンドのソーシャルネットワークとの通信、通信チャネル、テキストメッセージ、インスタントメッセージング、チャットサポートなどを含む。

【0029】

一実施形態では、クラウドゲーミングネットワーク２９０は、分散型ゲームサーバシステム及び／またはアーキテクチャである。特に、ゲームロジックを実行する分散型ゲームエンジンは、対応するゲームの対応するインスタンスとして構成される。一般に、分散型ゲームエンジンは、ゲームエンジンの各機能を取得し、多数の処理エンティティによる実行のために、それらの機能を分散する。個々の機能は、１つ以上の処理エンティティにわたって、さらに分散され得る。処理エンティティは、物理ハードウェアを含むさまざまな構成で、及び／または、仮想構成要素または仮想マシンとして、及び／または、仮想コンテナとして構成され得、コンテナは、仮想化されたオペレーティングシステム上で実行中のゲームアプリケーションのインスタンスを仮想化することから、仮想マシンとは異なっている。
処理エンティティは、クラウドゲーミングネットワーク２９０の１つ以上のサーバ（コンピューティングノード）上のサーバ及びその基礎となるハードウェアを利用及び／または依存することができ、サーバは、１つ以上のラックに配置され得る。様々な処理エンティティへのこれらの機能の実行の調整、割り当て、及び管理は、分散同期層によって実行されている。そのようにして、それらの機能の実行が分散同期層によって制御されて、プレイヤーによるコントローラ入力に応答して、ゲームアプリケーション用のメディア（例えば、ビデオフレーム、オーディオなど）を生成することが可能になる。分散同期層は、分散処理エンティティにわたって、（例えば、負荷均衡を通じて）これらの機能を効率的に実行でき、重要なゲームエンジン構成要素／機能が分散され、より効率的な処理のために再構築されるようになっている。

【0030】

ゲームタイトル処理エンジン２１１は、中央処理装置（ＣＰＵ）と、マルチテナンシＧＰＵ機能を実行するように構成され得るグラフィックス処理装置（ＧＰＵ）グループと、を含む。別の実施形態では、複数のＧＰＵデバイスが組み合わせられて、対応するＣＰＵ上で実行されている単一アプリケーションのグラフィックス処理を実行する。

【0031】

図２Ｂは、本開示の一実施形態による、２つ以上のピアデバイス間でゲームを提供するための図であり、ＶＳＹＮＣ信号は、同期及びオフセットされ、コントローラ及びデバイス間の他の情報の受信の最適なタイミングを達成することができる。例えば、直接対決ゲームは、ネットワーク２５０を介して、またはピアツーピア通信（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ローカルエリアネットワーキングなど）を介して直接接続された２つ以上のピアデバイスを使用して実行され得る。

【0032】

図示されるように、ゲームは、ビデオゲームをプレイしている対応するユーザのクライアントデバイス２１０（例えば、ゲームコンソール）の各々でローカルに実行されており、クライアントデバイス２１０は、ピアツーピアネットワーキングを介して通信する。例えば、ビデオゲームのインスタンスは、対応するクライアントデバイス２１０のゲームタイトル処理エンジン２１１によって実行されている。ビデオゲームを実装するゲームロジック２１５（例えば、実行可能コード）は、対応するクライアントデバイス２１０に格納され、ゲームを実行するために使用されている。説明の目的で、ゲームロジック２１５は、ポータブル媒体（例えば、光媒体）を介して、またはネットワークを介して（例えば、インターネットを介してゲームプロバイダからダウンロードされる）、対応するクライアントデバイス２１０に配信され得る。

【0033】

一実施形態では、対応するクライアントデバイス２１０のゲームタイトル処理エンジン２１１は、ゲーム及びゲームアプリケーションに関連するサービスを実行するための基本的なプロセッサベースの機能を含む。例えば、プロセッサベースの機能は、２Ｄまたは３Ｄレンダリング、物理学、物理学シミュレーション、スクリプト、オーディオ、アニメーション、グラフィックス処理、ライティング、シェーディング、ラスター化、レイトレーシング、シャドウイング、カリング、変換、人工知能、等を含む。さらに、ゲームアプリケーションのサービスは、メモリ管理、マルチスレッド管理、サービス品質（ＱｏＳ）、帯域幅テスト、ソーシャルネットワーキング、ソーシャルフレンドの管理、フレンドのソーシャルネットワークとの通信、通信チャネル、テキストメッセージ、インスタントメッセージング、チャットサポートなどを含む。

【0034】

クライアントデバイス２１０は、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラによってキャプチャされたジェスチャ、マウス、タッチパッドなど、様々なタイプの入力デバイスから入力を受信することができる。クライアントデバイス２１０は、少なくともメモリ及びプロセッサモジュールを有する任意タイプのコンピューティングデバイスであり得、ゲームタイトル処理エンジン２１１によって実行されるレンダリング画像を生成し、ディスプレイ（例えば、ディスプレイ１１、またはヘッドマウントディスプレイ（ＨＭＤ）を含むディスプレイ１１など）にレンダリング画像を表示するように構成される。
例えば、レンダリングされた画像は、クライアントデバイス２１０上でローカルに実行されるゲームのインスタンスに関連付けられ得、ゲームプレイを駆動するために使用される入力コマンドなどを介して、対応するユーザのゲームプレイを実装する。クライアントデバイス２１０のいくつかの例には、パーソナルコンピュータ（ＰＣ）、ゲームコンソール、ホームシアターデバイス、汎用コンピュータ、モバイルコンピューティングデバイス、タブレット、電話、またはゲームのインスタンスを実行することができる任意の他のタイプのコンピューティングデバイスが含まれる。

【0035】

図２Ｃは、本開示の実施形態による、ソースデバイスとターゲットデバイスとの間のＶＳＹＮＣ信号の適切な同期及びオフセットから恩恵を得る、図２Ａ～図２Ｂに示される構成を含む、様々なネットワーク構成を示している。特に、様々なネットワーク構成は、サーバとクライアントのＶＳＹＮＣ信号の周波数の適切なアライメント、及びサーバとクライアント間の一方向レイテンシ及び／またはレイテンシ変動性を低減する目的のサーバとクライアントのＶＳＹＮＣ信号のタイミングオフセットの恩恵を得る。例えば、１つのネットワークデバイス構成は、クラウドゲーミングサーバ（例えば、ソース）からクライアント（ターゲット）への構成を含む。
一実施形態では、クライアントは、ウェブブラウザ内でオーディオ及びビデオ通信を提供するように構成されたウェブＲＴＣクライアントを含み得る。別のネットワーク構成は、クライアント（例えば、ソース）からサーバ（ターゲット）への構成を含む。さらに別のネットワーク構成は、サーバ（例えば、ソース）からサーバ（例えば、ターゲット）への構成を含む。別のネットワークデバイス構成は、クライアント（例えば、ソース）からクライアント（ターゲット）への構成を含み、クライアントは各々が、例えば、直接対決ゲームを提供するためのゲームコンソールであり得る。

【0036】

特に、ＶＳＹＮＣ信号のアラインメントは、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号の周波数の同期を含み得、ドリフトを除去する目的のため、及び／または、一方向レイテンシ及び／またはレイテンシ変動性を低減する目的で、サーバとクライアントのＶＳＹＮＣ信号間の理想的な関係を維持するために、クライアントＶＳＹＮＣ信号とサーバＶＳＹＮＣ信号との間のタイミングオフセットを調整することも含み得る。
適切なアライメントを達成するために、一実施形態では、サーバ２６０とクライアント２１０のペアとの間の適切なアライメントを実施するために、サーバＶＳＹＮＣ信号が調節され得る。
別の実施形態では、クライアントＶＳＹＮＣ信号は、サーバ２６０とクライアント２１０のペアとの間の適切なアライメントを実施するために調節され得る。クライアントとサーバのＶＳＹＮＣ信号がアライメントされると、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号は、実質的に同一周波数で発生し、随時調整できるタイミングオフセットによって互いにオフセットされる。
別の実施形態では、ＶＳＹＮＣ信号のアライメントは、２つのクライアントのＶＳＹＮＣの周波数を同期させることを含み得、ドリフトを除去する目的で、それらのＶＳＹＮＣ信号の間のタイミングオフセットを調整すること、及び／またはコントローラ及びその他の情報の受信の適切なタイミングを達成することも含み得、いずれのＶＳＹＮＣ信号も、このアライメントを達成するように調節され得る。
さらに別の実施形態では、アラインメントは、複数のサーバのＶＳＹＮＣの周波数を同期させることを含み得、また、サーバＶＳＹＮＣ信号及びクライアントＶＳＹＮＣ信号の周波数を同期し、クライアントＶＳＹＮＣ信号とサーバＶＳＹＮＣ信号との間のタイミングオフセットを、例えば、直接対決クラウドゲーミングのために調整することを含み得る。サーバからクライアントへの構成、及びクライアントからクライアントへの構成では、アラインメントは、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号の間の周波数の同期、及びサーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の適切なタイミングオフセットの提供の両方が含まれ得る。サーバからサーバへの構成では、アライメントは、タイミングオフセットを設定することを伴わないサーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の周波数の同期を含み得る。

【0037】

図２Ｄは、本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のＶＳＹＮＣ信号の適切な同期及びオフセットから恩恵がもたらされるクラウドゲーミングサーバ２６０と１つ以上のクライアント２１０との間のマルチテナンシ構成を示す。サーバからクライアントへの構成では、アライメントは、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の周波数の同期、及びサーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の適切なタイミングオフセットの提供の両方を含み得る。マルチテナンシ構成では、一実施形態では、サーバ２６０とクライアント２１０のペアとの間の適切なアライメントを実施するために、クライアントＶＳＹＮＣ信号が各クライアント２１０において調節されている。

【0038】

例えば、グラフィックスサブシステムは、マルチテナンシＧＰＵ機能を実行するように構成され得、一実施形態では、１つのグラフィックスサブシステムは、グラフィックスの実装、及び／または複数のゲームのためのパイプラインのレンダリングである場合がある。つまり、グラフィックサブシステムは、実行されている複数のゲーム間で共有される。特に、ゲームタイトル処理エンジンは、マルチテナンシＧＰＵ機能を実行するように構成されたＣＰＵ及びＧＰＵグループを含み得、一実施形態では、１つのＣＰＵ及びＧＰＵグループは、グラフィックスの実装、及び／または複数のゲームのためのパイプラインのレンダリングである場合がある。つまり、ＣＰＵ及びＧＰＵグループは、実行されている複数のゲーム間で共有される。ＣＰＵ及びＧＰＵグループは、１つ以上の処理デバイスとして構成されることができる。別の実施形態では、複数のＧＰＵデバイスが組み合わせられて、対応するＣＰＵ上で実行されている単一アプリケーションのグラフィックス処理を実行する。

【0039】

図３は、サーバでビデオゲームを実行してゲーム用にレンダリングされたビデオフレームを生成し、それらのビデオフレームを表示のためにクライアントに送信する一般的なプロセスを示している。従来的に、ゲームサーバ２６０及びクライアント２１０における、いくつかの操作は、それぞれのＶＳＹＮＣ信号によって規定されるフレーム期間内に実行される。例えば、サーバ２６０は、対応するサーバＶＳＹＮＣ信号３１１によって規定されるような１つ以上のフレーム期間において、３０１においてゲーム用にレンダリングされたビデオフレームを生成しようと努める。
ビデオフレームは、操作３５０で入力デバイスから配信される制御情報（例えば、ユーザの入力コマンド）、または制御情報によって駆動されないゲームロジックのいずれかに応答して、ゲームによって生成される。伝送ジッター３５１は、制御情報をサーバ２６０に送信するときに存在し得、ジッター３５１は、クライアントからサーバへのネットワークレイテンシの変動（例えば、入力コマンドを送信するとき）を測定する。
図示されるように、太い矢印は、制御情報をサーバ２６０に送信するときの現在の遅延を示しているが、ジッターのために、サーバ２６０において制御情報のための到着時間の範囲（例えば、点線矢印で囲まれた範囲）があり得る。フリップ時間３０９で、ＧＰＵは、対応するビデオフレームが完全に生成され、サーバ２６０のフレームバッファに配置されたことを示すフリップコマンドに到達する。その後、サーバ２６０は、サーバＶＳＹＮＣ信号３１１（ＶＢＩは明確化のために省略されている）によって規定される後続のフレーム期間にわたって、そのビデオフレームに対してスキャンアウト／スキャンイン（操作３０２、そこでスキャンアウトはＶＳＹＮＣ信号３１１とアライメントされ得る）を実行する。続いて、ビデオフレームがエンコード（操作３０３）され（例えば、ＶＳＹＮＣ信号３１１の発生後にエンコードが開始され、エンコードの終了はＶＳＹＮＣ信号とアライメントされなくてもよい）、クライアント２１０へ伝送（操作３０４、ここでは伝送はＶＳＹＮＣ信号３１１とアライメントされなくてもよい）される。
クライアント２１０において、エンコードされたビデオフレームは、受信され（操作３０５、ここでは受信はクライアントＶＳＹＮＣ信号３１２とアライメントされなくてもよい）、デコードされ（操作３０６、ここではデコードはクライアントＶＳＹＮＣ信号３１２とアライメントされなくてもよい）、バッファリングされ、表示される（操作３０７、ここでは表示の開始は、クライアントのＶＳＹＮＣ信号３１２とアライメントされなくてもよい）。特に、クライアント２１０は、クライアントＶＳＹＮＣ信号３１２の対応する発生で開始する表示のためにレンダリングされた各ビデオフレームを表示する。

【0040】

一方向レイテンシ３１５は、サーバでのビデオフレームのエンコードユニット（例えば、スキャンアウト３０２）への転送の開始から、クライアント３０７でのビデオフレームの表示の開始までのレイテンシとして定義され得る。つまり、一方向レイテンシは、クライアントのバッファリングを考慮した、サーバのスキャンアウトからクライアントの表示までの時間である。個々のフレームは、スキャンアウト３０２の開始からデコード３０６の完了までのレイテンシを有し、このレイテンシは、エンコード３０３と伝送３０４、サーバ２６０とクライアント２１０との間のジッター３５２を伴うネットワーク伝送、及びクライアント受信３０５などのサーバ操作の高度な変動により、フレームごとに変化し得る。
図示されているように、直線の太い矢印は、対応するビデオフレームをクライアント２１０に送信するときの現在のレイテンシを示しているが、ジッター３５２のために、クライアント２１０におけるビデオフレームの到着時間の範囲（例えば、点線矢印で区分けされた範囲）があり得る。良好な再生体験を実現するには、一方向レイテンシが比較的安定している（例えば、かなり一貫性が保たれている）必要があるため、従来、バッファリング３２０は、低いレイテンシ（例えば、スキャンアウト３０２の開始からデコード３０６の完了まで）を伴う個々のフレームの表示が、いくつかのフレーム期間にわたり遅延される結果を伴って実行される。つまり、ネットワークの不安定性、または予測できないエンコード／デコード時間がある場合、一方向レイテンシが一定に保たれるように追加のバッファリングが必要になる。

【0041】

本開示の一実施形態によれば、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシは、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときに、クロックドリフトのために変化し得る。つまり、サーバＶＳＹＮＣ信号３１１とクライアントＶＳＹＮＣ信号３１２の周波数の違いは、サーバ２６０から到着するフレームに対してドリフトするクライアントＶＳＹＮＣ信号を生じ得る。このドリフトは、サーバとクライアントにおけるそれぞれのクロックの各々で使用される水晶振動子での、ごくわずかな違いによるものであり得る。さらに、本開示の実施形態は、サーバとクライアントとの間のアラインメントのためのＶＳＹＮＣ信号の同期及びオフセットの１つ以上を実行することによって、クライアントにおいて動的バッファリングを提供することによって、サーバにおいてビデオフレームのエンコード及び伝送を重複させることによって、クライアントにおいてビデオフレームの受信とデコードを重複させることによって、かつ、クライアントにおいてビデオフレームのデコードと表示を重複させることによって、一方向レイテンシを低減する。

【0042】

さらに、ビデオフレームのエンコード（操作３０３）の間、以前の技術では、エンコーダは、エンコードされている現在のビデオフレームと１つ以上の以前にエンコードされたフレームとの間にどれだけの変化があるかを判定して、シーン変化（例えば、対応する生成されたビデオフレームの複雑な画像）があるかどうかを判定する。つまり、シーン変化ヒントは、エンコードされる現在のフレームと、既にエンコードされている以前のフレームとの違いから推測できる。ネットワークを介してサーバからクライアントにコンテンツをストリーミングするとき、サーバにおけるエンコーダは、複雑性を伴うシーン変化として検出されるビデオフレームをエンコードすることを決定することができる。そうでない場合、エンコーダは、より低い複雑性を有するシーン変化として検出されないビデオフレームをエンコードする。
しかしながら、エンコーダにおけるシーン変化の検出は、ビデオフレームが初めに、より低い複雑性を伴って（第１のフレーム期間で）エンコードされるが、次いで、シーン変化があると判断されると、より高い複雑性を伴って（第２のフレーム期間で）再エンコードされるように、最大１フレーム期間（例えば、ジッターの追加）がかかり得る。同様に、シーン変化の検出は、シーン変化がないとしても、現在エンコードされているビデオフレームと以前にエンコードされたビデオフレームとの差異が閾値差異値を超え得ることから、（画像内の小さな爆発を介してなど）不必要にトリガーされ得る。このように、シーン変化がエンコーダにおいて検出されると、ジッターによる追加的なレイテンシがエンコーダにおいて導入され、シーン変化の検出の実行と、より高い複雑性を有するビデオフレームの再エンコードと、に適応する。

【0043】

図４は、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときの、高度に最適化されたクラウドゲーミングサーバ２６０と、高度に最適化されたクライアント２１０と、を含むネットワーク構成を通るデータのフローを示し、本開示の実施形態によれば、サーバ操作とクライアント操作の重複が、一方向レイテンシを低減し、サーバとクライアント間のＶＳＹＮＣ信号の同期及びオフセットが、一方向レイテンシを低減し、同時に、サーバとクライアント間の一方向レイテンシの変動性を低減する。
特に、図４は、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の望ましいアライメントを示している。一実施形態では、サーバＶＳＹＮＣ信号３１１の調節は、サーバ及びクライアントのネットワーク構成などにおいて、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の適切なアライメントを得るために実行されている。
別の実施形態では、クライアントＶＳＹＮＣ信号３１２の調節は、マルチテナントサーバから複数クライアントへのネットワーク構成におけるような、サーバＶＳＹＮＣ信号とクライアントＶＳＹＮＣ信号との間の適切なアラインメントを得るために実行されている。サーバ及びクライアントのＶＳＹＮＣ信号の周波数を同期させること、及び／または対応するクライアント及びサーバのＶＳＹＮＣ信号間のタイミングオフセットを調整することを目的として、例示を目的として、サーバＶＳＹＮＣ信号３１１の調節が図４で説明されているが、クライアントＶＳＹＮＣ信号３１２もまた、調節に使用され得ることが理解される。
この特許出願の文脈では、「同期」とは、周波数が一致するが、位相は異なり得るように信号を調節することを意味すると解釈されるべきであり、「オフセット」とは、例えば、一方の信号が最大値に達したときと、もう一方の信号が最大値に達したときとの間の時間のように、信号間の時間遅延を意味すると解釈されるべきである。

【0044】

図示されているように、図４は、本開示の実施形態において、サーバにおいてビデオゲームを実行してレンダリングされたビデオフレームを生成し、それらのビデオフレームを表示のためにクライアントに送信する改善されたプロセスを示している。本プロセスは、サーバとクライアントにおける単一ビデオフレームの生成と表示に関して示されている。特に、サーバは、４０１においてゲーム用にレンダリングされたビデオフレームを生成する。例えば、サーバ２６０は、ゲームを実行するように構成されたＣＰＵ（例えば、ゲームタイトル処理エンジン２１１）を含む。ＣＰＵは、ビデオフレームに対して１つ以上のドローコールを生成し、このドローコールは、グラフィックスパイプライン内のサーバ２６０の対応するＧＰＵによって実行するためにコマンドバッファに配置されたコマンドを含む。
グラフィックスパイプラインは、シーン内のオブジェクトの頂点に１つ以上のシェーダプログラムを含み、表示用のビデオフレームにレンダリングされたテクスチャ値を生成でき、この操作は、効率を上げるためにＧＰＵを介して並行して実行されている。フリップ時間４０９において、ＧＰＵは、コマンドバッファ内のフリップコマンドに到達し、これは、対応するビデオフレームが、完全に生成され、及び／またはレンダリングされ、サーバ２６０でフレームバッファ内に配置されたことを示している。

【0045】

４０２において、サーバはゲーム用にレンダリングされたビデオフレームのスキャンアウトをエンコーダに実行する。特に、スキャンアウトは、スキャンラインごとに、または連続するスキャンラインのグループで実行され、スキャンラインは、例えば、画面の端から画面の端までの単一の水平線の表示を指す。これらのスキャンラインまたは連続するスキャンラインのグループは、スライスと称されることもあり、この明細書ではスクリーンスライスと称されている。特に、スキャンアウト４０２は、いくつかのプロセスを含み得、これらはゲーム用にレンダリングされたフレームを変更し、別のフレームバッファでそれをオーバーレイすること、または別のフレームバッファからの情報でそれを囲むためにそれを縮小することを含む。スキャンアウト４０２の間、修正されたビデオフレームは、次いで、圧縮のためにエンコーダにスキャンされる。一実施形態では、スキャンアウト４０２は、ＶＳＹＮＣ信号３１１の発生３１１ａで実行される。他の実施形態では、スキャンアウト４０２は、フリップ時間４０９などで、ＶＳＹＮＣ信号３１１の発生の前に実行され得る。

【0046】

４０３において、ゲーム用にレンダリングされたビデオフレーム（変更された可能性がある）は、エンコーダでエンコーダスライスごとに１つのエンコーダスライスにエンコードされて、１つ以上のエンコードスライスを生成し、ここで、エンコードされたスライスは、スキャンラインまたはスクリーンスライスとは無関係である。このように、エンコーダは、１つ以上のエンコードされた（例えば、圧縮された）スライスを生成する。一実施形態では、エンコードプロセスは、スキャンアウト４０２プロセスが、対応するビデオフレームのために完全に完了する前に開始する。
さらに、エンコード４０３の開始及び／または終了は、サーバＶＳＹＮＣ信号３１１とアライメントされてもされなくてもよい。エンコードされたスライスの境界は、単一のスキャンラインに制限されず、単一のスキャンライン、または複数のスキャンラインで構成され得る。さらに、エンコードされたスライスの終了及び／または次のエンコーダスライスの開始は、必ずしも表示画面の端で発生し得ず（例えば、画面の中央またはスキャンラインの中央で発生し得る）、エンコードされたスライスは、表示画面の端から端まで完全に横断する必要はない。図示されるように、１つ以上のエンコードされたスライスは、ハッシュマークを有する圧縮された「エンコードされたスライスＡ」を含めて、圧縮及び／またはエンコードされ得る。

【0047】

４０４において、エンコードされたビデオフレームは、サーバからクライアントに伝送され、この伝送は、エンコードされたスライスごとに行われることができ、各エンコードされたスライスは、圧縮されたエンコーダスライスである。一実施形態では、伝送プロセス４０４は、エンコードプロセス４０３が、対応するビデオフレームに対して完全に完了する前に開始する。さらに、伝送４０４の開始及び／または終了は、サーバＶＳＹＮＣ信号３１１とアライメントされていてもされていなくてもよい。図示されているように、圧縮されたエンコードされたスライスＡは、レンダリングされたビデオフレームに対する他の圧縮されたエンコーダスライスとは独立してクライアントに伝送される。エンコーダスライスは、一度に１つずつ、または並行して伝送され得る。

【0048】

４０５において、クライアントは圧縮されたビデオフレームを受信し、これもエンコードされたスライスごとに行われる。さらに、受信４０５の開始及び／または終了は、クライアントＶＳＹＮＣ信号３１２とアライメントされても、されなくてもよい。図示されているように、圧縮されたエンコードされたスライスＡが、クライアントによって受信される。伝送ジッター４５２は、サーバ２６０とクライアント２１０との間に存在することができ、ジッター４５２は、サーバ２６０からクライアント２１０へのネットワークレイテンシの変動を測定する。
より低いジッター値は、より安定した接続を示す。図示されているように、太い直線矢印は、対応するビデオフレームをクライアント２１０に送信するときの現在のレイテンシを示しているが、ジッターにより、クライアント２１０におけるビデオフレームに対する到着時間の範囲（例えば、点線矢印で囲まれた範囲）があり得る。レイテンシの変動はまた、エンコード４０３や伝送４０４などのサーバでの１つ以上の操作によるものであり得、同様に、ビデオフレームをクライアント２１０に伝送するときにレイテンシをもたらすネットワークの問題によるものであり得る。

【0049】

４０６において、クライアントは、再びエンコードされたスライスごとに、圧縮されたビデオフレームをデコードし、現時点で表示準備ができているデコードされたスライスＡ（ハッシュマークなしで示されている）を生成する。一実施形態では、デコードプロセス４０６は、受信プロセス４０５が、対応するビデオフレームに対して完全に完了する前に開始する。さらに、デコード４０６の開始及び／または終了は、クライアントＶＳＹＮＣ信号３１２とアライメントされてもよく、またはされなくてもよい。４０７において、クライアントは、デコードされたレンダリングされたビデオフレームをクライアントにおいてディスプレイに表示する。つまり、デコードされたビデオフレームは、例えば、スキャンラインごとにディスプレイデバイスにストリームアウトされるディスプレイバッファに配置される。
一実施形態では、表示プロセス４０７（すなわち、ディスプレイデバイスへのストリーミングアウト）は、デコードプロセス４０６が、対応するビデオフレームに対して完全に完了した後、すなわち、デコードされたビデオフレームが、ディスプレイバッファに完全に常駐した後に開始する。
別の実施形態では、表示プロセス４０７は、デコードプロセス４０６が対応するビデオフレームに対して完全に完了する前に開始する。つまり、ディスプレイデバイスへのストリームアウトは、デコードされたフレームバッファの一部分のみがディスプレイバッファに常駐する時点で、ディスプレイバッファのアドレスで開始する。ディスプレイバッファは、次いで、表示に間に合うように、対応するビデオフレームの残りの部分で更新または充填され、ディスプレイバッファの更新は、それらの部分がディスプレイにストリームアウトする前に実行されるようになっている。さらに、表示４０７の開始及び／または終了は、クライアントＶＳＹＮＣ信号３１２とアライメントされる。

【0050】

一実施形態では、サーバ２６０とクライアント２１０との間の一方向レイテンシ４１６は、スキャンアウト４０２が開始されたときと、表示４０７が開始されるときとの間の経過時間として定義され得る。本開示の実施形態は、サーバとクライアントとの間のＶＳＹＮＣ信号をアライメント（例えば、周波数を同期させ、オフセットを調整する）させ、サーバとクライアントとの間の一方向レイテンシを低減し、サーバとクライアントとの間の一方向レイテンシの変動性を低減することができる。
例えば、本開示の実施形態は、サーバＶＳＹＮＣ信号３１１とクライアントＶＳＹＮＣ信号３１２との間のオフセット４３０に対する最適な調整を計算することができ、それにより、エンコード４０３及び伝送４０４などのサーバ処理に必要なほぼ最悪の場合の時間が発生した場合であっても、サーバ２６０とクライアント２１０との間のほぼ最悪の場合のネットワークレイテンシが発生した場合であっても、及び受信４０５及びデコード４０６などのほぼ最悪の場合のクライアント処理が発生した場合であっても、デコードされレンダリングされたビデオフレームは、表示プロセス４０７に間に合うように利用可能である。つまり、サーバＶＳＹＮＣとクライアントＶＳＹＮＣとの間の絶対オフセットを決定する必要はなく、デコードされレンダリングされたビデオフレームが表示プロセスに間に合うようにオフセットを調整するだけで十分である。

【0051】

特に、サーバＶＳＹＮＣ信号３１１及びクライアントＶＳＹＮＣ信号３１２の周波数は、同期によって調整され得る。同期は、サーバＶＳＹＮＣ信号３１１またはクライアントＶＳＹＮＣ信号３１２を調節することによって実現される。例示を目的として、調節は、サーバＶＳＹＮＣ信号３１１に関連して説明されているが、調節は、代わりにクライアントＶＳＹＮＣ信号３１２で実行され得ることが理解される。例えば、図４に示すように、サーバフレーム期間４１０（例えば、サーバＶＳＹＮＣ信号３１１の２回の発生である３１１ｃと３１１ｄとの間の時間）は、クライアントフレーム期間４１５（例えば、クライアントＶＳＹＮＣ信号３１２の２回の発生である３１２ａと３１２ｂとの間の時間）と実質的に等しく、このことは、サーバＶＳＹＮＣ信号３１１とクライアントのＶＳＹＮＣ信号３１２の周波数も実質的に等しいことを示している。

【0052】

サーバ及びクライアントのＶＳＹＮＣ信号の周波数の同期を維持するために、サーバＶＳＹＮＣ信号３１１のタイミングが操作され得る。例えば、サーバＶＳＹＮＣ信号３１１の垂直帰線区間（ＶＢＩ）は、例えば、サーバＶＳＹＮＣ信号３１１とクライアントＶＳＹＮＣ信号３１２との間のドリフトを確認するために、ある期間にわたって増加または減少され得る。ＶＢＩにおける垂直帰線（ＶＢＬＡＮＫ）の操作は、サーバＶＳＹＮＣ信号３１１の１つ以上のフレーム期間に対するＶＢＬＡＮＫに使用されるスキャンラインの数を調整することを提供する。ＶＢＬＡＮＫのスキャンラインの数が下落すると、サーバＶＳＹＮＣ信号３１１の２つの発生間の対応するフレーム期間（例えば、時間間隔）を短縮する。反対に、ＶＢＬＡＮＫのスキャンラインの数が増加すると、ＶＳＹＮＣ信号３１１の２つの発生の間の対応するフレーム期間（例えば、時間間隔）を延長する。そのようにして、サーバＶＳＹＮＣ信号３１１の周波数は、クライアントとサーバのＶＳＹＮＣ信号３１１と３１２との間の周波数が実質的に同じ周波数になるように調整される。また、サーバとクライアントのＶＳＹＮＣ信号間のオフセットは、ＶＢＩを元の値に戻す前に、ＶＢＩを短時間にわたり増減することで調整され得る。
一実施形態では、サーバＶＢＩが調整される。別の実施形態では、クライアントＶＢＩが調整される。さらに別の実施形態では、２つのデバイス（サーバ及びクライアント）の代わりに、複数の接続されたデバイスがあり、それらのそれぞれは、調整された対応するＶＢＩを有し得る。一実施形態では、複数の接続されたデバイスの各々は、（例えば、サーバデバイスを伴わない）独立したピアデバイスであり得る。別の実施形態では、複数のデバイスは、１つ以上のサーバ／クライアントアーキテクチャ、マルチテナントサーバ／クライアント（複数可）アーキテクチャ、またはそれらのいくつかの組み合わせに配置された、１つ以上のサーバデバイス及び／または１つ以上のクライアントデバイスを含み得る。

【0053】

他の形態として、サーバのピクセルクロック（例えば、サーバのノースブリッジ／サウスブリッジコアロジックチップセットのサウスブリッジに配置されているか、またはディスクリートＧＰＵの場合は、独自のハードウェアを使用してそれ自体でピクセルクロックを生成する）は、一実施形態では、ある期間にわたってサーバＶＳＹＮＣ信号３１１の周波数の粗い調節及び／または微細な調節を実行するように操作されることができ、サーバＶＳＹＮＣ信号３１１とクライアントのＶＳＹＮＣ信号３１２との間の周波数の同期をアライメント状態に戻す。
具体的には、サーバのサウスブリッジのピクセルクロックがオーバークロックまたはアンダークロックされ、サーバのＶＳＹＮＣ信号３１１の全体的な周波数を調整することができる。そのようにして、サーバＶＳＹＮＣ信号３１１の周波数は、クライアントとサーバのＶＳＹＮＣ信号３１１と３１２との間の周波数が実質的に同じ周波数になるように調整される。サーバとクライアントのＶＳＹＮＣ間のオフセットは、ピクセルクロックを元の値に戻す前に、クライアントサーバのピクセルクロックを短時間で増減することで調整されることができる。一実施形態では、サーバピクセルクロックが調整される。
別の実施形態では、クライアントピクセルクロックが調整される。さらに別の実施形態では、２つのデバイス（サーバ及びクライアント）の代わりに、複数の接続されたデバイスがあり、それらの各々は、調整されている対応するピクセルクロックを有し得る。一実施形態では、複数の接続されたデバイスの各々は、（例えば、サーバデバイスを伴わない）独立したピアデバイスであり得る。別の実施形態では、複数の接続されたデバイスは、１つ以上のサーバ／クライアントアーキテクチャ、マルチテナントサーバ／クライアント（複数可）アーキテクチャ、またはそれらのいくつかの組み合わせに配置された１つ以上のサーバデバイス及び１つ以上のクライアントデバイスを含み得る。

【0054】

一実施形態では、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシをさらに短縮するために高性能コーデック（例えば、エンコーダ及び／またはデコーダ）が使用され得る。圧縮メディアのストリーミングを伴う従来のストリーミングシステム（ストリーミング映画、テレビ番組、ビデオなど）では、エンドターゲット（例えば、クライアント）でストリーミングメディアを解凍するときに、解凍されたビデオのかなりの量をクライアントにおいてバッファリングして、エンコード操作で（例えばより長いエンコード時間）、伝送品質に侵入するジッター、デコード操作（例えば、より長いデコード時間）の変動に対処することが可能である。このように、従来のストリーミングシステムでは、デコードされたコンテンツがレイテンシ変動性に対処することから、平均的なデコード能力とメトリクス（例えば、平均的なデコードリソース）に依存することが可能であり、ビデオフレームが所望の速度で表示されること（例えば、６０Ｈｚで４Ｋメディアをサポートするか、クライアントＶＳＹＮＣ信号が生じるたびにビデオフレームを表示する）ができるようになっている。

【0055】

しかしながら、クラウドゲーミング環境ではバッファリングは非常に制限されており（例えば、ゼロバッファリングへの移行）、リアルタイムゲームが実現されることができるようになっている。その結果、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシに導入された変動性は、ダウンストリーム操作に悪影響を与え得る。例えば、複雑なフレームのエンコードやデコードに時間がかかると、（単一のフレームであっても）それに応じて一方向レイテンシが長くなり、最終的にユーザへの応答時間が長くなり、ユーザのリアルタイムエクスペリエンスに悪影響を及ぼす。

【0056】

一実施形態では、クラウドゲーミングの場合、ストリーミングビデオアプリケーションの必要性と比較した場合に不必要であると思われる、より強力なデコードリソース及びエンコードリソースを供給することが有益である。さらに、以下でさらに詳しく説明するように、エンコーダリソースは、長いか、または最も長い処理を必要とするフレームを処理するための時間に対して最適化される必要がある。つまり、エンコーダが、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するように調節されることができる実施形態では、エンコーダの調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたＩフレームの数、シーン変化の数、及び／または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ（ＱＰ）値を含み得、高性能エンコーダ及びデコーダが、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減することを補助する。

【0057】

図２Ａ～図２Ｄの様々なクライアントデバイス２１０及び／またはクラウドゲーミングネットワーク２９０（例えば、ゲームサーバ２６０内）の詳細な説明と共に、図５のフロー図５００は、本開示の一実施形態による、クラウドゲーミングの方法を示し、ビデオフレームのエンコードは、ネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダパラメータの調節を含んでいる。クラウドゲーミングサーバは、ネットワークを介して１つ以上のクライアントデバイスにコンテンツをストリーミングするように構成されている。このプロセスは、よりスムーズなフレームレートと、より信頼性の高いレイテンシをもたらし、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが低減され、より一貫性があるようにされ、それによって、ビデオのクライアント表示のスムーズさを改善する。

【0058】

５１０では、クラウドゲーミングサーバでビデオゲームを実行するときに、複数のビデオフレームが生成される。一般に、クラウドゲーミングサーバは、複数のゲーム用にレンダリングされたビデオフレームを生成する。例えば、ビデオゲームのゲームロジックは、ゲームエンジンまたはゲームタイトル処理エンジンに基づいて構築されている。ゲームエンジンは、ビデオゲームのゲーム環境を構築するためにゲームロジックによって使用され得るコア機能を含んでいる。例えば、ゲームエンジンのいくつかの機能は、ゲーム環境内のオブジェクトに対する物理的な力と衝突をシミュレートするための物理エンジン、２Ｄまたは３Ｄグラフィックス用のレンダリングエンジン、衝突検出、サウンド、アニメーション、人工知能、ネットワーキング、ストリーミング、等を含み得る。そのようにして、ゲームロジックは、ゲームエンジンによって提供されるコア機能を最初から構築する必要はない。

【0059】

ゲームエンジンと組み合わせたゲームロジックは、ＣＰＵ及びＧＰＵによって実行され、ＣＰＵ及びＧＰＵは、加速処理装置（ＡＰＵ）内で構成できる。つまり、共有メモリと共にＣＰＵ及びＧＰＵは、ゲーム用にレンダリングされたビデオフレームを生成するためのレンダリングパイプラインとして構成され得、レンダリングパイプラインが、目標化、及び／または仮想化された表示の各ピクセルに対して対応する色情報を含む、ゲーム用にレンダリングされた画像を表示に適したビデオまたは画像フレームとして出力するようになっている。
特に、ＣＰＵは、ビデオフレームに対して１つ以上のドローコールを生成するように構成され得、各ドローコールは、ＧＰＵパイプラインのＧＰＵによって実行される対応するコマンドバッファに格納されたコマンドを含んでいる。一般に、グラフィックスパイプラインは、シーン内のオブジェクトの頂点に対してシェーダ操作を実行して、表示のピクセルのテクスチャ値を生成することができる。特に、グラフィックスパイプラインは、入力ジオメトリ（例えば、ゲーミング環境のオブジェクトの頂点）を受信し、頂点シェーダは、オブジェクトを構成するプリミティブまたはポリゴンを構築する。頂点シェーダプログラムは、プリミティブに対してライティング、シェーディング、シャドウイング、及びその他の操作を実行することができる。
深度バッファリングまたはＺバッファリングは、対応する視点からレンダリングされたときに、どのオブジェクトが見えるかを判定するために実行される。ラスタライズは、３Ｄゲーム環境内のオブジェクトを視点によって定義された２Ｄ平面に投影するために実行される。ピクセルサイズのフラグメントがオブジェクトに対して生成され、１つ以上のフラグメントが、画像のピクセルの色に寄与することができる。フラグメントは、対応するビデオの各ピクセルの組み合わせられた色を決定するためにマージ及び／またはブレンドされることができ、フレームバッファ内に格納されることができる。後続のビデオフレームは、同様に構成されたコマンドバッファを使用して表示用に生成され、及び／またはレンダリングされ、複数のビデオフレームが、ＧＰＵパイプラインから出力されている。

【0060】

５２０では、本方法は、エンコーダビットレートで複数のビデオフレームをエンコードすることを含む。特に、複数のビデオフレームは、アプリケーション層で動作するストリーマを使用してクライアントにストリーミングする前に、圧縮されるエンコーダにスキャンされる。一実施形態では、ゲーム用にレンダリングされたビデオフレームの各々は、追加のユーザインターフェース機能で対応する改変されたビデオフレームに合成され、かつブレンドされ、次いでエンコーダにスキャンされることができ、このエンコーダは、改変されたビデオフレームを圧縮してクライアントにストリーミングする。
簡潔さと明確さのために、図５に開示されているエンコーダパラメータを調節する方法は、複数のビデオフレームをエンコードすることに関して説明されているが、改変されたビデオフレームをエンコードすることをサポートすると理解されている。エンコーダは、記述されたフォーマットに基づいて複数のビデオフレームを圧縮するように構成されている。例えば、クラウドゲーミングサーバからクライアントにメディアコンテンツをストリーミングするときに、モーションピクチャエキスパートグループ（ＭＰＥＧ）またはＨ．２６４標準が実装され得る。特に、エンコーダは、ビデオフレームによって、またはビデオフレームのエンコーダスライスによって圧縮を実行することができ、前述のように、各ビデオフレームは、１つ以上のエンコードされたスライスとして圧縮されることができる。一般に、メディアをストリーミングするとき、ビデオフレームは、Ｉフレーム（イントラフレーム）またはＰフレーム（予測フレーム）として圧縮され、それらの各々が、エンコードされたスライスに分割されることができる。

【0061】

５３０では、クライアントの最大受信帯域幅が測定される。一実施形態では、クライアントが経験する最大帯域幅は、クライアントからのフィードバックメカニズムによって判定されている。図６は、本開示の一実施形態による、クラウドゲーミングサーバのストリーマによるクライアント２１０の帯域幅の測定を示しており、ストリーマ６２０は、エンコーダ６１０を監視及び調節するように構成されており、圧縮されたビデオフレームが、クライアントの測定された帯域幅の範囲内の速度で伝送され得るようになっている。
図示されるように、圧縮されたビデオフレーム、エンコードされたスライス、及び／またはパケットは、エンコーダ６１０からバッファ６３０（例えば、先入れ先出し－ＦＩＦＯ）へ配信される。エンコーダは、エンコーダ充填速度６１５で圧縮されたビデオフレームを配信する。例えば、バッファは、エンコーダが、圧縮されたビデオフレーム、エンコードされたスライス６５０、及び／またはエンコードされたスライスのパケット６５５を生成することができるのと同じ速さで充填され得る。さらに、圧縮されたビデオフレームは、ネットワーク２５０を介してクライアント２１０に配信するために、バッファ排出速度６３５でバッファから排出される。
一実施形態では、バッファ排出速度６３５は、クライアントの測定された最大受信帯域幅に動的に調節される。例えば、バッファ排出速度６３５は、クライアントの測定された最大受信帯域幅にほぼ等しくなるように調整され得る。一実施形態では、パケットのエンコードは、それらが伝送されるのと同じ速度で実行され、両方の操作は、クライアントが利用できる最大の利用可能な帯域幅に動的に調節されるようになっている。

【0062】

特に、アプリケーション層で動作するストリーマ６２０は、帯域幅テスター６２５を使用するなどして、クライアント２１０の最大帯域幅を測定する。アプリケーション層は、インターネットを介してネットワークデバイスを相互接続するために使用されるプロトコルのユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）スイートで使用される。例えば、アプリケーション層は、ＩＰ通信ネットワークを介したデバイス間の通信に使用される通信プロトコルとインターフェースメソッドを規定する。テスト中に、ストリーマ６２０は、追加のバッファリングされたパケット６４０（例えば、前方誤り訂正（ＦＥＣ）パケット）を提供し、バッファ６３０が、テストされた最大帯域幅などの事前規定されたビットレートからパケットをストリーミングできるようになっている。
一実施形態では、クライアントは、フィードバック６９０として、ビデオフレームのある範囲などの、増分シーケンス識別子（ＩＤ）の範囲にわたって受信したパケットの数をストリーマ６２０に返す。例えば、クライアントは、シーケンスＩＤ１００～２５０（例えば、１５０ビデオフレーム）で受信した１５０ビデオフレームのうち１４５のようなものを報告することができる。このように、サーバ２６０におけるストリーマ６２０は、パケット損失を計算することができ、ストリーマ６２０は、そのパケットのシーケンスの間に送信された（例えば、テストされた）帯域幅の量を知っているので、ストリーマ６２０は、クライアントの最大帯域幅が特定の時点で何であるか動的に判定することができる。
クライアントの測定された最大帯域幅は、制御情報６２７としてストリーマ６２０からバッファ６３０に配信され得、バッファ６３０は、クライアントの最大帯域幅にほぼ等しい速度でパケットを動的に伝送することができるようになっている。このように、圧縮されたビデオフレーム、エンコードされたスライス、及び／またはパケットの伝送速度は、現在測定されているクライアントの最大帯域幅に応じて動的に調整されることができる。

【0063】

５４０では、エンコーディングプロセスはストリーマによって監視されている。つまり、複数のビデオフレームのエンコードが監視される。一実施形態では、監視は、クライアント２１０で実行され、フィードバック及び／または調節制御信号がエンコーダに戻されるように提供されている。別の実施形態では、監視は、クラウドゲーミングサーブ２６０において、ストリーマ６２０などによって実行されている。例えば、ビデオフレームのエンコードの監視は、ストリーマ６２０の監視及び調節ユニット６２９によって実行され得る。様々なエンコーディング特性及び／または操作が、追跡及び／または監視されることができる。
例えば、一実施形態では、複数のビデオフレーム内のＩフレームの発生率が、追跡及び／または監視されることができる。さらに、一実施形態では、複数のビデオフレーム内のシーン変化の発生率が、追跡及び／または監視されることができる。また、一実施形態では、目標フレームサイズを超えるビデオフレームの数が追跡及び／または監視されることができる。また、一実施形態では、１つ以上のビデオフレームをエンコードするために使用されるエンコーダビットレートが、追跡及び／または監視されることができる。

【0064】

５５０では、エンコーダのパラメータは、ビデオフレームのエンコーディングの監視に基づいて、動的に調節される。つまり、ビデオフレームのエンコーディングの監視は、エンコーダで受信される現在及び将来のビデオフレームを圧縮するときに、エンコーダがどのように動作するかに影響を及ぼす。特に、監視及び調整ユニット６２９は、ビデオフレームのエンコードの監視、及び監視された情報に対して実行される分析に応答して、どのエンコーダパラメータを調節すべきかを判定するように構成されている。制御信号６２１は、エンコーダを構成するために使用される監視及び調整ユニット６２９からエンコーダ６１０に返信される。調節のためのエンコーダパラメータには、量子化パラメータ（ＱＰ）（例えば、最小ＱＰ、最大ＱＰ）または品質パラメータ、目標フレームサイズ、最大フレームサイズ、などが含まれる。

【0065】

調節は、ネットワークの伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識して実行される。一実施形態では、ビデオ再生のスムーズさは、低レイテンシまたは画像品質よりも優先される。例えば、１つ以上のビデオフレームのエンコードのスキップは、無効になっている。具体的には、画像解像度または画像品質（６０Ｈｚなど）とレイテンシのバランスは、様々なエンコーダパラメータを使用して調節される。特に、クラウドゲーミングサーバ及びクライアントにおけるＶＳＹＮＣ信号は、同期及びオフセットされることができることから、クラウドゲーミングサーバとクライアント間の一方向レイテンシは、低減されることができ、それによって、低レイテンシを促進するためにビデオフレームをスキップする必要性が減少する。ＶＳＹＮＣ信号の同期とオフセットはまた、クラウドゲーミングサーバにおける重複操作（スキャンアウト、エンコード、及び伝送）、クライアントにおける重複操作（受信、デコード、レンダリング、表示）、及び／またはクラウドゲーミングサーバとクライアントにおける重複操作も提供し、これらはすべて、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイムでの生成と表示、及びクライアントにおける一貫したビデオ再生を促進する。

【0066】

一実施形態では、エンコーダビットレートは、クライアント帯域幅に対する需要を予測するために、次に続くフレーム及びそれらの複雑性（例えば、予測されるシーン変化）を考慮して監視され、ここでエンコーダビットレートは、予想される需要に従って調整されることができる。例えば、ビデオ再生のスムーズさを優先するとき、エンコーダ監視及び調節ユニット６２９は、使用されるエンコーダビットレートが、測定されている最大受信帯域幅を超えていると判定するように構成され得る。それに応じて、エンコーダビットレートは低減されることができ、フレームサイジングもまた低減されることができるようになっている。
スムーズさを優先する場合、最大受信帯域幅よりも低いエンコーダビットレート（例えば、１５メガビット／秒の最大受信帯域幅に対して１０メガビット／秒のエンコーダビットレート）を使用することが望ましい。そのようにして、エンコードされたフレームが最大フレームサイズを超えてスパイクした場合でも、エンコードされたフレームは、依然として６０Ｈｚ（ヘルツ）以内で送信されることができる。特に、エンコーダビットレートは、フレームサイズに変換され得る。ビデオゲームの所定のビットレート及び目標速度（例えば、毎秒６０フレーム）は、エンコードされたビデオフレームの平均サイズに変換される。例えば、１５メガビット／秒のエンコーダビットレート、及び６０フレーム／秒の所定の目標速度では、６０個のエンコードされたフレームが、１５メガビットを共有し、各エンコードされたフレームが、約２５０ｋ個のエンコードされたビットを有するようになっている。
このように、エンコーダビットレートを制御することはまた、エンコードされたビデオフレームのフレームサイズも制御し、その結果、エンコーダビットレートを増加すると、エンコード用のビットが多くなり（精度が高くなる）、また、エンコーダビットレートを低減すると、エンコード用のビットが少なくなる（精度が低くなる）。同様に、ビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、測定されている最大受信帯域幅内にあるとき、エンコーダビットレートは増加されることができ、フレームサイズもまた、増加されることができるようになっている。

【0067】

一実施形態では、ビデオ再生のスムーズさを優先する場合、エンコーダ監視及び調節ユニット６２９は、複数のビデオフレームからビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、測定されている最大受信帯域幅を超えているかを判定するように構成され得る。例えば、エンコーダビットレートは、１５メガビット／秒（Ｍｂｐｓ）であると検出されることができ、一方で、最大受信帯域幅は、現在１０Ｍｂｐｓであることができる。このようにして、エンコーダは、一方向レイテンシを増加させることなく、クライアントに送信できるよりも多くのビットをプッシュアウトする。
前述したように、スムーズさを優先する場合、最大受信帯域幅よりも低いエンコーダビットレートを使用することが望ましくなり得る。上の例では、上で紹介した１０メガビット／秒の最大受信帯域幅に対して１０メガビット／秒以下に設定したエンコーダビットレートを有することが許容可能となり得る。そのようにして、エンコードされたフレームが最大フレームサイズの上にスパイクする場合、エンコードされたフレームは、依然として６０Ｈｚ以内で送信されることができる。それに応じて、ＱＰ値は、エンコーダビットレートの低減をしても、低減しなくても調節されることができ、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。
つまり、ＱＰは、実行される量子化の量を制御する（例えば、ビデオフレーム内の値の可変範囲を単一量子値に圧縮する）。Ｈ．２６４では、ＱＰの範囲は「０」から「５１」である。例えば、「０」のＱＰ値は、量子化がより少なく、圧縮がより少なく、精度がより高く、品質がより高いことを意味する。例えば、「５１」のＱＰ値は、量子化がより少なく、圧縮がより少なく、精度がより高く、品質がより高いことを意味する。具体的には、ＱＰ値が増加されることができ、ビデオフレームのエンコードが、より低い精度で実行されるようになっている。

【0068】

一実施形態では、ビデオ再生のスムーズさを優先するとき、監視及び調節ユニット６２９によるエンコーダ監視は、複数のビデオフレームからのビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、最大受信帯域幅内にあることを判定するように構成され得る。以前に紹介したように、スムーズさを優先するとき、最大受信帯域幅よりも低いエンコーダビットレートを使用することが望ましくなり得る。このように、ビデオフレームのグループを送信するときに利用可能な超過帯域幅がある。超過帯域幅が判定されることができる。それに応じて、ＱＰ値は調節されることができ、ここで、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、ＱＰ値は、超過帯域幅に基づいて低減されることができ、エンコードがより正確に実行されるようになっている。

【0069】

別の実施形態では、個々のビデオゲームの特性は、Ｉフレーム処理及びＱＰ設定を決定するときに、特にビデオ再生のスムーズさを優先するときに考慮される。例えば、ビデオゲームの「シーン変化」が頻繁に行われない場合（例えば、カメラカットのみ）、Ｉフレームをより大きくすることが望ましくなり得る（ＱＰがより低いか、エンコーダビットレートがより高い）。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、シーン変化を有していると識別されたビデオフレームの数は、シーン変化の閾値数よりも少ないと判定される。つまり、ストリーミングシステムは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など）のシーン変化の数を処理できる。それに応じて、ＱＰ値は調節されることができ、ここで、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、ＱＰ値は、エンコードがより高い精度で実行されるように、低減されることができる。

【0070】

一方で、ビデオゲームでゲームプレイ中に頻繁に「シーン変化」が発生する場合は、Ｉフレームサイズを小さく保つことが望ましくなり得る（例えば、ＱＰをより高くするか、エンコーダビットレートをより低くする）。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、シーン変化を有していると識別されたビデオフレームの数は、シーン変化の閾値数を満たすか、または超えると判定される。つまり、ビデオゲームは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など）に対して多過ぎるシーン変化を生成している。それに応じて、ＱＰ値は調節されることができ、ここで、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、ＱＰ値は、エンコードがより低い精度で実行されるように、増加されることができる。

【0071】

別の実施形態では、Ｉフレーム処理及びＱＰ設定を決定するとき、特にビデオ再生のスムーズさを優先するときに、エンコードパターンが考慮され得る。例えば、エンコーダのＩフレームの生成頻度が低い場合は、Ｉフレームを大きくすることが望ましくなり得る（ＱＰが低いか、エンコーダビットレートがより高い）。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、Ｉフレームとして圧縮されるビデオフレームの数は、Ｉフレームの閾値数内にあるか、またはそれより少ない。つまり、ストリーミングシステムは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等）のＩフレームの数を処理できる。それに応じて、ＱＰ値は調節されることができ、ここで、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、ＱＰ値は、エンコードがより高い精度で実行されるように、低減されることができる。

【0072】

エンコーダが頻繁にＩフレームを生成する場合は、Ｉフレームサイズを小さく保つことが望ましくなり得る（例えば、ＱＰを高くするか、エンコーダビットレートをより低くする）。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、Ｉフレームとして圧縮されるビデオフレームの数は、Ｉフレームの閾値数内にあるか、またはそれを超える。つまり、ビデオゲームは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など）に対して多過ぎるＩフレームを生成している。それに応じて、ＱＰ値は調節されることができ、ここで、ＱＰは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、ＱＰ値は、エンコードがより低い精度で実行されるように、増加されることができる。

【0073】

別の実施形態では、エンコーダを回すとき、特にビデオ再生のスムーズさを優先するとき、エンコードパターンが考慮され得る。例えば、エンコーダが頻繁に目標フレームサイズを下回る場合は、目標フレームサイズをより大きくすることが望ましくなり得る。つまり、圧縮されて伝送速度で送信される複数のビデオフレームからのビデオフレームのグループ内で、ビデオフレームの数が閾値よりも低くなると判定される。ビデオフレームの数の各々は、目標フレームサイズ内にある（すなわち、目標フレームサイズと等しいか、小さい）。それに応じて、目標フレームサイズと最大フレームサイズのうちの少なくとも１つが増加する。

【0074】

一方で、エンコーダが頻繁に目標フレームサイズを超える場合は、目標フレームサイズを小さくすることが望ましくなり得る。つまり、圧縮されて伝送速度で送信される複数のビデオフレームからのビデオフレームのグループ内で、ビデオフレームの数が閾値を満たすか、または超えるかが、判定される。ビデオフレームの数の各々は、目標フレームサイズを超えている。それに応じて、目標フレームサイズ及び最大フレームサイズのうちの少なくとも１つが低減される。

【0075】

図７Ａは、本開示の一実施形態による、クライアントにおける品質及びバッファ利用を最適化するためのエンコーダの量子化パラメータ（ＱＰ）の設定を示す図である。グラフ７２０Ａは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ（バイト単位）を示している。目標フレームサイズと最大フレームサイズは静的である。特に、ライン７１１は最大フレームサイズを示し、ライン７１２は目標フレームサイズを示しており、最大フレームサイズは目標フレームサイズよりも大きくなっている。グラフ７２０Ａに示されるように、ライン７１２の目標フレームサイズを超える圧縮されたビデオフレームを含む複数のピークが存在する。目標フレームサイズを超えるビデオフレームは、クラウドゲーミングサーバからのエンコード及び／または送信に対して複数のフレーム期間を要し得ることから、再生ジッターをもたらすリスク（例えば、一方向レイテンシの増加）がある。

【0076】

グラフ７００Ｂは、クライアントにおけるエンコードの品質とバッファ利用を最適化するための、目標フレームサイズ、最大フレームサイズ、ＱＰ範囲（最小ＱＰや最大ＱＰなど）に基づいてＱＰが設定された後のエンコーダ応答を示す。例えば、ＱＰは、前述のように、エンコーダビットレートのエンコーダ監視、シーン変化の頻度、及びＩフレーム生成の頻度に基づいて調整及び／または調節され得る。グラフ７００Ｂは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ（バイト単位）を示している。
ライン７１２の目標フレームサイズ及びライン７１１の最大フレームサイズは、グラフ７００Ａにあるものと同じ位置のままである。ＱＰ調節及び／または調整の後、グラフ７００Ａと比較すると、ライン７１２の目標フレームサイズを超える圧縮されたビデオフレームを含むピーク数が減少する。つまり、ＱＰは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等）に対してビデオフレームのエンコードを最適化する（すなわち、目標フレームサイズ内に収まる）ために調節されている。

【0077】

図７Ｂは、本開示の一実施形態による、クライアントによってサポートされる真の目標フレームサイズを超えるＩフレームの発生を低減するための、目標フレームサイズ、最大フレームサイズ、及び／またはＱＰ（例えば、最小ＱＰ及び／または最大ＱＰ）エンコーダ設定の調節を示す図である。例えば、ＱＰは、前述のように、エンコーダビットレートのエンコーダ監視、シーン変化の頻度、及びＩフレーム生成の頻度に基づいて調整及び／または調節され得る。

【0078】

グラフ７２０Ａは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ（バイト単位）を示している。例示のために、図７Ｂの７２０Ａ及び図７Ａのグラフ７００Ａは、類似のエンコーダ状態を反映することができ、エンコーダ調節に使用される。グラフ７２０Ａでは、目標フレームサイズと最大フレームサイズは静的である。特に、ライン７１１は最大フレームサイズを示し、ライン７１２は目標フレームサイズを示しており、最大フレームサイズは目標フレームサイズよりも大きくなっている。
グラフ７２０Ａに示されるように、ライン７１２の目標フレームサイズを超える圧縮されたビデオフレームを含む複数のピークが存在する。目標フレームサイズを超えるビデオフレームは、クラウドゲーミングサーバからのエンコード及び／または送信に対して複数のフレーム期間を要し得ることから、再生ジッターをもたらすリスク（例えば、一方向レイテンシの増加）がある。例えば、ライン７１１で最大フレームサイズに達するピークは、クライアントに送信されるまでに１６ミリ秒以上かかるＩフレームであり得、このことが、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシを増加させることによる再生ジッターを生じさせる。

【0079】

グラフ７２０Ｂは、クライアントによってサポートされる真の目標フレームサイズを超えるＩフレームの発生を低減するために、目標フレームサイズ及び／または最大フレームサイズのうちの少なくとも１つが調節された後のエンコーダ応答を示している。真の目標フレームサイズは、前述のように、測定されるクライアント帯域幅、及び／またはエンコーダビットレート、シーン変化の頻度、及びＩフレーム生成の頻度の監視を含むエンコーダ監視に基づいて調整され得る。

【0080】

グラフ７２０Ｂは、水平方向に示されるように、生成された各フレームに対する垂直方向のフレームサイズ（バイト単位）を示している。グラフ７２０Ａと比較すると、ライン７１２’の目標フレームサイズとライン７１１’の最大フレームサイズの値が低くなっている。例えば、ライン７１２’の目標フレームサイズは、ライン７１２から値が小さくなっており、ライン７１１’の最大フレームサイズは、ライン７１１から値が小さくなっている。
目標フレームサイズ及び／または最大フレームサイズを調節した後、目標フレームサイズ７１２’を超えて圧縮されたビデオフレームのピークの最大サイズは、より良い送信のために縮小されている。さらに、グラフ７００Ａと比較した場合、目標フレームサイズ７１２’を超える圧縮されたビデオフレームを含むピークの数もまた減少した。例えば、グラフ７２０Ｂに示されているピークは１つだけである。つまり、目標フレームサイズ及び／または最大フレームサイズは、現在の状態（例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等）に対してビデオフレームのエンコーディングを最適化する（すなわち、目標フレームサイズ内に収まる）ために調節されている。

【0081】

図２Ａ～図２Ｄの様々なクライアントデバイス２１０及び／またはクラウドゲーミングネットワーク２９０（例えば、ゲームサーバ２６０内）の詳細な説明とともに、図８のフロー図８００は、本開示の一実施形態による、クラウドゲーミングの方法を示しており、ビデオフレームのエンコードは、エンコードが長い場合、または生成されるビデオフレームが大きい場合（Ｉフレームをエンコードする場合など）に、ビデオフレームをいつスキップするか、またはビデオフレームのエンコード及び送信をいつ遅らせるか、を決定することを含む。
特に、ビデオフレームをスキップする決定は、ネットワーク伝送速度と信頼性、及び全体的なレイテンシ目標を考慮して行われる。このプロセスは、よりスムーズなフレームレートと、より信頼性の高いレイテンシをもたらし、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが低減され、より一貫性があるようにされ、それによって、ビデオのクライアント表示のスムーズさを改善する。

【0082】

８１０では、ストリーミングモードで動作するクラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームが生成されている。一般に、クラウドゲーミングサーバは、複数のゲーム用にレンダリングされたビデオフレームを生成する。例えば、ゲーム用にレンダリングされたビデオフレームの生成は、図５の５１０で説明されており、図８のビデオフレームの生成に適用可能である。
例えば、ビデオゲームのゲームロジックは、ゲームエンジンまたはゲームタイトル処理エンジンに基づいて構築されている。ゲームエンジンと組み合わせたゲームロジックは、ＣＰＵ及びＧＰＵによって実行され、共有メモリとともにＣＰＵ及びＧＰＵは、ゲーム用にレンダリングされたビデオフレームを生成するためのレンダリングパイプラインとして構成され得、レンダリングパイプラインが、ゲーム用にレンダリングされた画像を目標の、及び／または仮想化された表示のピクセルの各々に対応する色情報を含む、表示に適したビデオまたは画像フレームとして出力するようになっている。

【0083】

８２０において、シーン変化は、ビデオゲームの第１のビデオフレームに対して予測され、シーン変化は、第１のビデオフレームが生成される前に予測されている。一実施形態では、ゲームロジックは、ＣＰＵがビデオゲームを実行している間のシーン変化を認識させることができる。例えば、ゲームロジックまたはアドオンロジックは、コード（例えば、シーン変化ロジック）を含むことができ、これは、ビデオフレームの範囲が少なくとも１つのシーン変化を含むと予測すること、または特定のビデオフレームがシーン変化であると予測することなど、ビデオフレームを生成するときにシーン変化を予測する。
特に、シーン変化予測のために構成されたゲームロジックまたはアドオンロジックは、ビデオゲームの実行中に収集されたゲーム状態データを分析して、次のＸフレーム数（例えば、範囲）内で、または識別されたビデオフレームに対して、など、いつシーン変化があるかを判定し、及び／または事前察知し、及び／または予測する。例えば、シーン変化は、仮想化ゲーム環境で、いつキャラクタが、あるシーンから別のシーンに移動するか、またはビデオゲームにおいて、いつキャラクタがレベルを終了し、別のレベルに移行するか、２つのビデオフレーム（例えば、映画的シーケンスでのシーンカット、または一連のメニューの後のインタラクティブなゲームプレイの開始）間でいつ移行するか、が予測されることができ、シーン変化は、仮想化ゲーム世界または環境の大きくて複雑なシーンを含む、ビデオフレームによって表され得る。

【0084】

ゲーム状態データは、その時点でのゲームの状態を定義することができ、ゲームキャラクタ、ゲームオブジェクト、ゲームオブジェクト属性、ゲーム属性、ゲームオブジェクト状態、グラフィックオーバーレイ、プレイヤーのゲームプレイのゲーム世界内のキャラクタの場所、ゲームプレイのシーンまたはゲーム環境、ゲームアプリケーションのレベル、キャラクタの資産（例えば、武器、ツール、爆弾など）、ロードアウト、キャラクタのスキルセット、ゲームレベル、キャラクタ属性、キャラクタの場所、残存ライフ数、利用可能なライフの総数、鎧、トロフィー、時間カウンター値、及びその他の資産情報、等を含むことができる。

【0085】

８３０において、シーン変化ヒントが生成され、シーン変化ヒントがエンコーダに送信され、このヒントは、第１のビデオフレームがシーン変化であることを示す。このように、次のシーン変化の通知が、エンコーダに提供され得、エンコーダは、識別されたビデオフレームを圧縮するときにそのエンコード操作を調整することができる。シーン変化ヒントとして提供される通知は、構成要素間で、またはクラウドゲーミングサーバ２６０の構成要素上で実行されているアプリケーション間で、通信するために使用されるＡＰＩを介して配信され得る。
一実施形態では、ＡＰＩはＧＰＵ ＡＰＩであり得る。例えば、ＡＰＩは、エンコーダと通信するためにシーン変化を検出するように構成されたゲームロジック及び／またはアドオンロジック上で実行されているか、またはそれらによって呼び出され得る。
一実施形態では、シーン変化ヒントは、データ制御パケットを受信するすべての構成要素が、どのタイプの情報がデータ制御パケットに含まれているかを理解することができ、対応するレンダリングされたビデオフレームへの適切な基準を理解することができるようにフォーマットされたデータ制御パケットとして提供され得る。
一実施態様では、ＡＰＩに対して使用される通信プロトコル、データ制御パケットに対するフォーマットは、ビデオゲームのための対応するソフトウェア開発キット（ＳＤＫ）で定義され得る。

【0086】

８４０において、第１のビデオフレームをエンコーダに配信する。前述のように、ゲームで生成されたビデオフレームは、追加のユーザインターフェース機能と合成され得、かつブレンドされ得、エンコーダにスキャンされる変更されたビデオフレームになる。エンコーダは、クラウドゲーミングサーバからクライアントへのメディアコンテンツのストリーミングに使用されるＭＰＥＧまたはＨ．２６４標準など、所望のフォーマットに基づいて、第１のビデオフレームを圧縮するように構成されている。
ストリーミングするとき、シーン変化があるまで、または現在エンコードされているフレームが、キーフレーム（例えば、以前のＩフレーム）を参照できなくなるまで、ビデオフレームはＰフレームとしてエンコードされ、次のビデオフレームが、次いで別のＩフレームとしてエンコードされるようになっている。この場合、第１のビデオフレームは、シーン変化ヒントに基づいてＩフレームとしてエンコードされ、Ｉフレームは、他のいずれのビデオフレーム（例えば、キー画像としてのスタンドアロン）を参照することなくエンコードされ得る。

【0087】

８５０では、クライアントの最大受信帯域幅が測定される。前述のように、クライアントが経験する最大帯域幅は、図５及び図６の操作５３０に示されるように、クライアントからのフィードバックメカニズムの手段によって、判定され得る。特に、クラウドゲーミングサーバのストリーマは、クライアントの帯域幅を測定するように構成されることができる。

【0088】

８６０において、エンコーダは第２のビデオフレームを受信する。つまり、第２のビデオフレームは、シーン変化の後に受信され、第１のビデオフレームが圧縮された後に圧縮される。また、第２のビデオフレーム（または後続のビデオフレーム）をエンコードしないか、または第２のビデオフレーム（または後続のビデオフレーム）のエンコードを遅らせるかのいずれかが、エンコーダによって決定される。この決定は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて行われる。つまり、エンコードをスキップするか、または遅延するかの決定は、クライアントが利用できる帯域幅を考慮する。
一般に、クライアントが経験する現在の帯域幅が十分である場合、クライアントの目標ディスプレイ用に生成及びエンコードされたビデオフレームが、レイテンシヒットを受けた（例えば、シーン変化用に大きなＩフレームを生成）後、早急に低い一方向レイテンシに戻ることができ、第２のビデオフレーム（及び／または後続のビデオフレーム）は、依然として遅延を伴ってエンコードされ得る。
一方、クライアントが経験する現在の帯域幅が十分でない場合、第２のビデオフレーム（及び／または後続のビデオフレーム）は、エンコードプロセス中にスキップされ、クライアントに配信されない場合がある。このように、クライアントへの帯域幅が、クライアントでのディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より少ないスキップされるフレーム（及びより低いレイテンシ）を有することが可能である。

【0089】

一実施形態では、圧縮されたビデオフレームは、特定の時点で、ネットワークを介して利用可能な最大ビットレートまたは帯域幅に基づくレートでサーバからクライアントに送信される。このように、圧縮されたビデオフレームのエンコードされたスライス及び／またはエンコードされたスライスのパケットの伝送速度は、現在測定されている最大帯域幅に従って動的に調整される。ビデオフレームは、ビデオフレームがエンコードされるときに送信され得、サーバＶＳＹＮＣ信号の次の発生を待たずに、またビデオフレーム全体がエンコードされるのを待たずに、エンコードが完了するとすぐに送信が行われるようになっている。

【0090】

さらに、一実施形態では、パケットのエンコードは、それらが送信されるのと同じ速度で実行され、両方の操作が、クライアントが利用できる最大の利用可能帯域幅に動的に調節されるようになっている。また、エンコーダビットレートは、クライアント帯域幅の需要を予測するために、次のフレームとその複雑さ（例えば、予測されるシーン変化）を考慮して監視されることができ、エンコーダビットレートは、予測される需要に従って調整されることができる。さらに、エンコーダビットレートは、クライアントに通信されることができるので、クライアントは、エンコーダビットレートに一致するように、それに応じてデコード速度を調整することができるようになっている。

【0091】

一実施形態では、クライアントへの伝送速度がクライアントディスプレイの目標解像度に対して低いとき、第２のビデオフレームはエンコーダによってスキップされる。つまり、第２のビデオフレームはエンコードされない。特に、圧縮されたビデオフレームのグループに対するクライアントへの伝送速度は、最大受信帯域幅を超えている。例えば、クライアントへの伝送速度は、１５メガバイト／秒（Ｍｂｐｓ）であることができるが、クライアントの測定された受信帯域幅は、現在５～１０Ｍｂｐｓであることができる。このように、すべてのビデオフレームが継続的にクライアントにプッシュされる場合、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが増加する。低遅延を促進するために、２番目以降のビデオフレームはエンコーダによってスキップされることができる。

【0092】

図９Ａは、本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンス９００Ａを示し、エンコーダは、クライアント帯域幅がクライアントのディスプレイの目標解像度に対して低いとき、第１のＩフレーム９０５をエンコードした後に、第２のビデオフレーム９２０のエンコードをドロップする。ビデオフレームのエンコードブロック及び伝送ブロックが、ＶＳＹＮＣ信号９５０に関連して示されている。特に、余分な帯域幅が利用できないとき、エンコードにより時間がかかるＩフレームは、１つ以上のスキップされたフレームが、一方向レイテンシを低く抑えるようにさせ、一方向レイテンシは、クライアントにおいて、ビデオフレームを表示する時間を含み得る。
図示されるように、Ｉフレームの後に１つ以上のビデオフレームをスキップすると、低い一方向レイテンシにすぐに戻ることを可能にする（例えば、１つまたは２つのフレーム期間内）。そうでない場合、ビデオフレームのエンコードをスキップしないことにより、低い一方向レイテンシに戻るまでに数フレーム期間を要することになる。

【0093】

例えば、ビデオフレームのシーケンス９００Ａは、１つのエンコードされたＩフレーム９０５を含み、残りのフレームは、Ｐフレームとしてエンコードされている。説明のために、Ｐフレームとしてのエンコードブロック９０１及びエンコードブロック９０２が、Ｉフレームとしてエンコードされたエンコードブロック９０５の前に、エンコードされている。
その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム（Ｉフレームなど）を参照できなくなるまで、ビデオフレームをＰフレームとして圧縮する。一般的に、Ｉフレームブロックのためのエンコード時間は、Ｐフレームブロックよりも長くかかることがある。例えば、Ｉフレームブロック９０５のエンコード時間は、１フレーム期間を超え得る。場合によっては、ＰフレームとＩフレームとの間のエンコード時間は、特に高出力のエンコーダを使用する場合、一般的に、ほぼ同じになり得る。

【0094】

しかしながら、ＩフレームとＰフレームとの間の送信時間は大きく異なる。図示されているように、様々な送信時間が、対応するエンコードされたビデオフレームに関連して示されている。例えば、エンコードされたＰフレームブロック９０１の伝送ブロック９１１は、低レイテンシで示され、エンコードブロック９０１及び伝送ブロック９１１が、１フレーム期間内に実行され得るようになっている。また、エンコードされたＰフレームブロック９０２の伝送ブロック９１２は、低い一方向レイテンシとともに示され、エンコードブロック９０２及び伝送ブロック９１２もまた、１フレーム期間内に実行され得るようになっている。

【0095】

一方で、エンコードされたＩフレームブロック９０５の伝送ブロック９１５Ａは、より高い一方向レイテンシと共に示され、エンコードブロック９０５及び伝送ブロック９１５Ａは、いくつかのフレーム期間にわたって発生し、それによって、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターを導入するようになっている。一方向レイテンシが少なくなるようにユーザにリアルタイムのエクスペリエンスを提供するために、クライアントにおけるバッファは、ジッターを修正するために使用され得ない。その場合、エンコーダは、Ｉフレームがエンコードされた後に、１つ以上のビデオフレームのエンコードをスキップすることを決定することができる。
例えば、ビデオフレーム９２０は、エンコーダによってドロップされる。その場合、エンコードされたビデオフレームの送信は、５つの後続のビデオフレームが、Ｐフレームとしてエンコードされて、クライアントに送信された後のように、ハイライトされた領域９１０の周りの低い一方向レイテンシの１つに戻る。つまり、Ｉフレームブロック９０５がエンコードされた後にエンコードされた第４または第５のＰフレームもまた、同じフレーム期間内でクライアントに送信され、それによって、クラウドゲーミングサーバとクライアントとの間の低い一方向レイテンシに戻る。

【0096】

一実施形態において、クライアントへの伝送速度が、クライアントディスプレイの目標解像度に対して高い場合、第２のビデオフレームは、遅延後も依然としてエンコーダによって圧縮される（すなわち、Ｉフレームがエンコードされるまで待機する）。特に、圧縮されたビデオフレームのグループのクライアントに対する伝送速度は、最大受信帯域幅の範囲内である。例えば、クライアントへの伝送速度は、１３メガバイト／秒（Ｍｂｐｓ）であり得るが、クライアントの測定された受信帯域幅は、現在１５Ｍｂｐｓであり得る。このように、クライアントにおけるエンコードされたビデオフレームの受信において、遅延が発生しないため、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシの増加はない。

【0097】

さらに、クラウドゲーミングサーバとクライアントにおいてＶＳＹＮＣ信号が同期及びオフセットされることができるため、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシは、低減されることができ、それによって、ネットワークを介した送信中にサーバにおいて、またはクライアントにおいて、ジッターによって生じたレイテンシの変動性を補正する。
また、ＶＳＹＮＣ信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作（スキャンアウト、エンコード、及び送信）、クライアントでの重複操作（受信、デコード、レンダリング、表示）、及び／またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされるレイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。

【0098】

図９Ｂは、エンコーダによって圧縮されているビデオフレームのシーケンス９００Ｂを示しており、エンコーダは、クライアントに利用可能な帯域幅を考慮に入れており、その結果、本開示の一実施形態によれば、帯域幅が、クライアントディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より低いレイテンシを有すると同時に、スキップされたフレームを有さないか、より少なくすることが可能であるようになっている。
特に、シーケンス９００Ｂでは、ビデオフレームはＩフレームとしてエンコードされ、後続のビデオフレームもまた正常にエンコードされ、クライアント帯域幅がクライアントディスプレイの目標解像度に対して中適度であるとき、Ｉフレームのエンコードの遅延後にエンコードされる。中程度の帯域幅の可用性があるため、中適度の量の超過帯域幅が、クラウドゲーミングサーバとクライアント間のレイテンシの変動性（例えば、ジッター）を補正するために利用可能であり、その結果、フレームスキップが回避されることができ、低い一方向レイテンシへの回帰が比較的迅速に（例えば、２つ～４つのフレーム期間内で）達成され得るようになっている。ビデオフレームのエンコードブロック及び伝送ブロックが、ＶＳＹＮＣ信号９５０に関連して示されている。

【0099】

ビデオフレームのシーケンス９００Ｂは、１つのエンコードされたＩフレーム９０５を含み、残りのフレームは、Ｐフレームとしてエンコードされている。例示のために、Ｐフレームとしてのエンコードブロック９０１及びエンコードブロック９０２が、エンコードブロック９０５がＩフレームとしてエンコードされる前に、エンコードされている。その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム（Ｉフレームなど）を参照できなくなるまで、ビデオフレームをＰフレームとして圧縮する。一般に、Ｉフレームブロックのエンコード時間は、Ｐフレームブロックより長くかかり得、Ｉフレームの送信は、１フレーム期間より長くかかり得る。例えば、Ｉフレームブロック９０５に対するエンコード時間及び送信時間は、１フレーム期間を超えている。
また、対応するエンコードされたビデオフレームに関連して様々な送信時間が表示されている。例えば、Ｉフレームブロック９０５の前のビデオフレームのエンコード及び送信は、低い一方向レイテンシを有して示され、その結果、対応するエンコード及び伝送ブロックが、１フレーム期間内に実行され得るようになっている。しかしながら、エンコードされたＩフレームブロック９０５の伝送ブロック９１５Ｂは、より高い一方向レイテンシで示されており、その結果、エンコードブロック９０５及び伝送ブロック９１５Ｂは、２つ以上のフレーム期間にわたって発生し、それにより、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターをもたらす。
前述したように、１つ以上のエンコーダパラメータ（例えば、ＱＰ、目標フレームサイズ、最大フレームサイズ、エンコーダビットレートなど）を調節することにより、エンコード時間はさらに短縮され得る。つまり、Ｉフレームの後の第２の、または後続のビデオフレームは、クライアントへの伝送速度がクライアントディスプレイの目標解像度に対して中程度のとき、より低い精度でエンコードされており、また、伝送速度が目標解像度に対して高いときより低い精度でエンコードされている。

【0100】

Ｉフレームブロック９０５の後、エンコーダは、ビデオフレームの圧縮を継続するが、Ｉフレームのエンコードにより、それらは一時的に遅延することがある。この場合も、ＶＳＹＮＣ信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作（スキャンアウト、エンコード、及び伝送）、クライアントでの重複操作（受信、デコード、レンダリング、表示）、及び／またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされる一方向レイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。

【0101】

クライアント帯域幅はクライアントディスプレイの目標解像度に関して中程度であるため、エンコードされたビデオフレームの伝送は、２つまたは３つの後続のビデオフレームがＰフレームとしてエンコードされ、クライアントに伝送された後など、強調表示された領域９４０周辺の低い一方向レイテンシの１つに戻る。領域９４０内で、Ｉフレームブロック９０５がエンコードされた後にエンコードされたＰフレームもまた、同じフレーム期間内にクライアントに伝送され、それにより、クラウドゲーミングサーバとクライアントとの間で低い一方向レイテンシに戻る。

【0102】

図９Ｃは、エンコーダによって圧縮されているビデオフレームのシーケンス９００Ｃを示し、エンコーダは、クライアントに利用可能な帯域幅を考慮しており、本開示の一実施形態によれば、帯域幅が、クライアントディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より低い一方向レイテンシを依然として有しながら、スキップされたフレームがないか、より少ないスキップされたフレームを有することが可能であるようになっている。特に、シーケンス９００Ｃでは、ビデオフレームはＩフレームとしてエンコードされ、後続のビデオフレームもまた正常にエンコードされ、クライアント帯域幅が、クライアントディスプレイの目標解像度に対して高い場合、Ｉフレームのエンコードの遅延後にエンコードされる。
高い帯域幅の可用性があるため、大量の超過帯域幅が、クラウドゲーミングサーバとクライアント間の一方向レイテンシの変動性（例えば、ジッター）を補正するために利用可能であり、その結果、フレームスキップが回避されることができ、低い一方向レイテンシへの回帰が、迅速に（例えば、１つ～２つのフレーム期間内で）達成され得るようになっている。ビデオフレームのエンコードブロック及び伝送ブロックが、ＶＳＹＮＣ信号９５０に関連して示されている。

【0103】

図９Ｂと同様に、図９Ｃのビデオフレームのシーケンス９００Ｃは、１つのエンコードされたＩフレーム９０５を含み、残りのフレームは、Ｐフレームとしてエンコードされている。例示のために、Ｐフレームとしてのエンコードブロック９０１及びエンコードブロック９０２が、エンコードブロック９０５がＩフレームとしてエンコードされる前に、エンコードされている。その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム（Ｉフレームなど）を参照できなくなるまで、ビデオフレームをＰフレームとして圧縮する。一般的に、Ｉフレームブロックのためのエンコード時間は、Ｐフレームブロックよりも長くかかることがある。例えば、Ｉフレームブロック９０５のエンコード時間は、１フレーム期間を超え得る。
また、対応するエンコードされたビデオフレームに関連して様々な伝送時間が表示されている。例えば、Ｉフレームブロック９０５の前のビデオフレームのエンコード及び伝送は、低いレイテンシを有して示され、その結果、対応するエンコード及び伝送ブロックが、１フレーム期間内に実行され得るようになっている。しかしながら、エンコードされたＩフレームブロック９０５の伝送ブロック９１５Ｃは、より高いレイテンシで示されており、その結果、エンコードブロック９０５及び伝送ブロック９１５Ｃは、２つ以上のフレーム期間にわたって発生し、それにより、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターをもたらす。前述したように、１つ以上のエンコーダパラメータ（例えば、ＱＰ、目標フレームサイズ、最大フレームサイズ、エンコーダビットレートなど）を調節することにより、エンコード時間はさらに短縮され得る。

【0104】

Ｉフレームブロック９０５の後、エンコーダは、ビデオフレームの圧縮を継続するが、Ｉフレームのエンコードにより、それらは一時的に遅延することがある。この場合も、ＶＳＹＮＣ信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作（スキャンアウト、エンコード、及び送信）、クライアントでの重複操作（受信、デコード、レンダリング、表示）、及び／またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされるレイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。
クライアント帯域幅はクライアントディスプレイの目標解像度に対して高いため、エンコードされたビデオフレームの伝送は、１つまたは２つの後続のビデオフレームがＰフレームとしてエンコードされ、クライアントに伝送された後など、強調表示された領域９７０周辺の低い一方向レイテンシの１つに戻る。領域９７０内で、Ｉフレームブロック９０５がエンコードされた後にエンコードされたＰフレームもまた、（これらはＶＳＹＮＣ信号の発生の両側にまたがるが）１フレーム期間内にクライアントに伝送され、それにより、クラウドゲーミングサーバとクライアントとの間で低い一方向レイテンシに戻る。

【0105】

図１０は、本開示の様々な実施形態の態様を実行するために使用されることができる例示的なデバイス１０００の構成要素を示している。例えば、図１０は、メディアコンテンツのストリーミング及び／またはストリーミングされたメディアコンテンツの受信に適した例示的なハードウェアシステムを示しており、レイテンシを低減し、クラウド間のより一貫したレイテンシを提供する目的のために、また、ビデオのクライアントディスプレイのスムーズさを改善するために、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するエンコーダ調節を提供することを含み、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたＩフレームの数、シーン変化の数、及び／または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ（ＱＰ）値を含み得、本開示の実施形態によると、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。
このブロック図は、デバイス１０００を示し、デバイス１０００は、パーソナルコンピュータ、サーバコンピュータ、ゲームコンソール、モバイルデバイス、または他のデジタルデバイスを組み込むことができるか、またはそれらであり得、これらの各々は、本発明の実施形態を実施するのに適している。デバイス１０００は、ソフトウェアアプリケーション及び任意選択でオペレーティングシステムを実行するための中央処理装置（ＣＰＵ）１００２を含む。ＣＰＵ１００２は、１つ以上の同種または異種の処理コアで構成され得る。

【0106】

様々な実施形態によれば、ＣＰＵ１００２は、１つ以上の処理コアを有する１つ以上の汎用マイクロプロセッサである。さらなる実施形態は、マイクロプロセッサアーキテクチャを備えた１つ以上のＣＰＵを使用して実装されることができ、このマイクロプロセッサアーキテクチャは、ゲーム実行中のグラフィックス処理のために構成されたアプリケーションの、メディア及びインタラクティブエンターテインメントアプリケーションなどの高度に並列で計算集約的な用途に具体的に適合されている。

【0107】

メモリ１００４は、ＣＰＵ１００２及びＧＰＵ１０１６が使用するためのアプリケーション及びデータを格納する。ストレージ１００６は、アプリケーション及びデータ用の不揮発性ストレージ及びその他のコンピュータ可読メディアを提供し、固定ディスクドライブ、リムーバブルディスクドライブ、フラッシュメモリデバイス、及びＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、Ｂｌｕ－ｒａｙ（登録商標）、ＨＤ－ＤＶＤ、または、その他の光ストレージデバイス、及び信号送信とストレージメディアを含み得る。ユーザ入力デバイス１００８は、１人以上のユーザからデバイス１０００にユーザ入力を通信し、デバイス１０００の例には、キーボード、マウス、ジョイスティック、タッチパッド、タッチスクリーン、静止画またはビデオレコーダ／カメラ、及び／またはマイクロフォンが含まれ得る。
ネットワークインターフェース１００９は、デバイス１０００が、電子通信ネットワークを介して他のコンピュータシステムと通信することを可能にし、ローカルエリアネットワーク及びインターネットなどのワイドエリアネットワークを介した有線または無線通信を含み得る。オーディオプロセッサ１０１２は、ＣＰＵ１００２、メモリ１００４、及び／またはストレージ１００６によって提供される命令及び／またはデータからアナログまたはデジタルオーディオ出力を生成するように適合されている。ＣＰＵ１００２、ＧＰＵ１０１６を含むグラフィックスサブシステム、メモリ１００４、データストレージ１００６、ユーザ入力デバイス１００８、ネットワークインターフェース１００９、及びオーディオプロセッサ１０１２を含むデバイス１０００の構成要素は、１つ以上のデータバス１０２２を介して接続されている。

【0108】

グラフィックサブシステム１０１４は、データバス１０２２及びデバイス１０００の構成要素にさらに接続されている。グラフィックサブシステム１０１４は、グラフィック処理ユニット（ＧＰＵ）１０１６及びグラフィックメモリ１０１８を含む。グラフィックメモリ１０１８は、出力画像の各ピクセルのピクセルデータを格納するために使用されるディスプレイメモリ（例えば、フレームバッファ）を含む。グラフィックスメモリ１０１８は、ＧＰＵ１０１６と同じデバイスに統合することができ、別のデバイスとしてＧＰＵ１０１６と接続され、及び／またはメモリ１００４内に実装されている。
ピクセルデータは、ＣＰＵ１００２から直接的にグラフィックスメモリ１０１８に提供されることができる。代替的に、ＣＰＵ１００２は、ＧＰＵ１０１６に所望の出力画像を定義するデータ及び／または命令を提供し、そこから、ＧＰＵ１０１６は、１つ以上の出力画像のピクセルデータを生成する。所望の出力画像を定義するデータ及び／または命令は、メモリ１００４及び／またはグラフィックスメモリ１０１８に格納されることができる。一実施形態では、ＧＰＵ１０１６は、シーンに対するジオメトリ、照明、シェーディング、テクスチャリング、モーション、及び／またはカメラパラメータを定義する命令及びデータから、出力画像のピクセルデータを生成するための３Ｄレンダリング機能を含む。ＧＰＵ１０１６は、シェーダプログラムを実行することができる１つ以上のプログラム可能な実行ユニットをさらに含むことができる。

【0109】

グラフィックサブシステム１０１４は、ディスプレイデバイス１０１０に表示されるか、または投影システム（図示せず）によって投影される画像のピクセルデータをグラフィックメモリ１０１８から周期的に出力する。ディスプレイデバイス１０１０は、ＣＲＴ、ＬＣＤ、プラズマディスプレイ及びＯＬＥＤディスプレイを含む、デバイス１０００からの信号に応答して視覚情報を表示することができる任意のデバイスであり得る。デバイス１０００は、例えば、アナログまたはデジタルの信号をディスプレイデバイス１０１０に提供することができる。

【0110】

グラフィックサブシステム１０１４を最適化するための他の実施形態は、ＧＰＵインスタンスが複数のアプリケーション間で共有され、かつ、単一のゲームをサポートするＧＰＵが分散されたマルチテナンシＧＰＵ操作を含むことができる。グラフィックサブシステム１０１４は、１つ以上の処理デバイスとして構成されることができる。

【0111】

例えば、グラフィックスサブシステム１０１４は、マルチテナンシＧＰＵ機能を実行するように構成され得、一実施形態では、１つのグラフィックスサブシステムが、複数のゲーム用のグラフィックス及び／またはレンダリングパイプラインを実装し得る。つまり、グラフィックサブシステム１０１４は、実行されている複数のゲーム間で共有される。

【0112】

他の実施形態では、グラフィックサブシステム１０１４は、複数のＧＰＵデバイスを含み、これらは、対応するＣＰＵ上で実行されている単一アプリケーション用にグラフィック処理を実行するために組み合わされている。例えば、複数のＧＰＵは、フレームレンダリングの代替的形態を実行でき、ここでは、ＧＰＵ１は第１のフレームをレンダリングし、ＧＰＵ２は第２のフレームを連続したフレーム期間でレンダリングし、最後のＧＰＵに到達するまでそれを行い、その結果、最初のＧＰＵが次のビデオフレームをレンダリングする（例えば、ＧＰＵが２つしかない場合、ＧＰＵ１は第３のフレームをレンダリングする）。つまり、フレームをレンダリングするときにＧＰＵは循環する。レンダリング操作は重複することができ、ＧＰＵ１が第１のフレームのレンダリングを終了する前にＧＰＵ２が第２のフレームのレンダリングを開始することができる。
別の実施態様では、複数のＧＰＵデバイスに、レンダリングパイプライン及び／またはグラフィックスパイプラインにおいて、異なるシェーダ操作が割り当てられることができる。マスターＧＰＵが、メインのレンダリングと合成を実行している。例えば、３つのＧＰＵを含むグループでは、マスターＧＰＵ１が、メインレンダリング（例えば、第１のシェーダ操作）、及びスレーブＧＰＵ２とスレーブＧＰＵ３からの出力の合成を実行することができ、スレーブＧＰＵ２は、第２のシェーダ操作（例えば、河川などの流体効果）を実行することができ、スレーブＧＰＵ３は、第３のシェーダ（粒子の煙など）操作を実行することができ、マスターＧＰＵ１は、ＧＰＵ１、ＧＰＵ２、ＧＰＵ３の各々からの結果を合成する。このようにして、様々なＧＰＵが割り当てられ、様々なシェーダ操作（旗を振る、風、煙の生成、火など）を実行してビデオフレームをレンダリングすることができる。
さらに別の実施形態では、３つのＧＰＵの各々が、ビデオフレームに対応するシーンの異なるオブジェクト及び／または部分に割り当てられることができる。上述の実施形態及び実装態様では、これらの操作は、同じフレーム期間で（並行して同時に）、または異なるフレーム期間で（並行して連続的に）実行されることができる。

【0113】

従って、本開示は、クラウドゲーミングシステムにおいて一方向レイテンシとビデオ品質との間のトレードオフを改善するためのエンコーダ調整を提供することを含む、メディアコンテンツをストリーミングし、及び／またはストリーミングされたメディアコンテンツを受信するために構成された方法及びシステムを説明しており、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたＩフレームの数、シーン変化の数、及び／または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ（ＱＰ）値を含み得、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。

【0114】

本明細書で定義される様々な実施形態が、本明細書で開示された様々な特徴を使用して、特定の実施態様に組み合わせられるか、または組み立てられ得ることが理解されるべきである。従って、提供される実施例は、いくつかの可能な実施例にすぎず、様々な要素を組み合わせることでより多くの実施態様を定義することが可能な様々な実施態様に限定されない。ある例では、ある実施態様は、開示されたまたは同等の実施態様の趣旨から逸脱することなく、より少ない要素を含んでもよい。

【0115】

本開示の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成で実施されることができる。本開示の実施形態は、有線ベースのネットワークまたは無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実施されることができる。

【0116】

上述の実施形態を念頭に置いて、本開示の実施形態は、コンピュータシステムに格納されたデータを含む様々なコンピュータ実装操作を採用できることを理解されるべきである。これらの動作は、物理量の物理的操作を要する動作である。本開示の実施形態の一部を形成する、本明細書で説明される動作のうちのいずれも、有用な機械動作である。開示の実施形態はまた、これら動作を実行するためのデバイスまたは装置に関する。装置は、必要な目的のために特別に構築されてもよい。または、装置は、コンピュータに記憶されたコンピュータプログラムにより選択的に起動または構成される汎用コンピュータであってもよい。具体的には、本明細書の教示に従って書かれたコンピュータプログラムと共に様々な汎用マシンを使用することができる、あるいは、必要な動作を実行するためにさらに特化した装置を構築するほうがより好都合である場合もある。

【0117】

本開示はまた、コンピュータ可読媒体上のコンピュータ可読コードとして具現化されることができる。コンピュータ可読媒体は、データを格納することができる任意のデータ格納装置であり、これは、その後、コンピュータシステムによって読み取られることができる。コンピュータ可読媒体の例には、ハードドライブ、ネットクワーク接続ストレージ（ＮＡＳ）、読み出し専用メモリ、ランダムアクセスメモリ、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、並びに他の光学及び非光学データストレージデバイスが含まれる。コンピュータ可読媒体は、ネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形媒体を含むことができ、コンピュータ可読コードが分散方式で格納及び実行されるようになっている。

【0118】

本方法の操作は特定の順序で説明されているが、他のハウスキーピング操作が、操作の間に実行され得、もしくは、操作が、わずかに異なる時間に発生するように調整されることができるか、またはシステムに分散されることができ、このことが、重複操作の処理が所望の方法で実行される限り、処理に関連する様々な間隔での処理操作の発生を可能とすることが理解されるべきである。

【0119】

前述の開示は、理解を明確にする目的で、ある程度詳細に説明されてきたが、特定の変更及び修正は、添付の特許請求の範囲内で実施されることができることは明らかであろう。従って、本実施形態は、限定ではなく例示としてみなされるべきであり、本開示の実施形態は、本明細書に提供される詳細に限定されるものではなく、添付の特許請求の範囲内及び均等物内で変更されてもよい。

【図1A】

【図1B】

【図2A】

【図2B】

【図2C】

【図2D】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】