IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ソニー・コンピュータエンタテインメントの特許一覧

特表2022-550443レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整
<>
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図1A
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図1B
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図2A
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図2B
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図2C
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図2D
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図3
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図4
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図5
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図6
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図7
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図8
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図9
  • 特表-レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-12-01
(54)【発明の名称】レイテンシとビデオ品質の間のトレードオフをクラウドゲーミングアプリケーションにおいて改善するためのエンコーダ調整
(51)【国際特許分類】
   H04N 21/2385 20110101AFI20221124BHJP
   H04N 21/24 20110101ALI20221124BHJP
   H04N 19/126 20140101ALI20221124BHJP
   H04N 19/164 20140101ALI20221124BHJP
   H04N 19/179 20140101ALI20221124BHJP
   H04N 19/177 20140101ALI20221124BHJP
   A63F 13/35 20140101ALI20221124BHJP
【FI】
H04N21/2385
H04N21/24
H04N19/126
H04N19/164
H04N19/179
H04N19/177
A63F13/35
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022520322
(86)(22)【出願日】2020-09-30
(85)【翻訳文提出日】2022-05-19
(86)【国際出願番号】 US2020053657
(87)【国際公開番号】W WO2021067516
(87)【国際公開日】2021-04-08
(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
(81)【指定国・地域】
(71)【出願人】
【識別番号】310021766
【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント
(74)【代理人】
【識別番号】100099324
【弁理士】
【氏名又は名称】鈴木 正剛
(72)【発明者】
【氏名】マーク イー. サーニー
(72)【発明者】
【氏名】ケルビン エム. ヨン
【テーマコード(参考)】
5C159
5C164
【Fターム(参考)】
5C159TA53
5C159TB02
5C159TB03
5C159TC45
5C159TD12
5C159UA02
5C159UA05
5C164FA22
5C164GA03
5C164SA32S
5C164SB22P
5C164SB41P
5C164YA24
(57)【要約】
クラウドゲーミングのための方法である。この方法では、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成する。この方法では、複数のビデオフレームをエンコーダビットレートでエンコードし、圧縮された複数のビデオフレームが、クラウドゲーミングサーバのストリーマからクライアントに伝送される。また、この方法では、クライアントの最大受信帯域幅を測定し、ストリーマにおける複数のビデオフレームのエンコードを監視し、さらに、エンコードの監視に基づいてエンコーダのパラメータを動的に調節する。
【選択図】図6
【特許請求の範囲】
【請求項1】
クラウドゲーミング方法であって、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
エンコーダビットレートで前記複数のビデオフレームをエンコードし、圧縮された前記複数のビデオフレームは、前記クラウドゲーミングサーバのストリーマからクライアントに伝送され、
クライアントの最大受信帯域幅を測定し、
前記ストリーマにおいて、前記複数のビデオフレームの前記エンコードを監視し、
前記エンコードの前記監視に基づいて、前記エンコーダのパラメータの動的な調節を行う、方法。
【請求項2】
前記パラメータの動的な調節では、
前記複数のビデオフレームからのビデオフレームのグループをエンコードするために使用される前記エンコーダビットレートが、前記最大受信帯域幅を超えることを判定し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させ、前記パラメータは前記QPパラメータである、請求項1に記載の方法。
【請求項3】
前記パラメータの動的な調節では、
前記複数のビデオフレームからのビデオフレームのグループをエンコードするために使用される前記エンコーダビットレートが、前記最大受信帯域幅内であることを判定し、
前記ビデオフレームのグループを送信するときに、超過帯域幅があることを判定し、
エンコードがより高い精度で実行されるように、前記超過帯域幅に基づいてQPパラメータの値を低減させることであって、前記パラメータが前記QPパラメータである、前記低減させることと、
を含む、請求項1に記載の方法。
【請求項4】
前記パラメータの動的な調整では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのIフレームとして圧縮されたビデオフレームの数がIフレームの閾値数を満たすこと、または超えることを判定し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させることであって、前記パラメータが前記QPパラメータである、前記増加させることと、
を含む、請求項1に記載の方法。
【請求項5】
前記パラメータの動的な調整では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのIフレームとして圧縮されたビデオフレームの数がIフレームの閾値数より低いことを判定し、
エンコードがより高い精度で実行されるようにQPパラメータの値を低減させ、前記パラメータは前記QPパラメータである、請求項1に記載の方法。
【請求項6】
前記パラメータの動的な調整では、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値を満たすこと、または超えることを判定し、前記ビデオフレームの数の各々は、目標フレームサイズを超えるものであり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つを前記パラメータのために低減する、請求項1に記載の方法。
【請求項7】
前記目標フレームサイズ及び前記最大フレームサイズは等しいものである、請求項6に記載の方法。
【請求項8】
前記パラメータの動的な調整では、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値より低いことを判定し、前記ビデオフレームの数の各々は、目標フレームサイズ内にあり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つを前記パラメータとして増加させる、請求項1に記載の方法。
【請求項9】
前記パラメータの動的な調整では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有しているとして識別されたビデオフレームの数がシーン変化の閾値数を満たすこと、または超えることを判定し、
エンコードがより低い精度で実行されるようにQPパラメータの値を増加させ、前記パラメータは前記QPパラメータである、請求項1に記載の方法。
【請求項10】
前記パラメータの動的な調整では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有しているとして識別されたビデオフレームの数がシーン変化の閾値数より低いことを判定し、
エンコードがより高い精度で実行されるようにQPパラメータの値を低減させ、前記パラメータは前記QPパラメータである、請求項1に記載の方法。
【請求項11】
ビデオフレームのエンコードをスキップすることを無効化するによって、前記クライアントにおける再生のスムーズさを優先することをさらに含む、請求項1に記載の方法。
【請求項12】
前記エンコーダにおいて、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整することをさらに含む、請求項1に記載の方法。
【請求項13】
クラウドゲーミングのコンピュータプログラムを格納する非一時的コンピュータ可読媒体であって、
クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成するためのプログラム命令を有し、
クライアントの最大受信帯域幅を測定するためのプログラム命令を有し、
エンコーダビットレートで前記複数のビデオフレームをエンコードするためのプログラム命令を有し、圧縮される前記複数のビデオフレームは、前記クラウドゲーミングサーバのストリーマからクライアントに伝送され、
前記ストリーマにおいて前記複数のビデオフレームの前記エンコードを監視するためのプログラム命令を有し、
前記エンコードの前記監視に基づいて前記エンコーダのパラメータを動的に調節するためのプログラム命令を有する、非一時的コンピュータ可読媒体。
【請求項14】
前記パラメータを動的に調節するための前記プログラム命令は、
前記複数のビデオフレームからのビデオフレームのグループをエンコードするために使用される前記エンコーダビットレートが、前記最大受信帯域幅を超えることを判定するためのプログラム命令を有し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させるためのプログラム命令を有し、前記パラメータは前記QPパラメータである、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項15】
前記パラメータを動的に調節するための前記プログラム命令は、
前記複数のビデオフレームからのビデオフレームのグループをエンコードするために使用される前記エンコーダビットレートが、前記最大受信帯域幅内であることを判定するためのプログラム命令を有し、
前記ビデオフレームのグループを送信するときに、超過帯域幅があることを判定するためのプログラム命令を有し、
エンコードがより高い精度で実行されるように、前記超過帯域幅に基づいてQPパラメータの値を低減させるためのプログラム命令を有し、前記パラメータは前記QPパラメータである、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項16】
前記パラメータを動的に調節するための前記プログラム命令は、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有しているとして識別されたビデオフレームの数がシーン変化の閾値数を満たすこと、または超えることを判定するためのプログラム命令を有し、
エンコードがより低い精度で実行されるようにQPパラメータの値を増加させるためのプログラム命令を有し、前記パラメータは前記QPパラメータである、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項17】
前記パラメータを動的に調節するための前記プログラム命令は、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのIフレームとして圧縮されたビデオフレームの数がIフレームの閾値数より低いことを判定するためのプログラム命令を有し、
プログラミング命令をエンコードがより高い精度で実行されるようにQPパラメータの値を低減させるためのプログラム命令を有し、前記パラメータは前記QPパラメータである
、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項18】
前記パラメータを動的に調節するための前記プログラム命令は、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値を満たすこと、または超えることを判定するためのプログラム命令を有し、前記ビデオフレームの数の各々は目標フレームサイズを超えるものであり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つのパラメータを低減するためのプログラム命令を有する、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項19】
クラウドゲーミング用の前記コンピュータプログラム内で、前記目標フレームサイズと前記最大フレームサイズが等しい、請求項18に記載の非一時的コンピュータ可読媒体。
【請求項20】
前記パラメータを動的に調節するための前記プログラム命令は、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値より低いことを判定するためのプログラム命令であって、前記ビデオフレームの数の各々は目標フレームサイズ内にあり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つを前記パラメータとして増加させるためのプログラム命令を有する、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項21】
前記パラメータを動的に調節するための前記プログラム命令は、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有していると識別されたビデオフレームの数がシーン変化の閾値数を満たすこと、または超えることを判定するためのプログラム命令を有し、
エンコードがより低い精度で実行されるようにQPパラメータの値を増加させるためのプログラム命令を有し、前記パラメータは前記QPパラメータである、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項22】
前記パラメータを動的に調節するための前記プログラム命令は、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有していると識別されたビデオフレームの数がシーン変化の閾値数より低いことを判定するためのプログラム命令を有し、
エンコードがより高い精度で実行されるようにQPパラメータの値を低減するためのプログラム命令を有し、前記パラメータは前記QPパラメータである、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項23】
ビデオフレームのエンコードのスキップを無効化することによって、前記クライアントにおける再生のスムーズさを優先させるためのプログラム命令をさらに含む、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項24】
前記クライアントの前記最大受信帯域幅に基づいて、前記エンコーダでのエンコーダビットレート速度を動的に調整するためのプログラム命令をさらに含む、請求項13に記載の非一時的コンピュータ可読媒体。
【請求項25】
コンピュータシステムであって、
プロセッサと、
前記プロセッサに結合され、その中に格納された命令を有しているメモリと、を含み、前記命令は、前記コンピュータシステムによって実行された場合に、前記コンピュータシステムにクラウドゲーミング方法を実行させ、前記クラウドゲーミング方法は、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
前記複数のビデオフレームをエンコーダビットレートでエンコードし、圧縮された前記複数のビデオフレームが、前記クラウドゲーミングサーバのストリーマからクライアントに伝送され、
クライアントの最大受信帯域幅を測定し、
前記ストリーマにおいて、前記複数のビデオフレームを前記エンコードすることを監視し、
前記エンコードすることを前記監視することに基づいて、前記エンコーダのパラメータを動的に調節する、コンピュータシステム。
【請求項26】
前記パラメータを前記動的に調節する前記方法では、
前記複数のビデオフレームからのビデオフレームのグループをエンコーダするために使用される前記エンコーダビットレートが、前記最大受信帯域幅を超えることを判定し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させ、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項27】
前記パラメータを前記動的に調節する前記方法では、
前記複数のビデオフレームからのビデオフレームのグループをエンコードするために使用される前記エンコーダビットレートが、前記最大受信帯域幅内であることを判定し、
前記ビデオフレームのグループを送信するときに、超過帯域幅があることを判定し、
エンコードがより高い精度で実行されるように前記超過帯域幅に基づいてQPパラメータの値を低減させる、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項28】
前記パラメータを前記動的に調節する前記方法では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのIフレームとして圧縮されたビデオフレームの数がIフレームの閾値数を満たすこと、または超えることを判定し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させ、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項29】
前記パラメータを前記動的に調節する前記方法では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのIフレームとして圧縮されたビデオフレームの数がIフレームの閾値数より低いことを判定し、
エンコードがより高い精度で実行されるようにQPパラメータの値を低減させる、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項30】
前記パラメータを前記動的に調節する前記方法では、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値を満たすこと、または超えることを判定し、前記ビデオフレームの数の各々は目標フレームサイズを超えるものであり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つを前記パラメータのために低減する、請求項25に記載のコンピュータシステム。
【請求項31】
前記方法では、前記目標フレームサイズ及び前記最大フレームサイズが等しい、請求項30に記載のコンピュータシステム。
【請求項32】
前記パラメータを前記動的に調節する前記方法では、
エンコードされ、前記伝送速度で伝送された前記複数のビデオフレームからのビデオフレームのグループが、ビデオフレームの数を含み、前記ビデオフレームの数が閾値より低いことを判定し、前記ビデオフレームの数の各々は目標フレームサイズ内にあり、
前記目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つを前記パラメータとして増加させる、請求項25に記載のコンピュータシステム。
【請求項33】
前記パラメータを前記動的に調節する前記方法では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有しているとして識別されたビデオフレームの数がシーン変化の閾値数を満たすこと、または超えることを判定し、
エンコードがより低い精度で実行されるように、QPパラメータの値を増加させ、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項34】
前記パラメータを前記動的に調節する前記方法では、
圧縮された前記複数のビデオフレームからのビデオフレームのグループからのシーン変化を有しているとして識別されたビデオフレームの数がシーン変化の閾値数より低いことを判定し、
エンコードがより高い精度で実行されるようにQPパラメータの値を低減させ、前記パラメータは前記QPパラメータである、請求項25に記載のコンピュータシステム。
【請求項35】
前記方法では、さらに、
ビデオフレームのエンコードをスキップすることを無効化するによって、前記クライアントにおける再生のスムーズさを優先する、請求項25に記載のコンピュータシステム。
【請求項36】
前記方法では、さらに、
前記エンコーダにおいて、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整する、請求項25に記載のコンピュータシステム。
【請求項37】
クラウドゲーミング方法であって、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
前記ビデオゲームのための第1のビデオフレームに対してシーン変化を予測し、前記シーン変化は、前記第1のビデオフレームが生成される前に予測されるものであり、
前記第1のビデオフレームがシーン変化であるというシーン変化ヒントを生成し、
前記シーン変化ヒントを前記エンコーダに送信し、
前記第1のビデオフレームをエンコーダに配信し、前記第1のビデオフレームは前記シーン変化ヒントに基づいてIフレームとしてエンコードされるものであり、
クライアントの最大受信帯域幅を測定し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第2のビデオフレームをエンコードするか、エンコードしないかを判定する、方法。
【請求項38】
さらに、前記エンコーダでは、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整し、
前記ビデオフレームがエンコードされると、ビデオフレームを前記クライアントに伝送する、請求項37に記載の方法。
【請求項39】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第2のビデオフレームのエンコードをスキップする、請求項37に記載の方法。
【請求項40】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第2のビデオフレームを正常にエンコードする、請求項37に記載の方法。
【請求項41】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第2のビデオフレームをより低い精度でエンコードする、請求項40に記載の方法。
【請求項42】
前記第1のビデオフレームに対するシーン変化の予測では、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて、前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行し、
前記第1のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行し、前記予測は、前記ゲームロジックの実行中に収集されたゲーム状態に基づく、ものであり、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成し、
前記エンコーダが、前記第1のビデオフレームを受信する前に前記シーン変化ヒントを送信する、請求項37に記載の方法。
【請求項43】
前記シーン変化ヒントは、前記シーン変化ロジックからAPIを介して前記エンコーダに配信される、請求項42に記載の方法。
【請求項44】
前記第2のビデオフレームは、前記第1のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、請求項37に記載の方法。
【請求項45】
クラウドゲーミングのコンピュータプログラムを格納する非一時的コンピュータ可読媒体であって、
クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成するためのプログラム命令を有し、
前記ビデオゲームのための第1のビデオフレームに対してシーン変化を予測するためのプログラム命令を有し、前記第1のビデオフレームが生成される前に前記シーン変化が予測されるものであり、
前記第1のビデオフレームがシーン変化であるシーン変化ヒントを生成するためのプログラム命令を有し、
前記シーン変化ヒントを前記エンコーダに送信するためのプログラム命令を有し、
前記第1のビデオフレームをエンコーダに配信するためのプログラム命令を有し、前記第1のビデオフレームは、前記シーン変化ヒントに基づいてIフレームとしてエンコードされ、
クライアントの最大受信帯域幅を測定するためのプログラム命令を有し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第2のビデオフレームをエンコードするか、エンコードしないかを判定するためのプログラム命令を有する、非一時的コンピュータ可読媒体。
【請求項46】
さらに、前記クライアントの前記最大受信帯域幅に基づいて、前記エンコーダでのエンコーダビットレート速度を動的に調整するためのプログラム命令を有し、
前記ビデオフレームがエンコードされると、ビデオフレームを前記クライアントに伝送するためのプログラム命令を有する、請求項45に記載の非一時的コンピュータ可読媒体。
【請求項47】
前記第2のビデオフレームをエンコードするか、エンコードしないかを判定するための前記プログラム命令は、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第2のビデオフレームのエンコードをスキップするためのプログラム命令を有する、請求項45に記載の非一時的コンピュータ可読媒体。
【請求項48】
前記第2のビデオフレームをエンコードするか、エンコードしないかを判定するための前記プログラム命令は、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第2のビデオフレームを正常にエンコードするためのプログラム命令を有する、請求項45に記載の非一時的コンピュータ可読媒体。
【請求項49】
前記第2のビデオフレームをエンコードするか、エンコードしないかを判定するための前記プログラム命令は、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第2のビデオフレームをより低い精度でエンコードするためのプログラム命令を有する、請求項48に記載の非一時的コンピュータ可読媒体。
【請求項50】
前記第1のビデオフレームに対してシーン変化を予測するためのプログラム命令は、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行するためのプログラム命令を有し、
前記第1のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行するプログラム命令を有し、前記予測は、前記ゲームロジックの実行中に収集されたゲーム状態に基づくものであり、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成するためのプログラム命令を有し、
前記エンコーダが前記第1のビデオフレームを受信する前に前記シーン変化ヒントを送信するためのプログラム命令を有する、請求項45に記載の非一時的コンピュータ可読媒体。
【請求項51】
前記クラウドゲーミング用のコンピュータプログラムにおいて、前記シーン変化ヒントは、前記シーン変化ロジックからAPIを介して前記エンコーダに配信される、請求項50に記載の非一時的コンピュータ可読媒体。
【請求項52】
前記クラウドゲーミング用のコンピュータプログラムにおいて、前記第2のビデオフレームは、前記第1のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、請求項45に記載の非一時的コンピュータ可読媒体。
【請求項53】
コンピュータシステムであって、
プロセッサと、
前記プロセッサに結合され、その中に格納された命令を有しているメモリと、を有し、前記命令は、前記コンピュータシステムによって実行されると、前記コンピュータシステムにクラウドゲーミング方法を実行させ、前記クラウドゲーミング方法は、
クラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームを生成し、
前記ビデオゲームのための第1のビデオフレームに対してシーン変化を予測し、前記シーン変化は前記第1のビデオフレームが生成される前に予測されるものであり、
前記第1のビデオフレームがシーン変化である、シーン変化ヒントを生成し、
前記シーン変化ヒントを前記エンコーダに送信し、
前記第1のビデオフレームをエンコーダに配信し、前記第1のビデオフレームは、前記シーン変化ヒントに基づいてIフレームとしてエンコードされるものであり、
クライアントの最大受信帯域幅を測定し、
前記クライアントの前記最大受信帯域幅及びクライアントディスプレイの目標解像度に基づいて、前記エンコーダにおいて受信された第2のビデオフレームをエンコードするか、エンコードしないかを判定する、コンピュータシステム。
【請求項54】
さらに、前記エンコーダにおいて、前記クライアントの前記最大受信帯域幅に基づいて、エンコーダビットレート速度を動的に調整し、
前記ビデオフレームがエンコードされると、ビデオフレームを前記クライアントに伝送する、請求項53に記載のコンピュータシステム。
【請求項55】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して低いときに、圧縮された前記複数のビデオフレームからのビデオフレームのグループの前記クライアントへの前記伝送速度が前記最大受信帯域幅を超えるように、前記第2のビデオフレームのエンコードをスキップする、請求項53に記載のコンピュータシステム。
【請求項56】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの伝送速度が、前記クライアントディスプレイの前記目標解像度に対して高い場合に、圧縮された前記複数のビデオフレームからのビデオフレームのグループに対して前記クライアントへの前記伝送速度が前記最大受信帯域幅内にあるように、前記第2のビデオフレームを正常にエンコードする、請求項53に記載のコンピュータシステム。
【請求項57】
前記第2のビデオフレームをエンコードするか、エンコードしないかの判定では、
前記クライアントへの前記伝送速度が、前記クライアントディスプレイの前記目標解像度に対して中程度である場合、前記第2のビデオフレームをより低い精度でエンコードする、請求項56に記載のコンピュータシステム。
【請求項58】
前記第1のビデオフレームに対するシーン変化の予測では、
前記複数のビデオフレームを生成するために、前記クラウドゲーミングサーバにおいて、前記ビデオゲームのゲームエンジン上に構築されたゲームロジックを実行し、
前記第1のビデオフレームに対する前記シーン変化を予測するためにシーン変化ロジックを実行することであって、前記予測が、前記ゲームロジックの実行中に収集されたゲーム状態に基づく、前記実行し、
前記シーン変化ロジックを使用して前記シーン変化ヒントを生成し、
前記エンコーダが、前記第1のビデオフレームを受信する前に前記シーン変化ヒントを送信する、請求項53に記載のコンピュータシステム。
【請求項59】
前記シーン変化ヒントは、前記シーン変化ロジックからAPIを介して前記エンコーダに配信される、請求項58に記載のコンピュータシステム。
【請求項60】
前記第2のビデオフレームは、前記第1のビデオフレームが前記エンコーダによって圧縮された後に圧縮される、請求項53に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ネットワークを介してコンテンツをストリーミングするように構成されたストリーミングシステムに関し、より具体的には、クラウドゲーミングシステム用の高性能エンコーダ及びデコーダ、ならびにネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダ調節のために構成されたストリーミングシステムに関連する。
【背景技術】
【0002】
近年、ネットワークを介して接続されたクラウドゲーミングサーバとクライアントとの間でストリーミングフォーマットのオンラインまたはクラウドゲーミングを可能にするオンラインサービスが継続的に推進されている。ストリーミングフォーマットは、オンデマンドでのゲームタイトルの利用可能性、マルチプレイヤーゲームのためにプレイヤー間をネットワークする機能、プレイヤー間での資産の共有、プレイヤー間及び/または観客間でのインスタントエクスペリエンスの共有、友人達が、友人がビデオゲームをプレイするのを見ることを可能にすること、友人が進行中のゲームプレイに参加する友人を有すること、などによって、増々人気が高まっている。
残念ながら、その需要はまた、ネットワーク接続の能力と、クライアントに配信されると高品質画像をレンダリングするのに十分な応答性を備えたサーバ及びクライアントにおいて実行される処理の制限と、に対しても押し上がっている。例えば、サーバで実行されるすべてのゲームアクティビティの結果は、最高のユーザエクスペリエンスのために、圧縮されて低いミリ秒のレイテンシでクライアントに戻すように伝送される必要がある。ラウンドトリップレイテンシは、ユーザのコントローラ入力とクライアントにおけるビデオフレームの表示との間の全体的な時間として定義されることができ、これは、コントローラからクライアントへの制御情報の処理と伝送と、クライアントからサーバへの制御情報の処理と伝送と、入力に応答するビデオフレームを生成するためのサーバでのその入力の使用と、ビデオフレームの処理とエンコーディングユニットへの転送(例えば、スキャンアウト)と、ビデオフレームのエンコードと、クライアントへ戻すエンコードされたビデオフレームの伝送と、ビデオフレームの受信とデコードと、表示前のビデオフレームの処理またはステージングのいずれかと、を含み得る。
一方向レイテンシは、ビデオフレームのサーバにあるエンコーディングユニットへの転送(例えば、スキャンアウト)の開始からクライアントにおけるビデオフレームの表示の開始までの時間で構成されるラウンドトリップレイテンシの一部として定義され得る。ラウンドトリップレイテンシ及び一方向レイテンシの一部分は、データストリームが、通信ネットワークを介してクライアントからサーバに送信され、サーバからクライアントに送信されるのにかかる時間に関連付けられている。別の部分は、クライアントとサーバでの処理に関連付けられており、フレームのデコードと表示に関する高度な方策などの、これらの動作での改善は、サーバとクライアント間のラウンドトリップレイテンシ及び一方向レイテンシの実質的な低減になり得、クラウドゲーミングサービスのユーザに高品質のエクスペリエンスを提供する。
【0003】
本開示の実施形態は、このような背景のもとになされたものである。
【発明の概要】
【0004】
本開示の実施形態は、ネットワークを介してコンテンツ(例えば、ゲーム)をストリーミングするように構成されたストリーミングシステムに関し、より具体的には、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するためにエンコーダ調節を提供するように構成されたストリーミングシステムに関し、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたIフレームの数、シーン変化の数、及び/または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ(QP)値を含み得、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。
【0005】
本開示の実施形態は、クラウドゲーミングのための方法を開示する。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、複数のビデオフレームをエンコーダビットレートでエンコードすることを含み、圧縮された複数のビデオフレームが、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、ストリーマにおける複数のビデオフレームのエンコードを監視することを含んでいる。本方法は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節することを含んでいる。
【0006】
別の実施形態では、クラウドゲーミング用のコンピュータプログラムを格納する非一時的なコンピュータ可読媒体が開示されている。コンピュータ可読媒体は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに複数のビデオフレームを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、複数のビデオフレームをエンコーダビットレートでエンコードするためのプログラム命令を含んでおり、圧縮された複数のビデオフレームは、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。コンピュータ可読媒体は、クライアントの最大受信帯域幅を測定するためのプログラム命令を含んでいる。コンピュータ可読媒体は、ストリーマにおける複数のビデオフレームのエンコードを監視するためのプログラム命令を含んでいる。コンピュータ可読媒体は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節するためのプログラム命令を含んでいる。
【0007】
さらに別の実施形態では、コンピュータシステムは、プロセッサと、プロセッサに結合され、命令をその中に格納したメモリと、を含み、命令は、コンピュータシステムによって実行された場合、コンピュータシステムにクラウドゲーミングの方法を実行させる。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、複数のビデオフレームをエンコーダビットレートでエンコードすることを含み、圧縮された複数のビデオフレームが、クラウドゲーミングサーバのストリーマからクライアントに伝送されている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、ストリーマにおける複数のビデオフレームのエンコードを監視することを含んでいる。本方法は、エンコードの監視に基づいてエンコーダのパラメータを動的に調節することを含んでいる。
【0008】
さらに別の実施形態では、クラウドゲーミングのための方法が開示されている。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、ビデオゲームの第1のビデオフレームのシーン変化を予測することを含んでおり、シーン変化は、第1のビデオフレームが生成される前に予測されている。本方法は、第1のビデオフレームがシーン変化である、シーン変化ヒントを生成することを含んでいる。本方法は、シーン変化ヒントをエンコーダに送信することを含んでいる。本方法は、第1のビデオフレームをエンコーダに送達することを含んでおり、第1のビデオフレームは、シーン変化ヒントに基づいてIフレームとしてエンコードされている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて、エンコーダで受信された第2のビデオフレームをエンコードするかエンコードしないかを判定することを含んでいる。
【0009】
別の実施形態では、クラウドゲーミング用のコンピュータプログラムを格納する非一時的なコンピュータ可読媒体が開示されている。コンピュータ可読媒体は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに複数のビデオフレームを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、ビデオゲームの第1のビデオフレームのシーン変化を予測するためのプログラム命令を含んでおり、シーン変化は、第1のビデオフレームが生成される前に予測されている。コンピュータ可読媒体は、第1のビデオフレームがシーン変化であるシーン変化ヒントを生成するためのプログラム命令を含んでいる。コンピュータ可読媒体は、シーン変化ヒントをエンコーダに送信するためのプログラム命令を含んでいる。コンピュータ可読媒体は、第1のビデオフレームをエンコーダに配信するためのプログラム命令を含んでおり、第1のビデオフレームは、シーン変化ヒントに基づいてIフレームとしてエンコードされている。コンピュータ可読媒体は、クライアントの最大受信帯域幅を測定するためのプログラム命令を含んでいる。コンピュータ可読媒体は、エンコーダで受信した第2のビデオフレームをエンコードするかエンコードしないかをクライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて判定するためのプログラム命令を含んでいる。
【0010】
さらに別の実施形態では、コンピュータシステムは、プロセッサと、プロセッサに結合され、コンピュータシステムによって実行されると、コンピュータシステムにクラウドゲーミングの方法を実行させる命令をその中に格納したメモリと、を含む。本方法は、クラウドゲーミングサーバにおいてビデオゲームを実行するときに、複数のビデオフレームを生成することを含んでいる。本方法は、ビデオゲームの第1のビデオフレームのシーン変化を予測することを含んでおり、シーン変化は、第1のビデオフレームが生成される前に予測されている。本方法は、第1のビデオフレームがシーン変化である、シーン変化ヒントを生成することを含んでいる。
本方法は、シーン変化ヒントをエンコーダに送信することを含んでいる。本方法は、第1のビデオフレームをエンコーダに送達することを含んでおり、第1のビデオフレームは、シーン変化ヒントに基づいてIフレームとしてエンコードされている。本方法は、クライアントの最大受信帯域幅を測定することを含んでいる。本方法は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて、エンコーダで受信された第2のビデオフレームをエンコードするかエンコードしないかを判定することを含んでいる。
【0011】
本開示の他の態様は、本開示の原理を例として示す、添付の図面と併せて取られる以下の詳細な説明から明らかになるであろう。
【0012】
本開示は、添付の図面と併せて以下の説明を参照することによって最もよく理解することができる。
【図面の簡単な説明】
【0013】
図1A】本開示の一実施形態による、フレーム期間の開始時のVSYNC信号の図である。
図1B】本開示の一実施形態による、VSYNC信号の周波数の図である。
図2A】本開示の一実施形態による、様々な構成において、1つ以上のクラウドゲーミングサーバと1つ以上のクライアントデバイスとの間でネットワークを介してゲームを提供するためのシステムの図であり、VSYNC信号は、同期及びオフセットされ、一方向レイテンシを低減することができる。
図2B】本開示の一実施形態による、2つ以上のピアデバイス間でゲームを提供するための図であり、VSYNC信号は、同期及びオフセットされ、コントローラ及びデバイス間の他の情報の受信の最適なタイミングを達成することができる。
図2C】本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のVSYNC信号の適切な同期及びオフセットから恩恵を得る様々なネットワーク構成を示す。
図2D】本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のVSYNC信号の適切な同期及びオフセットから恩恵を得る、クラウドゲーミングサーバと複数のクライアントとの間のマルチテナンシ構成を示す。
図3】本開示の一実施形態による、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときのクロックドリフトによるクラウドゲーミングサーバとクライアントとの間の一方向レイテンシの変動を示す。
図4】サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときのクラウドゲーミングサーバとクライアントを含むネットワーク構成を示し、サーバとクライアントとの間のVSYNC信号は、同期かつオフセットされており、サーバ及びクライアントでの操作の重複を可能にし、サーバとクライアント間の一方向レイテンシを低減する。
図5】本開示の一実施形態による、クラウドゲーミングの方法を示すフロー図であり、ビデオフレームのエンコードが、ネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダパラメータの調節を含む。
図6】本開示の一実施形態による、アプリケーション層で動作するストリーマ構成要素によるクライアントの帯域幅の測定を示す図であり、ストリーマは、エンコーダを監視し、調節するように構成されており、圧縮されたビデオフレームが、クライアントの測定された帯域幅内の速度で伝送され得るようになっている。
図7】Aは本開示の一実施形態による、クライアントにおける品質及びバッファ利用を最適化するためのエンコーダの量子化パラメータ(QP)の設定を示す図、Bは本開示の一実施形態による、クライアントによってサポートされる真の目標フレームサイズを超えるIフレームの発生を低減するための、目標フレームサイズ、最大フレームサイズ、及び/またはQP(例えば、最小QP及び/または最大QP)エンコーダ設定の調節を示す図である。
図8】本開示の一実施形態による、クラウドゲーミングの方法を示すフロー図であり、ビデオフレームのエンコードは、Iフレームをエンコードするときなど、エンコードが長い場合、または生成されているビデオフレームが大きい場合に、ビデオフレームをスキップするか、ビデオフレームのエンコード及び伝送を遅延させるかを決定することを含む。
図9】Aは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示しており、エンコーダは、クライアントのディスプレイの目標解像度に対してクライアント帯域幅が低いとき、Iフレームをエンコードした後にビデオフレームのエンコードをドロップし、Bは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示し、各シーケンスでは、ビデオフレームがIフレームとしてエンコードされており、後続のビデオフレームも、クライアント帯域幅が、クライアントのディスプレイの目標解像度に対して中程度または高いときに、Iフレームのエンコードの遅延後にエンコードされ、Cは本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンスを示し、各シーケンスでは、ビデオフレームがIフレームとしてエンコードされており、後続のビデオフレームも、クライアント帯域幅が、クライアントのディスプレイの目標解像度に対して中程度または高いときに、Iフレームのエンコードの遅延後にエンコードされている。
図10】本開示の様々な実施形態の態様を実行するために使用されることができる例示的なデバイスの構成要素を示している。
【発明を実施するための形態】
【0014】
以下の詳細な説明は、例示の目的で多くの具体的な詳細を含むが、当業者は、以下の詳細に対する多くの変形及び変更が本開示の範囲内にあることを理解するであろう。従って、以下に説明する本開示の態様は、この説明に続く特許請求の範囲に対する一般性を失うことなく、また制限を課すことなく説明されている。
【0015】
一般的に言えば、本開示の様々な実施形態は、メディアコンテンツをストリーミングするとき(例えば、ビデオゲームからオーディオ及びビデオをストリーミングするとき)、ソースデバイスとターゲットデバイスとの間のレイテンシ及び/またはレイテンシの不安定性を低減するように構成された方法及びシステムを説明する。サーバにおいて複雑なフレーム(例えば、シーン変化)を生成するために必要になる追加の時間、サーバにおいて複雑なフレームのエンコード/圧縮にかかる時間増加、ネットワークを介した可変通信経路、及びクライアントにおいて複雑なフレームをデコードにかかる時間増加により、サーバとクライアント間の一方向レイテンシにレイテンシ不安定性が生じる可能性がある。レイテンシの不安定性はまた、サーバとクライアントのVSYNC信号の間にドリフトを生じさせるサーバとクライアントにおけるクロックの違いによっても導入され得る。
本開示の実施形態では、サーバとクライアントとの間の一方向レイテンシは、高性能のエンコード及びデコードを提供することによって、クラウドゲーミングアプリケーションにおいて低減され得る。ストリーミングメディア(例えば、ストリーミングビデオ、映画、クリップ、コンテンツ)を解凍するとき、解凍されたビデオのかなりの量をバッファリングすることが可能であり、従って、ストリーミングされたコンテンツを表示するときに、平均のデコード能力及びメトリクスに依存(例えば、60Hzで4Kメディアをサポートするには、デコードリソースの平均量に依存)することが可能である。
しかしながら、クラウドゲーミングでは、(単一フレームであっても)エンコード及び/またはデコード操作を実行する時間が長くなると、それに応じて一方向レイテンシがより高くなる。従って、クラウドゲーミングの場合、ストリーミングビデオアプリケーションの必要性と比較すると不要と見える強力なデコードリソース及びエンコードリソースを供給することが有益であり、リソースは、より長いか、または最も長い処理を必要とするフレームを処理する時間のために最適化される必要がある。本開示の他の実施形態では、クラウドゲーミングアプリケーションにおいてレイテンシとビデオ品質との間のトレードオフを改善するためにエンコーダ調節が実行され得る。
エンコーダ調節は、ネットワークの伝送速度と信頼性の認識、及び全体的なレイテンシ目標のなかで実行される。実施形態では、エンコードが長く実行されるか、または生成されたデータが大きい(例えば、圧縮されたIフレームで両方の条件が発生し得る)場合、後続のフレームのエンコード及び伝送を遅延させるか、またはそれらをスキップするかどうかを判定するための方法が実行される。
実施形態では、量子化パラメータ(QP)値、目標フレームサイズ、及び最大フレームサイズの調節は、クライアントへの利用可能なネットワーク速度に基づいて実行されている。例えば、ネットワーク速度がより速い場合、QPは低減され得る。
他の実施形態では、Iフレーム発生率の監視が実行され、QPの設定に使用される。例えば、Iフレームの頻度が低い場合、QPは低減されることができ(例えば、より高いエンコード精度、またはエンコードのより高い品質をもたらす)、ビデオ再生品質を犠牲にする一方で、一方向レイテンシを低く抑えるためにビデオフレームのエンコードがスキップされ得るようになっている。このように、高性能のエンコードとデコード、及びクラウドゲーミングアプリケーションのレイテンシとビデオ品質の間のトレードオフを改善するために実行されるエンコーダ調節は、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシの低減、よりスムーズなフレームレート、及びより信頼性の高い及び/または一貫した一方向レイテンシへと繋がる。
【0016】
上述の様々な実施形態の一般的な理解を伴って、実施形態の例示的な詳細が、様々な図面を参照して説明される。
【0017】
明細書全体を通して、「ゲーム」または「ビデオゲーム」または「ゲーミングアプリケーション」への言及は、入力コマンドの実行を通じて指示される任意タイプのインタラクティブアプリケーションを表すことを意味する。例示的目的としてだけに、インタラクティブアプリケーションは、ゲーム、ワードプロセッシング、ビデオプロセッシング、ビデオゲームプロセッシングなどのためのアプリケーションを含む。さらに、上記で紹介した用語は互換性があるものである。
【0018】
クラウドゲーミングは、サーバでビデオゲームを実行して、ゲームでレンダリングされたビデオフレームを生成することを含み、これらは、次いで表示のためにクライアントに送信される。サーバとクライアントの両方での操作のタイミングは、それぞれの垂直同期(VSYNC)パラメータに関連付けられ得る。VSYNC信号が、サーバ及び/またはクライアント間で適切に同期及び/またはオフセットされると、サーバで実行される操作(例えば、1つ以上のフレーム期間にわたるビデオフレームの生成と伝送)は、クライアントで実行される操作(例えば、フレーム期間に対応する表示フレームまたはリフレッシュレートでディスプレイにビデオフレームを表示する)と同期される。特に、サーバで生成されたサーバVSYNC信号とクライアントで生成されたクライアントVSYNC信号は、サーバとクライアントでの操作を同期させるために使用され得る。つまり、サーバとクライアントのVSYNC信号が同期及び/またはオフセットされると、サーバは、クライアントがそれらのビデオフレームを表示する方法と同期してビデオフレームを生成及び送信する。
【0019】
サーバとクライアントとの間でメディアコンテンツをストリーミングするときにビデオフレームを生成し、それらのビデオフレームを表示するために、VSYNC信号と垂直帰線区間(VBI)が組み込まれている。例えば、サーバは、対応するサーバVSYNC信号で規定された1つ以上のフレーム期間でゲーム用にレンダリングされたビデオフレームを生成しようとし(例えば、フレーム期間が16.7msの場合、フレーム期間ごとにビデオフレームを生成すると、60Hzの操作になり、2つのフレーム期間ごとに1つのビデオフレームを生成すると、30Hzの操作になる)、その後、そのビデオフレームをエンコードしてクライアントに伝送する。クライアントでは、受信したエンコードされたビデオフレームがデコードされて表示され、クライアントは、対応するクライアントVSYNCで始まる表示用にレンダリングされた各ビデオフレームを表示する。
【0020】
例示のために、図1Aは、VSYNC信号111が、フレーム期間の開始をどのように示し得るかを示しており、ここで、様々な操作が、サーバ及び/またはクライアントにおいて、対応するフレーム期間中に実行され得る。メディアコンテンツをストリーミングするとき、サーバは、ビデオフレームを生成及びエンコードするためにサーバVSYNC信号を使用することができ、クライアントは、ビデオフレームを表示するためにクライアントVSYNC信号を使用することができる。VSYNC信号111は、図1Bに示されるように、規定されたフレーム期間110に対応する規定された周波数で生成される。さらに、VBI105は、最後のラスターラインが、前のフレーム期間のためにディスプレイ上に描かれたときと、最初のラスターライン(例えば、上)が、ディスプレイに描かれたときとの間の期間を規定する。図示されるように、VBI105の後、表示のためにレンダリングされたビデオフレームは、ラスタースキャンライン106を介して表示される(例えば、左から右へのラスターラインごとのラスターライン)。
【0021】
さらに、本開示の様々な実施形態は、メディアコンテンツ(例えば、ビデオゲームコンテンツ)をストリーミングするときなどの、ソースデバイスとターゲットデバイスとの間の一方向レイテンシ及び/またはレイテンシ不安定性を低減するために開示される。説明のみを目的として、一方向レイテンシ及び/またはレイテンシ不安定性を低減するための様々な実施形態が、サーバとクライアントのネットワーク構成の中で説明されている。しかしながら、図2A図2Dに示されるように、一方向レイテンシ及び/またはレイテンシ不安定性を低減するために開示された様々な技術は、他のネットワーク構成内で、及び/またはピアツーピアネットワーク上で実装され得ることが理解される。例えば、一方向レイテンシ及び/またはレイテンシ不安定性を低減するために開示される様々な実施形態は、(例えば、サーバとクライアント、サーバとサーバ、サーバと複数のクライアント、サーバと複数のサーバ、クライアントとクライアント、クライアントと複数のクライアント、など)様々な構成で1つ以上のサーバとクライアントデバイスとの間に実装され得る。
【0022】
図2Aは、様々な構成で、ネットワーク250を介して1つ以上のクラウドゲーミングネットワーク290及び/またはサーバ260と1つ以上のクライアントデバイス210との間にゲームを提供するためのシステム200Aの図であり、本開示の一実施形態によれば、サーバ及びクライアントのVSYNC信号は同期及びオフセットされることができ、及び/または、動的バッファリングがクライアント上で実行されており、及び/または、サーバ上でのエンコード及び伝送操作が重複されることができ、及び/または、クライアントでの受信及びデコード操作が重複されることができ、及び/または、クライアント上でのデコード及び表示操作が重複され、サーバ260とクライアント210との間の一方向レイテンシを短縮することができる。
特に、本開示の一実施形態によれば、システム200Aは、クラウドゲームネットワーク290を介してゲームを提供し、ゲームは、ゲームをプレイしている対応するユーザのクライアントデバイス210(例えば、シンクライアント)から遠隔で実行されている。システム200Aは、シングルプレイヤーモードまたはマルチプレイヤーモードのいずれかで、ネットワーク250を介してクラウドゲームネットワーク290を通じて1つ以上のゲームをプレイする1人以上のユーザにゲーム制御を提供することができる。いくつかの実施形態では、クラウドゲーミングネットワーク290は、ホストマシンのハイパーバイザー上で実行される複数の仮想マシン(VM)を含み得、1つ以上の仮想マシンは、ホストマシンのハイパーバイザーに利用可能なハードウェアリソースを利用してゲームプロセッサモジュールを実行するように構成される。ネットワーク250は、1つ以上の通信技術を含み得る。いくつかの実施形態では、ネットワーク250は、高度な無線通信システムを有する第5世代(5G)ネットワーク技術を含み得る。
【0023】
いくつかの実施形態では、通信は、無線技術を使用して促進され得る。そのような技術は、例えば、5G無線通信技術を含み得る。5Gは、セルラーネットワーク技術の第5世代である。5Gネットワークは、デジタルセルラーネットワークであり、プロバイダーがカバーするサービスエリアは、セルと呼ばれる小さな地理的エリアに分割されている。音と画像を表すアナログ信号は、電話でデジタル化され、アナログ-デジタルコンバータによって変換され、ビットのストリームとして伝送される。セル内のすべての5G無線デバイスは、他のセルで再利用される周波数のプールからトランシーバによって割り当てられた周波数チャネルを介して、セル内のローカルアンテナアレイ及び低電力自動トランシーバ(伝送機及び受信機)を用いて電波で通信する。ローカルアンテナは、高帯域幅の光ファイバまたは無線バックホール接続によって電話網及びインターネットに接続される。他のセルネットワークと同様に、あるセルから別のセルに移動するモバイルデバイスは、新しいセルに自動的に転送される。5Gネットワークは、通信ネットワークの単なる一例示的タイプであり、本開示の実施形態は、5Gに続く後続世代の有線技術または無線技術と同様に、前世代の無線通信または有線通信を利用することができることを理解されたい。
【0024】
図示されるように、クラウドゲーミングネットワーク290は、複数のビデオゲームへのアクセスを提供するゲームサーバ260を含む。ゲームサーバ260は、クラウドで利用可能な任意タイプのサーバコンピューティングデバイスであり得、そして1つ以上のホスト上で実行される1つ以上の仮想マシンとして構成され得る。例えば、ゲームサーバ260は、ユーザのためにゲームのインスタンスをインスタンス化するゲームプロセッサをサポートする仮想マシンを管理することができる。このように、複数の仮想マシンに関連付けられたゲームサーバ260の複数のゲームプロセッサは、複数のユーザのゲームプレイに関連付けられた1つ以上のゲームの複数のインスタンスを実行するように構成されている。
そのようにして、バックエンドサーバサポートは、複数のゲームアプリケーションのゲームプレイのメディア(例えば、ビデオ、オーディオなど)のストリーミングを複数の対応するユーザに提供する。つまり、ゲームサーバ260は、ネットワーク250を介してデータ(例えば、対応するゲームプレイのレンダリングされた画像及び/またはフレーム)を対応するクライアントデバイス210にストリーミングして戻すように構成されている。そのようにして、計算が複雑なゲームアプリケーションは、クライアントデバイス210によって受信及び転送されたコントローラ入力に応答して、バックエンドサーバで実行され得る。各サーバは、画像やフレームをレンダリングすることができ、これらは次いでエンコード(例えば、圧縮)され、対応するクライアントデバイスに表示のためにストリーミングされ得る。
【0025】
例えば、複数のユーザは、ストリーミングメディアを受信するように構成された対応するクライアントデバイス210を使用して、通信ネットワーク250を介してクラウドゲームネットワーク290にアクセスすることができる。一実施形態では、クライアントデバイス210は、計算機能(例えば、ゲームタイトル処理エンジン211を含む)を提供するように構成されたバックエンドサーバ(例えば、クラウドゲームネットワーク290のゲームサーバ260)とのインターフェースを提供するシンクライアントとして構成され得る。
別の実施形態では、クライアントデバイス210は、ビデオゲームの少なくともいくつかのローカル処理のためのゲームタイトル処理エンジン及びゲームロジックで構成され得、バックエンドで実行されるビデオゲームによって生成されるストリーミングコンテンツを受信するために、または、バックエンドサーバサポートによって提供されるその他のコンテンツのためにさらに利用され得る。ローカル処理に対して、ゲームタイトル処理エンジンは、ビデオゲームを実行するための基本的なプロセッサベースの機能と、ビデオゲームに関連するサービスと、を含む。ゲームロジックは、ローカルクライアントデバイス210に格納され、ビデオゲームを実行するために使用される。
【0026】
特に、対応するユーザ(図示せず)のクライアントデバイス210は、インターネットなどの通信ネットワーク250を介してゲームへのアクセスを要求するように、及びゲームサーバ260によって実行されるビデオゲームによって生成される表示画像をレンダリングするように構成され、エンコードされた画像は、対応するユーザに関連付けて表示するためにクライアントデバイス210に配信されている。
例えば、ユーザは、クライアントデバイス210を介して、ゲームサーバ260のゲームプロセッサ上で実行されているビデオゲームのインスタンスと対話し得る。より具体的には、ビデオゲームのインスタンスは、ゲームタイトル処理エンジン211によって実行されている。ビデオゲームを実装する対応するゲームロジック(例えば、実行可能コード)215は、データストア(図示せず)に格納され、データストアを介してアクセス可能であり、ビデオゲームを実行するために使用されている。ゲームタイトル処理エンジン211は、複数のゲームロジックを使用して複数のビデオゲームをサポートすることができ、それらの各々がユーザによって選択可能である。
【0027】
例えば、クライアントデバイス210は、ゲームプレイを駆動するために使用される入力コマンドを介してなど、対応するユーザのゲームプレイに関連してゲームタイトル処理エンジン211と相互作用するように構成される。特に、クライアントデバイス210は、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラよってキャプチャされたジェスチャ、マウス、タッチパッドなどの様々なタイプの入力デバイスからの入力を受信することができる。
クライアントデバイス210は、ネットワーク250を介してゲームサーバ260に接続することができる少なくともメモリ及びプロセッサモジュールを有する任意タイプのコンピューティングデバイスであり得る。バックエンドゲームタイトル処理エンジン211は、レンダリングされた画像を生成するように構成され、レンダリングされた画像は、クライアントデバイス210に関連付けられた対応するディスプレイに表示するためにネットワーク250を介して配信される。
例えば、クラウドベースのサービスを通じて、ゲーム用にレンダリングされた画像は、ゲームサーバ260のゲーム実行エンジン211上で実行される対応するゲームのインスタンスによって配信され得る。つまり、クライアントデバイス210は、エンコードされた画像(例えば、ビデオゲームの実行を通じて生成されたゲームレンダリング画像からエンコードされた)を受信し、表示11のためにレンダリングされた画像を表示するように構成される。一実施形態では、ディスプレイ11は、HMDを含む(例えば、VRコンテンツを表示する)。いくつかの実施形態では、レンダリングされた画像は、クラウドベースのサービスから直接的に、またはクライアントデバイス210(例えば、プレイステーション(登録商標)リモートプレイ)を介して、無線または有線でスマートフォンまたはタブレットにストリーミングされ得る。
【0028】
一実施形態では、ゲームサーバ260及び/またはゲームタイトル処理エンジン211は、ゲーム及びゲームアプリケーションに関連するサービスを実行するための基本的なプロセッサベースの機能を含む。例えば、プロセッサベースの機能は、2Dまたは3Dレンダリング、物理学、物理学シミュレーション、スクリプト、オーディオ、アニメーション、グラフィックス処理、ライティング、シェーディング、ラスター化、レイトレーシング、シャドウイング、カリング、変換、人工知能、等を含む。さらに、ゲームアプリケーションのサービスは、メモリ管理、マルチスレッド管理、サービス品質(QoS)、帯域幅テスト、ソーシャルネットワーキング、ソーシャルフレンドの管理、フレンドのソーシャルネットワークとの通信、通信チャネル、テキストメッセージ、インスタントメッセージング、チャットサポートなどを含む。
【0029】
一実施形態では、クラウドゲーミングネットワーク290は、分散型ゲームサーバシステム及び/またはアーキテクチャである。特に、ゲームロジックを実行する分散型ゲームエンジンは、対応するゲームの対応するインスタンスとして構成される。一般に、分散型ゲームエンジンは、ゲームエンジンの各機能を取得し、多数の処理エンティティによる実行のために、それらの機能を分散する。個々の機能は、1つ以上の処理エンティティにわたって、さらに分散され得る。処理エンティティは、物理ハードウェアを含むさまざまな構成で、及び/または、仮想構成要素または仮想マシンとして、及び/または、仮想コンテナとして構成され得、コンテナは、仮想化されたオペレーティングシステム上で実行中のゲームアプリケーションのインスタンスを仮想化することから、仮想マシンとは異なっている。
処理エンティティは、クラウドゲーミングネットワーク290の1つ以上のサーバ(コンピューティングノード)上のサーバ及びその基礎となるハードウェアを利用及び/または依存することができ、サーバは、1つ以上のラックに配置され得る。様々な処理エンティティへのこれらの機能の実行の調整、割り当て、及び管理は、分散同期層によって実行されている。そのようにして、それらの機能の実行が分散同期層によって制御されて、プレイヤーによるコントローラ入力に応答して、ゲームアプリケーション用のメディア(例えば、ビデオフレーム、オーディオなど)を生成することが可能になる。分散同期層は、分散処理エンティティにわたって、(例えば、負荷均衡を通じて)これらの機能を効率的に実行でき、重要なゲームエンジン構成要素/機能が分散され、より効率的な処理のために再構築されるようになっている。
【0030】
ゲームタイトル処理エンジン211は、中央処理装置(CPU)と、マルチテナンシGPU機能を実行するように構成され得るグラフィックス処理装置(GPU)グループと、を含む。別の実施形態では、複数のGPUデバイスが組み合わせられて、対応するCPU上で実行されている単一アプリケーションのグラフィックス処理を実行する。
【0031】
図2Bは、本開示の一実施形態による、2つ以上のピアデバイス間でゲームを提供するための図であり、VSYNC信号は、同期及びオフセットされ、コントローラ及びデバイス間の他の情報の受信の最適なタイミングを達成することができる。例えば、直接対決ゲームは、ネットワーク250を介して、またはピアツーピア通信(例えば、Bluetooth(登録商標)、ローカルエリアネットワーキングなど)を介して直接接続された2つ以上のピアデバイスを使用して実行され得る。
【0032】
図示されるように、ゲームは、ビデオゲームをプレイしている対応するユーザのクライアントデバイス210(例えば、ゲームコンソール)の各々でローカルに実行されており、クライアントデバイス210は、ピアツーピアネットワーキングを介して通信する。例えば、ビデオゲームのインスタンスは、対応するクライアントデバイス210のゲームタイトル処理エンジン211によって実行されている。ビデオゲームを実装するゲームロジック215(例えば、実行可能コード)は、対応するクライアントデバイス210に格納され、ゲームを実行するために使用されている。説明の目的で、ゲームロジック215は、ポータブル媒体(例えば、光媒体)を介して、またはネットワークを介して(例えば、インターネットを介してゲームプロバイダからダウンロードされる)、対応するクライアントデバイス210に配信され得る。
【0033】
一実施形態では、対応するクライアントデバイス210のゲームタイトル処理エンジン211は、ゲーム及びゲームアプリケーションに関連するサービスを実行するための基本的なプロセッサベースの機能を含む。例えば、プロセッサベースの機能は、2Dまたは3Dレンダリング、物理学、物理学シミュレーション、スクリプト、オーディオ、アニメーション、グラフィックス処理、ライティング、シェーディング、ラスター化、レイトレーシング、シャドウイング、カリング、変換、人工知能、等を含む。さらに、ゲームアプリケーションのサービスは、メモリ管理、マルチスレッド管理、サービス品質(QoS)、帯域幅テスト、ソーシャルネットワーキング、ソーシャルフレンドの管理、フレンドのソーシャルネットワークとの通信、通信チャネル、テキストメッセージ、インスタントメッセージング、チャットサポートなどを含む。
【0034】
クライアントデバイス210は、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラによってキャプチャされたジェスチャ、マウス、タッチパッドなど、様々なタイプの入力デバイスから入力を受信することができる。クライアントデバイス210は、少なくともメモリ及びプロセッサモジュールを有する任意タイプのコンピューティングデバイスであり得、ゲームタイトル処理エンジン211によって実行されるレンダリング画像を生成し、ディスプレイ(例えば、ディスプレイ11、またはヘッドマウントディスプレイ(HMD)を含むディスプレイ11など)にレンダリング画像を表示するように構成される。
例えば、レンダリングされた画像は、クライアントデバイス210上でローカルに実行されるゲームのインスタンスに関連付けられ得、ゲームプレイを駆動するために使用される入力コマンドなどを介して、対応するユーザのゲームプレイを実装する。クライアントデバイス210のいくつかの例には、パーソナルコンピュータ(PC)、ゲームコンソール、ホームシアターデバイス、汎用コンピュータ、モバイルコンピューティングデバイス、タブレット、電話、またはゲームのインスタンスを実行することができる任意の他のタイプのコンピューティングデバイスが含まれる。
【0035】
図2Cは、本開示の実施形態による、ソースデバイスとターゲットデバイスとの間のVSYNC信号の適切な同期及びオフセットから恩恵を得る、図2A図2Bに示される構成を含む、様々なネットワーク構成を示している。特に、様々なネットワーク構成は、サーバとクライアントのVSYNC信号の周波数の適切なアライメント、及びサーバとクライアント間の一方向レイテンシ及び/またはレイテンシ変動性を低減する目的のサーバとクライアントのVSYNC信号のタイミングオフセットの恩恵を得る。例えば、1つのネットワークデバイス構成は、クラウドゲーミングサーバ(例えば、ソース)からクライアント(ターゲット)への構成を含む。
一実施形態では、クライアントは、ウェブブラウザ内でオーディオ及びビデオ通信を提供するように構成されたウェブRTCクライアントを含み得る。別のネットワーク構成は、クライアント(例えば、ソース)からサーバ(ターゲット)への構成を含む。さらに別のネットワーク構成は、サーバ(例えば、ソース)からサーバ(例えば、ターゲット)への構成を含む。別のネットワークデバイス構成は、クライアント(例えば、ソース)からクライアント(ターゲット)への構成を含み、クライアントは各々が、例えば、直接対決ゲームを提供するためのゲームコンソールであり得る。
【0036】
特に、VSYNC信号のアラインメントは、サーバVSYNC信号とクライアントVSYNC信号の周波数の同期を含み得、ドリフトを除去する目的のため、及び/または、一方向レイテンシ及び/またはレイテンシ変動性を低減する目的で、サーバとクライアントのVSYNC信号間の理想的な関係を維持するために、クライアントVSYNC信号とサーバVSYNC信号との間のタイミングオフセットを調整することも含み得る。
適切なアライメントを達成するために、一実施形態では、サーバ260とクライアント210のペアとの間の適切なアライメントを実施するために、サーバVSYNC信号が調節され得る。
別の実施形態では、クライアントVSYNC信号は、サーバ260とクライアント210のペアとの間の適切なアライメントを実施するために調節され得る。クライアントとサーバのVSYNC信号がアライメントされると、サーバVSYNC信号とクライアントVSYNC信号は、実質的に同一周波数で発生し、随時調整できるタイミングオフセットによって互いにオフセットされる。
別の実施形態では、VSYNC信号のアライメントは、2つのクライアントのVSYNCの周波数を同期させることを含み得、ドリフトを除去する目的で、それらのVSYNC信号の間のタイミングオフセットを調整すること、及び/またはコントローラ及びその他の情報の受信の適切なタイミングを達成することも含み得、いずれのVSYNC信号も、このアライメントを達成するように調節され得る。
さらに別の実施形態では、アラインメントは、複数のサーバのVSYNCの周波数を同期させることを含み得、また、サーバVSYNC信号及びクライアントVSYNC信号の周波数を同期し、クライアントVSYNC信号とサーバVSYNC信号との間のタイミングオフセットを、例えば、直接対決クラウドゲーミングのために調整することを含み得る。サーバからクライアントへの構成、及びクライアントからクライアントへの構成では、アラインメントは、サーバVSYNC信号とクライアントVSYNC信号の間の周波数の同期、及びサーバVSYNC信号とクライアントVSYNC信号との間の適切なタイミングオフセットの提供の両方が含まれ得る。サーバからサーバへの構成では、アライメントは、タイミングオフセットを設定することを伴わないサーバVSYNC信号とクライアントVSYNC信号との間の周波数の同期を含み得る。
【0037】
図2Dは、本開示の一実施形態による、ソースデバイスとターゲットデバイスとの間のVSYNC信号の適切な同期及びオフセットから恩恵がもたらされるクラウドゲーミングサーバ260と1つ以上のクライアント210との間のマルチテナンシ構成を示す。サーバからクライアントへの構成では、アライメントは、サーバVSYNC信号とクライアントVSYNC信号との間の周波数の同期、及びサーバVSYNC信号とクライアントVSYNC信号との間の適切なタイミングオフセットの提供の両方を含み得る。マルチテナンシ構成では、一実施形態では、サーバ260とクライアント210のペアとの間の適切なアライメントを実施するために、クライアントVSYNC信号が各クライアント210において調節されている。
【0038】
例えば、グラフィックスサブシステムは、マルチテナンシGPU機能を実行するように構成され得、一実施形態では、1つのグラフィックスサブシステムは、グラフィックスの実装、及び/または複数のゲームのためのパイプラインのレンダリングである場合がある。つまり、グラフィックサブシステムは、実行されている複数のゲーム間で共有される。特に、ゲームタイトル処理エンジンは、マルチテナンシGPU機能を実行するように構成されたCPU及びGPUグループを含み得、一実施形態では、1つのCPU及びGPUグループは、グラフィックスの実装、及び/または複数のゲームのためのパイプラインのレンダリングである場合がある。つまり、CPU及びGPUグループは、実行されている複数のゲーム間で共有される。CPU及びGPUグループは、1つ以上の処理デバイスとして構成されることができる。別の実施形態では、複数のGPUデバイスが組み合わせられて、対応するCPU上で実行されている単一アプリケーションのグラフィックス処理を実行する。
【0039】
図3は、サーバでビデオゲームを実行してゲーム用にレンダリングされたビデオフレームを生成し、それらのビデオフレームを表示のためにクライアントに送信する一般的なプロセスを示している。従来的に、ゲームサーバ260及びクライアント210における、いくつかの操作は、それぞれのVSYNC信号によって規定されるフレーム期間内に実行される。例えば、サーバ260は、対応するサーバVSYNC信号311によって規定されるような1つ以上のフレーム期間において、301においてゲーム用にレンダリングされたビデオフレームを生成しようと努める。
ビデオフレームは、操作350で入力デバイスから配信される制御情報(例えば、ユーザの入力コマンド)、または制御情報によって駆動されないゲームロジックのいずれかに応答して、ゲームによって生成される。伝送ジッター351は、制御情報をサーバ260に送信するときに存在し得、ジッター351は、クライアントからサーバへのネットワークレイテンシの変動(例えば、入力コマンドを送信するとき)を測定する。
図示されるように、太い矢印は、制御情報をサーバ260に送信するときの現在の遅延を示しているが、ジッターのために、サーバ260において制御情報のための到着時間の範囲(例えば、点線矢印で囲まれた範囲)があり得る。フリップ時間309で、GPUは、対応するビデオフレームが完全に生成され、サーバ260のフレームバッファに配置されたことを示すフリップコマンドに到達する。その後、サーバ260は、サーバVSYNC信号311(VBIは明確化のために省略されている)によって規定される後続のフレーム期間にわたって、そのビデオフレームに対してスキャンアウト/スキャンイン(操作302、そこでスキャンアウトはVSYNC信号311とアライメントされ得る)を実行する。続いて、ビデオフレームがエンコード(操作303)され(例えば、VSYNC信号311の発生後にエンコードが開始され、エンコードの終了はVSYNC信号とアライメントされなくてもよい)、クライアント210へ伝送(操作304、ここでは伝送はVSYNC信号311とアライメントされなくてもよい)される。
クライアント210において、エンコードされたビデオフレームは、受信され(操作305、ここでは受信はクライアントVSYNC信号312とアライメントされなくてもよい)、デコードされ(操作306、ここではデコードはクライアントVSYNC信号312とアライメントされなくてもよい)、バッファリングされ、表示される(操作307、ここでは表示の開始は、クライアントのVSYNC信号312とアライメントされなくてもよい)。特に、クライアント210は、クライアントVSYNC信号312の対応する発生で開始する表示のためにレンダリングされた各ビデオフレームを表示する。
【0040】
一方向レイテンシ315は、サーバでのビデオフレームのエンコードユニット(例えば、スキャンアウト302)への転送の開始から、クライアント307でのビデオフレームの表示の開始までのレイテンシとして定義され得る。つまり、一方向レイテンシは、クライアントのバッファリングを考慮した、サーバのスキャンアウトからクライアントの表示までの時間である。個々のフレームは、スキャンアウト302の開始からデコード306の完了までのレイテンシを有し、このレイテンシは、エンコード303と伝送304、サーバ260とクライアント210との間のジッター352を伴うネットワーク伝送、及びクライアント受信305などのサーバ操作の高度な変動により、フレームごとに変化し得る。
図示されているように、直線の太い矢印は、対応するビデオフレームをクライアント210に送信するときの現在のレイテンシを示しているが、ジッター352のために、クライアント210におけるビデオフレームの到着時間の範囲(例えば、点線矢印で区分けされた範囲)があり得る。良好な再生体験を実現するには、一方向レイテンシが比較的安定している(例えば、かなり一貫性が保たれている)必要があるため、従来、バッファリング320は、低いレイテンシ(例えば、スキャンアウト302の開始からデコード306の完了まで)を伴う個々のフレームの表示が、いくつかのフレーム期間にわたり遅延される結果を伴って実行される。つまり、ネットワークの不安定性、または予測できないエンコード/デコード時間がある場合、一方向レイテンシが一定に保たれるように追加のバッファリングが必要になる。
【0041】
本開示の一実施形態によれば、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシは、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときに、クロックドリフトのために変化し得る。つまり、サーバVSYNC信号311とクライアントVSYNC信号312の周波数の違いは、サーバ260から到着するフレームに対してドリフトするクライアントVSYNC信号を生じ得る。このドリフトは、サーバとクライアントにおけるそれぞれのクロックの各々で使用される水晶振動子での、ごくわずかな違いによるものであり得る。さらに、本開示の実施形態は、サーバとクライアントとの間のアラインメントのためのVSYNC信号の同期及びオフセットの1つ以上を実行することによって、クライアントにおいて動的バッファリングを提供することによって、サーバにおいてビデオフレームのエンコード及び伝送を重複させることによって、クライアントにおいてビデオフレームの受信とデコードを重複させることによって、かつ、クライアントにおいてビデオフレームのデコードと表示を重複させることによって、一方向レイテンシを低減する。
【0042】
さらに、ビデオフレームのエンコード(操作303)の間、以前の技術では、エンコーダは、エンコードされている現在のビデオフレームと1つ以上の以前にエンコードされたフレームとの間にどれだけの変化があるかを判定して、シーン変化(例えば、対応する生成されたビデオフレームの複雑な画像)があるかどうかを判定する。つまり、シーン変化ヒントは、エンコードされる現在のフレームと、既にエンコードされている以前のフレームとの違いから推測できる。ネットワークを介してサーバからクライアントにコンテンツをストリーミングするとき、サーバにおけるエンコーダは、複雑性を伴うシーン変化として検出されるビデオフレームをエンコードすることを決定することができる。そうでない場合、エンコーダは、より低い複雑性を有するシーン変化として検出されないビデオフレームをエンコードする。
しかしながら、エンコーダにおけるシーン変化の検出は、ビデオフレームが初めに、より低い複雑性を伴って(第1のフレーム期間で)エンコードされるが、次いで、シーン変化があると判断されると、より高い複雑性を伴って(第2のフレーム期間で)再エンコードされるように、最大1フレーム期間(例えば、ジッターの追加)がかかり得る。同様に、シーン変化の検出は、シーン変化がないとしても、現在エンコードされているビデオフレームと以前にエンコードされたビデオフレームとの差異が閾値差異値を超え得ることから、(画像内の小さな爆発を介してなど)不必要にトリガーされ得る。このように、シーン変化がエンコーダにおいて検出されると、ジッターによる追加的なレイテンシがエンコーダにおいて導入され、シーン変化の検出の実行と、より高い複雑性を有するビデオフレームの再エンコードと、に適応する。
【0043】
図4は、サーバ上で実行されるビデオゲームから生成されたビデオフレームをストリーミングするときの、高度に最適化されたクラウドゲーミングサーバ260と、高度に最適化されたクライアント210と、を含むネットワーク構成を通るデータのフローを示し、本開示の実施形態によれば、サーバ操作とクライアント操作の重複が、一方向レイテンシを低減し、サーバとクライアント間のVSYNC信号の同期及びオフセットが、一方向レイテンシを低減し、同時に、サーバとクライアント間の一方向レイテンシの変動性を低減する。
特に、図4は、サーバVSYNC信号とクライアントVSYNC信号との間の望ましいアライメントを示している。一実施形態では、サーバVSYNC信号311の調節は、サーバ及びクライアントのネットワーク構成などにおいて、サーバVSYNC信号とクライアントVSYNC信号との間の適切なアライメントを得るために実行されている。
別の実施形態では、クライアントVSYNC信号312の調節は、マルチテナントサーバから複数クライアントへのネットワーク構成におけるような、サーバVSYNC信号とクライアントVSYNC信号との間の適切なアラインメントを得るために実行されている。サーバ及びクライアントのVSYNC信号の周波数を同期させること、及び/または対応するクライアント及びサーバのVSYNC信号間のタイミングオフセットを調整することを目的として、例示を目的として、サーバVSYNC信号311の調節が図4で説明されているが、クライアントVSYNC信号312もまた、調節に使用され得ることが理解される。
この特許出願の文脈では、「同期」とは、周波数が一致するが、位相は異なり得るように信号を調節することを意味すると解釈されるべきであり、「オフセット」とは、例えば、一方の信号が最大値に達したときと、もう一方の信号が最大値に達したときとの間の時間のように、信号間の時間遅延を意味すると解釈されるべきである。
【0044】
図示されているように、図4は、本開示の実施形態において、サーバにおいてビデオゲームを実行してレンダリングされたビデオフレームを生成し、それらのビデオフレームを表示のためにクライアントに送信する改善されたプロセスを示している。本プロセスは、サーバとクライアントにおける単一ビデオフレームの生成と表示に関して示されている。特に、サーバは、401においてゲーム用にレンダリングされたビデオフレームを生成する。例えば、サーバ260は、ゲームを実行するように構成されたCPU(例えば、ゲームタイトル処理エンジン211)を含む。CPUは、ビデオフレームに対して1つ以上のドローコールを生成し、このドローコールは、グラフィックスパイプライン内のサーバ260の対応するGPUによって実行するためにコマンドバッファに配置されたコマンドを含む。
グラフィックスパイプラインは、シーン内のオブジェクトの頂点に1つ以上のシェーダプログラムを含み、表示用のビデオフレームにレンダリングされたテクスチャ値を生成でき、この操作は、効率を上げるためにGPUを介して並行して実行されている。フリップ時間409において、GPUは、コマンドバッファ内のフリップコマンドに到達し、これは、対応するビデオフレームが、完全に生成され、及び/またはレンダリングされ、サーバ260でフレームバッファ内に配置されたことを示している。
【0045】
402において、サーバはゲーム用にレンダリングされたビデオフレームのスキャンアウトをエンコーダに実行する。特に、スキャンアウトは、スキャンラインごとに、または連続するスキャンラインのグループで実行され、スキャンラインは、例えば、画面の端から画面の端までの単一の水平線の表示を指す。これらのスキャンラインまたは連続するスキャンラインのグループは、スライスと称されることもあり、この明細書ではスクリーンスライスと称されている。特に、スキャンアウト402は、いくつかのプロセスを含み得、これらはゲーム用にレンダリングされたフレームを変更し、別のフレームバッファでそれをオーバーレイすること、または別のフレームバッファからの情報でそれを囲むためにそれを縮小することを含む。スキャンアウト402の間、修正されたビデオフレームは、次いで、圧縮のためにエンコーダにスキャンされる。一実施形態では、スキャンアウト402は、VSYNC信号311の発生311aで実行される。他の実施形態では、スキャンアウト402は、フリップ時間409などで、VSYNC信号311の発生の前に実行され得る。
【0046】
403において、ゲーム用にレンダリングされたビデオフレーム(変更された可能性がある)は、エンコーダでエンコーダスライスごとに1つのエンコーダスライスにエンコードされて、1つ以上のエンコードスライスを生成し、ここで、エンコードされたスライスは、スキャンラインまたはスクリーンスライスとは無関係である。このように、エンコーダは、1つ以上のエンコードされた(例えば、圧縮された)スライスを生成する。一実施形態では、エンコードプロセスは、スキャンアウト402プロセスが、対応するビデオフレームのために完全に完了する前に開始する。
さらに、エンコード403の開始及び/または終了は、サーバVSYNC信号311とアライメントされてもされなくてもよい。エンコードされたスライスの境界は、単一のスキャンラインに制限されず、単一のスキャンライン、または複数のスキャンラインで構成され得る。さらに、エンコードされたスライスの終了及び/または次のエンコーダスライスの開始は、必ずしも表示画面の端で発生し得ず(例えば、画面の中央またはスキャンラインの中央で発生し得る)、エンコードされたスライスは、表示画面の端から端まで完全に横断する必要はない。図示されるように、1つ以上のエンコードされたスライスは、ハッシュマークを有する圧縮された「エンコードされたスライスA」を含めて、圧縮及び/またはエンコードされ得る。
【0047】
404において、エンコードされたビデオフレームは、サーバからクライアントに伝送され、この伝送は、エンコードされたスライスごとに行われることができ、各エンコードされたスライスは、圧縮されたエンコーダスライスである。一実施形態では、伝送プロセス404は、エンコードプロセス403が、対応するビデオフレームに対して完全に完了する前に開始する。さらに、伝送404の開始及び/または終了は、サーバVSYNC信号311とアライメントされていてもされていなくてもよい。図示されているように、圧縮されたエンコードされたスライスAは、レンダリングされたビデオフレームに対する他の圧縮されたエンコーダスライスとは独立してクライアントに伝送される。エンコーダスライスは、一度に1つずつ、または並行して伝送され得る。
【0048】
405において、クライアントは圧縮されたビデオフレームを受信し、これもエンコードされたスライスごとに行われる。さらに、受信405の開始及び/または終了は、クライアントVSYNC信号312とアライメントされても、されなくてもよい。図示されているように、圧縮されたエンコードされたスライスAが、クライアントによって受信される。伝送ジッター452は、サーバ260とクライアント210との間に存在することができ、ジッター452は、サーバ260からクライアント210へのネットワークレイテンシの変動を測定する。
より低いジッター値は、より安定した接続を示す。図示されているように、太い直線矢印は、対応するビデオフレームをクライアント210に送信するときの現在のレイテンシを示しているが、ジッターにより、クライアント210におけるビデオフレームに対する到着時間の範囲(例えば、点線矢印で囲まれた範囲)があり得る。レイテンシの変動はまた、エンコード403や伝送404などのサーバでの1つ以上の操作によるものであり得、同様に、ビデオフレームをクライアント210に伝送するときにレイテンシをもたらすネットワークの問題によるものであり得る。
【0049】
406において、クライアントは、再びエンコードされたスライスごとに、圧縮されたビデオフレームをデコードし、現時点で表示準備ができているデコードされたスライスA(ハッシュマークなしで示されている)を生成する。一実施形態では、デコードプロセス406は、受信プロセス405が、対応するビデオフレームに対して完全に完了する前に開始する。さらに、デコード406の開始及び/または終了は、クライアントVSYNC信号312とアライメントされてもよく、またはされなくてもよい。407において、クライアントは、デコードされたレンダリングされたビデオフレームをクライアントにおいてディスプレイに表示する。つまり、デコードされたビデオフレームは、例えば、スキャンラインごとにディスプレイデバイスにストリームアウトされるディスプレイバッファに配置される。
一実施形態では、表示プロセス407(すなわち、ディスプレイデバイスへのストリーミングアウト)は、デコードプロセス406が、対応するビデオフレームに対して完全に完了した後、すなわち、デコードされたビデオフレームが、ディスプレイバッファに完全に常駐した後に開始する。
別の実施形態では、表示プロセス407は、デコードプロセス406が対応するビデオフレームに対して完全に完了する前に開始する。つまり、ディスプレイデバイスへのストリームアウトは、デコードされたフレームバッファの一部分のみがディスプレイバッファに常駐する時点で、ディスプレイバッファのアドレスで開始する。ディスプレイバッファは、次いで、表示に間に合うように、対応するビデオフレームの残りの部分で更新または充填され、ディスプレイバッファの更新は、それらの部分がディスプレイにストリームアウトする前に実行されるようになっている。さらに、表示407の開始及び/または終了は、クライアントVSYNC信号312とアライメントされる。
【0050】
一実施形態では、サーバ260とクライアント210との間の一方向レイテンシ416は、スキャンアウト402が開始されたときと、表示407が開始されるときとの間の経過時間として定義され得る。本開示の実施形態は、サーバとクライアントとの間のVSYNC信号をアライメント(例えば、周波数を同期させ、オフセットを調整する)させ、サーバとクライアントとの間の一方向レイテンシを低減し、サーバとクライアントとの間の一方向レイテンシの変動性を低減することができる。
例えば、本開示の実施形態は、サーバVSYNC信号311とクライアントVSYNC信号312との間のオフセット430に対する最適な調整を計算することができ、それにより、エンコード403及び伝送404などのサーバ処理に必要なほぼ最悪の場合の時間が発生した場合であっても、サーバ260とクライアント210との間のほぼ最悪の場合のネットワークレイテンシが発生した場合であっても、及び受信405及びデコード406などのほぼ最悪の場合のクライアント処理が発生した場合であっても、デコードされレンダリングされたビデオフレームは、表示プロセス407に間に合うように利用可能である。つまり、サーバVSYNCとクライアントVSYNCとの間の絶対オフセットを決定する必要はなく、デコードされレンダリングされたビデオフレームが表示プロセスに間に合うようにオフセットを調整するだけで十分である。
【0051】
特に、サーバVSYNC信号311及びクライアントVSYNC信号312の周波数は、同期によって調整され得る。同期は、サーバVSYNC信号311またはクライアントVSYNC信号312を調節することによって実現される。例示を目的として、調節は、サーバVSYNC信号311に関連して説明されているが、調節は、代わりにクライアントVSYNC信号312で実行され得ることが理解される。例えば、図4に示すように、サーバフレーム期間410(例えば、サーバVSYNC信号311の2回の発生である311cと311dとの間の時間)は、クライアントフレーム期間415(例えば、クライアントVSYNC信号312の2回の発生である312aと312bとの間の時間)と実質的に等しく、このことは、サーバVSYNC信号311とクライアントのVSYNC信号312の周波数も実質的に等しいことを示している。
【0052】
サーバ及びクライアントのVSYNC信号の周波数の同期を維持するために、サーバVSYNC信号311のタイミングが操作され得る。例えば、サーバVSYNC信号311の垂直帰線区間(VBI)は、例えば、サーバVSYNC信号311とクライアントVSYNC信号312との間のドリフトを確認するために、ある期間にわたって増加または減少され得る。VBIにおける垂直帰線(VBLANK)の操作は、サーバVSYNC信号311の1つ以上のフレーム期間に対するVBLANKに使用されるスキャンラインの数を調整することを提供する。VBLANKのスキャンラインの数が下落すると、サーバVSYNC信号311の2つの発生間の対応するフレーム期間(例えば、時間間隔)を短縮する。反対に、VBLANKのスキャンラインの数が増加すると、VSYNC信号311の2つの発生の間の対応するフレーム期間(例えば、時間間隔)を延長する。そのようにして、サーバVSYNC信号311の周波数は、クライアントとサーバのVSYNC信号311と312との間の周波数が実質的に同じ周波数になるように調整される。また、サーバとクライアントのVSYNC信号間のオフセットは、VBIを元の値に戻す前に、VBIを短時間にわたり増減することで調整され得る。
一実施形態では、サーバVBIが調整される。別の実施形態では、クライアントVBIが調整される。さらに別の実施形態では、2つのデバイス(サーバ及びクライアント)の代わりに、複数の接続されたデバイスがあり、それらのそれぞれは、調整された対応するVBIを有し得る。一実施形態では、複数の接続されたデバイスの各々は、(例えば、サーバデバイスを伴わない)独立したピアデバイスであり得る。別の実施形態では、複数のデバイスは、1つ以上のサーバ/クライアントアーキテクチャ、マルチテナントサーバ/クライアント(複数可)アーキテクチャ、またはそれらのいくつかの組み合わせに配置された、1つ以上のサーバデバイス及び/または1つ以上のクライアントデバイスを含み得る。
【0053】
他の形態として、サーバのピクセルクロック(例えば、サーバのノースブリッジ/サウスブリッジコアロジックチップセットのサウスブリッジに配置されているか、またはディスクリートGPUの場合は、独自のハードウェアを使用してそれ自体でピクセルクロックを生成する)は、一実施形態では、ある期間にわたってサーバVSYNC信号311の周波数の粗い調節及び/または微細な調節を実行するように操作されることができ、サーバVSYNC信号311とクライアントのVSYNC信号312との間の周波数の同期をアライメント状態に戻す。
具体的には、サーバのサウスブリッジのピクセルクロックがオーバークロックまたはアンダークロックされ、サーバのVSYNC信号311の全体的な周波数を調整することができる。そのようにして、サーバVSYNC信号311の周波数は、クライアントとサーバのVSYNC信号311と312との間の周波数が実質的に同じ周波数になるように調整される。サーバとクライアントのVSYNC間のオフセットは、ピクセルクロックを元の値に戻す前に、クライアントサーバのピクセルクロックを短時間で増減することで調整されることができる。一実施形態では、サーバピクセルクロックが調整される。
別の実施形態では、クライアントピクセルクロックが調整される。さらに別の実施形態では、2つのデバイス(サーバ及びクライアント)の代わりに、複数の接続されたデバイスがあり、それらの各々は、調整されている対応するピクセルクロックを有し得る。一実施形態では、複数の接続されたデバイスの各々は、(例えば、サーバデバイスを伴わない)独立したピアデバイスであり得る。別の実施形態では、複数の接続されたデバイスは、1つ以上のサーバ/クライアントアーキテクチャ、マルチテナントサーバ/クライアント(複数可)アーキテクチャ、またはそれらのいくつかの組み合わせに配置された1つ以上のサーバデバイス及び1つ以上のクライアントデバイスを含み得る。
【0054】
一実施形態では、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシをさらに短縮するために高性能コーデック(例えば、エンコーダ及び/またはデコーダ)が使用され得る。圧縮メディアのストリーミングを伴う従来のストリーミングシステム(ストリーミング映画、テレビ番組、ビデオなど)では、エンドターゲット(例えば、クライアント)でストリーミングメディアを解凍するときに、解凍されたビデオのかなりの量をクライアントにおいてバッファリングして、エンコード操作で(例えばより長いエンコード時間)、伝送品質に侵入するジッター、デコード操作(例えば、より長いデコード時間)の変動に対処することが可能である。このように、従来のストリーミングシステムでは、デコードされたコンテンツがレイテンシ変動性に対処することから、平均的なデコード能力とメトリクス(例えば、平均的なデコードリソース)に依存することが可能であり、ビデオフレームが所望の速度で表示されること(例えば、60Hzで4Kメディアをサポートするか、クライアントVSYNC信号が生じるたびにビデオフレームを表示する)ができるようになっている。
【0055】
しかしながら、クラウドゲーミング環境ではバッファリングは非常に制限されており(例えば、ゼロバッファリングへの移行)、リアルタイムゲームが実現されることができるようになっている。その結果、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシに導入された変動性は、ダウンストリーム操作に悪影響を与え得る。例えば、複雑なフレームのエンコードやデコードに時間がかかると、(単一のフレームであっても)それに応じて一方向レイテンシが長くなり、最終的にユーザへの応答時間が長くなり、ユーザのリアルタイムエクスペリエンスに悪影響を及ぼす。
【0056】
一実施形態では、クラウドゲーミングの場合、ストリーミングビデオアプリケーションの必要性と比較した場合に不必要であると思われる、より強力なデコードリソース及びエンコードリソースを供給することが有益である。さらに、以下でさらに詳しく説明するように、エンコーダリソースは、長いか、または最も長い処理を必要とするフレームを処理するための時間に対して最適化される必要がある。つまり、エンコーダが、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するように調節されることができる実施形態では、エンコーダの調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたIフレームの数、シーン変化の数、及び/または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ(QP)値を含み得、高性能エンコーダ及びデコーダが、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減することを補助する。
【0057】
図2A図2Dの様々なクライアントデバイス210及び/またはクラウドゲーミングネットワーク290(例えば、ゲームサーバ260内)の詳細な説明と共に、図5のフロー図500は、本開示の一実施形態による、クラウドゲーミングの方法を示し、ビデオフレームのエンコードは、ネットワーク伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識したエンコーダパラメータの調節を含んでいる。クラウドゲーミングサーバは、ネットワークを介して1つ以上のクライアントデバイスにコンテンツをストリーミングするように構成されている。このプロセスは、よりスムーズなフレームレートと、より信頼性の高いレイテンシをもたらし、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが低減され、より一貫性があるようにされ、それによって、ビデオのクライアント表示のスムーズさを改善する。
【0058】
510では、クラウドゲーミングサーバでビデオゲームを実行するときに、複数のビデオフレームが生成される。一般に、クラウドゲーミングサーバは、複数のゲーム用にレンダリングされたビデオフレームを生成する。例えば、ビデオゲームのゲームロジックは、ゲームエンジンまたはゲームタイトル処理エンジンに基づいて構築されている。ゲームエンジンは、ビデオゲームのゲーム環境を構築するためにゲームロジックによって使用され得るコア機能を含んでいる。例えば、ゲームエンジンのいくつかの機能は、ゲーム環境内のオブジェクトに対する物理的な力と衝突をシミュレートするための物理エンジン、2Dまたは3Dグラフィックス用のレンダリングエンジン、衝突検出、サウンド、アニメーション、人工知能、ネットワーキング、ストリーミング、等を含み得る。そのようにして、ゲームロジックは、ゲームエンジンによって提供されるコア機能を最初から構築する必要はない。
【0059】
ゲームエンジンと組み合わせたゲームロジックは、CPU及びGPUによって実行され、CPU及びGPUは、加速処理装置(APU)内で構成できる。つまり、共有メモリと共にCPU及びGPUは、ゲーム用にレンダリングされたビデオフレームを生成するためのレンダリングパイプラインとして構成され得、レンダリングパイプラインが、目標化、及び/または仮想化された表示の各ピクセルに対して対応する色情報を含む、ゲーム用にレンダリングされた画像を表示に適したビデオまたは画像フレームとして出力するようになっている。
特に、CPUは、ビデオフレームに対して1つ以上のドローコールを生成するように構成され得、各ドローコールは、GPUパイプラインのGPUによって実行される対応するコマンドバッファに格納されたコマンドを含んでいる。一般に、グラフィックスパイプラインは、シーン内のオブジェクトの頂点に対してシェーダ操作を実行して、表示のピクセルのテクスチャ値を生成することができる。特に、グラフィックスパイプラインは、入力ジオメトリ(例えば、ゲーミング環境のオブジェクトの頂点)を受信し、頂点シェーダは、オブジェクトを構成するプリミティブまたはポリゴンを構築する。頂点シェーダプログラムは、プリミティブに対してライティング、シェーディング、シャドウイング、及びその他の操作を実行することができる。
深度バッファリングまたはZバッファリングは、対応する視点からレンダリングされたときに、どのオブジェクトが見えるかを判定するために実行される。ラスタライズは、3Dゲーム環境内のオブジェクトを視点によって定義された2D平面に投影するために実行される。ピクセルサイズのフラグメントがオブジェクトに対して生成され、1つ以上のフラグメントが、画像のピクセルの色に寄与することができる。フラグメントは、対応するビデオの各ピクセルの組み合わせられた色を決定するためにマージ及び/またはブレンドされることができ、フレームバッファ内に格納されることができる。後続のビデオフレームは、同様に構成されたコマンドバッファを使用して表示用に生成され、及び/またはレンダリングされ、複数のビデオフレームが、GPUパイプラインから出力されている。
【0060】
520では、本方法は、エンコーダビットレートで複数のビデオフレームをエンコードすることを含む。特に、複数のビデオフレームは、アプリケーション層で動作するストリーマを使用してクライアントにストリーミングする前に、圧縮されるエンコーダにスキャンされる。一実施形態では、ゲーム用にレンダリングされたビデオフレームの各々は、追加のユーザインターフェース機能で対応する改変されたビデオフレームに合成され、かつブレンドされ、次いでエンコーダにスキャンされることができ、このエンコーダは、改変されたビデオフレームを圧縮してクライアントにストリーミングする。
簡潔さと明確さのために、図5に開示されているエンコーダパラメータを調節する方法は、複数のビデオフレームをエンコードすることに関して説明されているが、改変されたビデオフレームをエンコードすることをサポートすると理解されている。エンコーダは、記述されたフォーマットに基づいて複数のビデオフレームを圧縮するように構成されている。例えば、クラウドゲーミングサーバからクライアントにメディアコンテンツをストリーミングするときに、モーションピクチャエキスパートグループ(MPEG)またはH.264標準が実装され得る。特に、エンコーダは、ビデオフレームによって、またはビデオフレームのエンコーダスライスによって圧縮を実行することができ、前述のように、各ビデオフレームは、1つ以上のエンコードされたスライスとして圧縮されることができる。一般に、メディアをストリーミングするとき、ビデオフレームは、Iフレーム(イントラフレーム)またはPフレーム(予測フレーム)として圧縮され、それらの各々が、エンコードされたスライスに分割されることができる。
【0061】
530では、クライアントの最大受信帯域幅が測定される。一実施形態では、クライアントが経験する最大帯域幅は、クライアントからのフィードバックメカニズムによって判定されている。図6は、本開示の一実施形態による、クラウドゲーミングサーバのストリーマによるクライアント210の帯域幅の測定を示しており、ストリーマ620は、エンコーダ610を監視及び調節するように構成されており、圧縮されたビデオフレームが、クライアントの測定された帯域幅の範囲内の速度で伝送され得るようになっている。
図示されるように、圧縮されたビデオフレーム、エンコードされたスライス、及び/またはパケットは、エンコーダ610からバッファ630(例えば、先入れ先出し-FIFO)へ配信される。エンコーダは、エンコーダ充填速度615で圧縮されたビデオフレームを配信する。例えば、バッファは、エンコーダが、圧縮されたビデオフレーム、エンコードされたスライス650、及び/またはエンコードされたスライスのパケット655を生成することができるのと同じ速さで充填され得る。さらに、圧縮されたビデオフレームは、ネットワーク250を介してクライアント210に配信するために、バッファ排出速度635でバッファから排出される。
一実施形態では、バッファ排出速度635は、クライアントの測定された最大受信帯域幅に動的に調節される。例えば、バッファ排出速度635は、クライアントの測定された最大受信帯域幅にほぼ等しくなるように調整され得る。一実施形態では、パケットのエンコードは、それらが伝送されるのと同じ速度で実行され、両方の操作は、クライアントが利用できる最大の利用可能な帯域幅に動的に調節されるようになっている。
【0062】
特に、アプリケーション層で動作するストリーマ620は、帯域幅テスター625を使用するなどして、クライアント210の最大帯域幅を測定する。アプリケーション層は、インターネットを介してネットワークデバイスを相互接続するために使用されるプロトコルのユーザデータグラムプロトコル/インターネットプロトコル(UDP/IP)スイートで使用される。例えば、アプリケーション層は、IP通信ネットワークを介したデバイス間の通信に使用される通信プロトコルとインターフェースメソッドを規定する。テスト中に、ストリーマ620は、追加のバッファリングされたパケット640(例えば、前方誤り訂正(FEC)パケット)を提供し、バッファ630が、テストされた最大帯域幅などの事前規定されたビットレートからパケットをストリーミングできるようになっている。
一実施形態では、クライアントは、フィードバック690として、ビデオフレームのある範囲などの、増分シーケンス識別子(ID)の範囲にわたって受信したパケットの数をストリーマ620に返す。例えば、クライアントは、シーケンスID100~250(例えば、150ビデオフレーム)で受信した150ビデオフレームのうち145のようなものを報告することができる。このように、サーバ260におけるストリーマ620は、パケット損失を計算することができ、ストリーマ620は、そのパケットのシーケンスの間に送信された(例えば、テストされた)帯域幅の量を知っているので、ストリーマ620は、クライアントの最大帯域幅が特定の時点で何であるか動的に判定することができる。
クライアントの測定された最大帯域幅は、制御情報627としてストリーマ620からバッファ630に配信され得、バッファ630は、クライアントの最大帯域幅にほぼ等しい速度でパケットを動的に伝送することができるようになっている。このように、圧縮されたビデオフレーム、エンコードされたスライス、及び/またはパケットの伝送速度は、現在測定されているクライアントの最大帯域幅に応じて動的に調整されることができる。
【0063】
540では、エンコーディングプロセスはストリーマによって監視されている。つまり、複数のビデオフレームのエンコードが監視される。一実施形態では、監視は、クライアント210で実行され、フィードバック及び/または調節制御信号がエンコーダに戻されるように提供されている。別の実施形態では、監視は、クラウドゲーミングサーブ260において、ストリーマ620などによって実行されている。例えば、ビデオフレームのエンコードの監視は、ストリーマ620の監視及び調節ユニット629によって実行され得る。様々なエンコーディング特性及び/または操作が、追跡及び/または監視されることができる。
例えば、一実施形態では、複数のビデオフレーム内のIフレームの発生率が、追跡及び/または監視されることができる。さらに、一実施形態では、複数のビデオフレーム内のシーン変化の発生率が、追跡及び/または監視されることができる。また、一実施形態では、目標フレームサイズを超えるビデオフレームの数が追跡及び/または監視されることができる。また、一実施形態では、1つ以上のビデオフレームをエンコードするために使用されるエンコーダビットレートが、追跡及び/または監視されることができる。
【0064】
550では、エンコーダのパラメータは、ビデオフレームのエンコーディングの監視に基づいて、動的に調節される。つまり、ビデオフレームのエンコーディングの監視は、エンコーダで受信される現在及び将来のビデオフレームを圧縮するときに、エンコーダがどのように動作するかに影響を及ぼす。特に、監視及び調整ユニット629は、ビデオフレームのエンコードの監視、及び監視された情報に対して実行される分析に応答して、どのエンコーダパラメータを調節すべきかを判定するように構成されている。制御信号621は、エンコーダを構成するために使用される監視及び調整ユニット629からエンコーダ610に返信される。調節のためのエンコーダパラメータには、量子化パラメータ(QP)(例えば、最小QP、最大QP)または品質パラメータ、目標フレームサイズ、最大フレームサイズ、などが含まれる。
【0065】
調節は、ネットワークの伝送速度及び信頼性、ならびに全体的なレイテンシ目標を認識して実行される。一実施形態では、ビデオ再生のスムーズさは、低レイテンシまたは画像品質よりも優先される。例えば、1つ以上のビデオフレームのエンコードのスキップは、無効になっている。具体的には、画像解像度または画像品質(60Hzなど)とレイテンシのバランスは、様々なエンコーダパラメータを使用して調節される。特に、クラウドゲーミングサーバ及びクライアントにおけるVSYNC信号は、同期及びオフセットされることができることから、クラウドゲーミングサーバとクライアント間の一方向レイテンシは、低減されることができ、それによって、低レイテンシを促進するためにビデオフレームをスキップする必要性が減少する。VSYNC信号の同期とオフセットはまた、クラウドゲーミングサーバにおける重複操作(スキャンアウト、エンコード、及び伝送)、クライアントにおける重複操作(受信、デコード、レンダリング、表示)、及び/またはクラウドゲーミングサーバとクライアントにおける重複操作も提供し、これらはすべて、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイムでの生成と表示、及びクライアントにおける一貫したビデオ再生を促進する。
【0066】
一実施形態では、エンコーダビットレートは、クライアント帯域幅に対する需要を予測するために、次に続くフレーム及びそれらの複雑性(例えば、予測されるシーン変化)を考慮して監視され、ここでエンコーダビットレートは、予想される需要に従って調整されることができる。例えば、ビデオ再生のスムーズさを優先するとき、エンコーダ監視及び調節ユニット629は、使用されるエンコーダビットレートが、測定されている最大受信帯域幅を超えていると判定するように構成され得る。それに応じて、エンコーダビットレートは低減されることができ、フレームサイジングもまた低減されることができるようになっている。
スムーズさを優先する場合、最大受信帯域幅よりも低いエンコーダビットレート(例えば、15メガビット/秒の最大受信帯域幅に対して10メガビット/秒のエンコーダビットレート)を使用することが望ましい。そのようにして、エンコードされたフレームが最大フレームサイズを超えてスパイクした場合でも、エンコードされたフレームは、依然として60Hz(ヘルツ)以内で送信されることができる。特に、エンコーダビットレートは、フレームサイズに変換され得る。ビデオゲームの所定のビットレート及び目標速度(例えば、毎秒60フレーム)は、エンコードされたビデオフレームの平均サイズに変換される。例えば、15メガビット/秒のエンコーダビットレート、及び60フレーム/秒の所定の目標速度では、60個のエンコードされたフレームが、15メガビットを共有し、各エンコードされたフレームが、約250k個のエンコードされたビットを有するようになっている。
このように、エンコーダビットレートを制御することはまた、エンコードされたビデオフレームのフレームサイズも制御し、その結果、エンコーダビットレートを増加すると、エンコード用のビットが多くなり(精度が高くなる)、また、エンコーダビットレートを低減すると、エンコード用のビットが少なくなる(精度が低くなる)。同様に、ビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、測定されている最大受信帯域幅内にあるとき、エンコーダビットレートは増加されることができ、フレームサイズもまた、増加されることができるようになっている。
【0067】
一実施形態では、ビデオ再生のスムーズさを優先する場合、エンコーダ監視及び調節ユニット629は、複数のビデオフレームからビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、測定されている最大受信帯域幅を超えているかを判定するように構成され得る。例えば、エンコーダビットレートは、15メガビット/秒(Mbps)であると検出されることができ、一方で、最大受信帯域幅は、現在10Mbpsであることができる。このようにして、エンコーダは、一方向レイテンシを増加させることなく、クライアントに送信できるよりも多くのビットをプッシュアウトする。
前述したように、スムーズさを優先する場合、最大受信帯域幅よりも低いエンコーダビットレートを使用することが望ましくなり得る。上の例では、上で紹介した10メガビット/秒の最大受信帯域幅に対して10メガビット/秒以下に設定したエンコーダビットレートを有することが許容可能となり得る。そのようにして、エンコードされたフレームが最大フレームサイズの上にスパイクする場合、エンコードされたフレームは、依然として60Hz以内で送信されることができる。それに応じて、QP値は、エンコーダビットレートの低減をしても、低減しなくても調節されることができ、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。
つまり、QPは、実行される量子化の量を制御する(例えば、ビデオフレーム内の値の可変範囲を単一量子値に圧縮する)。H.264では、QPの範囲は「0」から「51」である。例えば、「0」のQP値は、量子化がより少なく、圧縮がより少なく、精度がより高く、品質がより高いことを意味する。例えば、「51」のQP値は、量子化がより少なく、圧縮がより少なく、精度がより高く、品質がより高いことを意味する。具体的には、QP値が増加されることができ、ビデオフレームのエンコードが、より低い精度で実行されるようになっている。
【0068】
一実施形態では、ビデオ再生のスムーズさを優先するとき、監視及び調節ユニット629によるエンコーダ監視は、複数のビデオフレームからのビデオフレームのグループをエンコードするために使用されるエンコーダビットレートが、最大受信帯域幅内にあることを判定するように構成され得る。以前に紹介したように、スムーズさを優先するとき、最大受信帯域幅よりも低いエンコーダビットレートを使用することが望ましくなり得る。このように、ビデオフレームのグループを送信するときに利用可能な超過帯域幅がある。超過帯域幅が判定されることができる。それに応じて、QP値は調節されることができ、ここで、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、QP値は、超過帯域幅に基づいて低減されることができ、エンコードがより正確に実行されるようになっている。
【0069】
別の実施形態では、個々のビデオゲームの特性は、Iフレーム処理及びQP設定を決定するときに、特にビデオ再生のスムーズさを優先するときに考慮される。例えば、ビデオゲームの「シーン変化」が頻繁に行われない場合(例えば、カメラカットのみ)、Iフレームをより大きくすることが望ましくなり得る(QPがより低いか、エンコーダビットレートがより高い)。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、シーン変化を有していると識別されたビデオフレームの数は、シーン変化の閾値数よりも少ないと判定される。つまり、ストリーミングシステムは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など)のシーン変化の数を処理できる。それに応じて、QP値は調節されることができ、ここで、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、QP値は、エンコードがより高い精度で実行されるように、低減されることができる。
【0070】
一方で、ビデオゲームでゲームプレイ中に頻繁に「シーン変化」が発生する場合は、Iフレームサイズを小さく保つことが望ましくなり得る(例えば、QPをより高くするか、エンコーダビットレートをより低くする)。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、シーン変化を有していると識別されたビデオフレームの数は、シーン変化の閾値数を満たすか、または超えると判定される。つまり、ビデオゲームは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など)に対して多過ぎるシーン変化を生成している。それに応じて、QP値は調節されることができ、ここで、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、QP値は、エンコードがより低い精度で実行されるように、増加されることができる。
【0071】
別の実施形態では、Iフレーム処理及びQP設定を決定するとき、特にビデオ再生のスムーズさを優先するときに、エンコードパターンが考慮され得る。例えば、エンコーダのIフレームの生成頻度が低い場合は、Iフレームを大きくすることが望ましくなり得る(QPが低いか、エンコーダビットレートがより高い)。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、Iフレームとして圧縮されるビデオフレームの数は、Iフレームの閾値数内にあるか、またはそれより少ない。つまり、ストリーミングシステムは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等)のIフレームの数を処理できる。それに応じて、QP値は調節されることができ、ここで、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、QP値は、エンコードがより高い精度で実行されるように、低減されることができる。
【0072】
エンコーダが頻繁にIフレームを生成する場合は、Iフレームサイズを小さく保つことが望ましくなり得る(例えば、QPを高くするか、エンコーダビットレートをより低くする)。つまり、圧縮されている複数のビデオフレームからのビデオフレームのグループ内で、Iフレームとして圧縮されるビデオフレームの数は、Iフレームの閾値数内にあるか、またはそれを超える。つまり、ビデオゲームは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、など)に対して多過ぎるIフレームを生成している。それに応じて、QP値は調節されることができ、ここで、QPは、ビデオフレームを圧縮するときに使用される精度を制御する。特に、QP値は、エンコードがより低い精度で実行されるように、増加されることができる。
【0073】
別の実施形態では、エンコーダを回すとき、特にビデオ再生のスムーズさを優先するとき、エンコードパターンが考慮され得る。例えば、エンコーダが頻繁に目標フレームサイズを下回る場合は、目標フレームサイズをより大きくすることが望ましくなり得る。つまり、圧縮されて伝送速度で送信される複数のビデオフレームからのビデオフレームのグループ内で、ビデオフレームの数が閾値よりも低くなると判定される。ビデオフレームの数の各々は、目標フレームサイズ内にある(すなわち、目標フレームサイズと等しいか、小さい)。それに応じて、目標フレームサイズと最大フレームサイズのうちの少なくとも1つが増加する。
【0074】
一方で、エンコーダが頻繁に目標フレームサイズを超える場合は、目標フレームサイズを小さくすることが望ましくなり得る。つまり、圧縮されて伝送速度で送信される複数のビデオフレームからのビデオフレームのグループ内で、ビデオフレームの数が閾値を満たすか、または超えるかが、判定される。ビデオフレームの数の各々は、目標フレームサイズを超えている。それに応じて、目標フレームサイズ及び最大フレームサイズのうちの少なくとも1つが低減される。
【0075】
図7Aは、本開示の一実施形態による、クライアントにおける品質及びバッファ利用を最適化するためのエンコーダの量子化パラメータ(QP)の設定を示す図である。グラフ720Aは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ(バイト単位)を示している。目標フレームサイズと最大フレームサイズは静的である。特に、ライン711は最大フレームサイズを示し、ライン712は目標フレームサイズを示しており、最大フレームサイズは目標フレームサイズよりも大きくなっている。グラフ720Aに示されるように、ライン712の目標フレームサイズを超える圧縮されたビデオフレームを含む複数のピークが存在する。目標フレームサイズを超えるビデオフレームは、クラウドゲーミングサーバからのエンコード及び/または送信に対して複数のフレーム期間を要し得ることから、再生ジッターをもたらすリスク(例えば、一方向レイテンシの増加)がある。
【0076】
グラフ700Bは、クライアントにおけるエンコードの品質とバッファ利用を最適化するための、目標フレームサイズ、最大フレームサイズ、QP範囲(最小QPや最大QPなど)に基づいてQPが設定された後のエンコーダ応答を示す。例えば、QPは、前述のように、エンコーダビットレートのエンコーダ監視、シーン変化の頻度、及びIフレーム生成の頻度に基づいて調整及び/または調節され得る。グラフ700Bは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ(バイト単位)を示している。
ライン712の目標フレームサイズ及びライン711の最大フレームサイズは、グラフ700Aにあるものと同じ位置のままである。QP調節及び/または調整の後、グラフ700Aと比較すると、ライン712の目標フレームサイズを超える圧縮されたビデオフレームを含むピーク数が減少する。つまり、QPは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等)に対してビデオフレームのエンコードを最適化する(すなわち、目標フレームサイズ内に収まる)ために調節されている。
【0077】
図7Bは、本開示の一実施形態による、クライアントによってサポートされる真の目標フレームサイズを超えるIフレームの発生を低減するための、目標フレームサイズ、最大フレームサイズ、及び/またはQP(例えば、最小QP及び/または最大QP)エンコーダ設定の調節を示す図である。例えば、QPは、前述のように、エンコーダビットレートのエンコーダ監視、シーン変化の頻度、及びIフレーム生成の頻度に基づいて調整及び/または調節され得る。
【0078】
グラフ720Aは、水平方向に示されているように、生成された各フレームに対する垂直方向のフレームサイズ(バイト単位)を示している。例示のために、図7Bの720A及び図7Aのグラフ700Aは、類似のエンコーダ状態を反映することができ、エンコーダ調節に使用される。グラフ720Aでは、目標フレームサイズと最大フレームサイズは静的である。特に、ライン711は最大フレームサイズを示し、ライン712は目標フレームサイズを示しており、最大フレームサイズは目標フレームサイズよりも大きくなっている。
グラフ720Aに示されるように、ライン712の目標フレームサイズを超える圧縮されたビデオフレームを含む複数のピークが存在する。目標フレームサイズを超えるビデオフレームは、クラウドゲーミングサーバからのエンコード及び/または送信に対して複数のフレーム期間を要し得ることから、再生ジッターをもたらすリスク(例えば、一方向レイテンシの増加)がある。例えば、ライン711で最大フレームサイズに達するピークは、クライアントに送信されるまでに16ミリ秒以上かかるIフレームであり得、このことが、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシを増加させることによる再生ジッターを生じさせる。
【0079】
グラフ720Bは、クライアントによってサポートされる真の目標フレームサイズを超えるIフレームの発生を低減するために、目標フレームサイズ及び/または最大フレームサイズのうちの少なくとも1つが調節された後のエンコーダ応答を示している。真の目標フレームサイズは、前述のように、測定されるクライアント帯域幅、及び/またはエンコーダビットレート、シーン変化の頻度、及びIフレーム生成の頻度の監視を含むエンコーダ監視に基づいて調整され得る。
【0080】
グラフ720Bは、水平方向に示されるように、生成された各フレームに対する垂直方向のフレームサイズ(バイト単位)を示している。グラフ720Aと比較すると、ライン712’の目標フレームサイズとライン711’の最大フレームサイズの値が低くなっている。例えば、ライン712’の目標フレームサイズは、ライン712から値が小さくなっており、ライン711’の最大フレームサイズは、ライン711から値が小さくなっている。
目標フレームサイズ及び/または最大フレームサイズを調節した後、目標フレームサイズ712’を超えて圧縮されたビデオフレームのピークの最大サイズは、より良い送信のために縮小されている。さらに、グラフ700Aと比較した場合、目標フレームサイズ712’を超える圧縮されたビデオフレームを含むピークの数もまた減少した。例えば、グラフ720Bに示されているピークは1つだけである。つまり、目標フレームサイズ及び/または最大フレームサイズは、現在の状態(例えば、測定されたクライアント帯域幅、必要とされるレイテンシ、等)に対してビデオフレームのエンコーディングを最適化する(すなわち、目標フレームサイズ内に収まる)ために調節されている。
【0081】
図2A図2Dの様々なクライアントデバイス210及び/またはクラウドゲーミングネットワーク290(例えば、ゲームサーバ260内)の詳細な説明とともに、図8のフロー図800は、本開示の一実施形態による、クラウドゲーミングの方法を示しており、ビデオフレームのエンコードは、エンコードが長い場合、または生成されるビデオフレームが大きい場合(Iフレームをエンコードする場合など)に、ビデオフレームをいつスキップするか、またはビデオフレームのエンコード及び送信をいつ遅らせるか、を決定することを含む。
特に、ビデオフレームをスキップする決定は、ネットワーク伝送速度と信頼性、及び全体的なレイテンシ目標を考慮して行われる。このプロセスは、よりスムーズなフレームレートと、より信頼性の高いレイテンシをもたらし、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが低減され、より一貫性があるようにされ、それによって、ビデオのクライアント表示のスムーズさを改善する。
【0082】
810では、ストリーミングモードで動作するクラウドゲーミングサーバにおいて、ビデオゲームを実行するときに、複数のビデオフレームが生成されている。一般に、クラウドゲーミングサーバは、複数のゲーム用にレンダリングされたビデオフレームを生成する。例えば、ゲーム用にレンダリングされたビデオフレームの生成は、図5の510で説明されており、図8のビデオフレームの生成に適用可能である。
例えば、ビデオゲームのゲームロジックは、ゲームエンジンまたはゲームタイトル処理エンジンに基づいて構築されている。ゲームエンジンと組み合わせたゲームロジックは、CPU及びGPUによって実行され、共有メモリとともにCPU及びGPUは、ゲーム用にレンダリングされたビデオフレームを生成するためのレンダリングパイプラインとして構成され得、レンダリングパイプラインが、ゲーム用にレンダリングされた画像を目標の、及び/または仮想化された表示のピクセルの各々に対応する色情報を含む、表示に適したビデオまたは画像フレームとして出力するようになっている。
【0083】
820において、シーン変化は、ビデオゲームの第1のビデオフレームに対して予測され、シーン変化は、第1のビデオフレームが生成される前に予測されている。一実施形態では、ゲームロジックは、CPUがビデオゲームを実行している間のシーン変化を認識させることができる。例えば、ゲームロジックまたはアドオンロジックは、コード(例えば、シーン変化ロジック)を含むことができ、これは、ビデオフレームの範囲が少なくとも1つのシーン変化を含むと予測すること、または特定のビデオフレームがシーン変化であると予測することなど、ビデオフレームを生成するときにシーン変化を予測する。
特に、シーン変化予測のために構成されたゲームロジックまたはアドオンロジックは、ビデオゲームの実行中に収集されたゲーム状態データを分析して、次のXフレーム数(例えば、範囲)内で、または識別されたビデオフレームに対して、など、いつシーン変化があるかを判定し、及び/または事前察知し、及び/または予測する。例えば、シーン変化は、仮想化ゲーム環境で、いつキャラクタが、あるシーンから別のシーンに移動するか、またはビデオゲームにおいて、いつキャラクタがレベルを終了し、別のレベルに移行するか、2つのビデオフレーム(例えば、映画的シーケンスでのシーンカット、または一連のメニューの後のインタラクティブなゲームプレイの開始)間でいつ移行するか、が予測されることができ、シーン変化は、仮想化ゲーム世界または環境の大きくて複雑なシーンを含む、ビデオフレームによって表され得る。
【0084】
ゲーム状態データは、その時点でのゲームの状態を定義することができ、ゲームキャラクタ、ゲームオブジェクト、ゲームオブジェクト属性、ゲーム属性、ゲームオブジェクト状態、グラフィックオーバーレイ、プレイヤーのゲームプレイのゲーム世界内のキャラクタの場所、ゲームプレイのシーンまたはゲーム環境、ゲームアプリケーションのレベル、キャラクタの資産(例えば、武器、ツール、爆弾など)、ロードアウト、キャラクタのスキルセット、ゲームレベル、キャラクタ属性、キャラクタの場所、残存ライフ数、利用可能なライフの総数、鎧、トロフィー、時間カウンター値、及びその他の資産情報、等を含むことができる。
【0085】
830において、シーン変化ヒントが生成され、シーン変化ヒントがエンコーダに送信され、このヒントは、第1のビデオフレームがシーン変化であることを示す。このように、次のシーン変化の通知が、エンコーダに提供され得、エンコーダは、識別されたビデオフレームを圧縮するときにそのエンコード操作を調整することができる。シーン変化ヒントとして提供される通知は、構成要素間で、またはクラウドゲーミングサーバ260の構成要素上で実行されているアプリケーション間で、通信するために使用されるAPIを介して配信され得る。
一実施形態では、APIはGPU APIであり得る。例えば、APIは、エンコーダと通信するためにシーン変化を検出するように構成されたゲームロジック及び/またはアドオンロジック上で実行されているか、またはそれらによって呼び出され得る。
一実施形態では、シーン変化ヒントは、データ制御パケットを受信するすべての構成要素が、どのタイプの情報がデータ制御パケットに含まれているかを理解することができ、対応するレンダリングされたビデオフレームへの適切な基準を理解することができるようにフォーマットされたデータ制御パケットとして提供され得る。
一実施態様では、APIに対して使用される通信プロトコル、データ制御パケットに対するフォーマットは、ビデオゲームのための対応するソフトウェア開発キット(SDK)で定義され得る。
【0086】
840において、第1のビデオフレームをエンコーダに配信する。前述のように、ゲームで生成されたビデオフレームは、追加のユーザインターフェース機能と合成され得、かつブレンドされ得、エンコーダにスキャンされる変更されたビデオフレームになる。エンコーダは、クラウドゲーミングサーバからクライアントへのメディアコンテンツのストリーミングに使用されるMPEGまたはH.264標準など、所望のフォーマットに基づいて、第1のビデオフレームを圧縮するように構成されている。
ストリーミングするとき、シーン変化があるまで、または現在エンコードされているフレームが、キーフレーム(例えば、以前のIフレーム)を参照できなくなるまで、ビデオフレームはPフレームとしてエンコードされ、次のビデオフレームが、次いで別のIフレームとしてエンコードされるようになっている。この場合、第1のビデオフレームは、シーン変化ヒントに基づいてIフレームとしてエンコードされ、Iフレームは、他のいずれのビデオフレーム(例えば、キー画像としてのスタンドアロン)を参照することなくエンコードされ得る。
【0087】
850では、クライアントの最大受信帯域幅が測定される。前述のように、クライアントが経験する最大帯域幅は、図5及び図6の操作530に示されるように、クライアントからのフィードバックメカニズムの手段によって、判定され得る。特に、クラウドゲーミングサーバのストリーマは、クライアントの帯域幅を測定するように構成されることができる。
【0088】
860において、エンコーダは第2のビデオフレームを受信する。つまり、第2のビデオフレームは、シーン変化の後に受信され、第1のビデオフレームが圧縮された後に圧縮される。また、第2のビデオフレーム(または後続のビデオフレーム)をエンコードしないか、または第2のビデオフレーム(または後続のビデオフレーム)のエンコードを遅らせるかのいずれかが、エンコーダによって決定される。この決定は、クライアントの最大受信帯域幅とクライアントディスプレイの目標解像度に基づいて行われる。つまり、エンコードをスキップするか、または遅延するかの決定は、クライアントが利用できる帯域幅を考慮する。
一般に、クライアントが経験する現在の帯域幅が十分である場合、クライアントの目標ディスプレイ用に生成及びエンコードされたビデオフレームが、レイテンシヒットを受けた(例えば、シーン変化用に大きなIフレームを生成)後、早急に低い一方向レイテンシに戻ることができ、第2のビデオフレーム(及び/または後続のビデオフレーム)は、依然として遅延を伴ってエンコードされ得る。
一方、クライアントが経験する現在の帯域幅が十分でない場合、第2のビデオフレーム(及び/または後続のビデオフレーム)は、エンコードプロセス中にスキップされ、クライアントに配信されない場合がある。このように、クライアントへの帯域幅が、クライアントでのディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より少ないスキップされるフレーム(及びより低いレイテンシ)を有することが可能である。
【0089】
一実施形態では、圧縮されたビデオフレームは、特定の時点で、ネットワークを介して利用可能な最大ビットレートまたは帯域幅に基づくレートでサーバからクライアントに送信される。このように、圧縮されたビデオフレームのエンコードされたスライス及び/またはエンコードされたスライスのパケットの伝送速度は、現在測定されている最大帯域幅に従って動的に調整される。ビデオフレームは、ビデオフレームがエンコードされるときに送信され得、サーバVSYNC信号の次の発生を待たずに、またビデオフレーム全体がエンコードされるのを待たずに、エンコードが完了するとすぐに送信が行われるようになっている。
【0090】
さらに、一実施形態では、パケットのエンコードは、それらが送信されるのと同じ速度で実行され、両方の操作が、クライアントが利用できる最大の利用可能帯域幅に動的に調節されるようになっている。また、エンコーダビットレートは、クライアント帯域幅の需要を予測するために、次のフレームとその複雑さ(例えば、予測されるシーン変化)を考慮して監視されることができ、エンコーダビットレートは、予測される需要に従って調整されることができる。さらに、エンコーダビットレートは、クライアントに通信されることができるので、クライアントは、エンコーダビットレートに一致するように、それに応じてデコード速度を調整することができるようになっている。
【0091】
一実施形態では、クライアントへの伝送速度がクライアントディスプレイの目標解像度に対して低いとき、第2のビデオフレームはエンコーダによってスキップされる。つまり、第2のビデオフレームはエンコードされない。特に、圧縮されたビデオフレームのグループに対するクライアントへの伝送速度は、最大受信帯域幅を超えている。例えば、クライアントへの伝送速度は、15メガバイト/秒(Mbps)であることができるが、クライアントの測定された受信帯域幅は、現在5~10Mbpsであることができる。このように、すべてのビデオフレームが継続的にクライアントにプッシュされる場合、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシが増加する。低遅延を促進するために、2番目以降のビデオフレームはエンコーダによってスキップされることができる。
【0092】
図9Aは、本開示の一実施形態による、エンコーダによって圧縮されているビデオフレームのシーケンス900Aを示し、エンコーダは、クライアント帯域幅がクライアントのディスプレイの目標解像度に対して低いとき、第1のIフレーム905をエンコードした後に、第2のビデオフレーム920のエンコードをドロップする。ビデオフレームのエンコードブロック及び伝送ブロックが、VSYNC信号950に関連して示されている。特に、余分な帯域幅が利用できないとき、エンコードにより時間がかかるIフレームは、1つ以上のスキップされたフレームが、一方向レイテンシを低く抑えるようにさせ、一方向レイテンシは、クライアントにおいて、ビデオフレームを表示する時間を含み得る。
図示されるように、Iフレームの後に1つ以上のビデオフレームをスキップすると、低い一方向レイテンシにすぐに戻ることを可能にする(例えば、1つまたは2つのフレーム期間内)。そうでない場合、ビデオフレームのエンコードをスキップしないことにより、低い一方向レイテンシに戻るまでに数フレーム期間を要することになる。
【0093】
例えば、ビデオフレームのシーケンス900Aは、1つのエンコードされたIフレーム905を含み、残りのフレームは、Pフレームとしてエンコードされている。説明のために、Pフレームとしてのエンコードブロック901及びエンコードブロック902が、Iフレームとしてエンコードされたエンコードブロック905の前に、エンコードされている。
その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム(Iフレームなど)を参照できなくなるまで、ビデオフレームをPフレームとして圧縮する。一般的に、Iフレームブロックのためのエンコード時間は、Pフレームブロックよりも長くかかることがある。例えば、Iフレームブロック905のエンコード時間は、1フレーム期間を超え得る。場合によっては、PフレームとIフレームとの間のエンコード時間は、特に高出力のエンコーダを使用する場合、一般的に、ほぼ同じになり得る。
【0094】
しかしながら、IフレームとPフレームとの間の送信時間は大きく異なる。図示されているように、様々な送信時間が、対応するエンコードされたビデオフレームに関連して示されている。例えば、エンコードされたPフレームブロック901の伝送ブロック911は、低レイテンシで示され、エンコードブロック901及び伝送ブロック911が、1フレーム期間内に実行され得るようになっている。また、エンコードされたPフレームブロック902の伝送ブロック912は、低い一方向レイテンシとともに示され、エンコードブロック902及び伝送ブロック912もまた、1フレーム期間内に実行され得るようになっている。
【0095】
一方で、エンコードされたIフレームブロック905の伝送ブロック915Aは、より高い一方向レイテンシと共に示され、エンコードブロック905及び伝送ブロック915Aは、いくつかのフレーム期間にわたって発生し、それによって、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターを導入するようになっている。一方向レイテンシが少なくなるようにユーザにリアルタイムのエクスペリエンスを提供するために、クライアントにおけるバッファは、ジッターを修正するために使用され得ない。その場合、エンコーダは、Iフレームがエンコードされた後に、1つ以上のビデオフレームのエンコードをスキップすることを決定することができる。
例えば、ビデオフレーム920は、エンコーダによってドロップされる。その場合、エンコードされたビデオフレームの送信は、5つの後続のビデオフレームが、Pフレームとしてエンコードされて、クライアントに送信された後のように、ハイライトされた領域910の周りの低い一方向レイテンシの1つに戻る。つまり、Iフレームブロック905がエンコードされた後にエンコードされた第4または第5のPフレームもまた、同じフレーム期間内でクライアントに送信され、それによって、クラウドゲーミングサーバとクライアントとの間の低い一方向レイテンシに戻る。
【0096】
一実施形態において、クライアントへの伝送速度が、クライアントディスプレイの目標解像度に対して高い場合、第2のビデオフレームは、遅延後も依然としてエンコーダによって圧縮される(すなわち、Iフレームがエンコードされるまで待機する)。特に、圧縮されたビデオフレームのグループのクライアントに対する伝送速度は、最大受信帯域幅の範囲内である。例えば、クライアントへの伝送速度は、13メガバイト/秒(Mbps)であり得るが、クライアントの測定された受信帯域幅は、現在15Mbpsであり得る。このように、クライアントにおけるエンコードされたビデオフレームの受信において、遅延が発生しないため、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシの増加はない。
【0097】
さらに、クラウドゲーミングサーバとクライアントにおいてVSYNC信号が同期及びオフセットされることができるため、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシは、低減されることができ、それによって、ネットワークを介した送信中にサーバにおいて、またはクライアントにおいて、ジッターによって生じたレイテンシの変動性を補正する。
また、VSYNC信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作(スキャンアウト、エンコード、及び送信)、クライアントでの重複操作(受信、デコード、レンダリング、表示)、及び/またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされるレイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。
【0098】
図9Bは、エンコーダによって圧縮されているビデオフレームのシーケンス900Bを示しており、エンコーダは、クライアントに利用可能な帯域幅を考慮に入れており、その結果、本開示の一実施形態によれば、帯域幅が、クライアントディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より低いレイテンシを有すると同時に、スキップされたフレームを有さないか、より少なくすることが可能であるようになっている。
特に、シーケンス900Bでは、ビデオフレームはIフレームとしてエンコードされ、後続のビデオフレームもまた正常にエンコードされ、クライアント帯域幅がクライアントディスプレイの目標解像度に対して中適度であるとき、Iフレームのエンコードの遅延後にエンコードされる。中程度の帯域幅の可用性があるため、中適度の量の超過帯域幅が、クラウドゲーミングサーバとクライアント間のレイテンシの変動性(例えば、ジッター)を補正するために利用可能であり、その結果、フレームスキップが回避されることができ、低い一方向レイテンシへの回帰が比較的迅速に(例えば、2つ~4つのフレーム期間内で)達成され得るようになっている。ビデオフレームのエンコードブロック及び伝送ブロックが、VSYNC信号950に関連して示されている。
【0099】
ビデオフレームのシーケンス900Bは、1つのエンコードされたIフレーム905を含み、残りのフレームは、Pフレームとしてエンコードされている。例示のために、Pフレームとしてのエンコードブロック901及びエンコードブロック902が、エンコードブロック905がIフレームとしてエンコードされる前に、エンコードされている。その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム(Iフレームなど)を参照できなくなるまで、ビデオフレームをPフレームとして圧縮する。一般に、Iフレームブロックのエンコード時間は、Pフレームブロックより長くかかり得、Iフレームの送信は、1フレーム期間より長くかかり得る。例えば、Iフレームブロック905に対するエンコード時間及び送信時間は、1フレーム期間を超えている。
また、対応するエンコードされたビデオフレームに関連して様々な送信時間が表示されている。例えば、Iフレームブロック905の前のビデオフレームのエンコード及び送信は、低い一方向レイテンシを有して示され、その結果、対応するエンコード及び伝送ブロックが、1フレーム期間内に実行され得るようになっている。しかしながら、エンコードされたIフレームブロック905の伝送ブロック915Bは、より高い一方向レイテンシで示されており、その結果、エンコードブロック905及び伝送ブロック915Bは、2つ以上のフレーム期間にわたって発生し、それにより、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターをもたらす。
前述したように、1つ以上のエンコーダパラメータ(例えば、QP、目標フレームサイズ、最大フレームサイズ、エンコーダビットレートなど)を調節することにより、エンコード時間はさらに短縮され得る。つまり、Iフレームの後の第2の、または後続のビデオフレームは、クライアントへの伝送速度がクライアントディスプレイの目標解像度に対して中程度のとき、より低い精度でエンコードされており、また、伝送速度が目標解像度に対して高いときより低い精度でエンコードされている。
【0100】
Iフレームブロック905の後、エンコーダは、ビデオフレームの圧縮を継続するが、Iフレームのエンコードにより、それらは一時的に遅延することがある。この場合も、VSYNC信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作(スキャンアウト、エンコード、及び伝送)、クライアントでの重複操作(受信、デコード、レンダリング、表示)、及び/またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされる一方向レイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。
【0101】
クライアント帯域幅はクライアントディスプレイの目標解像度に関して中程度であるため、エンコードされたビデオフレームの伝送は、2つまたは3つの後続のビデオフレームがPフレームとしてエンコードされ、クライアントに伝送された後など、強調表示された領域940周辺の低い一方向レイテンシの1つに戻る。領域940内で、Iフレームブロック905がエンコードされた後にエンコードされたPフレームもまた、同じフレーム期間内にクライアントに伝送され、それにより、クラウドゲーミングサーバとクライアントとの間で低い一方向レイテンシに戻る。
【0102】
図9Cは、エンコーダによって圧縮されているビデオフレームのシーケンス900Cを示し、エンコーダは、クライアントに利用可能な帯域幅を考慮しており、本開示の一実施形態によれば、帯域幅が、クライアントディスプレイの目標解像度をサポートするために必要な帯域幅を超える場合、より低い一方向レイテンシを依然として有しながら、スキップされたフレームがないか、より少ないスキップされたフレームを有することが可能であるようになっている。特に、シーケンス900Cでは、ビデオフレームはIフレームとしてエンコードされ、後続のビデオフレームもまた正常にエンコードされ、クライアント帯域幅が、クライアントディスプレイの目標解像度に対して高い場合、Iフレームのエンコードの遅延後にエンコードされる。
高い帯域幅の可用性があるため、大量の超過帯域幅が、クラウドゲーミングサーバとクライアント間の一方向レイテンシの変動性(例えば、ジッター)を補正するために利用可能であり、その結果、フレームスキップが回避されることができ、低い一方向レイテンシへの回帰が、迅速に(例えば、1つ~2つのフレーム期間内で)達成され得るようになっている。ビデオフレームのエンコードブロック及び伝送ブロックが、VSYNC信号950に関連して示されている。
【0103】
図9Bと同様に、図9Cのビデオフレームのシーケンス900Cは、1つのエンコードされたIフレーム905を含み、残りのフレームは、Pフレームとしてエンコードされている。例示のために、Pフレームとしてのエンコードブロック901及びエンコードブロック902が、エンコードブロック905がIフレームとしてエンコードされる前に、エンコードされている。その後、エンコーダは、次のシーン変化まで、またはビデオフレームが以前のキーフレーム(Iフレームなど)を参照できなくなるまで、ビデオフレームをPフレームとして圧縮する。一般的に、Iフレームブロックのためのエンコード時間は、Pフレームブロックよりも長くかかることがある。例えば、Iフレームブロック905のエンコード時間は、1フレーム期間を超え得る。
また、対応するエンコードされたビデオフレームに関連して様々な伝送時間が表示されている。例えば、Iフレームブロック905の前のビデオフレームのエンコード及び伝送は、低いレイテンシを有して示され、その結果、対応するエンコード及び伝送ブロックが、1フレーム期間内に実行され得るようになっている。しかしながら、エンコードされたIフレームブロック905の伝送ブロック915Cは、より高いレイテンシで示されており、その結果、エンコードブロック905及び伝送ブロック915Cは、2つ以上のフレーム期間にわたって発生し、それにより、クラウドゲーミングサーバとクライアントとの間の一方向レイテンシにジッターをもたらす。前述したように、1つ以上のエンコーダパラメータ(例えば、QP、目標フレームサイズ、最大フレームサイズ、エンコーダビットレートなど)を調節することにより、エンコード時間はさらに短縮され得る。
【0104】
Iフレームブロック905の後、エンコーダは、ビデオフレームの圧縮を継続するが、Iフレームのエンコードにより、それらは一時的に遅延することがある。この場合も、VSYNC信号の同期とオフセットは、クラウドゲーミングサーバでの重複操作(スキャンアウト、エンコード、及び送信)、クライアントでの重複操作(受信、デコード、レンダリング、表示)、及び/またはクラウドゲーミングサーバとクライアントでの重複操作を提供し、これらのすべてが、サーバまたはネットワークまたはクライアントのジッターによってもたらされるレイテンシの変動性に対する補償、一方向レイテンシの低減、一方向レイテンシの変動性の低減、ビデオコンテンツのリアルタイム生成と表示、及びクライアントでの一貫したビデオ再生を促進する。
クライアント帯域幅はクライアントディスプレイの目標解像度に対して高いため、エンコードされたビデオフレームの伝送は、1つまたは2つの後続のビデオフレームがPフレームとしてエンコードされ、クライアントに伝送された後など、強調表示された領域970周辺の低い一方向レイテンシの1つに戻る。領域970内で、Iフレームブロック905がエンコードされた後にエンコードされたPフレームもまた、(これらはVSYNC信号の発生の両側にまたがるが)1フレーム期間内にクライアントに伝送され、それにより、クラウドゲーミングサーバとクライアントとの間で低い一方向レイテンシに戻る。
【0105】
図10は、本開示の様々な実施形態の態様を実行するために使用されることができる例示的なデバイス1000の構成要素を示している。例えば、図10は、メディアコンテンツのストリーミング及び/またはストリーミングされたメディアコンテンツの受信に適した例示的なハードウェアシステムを示しており、レイテンシを低減し、クラウド間のより一貫したレイテンシを提供する目的のために、また、ビデオのクライアントディスプレイのスムーズさを改善するために、クラウドゲーミングシステムにおける一方向レイテンシとビデオ品質との間のトレードオフを改善するエンコーダ調節を提供することを含み、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたIフレームの数、シーン変化の数、及び/または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ(QP)値を含み得、本開示の実施形態によると、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。
このブロック図は、デバイス1000を示し、デバイス1000は、パーソナルコンピュータ、サーバコンピュータ、ゲームコンソール、モバイルデバイス、または他のデジタルデバイスを組み込むことができるか、またはそれらであり得、これらの各々は、本発明の実施形態を実施するのに適している。デバイス1000は、ソフトウェアアプリケーション及び任意選択でオペレーティングシステムを実行するための中央処理装置(CPU)1002を含む。CPU1002は、1つ以上の同種または異種の処理コアで構成され得る。
【0106】
様々な実施形態によれば、CPU1002は、1つ以上の処理コアを有する1つ以上の汎用マイクロプロセッサである。さらなる実施形態は、マイクロプロセッサアーキテクチャを備えた1つ以上のCPUを使用して実装されることができ、このマイクロプロセッサアーキテクチャは、ゲーム実行中のグラフィックス処理のために構成されたアプリケーションの、メディア及びインタラクティブエンターテインメントアプリケーションなどの高度に並列で計算集約的な用途に具体的に適合されている。
【0107】
メモリ1004は、CPU1002及びGPU1016が使用するためのアプリケーション及びデータを格納する。ストレージ1006は、アプリケーション及びデータ用の不揮発性ストレージ及びその他のコンピュータ可読メディアを提供し、固定ディスクドライブ、リムーバブルディスクドライブ、フラッシュメモリデバイス、及びCD-ROM、DVD-ROM、Blu-ray(登録商標)、HD-DVD、または、その他の光ストレージデバイス、及び信号送信とストレージメディアを含み得る。ユーザ入力デバイス1008は、1人以上のユーザからデバイス1000にユーザ入力を通信し、デバイス1000の例には、キーボード、マウス、ジョイスティック、タッチパッド、タッチスクリーン、静止画またはビデオレコーダ/カメラ、及び/またはマイクロフォンが含まれ得る。
ネットワークインターフェース1009は、デバイス1000が、電子通信ネットワークを介して他のコンピュータシステムと通信することを可能にし、ローカルエリアネットワーク及びインターネットなどのワイドエリアネットワークを介した有線または無線通信を含み得る。オーディオプロセッサ1012は、CPU1002、メモリ1004、及び/またはストレージ1006によって提供される命令及び/またはデータからアナログまたはデジタルオーディオ出力を生成するように適合されている。CPU1002、GPU1016を含むグラフィックスサブシステム、メモリ1004、データストレージ1006、ユーザ入力デバイス1008、ネットワークインターフェース1009、及びオーディオプロセッサ1012を含むデバイス1000の構成要素は、1つ以上のデータバス1022を介して接続されている。
【0108】
グラフィックサブシステム1014は、データバス1022及びデバイス1000の構成要素にさらに接続されている。グラフィックサブシステム1014は、グラフィック処理ユニット(GPU)1016及びグラフィックメモリ1018を含む。グラフィックメモリ1018は、出力画像の各ピクセルのピクセルデータを格納するために使用されるディスプレイメモリ(例えば、フレームバッファ)を含む。グラフィックスメモリ1018は、GPU1016と同じデバイスに統合することができ、別のデバイスとしてGPU1016と接続され、及び/またはメモリ1004内に実装されている。
ピクセルデータは、CPU1002から直接的にグラフィックスメモリ1018に提供されることができる。代替的に、CPU1002は、GPU1016に所望の出力画像を定義するデータ及び/または命令を提供し、そこから、GPU1016は、1つ以上の出力画像のピクセルデータを生成する。所望の出力画像を定義するデータ及び/または命令は、メモリ1004及び/またはグラフィックスメモリ1018に格納されることができる。一実施形態では、GPU1016は、シーンに対するジオメトリ、照明、シェーディング、テクスチャリング、モーション、及び/またはカメラパラメータを定義する命令及びデータから、出力画像のピクセルデータを生成するための3Dレンダリング機能を含む。GPU1016は、シェーダプログラムを実行することができる1つ以上のプログラム可能な実行ユニットをさらに含むことができる。
【0109】
グラフィックサブシステム1014は、ディスプレイデバイス1010に表示されるか、または投影システム(図示せず)によって投影される画像のピクセルデータをグラフィックメモリ1018から周期的に出力する。ディスプレイデバイス1010は、CRT、LCD、プラズマディスプレイ及びOLEDディスプレイを含む、デバイス1000からの信号に応答して視覚情報を表示することができる任意のデバイスであり得る。デバイス1000は、例えば、アナログまたはデジタルの信号をディスプレイデバイス1010に提供することができる。
【0110】
グラフィックサブシステム1014を最適化するための他の実施形態は、GPUインスタンスが複数のアプリケーション間で共有され、かつ、単一のゲームをサポートするGPUが分散されたマルチテナンシGPU操作を含むことができる。グラフィックサブシステム1014は、1つ以上の処理デバイスとして構成されることができる。
【0111】
例えば、グラフィックスサブシステム1014は、マルチテナンシGPU機能を実行するように構成され得、一実施形態では、1つのグラフィックスサブシステムが、複数のゲーム用のグラフィックス及び/またはレンダリングパイプラインを実装し得る。つまり、グラフィックサブシステム1014は、実行されている複数のゲーム間で共有される。
【0112】
他の実施形態では、グラフィックサブシステム1014は、複数のGPUデバイスを含み、これらは、対応するCPU上で実行されている単一アプリケーション用にグラフィック処理を実行するために組み合わされている。例えば、複数のGPUは、フレームレンダリングの代替的形態を実行でき、ここでは、GPU1は第1のフレームをレンダリングし、GPU2は第2のフレームを連続したフレーム期間でレンダリングし、最後のGPUに到達するまでそれを行い、その結果、最初のGPUが次のビデオフレームをレンダリングする(例えば、GPUが2つしかない場合、GPU1は第3のフレームをレンダリングする)。つまり、フレームをレンダリングするときにGPUは循環する。レンダリング操作は重複することができ、GPU1が第1のフレームのレンダリングを終了する前にGPU2が第2のフレームのレンダリングを開始することができる。
別の実施態様では、複数のGPUデバイスに、レンダリングパイプライン及び/またはグラフィックスパイプラインにおいて、異なるシェーダ操作が割り当てられることができる。マスターGPUが、メインのレンダリングと合成を実行している。例えば、3つのGPUを含むグループでは、マスターGPU1が、メインレンダリング(例えば、第1のシェーダ操作)、及びスレーブGPU2とスレーブGPU3からの出力の合成を実行することができ、スレーブGPU2は、第2のシェーダ操作(例えば、河川などの流体効果)を実行することができ、スレーブGPU3は、第3のシェーダ(粒子の煙など)操作を実行することができ、マスターGPU1は、GPU1、GPU2、GPU3の各々からの結果を合成する。このようにして、様々なGPUが割り当てられ、様々なシェーダ操作(旗を振る、風、煙の生成、火など)を実行してビデオフレームをレンダリングすることができる。
さらに別の実施形態では、3つのGPUの各々が、ビデオフレームに対応するシーンの異なるオブジェクト及び/または部分に割り当てられることができる。上述の実施形態及び実装態様では、これらの操作は、同じフレーム期間で(並行して同時に)、または異なるフレーム期間で(並行して連続的に)実行されることができる。
【0113】
従って、本開示は、クラウドゲーミングシステムにおいて一方向レイテンシとビデオ品質との間のトレードオフを改善するためのエンコーダ調整を提供することを含む、メディアコンテンツをストリーミングし、及び/またはストリーミングされたメディアコンテンツを受信するために構成された方法及びシステムを説明しており、エンコーダ調節は、クライアント帯域幅、スキップされたフレーム、エンコードされたIフレームの数、シーン変化の数、及び/または目標フレームサイズを超えるビデオフレームの数の監視に基づき得、調節されたパラメータは、エンコーダビットレート、目標フレームサイズ、最大フレームサイズ、及び量子化パラメータ(QP)値を含み得、高性能のエンコーダとデコーダは、クラウドゲーミングサーバとクライアントとの間の全体的な一方向レイテンシを低減する働きをする。
【0114】
本明細書で定義される様々な実施形態が、本明細書で開示された様々な特徴を使用して、特定の実施態様に組み合わせられるか、または組み立てられ得ることが理解されるべきである。従って、提供される実施例は、いくつかの可能な実施例にすぎず、様々な要素を組み合わせることでより多くの実施態様を定義することが可能な様々な実施態様に限定されない。ある例では、ある実施態様は、開示されたまたは同等の実施態様の趣旨から逸脱することなく、より少ない要素を含んでもよい。
【0115】
本開示の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成で実施されることができる。本開示の実施形態は、有線ベースのネットワークまたは無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実施されることができる。
【0116】
上述の実施形態を念頭に置いて、本開示の実施形態は、コンピュータシステムに格納されたデータを含む様々なコンピュータ実装操作を採用できることを理解されるべきである。これらの動作は、物理量の物理的操作を要する動作である。本開示の実施形態の一部を形成する、本明細書で説明される動作のうちのいずれも、有用な機械動作である。開示の実施形態はまた、これら動作を実行するためのデバイスまたは装置に関する。装置は、必要な目的のために特別に構築されてもよい。または、装置は、コンピュータに記憶されたコンピュータプログラムにより選択的に起動または構成される汎用コンピュータであってもよい。具体的には、本明細書の教示に従って書かれたコンピュータプログラムと共に様々な汎用マシンを使用することができる、あるいは、必要な動作を実行するためにさらに特化した装置を構築するほうがより好都合である場合もある。
【0117】
本開示はまた、コンピュータ可読媒体上のコンピュータ可読コードとして具現化されることができる。コンピュータ可読媒体は、データを格納することができる任意のデータ格納装置であり、これは、その後、コンピュータシステムによって読み取られることができる。コンピュータ可読媒体の例には、ハードドライブ、ネットクワーク接続ストレージ(NAS)、読み出し専用メモリ、ランダムアクセスメモリ、CD-ROM、CD-R、CD-RW、磁気テープ、並びに他の光学及び非光学データストレージデバイスが含まれる。コンピュータ可読媒体は、ネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形媒体を含むことができ、コンピュータ可読コードが分散方式で格納及び実行されるようになっている。
【0118】
本方法の操作は特定の順序で説明されているが、他のハウスキーピング操作が、操作の間に実行され得、もしくは、操作が、わずかに異なる時間に発生するように調整されることができるか、またはシステムに分散されることができ、このことが、重複操作の処理が所望の方法で実行される限り、処理に関連する様々な間隔での処理操作の発生を可能とすることが理解されるべきである。
【0119】
前述の開示は、理解を明確にする目的で、ある程度詳細に説明されてきたが、特定の変更及び修正は、添付の特許請求の範囲内で実施されることができることは明らかであろう。従って、本実施形態は、限定ではなく例示としてみなされるべきであり、本開示の実施形態は、本明細書に提供される詳細に限定されるものではなく、添付の特許請求の範囲内及び均等物内で変更されてもよい。
図1A
図1B
図2A
図2B
図2C
図2D
図3
図4
図5
図6
図7
図8
図9
図10
【国際調査報告】