(57)【要約】【課題】リアルタイム生成されるフレーム画像のストリーミングにおいて、クライアントにおけるフレーム画像の受信遅延をサーバ側で予測することによってフレーム画像をより円滑に出力する。【解決手段】フレーム画像をリアルタイム生成するレンダラと、上記フレーム画像をエンコードしてエンコードデータを生成するエンコーダと、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信する送信部と、上記クライアント装置における上記エンコードデータの受信に発生する遅延増加を予測し、該予測に基づいて上記レンダラによる上記フレーム画像の生成間隔を制御する制御部とを含む画像処理装置が提供される。【選択図】図５
2014075735.tif 000002
【特許請求の範囲】
【請求項１】
フレーム画像をリアルタイム生成するレンダラと、
前記フレーム画像をエンコードしてエンコードデータを生成するエンコーダと、
前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信する送信部と、
前記クライアント装置における前記エンコードデータの受信に発生する遅延増加を予測し、該予測に基づいて前記レンダラによる前記フレーム画像の生成間隔を制御する制御部と
を備える画像処理装置。
【請求項２】
前記制御部は、前記送信部における前記エンコードデータの送信タイミングの遅延量に基づいて前記エンコードデータの受信に発生する遅延増加を予測する、請求項１に記載の画像処理装置。
【請求項３】
前記制御部は、前記送信タイミングの間隔の所定値との差に基づいて前記送信タイミングの遅延量を算出する、請求項２に記載の画像処理装置。
【請求項４】
前記制御部は、前記レンダラが前記フレーム画像の生成を開始したタイミングから前記送信タイミングまでの時間の所定値との差に基づいて前記送信タイミングの遅延量を算出する、請求項２に記載の画像処理装置。
【請求項５】
前記制御部は、前記生成間隔を制御した後に前記レンダラおよび前記エンコーダの処理量が所定の値以下になった場合には前記生成間隔の制御を元に戻す、請求項２に記載の画像処理装置。
【請求項６】
前記制御部は、前記クライアント装置から報告される、該クライアント装置における前記フレーム画像の出力状態に基づいて前記エンコードデータの受信に発生する遅延増加を予測する、請求項１に記載の画像処理装置。
【請求項７】
前記制御部は、前記クライアント装置において１または複数の前記フレーム画像の欠損が発生した場合に前記エンコードデータの受信に前記生成間隔の制御を必要とする程度の遅延増加が発生していると予測する、請求項６に記載の画像処理装置。
【請求項８】
前記制御部は、前記フレーム画像のうち欠損したものの割合が所定の値を超えた場合に、前記エンコードデータの受信に前記生成間隔の制御を必要とする程度の遅延増加が発生していると予測する、請求項７に記載の画像処理装置。
【請求項９】
前記制御部は、前記フレーム画像の出力タイミングの遅延量に基づいて前記エンコードデータの受信に発生する遅延増加を予測する、請求項６に記載の画像処理装置。
【請求項１０】
前記制御部は、前記出力タイミングの間隔の所定値との差に基づいて前記出力タイミングの遅延量を算出する、請求項９に記載の画像処理装置。
【請求項１１】
前記制御部は、前記レンダラが前記フレーム画像の生成を開始したタイミングから前記出力タイミングまでの時間の所定値との差に基づいて前記出力タイミングの遅延量を算出する、請求項９に記載の画像処理装置。
【請求項１２】
前記制御部は、前記送信部における前記エンコードデータの送信タイミングから前記出力タイミングまでの時間の所定値との差に基づいて前記出力タイミングの遅延量を算出する、請求項９に記載の画像処理装置。
【請求項１３】
前記制御部は、前記予測に基づいて、前記生成間隔を延長するように前記レンダラを制御する、請求項１に記載の画像処理装置。
【請求項１４】
前記制御部は、前記生成間隔が延長されたことによって生成されなくなったフレーム画像の代わりに、該フレーム画像の直前に生成されたフレーム画像を前記エンコーダに提供するように前記レンダラを制御する、請求項１３に記載の画像処理装置。
【請求項１５】
前記制御部は、前記生成間隔が延長されたことによって生成されなくなったフレーム画像のエンコードデータの代わりに、該フレーム画像の直前に生成されたフレーム画像のエンコードデータを前記送信部に提供するように前記エンコーダを制御する、請求項１３に記載の画像処理装置。
【請求項１６】
前記制御部は、前記生成間隔の延長に伴って前記エンコードデータの送信間隔を延長するように前記送信部を制御する、請求項１３に記載の画像処理装置。
【請求項１７】
前記制御部は、１または複数の前記フレーム画像の生成をスキップする、または前記フレーム画像の生成レートを変更することによって前記生成間隔を延長するように前記レンダラを制御する、請求項１３に記載の画像処理装置。
【請求項１８】
前記制御部は、所定の持続時間または所定のフレーム数にわたって前記生成間隔を延長するように前記レンダラを制御する、請求項１３に記載の画像処理装置。
【請求項１９】
前記クライアント装置で取得された操作入力を、前記ネットワークを介して受信する受信部をさらに備え、
前記レンダラは、前記操作入力に従って前記フレーム画像をリアルタイム生成する、請求項１に記載の画像処理装置。
【請求項２０】
フレーム画像をリアルタイム生成することと、
前記フレーム画像をエンコードしてエンコードデータを生成することと、
前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、
前記クライアント装置における前記エンコードデータの受信に発生する遅延増加を予測し、該予測に基づいて前記フレーム画像の生成間隔を制御することと
を含む画像処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、画像処理装置および画像処理方法に関する。
【背景技術】
【０００２】
サーバからネットワークを介してクライアントに映像や音声を配信するストリーミングでは、例えばネットワークにおける通信状態の変化に起因するデータ転送レートの変動（ジッタ）が生じる。データ転送レートが設計上の値よりも低い状態が継続したような場合には、クライアントにおいて表示されるべきフレーム画像がデータの転送の遅れのために表示されないフレーム欠損が生じる可能性がある。
【０００３】
フレーム欠損の発生を防ぐために、例えば、特許文献１，２に記載されているような技術が提案されている。これらの技術では、クライアントにおけるフレーム画像のデータのバッファ状態に応じて、サーバからのデータの送信レートを変更する。クライアントでバッファされているフレーム画像のデータが減少した場合にはデータの送信レートを低下させることで、画質は低下するもののフレーム欠損を防ぐことができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１１９９７１号公報
【特許文献２】特開２００２−０８４３３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところが、サーバにおいてリアルタイムで生成されるフレーム画像を順次エンコードしてクライアントに送信するストリーミングの場合、一連のフレーム画像が予め用意されているわけではないため、例えば送信するフレームを間引いてデータの送信レートを低下させるといった対応は困難である。また、リアルタイム性を重視するとクライアントでバッファされるフレーム画像も少なくなるため、上記のようにバッファ状態に応じて何らかの対応をとることも容易ではない。
【０００６】
そこで、本開示では、リアルタイム生成されるフレーム画像のストリーミングにおいて、クライアントにおけるフレーム画像の受信遅延をサーバ側で予測することによってフレーム画像をより円滑に出力することが可能な、新規かつ改良された画像処理装置および画像処理方法を提案する。
【課題を解決するための手段】
【０００７】
本開示によれば、フレーム画像をリアルタイム生成するレンダラと、上記フレーム画像をエンコードしてエンコードデータを生成するエンコーダと、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信する送信部と、上記クライアント装置における上記エンコードデータの受信に発生する遅延増加を予測し、該予測に基づいて上記レンダラによる上記フレーム画像の生成間隔を制御する制御部とを含む画像処理装置が提供される。
【０００８】
また、本開示によれば、フレーム画像をリアルタイム生成することと、上記フレーム画像をエンコードしてエンコードデータを生成することと、上記エンコードデータを、該エンコードデータをデコードして上記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、上記クライアント装置における上記エンコードデータの受信に発生する遅延増加を予測し、該予測に基づいて上記フレーム画像の生成間隔を制御することとを含む画像処理方法が提供される。
【０００９】
クライアントにおけるフレーム画像の受信遅延をサーバ側で予測し、これに基づいてフレーム画像の生成間隔を制御することによって、生じうる受信遅延を未然に防ぐことができ、クライアントにおいてフレーム画像をより円滑に出力することができる。
【発明の効果】
【００１０】
以上説明したように本開示によれば、アルタイム生成されるフレーム画像のストリーミングにおいて、クライアントにおけるフレーム画像の受信遅延をサーバ側で予測することによってフレーム画像をより円滑に出力することができる。
【図面の簡単な説明】
【００１１】
【図１】本開示の実施形態に係るストリーミングシステムの全体構成を概略的に示す図である。
【図２】本開示の実施形態に係るストリーミングシステムにおける情報の流れの例を示す図である。
【図３】本開示の実施形態に係るストリーミングシステムのクライアントおよびサーバの機能構成を概略的に示す図である。
【図４】本開示の実施形態におけるストリーミング処理部の機能構成を概略的に示す図である。
【図５】本開示の第１の実施形態について説明するための図である。
【図６】本開示の第２の実施形態について説明するための図である。
【図７】情報処理装置のハードウェア構成を説明するためのブロック図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１３】
なお、説明は以下の順序で行うものとする。
１．ストリーミングシステムの構成
１−１．全体構成
１−２．クライアントおよびサーバの構成
１−３．ストリーミング処理部の構成
２．エンコード制御に関する構成
２−１．第１の実施形態
２−２．第２の実施形態
３．ハードウェア構成
４．補足
【００１４】
（１．ストリーミングシステムの構成）
まず、図１〜図４を参照して、本開示の実施形態が適用されるストリーミングシステムの構成について説明する。
【００１５】
（１−１．全体構成）
図１は、本開示の実施形態に係るストリーミングシステムの全体構成を概略的に示す図である。図１を参照すると、ストリーミングシステム１０は、クライアント１００と、クライアント１００にストリーミングコンテンツを配信するためのサーバ（サービサー２１０、ノード２２０、およびエッジ２３０）とを含む。クライアント１００および各サーバは、有線または無線の各種ネットワークによって互いに接続される。
【００１６】
サービサー２１０は、オリジナルのコンテンツ２１１を保持している。ノード２２０は、ＣＤＮ（Contents  Delivery  Network）を構成するノードであり、サービサー２１０が保持するオリジナルをコピーしたコンテンツ２２１を保持している。エッジ２３０は、クライアント１００と直接的にやりとりし、要求に応じてコンテンツを適宜加工してクライアント１００に提供する。このとき、エッジ２３０は、ノード２２０が保持しているコンテンツをキャッシュ２３１として取得し、これをクライアント１００からの要求に応じて提供する。
【００１７】
図２は、本開示の実施形態に係るストリーミングシステムにおける情報の流れの例を示す図である。コンテンツの配信に先立って、クライアント１００は、サービサー２１０のユーザ認証モジュール２１３にアクセスし、サービスにログインする。ログインに成功したクライアント１００は、エッジ２３０のセッションコントローラ２３３にアクセスし、クライアント１００のためのプロセスの開始を要求する。これに応じて、セッションコントローラ２３３はプロセス２３５を立ち上げる。
【００１８】
エッジ２３０では、プロセス２３５がクライアント１００ごとに立ち上げられ、各クライアント１００からの要求に応じてコンテンツ配信のための処理を実行する。従って、エッジ２３０が複数のクライアント１００にサービスを提供する場合、エッジ２３０では複数のプロセス２３５が立ち上げられうる。各プロセス２３５は、スケジューラ２３７によってスケジューリングされる。スケジューラ２３７は、セッションコントローラ２３３によって制御される。
【００１９】
一方、サービサー２１０が保持しているオリジナルのコンテンツ２１１は、ノード２２０に予めコピーされ、コンテンツ２２１として保持されている。エッジ２３０で起動されたプロセス２３５は、クライアント１００からの要求に応じて、ノード２２０で保持されているコンテンツ２２１をキャッシュとして取得し、これを適宜加工してクライアント１００に提供する。このとき、プロセス２３５は、クライアント１００からのどのような要求に応じてどのようにコンテンツを提供したかというログを記録してもよい。このログ、およびその他の情報は、プロセス２３５によってノード２２０に提供され、情報２２３として保持されてもよい。ログなどの情報２２３は、例えばサービサー２１０の付加機能２１５によって利用されうる。
【００２０】
（１−２．クライアントおよびサーバの構成）
図３は、本開示の実施形態に係るストリーミングシステムのクライアントおよびサーバの機能構成を概略的に示す図である。なお、サーバ３００は、図１，２を参照して説明したストリーミングシステムにおいてエッジ２３０として機能するサーバである。図では、クライアント１００に配信されるストリーミングコンテンツの流れを実線で示し、ストリーミングコンテンツの再生に関する制御情報の流れを破線で示している。
【００２１】
クライアント１００は、ユーザにストリーミングコンテンツを提供する装置であり、例えば各種のパーソナルコンピュータ、タブレット端末、携帯電話（スマートフォンを含む）、メディアプレーヤ、ゲーム機などでありうる。一方、サーバ３００は、単一のサーバ装置、または有線もしくは無線の各種ネットワークによって互いに接続される複数のサーバ装置の協働によって実現される機能の集合体である。クライアント１００、およびサーバ３００を構成する各サーバ装置は、いずれも、例えば後述する情報処理装置のハードウェア構成を用いて実現されうる。図示された構成要素のうち、入力装置および出力装置、およびデータ（記憶装置に記憶される）を除く各部分は、例えばＣＰＵ（Central  Processing  Unit）などのプロセッサによってソフトウェア的に実現されうる。
【００２２】
クライアント１００では、入力装置１１０がユーザの操作入力を取得する。入力装置１１０は、例えばサービスへのログインやコンテンツの選択などのコンテンツ外の操作入力と、例えば静止画／動画の切替えや画像の拡大／縮小、音声の音質切替えなどのコンテンツ内の操作入力とを取得する。コンテンツ外の操作入力は、セッションコントローラ１２０によって処理される。セッションコントローラ１２０は、例えばログインに関する入力情報をサービサー２１０に送信したり、ログイン後にプロセス開始の要求をサーバ３００に送信したりする。一方、コンテンツ内の操作入力は、入力送信部１３０からサーバ３００に送信される。
【００２３】
サーバ３００では、セッションコントローラ２３３が、クライアント１００からのプロセス開始の要求に応じてプロセス２３５を立ち上げる。プロセス２３５は、クライアント１００で入力装置１１０が取得したコンテンツの選択操作によって指定されたコンテンツ２２１を取得し、コンテンツキャッシュ２３１として保持する。コンテンツキャッシュ２３１はエンコードデータであり、サーバ３００ではデコーダ３１０がこれをデコードする。デコードされたコンテンツのデータは、ストリーム処理部／送信部３２０で処理される。
【００２４】
一方、クライアント１００で入力装置１１０が取得したコンテンツ内の操作入力は、入力受信部３３０によって受信され、プレーヤコントローラ３４０に提供される。プレーヤコントローラ３４０は、操作入力に従ってデコーダ３１０やストリーム処理部／送信部３２０を制御する。ストリーム処理部／送信部３２０は、この制御に従って、コンテンツのデータから映像や音声を生成する。さらに、ストリーム処理部／送信部３２０は、生成した映像や音声をエンコードしてクライアント１００に送信する。なお、図示された例では、コンテンツは映像および音声を含むが、他の例ではコンテンツが映像だけを含んでもよく、また音声だけを含んでもよい。
【００２５】
クライアント１００に送信されたエンコードデータは、ストリーム受信部／処理部１４０でデコードされ、映像や音声としてレンダリングされて、出力装置１５０からユーザに向けて出力される。ここで、サーバ側のストリーム処理部／送信部３２０と、クライアント側のストリーム受信部／処理部１４０とは、それぞれマネージャ３５０およびマネージャ１６０によって管理される。サーバ側のマネージャ３５０と、クライアント側のマネージャ１６０とは、必要に応じて情報を交換して協働する。
【００２６】
（１−３．ストリーミング処理部の構成）
図４は、本開示の実施形態におけるストリーミング処理部の機能構成を概略的に示す図である。図では、クライアント１００のストリーム受信部／処理部１４０、およびサーバ３００のストリーム処理部／送信部３２０の機能構成がそれぞれ示されている。
【００２７】
（クライアント側）
ストリーム受信部／処理部１４０は、ストリーム受信部１４１、デコーダ１４３、フレームバッファ１４５、およびレンダラ１４７を含む。ストリーム受信部１４１は、サーバ側のストリーム送信部３２７から所定のプロトコルに従ってデータを受信する。図示された例ではＲＴＰ（Real-Time  Transport  Protocol）が用いられる。この場合、ストリーム受信部１４１は、受信したデータをデコーダ１４３に提供するとともに、データの遅延などの通信状態を検出し、ＲＴＣＰ（RTP  Control  Protocol）を用いてストリーム送信部３２７に報告する。
【００２８】
デコーダ１４３は、ストリーム受信部１４１から提供されたデータをデコードして、映像データおよび音声データを得る。デコーダ１４３は、映像データをデコードする映像デコーダ１４３ａと、音声データをデコードする音声デコーダ１４３ｂとを含む。映像デコーダ１４３ａおよび音声デコーダ１４３ｂは、それぞれ複数の種類が用意されて、処理対象のデータのフォーマットに応じて選択的に使用されてもよい。なお、以下の説明では、デコーダ１４３ａおよびデコーダ１４３ｂの両方、またはいずれか一方を、単にデコーダ１４３と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００２９】
フレームバッファ１４５は、デコーダ１４３で得られた映像データおよび音声データをフレーム単位で一時的に蓄積する。フレームバッファ１４５は、映像データを蓄積するフレームバッファ１４５ａと、音声データを蓄積するフレームバッファ１４５ｂとを含む。フレームバッファ１４５は、マネージャ１６０の制御に従って、所定のタイミングで各フレームの映像データおよび音声データをレンダラ１４７に提供する。なお、以下の説明では、フレームバッファ１４５ａおよびフレームバッファ１４５ｂの両方、またはいずれか一方を、単にフレームバッファ１４５と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３０】
レンダラ１４７は、映像データをレンダリングしてディスプレイなどの出力装置に提供する映像レンダラ１４７ａと、音声データをレンダリングしてスピーカなどの出力装置に提供する音声レンダラ１４７ｂとを含む。映像レンダラ１４７ａと音声レンダラ１４７ｂとは、出力される映像と音声とのフレームを同期させる。また、レンダラ１４７は、出力したフレームのＩＤや、出力が実行された時刻などをマネージャ１６０に報告する。なお、以下の説明では、レンダラ１４７ａおよびレンダラ１４７ｂの両方、またはいずれか一方を、単にレンダラ１４７と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３１】
（サーバ側）
ストリーム処理部／送信部３２０は、レンダラ３２１、フレームバッファ３２３、エンコーダ３２５、およびストリーム送信部３２７を含む。レンダラ３２１は、デコーダ３１０によってデコードされたコンテンツのデータを素材として用いて、またプレーヤコントローラ３４０によるユーザの操作入力に基づく制御に従って、映像データおよび音声データを生成する。ここで、映像データおよび音声データについてフレームが定義され、映像データは連続するフレーム画像として生成される。
【００３２】
フレームバッファ３２３は、レンダラ３２１で生成された映像データおよび音声データをフレーム単位で一時的に蓄積する。フレームバッファ３２３は、映像データを蓄積するフレームバッファ３２３ａと、音声データを蓄積するフレームバッファ３２３ｂとを含む。フレームバッファ３２３に蓄積された映像データおよび音声データは、順次エンコーダ３２５によってエンコードされる。なお、以下の説明では、フレームバッファ３２３ａおよびフレームバッファ３２３ｂの両方、またはいずれか一方を、単にフレームバッファ３２３と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３３】
エンコーダ３２５は、映像データをエンコードする映像エンコーダ３２５ａと、音声データをエンコードする音声エンコーダ３２５ｂとを含む。映像エンコーダ３２５ａおよび音声エンコーダ３２５ｂは、それぞれ複数の種類が用意されて、クライアント１００で使用可能な映像デコーダ１４３ａおよび音声デコーダ１４３ｂの種類、または処理対象の映像データや音声データの特性に応じて選択的に使用されてもよい。エンコードされた映像データおよび音声データは、ストリーム送信部３２７からクライアント１００に送信される。なお、以下の説明では、エンコーダ３２５ａおよびエンコーダ３２５ｂの両方、または一方を、単にエンコーダ３２５と称する場合がある（いずれか一方を指す場合、扱うのが音声であるか映像であるかが明示される）。
【００３４】
以上で説明したような本実施形態に係るストリーミングシステムの構成によれば、エッジとして機能するサーバにおいて、ユーザの操作入力に応じて映像や音声をリアルタイム生成してクライアントに配信することが可能である。従って、例えば特開２０１０−１１７８２８号公報に記載された画像を自由に拡大／縮小したり移動したりするアプリケーションや、サイズの大きな画像や映像の閲覧、オンラインゲーム、シミュレーションビューアなどのさまざまなアプリケーションを、ユーザの操作入力に対する応答性を確保しつつストリーミングによって提供することができる。
【００３５】
（２．画像生成レート制御に関する構成）
次に、図５および図６を参照して、本開示の実施形態における画像生成レート制御に関する構成について説明する。画像生成レート制御に関する構成は、第１および第２の実施形態として説明される。
【００３６】
（２−１．第１の実施形態）
図５は、本開示の第１の実施形態について説明するための図である。本実施形態では、サーバからのデータ送信の遅延状態に基づいて、クライアントでのデータの受信に発生する遅延量が予測される。
【００３７】
ストリーミングシステム１０では、サーバ３００がユーザの操作入力に従って映像をリアルタイム生成し、クライアント１００に配信する。それゆえ、映像を構成する各フレーム画像の内容が場合によって変化し、レンダラ３２１でフレーム画像を生成する処理にかかる時間（描画処理時間）や、エンコーダ３２５でフレーム画像をエンコードするのにかかる時間（エンコード処理時間）が不規則に変動する可能性がある。
【００３８】
描画処理時間またはエンコード処理時間のいずれかまたは両方が想定される値よりも長いフレーム画像のエンコードデータは、本来のタイミングよりも遅延してストリーム送信部３２７からクライアント１００に向けて送信されることになる。この場合、エンコードデータがクライアント１００のストリーム受信部１４１によって受信されるタイミングも同じだけ、またはネットワーク遅延が大きければそれ以上に遅延する。
【００３９】
この遅延がフレームバッファ１４５によって吸収可能な範囲を超えると、クライアント１００で出力される映像においてフレーム欠損が発生する。このようなフレーム欠損は、例えばあるフレーム画像の処理時間が突出して長くなることによって発生する場合もあれば、処理時間が想定される値を少しだけ上回るフレーム画像が連続することで遅延が蓄積することによって発生する場合もある。
【００４０】
そこで、本実施形態では、ストリーム送信部３２７が、エンコードデータをクライアント１００に向けて送信したタイミングをマネージャ３５０に報告する。マネージャ３５０は、この送信タイミングの遅延状態に基づいて、クライアント１００におけるデータの受信に発生する遅延量を予測する。マネージャ３５０は、予測される遅延量によってフレーム欠損が発生する可能性がある場合、フレーム画像の生成間隔を延長するようにレンダラ３２１を制御する。
【００４１】
以下では、まず、マネージャ３５０がどのようにしてクライアント１００におけるデータの受信に発生する遅延量を予測するかについて説明し、次に、どのようなレンダラ３２１の制御によってフレーム画像の生成間隔が延長されるかについて説明する。
【００４２】
（データ受信の遅延量予測）
上記のように、クライアント１００におけるエンコードデータの受信は、少なくともストリーム送信部３２７からのデータの送信が遅延した分だけ遅延し、ネットワーク遅延が大きければそれ以上に遅延する。従って、本実施形態において、マネージャ３５０は、ストリーム送信部３２７によるエンコードデータの送信タイミングの所定のタイミングからの遅延量を、クライアント１００におけるデータの受信に発生する遅延量の最小値として見積もる。マネージャ３５０は、この最小値に、想定されるネットワーク遅延量の増減分を加えることで、データの受信に発生する遅延量を予測することができる。
【００４３】
ここで、ストリーム送信部３２７によるエンコードデータの送信タイミングの所定のタイミングからの遅延量の定義には、いくつかの例がある。
【００４４】
第１の例は、データの送信タイミングの間隔と所定の間隔との差である。ストリーム送信部３２７によるデータの送信タイミングの間隔は、本来は、映像のフレームレートによって規定される所定の間隔（例えば、フレームレートが３０ｆｐｓ（frames  per  second）であれば約３３．３ｍｓｅｃ）に一致する。従って、データの送信タイミングの間隔が所定の間隔よりも長い場合、データが所定のタイミングまでに送信可能な状態になっていないことによってデータの送信タイミングが遅延していると推定される。
【００４５】
第２の例は、フレーム画像ごとの処理時間の所定の時間との差である。レンダラ３２１がフレーム画像の生成を開始してから、生成された画像をエンコーダ３２５がエンコードし、出力されたエンコードデータをストリーム送信部３２７が送信するまでの時間は、本来はフレームごとにほぼ一定である。従って、レンダラ３２１がフレーム画像の作成を開始してからストリーム送信部３２７がエンコードデータを送信するまでの処理時間が、平均的な処理時間、または設計上の処理時間よりも長い場合、レンダラ３２１またはエンコーダ３２５での処理が所定のタイミングまでに完了していないことによってデータの送信タイミングが遅延していると推定される。
【００４６】
以上のようにして予測されたデータ受信の遅延増加に対してフレーム画像の生成間隔を延長する必要があるか否かは、例えば、遅延増加量がクライアント１００におけるフレーム画像のバッファサイズなどに応じて設定された所定の閾値を超えているか否かによって判定されうる。
【００４７】
（フレーム画像の生成間隔の延長）
上述のように、サーバ３００のストリーム送信部３２７からのエンコードデータの送信が遅延すれば、少なくともその分だけ、クライアント１００におけるデータの受信が遅延する。従って、ストリーム送信部３２７からのデータの送信の遅延を低減すれば、クライアント１００でのデータの受信の遅延も低減する可能性が高い。そこで、マネージャ３５０は、予測されるデータの受信の遅延量が大きい場合に、フレーム画像の生成間隔を延長するようにレンダラ３２１を制御することによって、ストリーム送信部３２７からのデータの送信の遅延を低減させる。
【００４８】
マネージャ３５０によってフレーム画像の生成間隔を延長するための制御が実行された場合、レンダラ３２１は、後述するように、フレーム画像の生成をスキップする、またはフレーム画像の生成レートを低下させることによって、フレーム画像の生成間隔を延長する。この場合、本来フレーム画像が生成されていたタイミングでフレーム画像が生成されなくなる場合があるため、レンダラ３２１は、（ｉ）図５に示されるようにフレーム画像の生成タイミングの変更をエンコーダ３２５に通知するか、（ｉｉ）代わりのフレーム画像をエンコーダ３２５に提供する。
【００４９】
フレーム画像の生成間隔が延長されることで、レンダラ３２１における時間あたりの処理量が減少する。これによって、レンダラ３２１の処理が原因で発生していたデータ送信の遅延は解消される。また、上記の（ｉ）の場合、エンコーダ３２５での処理の間隔も延長され、時間あたりの処理量が減少する。（ｉｉ）の場合、エンコーダ３２５での処理の間隔は変わらないが、レンダラ３２１の処理量が減少したことで、エンコーダ３２５が利用できるＣＰＵなどのリソースの量が増加する。従って、両方の場合で、エンコーダ３２５の処理が原因で発生していたデータ送信の遅延も解消される。
【００５０】
ここで、制御を受けたレンダラ３２１が実行するフレーム画像の生成間隔を延長するための具体的な処理には、いくつかの例がある。
【００５１】
第１の例として、レンダラ３２１は、フレーム画像の生成間隔を延長するために、１または複数のフレーム画像の生成をスキップしてもよい。この場合、レンダラ３２１は、生成がスキップされたフレーム画像の代わりに、その直前に生成されたフレーム画像のコピーをエンコーダ３２５に提供し、エンコーダ３２５はスキップがない場合と同様に処理を継続してもよい。あるいは、レンダラ３２１は、フレーム画像の生成がスキップされるタイミングをエンコーダ３２５に通知し、エンコーダ３２５はそのタイミングで直前に出力したフレーム画像のエンコードデータのコピーを出力してもよい。
【００５２】
第２の例として、レンダラ３２１は、フレーム画像の生成間隔を延長するために、フレーム画像の生成レートを低下させてもよい。この場合、レンダラ３２１は、生成レートの低下によって、フレーム画像が生成されるタイミングでフレーム画像が生成されない場合には、その直前に生成されたフレーム画像をエンコーダ３２５に提供し、レンダラ３２１は生成レートが低下しない場合と同様に処理を継続してもよい。あるいは、レンダラ３２１は、変更後の生成レートをエンコーダ３２５に通知し、エンコーダ３２５は同じレートでフレーム画像のエンコードを実行してもよい。この場合、フレーム画像が生成されるタイミングでフレーム画像が生成されない場合には、エンコーダ３２５が直前に出力したフレーム画像のエンコードデータを出力する。
【００５３】
以上のようにして延長されたフレーム画像の生成間隔は、例えば、所定の持続時間または所定のフレーム数にわたって継続されてもよい。上記の第１の例の場合であれば、所定の持続時間または所定のフレーム数の間、所定の数のフレーム画像をスキップして（例えば、２つおき、３つおき、などで）フレーム画像が生成される。また、第２の例の場合であれば、所定の持続時間または所定のフレーム数の間、低下した生成レートの設定が維持される。
【００５４】
あるいは、マネージャ３５０は、フレーム画像の生成間隔を延長する前後のレンダラ３２１およびエンコーダ３２５の処理量を監視し、処理量が十分に下がった場合に生成間隔を元に戻してもよい。処理量が十分に下がった場合とは、例えば、フレーム画像の生成間隔を２倍に延長したときに、処理量が延長前の１／２以下になったような場合である。この場合、フレーム画像の生成間隔を元に戻しても、データ送信が遅延する可能性は低いと考えられる。
【００５５】
以上のような処理によってフレーム画像の生成間隔を延長した場合も、クライアント１００で出力される映像において画像の更新間隔が本来よりも長くなることはフレーム欠損の場合と同じである。しかしながら、不規則にフレーム欠損が発生するよりも、上記のような制御によって規則的にフレーム画像の更新間隔が延びる方が、映像を観察するユーザへの違和感は小さく、より円滑なフレーム画像の出力が実現されるといえる。
【００５６】
（２−２．第２の実施形態）
図６は、本開示の第２の実施形態について説明するための図である。本実施形態では、クライアントにおける過去のフレーム画像の出力状態に基づいて、クライアントにおける今後のデータの受信に発生する遅延量が予測される。
【００５７】
ストリーミングシステム１０では、サーバ３００がユーザの操作入力に従って映像をリアルタイム生成し、クライアント１００に配信する。表示される映像において高いリアルタイム性を実現するためには、フレーム画像がサーバ３００で生成されてからクライアント１００で出力されるまでの時間差を可能な限り小さくすることが望ましい。そのため、クライアント１００のフレームバッファ１４５でバッファされるフレーム画像の数が少なく、ストリーム受信部１４１がデータを受信するタイミングが本来のタイミングよりも遅延すると、フレーム欠損が発生する可能性が高い。
【００５８】
そこで、本実施形態では、クライアント１００のレンダラ１４７が、フレーム画像の出力状態をクライアント１００側のマネージャ１６０に報告する。報告の内容は、後述するサーバ３００のマネージャ３５０の予測手法に応じて、適宜設定されうる。報告は、例えば各フレーム画像の出力タイミングを報告するものであってもよいし、フレーム欠損が発生した場合にその旨を報告するものであってもよい。
【００５９】
マネージャ１６０から情報を提供されたサーバ３００側のマネージャ３５０は、報告された出力状態に基づいて、クライアント１００における今後のデータの受信に発生する遅延量を予測する。マネージャ３５０は、予測される遅延量によってフレーム欠損が発生する可能性がある場合、フレーム画像の生成間隔を延長するようにレンダラ３２１を制御する。
【００６０】
以下では、マネージャ３５０がどのようにしてクライアント１００におけるデータの受信に発生する遅延量を予測するかについて説明する。どのようなレンダラ３２１の制御によってフレーム画像の生成間隔が延長されるかについては、上述した第１の実施形態と同様であるため、重複する部分については説明を省略する。
【００６１】
（データ受信の遅延量予測）
本実施形態では、クライアント１００から提供されるフレーム画像の出力状態に基づいて、クライアント１００における今後のデータ受信の遅延量が予測される。従って、この予測には、上記の第１の実施形態で説明したようなサーバ３００側の要因による遅延に加えて、ネットワーク遅延も反映される。従って、第１の実施形態との違いとして、予測される遅延量は、必ずしも数値でなくてよい。例えば、クライアント１００のレンダラ１４７からの報告が、フレーム欠損が発生した場合にその旨を報告するものである場合に、サーバ３００のマネージャ３５０は、その報告に基づいて“今後のデータ受信の遅延量は、フレーム欠損が発生しうる程度になる”と予測し、フレーム画像の生成間隔を延長するようにレンダラ３２１を制御することができる。
【００６２】
ここで、マネージャ３５０は、１回のフレーム欠損の報告によってレンダラ３２１の制御を実行してもよいし、所定の期間内に取得された２回以上の所定の回数のフレーム欠損の報告によってレンダラ３２１の制御を実行してもよい。あるいは、マネージャ３５０は、所定の期間内に出力される予定のフレーム画像のうち、フレーム欠損によって出力されなかったフレーム画像の割合が所定の値を超えた場合に、レンダラ３２１の制御を実行してもよい。
【００６３】
もちろん、マネージャ３５０は、今後のデータ受信の遅延量を、数値として予測してもよい。例えば、レンダラ１４７からの報告が、各フレーム画像の出力タイミングを報告するものである場合に、マネージャ３５０（またはマネージャ１６０）は、出力タイミングの所定のタイミングからの遅延量を、クライアント１００における今後のデータの受信に発生する遅延量として見積もってもよい。
【００６４】
ここで、上記の送信タイミングの例と同様に、出力タイミングについても、所定のタイミングからの遅延量の定義には、いくつかの例がある。
【００６５】
第１の例は、フレーム画像の出力タイミングの間隔と所定の間隔との差である。レンダラ１４７がフレーム画像を出力するタイミングの間隔は、本来は、映像のフレームレートによって規定される所定の間隔（例えば、フレームレートが３０ｆｐｓであれば約３３．３ｍｓｅｃ）に一致する。従って、フレーム画像の出力タイミングの間隔が所定の間隔よりも長い場合、データが所定のタイミングで受信されず、遅延していると推定される。
【００６６】
第２の例は、フレーム画像ごとの処理／伝送時間の所定の時間との差である。レンダラ３２１がフレーム画像の生成を開始してから（またはストリーム送信部３２７がエンコードデータを送信してから）、クライアント１００でフレーム画像が出力されるまでの時間は、本来はフレームごとにほぼ一定である。従って、レンダラ３２１がフレーム画像の作成を開始してから（またはストリーム送信部３２７がエンコードデータを送信してから）クライアント１００でフレーム画像が出力されるまでの処理／伝送時間が、平均的な処理／伝送時間、または設計上の処理／伝送時間よりも長い場合、サーバ３００におけるフレーム画像の処理、またはネットワークでのデータの伝送に遅延が生じていることによって、データが所定のタイミングで受信されず、遅延していると推定される。
【００６７】
以上のようにして予測されたデータ受信の遅延増加に対してフレーム画像の生成間隔を延長する必要があるか否かは、例えば、遅延増加量がクライアント１００におけるフレーム画像のバッファサイズなどに応じて設定された所定の閾値を超えているか否かによって判定されうる。
【００６８】
（画像生成間隔の制御）
上記のように、本実施形態では、上記の第１の実施形態と同様にして、サーバ３００のマネージャ３５０がレンダラ３２１を制御し、フレーム画像の生成間隔を延長する。加えて、本実施形態では、予測されたデータ受信の遅延量が、ネットワーク遅延をも反映したものであるために、以下のような付加的な構成が採用されてもよい。
【００６９】
上記の第１の実施形態では、レンダラ３２１においてフレーム画像の生成間隔が延長された場合も、直前に生成されたフレーム画像やエンコードデータを用いることによって、エンコーダ３２５からエンコードデータが出力される間隔は維持された。これに対して、本実施形態では、フレーム画像の生成間隔の延長を、ストリーム送信部３２７、およびクライアント１００のストリーム受信／処理部１４０にも通知することによって、エンコードデータがサーバ３００からクライアント１００に伝送される間隔をも同様に延長してもよい。これによって、ネットワークを経由してサーバ３００からクライアント１００に伝送されるデータの量を削減できるため、ネットワーク遅延が大きい場合でも、効果的にフレーム欠損の発生を防止することができる。
【００７０】
（３．ハードウェア構成）
次に、図７を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図７は、情報処理装置のハードウェア構成を説明するためのブロック図である。図示された情報処理装置９００は、例えば、上記の実施形態におけるクライアント１００およびサーバ３００を実現しうる。
【００７１】
情報処理装置９００は、ＣＰＵ（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）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２５は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２５に接続される通信ネットワーク９３１は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。
【００７９】
以上、情報処理装置９００のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。
【００８０】
（４．補足）
本開示の実施形態は、例えば、上記で説明したような画像処理装置（例えばサーバに含まれる）、システム、画像処理装置またはシステムで実行される方法、画像処理装置を機能させるためのプログラム、およびプログラムが記録された記録媒体を含みうる。
【００８１】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００８２】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）フレーム画像をリアルタイム生成するレンダラと、
前記フレーム画像をエンコードしてエンコードデータを生成するエンコーダと、
前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信する送信部と、
前記クライアント装置における前記エンコードデータの受信に発生する遅延量を予測し、該遅延量に基づいて前記レンダラによる前記フレーム画像の生成間隔を制御する制御部と
を備える画像処理装置。
（２）前記制御部は、前記送信部における前記エンコードデータの送信タイミングの遅延量に基づいて前記遅延量を予測する、前記（１）に記載の画像処理装置。
（３）前記制御部は、前記送信タイミングの間隔の所定値との差に基づいて前記送信タイミングの遅延量を算出する、前記（２）に記載の画像処理装置。
（４）前記制御部は、前記レンダラが前記フレーム画像の生成を開始したタイミングから前記送信タイミングまでの時間の所定値との差に基づいて前記送信タイミングの遅延量を算出する、前記（２）に記載の画像処理装置。
（５）前記制御部は、前記クライアント装置から報告される、該クライアント装置における前記フレーム画像の出力状態に基づいて前記遅延量を予測する、前記（１）に記載の画像処理装置。
（６）前記制御部は、前記クライアント装置において１または複数の前記フレーム画像の欠損が発生した場合に前記遅延量が前記生成間隔の制御を必要とする程度の量であると予測する、前記（５）に記載の画像処理装置。
（７）前記制御部は、前記フレーム画像のうち欠損したものの割合が所定の値を超えた場合に、前記遅延量が前記生成間隔の制御を必要とする程度の量であると予測する、前記（６）に記載の画像処理装置。
（８）前記制御部は、前記フレーム画像の出力タイミングの遅延量に基づいて前記遅延量を予測する、前記（５）に記載の画像処理装置。
（９）前記制御部は、前記出力タイミングの間隔の所定値との差に基づいて前記出力タイミングの遅延量を算出する、前記（８）に記載の画像処理装置。
（１０）前記制御部は、前記レンダラが前記フレーム画像の生成を開始したタイミングから前記出力タイミングまでの時間の所定値との差に基づいて前記出力タイミングの遅延量を算出する、前記（８）に記載の画像処理装置。
（１１）前記制御部は、前記送信部における前記エンコードデータの送信タイミングから前記出力タイミングまでの時間の所定値との差に基づいて前記出力タイミングの遅延量を算出する、前記（８）に記載の画像処理装置。
（１２）前記制御部は、前記遅延量に基づいて、前記生成間隔を延長するように前記レンダラを制御する、前記（１）〜（１１）のいずれか１項に記載の画像処理装置。
（１３）前記制御部は、前記生成間隔が延長されたことによって生成されなくなったフレーム画像の代わりに、該フレーム画像の直前に生成されたフレーム画像のコピーを前記エンコーダに提供するように前記レンダラを制御する、前記（１２）に記載の画像処理装置。
（１４）前記制御部は、前記生成間隔が延長されたことによって生成されなくなったフレーム画像のエンコードデータの代わりに、該フレーム画像の直前に生成されたフレーム画像のエンコードデータのコピーを前記送信部に提供するように前記エンコーダを制御する、前記（１２）に記載の画像処理装置。
（１５）前記制御部は、前記生成間隔の延長に伴って前記エンコードデータの送信間隔を延長するように前記送信部を制御する、前記（１２）〜（１４）のいずれか１項に記載の画像処理装置。
（１６）前記制御部は、１または複数の前記フレーム画像の生成をスキップすることによって前記生成間隔を延長するように前記レンダラを制御する、前記（１２）〜（１５）のいずれか１項に記載の画像処理装置。
（１７）前記制御部は、前記フレーム画像の生成レートを変更することによって前記生成間隔を延長するように前記レンダラを制御する、前記（１２）〜（１５）のいずれか１項に記載の画像処理装置。
（１８）前記制御部は、所定の持続時間または所定のフレーム数にわたって前記生成間隔を延長するように前記レンダラを制御する、前記（１２）〜（１７）のいずれか１項に記載の画像処理装置。
（１９）前記クライアント装置で取得された操作入力を、前記ネットワークを介して受信する受信部をさらに備え、
前記レンダラは、前記操作入力に従って前記フレーム画像をリアルタイム生成する、前記（１）〜（１８）のいずれか１項に記載の画像処理装置。
（２０）フレーム画像をリアルタイム生成することと、
前記フレーム画像をエンコードしてエンコードデータを生成することと、
前記エンコードデータを、該エンコードデータをデコードして前記フレーム画像を出力するクライアント装置にネットワークを介して送信することと、
前記クライアント装置における前記エンコードデータの受信に発生する遅延量を予測し、該遅延量に基づいて前記フレーム画像の生成間隔を制御することと
を含む画像処理方法。
【符号の説明】
【００８３】
１０      ストリーミングシステム
１００    クライアント
１４０    ストリーム受信部／処理部
１４１    ストリーム受信部
１４３    デコーダ
１４５    フレームバッファ
１４７    レンダラ
１６０    マネージャ
２１０    サービサー
２２０    ノード
２３０    エッジ
３００    サーバ
３２０    ストリーム処理部／送信部
３２１    レンダラ
３２３    フレームバッファ
３２５    エンコーダ
３２７    ストリーム送信部
【図１】
2014075735.tif 000003
【図２】
2014075735.tif 000004
【図３】
2014075735.tif 000005
【図４】
2014075735.tif 000006
【図５】
2014075735.tif 000007
【図６】
2014075735.tif 000008
【図７】
2014075735.tif 000009