(57)【要約】【課題】リアルタイム生成されるフレーム画像のストリーミングにおいてクライアント側のバッファ状態をより高い精度で管理する。【解決手段】フレーム画像をリアルタイム生成し、上記フレーム画像をエンコードしてエンコードデータを生成し、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信するストリーミング処理部と、上記クライアント装置における上記フレーム画像の出力タイミングに関する情報を上記クライアント装置から受信し、上記出力タイミングと上記ストリーミング処理部における上記フレーム画像の処理タイミングとが所定の関係を維持するように上記処理タイミングを制御する制御部とを含むサーバ装置が提供される。【選択図】図５
2014075736.tif 000002
【特許請求の範囲】
【請求項１】
フレーム画像をリアルタイム生成し、前記フレーム画像をエンコードしてエンコードデータを生成し、前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信するストリーミング処理部と、
前記クライアント装置における前記フレーム画像の出力タイミングに関する情報を前記クライアント装置から受信し、前記出力タイミングと前記ストリーミング処理部における前記フレーム画像の処理タイミングとが所定の関係を維持するように前記処理タイミングを制御する制御部と
を備えるサーバ装置。
【請求項２】
前記制御部は、前記出力タイミングを規定する第１の同期信号の周期を示す情報を受信し、前記第１の同期信号の周期と前記処理タイミングを規定する第２の同期信号の周期との周期差が小さくなるように前記処理タイミングを制御する、請求項１に記載のサーバ装置。
【請求項３】
前記制御部は、前記クライアント装置において前記フレーム画像の出力処理が開始された第１のタイミングを示す情報を受信し、前記ストリーミング処理部において当該フレーム画像の生成が開始された第２のタイミングと比較することによって前記周期差を算出する、請求項２に記載のサーバ装置。
【請求項４】
前記制御部は、前記クライアント装置が前記エンコードデータを受信してから前記フレーム画像が出力されるまでの経過時間を示す情報を受信し、前記経過時間の変化に基づいて前記周期差を算出する、請求項２に記載のサーバ装置。
【請求項５】
前記制御部は、前記クライアント装置が前記第１の同期信号の周期ごとに送信する信号を受信し、前記信号の受信周期を前記第２の同期信号の周期と比較することによって前記周期差を算出する、請求項２に記載のサーバ装置。
【請求項６】
前記制御部は、前記周期差を所定の期間にわたって算出し、算出された周期差の平均値を所定の閾値と比較した結果に応じて前記処理タイミングを制御する、請求項２に記載のサーバ装置。
【請求項７】
前記制御部は、前記処理タイミングと前記出力タイミングとの時間差を表す値が所定の範囲内に収まるように前記処理タイミングを制御する、請求項１に記載のサーバ装置。
【請求項８】
前記制御部は、前記クライアント装置において前記フレーム画像の出力処理が開始された第１のタイミングを示す情報を受信し、前記ストリーミング処理部において当該フレーム画像の生成が開始された第２のタイミングと比較することによって前記時間差を表す値を算出する、請求項７に記載のサーバ装置。
【請求項９】
前記制御部は、前記クライアント装置が前記エンコードデータを受信してから前記フレーム画像が出力されるまでの経過時間を示す情報を受信し、前記経過時間が所定の範囲内に収まるように前記処理タイミングを制御する、請求項７に記載のサーバ装置。
【請求項１０】
前記制御部は、前記クライアント装置が前記出力タイミングを規定する第１の同期信号の周期ごとに送信する信号を受信し、前記信号の受信タイミングと前記処理タイミングとの時間差が所定の範囲内に収まるように前記処理タイミングを制御する、請求項７に記載のサーバ装置。
【請求項１１】
前記制御部は、前記時間差を表す値を所定の期間にわたって取得し、取得された値の平均値を所定の閾値と比較した結果に応じて前記処理タイミングを制御する、請求項７に記載のサーバ装置。
【請求項１２】
前記制御部は、前記処理タイミングの制御として、前記処理タイミングを規定する第２の同期信号の周期を変更する、請求項１に記載のサーバ装置。
【請求項１３】
前記制御部は、前記処理タイミングの制御として、前記処理タイミングを前後させる、請求項１に記載のサーバ装置。
【請求項１４】
前記クライアント装置で取得された操作入力を、前記ネットワークを介して受信する受信部をさらに備え、
前記ストリーミング処理部は、前記操作入力に従って前記フレーム画像をリアルタイム生成する、請求項１に記載の画像処理装置。
【請求項１５】
フレーム画像をリアルタイム生成し、前記フレーム画像をエンコードしてエンコードデータを生成し、前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、
前記クライアント装置における前記フレーム画像の出力タイミングに関する情報を前記クライアント装置から受信し、前記出力タイミングと前記フレーム画像の処理タイミングとが所定の関係を維持するように前記処理タイミングを制御することと
を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、サーバ装置および情報処理方法に関する。
【背景技術】
【０００２】
サーバからネットワークを介してクライアントに映像や音声を配信するストリーミングでは、例えばネットワークにおける通信状態の変化に起因するデータ転送レートの変動（ジッタ）が生じる。データ転送レートが設計上の値よりも低い状態が継続したような場合には、クライアントにおいて表示されるべきフレーム画像がデータの転送の遅れのために表示されないフレーム欠損が生じる可能性がある。
【０００３】
フレーム欠損の発生を防ぐために、例えば、特許文献１に記載されているような技術が提案されている。これらの技術では、クライアントにおけるフレーム画像のデータのバッファ状態に応じて、サーバからのデータの送信レートを変更する。クライアントでバッファされているフレーム画像のデータが減少した場合にはデータの送信レートを低下させることで、画質は低下するもののフレーム欠損を防ぐことができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１１９９７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところが、サーバにおいてリアルタイムで生成されるフレーム画像を順次エンコードしてクライアントに送信するストリーミングでは、フレーム画像がサーバで生成されてからクライアントで出力されるまでの時間差を可能な限り小さくすることが求められる。この場合、クライアントでバッファされるフレーム画像は可能な限り少なくすることが望ましい。従って、上記のようなストリーミングのシステムでは、クライアントにおけるバッファのサイズが、上記の特許文献１などに記載された技術の場合よりもさらに小さくなる。
【０００６】
その結果、上述したようなネットワーク遅延に起因するフレーム欠損の発生やその影響をより高い精度で除去することも必要になるが、それとともに、ネットワーク遅延が小さい場合でも発生するフレーム欠損やバッファの溢れへの対策が求められる。本開示では、かかるフレーム欠損やバッファ溢れの発生原因を明らかにするとともに、リアルタイム生成されるフレーム画像のストリーミングにおいてクライアント側のバッファ状態をより高い精度で管理することが可能な、新規かつ改良された画像処理装置および画像処理方法を提案する。
【課題を解決するための手段】
【０００７】
本開示によれば、フレーム画像をリアルタイム生成し、上記フレーム画像をエンコードしてエンコードデータを生成し、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信するストリーミング処理部と、上記クライアント装置における上記フレーム画像の出力タイミングに関する情報を上記クライアント装置から受信し、上記出力タイミングと上記ストリーミング処理部における上記フレーム画像の処理タイミングとが所定の関係を維持するように上記処理タイミングを制御する制御部とを含むサーバ装置が提供される。
【０００８】
また、本開示によれば、フレーム画像をリアルタイム生成し、上記フレーム画像をエンコードしてエンコードデータを生成し、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、上記クライアント装置における上記フレーム画像の出力タイミングに関する情報を上記クライアント装置から受信し、上記出力タイミングと上記フレーム画像の処理タイミングとが所定の関係を維持するように上記処理タイミングを制御することとを含む情報処理方法が提供される。
【０００９】
クライアント装置におけるフレーム画像の出力タイミングと、サーバ装置におけるフレーム画像の処理タイミングとが所定の関係を維持することによって、クライアント装置におけるフレーム画像のバッファ状態がより適切な状態に保たれる。
【発明の効果】
【００１０】
以上説明したように本開示によれば、リアルタイム生成されるフレーム画像のストリーミングにおいてクライアント側のバッファ状態をより高い精度で管理することができる。
【図面の簡単な説明】
【００１１】
【図１】本開示の実施形態に係るストリーミングシステムの全体構成を概略的に示す図である。
【図２】本開示の実施形態に係るストリーミングシステムにおける情報の流れの例を示す図である。
【図３】本開示の実施形態に係るストリーミングシステムのクライアントおよびサーバの機能構成を概略的に示す図である。
【図４】本開示の実施形態におけるストリーミング処理部の機能構成を概略的に示す図である。
【図５】本開示の実施形態における同期信号の制御について説明するための図である。
【図６】本開示の実施形態における同期信号の制御の第１の例を示す図である。
【図７】本開示の実施形態における周期差に応じた処理の例を示すフローチャートである。
【図８】本開示の実施形態における同期信号の制御の第２の例を示す図である。
【図９】本開示の実施形態における同期信号の制御の第３の例を示す図である。
【図１０】情報処理装置のハードウェア構成を説明するためのブロック図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１３】
なお、説明は以下の順序で行うものとする。
１．ストリーミングシステムの構成
１−１．全体構成
１−２．クライアントおよびサーバの構成
１−３．ストリーミング処理部の構成
２．同期信号の制御に関する構成
２−１．第１の例
２−２．第２の例
２−３．第３の例
３．ハードウェア構成
４．補足
【００１４】
（１．ストリーミングシステムの構成）
まず、図１〜図４を参照して、本開示の実施形態が適用されるストリーミングシステムの構成について説明する。
【００１５】
（１−１．全体構成）
図１は、本開示の実施形態に係るストリーミングシステムの全体構成を概略的に示す図である。図１を参照すると、ストリーミングシステム１０は、クライアント１００と、クライアント１００にストリーミングコンテンツを配信するためのサーバ（サービサー２１０、ノード２２０、およびエッジ２３０）とを含む。クライアント１００および各サーバは、有線または無線の各種ネットワークによって互いに接続される。
【００１６】
サービサー２１０は、オリジナルのコンテンツ２１１を保持している。ノード２２０は、ＣＤＮ（Contents  Delivery  Network）を構成するノードであり、サービサー２１０が保持するオリジナルをコピーしたコンテンツ２２１を保持している。エッジ２３０は、クライアント１００と直接的にやりとりし、要求に応じてコンテンツを適宜加工してクライアント１００に提供する。このとき、エッジ２３０は、ノード２２０が保持しているコンテンツをキャッシュ２３１として取得し、これをクライアント１００からの要求に応じて提供する。
【００１７】
図２は、本開示の実施形態に係るストリーミングシステムにおける情報の流れの例を示す図である。コンテンツの配信に先立って、クライアント１００は、サービサー２１０のユーザ認証モジュール２１３にアクセスし、サービスにログインする。ログインに成功したクライアント１００は、エッジ２３０のセッションコントローラ２３３にアクセスし、クライアント１００のためのプロセスの開始を要求する。これに応じて、セッションコントローラ２３３はプロセス２３５を立ち上げる。
【００１８】
エッジ２３０では、プロセス２３５がクライアント１００ごとに立ち上げられ、各クライアント１００からの要求に応じてコンテンツ配信のための処理を実行する。従って、エッジ２３０が複数のクライアント１００にサービスを提供する場合、エッジ２３０では複数のプロセス２３５が立ち上げられうる。各プロセス２３５は、スケジューラ２３７によってスケジューリングされる。スケジューラ２３７は、セッションコントローラ２３３によって制御される。
【００１９】
一方、サービサー２１０が保持しているオリジナルのコンテンツ２１１は、ノード２２０に予めコピーされ、コンテンツ２２１として保持されている。エッジ２３０で起動されたプロセス２３５は、クライアント１００からの要求に応じて、ノード２２０で保持されているコンテンツ２２１をキャッシュとして取得し、これを適宜加工してクライアント１００に提供する。このとき、プロセス２３５は、クライアント１００からのどのような要求に応じてどのようにコンテンツを提供したかというログを記録してもよい。このログ、およびその他の情報は、プロセス２３５によってノード２２０に提供され、情報２２３として保持されてもよい。ログなどの情報２２３は、例えばサービサー２１０の付加機能２１５によって利用されうる。
【００２０】
（１−２．クライアントおよびサーバの構成）
図３は、本開示の実施形態に係るストリーミングシステムのクライアントおよびサーバの機能構成を概略的に示す図である。なお、サーバ３００は、図１，２を参照して説明したストリーミングシステムにおいてエッジ２３０として機能するサーバである。図では、クライアント１００に配信されるストリーミングコンテンツの流れを実線で示し、ストリーミングコンテンツの再生に関する制御情報の流れを破線で示している。
【００２１】
クライアント１００は、ユーザにストリーミングコンテンツを提供する装置であり、例えば各種のパーソナルコンピュータ、タブレット端末、携帯電話（スマートフォンを含む）、メディアプレーヤ、ゲーム機などでありうる。一方、サーバ３００は、単一のサーバ装置、または有線もしくは無線の各種ネットワークによって互いに接続される複数のサーバ装置の協働によって実現される機能の集合体である。クライアント１００、およびサーバ３００を構成する各サーバ装置は、いずれも、例えば後述する情報処理装置のハードウェア構成を用いて実現されうる。図示された構成要素のうち、入力装置および出力装置、およびデータ（記憶装置に記憶される）を除く各部分は、例えばＣＰＵ（Central  Processing  Unit）などのプロセッサによってソフトウェア的に実現されうる。
【００２２】
クライアント１００では、入力装置１１０がユーザの操作入力を取得する。入力装置１１０は、例えばサービスへのログインやコンテンツの選択などのコンテンツ外の操作入力と、例えば静止画／動画の切替えや画像の拡大／縮小、音声の音質切替えなどのコンテンツ内の操作入力とを取得する。コンテンツ外の操作入力は、セッションコントローラ１２０によって処理される。セッションコントローラ１２０は、例えばログインに関する入力情報をサービサー２１０に送信したり、ログイン後にプロセス開始の要求をサーバ３００に送信したりする。一方、コンテンツ内の操作入力は、入力送信部１３０からサーバ３００に送信される。
【００２３】
サーバ３００では、セッションコントローラ２３３が、クライアント１００からのプロセス開始の要求に応じてプロセス２３５を立ち上げる。プロセス２３５は、クライアント１００で入力装置１１０が取得したコンテンツの選択操作によって指定されたコンテンツ２２１を取得し、コンテンツキャッシュ２３１として保持する。コンテンツキャッシュ２３１はエンコードデータであり、サーバ３００ではデコーダ３１０がこれをデコードする。デコードされたコンテンツのデータは、ストリーム処理部／送信部３２０で処理される。
【００２４】
一方、クライアント１００で入力装置１１０が取得したコンテンツ内の操作入力は、入力受信部３３０によって受信され、プレーヤコントローラ３４０に提供される。プレーヤコントローラ３４０は、操作入力に従ってデコーダ３１０やストリーム処理部／送信部３２０を制御する。ストリーム処理部／送信部３２０は、この制御に従って、コンテンツのデータから映像や音声を生成する。さらに、ストリーム処理部／送信部３２０は、生成した映像や音声をエンコードしてクライアント１００に送信する。なお、図示された例では、コンテンツは映像および音声を含むが、他の例ではコンテンツが映像だけを含んでもよく、また音声だけを含んでもよい。
【００２５】
クライアント１００に送信されたエンコードデータは、ストリーム受信部／処理部１４０でデコードされ、映像や音声としてレンダリングされて、出力装置１５０からユーザに向けて出力される。ここで、サーバ側のストリーム処理部／送信部３２０と、クライアント側のストリーム受信部／処理部１４０とは、それぞれマネージャ３５０およびマネージャ１６０によって管理される。サーバ側のマネージャ３５０と、クライアント側のマネージャ１６０とは、必要に応じて情報を交換して協働する。
【００２６】
（１−３．ストリーミング処理部の構成）
図４は、本開示の実施形態におけるストリーミング処理部の機能構成を概略的に示す図である。図では、クライアント１００のストリーム受信部／処理部１４０、およびサーバ３００のストリーム処理部／送信部３２０の機能構成がそれぞれ示されている。
【００２７】
（クライアント側）
ストリーム受信部／処理部１４０は、ストリーム受信部１４１、デコーダ１４３、フレームバッファ１４５、およびレンダラ１４７を含む。ストリーム受信部１４１は、サーバ側のストリーム送信部３２７から所定のプロトコルに従ってデータを受信する。図示された例ではＲＴＰ（Real-Time  Transport  Protocol）が用いられる。この場合、ストリーム受信部１４１は、受信したデータをデコーダ１４３に提供するとともに、データの遅延などの通信状態を検出し、ＲＴＣＰ（RTP  Control  Protocol）を用いてストリーム送信部３２７に報告する。
【００２８】
デコーダ１４３は、ストリーム受信部１４１から提供されたデータをデコードして、映像データおよび音声データを得る。デコーダ１４３は、映像データをデコードする映像デコーダ１４３ａと、音声データをデコードする音声デコーダ１４３ｂとを含む。映像デコーダ１４３ａおよび音声デコーダ１４３ｂは、それぞれ複数の種類が用意されて、処理対象のデータのフォーマットに応じて選択的に使用されてもよい。なお、以下の説明では、デコーダ１４３ａおよびデコーダ１４３ｂの両方、またはいずれか一方を、単にデコーダ１４３と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００２９】
フレームバッファ１４５は、デコーダ１４３で得られた映像データおよび音声データをフレーム単位で一時的に蓄積する。フレームバッファ１４５は、映像データを蓄積するフレームバッファ１４５ａと、音声データを蓄積するフレームバッファ１４５ｂとを含む。フレームバッファ１４５は、マネージャ１６０の制御に従って、所定のタイミングで各フレームの映像データおよび音声データをレンダラ１４７に提供する。なお、以下の説明では、フレームバッファ１４５ａおよびフレームバッファ１４５ｂの両方、またはいずれか一方を、単にフレームバッファ１４５と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３０】
レンダラ１４７は、映像データをレンダリングしてディスプレイなどの出力装置に提供する映像レンダラ１４７ａと、音声データをレンダリングしてスピーカなどの出力装置に提供する音声レンダラ１４７ｂとを含む。映像レンダラ１４７ａと音声レンダラ１４７ｂとは、出力される映像と音声とのフレームを同期させる。また、レンダラ１４７は、出力したフレームのＩＤや、出力が実行された時刻などをマネージャ１６０に報告する。なお、以下の説明では、レンダラ１４７ａおよびレンダラ１４７ｂの両方、またはいずれか一方を、単にレンダラ１４７と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３１】
（サーバ側）
ストリーム処理部／送信部３２０は、レンダラ３２１、フレームバッファ３２３、エンコーダ３２５、およびストリーム送信部３２７を含む。レンダラ３２１は、デコーダ３１０によってデコードされたコンテンツのデータを素材として用いて、またプレーヤコントローラ３４０によるユーザの操作入力に基づく制御に従って、映像データおよび音声データを生成する。ここで、映像データおよび音声データについてフレームが定義され、映像データは連続するフレーム画像として生成される。
【００３２】
フレームバッファ３２３は、レンダラ３２１で生成された映像データおよび音声データをフレーム単位で一時的に蓄積する。フレームバッファ３２３は、映像データを蓄積するフレームバッファ３２３ａと、音声データを蓄積するフレームバッファ３２３ｂとを含む。フレームバッファ３２３に蓄積された映像データおよび音声データは、順次エンコーダ３２５によってエンコードされる。なお、以下の説明では、フレームバッファ３２３ａおよびフレームバッファ３２３ｂの両方、またはいずれか一方を、単にフレームバッファ３２３と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３３】
エンコーダ３２５は、映像データをエンコードする映像エンコーダ３２５ａと、音声データをエンコードする音声エンコーダ３２５ｂとを含む。映像エンコーダ３２５ａおよび音声エンコーダ３２５ｂは、それぞれ複数の種類が用意されて、クライアント１００で使用可能な映像デコーダ１４３ａおよび音声デコーダ１４３ｂの種類、または処理対象の映像データや音声データの特性に応じて選択的に使用されてもよい。エンコードされた映像データおよび音声データは、ストリーム送信部３２７からクライアント１００に送信される。なお、以下の説明では、エンコーダ３２５ａおよびエンコーダ３２５ｂの両方、または一方を、単にエンコーダ３２５と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３４】
以上で説明したような本実施形態に係るストリーミングシステムの構成によれば、エッジとして機能するサーバにおいて、ユーザの操作入力に応じて映像や音声をリアルタイム生成してクライアントに配信することが可能である。従って、例えば特開２０１０−１１７８２８号公報に記載された画像を自由に拡大／縮小したり移動したりするアプリケーションや、サイズの大きな画像や映像の閲覧、オンラインゲーム、シミュレーションビューアなどのさまざまなアプリケーションを、ユーザの操作入力に対する応答性を確保しつつストリーミングによって提供することができる。
【００３５】
（２．同期信号の制御に関する構成）
次に、図５〜図９を参照して、本開示の実施形態における同期信号周期の制御に関する構成について説明する。
【００３６】
図５は、本開示の実施形態における同期信号の制御について説明するための図である。
【００３７】
ストリーミングシステム１０において、上記のようなリアルタイム性の高いコンテンツを提供する場合、クライアント１００で出力前にバッファされるフレーム画像は、可能な限り少なく設定される。この場合、ネットワーク遅延によるフレーム欠損が発生しやすくなるのに加えて、ネットワーク遅延が小さくても、フレーム欠損やバッファの溢れが発生する場合がある。従って、ネットワーク遅延に起因するフレーム欠損の発生やその影響を高い精度で除去するとともに、それ以外の要因で発生するフレーム欠損やバッファの溢れへの対策も求められる。
【００３８】
そこで検討を進めた結果、上記のようなフレーム欠損やバッファの溢れの原因の１つとして、サーバ３００とクライアント１００との間での時刻のずれがあることが見出された。サーバ３００とクライアント１００との間では、共通するフレームレートが設定され、それぞれの装置において、このフレームレートに応じた所定の周期で生成される同期信号（例えば垂直同期信号（Ｖ  Ｓｙｎｃ））によってフレーム画像の生成やエンコード、デコード、出力のタイミングが規定される。ところが、サーバ３００とクライアント１００とのそれぞれでの時刻にずれがあると、それぞれの装置において同期信号が生成されるタイミングの関係が変化してしまい、その結果としてフレーム欠損やバッファの溢れが発生する。
【００３９】
例えば、それぞれの装置で時刻周期を規定する水晶振動子の振動数は、水晶振動子自体の特性や温度変化などによって変動する。それゆえ、時刻周期が装置間で異なる可能性がある。装置間で時刻周期が異なれば、時刻に基づいて定義される同期信号の周期も装置間でずれてしまう。このずれが蓄積すると、一方の装置での処理タイミングが次第に先行することになる。例えば、クライアント１００での同期信号の周期がクライアント３００よりも短い場合、クライアント１００での処理タイミングが次第に先行し、受信したフレーム画像を本来のタイミングよりも早いタイミングでどんどん出力してしまう結果、フレーム欠損が発生する可能性がある。逆に、サーバ３００での同期信号の周期がクライアント１００よりも短い場合、サーバ３００での処理タイミングが次第に先行し、クライアント１００が受信したフレーム画像を出力しないうちにどんどん送信してしまう結果、バッファの溢れが発生する可能性がある。
【００４０】
一方、装置間で時刻周期が一致していても、例えばネットワーク回線の輻輳などによって、時刻自体がずれてしまう可能性がある。そうすると、時刻に基づいて設定される同期信号の生成タイミングも装置間でずれてしまう。例えば、クライアント１００での時刻がサーバ３００よりもある程度以上進むと、クライアント１００での同期信号が本来のタイミングよりも早く生成されるために、フレーム画像を出力しようとするタイミングでサーバ３００からのデータが到達しておらず、フレーム欠損が発生する可能性がある。フレーム欠損が生じなくても、クライアント１００でバッファされるフレーム画像が本来よりも少なくなるために、ネットワーク遅延などによるフレーム欠損が一段と生じやすくなる。逆に、サーバ３００での時刻がクライアント１００よりもある程度以上進むと、サーバ３００での同期信号が本来のタイミングよりも早く生成されるために、クライアント１００が前のフレーム画像を出力しないうちに次のフレーム画像を送信してしまい、バッファの溢れが発生する可能性がある。
【００４１】
通常のストリーミングシステムでは、クライアントに用意されるバッファが大きいため、上記のような時刻のずれの影響はバッファによって吸収され、顕在化することはなかった。しかしながら、リアルタイム性の高いコンテンツを提供するストリーミングシステム１０では、クライアントに用意されるバッファが小さいため、上記のような時刻のずれの影響がフレーム欠損やバッファの溢れをもたらす可能性がある。
【００４２】
そこで、本実施形態では、クライアント１００のマネージャ１６０が、フレーム画像の出力タイミングに関する情報をレンダラ１４７から取得し、この情報をサーバ３００のマネージャ３５０に送信する。マネージャ３５０は、受信した情報に基づいて、クライアント１００におけるフレーム画像の出力タイミングとサーバ３００におけるフレーム画像の処理タイミングとが所定の関係を維持するように、ストリーム処理／送信部３２０での処理タイミングを制御する。
【００４３】
より具体的には、マネージャ３５０は、レンダラ３２１で用いられる、フレーム画像の生成タイミングを規定する同期信号（例えば垂直同期信号（Ｖ  Ｓｙｎｃ））の生成タイミングを制御する。ここで、マネージャ３５０は、クライアント１００とサーバ３００との間での同期信号の周期差が小さくなるように、サーバ３００での同期信号の周期を変更したり、サーバ３００での同期信号の生成タイミングを前後させたりしてもよい。また、マネージャ３５０は、クライアント１００とサーバ３００との間での同期信号の時間差が所定の範囲内に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００での同期信号の生成タイミングを前後させたりしてもよい。同期信号の生成タイミングが制御された場合、レンダラ３２１は、制御後の同期信号の生成タイミングに関する情報を、エンコーダ３２５に通知する。
【００４４】
以下、マネージャ３５０がクライアント１００から受信する情報と、その情報に基づいた処理タイミングの制御とに関する第１〜第３の例について説明する。
【００４５】
（２−１．第１の例）
図６は、本開示の実施形態における同期信号の制御の第１の例を示す図である。図示された例では、クライアント１００のレンダラ１４７が、フレーム画像の出力処理を開始した時刻ｔｃ［ｎ］をマネージャ１６０に報告する。サーバ３００のマネージャ３５０は、この時刻ｔｃ［ｎ］と、レンダラ３２１がフレーム画像の生成処理を開始した時刻ｔｓ［ｎ］とを比較する。なお、以下の説明において、［ｎ］は、時刻などがｎ番目のフレームについての値であることを示す。
【００４６】
（周期差に基づく制御）
マネージャ３５０は、時刻ｔｃ［ｎ］と時刻ｔｓ［ｎ］との差に基づいて、クライアント１００でフレーム画像の出力タイミングを規定している同期信号の周期ＴＣと、サーバ３００でフレーム画像の処理タイミングを規定している同期信号の周期ＴＳとの周期差を算出することができる。より具体的には、マネージャ３５０は、ｎ番目のフレーム画像についての時刻ｔｃ［ｎ］と時刻ｔｓ［ｎ］との差、およびｎ−１番目のフレーム画像についての時刻ｔｃ［ｎ−１］と時刻ｔｓ［ｎ−１］との差に基づいて、下記の式１によって周期差ｄ［ｎ］を算出する。
【００４７】
【数１】
2014075736.tif 000003
【００４８】
ここで、時刻ｔｃ［ｎ］は周期ＴＣに対応する所定のタイミングに設定されており（ｔｃ［ｎ］−ｔｃ［ｎ−１］＝ＴＣ）、時刻ｔｓ［ｎ］は周期ＴＳに対応する所定のタイミングに設定されている（ｔｓ［ｎ］−ｔｓ［ｎ−１］＝ＴＳ）。従って、周期ＴＣと周期ＴＳとが一致していれば、ｄ［ｎ］＝０になる。また、周期ＴＣと周期ＴＳとに差がある場合、ＴＣ＜ＴＳであればｄ［ｎ］＜０になり、ＴＣ＞ＴＳであればｄ［ｎ］＞０になる。
【００４９】
図７は、本開示の実施形態における周期差に応じた処理の例を示すフローチャートである。図示されているように、サーバ３００のマネージャ３５０は、周期差ｄ［ｎ］を所定の期間にわたって算出して、算出された周期差の平均値Ｄを所定の閾値と比較した結果に応じて、サーバ３００における同期信号の周期ＴＳを変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。
【００５０】
まず、初期値としてｎ＝ｎ０が設定される（ステップＳ１０１）。ｎ０は、例えば、マネージャ３５０が同期信号の制御を開始する任意のフレームに対応する。次に、マネージャ３５０は、周期差ｄ［ｎ］の所定の期間における移動平均Ｄを算出する（ステップＳ１０３）。移動平均Ｄは、所定の期間における周期ＴＣと周期ＴＳとの周期差の平均値を表す。
【００５１】
ここで、所定の期間は、例えばウインドウサイズｗ（ｎ０＞ｗ）によって規定される。マネージャ３５０は、ｎ−ｗ番目からｎ番目までのｗ＋１フレームについて、時刻ｔｃ［ｎ］と時刻ｔｓ［ｎ］との差に基づいて周期ＴＣと周期ＴＳとの周期差を算出し、下記の式２によって移動平均Ｄを取得する。
【数２】
2014075736.tif 000004
【００５２】
次に、マネージャ３５０は、移動平均Ｄを正の閾値ＴＰと比較する（ステップＳ１０５）。ここで、Ｄ＞ＴＰであれば（ＹＥＳ）、マネージャ３５０はサーバ３００における同期信号の周期ＴＳを時間ｄＴ１だけ延長する（ステップＳ１０７）。閾値ＴＰは、例えば、周期ＴＣが周期ＴＳよりもＴＰだけ長い状態が続くと、近い将来にバッファの溢れが発生する可能性があるような値として設定される。時間ｄＴ１は、例えば移動平均Ｄの値に基づいて動的に設定されてもよいし（例えばｄＴ１＝Ｄ）、閾値ＴＰに等しい値などの定数であってもよい。
【００５３】
一方、ステップＳ１０５においてＤ＞ＴＰではなかった場合（ＮＯ）、マネージャ３５０は、移動平均Ｄを負の閾値ＴＭと比較する（ステップＳ１０７）。ここで、Ｄ＜ＴＭであれば（ＹＥＳ）、マネージャ３５０はサーバ３００における同期信号の周期ＴＳを時間ｄＴ２だけ短縮する。閾値ＴＭは、例えば、周期ＴＳが周期ＴＣよりもＴＭだけ長い状態が続くと、近い将来にフレーム欠損が発生する可能性があるような値として設定される。時間ｄＴ２は、例えば移動平均Ｄの値に基づいて動的に設定されてもよいし（例えばｄＴ２＝｜Ｄ｜）、例えば閾値ＴＭの大きさ（｜ＴＭ｜）に等しい値などの定数であってもよい。
【００５４】
ステップＳ１０７においてＤ＜ＴＭではなかった場合（ＮＯ）、マネージャ３５０はこのサイクルではサーバ３００における同期信号の周期ＴＳを変更しない。マネージャ３５０は、ｎ＝ｎ＋１として、次のフレームを対象とした処理に移行する（ステップＳ１０３）。
【００５５】
（時間差に基づく制御）
マネージャ３５０は、時刻ｔｃ［ｎ］と時刻ｔｓ［ｎ］との差に基づいて、クライアント１００でフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差を算出することができる。より具体的には、マネージャ３５０は、時刻ｔｃ［ｎ］と時刻ｔｓ［ｎ］との時間差を、クライアント１００でフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差であると定義する。図では、説明のためにこの時間差が同期信号の周期（ＴＣまたはＴＳ）よりも短いように示されているが、実際には、クライアント１００でフレーム画像がバッファされるために、時間差は同期信号の周期よりも長いものでありうる。
【００５６】
例えばネットワーク回線の輻輳などによってクライアント１００での時刻とサーバ３００での時刻とがずれていると、上記の時間差が、設計上の範囲よりも短かったり長かったりする可能性がある。時間差が短すぎる、つまり時刻ｔｃ［ｎ］が時刻ｔｓ［ｎ］に近すぎる場合、クライアント１００でバッファされているフレーム画像が本来の数よりも少ないために、ネットワーク遅延が増大するとフレーム欠損が発生する可能性がある。一方、時間差が長すぎる、つまり時刻ｔｃ［ｎ］が時刻ｔｓ［ｎ］から離れすぎている場合、その時点ではバッファの溢れが発生していなくても、例えばその後ネットワーク遅延が減少してより多くのフレーム画像がクライアント１００に到達した場合に、バッファの溢れが発生する可能性がある。
【００５７】
そこで、マネージャ３５０は、クライアント１００でのフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差が所定の範囲内に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりする。時間差の所定の範囲は、例えば、サーバ３００とクライアント１００との間で想定されるネットワーク遅延の状態や、クライアント１００でどのぐらいのフレーム画像をバッファするのが適切かを考慮して決定されうる。なお、ここで、マネージャ３５０は、クライアント１００やサーバ３００の時刻自体を調整する必要はない。クライアント１００におけるフレーム画像のバッファ状態を正常な状態に保ち、フレーム画像を円滑に出力させるためには、クライアント１００でのフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとが所定の関係を維持していれば十分だからである。
【００５８】
以上で説明した時間差に基づく制御でも、上記で図７を参照して説明した周期差に基づく制御と同様に、時間差を所定の期間にわたって算出して平滑化して扱うことが望ましい。この場合、例えば、図７のステップＳ１０３において、ｄ［ｎ］が以下の式３によって算出される。
【００５９】
【数３】
2014075736.tif 000005
【００６０】
ここで、ｔｓｃは、クライアント１００でのフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差の設計値である。続くステップＳ１０５，Ｓ１０７では、式３によって算出された時間差の設計値（所定の値）との差分ｄ［ｎ］の移動平均Ｄ（式２によって算出）が、正負それぞれの閾値ＴＰ，ＴＭと比較される。従って、この例では、設計値ｔｓｃが時間差の所定の範囲の基準値を規定し、閾値ＴＰが時間差の所定の範囲の上限を規定し、閾値ＴＭが時間差の所定の範囲の下限を規定する。
【００６１】
（２−２．第２の例）
図８は、本開示の実施形態における同期信号の制御の第２の例を示す図である。図示された例では、クライアント１００のレンダラ１４７（またはストリーム受信部１４１）が、クライアント１００がエンコードデータを受信してからフレーム画像が出力されるまでの経過時間ｐ［ｎ］をマネージャ１６０に報告する。サーバ３００のマネージャ３５０は、この経過時間ｐ［ｎ］に基づいて周期差や時間差を算出することができる。
【００６２】
（周期差に基づく制御）
マネージャ３５０は、各フレームの経過時間ｐ［ｎ］に基づいて、クライアント１００でフレーム画像の出力タイミングを規定している同期信号の周期ＴＣと、サーバ３００でフレーム画像の処理タイミングを規定している同期信号の周期ＴＳとの周期差を算出することができる。より具体的には、マネージャ３５０は、ｎ番目のフレーム画像についての経過時間ｐ［ｎ］、およびｎ−１番目のフレーム画像についての経過時間ｐ［ｎ−１］との差に基づいて、下記の式４によって周期差ｄ［ｎ］を算出する。
【００６３】
【数４】
2014075736.tif 000006
【００６４】
この第２の例において、周期ＴＣはクライアント１００における垂直同期信号（Ｖ  Ｓｙｎｃ）の周期である。従って、経過時間ｐ［ｎ］の終わりは周期ＴＣの終わりに一致し、ここで垂直同期信号が生成されてフレーム画像が出力（表示）される。一方、経過時間ｐ［ｎ］の始まりは、サーバ３００での周期ＴＳの始まりから、レンダラ３２１によるフレーム画像の生成時間と、エンコーダ３２５によるフレーム画像のエンコード時間と、ストリーム送信部３２７からストリーム受信部１４１までの伝送時間とが経過した時刻である。これらの処理時間や伝送時間は多くの場合一定であるため、経過時間ｐ［ｎ］の始まりは周期ＴＳを反映している。
【００６５】
従って、周期ＴＣと周期ＴＳとが一致していれば、毎回の経過時間ｐ［ｎ］はほぼ一定であり、上記の式４によって算出されるｄ［ｎ］＝０になる。一方、周期ＴＣと周期ＴＳとに差があり、ＴＣ＜ＴＳの場合、経過時間ｐ［ｎ］の始まり（受信タイミング：周期ＴＳ）に対して終わり（出力タイミング：周期ＴＣ）が次第に近づいてくるため、経過時間ｐ［ｎ］は次第に短くなり、ｄ［ｎ］＜０になる。また、ＴＣ＞ＴＳの場合、経過時間ｐ［ｎ］の始まり（受信タイミング：周期ＴＳ）に対して終わり（出力タイミング：周期ＴＣ）が次第に遠ざかるため、経過時間ｐ［ｎ］は次第に長くなり、ｄ［ｎ］＞０になる。
【００６６】
ここで、サーバ３００のマネージャ３５０は、第１の例と同様に周期差ｄ［ｎ］を所定の期間にわたって算出して、算出された周期差の平均値を所定の閾値と比較した結果に応じて、サーバ３００における同期信号の周期ＴＳを変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。この処理については、周期差ｄ［ｎ］が上記の式４を用いて算出される以外は、図７を参照して説明した処理と同様であるため、詳細な説明は省略する。
【００６７】
（時間差に基づく制御）
マネージャ３５０は、経過時間ｐ［ｎ］を、クライアント１００でのフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差を表す値として扱うことができる。より具体的には、マネージャ３５０は、フレーム画像に関するサーバ３００での処理時間や伝送時間を所定の時間であるとみなし、経過時間ｐ［ｎ］の変化によって時間差の変動を検出する。なお、図では、説明のために経過時間ｐ［ｎ］が同期信号の周期（ＴＣまたはＴＳ）よりも短いように示されているが、実際には、クライアント１００でフレーム画像がバッファされるために、経過時間ｐ［ｎ］は同期信号の周期よりも長いものでありうる。
【００６８】
経過時間ｐ［ｎ］は、クライアント１００でバッファされているフレーム画像の数を表すため（バッファされているフレーム画像の数＝経過時間ｐ［ｎ］／周期ＴＣ）、マネージャ３５０は、経過時間ｐ［ｎ］が所定の範囲に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。あるいは、マネージャ３５０は、経過時間ｐ［ｎ］に処理時間や伝送時間に対応する所定の時間を加えて時間差を算出し、算出された時間差が所定の範囲内に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。時間差の所定の範囲は、例えば、サーバ３００とクライアント１００との間で想定されるネットワーク遅延の状態や、クライアント１００でどのぐらいのフレーム画像をバッファするのが適切かを考慮して決定されうる。
【００６９】
以上で説明した時間差に基づく制御でも、上記で図７を参照して説明した例と同様に、経過時間または時間差を所定の期間にわたって算出して平滑化して扱うことが望ましい。この場合、例えば、図７のステップＳ１０３において、ｄ［ｎ］が以下の式５によって算出される。
【００７０】
【数５】
2014075736.tif 000007
【００７１】
ここで、ｐｃは、クライアント１００がエンコードデータを受信してからフレーム画像が出力されるまでの経過時間の設計値である。続くステップＳ１０５，Ｓ１０７では、式５によって算出された経過時間の設計値（所定の値）との差分ｄ［ｎ］の移動平均Ｄ（式２によって算出）が、正負それぞれの閾値ＴＰ，ＴＭと比較される。従って、この例では、設計値ｐｃが経過時間の所定の範囲の基準値を規定し、閾値ＴＰが経過時間の所定の範囲の上限を規定し、閾値ＴＭが経過時間の所定の範囲の下限を規定する。
【００７２】
（２−３．第３の例）
図９は、本開示の実施形態における同期信号の制御の第３の例を示す図である。図示された例では、クライアント１００において同期信号（例えば垂直同期信号（Ｖ  Ｓｙｎｃ））が生成されるタイミングで、クライアント１００のマネージャ１６０からサーバ３００のマネージャ３５０に通知が送信される。マネージャ３５０は、この通知が受信された時刻ｔｒ［ｎ］に基づいて周期差や時間差を算出することができる。
【００７３】
（周期差に基づく制御）
マネージャ３５０は、各フレームについての通知の受信時刻ｔｒ［ｎ］に基づいて、クライアント１００でフレーム画像の出力タイミングを規定している同期信号の周期ＴＣと、サーバ３００でフレーム画像の処理タイミングを規定している同期信号の周期ＴＳとの周期差を算出することができる。より具体的には、マネージャ３５０は、通知の伝送におけるネットワーク遅延がほぼ一定であり、ｎ番目のフレームについての通知の受信時刻ｔｒ［ｎ］とｎ−１番目のフレームについての通知の受信時刻ｔｒ［ｎ−１］との差が周期ＴＣに等しいとみなして、下記の式６によって周期差ｄ［ｎ］を算出する。
【００７４】
【数６】
2014075736.tif 000008
【００７５】
上記の式６において周期ＴＣと周期ＴＳとが一致していればｄ［ｎ］＝０になり、ＴＣ＜ＴＳであればｄ［ｎ］＜０であり、ＴＣ＞ＴＳであればｄ［ｎ］＞０になることは明らかである。
【００７６】
ここで、サーバ３００のマネージャ３５０は、第１の例と同様に周期差ｄ［ｎ］を所定の期間にわたって算出して、算出された周期差の平均値を所定の閾値と比較した結果に応じて、サーバ３００における同期信号の周期ＴＳを変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。この処理については、周期差ｄ［ｎ］が上記の式６を用いて算出される以外は、図７を参照して説明した処理と同様であるため、詳細な説明は省略する。
【００７７】
（時間差に基づく制御）
マネージャ３５０は、フレームについての通知の受信時刻ｔｒ［ｎ］を、クライアント１００でのフレーム画像の出力タイミングとサーバ３００でのフレーム画像の処理タイミングとの時間差を表す値として扱うことができる。より具体的には、マネージャ３５０は、通知の伝送におけるネットワーク遅延がほぼ一定であるとみなし、受信時刻ｔｒ［ｎ］とレンダラ３２１がフレーム画像の生成処理を開始した時刻（サーバ３００において同期信号が生成される時刻）ｔｓ［ｎ］との差の変化によって時間差の変動を検出する。上記の第１の例と同様に、マネージャ３５０は、時刻ｔｒ［ｎ］と時刻ｔｓ［ｎ］との差が所定の範囲内に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりする。あるいは、マネージャ３５０は、時刻ｔｒ［ｎ］と時刻ｔｓ［ｎ］との差からネットワーク遅延の見積もり時間を差し引いて時間差を算出し、算出された時間差が所定の範囲内に収まるように、サーバ３００での同期信号の周期を変更したり、サーバ３００でのフレーム画像の処理タイミングを前後させたりしてもよい。時間差の所定の範囲は、例えば、サーバ３００とクライアント１００との間で想定されるネットワーク遅延の状態や、クライアント１００でどのぐらいのフレーム画像をバッファするのが適切かを考慮して決定されうる。
【００７８】
以上で説明した時間差に基づく制御でも、上記で図７を参照して説明した例と同様に、時刻ｔｒ［ｎ］と時刻ｔｓ［ｎ］との差または時間差を所定の期間にわたって算出して平滑化して扱うことが望ましい。この場合、例えば、図７のステップＳ１０３において、ｄ［ｎ］が以下の式７によって算出される。
【００７９】
【数７】
2014075736.tif 000009
【００８０】
ここで、ｔｒｓは、サーバ３００において同期信号が生成される時刻と、クライアント１００において同期信号が生成されるタイミングで送信された通知がサーバ３００で受信される時刻の差の設計値である。続くステップＳ１０５，Ｓ１０７では、式７によって算出された時刻の差の設計値（所定の値）との差分ｄ［ｎ］の移動平均Ｄ（式２によって算出）が、正負それぞれの閾値ＴＰ，ＴＭと比較される。従って、この例では、設計値ｐｃが時刻の差の所定の範囲の基準値を規定し、閾値ＴＰが時刻の差の所定の範囲の上限を規定し、閾値ＴＭが時刻の差の所定の範囲の下限を規定する。
【００８１】
以上、マネージャ３５０がクライアント１００から受信する情報と、その情報に基づいた処理タイミングの制御とに関する第１〜第３の例について説明した。本開示の実施形態にはこれには限られず、例えば同様の情報を抽出可能な他の情報がクライアント１００からサーバ３００に報告されてもよい。また、各例で説明した周期差に基づく制御および時間差に基づく制御は、いずれか一方だけが実行されてもよく、また両方実行されてもよい。
【００８２】
（３．ハードウェア構成）
次に、図１０を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図１０は、情報処理装置のハードウェア構成を説明するためのブロック図である。図示された情報処理装置９００は、例えば、上記の実施形態におけるクライアント１００およびサーバ３００を実現しうる。
【００８３】
情報処理装置９００は、ＣＰＵ（Central  Processing  unit）９０１、ＲＯＭ（Read  Only  Memory）９０３、およびＲＡＭ（Random  Access  Memory）９０５を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２３、通信装置９２５を含んでもよい。情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital  Signal  Processor）などの処理回路を有してもよい。
【００８４】
ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９、またはリムーバブル記録媒体９２７に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３、およびＲＡＭ９０５は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral  Component  Interconnect/Interface）バスなどの外部バス９１１に接続されている。
【００８５】
入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置である。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２９であってもよい。入力装置９１５は、ユーザが入力した情報に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。
【００８６】
出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ（Liquid  Crystal  Display）、ＰＤＰ（Plasma  Display  Panel）、有機ＥＬ（Electro-Luminescence）ディスプレイなどの表示装置、スピーカおよびヘッドホンなどの音声出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音声または音響などの音声として出力したりする。
【００８７】
ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard  Disk  Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。
【００８８】
ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２７のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録を書き込む。
【００８９】
接続ポート９２３は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２３は、例えば、ＵＳＢ（Universal  Serial  Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small  Computer  System  Interface）ポートなどでありうる。また、接続ポート９２３は、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（High-Definition  Multimedia  Interface）ポートなどであってもよい。接続ポート９２３に外部接続機器９２９を接続することで、情報処理装置９００と外部接続機器９２９との間で各種のデータが交換されうる。
【００９０】
通信装置９２５は、例えば、通信ネットワーク９３１に接続するための通信デバイスなどで構成された通信インターフェースである。通信装置９２５は、例えば、有線または無線ＬＡＮ（Local  Area  Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless  USB）用の通信カードなどでありうる。また、通信装置９２５は、光通信用のルータ、ＡＤＳＬ（Asymmetric  Digital  Subscriber  Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２５は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２５に接続される通信ネットワーク９３１は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。
【００９１】
以上、情報処理装置９００のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。
【００９２】
（４．補足）
本開示の実施形態は、例えば、上記で説明したようなサーバ装置、システム、サーバ装置またはシステムで実行される情報処理方法、サーバ装置を機能させるためのプログラム、およびプログラムが記録された記録媒体を含みうる。
【００９３】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００９４】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）フレーム画像をリアルタイム生成し、前記フレーム画像をエンコードしてエンコードデータを生成し、前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信するストリーミング処理部と、
前記クライアント装置における前記フレーム画像の出力タイミングに関する情報を前記クライアント装置から受信し、前記出力タイミングと前記ストリーミング処理部における前記フレーム画像の処理タイミングとが所定の関係を維持するように前記処理タイミングを制御する制御部と
を備えるサーバ装置。
（２）前記制御部は、前記出力タイミングを規定する第１の同期信号の周期を示す情報を受信し、前記第１の同期信号の周期と前記処理タイミングを規定する第２の同期信号の周期との周期差が小さくなるように前記処理タイミングを制御する、前記（１）に記載のサーバ装置。
（３）前記制御部は、前記クライアント装置において前記フレーム画像の出力処理が開始された第１のタイミングを示す情報を受信し、前記ストリーミング処理部において当該フレーム画像の生成が開始された第２のタイミングと比較することによって前記周期差を算出する、前記（２）に記載のサーバ装置。
（４）前記制御部は、前記クライアント装置が前記エンコードデータを受信してから前記フレーム画像が出力されるまでの経過時間を示す情報を受信し、前記経過時間の変化に基づいて前記周期差を算出する、前記（２）に記載のサーバ装置。
（５）前記制御部は、前記クライアント装置が前記第１の同期信号の周期ごとに送信する信号を受信し、前記信号の受信周期を前記第２の同期信号の周期と比較することによって前記周期差を算出する、前記（２）に記載のサーバ装置。
（６）前記制御部は、前記周期差を所定の期間にわたって算出し、算出された周期差の平均値を所定の閾値と比較した結果に応じて前記処理タイミングを制御する、前記（２）〜（５）のいずれか１項に記載のサーバ装置。
（７）前記制御部は、前記処理タイミングと前記出力タイミングとの時間差を表す値が所定の範囲内に収まるように前記処理タイミングを制御する、前記（１）〜（６）のいずれか１項に記載のサーバ装置。
（８）前記制御部は、前記クライアント装置において前記フレーム画像の出力処理が開始された第１のタイミングを示す情報を受信し、前記ストリーミング処理部において当該フレーム画像の生成が開始された第２のタイミングと比較することによって前記時間差を表す値を算出する、前記（７）に記載のサーバ装置。
（９）前記制御部は、前記クライアント装置が前記エンコードデータを受信してから前記フレーム画像が出力されるまでの経過時間を示す情報を受信し、前記経過時間が所定の範囲内に収まるように前記処理タイミングを制御する、前記（７）に記載のサーバ装置。
（１０）前記制御部は、前記クライアント装置が前記出力タイミングを規定する第１の同期信号の周期ごとに送信する信号を受信し、前記信号の受信タイミングと前記処理タイミングとの時間差が所定の範囲内に収まるように前記処理タイミングを制御する、前記（７）に記載のサーバ装置。
（１１）前記制御部は、前記時間差を表す値を所定の期間にわたって取得し、取得された値の平均値を所定の閾値と比較した結果に応じて前記処理タイミングを制御する、前記（７）〜（１０）のいずれか１項に記載のサーバ装置。
（１２）前記制御部は、前記処理タイミングの制御として、前記処理タイミングを規定する第２の同期信号の周期を変更する、前記（１）〜（１１）のいずれか１項に記載のサーバ装置。
（１３）前記制御部は、前記処理タイミングの制御として、前記処理タイミングを前後させる、前記（１）〜（１１）のいずれか１項に記載のサーバ装置。
（１４）前記クライアント装置で取得された操作入力を、前記ネットワークを介して受信する受信部をさらに備え、
前記ストリーミング処理部は、前記操作入力に従って前記フレーム画像をリアルタイム生成する、前記（１）〜（１３）のいずれか１項に記載の画像処理装置。
（１５）フレーム画像をリアルタイム生成し、前記フレーム画像をエンコードしてエンコードデータを生成し、前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、
前記クライアント装置における前記フレーム画像の出力タイミングに関する情報を前記クライアント装置から受信し、前記出力タイミングと前記フレーム画像の処理タイミングとが所定の関係を維持するように前記処理タイミングを制御することと
を含む情報処理方法。
【符号の説明】
【００９５】
１０      ストリーミングシステム
１００    クライアント
１４０    ストリーム受信部／処理部
１４１    ストリーム受信部
１４３    デコーダ
１４５    フレームバッファ
１４７    レンダラ
１６０    マネージャ
２１０    サービサー
２２０    ノード
２３０    エッジ
３００    サーバ
３２０    ストリーム処理部／送信部
３２１    レンダラ
３２３    フレームバッファ
３２５    エンコーダ
３２７    ストリーム送信部
【図１】
2014075736.tif 000010
【図２】
2014075736.tif 000011
【図３】
2014075736.tif 000012
【図４】
2014075736.tif 000013
【図５】
2014075736.tif 000014
【図６】
2014075736.tif 000015
【図７】
2014075736.tif 000016
【図８】
2014075736.tif 000017
【図９】
2014075736.tif 000018
【図１０】
2014075736.tif 000019