JP5973409B2 - プログラム、記録媒体、情報処理装置及び制御方法 - Google Patents

Description

本発明は、プログラム、記録媒体、情報処理装置及び制御方法に関し、特に通信を介したゲームコンテンツの提供を行う技術に関する。

ネットワーク接続可能なパーソナルコンピュータ（ＰＣ）等のクライアント機器が普及している。このような機器の普及により、インターネットにおけるネットワーク人口は増加している。近年では、ネットワークユーザに対する、インターネットを利用した様々なサービスが展開されており、ゲーム等のエンターテインメントサービスも提供されている。

ネットワークユーザに対するサービスの１つとして、ＭＭＯＲＰＧ（Massively Multiplayer Online Role-Playing Game）等の多人数同時参加型のネットワークゲームがある。多人数同時参加型のネットワークゲームでは、ユーザは使用するクライアント機器を、ゲームを提供するサーバ機器に接続することで、該サーバ機器に接続されているクライアント機器を使用するユーザとの対戦プレイや協力プレイを行うことができる。

一般的な多人数参加型のネットワークゲームでは、クライアント機器はサーバ機器との間でゲームの描画に必要なデータの送受信を行う。クライアント機器は、受信した描画に必要なデータを用いて描画処理を実行し、生成したゲーム画面をクライアント機器に接続された表示装置に提示することで、ユーザにゲーム画面を提供する。また、ユーザが入力インタフェースを操作することで入力された情報はサーバ機器に送信され、サーバ機器における演算処理に使用されたり、サーバ機器に接続された他のクライアント機器に伝送されたりする。

しかしながら、このようなクライアント機器で描画処理を行うネットワークゲームの中には、十分な描画性能を有するＰＣや専用のゲーム機をユーザが使用することが必要となるものがある。このため、ネットワークゲーム（１コンテンツ）のユーザ数は、コンテンツが要求するクライアント機器の性能に依存してしまう。高性能の機器は当然高価であり、該機器を所有できるユーザも限られる。即ち、例えば美麗なグラフィックを提供するゲーム等の高い描画性能が要求されるゲームでは、ユーザ数を増加させることが困難である。

これに対し、近年ではクライアント機器の描画性能等の処理能力に依存せずに、ユーザがプレイ可能なゲームも提供されている。特許文献１のようなゲームでは、サーバ機器はクライアント機器においてなされた操作の情報を取得し、該情報を用いて描画処理を実行して得られたゲーム画面を、クライアント機器に対して提供している。

国際公開第２００９／１３８８７８号明細書

上述した特許文献１のような通信を介したゲームコンテンツの提供を行う場合、提供に要するインフラ配備には所定のコストが必要となる。これは、コンテンツを提供する配信サーバの故障や接続端末数の増加に伴う提供品質の低下等のリスクを想定して、耐障害性及び耐応答性の観点で複数の配信サーバが設置されることによる。また、一般にクライアント機器に対して最も遅延が少ない、即ちレスポンスが好適なサーバは、伝送路の観点から地理的に最も近いサーバと考えられる。これらのことから、特にワールドワイドなコンテンツ提供を行う場合、提供サーバは複数の国に、さらにはタイムゾーンの存在を考えると複数のサーバを１つの国に、データセンタとして配備することが考えられる。つまり、インフラ配備には多大なコストが想定されるため、データセンタの提供はコンテンツごとに行うのではなく、複数のコンテンツでデータセンタのリソースを共用できるように設計されることが現実的である。

一方で、このようなサービスの利用に限らず、ネットワーク利用が集中する時間帯は、各国で同じような傾向にある。具体的には、日本におけるネットワーク利用のトラヒックピークは、１９時から２３時の間に存在する。即ち、上述のようにタイムゾーンを考慮してデータセンタを配置したとしても、トラヒックが増大する時間帯では、該タイムゾーンに存在するクライアント機器が地理的に最も近いデータセンタに集中することが考えられる。

本発明は、上述の問題点に鑑みてなされたものであり、提供するコンテンツについて要求される条件に応じた好適なデータセンタ間のロードバランシングを行うプログラム、記録媒体、情報処理装置及び制御方法を提供することを目的とする。

前述の目的を達成するために、本発明のプログラムは、複数の外部の描画装置のうちからゲームコンテンツに係る画面の描画を行う描画装置を決定するコンピュータに、ゲームコンテンツについて要求される、操作入力への応答性を取得する処理と、ゲームコンテンツに係る画面の提供先である受信装置と、複数の描画装置の各々との通信遅延量を取得する処理と、応答性と通信遅延量とに基づいて、複数の描画装置のうちの１つの描画装置を描画を行う描画装置として決定する処理と、を実行させる。

このような構成により本発明によれば、提供するコンテンツについて要求される条件に応じた好適なデータセンタ間のロードバランシングを行うことが可能となる。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。

本発明の実施形態１に係る動画配信システムのシステム構成を示した図 本発明の実施形態に係るＰＣ１００の機能構成を示したブロック図 本発明の実施形態に係る動画配信サーバ２００の機能構成を示したブロック図 本発明の実施形態に係る動画配信サーバ２００の動画配信処理を例示したフローチャート 本発明の実施形態に係る描画オブジェクトのデータ構造を例示した図 本発明の実施形態に係る動画配信サーバ２００の符号化処理を例示したフローチャート 本発明の実施形態に係るＰＣ１００の動画再生処理を例示したフローチャート 本発明の実施形態に係るＰＣ１００の復号前処理を例示したフローチャート 本発明の実施形態に係る動画配信システムの全体処理を例示したフローチャート 本発明の実施形態に係る最も相関が高いと思われる領域の推定方法を説明するための図 本発明の実施形態２に係る動画配信システムのシステム構成を示した図 本発明の実施形態２に係る中央サーバの機能構成を示したブロック図 本発明の実施形態２に係るＰＣ１００の開始時処理を例示したフローチャート 本発明の実施形態２に係る中央サーバ１１００の提供サーバ決定処理を例示したフローチャート

［実施形態１］
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下に説明する一実施形態は、動画配信システムの一例としての、動画再生装置であるＰＣ１００と、動画を配信する動画配信サーバ２００とに本発明を適用した例を説明する。

《動画配信システムの構成》
図１は、本発明の実施形態に係る動画配信システムのシステム構成を示す図である。

図示されるように、ＰＣ１００と動画配信サーバ２００とはインターネット等のネットワーク３００を介して接続されている。本実施形態ではＰＣ１００は、動画配信コンテンツの一例として、動画配信サーバ２００において実行されるゲームコンテンツに係るゲーム画面を、符号化動画データとして受信する。本実施形態では動画配信サーバ２００は、ＰＣ１００においてなされた操作（ユーザ入力）を受信し、該操作に応じたゲーム画面を１フレームごとに描画する。そして動画配信サーバ２００は、描画したゲーム画面を符号化し、得られた符号化動画データをＰＣ１００に配信する。またＰＣ１００は、動画配信サーバ２００から符号化動画データを受信すると、該符号化動画データを復号して再生することで、ユーザに対してゲーム画面を提供することができる。

なお、本実施形態では動画配信コンテンツの一例として、ネットワーク３００上の動画配信サーバ２００において実行されるゲームプログラムにより描画されたゲーム画面を提供するコンテンツを説明するが、本発明の実施はこれに限られるものではない。動画配信サーバ２００は、配信先に提供する動画配信コンテンツの１フレームを描画処理により描画し、各フレームについて行われた符号化処理により得られた符号化動画データを配信する構成であればよい。また、１フレームに係る画面の描画は、必ずしも動画配信サーバ２００において実行される必要はなく、例えば外部の描画サーバにより実行されてもよい。

また、本実施形態では動画配信サーバ２００に接続するクライアント機器として、ＰＣ１００を用いて説明するが、本発明の実施はこれに限られるものではない。例えば動画配信サーバ２００と接続するクライアント機器は、家庭用ゲーム機、携帯ゲーム機、携帯電話、ＰＤＡ、タブレット等の、動画配信サーバ２００から受信した符号化動画データを復号して再生可能な機器であればよい。

〈ＰＣ１００の構成〉
図２は、本発明の実施形態に係るＰＣ１００の機能構成を示すブロック図である。

ＣＰＵ１０１は、ＰＣ１００が有する各ブロックの動作を制御する。具体的にはＣＰＵ１０１は、例えばＲＯＭ１０２に記憶されている動画再生処理の動作プログラムを読み出し、ＲＡＭ１０３に展開して実行することにより、各ブロックの動作を制御する。

ＲＯＭ１０２は、例えば書き換え可能な不揮発性メモリである。ＲＯＭ１０２は、動画再生処理等の動作プログラムに加え、ＰＣ１００が有する各ブロックの動作に必要な定数等の情報を記憶する。

ＲＡＭ１０３は、揮発性メモリである。ＲＡＭ１０３は、動作プログラムの展開領域としてだけでなく、ＰＣ１００が有する各ブロックの動作において出力された中間データ等を一時的に記憶する格納領域としても用いられる。

復号部１０４は、後述する通信部１０５が受信した符号化動画データについて復号処理を行い、１フレームに係るゲーム画面を生成する。また復号部１０４は、符号化動画データについての復号処理を行う前に、該復号処理に用いる参照データを準備する復号前処理を行う。復号部１０４において実行される復号前処理及び復号処理については、後述する動画再生処理において詳述する。

通信部１０５は、ＰＣ１００が有する通信インタフェースである。通信部１０５は、ネットワーク３００を介して接続した、動画配信サーバ２００等の他の機器との間におけるデータ送受信を行う。データ送信時には通信部１０５は、ネットワーク３００あるいは送信先の機器との間で定められたデータ伝送形式にデータを変換し、送信先の機器へのデータ送信を行う。またデータ受信時には通信部１０５は、ネットワーク３００を介して受信したデータを、ＰＣ１００において読み取り可能な任意のデータ形式に変換し、例えばＲＡＭ１０３に記憶させる。

なお、本実施形態ではＰＣ１００と動画配信サーバ２００とは、ネットワーク３００を介して接続されるものとして説明するが、例えばＰＣ１００と動画配信サーバ２００とが直接ケーブルにより接続される形態であってもよいことは容易に想像されよう。

表示部１０６は、例えばＬＣＤモニタ等のＰＣ１００に接続された表示装置である。表示部１０６は、入力されたゲーム画面を表示領域に表示する表示制御を行う。なお、表示部１０６は、ラップトップＰＣのようにＰＣ１００に内蔵される表示装置であってもよいし、ケーブルを用いてＰＣ１００に外部接続された表示装置であってもよい。

操作入力部１０７は、例えばマウス、キーボード、ゲームパッド等のＰＣ１００が有するユーザインタフェースである。操作入力部１０７は、ユーザによりユーザインタフェースの操作がなされたことを検出すると、該操作に対応する制御信号をＣＰＵ１０１に対して出力する。

〈動画配信サーバ２００の構成〉
図３は、本発明の実施形態に係る動画配信サーバ２００の機能構成を示すブロック図である。

サーバＣＰＵ２０１は、動画配信サーバ２００が有する各ブロックの動作を制御する。具体的にはサーバＣＰＵ２０１は、例えばサーバＲＯＭ２０２に記憶されている動画配信処理の動作プログラムを読み出し、サーバＲＡＭ２０３に展開して実行することにより、各ブロックの動作を制御する。

サーバＲＯＭ２０２は、例えば書き換え可能な不揮発性メモリである。サーバＲＯＭ２０２は、動画配信処理等の動作プログラムに加え、動画配信サーバ２００が有する各ブロックの動作において必要となる定数等の情報を記憶する。

サーバＲＡＭ２０３は、揮発性メモリである。サーバＲＡＭ２０３は、動作プログラムの展開領域としてだけでなく、動画配信サーバ２００が有する各ブロックの動作において出力された中間データ等を一時的に記憶する格納領域としても用いられる。

サーバＧＰＵ２０４は、ＰＣ１００の表示部１０６に表示するゲーム画面の生成を行う。サーバＧＰＵ２０４には、サーバＶＲＡＭ２０５が接続される。サーバＧＰＵ２０４は、サーバＣＰＵ２０１より描画命令及びゲーム画面の描画に用いるカメラの位置及び方向の情報（視点情報）を受信すると、該描画命令に係る描画オブジェクトを例えば後述するサーバ記録媒体２０７から読み出し、ＧＰＵメモリに格納する。サーバＧＰＵ２０４は、接続されたサーバＶＲＡＭ２０５に対して描画を行う場合、描画オブジェクトのキャッシュメモリへの展開を行なった後、該展開後の描画オブジェクトをサーバＶＲＡＭ２０５に書き込む。

なお、本実施形態のサーバＧＰＵ２０４は、ゲーム画面の生成に係る描画処理において、所謂遅延レンダリング（Deferred Rendering）という手法を用いる。

従来の描画手法は、ゲーム画面に含まれる描画オブジェクトの各々を順番に選択し、該描画オブジェクトについて
１．バーテックスシェーダによる移動・回転処理
２．ジオメトリシェーダによる頂点処理
３．ピクセルシェーダによるピクセル単位の陰影処理を含むエフェクト処理
を行って描画する。即ち、各描画オブジェクトについて、陰影処理→描画の流れを有する、所謂Forward Renderingであった。Forward Renderingでは、各オブジェクトが逐次処理されるために、ピクセルによっては１つのオブジェクトが描画された後、よりカメラに対して近い位置にある（該オブジェクトよりも手前にある）別のオブジェクトの描画により、描画内容が上書きされてしまうケースがある。この場合、後から描画されたオブジェクトにより遮蔽される、先に描画されたオブジェクトの一部の領域については、適用した陰影処理が無駄になってしまう。また例えば描画するシーンに存在する光源等は、シーンに存在するオブジェクトに対して共通であるが、Forward Renderingでは１つのオブジェクトを描画する際の共通の計算内容を、別のオブジェクトの描画のために再利用することが難しかった。このため、特に複雑な陰影処理を行うゲーム画面の描画においては、Forward Renderingは効率的ではなかった。

これに対しDeferred Renderingでは、Forward Renderingとは異なり、陰影処理に用いるジオメトリの計算を先に行い、全ての描画オブジェクトについての陰影処理を、後からまとめて行う。即ち、ジオメトリ描画→陰影処理→描画の流れを有する２段階の描画処理を行う。Deferred Renderingでは、前段の描画において、ライティングを行わずに陰影処理に用いるパラメータとともにジオメトリの描画処理を行い、陰影処理で使用される中間値を示す複数の中間値マップ（散乱マップ、深度マップ、法線マップ、反射マップ、拡散マップ等）を生成する。そして後段の描画処理において、生成された複数の中間値マップを利用しながら、光源を適用して陰影処理を行なった画面を描画する。

サーバ符号化部２０６は、サーバＧＰＵ２０４によりサーバＶＲＡＭ２０５に生成されたゲーム画面に対する符号化処理を行う。サーバ符号化部２０６は、符号化対象のゲーム画面をブロックに分割し、各ブロックをイントラ符号化（フレーム内符号化）あるいはインター符号化（フレーム間符号化）する。符号化処理の詳細は後述するが、本実施形態ではサーバ符号化部２０６は、各ブロックをＹＣｂＣｒの色チャネルごとに離散コサイン変換（ＤＣＴ）した後、ランレングス符号化により圧縮する。なお、本実施形態ではゲーム画面に対する符号化処理を行うブロックとしてサーバ符号化部２０６が単体で存在するものとして説明するが、符号化処理はサーバＧＰＵ２０４が実行してもよい。

サーバ記録媒体２０７は、例えばＨＤＤ等の、動画配信サーバ２００に着脱可能に接続される記録装置である。本実施形態ではサーバ記録媒体２０７には、画面の描画処理において用いられる、各描画オブジェクトのデータや、画面に表現される３次元シーンに配置された光源情報等が記録されているものとする。

サーバ通信部２０８は、動画配信サーバ２００が有する通信インタフェースである。本実施形態ではサーバ通信部２０８は、ネットワーク３００を介して接続したＰＣ１００等の、他の機器との間におけるデータ送受信を行う。なお、サーバ通信部２０８は通信部１０５と同様に、通信仕様に従ったデータ形式の変換を行う。

《動画配信処理》
このような構成をもつ本実施形態の動画配信システムの動画配信サーバ２００において実行される動画配信処理について、図４のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、サーバＣＰＵ２０１が、例えばサーバＲＯＭ２０２に記憶された対応する処理プログラムを読み出し、サーバＲＡＭ２０３に展開して実行することにより実現することができる。なお、本動画配信処理は、例えば動画配信サーバ２００の提供するゲームコンテンツの提供要求をＰＣ１００から受信したことを、サーバＣＰＵ２０１が検出した際に開始され、ゲームの１フレームごとに繰り返し実行されるものとして説明する。

なお、本実施形態では動画配信サーバ２００は、３次元シーンをDeferred Renderingの手法を用いて描画したゲーム画面を符号化動画データの形態でＰＣ１００に提供するものとして説明する。しかしながら、上述したように動画配信サーバ２００が配信するコンテンツはこれに限られず、３次元シーンを少なくとも２段階の描画処理を行なって描画した画面を提供する任意のコンテンツであればよい。

Ｓ４０１で、サーバＣＰＵ２０１は、次に描画するゲーム画面の視点情報を更新する。具体的にはサーバＣＰＵ２０１は、例えばサーバ通信部２０８が受信した、ＰＣ１００においてユーザによりなされた、ゲームに係る操作入力の情報を参照し、次に描画するゲーム画面の視点情報を更新する。視点情報の更新が生じうるユーザによる操作は、例えば視点位置及び方向の変更操作、あるいはユーザの操作対象のキャラクタの移動等が相当する。なお、ゲーム画面の描画に用いられる視点情報の更新は、ＰＣ１００においてなされたユーザ操作にのみ更新されるものではなく、例えばゲームの進行状況に応じて変更されるものであってもよい。

Ｓ４０２で、サーバＣＰＵ２０１は、Ｓ４０１において更新した視点情報に対応するゲーム画面について、サーバＧＰＵ２０４に前段の描画処理を実行させ、後段の描画処理で用いる各種中間値マップを生成させる。具体的にはサーバＣＰＵ２０１は、描画されるゲーム画面に含まれる描画オブジェクトを特定し、各描画オブジェクトのデータを描画順に従ってサーバＧＰＵ２０４に伝送する。サーバＧＰＵ２０４は、転送された描画オブジェクトのデータをＧＰＵメモリに格納する。描画オブジェクトのデータは、例えば図５に示されるような構成であり、本実施形態ではオブジェクト識別ＩＤに関連付けられて、モデルデータ（あるいは頂点データ及び結線データ）、テクスチャデータ、及び位置・回転情報が含まれる。なお、テクスチャデータは３次元モデルに適用（貼り付け）される、該３次元モデルの模様等を表現する一般的な画像テクスチャ（デカルテクスチャ）だけでなく、該３次元モデルの陰影処理や質感の表現に用いられる各種マップが含まれる。

サーバＧＰＵ２０４は、描画命令を受けた描画オブジェクトについての位置・回転情報のパラメータに従ってＧＰＵメモリに格納されたモデルデータを移動及び回転させた後、光源エフェクト（陰影処理、シェーディング）を適用することなく、サーバＶＲＡＭ２０５への描画を行う。このときサーバＶＲＡＭ２０５には、最終的にＰＣ１００に対して提供するゲーム画面に対応する、複数種類の中間値マップが生成される。該複数種類の中間値マップは、後述する後段の描画処理における陰影処理で参照されるマップであり、本実施形態では少なくとも
・散乱マップ（Albedo map）
・深度マップ（Depth map）
・法線マップ（Normal map）
・反射マップ（Specular map）
・拡散マップ（Diffuse map）
を含む。なお、深度マップ以外の中間値マップは、描画するゲーム画面に含まれる全描画オブジェクトのデータの各々に含まれる対応するテクスチャデータやモデルデータの各ポリゴンの情報等を、描画するゲーム画面の視点情報に応じて変換することで生成される。即ち、Forward Renderingでは各描画オブジェクトについて該描画オブジェクトのテクスチャデータを考慮して１つ１つに陰影処理を実行するのに対し、Deferred Renderingの前段の描画処理では、描画するゲーム画面の全体を１つの描画オブジェクトとして捉えた中間値マップを生成することで、後段の描画処理においてゲーム画面の全体を対象として陰影処理を行うことができ、演算の重複を低減することができる。

なお、深度マップについては、中間値マップの生成において各描画オブジェクトの描画時に、ピクセル単位で描画オブジェクトの前後関係による遮蔽（オクルージョン）を考慮して従来の方法で生成される。

このように前段の描画処理が完了すると、サーバＣＰＵ２０１は、Ｓ４０３乃至Ｓ４０８の処理と、Ｓ４０９乃至Ｓ４１２の処理とを並行して実行する。

Ｓ４０３で、サーバＣＰＵ２０１は、前段の描画処理で生成された中間値マップを、描画しているフレーム（現フレーム）を識別するフレームＩＤ、及びＳ４０１において更新した視点情報（描画視点情報）に関連づけてサーバＲＡＭ２０３に格納する。本実施形態の動画配信サーバ２００は、ＰＣ１００に提供する符号化動画データの各フレームについて、描画したゲーム画面の生成に用いられた深度マップをサーバＲＡＭ２０３に格納し、少なくとも次のフレームの符号化処理が完了するまで保持するものとする。

Ｓ４０４で、サーバＣＰＵ２０１は、複数種類の中間値マップのうちの深度マップを符号化判断用に選択し、所定の画素数（例えば１６pixel×１６pixel）のブロックに分割する。上述したように中間値マップの各々は最終的にＰＣ１００に提供するゲーム画面に対応している。このため本実施形態では、提供するゲーム画面の各ブロックの動画符号化においてフレーム間予測を行うか否かを判断するために、複数種類の中間値マップのうちの深度マップを用いる。

Ｓ４０５で、サーバＣＰＵ２０１は、深度マップの各ブロックについて現フレームの１つ前のフレーム（前フレーム）のゲーム画面に係る前段の描画処理で生成された深度マップから、最も相関が高いと思われる領域を特定する。

まずサーバＣＰＵ２０１は、対象ブロックの四隅の座標に描画されている描画オブジェクト（ブロック特定オブジェクト）の３次元座標を特定する。具体的にはサーバＣＰＵ２０１は、深度バッファから対象ブロックの四隅の座標の各々における深度値を取得する。次にサーバＣＰＵ２０１は、描画視点情報と対象ブロックの四隅の座標とから、ブロック特定オブジェクトへの方向を特定する。そしてサーバＣＰＵ２０１は、描画視点情報、特定したブロック特定オブジェクトへの方向、及び深度値から、ブロック特定オブジェクトの３次元座標を特定する。

次にサーバＣＰＵ２０１は、ブロック特定オブジェクトの３次元座標を、前フレームのゲーム画面の描画に用いられた視点情報（過去視点情報）を用いて、前フレームのゲーム画面におけるスクリーン座標に変換する。このようにすることで、前フレームのゲーム画面における最も相関が高いと思われる領域の四隅の座標を特定することができる。即ち、本実施形態では、図１０に示されるように対象ブロックと同一の描画オブジェクトが表現されている領域、即ち相関が高い描画内容である可能性が高い領域を３次元シーンに逆変換して特定することができる。

Ｓ４０６で、サーバＣＰＵ２０１は、Ｓ３０５において推定された最も相関が高いと思われる領域について、相関度を算出する。具体的にはサーバＣＰＵ２０１は、前フレームの前段の描画処理で生成された深度マップ（過去深度マップ）をサーバＲＡＭ２０３から読み出す。そしてサーバＣＰＵ２０１は、推定された最も相関が高いと思われる領域の画像を該過去深度マップから抽出し、該画像に対して例えば過去視点情報と描画視点情報とから生成された変換マトリックスを乗ずることで、対象ブロックと同じ画素数の参照画像を生成する。そしてサーバＣＰＵ２０１は、例えば画像間のユークリッド距離を算出することで、該参照画像と対象ブロックの画像との相関度を算出する。

なお、本実施形態の動画配信サーバ２００では後述する符号化処理においてフレーム間符号化を行う場合に現フレームの１つ前のフレームから取得した参照データを使用し、現フレームの画像と参照データとの差分画像を符号化する。このため、符号化判断も現フレームの１つ前のフレームについて行うものとして説明するが、フレーム間符号化で参照される過去のフレームは現フレームの１つ前のフレームに限らず、現フレームよりも前のフレームが用いられてよい。

Ｓ４０７で、サーバＣＰＵ２０１は、符号化判断用の深度マップの各ブロックについてフレーム内符号化を行うか、あるいはフレーム間符号化を行うかを決定する（符号化判断）。具体的にはサーバＣＰＵ２０１は、各ブロックと最も相関が高いと思われる過去深度マップの領域について算出された類似度（例えばユークリッド距離の逆数）が予め設定された閾値以上であるか否かを判断する。そしてサーバＣＰＵ２０１は、最も相関が高いと思われる領域との類似度が閾値以上であるブロックについてはフレーム間符号化を行うものとして決定し、類似度が閾値未満であるブロックについてはフレーム内符号化を行うものとして決定する。

Ｓ４０８で、サーバＣＰＵ２０１は、符号化判断用の深度マップの各ブロックのうち、フレーム間符号化を行うとして決定されたブロックについて、過去深度マップの最も相関が高いと思われる領域からの動きベクトルを算出する。そしてサーバＣＰＵ２０１は、該フレーム間符号化を行うとして決定されたブロックを特定する特定情報に関連付けて、該ブロックについての動きベクトルの情報をサーバ通信部２０８に伝送し、前処理情報としてＰＣ１００に対して送信させる。

なお、本ステップで算出される動きベクトルは、前フレームからの視点の移動方向によっては２次元の動きベクトルになるとは限らない。即ち、例えば特定の描画オブジェクトに対して近接する、あるいは遠離する方向に視点が移動した場合は、２次元のベクトルに加えて、拡大／縮小する倍率の情報が含まれていてもよい。また例えば視点がロール方向に回転した場合は、２次元のベクトルに加えて回転用のマトリックスが含まれていてもよい。また例えば視点がピッチ方向あるいはヨー方向に回転した場合は、２次元のベクトルではなく３次元のベクトルが動きベクトルとして用いられてもよい。なお、参照データとして用いる前フレーム画面の領域を特定する情報は、これに限られるものではなく、例えば直接領域の頂点座標を指定する情報等、領域を特定できる情報であればどのような形式であってもよい。

一方、サーバＣＰＵ２０１はＳ４０３乃至Ｓ４０８の処理と並行して実行する処理では、Ｓ４０９でサーバＧＰＵ２０４にＳ４０１において更新した視点情報に対応するゲーム画面についての後段の描画処理を実行させ、最終的にＰＣ１００に提供するゲーム画面（提供ゲーム画面）を生成させる。具体的にはサーバＣＰＵ２０１は、描画されるゲーム画面についての３次元シーンに適用される光源を特定し、該光源の属性や強度等の情報をサーバＧＰＵ２０４に伝送する。サーバＧＰＵ２０４は、前段の描画処理で生成した各種中間値マップを用いて、各種光源をまとめて陰影処理（光源エフェクトの適用）しながら、再度ゲーム画面に含まれる描画オブジェクトを描画し、提供ゲーム画面をサーバＶＲＡＭ２０５のフレームバッファに生成する。

Ｓ４１０で、サーバＣＰＵ２０１は、Ｓ４０７の処理である現フレームについての符号化判断処理が完了したか否かを判断する。サーバＣＰＵ２０１は、符号化判断処理が完了していると判断した場合は処理をＳ４１１に移し、完了していないと判断した場合は処理を本ステップの処理を繰り返す。

Ｓ４１１で、サーバＣＰＵ２０１は、提供ゲーム画面をＳ４０４におけるブロック分割と同様にブロック分割し、符号化処理を実行して符号化動画データを生成する。

〈符号化処理〉
ここで、本実施形態の動画配信サーバ２００において実行される符号化処理について、図６を参照して詳細を説明する。

Ｓ６０１で、サーバＣＰＵ２０１は、提供ゲーム画面のブロックのうち、符号化がなされていないブロックを選択する。

Ｓ６０２で、サーバＣＰＵ２０１は、符号化判断要の深度マップについて行われた符号化判断処理の結果を参照し、選択ブロックについてフレーム間符号化を行うか否かを判断する。サーバＣＰＵ２０１は、選択ブロックについてフレーム間符号化を行うと判断した場合は処理をＳ６０３に移し、フレーム間符号化を行わないと判断した場合は処理をＳ６０５に移す。

Ｓ６０３で、サーバＣＰＵ２０１は、現フレームの１つ前のフレームで描画されたゲーム画面（前フレーム画面）内の選択ブロックに対応する領域の画像から、フレーム間符号化に使用する参照画像（参照データ）を生成する。具体的にはサーバＣＰＵ２０１はまず、前フレームでＰＣ１００に提供されたゲーム画面（過去ゲーム画面）を例えばサーバＲＡＭ２０３から読み出す。そしてサーバＣＰＵ２０１は、選択ブロックについて特定された最も相関が高い領域に対応する領域の画像を、参照画像として過去ゲーム画面から抽出する。

Ｓ６０４で、サーバＣＰＵ２０１は、選択ブロックの画像と参照画像との差分を差分画像として生成し、符号化対象画像として設定する。具体的にはサーバＣＰＵ２０１は、選択ブロックの画像の各画素値から、参照画像の対応する画素の画素値を減算することにより差分画像（pblock）を生成する。

一方、Ｓ６０２においてフレーム間符号化を行わないと判断した場合、サーバＣＰＵ２０１はＳ６０５において、選択ブロックの画像を符号化対象画像として設定する。

Ｓ６０６で、サーバＣＰＵ２０１は、符号化対象画像をサーバ符号化部２０６に伝送し、ＤＣＴ処理を実行させて周波数領域のデータに変換させる。またサーバＣＰＵ２０１は、変換により得られた周波数領域のデータに対してサーバ符号化部２０６にランレングス符号化を行わせることで、選択ブロックの符号化データを生成させる。

Ｓ６０７で、サーバＣＰＵ２０１は、描画されたゲーム画面の全てのブロックについてＳ６０２乃至Ｓ６０６の処理を実行したか否かを判断する。サーバＣＰＵ２０１は、まだ処理が実行されていないブロックが存在すると判断した場合は処理をＳ６０１に戻し、存在しないと判断した場合は本符号化処理を完了する。

サーバＣＰＵ２０１は、描画されたゲーム画面から符号化動画データを生成した後、Ｓ４１２で該符号化動画データをサーバ通信部２０８に伝送してＰＣ１００に対して送信させ、現フレームの動画配信処理を完了する。

このように、本実施形態の動画配信サーバ２００では、ＰＣ１００に対して提供するゲーム画面の生成が多段階の描画処理によって行われることを利用し、最終的なゲーム画面の描画が行われる後段の描画処理中に、前段の描画処理で生成された深度マップを用いて、符号化ブロックと最も相関が高いと思われる領域を、座標変換により推定することができる。このため、最終的なゲーム画面の描画を行なった後に符号化方法を決定することなく符号化処理に移行できるため、ゲーム画面のＰＣ１００への提供に要する時間を短縮することができる。また、総当り式に相関度を算出して最も相関が高いと思われる領域を特定する必要がなく、後段の描画処理中に全符号化ブロックについての相関演算に係る演算量を低減することができる。

《動画再生処理》
次に、本実施形態のＰＣ１００において実行される動画再生処理について、図７のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、ＣＰＵ１０１が、例えばＲＯＭ１０２に記憶された対応する処理プログラムを読み出し、ＲＡＭ１０３に展開して実行することにより実現することができる。なお、本動画再生処理は、例えばＰＣ１００において動画配信サーバ２００の提供するゲームコンテンツを受信するアプリケーションが実行された際に開始され、ゲームの１フレームごとに繰り返し実行されるものとして説明する。

Ｓ７０１で、ＣＰＵ１０１は、通信部１０５が動画配信サーバ２００から前処理情報を受信したか否かを判断する。ＣＰＵ１０１は、動画配信サーバ２００から前処理情報を受信したと判断した場合は処理をＳ７０２に移し、受信していないと判断した場合は本ステップの処理を繰り返す。

Ｓ７０２で、ＣＰＵ１０１は、前処理情報を参照し、現フレームのゲーム画面の復号に必要な参照データを準備する復号前処理を実行する。

〈復号前処理〉
ここで、本実施形態のＰＣ１００で実行される復号前処理について、図８のフローチャートを用いて詳細を説明する。

Ｓ８０１で、ＣＰＵ１０１は、現フレームで受信するゲーム画面のブロックのうち、使用された符号化方式の判定がなされていないブロックを選択する。

Ｓ８０２で、ＣＰＵ１０１は前処理情報を参照し、選択ブロックについてフレーム間符号化がなされるか否かを判断する。具体的にはＣＰＵ１０１は、選択ブロックを特定する情報が前処理情報に含まれるか否かを判断する。ＣＰＵ１０１は、選択ブロックについてフレーム間符号化がなされると判断した場合は処理をＳ８０３に移し、なされていないと判断した場合は処理をＳ８０４に移す。

Ｓ８０３で、ＣＰＵ１０１は、現フレームの１つ前のフレームで復号したゲーム画面（前フレーム画面）から、選択ブロックについての復号に使用する参照画像（参照データ）を抽出する。具体的にはＣＰＵ１０１は、前処理情報に含まれる選択ブロックについて関連付けられた動きベクトルを参照し、前フレーム画面における選択ブロックの復号で参照される領域を特定し、該領域の画像を参照画像として抽出する。

Ｓ８０４で、ＣＰＵ１０１は、現フレームで受信するゲーム画面の全てのブロックについてＳ８０２乃至Ｓ８０３の処理を実行したか否かを判断する。サーバＣＰＵ２０１は、まだ処理が実行されていないブロックが存在すると判断した場合は処理をＳ８０１に戻し、存在しないと判断した場合は本復号前処理を完了する。

このように本実施形態のＰＣ１００では、符号化動画データの前に受信した前処理情報を参照することで、符号化動画データの受信後に行われる復号処理に先立って、復号処理で用いられる参照データを準備することができる。

Ｓ７０３で、ＣＰＵ１０１は、通信部１０５が動画配信サーバ２００から符号化動画データを受信したか否かを判断する。ＣＰＵ１０１は、動画配信サーバ２００から符号化動画データを受信したと判断した場合は処理をＳ７０４に移し、受信していないと判断した場合は本ステップの処理を繰り返す。

Ｓ７０４で、ＣＰＵ１０１は、受信した符号化動画データを復号部１０４に伝送し、復号処理を実行させてゲーム画面を生成させる。具体的には復号部１０４は、符号化動画データの各ブロックについてランレングス符号化データ列の復号、逆ＤＣＴ処理を行うことで現フレームのゲーム画面のブロックデータを生成する。またフレーム間符号化が行われたブロックについては、上述した復号前処理で生成された参照データを加算することで、復号部１０４は現フレームのゲーム画面を生成する。

Ｓ７０５で、ＣＰＵ１０１は、Ｓ７０４において生成された現フレームのゲーム画面を表示部１０６に伝送し、対応する表示領域に表示させ、現フレームの動画再生処理を完了する。

このように、本実施形態の動画配信システムにおける動画配信サーバ２００は、符号化動画データの生成が完了して配信するよりも前に、符号化方法の情報を動画再生装置であるＰＣ１００に伝えることができる。即ち、符号化動画データの受信前に参照画像を前処理として準備することができるため、符号化動画データを受信してから行われる復号処理を短縮することができる。つまり、フレーム間符号化がなされたブロックの復号に用いる参照画像を、受信した符号化動画データに含まれる動きベクトルを参照して前のフレームの画像から生成する従来の方法に比べて、本実施形態の動画配信方法は復号した動画像の再生までに要する時間を短縮することができる。

即ち、動画配信システム全体としては、図９に示されるような処理フローとなり、本発明を適用することで、動画配信サーバ２００における動画符号化処理の効率化、及びＰＣ１００における動画復号処理の効率化の両方を実現することができる。

なお、上述した動画配信処理では、現フレームの画面の全てのブロックについて符号化判断を行った後に前処理情報をＰＣ１００に送信するものとして説明したが、前処理情報の送信タイミングはこれに限られないことは容易に想像されよう。即ち、各ブロックについてフレーム間符号化を行うか否かの判断結果が得られた場合に、全てのブロックについての判断結果が得られるのを待たずに、都度、サーバＣＰＵ２０１は該ブロックの前処理情報をＰＣ１００に送信してもよい。またこの場合、ＰＣ１００のＣＰＵ１０１が、前処理情報を受信すると、該前処理情報で特定されるブロックの参照画像を生成するようにすることで、動画再生処理における更なる効率化が見込める。

以上説明したように、本実施形態の動画配信サーバは描画処理により得られた画面を高速かつ効率的に動画符号化することができる。具体的には動画配信サーバは、描画する画面を決定する視点情報を用いて、少なくとも２段階の描画処理により提供画面を描画する。該描画処理は、後段の描画処理において、前段の描画処理で生成された深度マップを参照して提供画面の描画がなされる。動画配信サーバは、第１の画面の後段の描画処理の実行中に深度マップを符号化判断用に選択し、設定されたブロックごとに第１の画面よりも前に描画された第２の画面について生成された深度マップを参照してフレーム間符号化を行うか否かを判断する。動画配信サーバは、第１の画面の後段の描画処理の終了後、該判断の結果に応じて符号化を行って外部装置に符号化動画データを送信する。また該判断の結果は、第１の画面の符号化動画データの生成が完了する前に外部装置に送信される。

［実施形態２］
ところで、実際に上述のような通信を介したゲームコンテンツの提供を行う場合、提供に要するインフラ配備には所定のコストが必要となる。これは、コンテンツを提供する動画配信サーバ２００の故障や接続端末数の増加に伴う提供品質の低下等のリスクを想定して、耐障害性及び耐応答性の観点で複数の動画配信サーバ２００が設置されることによる。また、一般にクライアント機器に対して最も遅延が少ない、即ちレスポンスが好適なサーバは、伝送路の観点から地理的に最も近いサーバと考えられる。これらのことから、特にワールドワイドなコンテンツ提供を行う場合、提供サーバは複数の国に、さらにはタイムゾーンの存在を考えると複数のサーバを１つの国に、データセンタとして配備することが考えられる。つまり、インフラ配備には多大なコストが想定されるため、データセンタの提供はコンテンツごとに行うのではなく、複数のコンテンツでデータセンタのリソースを共用できるように設計されることが現実的である。

一方で、このようなサービスの利用に限らず、ネットワーク利用が集中する時間帯は、各国で同じような傾向にある。具体的には、日本におけるネットワーク利用のトラヒックピークは、１９時から２３時の間に存在する。即ち、上述のようにタイムゾーンを考慮してデータセンタを配置したとしても、トラヒックが増大する時間帯では、該タイムゾーンに存在するクライアント機器が地理的に最も近いデータセンタに集中することが考えられる。

本実施形態では、提供するコンテンツについて要求されるリアルタイム性、及びコンテンツが実施形態１のような少なくとも２段階の描画処理を行うか否かに応じて、好適にデータセンタ間のロードバランシングを行う方法について説明する。

《動画配信システムの構成》
図１１は、本実施形態の動画配信システムのシステム構成を示した図である。なお、本実施形態の動画配信システムにおいて、ＰＣ１００及び動画配信サーバ２００の各々の構成は上述した実施形態１と同様であるものとして、説明を省略するものとする。

本実施形態の動画配信システムは、中央サーバ１１００を含む。中央サーバ１１００は、ネットワーク３００を介して少なくともＰＣ１００と通信可能に接続される。中央サーバ１１００は、ＰＣ１００の各々がコンテンツ提供に際して接続すべき動画配信サーバ２００を決定し、該サーバの情報を対応するＰＣ１００に提供する。また本実施形態では、中央サーバ１１００は接続すべきデータセンタとして１つの動画配信サーバ２００を特定する情報をＰＣ１００に提供するものとして説明するが、本発明の実施はこれに限られるものではない。例えば、データセンタが複数の動画配信サーバ２００を有して構成される場合は、中央サーバ１１００はそのうちの１つの動画配信サーバ２００を特定する情報を提供する構成であってもよいし、単にデータセンタ（同一ロケーションに存在する動画配信サーバ２００を統合管理する単位）を特定する情報を提供する構成であってもよい。後者の場合、例えばデータセンタには、コンテンツ提供要求に対して提供を行うセンタ内の適切な動画配信サーバ２００を割り当て、対応するＰＣ１００を接続させる管理装置を有していればよい。

〈中央サーバ１１００の構成〉
図１２は、本実施形態に係る中央サーバ１１００の機能構成を示したブロック図である。

中央ＣＰＵ１１０１は、中央サーバ１１００が有する各ブロックの動作を制御する。具体的には中央ＣＰＵ１１０１は、中央ＲＯＭ１１０２に記憶されている各ブロックの動作プログラムを読み出し、中央ＲＡＭ１１０３に展開して実行することにより各ブロックの動作を制御する。

中央ＲＯＭ１１０２は、例えば書き換え可能な不揮発性メモリである。中央ＲＯＭ１１０２は、中央サーバ１１００が有する各ブロックの動作プログラムに加え、各ブロックの動作に必要となるパラメータ等を格納する。また本実施形態では中央ＲＯＭ１１０２は、ネットワーク３００上の動画配信サーバ２００で提供可能な複数のゲームコンテンツのそれぞれについて、少なくとも
・コンテンツについて要求される、ユーザの操作入力に対するレスポンス性能の情報
・コンテンツの描画においてDeferred Renderingが使用されるか否かの情報
を管理情報として記憶する。中央ＲＡＭ１１０３は、揮発性メモリである。中央ＲＡＭ１１０３は、各ブロックの動作プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に格納する格納領域としても用いられる。

中央通信部１１０４は、中央サーバ１１００が有する通信インタフェースである。中央通信部１１０４は、ネットワーク３００を介して接続した、ＰＣ１００等の他の機器との間でデータの送受信を行う。通信部１０５及びサーバ通信部２０８と同様に、中央通信部１１０４は、データの送受信時に必要なデータ変換等を行う。

《開始時処理》
以下、ゲームコンテンツの提供要求を開始する際に、本実施形態のＰＣ１００において実行される開始時処理について、図１３のフローチャートを参照して詳細を説明する。なお、本開始時処理は、例えばＰＣ１００において複数のゲームコンテンツのサービス提供を受けることが可能なポータルアプリケーションが実行された際に開始されるものとして説明する。

Ｓ１３０１で、ＣＰＵ１０１は、ゲームコンテンツを提供している動画配信サーバ２００に接続するための情報である接続先情報を中央サーバ１１００に要求する。接続先情報は、例えばサービス提供を行なっている動画配信サーバ２００のＩＰアドレスリストであってよく、予め中央サーバ１１００が中央ＲＯＭ１１０２に保持している保持している情報であってよい。

Ｓ１３０２で、ＣＰＵ１０１は、接続先情報の提供要求に応じて受信した接続先情報を参照し、ネットワーク３００上に存在する複数の動画配信サーバ２００の各々に対して接続テストを実行する。接続テストでは、ＣＰＵ１０１は対象の動画配信サーバ２００との通信において生じる通信遅延量を計測し、該サーバの識別情報に関連付けて通信遅延量の情報をリストとしてＲＡＭ１０３に記憶する。ＣＰＵ１０１は、接続先情報に含まれる動画配信サーバ２００について通信遅延量の計測が終了すると、処理をＳ１３０３に移す。

Ｓ１３０３で、ＣＰＵ１０１は、提供要求を開始するゲームコンテンツの選択がなされたか否かを判断する。具体的にはＣＰＵ１０１は、ユーザが提供を所望するゲームコンテンツを選択したことにより出力される制御信号を操作入力部１０７から受信したか否かにより判断を行う。ＣＰＵ１０１は、提供要求を開始するゲームコンテンツの選択がなされたと判断した場合は処理をＳ１３０４に移し、なされていないと判断した場合は本ステップの処理を繰り返す。

Ｓ１３０４で、ＣＰＵ１０１は、提供要求するゲームコンテンツを指定する情報と、Ｓ１３０２において生成した動画配信サーバ２００ごとの通信遅延量のリストとを中央サーバ１１００に送信する。

Ｓ１３０５で、ＣＰＵ１０１は、中央サーバ１１００からゲームコンテンツの提供を行う動画配信サーバ２００を指定するサーバ指定情報を受信したか否かを判断する。サーバ指定情報は、中央サーバ１１００において後述の提供サーバ決定処理が実行されることにより生成される。ＣＰＵ１０１は、指定情報を受信したと判断した場合は処理をＳ１３０６に移し、受信していないと判断した場合は本ステップの処理を繰り返す。

Ｓ１３０６で、ＣＰＵ１０１は、サーバ指定情報により指定される動画配信サーバ２００に対し、選択されたゲームコンテンツの提供要求を送信することで、動画配信処理を動画配信サーバ２００に開始させることができる。

《提供サーバ決定処理》
次に、本実施形態の中央サーバ１１００で実行される、ＰＣ１００において指定されたゲームコンテンツを提供する動画配信サーバ２００を決定する提供サーバ決定処理について、図１４のフローチャートを参照して詳細を説明する。なお、本提供サーバ決定処理は、中央サーバ１１００が起動された際に開始されるものとして説明する。

Ｓ１４０１で、中央ＣＰＵ１１０１は、ネットワーク３００上のＰＣ１００から、提供要求するゲームコンテンツを指定する情報（コンテンツ指定情報）と、該ＰＣ１００と各動画配信サーバ２００との通信遅延量のリストとを受信したか否かを判断する。中央ＣＰＵ１１０１は、コンテンツ指定情報及び通信遅延量リストを受信したと判断した場合、該情報を送信したＰＣ１００（対象ＰＣ）を識別する情報とともに中央ＲＡＭ１１０３に格納し、処理をＳ１４０２に移す。情報を送信したＰＣ１００を識別する情報は、例えば該ＰＣのＩＰアドレスであってよい。また中央ＣＰＵ１１０１は、コンテンツ指定情報及び通信遅延量リストを受信していないと判断した場合は本ステップの処理を繰り返す。

Ｓ１４０２で、中央ＣＰＵ１１０１は、コンテンツ指定情報により指定されるコンテンツ（指定コンテンツ）が、ユーザの操作入力に対してレスポンスが高いことが要求されるリアルタイム性の高いコンテンツとして指定されているか否かを判断する。具体的には中央ＣＰＵ１１０１は、中央ＲＯＭ１１０２に記憶されている管理情報を参照し、指定コンテンツがリアルタイム性の高いコンテンツとして指定されているか否かを判断する。中央ＣＰＵ１１０１は、指定コンテンツがリアルタイム性の高いコンテンツとして指定されていると判断した場合は処理をＳ１４０３に移し、指定されていないと判断した場合は処理をＳ１４０６に移す。

Ｓ１４０３で、中央ＣＰＵ１１０１は管理情報を参照し、指定コンテンツがDeferred Renderingを使用して提供画面を描画するコンテンツであるか否かを判断する。中央ＣＰＵ１１０１は、指定コンテンツがDeferred Renderingを使用して提供画面を描画するコンテンツであると判断した場合は処理をＳ１４０５に移し、使用せずに提供画面を描画するコンテンツであると判断した場合は処理をＳ１４０４に移す。

Ｓ１４０４で、中央ＣＰＵ１１０１は受信した通信遅延量リストを参照し、対象ＰＣとのデータ通信における通信遅延量が所定の閾値（第１の閾値）よりも低い１つの動画配信サーバ２００を選択する。そして中央ＣＰＵ１１０１は、選択した動画配信サーバ２００を特定する情報を指定情報として対象ＰＣに送信し、処理をＳ１４０１に戻す。

一方、Ｓ１４０３において指定コンテンツがDeferred Renderingを使用して提供画面を描画するコンテンツであると判断した場合、中央ＣＰＵ１１０１はＳ１４０５で、受信した通信遅延量リストを参照し、通信遅延量が所定の閾値（第２の閾値）よりも低く、第１の閾値よりも高い１つの動画配信サーバ２００を選択する。これは、影響画面の生成にDeferred Renderingが使用される場合は、実施形態１で説明したように前段の描画処理で生成された深度バッファを利用することで符号化及び復号に要する処理時間を短縮することができることによる。即ち、リアルタイム性が要求されるコンテンツであっても、少なくとも２段階の描画処理を行なって提供画面が生成される場合は処理の短縮が見込めるため、１段階の描画処理を行うコンテンツよりは通信遅延量を許容することができる。中央ＣＰＵ１１０１は、このようにして選択した動画配信サーバ２００を特定する情報を指定情報として対象ＰＣに送信し、処理をＳ１４０１に戻す。

またＳ１４０２において指定コンテンツがリアルタイム性の高いコンテンツとして指定されていないと判断した場合、中央ＣＰＵ１１０１はＳ１４０６で、受信した通信遅延量リストを参照し、通信遅延量が所定の閾値（第３の閾値）よりも低く、第２の閾値よりも大きい１つの動画配信サーバ２００を選択する。そして中央ＣＰＵ１１０１は、選択した動画配信サーバ２００を特定する情報を指定情報として対象ＰＣに送信し、処理をＳ１４０１に戻す。

なお、第１の閾値及び第２の閾値はコンテンツについて要求されるリアルタイム性を満たすように、また第３の閾値は許容可能な通信遅延量に基づいて決定される。３つの閾値は、コンテンツごとに定められるものであってもよいし、コンテンツによらず共通に定められるものであってもよい。また３つの閾値は、対象ＰＣの存在する地理的な位置に応じて定められるものであってもよい。

このように、本実施形態の動画配信システムでは、ＰＣ１００において選択されたコンテンツを提供する動画配信サーバ２００を、サーバとの通信遅延量及びコンテンツに要求されるリアルタイム性に応じて決定することができる。またさらに、コンテンツが少なくとも２段階の描画処理によって提供画面を生成するコンテンツであるか否かに応じて、好適な動画配信サーバ２００を選択することで、効率よくロードバランシングを行うことができる。

なお、本実施形態ではサーバとの通信遅延量及びコンテンツに要求されるリアルタイム性に応じて、コンテンツを提供するサーバを決定するものとして説明したが、本発明の実施はこれに限られるものではない。例えば、コンテンツの提供要求を送信したクライアント機器及びサーバの地理的な位置に応じて絞り込みを行う等、複合的な条件をさらに組み合わせて動画配信サーバ２００の決定を行う構成であってもよい。

本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

本願は、２０１２年４月１２日提出の日本国特許出願特願２０１２−０９１３５７を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。

Claims (8)

1. 複数の外部の描画装置のうちからゲームコンテンツに係る画面の描画を行う描画装置を決定するコンピュータに、
   ゲームコンテンツについて要求される、操作入力への応答性を取得する処理と、
   ゲームコンテンツに係る画面の提供先である受信装置と、前記複数の描画装置の各々との通信遅延量を取得する処理と、
   前記応答性と前記通信遅延量とに基づいて、前記複数の描画装置のうちの１つの描画装置を前記描画を行う描画装置として決定する処理と、
   を実行させるプログラム。
2. 前記決定する処理は、ゲームコンテンツが要求される前記応答性が高いと定められたコンテンツである場合に、前記複数の描画装置のうちの前記通信遅延量が第１の閾値以下の描画装置を前記描画を行う描画装置として決定する請求項１に記載のプログラム。
3. 前記プログラムは、
   前記受信装置から提供を要求されたゲームコンテンツを特定する処理と、
   前記要求されたゲームコンテンツが、該ゲームコンテンツに係る画面の描画において少なくとも２段階の描画処理であって、前段の描画処理の結果を用いて後段の描画処理を行って該ゲームコンテンツに係る画面を描画するゲームコンテンツであるかを判断する処理と、を前記コンピュータにさらに実行させ、
   前記決定する処理は、前記要求されたゲームコンテンツが前記少なくとも２段階の描画処理を行って該ゲームコンテンツに係る画面を描画するゲームコンテンツである場合に、前記複数の描画装置のうちの前記通信遅延量が前記第１の閾値より大きい第２の閾値以下の描画装置を前記描画を行う描画装置として決定する請求項２に記載のプログラム。
4. 前記決定する処理は、前記要求されたゲームコンテンツが前記応答性が高いと定められたコンテンツであり、かつ前記少なくとも２段階の描画処理を行って該ゲームコンテンツに係る画面を描画するゲームコンテンツである場合に、前記複数の描画装置のうちの前記通信遅延量が前記第１の閾値より大きい前記第２の閾値以下の描画装置を前記描画を行う描画装置として決定する請求項３に記載のプログラム。
5. 前記決定する処理は、ゲームコンテンツが要求される前記応答性が高いコンテンツではない場合に、前記複数の描画装置のうちの前記通信遅延量が前記第２の閾値より大きい第３の閾値以下の描画装置を前記描画を行う描画装置として決定する請求項３または４に記載のプログラム。
6. 請求項１乃至５のいずれか１項に記載のプログラムを記録したコンピュータが読み取り可能な記録媒体。
7. 複数の外部の描画装置のうちからゲームコンテンツに係る画面の描画を行う描画装置を決定する情報処理装置であって、
   ゲームコンテンツについて要求される、操作入力への応答性を取得する第１の取得手段と、
   ゲームコンテンツに係る画面の提供先である受信装置と、前記複数の描画装置の各々との通信遅延量を取得する第２の取得手段と、
   前記第１の取得手段により取得された前記応答性と前記第２の取得手段により取得された前記通信遅延量とに基づいて、前記複数の描画装置のうちの１つの描画装置を前記描画を行う描画装置として決定する決定手段と、
   を有する情報処理装置。
8. 複数の外部の描画装置のうちからゲームコンテンツに係る画面の描画を行う描画装置を決定する情報処理装置の制御方法であって、
   ゲームコンテンツについて要求される、操作入力への応答性を取得する第１の取得工程と、
   ゲームコンテンツに係る画面の提供先である受信装置と、前記複数の描画装置の各々との通信遅延量を取得する第２の取得工程と、
   前記第１の取得工程において取得された前記応答性と前記第２の取得工程において取得された前記通信遅延量とに基づいて、前記複数の描画装置のうちの１つの描画装置を前記描画を行う描画装置として決定する決定工程と、
   を有する情報処理装置の制御方法。

Images