JP2014182793A - エンコーダ、映像処理サーバ、映像処理システム、エンコード方法およびそのプログラム - Google Patents

Abstract

【課題】端末側の負荷を低減させつつ、リッチなウェブコンテンツをブラウジングできるようにする。
【解決手段】映像音声エンコーダ２１１は、ウェブコンテンツをレンダリングしてブラウザ出力画像を生成するクラウドブラウザ２０４を備えたエンジンサーバ２００に組み込まれるエンコーダであって、クラウドブラウザ２０４で生成されたブラウザ出力画像のＩフレームまたはブラウザ出力画像の前のブラウザ出力画像に対するＰフレームを生成するフレーム生成部２１１２と、フレーム生成部２１１２が生成したフレームを出力するフレーム出力部２１１３と、クラウドブラウザ２０４に更新が発生していない期間を計測するタイマと、を備え、フレーム生成部２１１２は、タイマによって計時されたクラウドブラウザ２０４に更新が発生していない期間が所定時間Ｔｗ以上となった場合、強制ＩフレームＦ１ｆを生成することを特徴とする。
【選択図】図３０

Description

本発明は、エンコーダ、映像処理サーバ、映像処理システム、エンコード方法およびそのプログラムに関する。

近年、インターネットの普及に伴い、様々な分野でクラウドコンピューティングが利用されてきている。クラウドコンピューティングは、ユーザが、インターネットに接続した端末を用いてインターネット上のサーバが提供するサービス（クラウドサービス）を利用し、その対価を支払うサービス利用形態である。

しかし、インターネット上で扱われるコンテンツ（ウェブコンテンツ）は、様々な要求に応えるためにリッチ化される傾向にある。従来技術では、インターネット経由でサービスを利用するための端末をウェブコンテンツのリッチ化に対応させるための負荷が高いという問題がある。また、従来技術では、ウェブコンテンツの映像と音声を別個の端末で再生したいというニーズ、例えば、映像はプロジェクタで再生し、音声はプロジェクタから独立したスピーカで再生したいといったニーズに応えられない。

端末の負荷を低減させる技術としては、シンクライアントと呼ばれる技術があるが（例えば、特許文献１等を参照）、シンクライアントの多くはインターネット環境を利用しない閉じた環境で利用される。インターネット環境を利用してウェブベースで様々なアプリケーションをクライアント端末で実行できるようにするシンクライアントもあるが、この場合は、上記と同様に、クライアント端末をウェブコンテンツのリッチ化に対応させるための負荷が高くなるという問題が生じる。

本発明は、上記に鑑みてなされたものであって、端末側の負荷を低減させつつ、リッチなウェブコンテンツをブラウジングできるようにするエンコーダ、映像処理サーバ、映像処理システム、エンコード方法およびそのプログラムを提供することを主な目的とする。

上述した課題を解決し、目的を達成するために、本発明にかかるエンコーダは、コンテンツをレンダリングして出力画像を生成するブラウザを備えたサーバに組み込まれるエンコーダであって、前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成するフレーム生成部と、前記フレーム生成部が生成したフレームを出力するフレーム出力部と、前記ブラウザに更新が発生していない期間を計測するタイマと、を備え、前記フレーム生成部は、前記タイマによって計時された前記ブラウザに更新が発生していない期間が所定時間以上となった場合、第２先頭フレームを生成することを特徴とする。

また、本発明にかかる映像処理サーバは、１つ以上の端末にネットワークを介して接続された映像処理サーバであって、コンテンツをレンダリングして出力画像を生成するブラウザと、上記のエンコーダと、前記フレーム出力部が出力した前記フレームを前記１つ以上の端末に前記ネットワークを介して配信する配信部と、を備えることを特徴とする。

また、本発明にかかる映像処理システムは、ネットワークを介して１つ以上の端末とサーバとが接続された映像処理システムであって、前記サーバは、コンテンツをレンダリングして出力画像を生成するブラウザと、上記のエンコーダと、前記前記フレーム出力部が出力した前記フレームを前記１つ以上の端末に前記ネットワークを介して配信する配信部と、を備え、各端末は、前記フレームをデコードするデコーダと、前記デコーダでデコードされた画像を表示する表示部と、を備えることを特徴とする。

また、本発明にかかるエンコード方法は、コンテンツをレンダリングして出力画像を生成するブラウザを備えたクラウドサーバにおける配信画像のエンコード方法であって、前記ブラウザに更新が発生していない期間を計測し、前記ブラウザに更新が発生していない期間が所定時間未満である場合、前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成し、前記ブラウザに更新が発生していない期間が前記所定時間以上となった場合、第２先頭フレームを生成することを含むことを特徴とする。

また、本発明にかかるプログラムは、ブラウザを備えたクラウドサーバに組み込まれたコンピュータを機能させるためのプログラムであって、前記ブラウザに更新が発生していない期間を計測する計時処理と、前記ブラウザに更新が発生していない期間が所定時間未満である場合、前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成し、前記ブラウザに更新が発生していない期間が前記所定時間以上となった場合、第２先頭フレームを生成するフレーム生成処理と、を前記コンピュータに実行させる。

本発明によれば、端末側の負荷を低減させつつ、リッチなウェブコンテンツをブラウジングすることができるという効果を奏する。

図１は、映像音声処理システムの概要を説明する図である。 図２は、映像音声処理システムの構成例を示すシステム構成図である。 図３は、管理サーバの機能的な構成例を示すブロック図である。 図４は、エンジンサーバの機能的な構成例を示すブロック図である。 図５は、クライアント端末の機能的な構成例を示すブロック図である。 図６は、デバイスの機能的な構成例を示すブロック図である。 図７は、デバイスを起動するための端末起動処理の具体例を示すシーケンス図である。 図８は、クライアント端末を起動するための端末起動処理の具体例を示すシーケンス図である。 図９は、エンジン準備処理の具体例を示すシーケンス図である。 図１０は、エンジン準備処理の具体例を示すシーケンス図である。 図１１は、実行環境情報取得処理の具体例を示すシーケンス図である。 図１２は、セッション確立処理の具体例を示すシーケンス図である。 図１３は、映像受信・再生処理の具体例を示すシーケンス図である。 図１４は、音声受信・再生処理の具体例を示すシーケンス図である。 図１５は、操作イベント送信処理の具体例を示すシーケンス図である。 図１６は、マルチキャストの具体例を示すシーケンス図である。 図１７は、端末状態管理処理の具体例を示すシーケンス図である。 図１８は、エンジンサーバ負荷判定処理の具体例を示すシーケンス図である。 図１９は、ユーザセッション終了処理の具体例を示すシーケンス図である。 図２０は、映像音声個別配信の概要を説明する概念図である。 図２１は、再生遅延時間を説明する概念図である。 図２２は、実施形態にかかるブラウザ出力画像と更新領域との一例を示す図である。 図２３は、実施形態にかかる映像音声エンコーダの概略機能構成例を示すブロック図である。 図２４は、実施形態にかかる映像音声エンコーダの動作例を示すフローチャートである。 図２５は、最新のブラウザ出力画像がＩフレーム生成用の画像である場合を説明するための模式図である。 図２６は、最新のブラウザ出力画像がＩフレーム生成用の画像の次のＰフレーム生成用の画像である場合を説明するための模式図である。 図２７は、最新のブラウザ出力画像がＰフレーム生成用の画像のさらに次のＰフレーム生成用の画像である場合を説明するための模式図である。 図２８は、変形例にかかるブラウザ出力画像と更新領域との一例を示す図である。 図２９は、スキップフレームを利用しない場合の映像配信の流れを示す概念図である。 図３０は、実施形態にかかるスキップフレームを利用した場合の映像配信の流れを示す概念図である。 図３１は、実施形態にかかるスキップフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。 図３２は、強制Ｉフレームを利用した場合の映像配信の流れを示す概念図である。 図３３は、実施形態にかかる強制Ｉフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。 図３４は、実施形態にかかるスキップフレームおよび強制Ｉフレームを利用した場合の映像配信の流れを示す概念図である。 図３５は、実施形態にかかるスキップフレームおよび強制Ｉフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。

以下に添付図面を参照して、この発明に係るエンコーダ、映像処理サーバ、映像処理システム、エンコード方法およびそのプログラムの実施形態を詳細に説明する。以下で示す実施形態は、クラウドコンピューティングを利用した映像音声処理システムとしての適用例である。

＜概要＞
本実施形態の映像音声処理システムは、クラウド上にあるウェブブラウザ（以下、クラウドブラウザという。）によりウェブコンテンツをレンダリングし、その結果を映像および音声として端末に配信して、端末で再生させる。

本実施形態の映像音声処理システムでは、クラウドブラウザを最新化しておくことで、ローカルのウェブブラウザを最新化しなくても、最新のリッチなウェブコンテンツをブラウジングすることが可能となる。また、映像および音声を再生する負荷はさほど高くないため、マシンスペックが低くても、映像および音声の再生は可能である。以上のことから、クラウドブラウザによりウェブコンテンツをレンダリングし、その結果を映像および音声として配信する本実施形態の映像音声処理システムを利用すると、リッチなウェブコンテンツを低スペックの端末でブラウジングすることが可能になる。つまり、本実施形態の映像音声処理システムを利用すると、端末側の負荷を低減させつつ、リッチなウェブコンテンツをブラウジングすることができる。

さらに、本実施形態の映像音声処理システムでは、ブラウジングしているウェブコンテンツに対しての端末からの入力（マウスクリック、タップ、スクロールなど）がイベントとしてクラウドブラウザにリアルタイムに送信され、ウェブコンテンツに反映される。すなわち、本実施形態の映像音声処理システムによれば、映像および音声として端末に配信されているウェブコンテンツをインタラクティブに操作することが可能である。

また、本実施形態の映像音声処理システムは、ウェブコンテンツを映像および音声として配信する仕組みであるため、同一のウェブコンテンツを多拠点に同時に配信（マルチキャスト）することもでき、ブラウジングの内容を多拠点で共有することができる。

また、本実施形態の映像音声処理システムは、ウエブコンテンツの映像と音声とを、それぞれ別個の端末に配信し、別個の端末で同期をとりながらこれら映像と音声とを再生させることができる。

図１は、本実施形態の映像音声処理システムの概要を説明する図である。図１に示すように、この映像音声処理システムは、主に、クラウド側の管理サーバ１００および映像音声処理エンジンサーバ（以下、エンジンサーバと略称する。）２００と、クライアント側のクライアント端末３００およびデバイス４００と、を備える。

管理サーバ１００は、映像音声処理システムのサービスを管理する装置である。エンジンサーバ２００は、管理サーバ１００による管理のもとで実際にウェブコンテンツをレンダリングし、映像および音声として配信する装置であり、クラウドブラウザと映像エンコーダおよび音声エンコーダとを備えている。エンジンサーバ２００および管理サーバ１００の少なくとも一方は本発明に係る「映像処理サーバ」に相当する。

クライアント端末３００およびデバイス４００は、映像音声処理システムのサービスを受けるユーザが使用する端末であり、映像音声処理システム専用のアプリケーションプログラムを内蔵している。以下、クライアント端末３００が内蔵しているアプリケーションプログラムをクライアントアプリといい、デバイス４００が内蔵しているアプリケーションプログラムをデバイスアプリという。また、クライアント端末３００およびデバイス４００を総称する場合は、端末５００という。

図１を参照して、本実施形態の映像音声処理システムの動作概要を説明する。映像音声処理システムの動作は、映像音声処理システムのサービスを受けるユーザが、端末５００を用いて管理サーバ１００にログインすることで開始される（１）。ユーザがログインすると、管理サーバ１００がエンジンサーバ２００の選定およびクラウドブラウザの割当を行い、エンジンサーバ２００に配信を指示する（２）。エンジンサーバ２００は、指定されたウェブコンテンツをクラウドブラウザによりレンダリングして画像および音声を生成する（３）。そして、エンジンサーバ２００は、クラウドブラウザにより生成された画像と音声をそれぞれ映像エンコーダおよび音声エンコーダによりエンコードして、圧縮映像および圧縮音声として端末５００に配信する（４）。

さらに、ユーザが、端末５００を用いて、映像として配信されているウェブコンテンツに対して操作（マウスクリック、タップ、スクロールなど）を行うと、その操作に応じた操作情報がエンジンサーバ２００に送信される（５）。エンジンサーバ２００は、端末５００からの操作情報をクラウドブラウザの処理に反映させる。これにより、ウェブコンテンツをインタラクティブに操作することができる。

＜システム構成＞
次に、本実施形態の映像音声処理システムの具体的な構成例を説明する。図２は、映像音声処理システムの構成例を示すシステム構成図である。図２に示すように、映像音声処理システムは、例えば、管理サーバ１００と、エンジンサーバ２００と、端末５００（クライアント端末３００およびデバイス４００）と、システムストレージサーバ６００Ａと、ユーザストレージサーバ６００Ｂと、を備える。また、映像音声処理システムは、ネットワーク上の外部認証サービス１０と接続されている。

管理サーバ１００は、ユーザの認証および管理、端末５００の管理、エンジンサーバ２００の配信管理など、映像音声処理システム全体の管理を行う。また、管理サーバ１００は、ユーザが利用するログイン画面や設定画面などを提供するウェブサイトを有する。また、管理サーバ１００は、メール送信のためのＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバを搭載している。

管理サーバ１００は、例えば、クラウドのサービス（ＩａａＳ：Ｉｎｆｒａｓｔｒａｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）上に展開される仮想マシンとして実現することができる。管理サーバ１００は、不測の事態に対応して継続的なサービス提供を実現するために、多重化して運用することが望ましい。

エンジンサーバ２００は、指定されたウェブサイトのコンテンツを映像および音声として端末５００に配信する。エンジンサーバ２００は、例えば、複数台のコンピュータを用いて構成され、利用状況に応じてスケールアウトできるようになっている。本実施形態においては、エンジンサーバ２００は、画像処理用に拡張ボードを利用する構成であり仮想環境が利用できないため、物理マシンで構成する。

エンジンサーバ２００がコンテンツを取得するウェブサイトは、連携サイト４０と一般サイト５０に分類される。連携サイト４０は、映像音声処理システムと連携してサービスを提供するウェブサイトであり、事前に連携サイト４０として登録されたウェブサイトである。連携サイト４０は、映像音声処理システムのユーザや端末５００に関する情報を利用することができる。また、連携サイト４０は、例えばマルチキャスト等、映像音声処理システムの様々な機能を利用することができる。一般サイト５０は、一般にインターネット上に存在するウェブサイトである。

クライアント端末３００は、クライアントアプリがインストールされたＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレット端末、モバイル端末などである。本実施形態では、映像音声処理システムのサービスを受けるユーザが専有して利用する端末を、クライアント端末３００として想定している。

クライアントアプリは、所定のＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）上で動作する映像音声処理システム専用のアプリケーションプログラムである。クライアントアプリは、エンジンサーバ２００から配信された映像や音声の再生を行うとともに、フレームロス数などの品質情報をエンジンサーバ２００に送信する。クライアントアプリは、クラウドブラウザを操作したり、設定画面を操作したりするための操作情報を送信する機能も有する。なお、クライアント端末３００にカメラやマイクが搭載されている場合は、これらカメラやマイクで取得された映像や音声をエンジンサーバ２００に送信することもできる。

デバイス４００は、サービスに対応したプロジェクタ、カメラ、スピーカなどである。デバイス４００には、デバイスアプリが組み込まれている。デバイス４００は、その種類によって再生できるメディアが、映像および音声、映像のみ、音声のみ、と異なったものとなる。また、映像音声処理システムのサービスに対応していないデバイスであっても、デバイスアプリが格納されたドングルを接続することで、デバイス４００として利用することもできる。

本実施形態の映像音声処理システムでは、映像を表示する複数のデバイス４００を並べて使用することで、マルチプロジェクションを行うことができる。マルチプロジェクションとは、クラウドブラウザでレンダリングされたウェブコンテンツの映像を分割し、分割した映像を複数のデバイス４００にそれぞれ送信して再生する配信方式である。マルチプロジェクションでは、複数のデバイス４００を連携させることで、大画面表示を行うことができる。

デバイスアプリは、デバイス４００に組み込まれている映像音声処理システム専用のアプリケーションプログラムである。デバイスアプリは、エンジンサーバ２００から配信された映像や音声の再生を行うとともに、フレームロス数などの品質情報をエンジンサーバ２００に送信する。デバイスアプリは、映像や音声の配信に関しては、クライアントアプリと同等の機能を持つが、以下の点がクライアントアプリと異なる。すなわち、デバイスアプリは、映像音声処理システムへの接続の際にクライアント証明書で認証を行う。また、デバイスアプリは、デバイス４００に固有のデバイスＩＤを保持する。デバイスアプリは、ユーザのログインがなくても映像や音声の配信を受けることができる。

システムストレージサーバ６００Ａは、映像音声処理システムのサービスに必要なユーザ情報や、デバイス情報などの永続的なデータを保管する。また、システムストレージサーバ６００Ａは、端末５００の状態（切断状態／待機状態／使用中）を表す状態情報や、エンジンサーバ２００の負荷の状態を表す負荷情報、セッションで用いるユーザごとの情報（Ｃｏｏｋｉｅ、ブラウザ設定情報、キャッシュ、閲覧履歴など）である実行環境情報など、映像音声処理システムの管理に用いられる各種情報を保存することができる。システムストレージサーバ６００Ａは、管理サーバ１００と例えばＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）により接続される。

ユーザストレージサーバ６００Ｂは、ユーザのデータを保存する。例えば、映像音声処理システムでは、ユーザ操作に応じて端末５００に配信される映像（および音声）をレコーディングすることができ、このレコーディング機能で録画（録音）された映像（音声）のデータをユーザストレージサーバ６００Ｂに保存することができる。また、映像音声処理システムでは、ユーザ操作に応じてクラウドブラウザでファイルをダウンロードすることができ、このクラウドブラウザでダウンロードしたファイルなどを、ユーザストレージサーバ６００Ｂに保存することができる。ユーザストレージサーバ６００Ｂのストレージ領域は、ユーザごとに契約によって割り当てられる。ユーザストレージサーバ６００Ｂは、管理サーバ１００と例えばＴＣＰ／ＩＰにより接続される。

システムストレージサーバ６００Ａおよびユーザストレージサーバ６００Ｂは、管理サーバ１００と同様に、クラウドのサービス上に展開される仮想マシンとして実現することができる。システムストレージサーバ６００Ａおよびユーザストレージサーバ６００Ｂは、多重化して運用することが望ましい。

外部認証サービス１０は、映像音声処理システムの外部のサービスを利用してユーザの認証を行う。本実施形態の映像音声処理システムでは、外部認証サービス１０にウェブサービスとしてユーザの認証を依頼し、結果を受け取り、映像音声処理システムのサービスへの認証とする。

＜機能的な構成の詳細＞
次に、映像音声処理システムを実現するための管理サーバ１００、エンジンサーバ２００、および端末５００（クライアント端末３００およびデバイス４００）における機能的な構成の詳細について説明する。

＜管理サーバ＞
まず、管理サーバ１００の機能的な構成例について説明する。図３は、管理サーバ１００の機能的な構成例を示すブロック図である。図３に示すように、管理サーバ１００は、機能的な構成要素として、ウェブサービス１０１（本発明に係る「管理装置」の「送信部」としての機能を持つ）と、エンジン用ウェブインターフェース１０２（本発明に係る「管理装置」の「取得部」としての機能を持つ）と、ＳＭＴＰサーバ１０３と、を備える。これらの構成要素は、例えば、管理サーバ１００のハードウェアとして用いるコンピュータのＯＳ上で実行されるプログラム（ソフトウェア）によって実現することができる。

ウェブサービス１０１は、連携サイト４０から映像音声処理システムの機能を利用するためにウェブサービスによるインターフェースを提供する。また、ウェブサービス１０１は、セッションＩＤをもとに接続ＩＤを発行する。

セッションＩＤは、アクセス中のユーザのセッション管理のためにウェブアプリケーションが付与する一意のＩＤである。映像音声処理システムのサービスでは、管理サーバ１００で発行されたセッションＩＤを、映像音声処理システム内での接続ＩＤとして利用する。接続ＩＤは、端末５００からの接続ごとに一意に振られるＩＤである。接続ＩＤは、端末５００、管理サーバ１００、およびエンジンサーバ２００で共有される。

ウェブサービス１０１は、ユーザ管理部１１１、デバイス管理部１１２、ＤＢアクセサ１１３、メッセージ管理部１１４、エンジン制御部１１５（本発明に係る「管理装置」の「選択部」としての機能を持つ）、および端末状態管理部１１７を有する。

ユーザ管理部１１１は、ユーザ情報を管理する。ユーザ管理部１１１は、ログイン・ログアウトの管理、複数の外部認証サービス１０の紐付け、ユーザ情報の変更（代表者設定など）、管理者によるユーザ管理などの管理機能を有する。また、ユーザ管理部１１１は、信頼関係管理部１１８およびユーザ認証部１１９を有する。

信頼関係管理部１１８は、ユーザ間の信頼関係を管理する。本実施形態の映像音声処理システムにおいては、ユーザは、基本的に自身が触れることのできる範囲の端末５００に対してのみ映像や音声を配信できるが、他のユーザとの間で信頼関係を構築することで、物理的に離れた場所にある端末５００に対しても映像や音声を配信することができる。信頼関係管理部１１８は、このユーザ間の信頼関係を管理するものであり、信頼関係表示、信頼関係構築依頼、信頼関係承認／拒否、および信頼関係解除の各機能を有する。

ユーザ認証部１１９は、外部認証サービス１０を利用した認証機能を提供する。

デバイス管理部１１２は、デバイス４００のプロパティ、ステータスの管理と、ユーザごとに利用できるデバイス４００を管理する。デバイス管理部１１２は、デバイス４００の登録・変更・削除、プロパティの更新（名称、国名コード、公開設定、機能設定（ケーパビリティ）、管理連絡先など）、ユーザごとの利用するデバイス４００の登録・表示・更新・削除、定期通信によるデバイス４００の生存管理などの管理機能を有する。

また、デバイス管理部１１２は、デバイス認証部１２０を有する。デバイス認証部１２０は、接続されたデバイス４００が許可されたデバイス４００であるか否かをチェックする。例えば、許可されたデバイス４００には共通のクライアント証明書が与えられる。デバイス管理部１１２は、このクライアント証明書の有無により、許可されたデバイス４００であるか否かを認証する。認証されたデバイス４００には接続ＩＤを発行する。この接続ＩＤにより、セッションが管理される。また、マスタデータに登録されていないデバイス４００である場合は、マスタデータへの登録を行う。登録されたデバイス４００には、デバイス４００ごとに一意のデバイスＩＤが与えられ、このデバイスＩＤがマスタデータに保存される。

ＤＢアクセサ１１３は、システムストレージサーバ６００Ａのデータベースに対して、ユーザ情報およびデバイス情報の永続的なデータの入出力を行う。また、ＤＢアクセサ１１３は、ユーザストレージサーバ６００Ｂのデータベースに対して、ユーザのデータの入出力を行う。

メッセージ管理部１１４は、一般ユーザ向けのウェブサイトのＵＩ（ユーザインターフェース）上に表示するメッセージや、ユーザへの通知を管理する。メッセージの種類としては、例えば、信頼関係構築依頼、デバイス削除、出力デバイス選択要求、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、ユーザメールアドレスへの通知などがある。

エンジン制御部１１５は、エンジンサーバ２００による映像および音声の配信を制御する。エンジン制御部１１５は、出力デバイス設定、配信情報の生成・更新、マルチプロジェクションの設定・パターン表示・補正データ受信、信頼関係者に対する出力デバイス要求、配信開始・終了、配信セッションの管理（どの端末５００がどのエンジンサーバ２００に接続されているかなど）、エンジンサーバ２００の負荷分散判定、映像の品質判定などの機能を有する。

端末状態管理部１１７は、端末５００からの定期通信（ポーリング）を受信するインターフェースを提供する。定期通信は、端末５００の生存確認、および、映像および音声の配信元のエンジンサーバ２００に関する情報の送信（初回のみ）の用途で利用される。

エンジン用ウェブインターフェース１０２は、エンジンサーバ２００から管理サーバ１００に対してのインターフェースとなるウェブサービスである。エンジン用ウェブインターフェース１０２は、クラウドブラウザの実行環境情報の保存や、端末５００からアップロードされたセンサ情報の保存、エンジンサーバ２００の負荷情報の更新などの用途で使用される。

エンジン用ウェブインターフェース１０２は、ブラウザ実行環境情報制御部１２１およびＤＢアクセサ１２２を有する。

ブラウザ実行環境情報制御部１２１は、クラウドブラウザの実行環境情報をシステムストレージサーバ６００Ａのデータベースに保存するためのインターフェースである。ブラウザ実行環境情報制御部１２１からＤＢアクセサ１２２を通じて、システムストレージサーバ６００Ａに対する実行環境情報の入出力が行われる。

ＤＢアクセサ１２２は、システムストレージサーバ６００Ａのデータベースに対して、クラウドブラウザの実行環境情報の入出力を行う。

ＳＭＴＰサーバ１０３は、ユーザに対して電子メールでメッセージを通知するために利用される。

＜エンジンサーバ＞
次に、エンジンサーバ２００の機能的な構成例について説明する。図４は、エンジンサーバ２００の機能的な構成例を示すブロック図である。図４に示すように、エンジンサーバ２００は、機能的な構成要素として、対管理サーバウェブサービス２０１と、管理サーバ送信部２０２と、配信制御部２０３と、クラウドブラウザ２０４（本発明に係る「ブラウザ」に相当）と、クラウドブラウザ制御部２０５と、エンコーダブリッジ２０６と、ブラウザＦＩＦＯ２０７と、コンテンツ取得部２０８と、送信映像音声処理部２０９と、受信映像音声処理部２１０と、映像エンコーダ２１１ａ（本発明に係る「エンコーダ」または「映像エンコーダ」に相当）と、音声エンコーダ２１１ｂ（本発明に係る「エンコーダ」または「音声エンコーダ」に相当）と、映像音声デコーダ２１２と、デコーダブリッジ２１４と、独自転送プロトコル対応サーバ２１５（本発明に係る「配信部」としての機能を持つ）と、回線適応制御部（アップロード）２１６Ａと、回線適応制御部（ダウンロード）２１６Ｂと、エンジン負荷状況報告部２１７と、を備える。なお、映像エンコーダ２１１ａと音声エンコーダ２１１ｂを区別しない場合は、これらを総称して映像音声エンコーダ２１１と表記する。これらの構成要素は、例えば、エンジンサーバ２００のハードウェアとして用いるコンピュータのＯＳ上で実行されるプログラム（ソフトウェア）によって実現することができる。

対管理サーバウェブサービス２０１は、管理サーバ１００からのリクエストを受け付ける。具体的には、対管理サーバウェブサービス２０１は、管理サーバ１００から、配信情報（マルチキャスト・マルチプロジェクション先のデバイスまたはユーザ）のリクエストや、キャリブレーション用の校正パターン映像の配信指示のリクエスト、映像および音声の配信・停止指示のリクエストなどを受け付ける。マルチキャストとは、クラウドブラウザ２０４でレンダリングされたウェブコンテンツの映像および音声を複数の端末５００に送信して再生する配信方式である。また、キャリブレーションとは、マルチプロジェクションによる映像の表示を最適化するための補正データを算出する処理である。

管理サーバ送信部２０２は、管理サーバ１００に保存する必要がある情報を管理サーバ１００に送信する。具体的には、管理サーバ送信部２０２は、キャリブレーションの結果や、クラウドブラウザ２０４のユーザ別情報（実行環境情報）の保存要求、ユーザ別の手書き情報の保存要求などを、管理サーバ１００に送信する。

配信制御部２０３は、管理サーバ１００からの指示に従って配信に関する処理を行う。具体的には、配信制御部２０３は、クラウドブラウザ２０４や映像音声エンコーダ２１１の起動・終了を指示したり、起動・終了時にエンコーダＩＤを採番したりする。エンコーダＩＤとは、配信制御部２０３が映像音声エンコーダ２１１のプロセスを管理するために採番するＩＤである。

クラウドブラウザ２０４は、エンジンサーバ２００内で動作するウェブキットベースのウェブブラウザである。クラウドブラウザ２０４は、ウェブコンテンツ等のコンテンツをレンダリングすることにより、映像（すなわち画像）や音声といった出力情報を生成する。クラウドブラウザ２０４は、ウェブコンテンツのリッチ化に対応させて常に最新化されている。本実施形態の映像音声処理システムでは、エンジンサーバ２００内に複数のクラウドブラウザ２０４を用意しており、これら複数のクラウドブラウザ２０４の中からユーザセッションに使用するクラウドブラウザ２０４が選択される。各クラウドブラウザ２０４は、Ｍｅｄｉａ Ｐｌａｙｅｒ２２１、Ｆｌａｓｈ Ｐｌａｙｅｒ２２２、独自ＪａｖａＳｃｒｉｐｔ（登録商標）２２３、およびＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）レンダラ２２４を有する。

Ｍｅｄｉａ Ｐｌａｙｅｒ２２１は、映像（および音声）ファイルなどのマルチメディアファイルをクラウドブラウザ２０４内で再生するためのブラウザプラグインである。

Ｆｌａｓｈ Ｐｌａｙｅｒ２２２は、Ｆｌａｓｈコンテンツをクラウドブラウザ２０４内で再生するためのブラウザプラグインである。

独自ＪａｖａＳｃｒｉｐｔ２２３は、映像音声処理システムに固有のサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供するＪａｖａＳｃｒｉｐｔ群である。

ＨＴＭＬレンダラ２２４は、ウェブキットベースのＨＴＭＬレンダリングエンジンである。

クラウドブラウザ制御部２０５は、クラウドブラウザ２０４のプロセスの起動・停止を管理する。クラウドブラウザ制御部２０５は、クラウドブラウザ２０４が起動されるたびに、ブラウザＩＤを採番し、管理する。ブラウザＩＤとは、クラウドブラウザ制御部２０５がクラウドブラウザ２０４のプロセスを管理するために採番するＩＤである。

クラウドブラウザ制御部２０５は、センサ受信部２２５を有する。センサ受信部２２５は、クライアント端末３００での操作イベントや、温度センサなどのセンサ情報を受け取り、適切なクラウドブラウザ２０４に渡す。

エンコーダブリッジ２０６は、クラウドブラウザ２０４が出力したＲＧＢデータ（画像）、ＰＣＭ（Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）データ（音声）を映像音声エンコーダ２１１に渡すモジュールである。エンコーダブリッジ２０６は、映像音声エンコーダ２１１がエンコードした結果を受け取り、独自転送プロトコル対応サーバ２１５に渡す機能も有する。

ブラウザＦＩＦＯ２０７は、クラウドブラウザ２０４でレンダリングされたＲＧＢデータ、ＰＣＭデータが格納されるバッファである。映像音声エンコーダ２１１は、このブラウザＦＩＦＯ２０７に格納されたデータを用いて、配信する映像や音声のエンコードを行う。

コンテンツ取得部２０８は、インターネット上のコンテンツサイトからウェブコンテンツを取得する。クラウドブラウザ２０４は、たとえばこのコンテンツ取得部２０８によって取得されるウェブコンテンツをレンダリングすることにより映像（すなわち画像）や音声といった出力情報を生成する。

送信映像音声処理部２０９は、端末５００に送信する映像や音声に対しての処理を行う。具体的には、送信映像音声処理部２０９は、例えば、マルチプロジェクション用の映像補正処理などを行う。マルチプロジェクション用の映像補正処理とは、マルチプロジェクション時のキャリブレーションにより算出された補正パラメータに従って、マルチプロジェクション用の映像の座標変換とブレンディング（オーバーラップ部分の映像の混合処理）などを行う処理である。送信映像音声処理部２０９は、拡張ボードで処理を行うことで高速化が実現される。

受信映像音声処理部２１０は、端末５００から受信する映像や音声に対しての処理を行う。具体的には、受信映像音声処理部２１０は、例えば、サイネージ向けにカメラで撮影された映像から顔や年齢、性別などを認識する処理を行う。また、受信映像音声処理部２１０は、オフィス向けに、カメラで撮影された映像から顔認識による名前タグ付けや背景映像の差し替え処理などを行う。受信映像音声処理部２１０は、送信映像音声処理部２０９と同様、拡張ボードで処理を行うことで高速化が実現される。

映像エンコーダ２１１ａは、クラウドブラウザ２０４で生成された画像を、拡張ボード内で、圧縮映像の１フレームにエンコードする。映像エンコーダ２１１ａは、映像が動かなければ（フレーム間で変化がなければ）、以降、映像が動くまでスキップフレームを挿入することで帯域をセーブする。後述の回線適応制御部２１６Ａ，２１６Ｂでは、端末５００でフレーム遅延時間を集計して定期的にエンジンサーバ２００に報告する。映像エンコーダ２１１ａは、この時間が最小となるように、映像に対する解像度変換やスキップフレームの追加処理などを行う。

音声エンコーダ２１１ｂは、クラウドブラウザ２０４で生成された音声を、拡張ボード内で、圧縮音声の１フレームにエンコードする。なお、１つの音声フレームは、所定数のサンプルで構成され、音声が停止している間は無音サンプルを付加することで、連続したフレームとする。

映像音声デコーダ２１２は、端末５００から送られてきた圧縮映像および圧縮音声を拡張ボード内でデコードする。

デコーダブリッジ２１４は、クラウドブラウザ２０４と映像音声エンコーダ２１１、独自転送プロトコル対応サーバ２１５間のデータの受け渡しを行う。デコーダブリッジは、クラウドブラウザ２０４が生成しブラウザＦＩＦＯ２０７に格納したＲＧＢデータを取り出し、エンコード結果を受け取り、独自転送プロトコル対応サーバ２１５に渡す。

独自転送プロトコル対応サーバ２１５は、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）サーバを介して映像音声処理システム独自のプロトコルにより、後述の独自転送プロトコル対応クライアント（クライアントアプリおよびデバイスアプリのモジュール）へのデータ送信およびデータ受信を行う。独自転送プロトコルは、エンジンサーバ２００と端末５００との間でリアルタイムに途切れることなくデータを送受信するためのＨＴＴＰＳベースのアプリケーション層プロトコルである。

独自転送プロトコル対応サーバ２１５は、送信レスポンス制御部２３１、ＲＴＰ作成部２３２、クライアントコマンド送信部２３３、受信レスポンス制御部２３４、受信データ分析部２３５、およびジェスチャ変換部２３６を有する。

送信レスポンス制御部２３１は、後述の独自転送プロトコル対応クライアントからリクエストされたダウンロード用のＨＴＴＰＳセッションを管理する。このダウンロード用のＨＴＴＰＳセッションのレスポンスはすぐに終了せず、一定時間（１〜数分）保持する。独自転送プロトコル対応サーバ２１５は、独自転送プロトコル対応クライアントに送るデータを動的にレスポンスのＢｏｄｙ部に書き込む。また、再接続のコストをなくすため、独自転送プロトコル対応クライアントからは前のセッションが終了しないうちに別のリクエストが届くようにする。独自転送プロトコル対応サーバ２１５を、前のリクエストが完了するまで待機させておくようにすることで、再接続が不要となる。

ＲＴＰ作成部２３２は、映像音声エンコーダ２１１で生成された圧縮映像や圧縮音声のデータ（ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）データ）に独自のヘッダを付与して、ＲＴＰパケットとして下り用のＨＴＴＰＳのＢｏｄｙ部に書き込む。

クライアントコマンド送信部２３３は、独自転送プロトコル対応クライアントに送るコマンドデータを生成し、下り用のＨＴＴＰＳのＢｏｄｙ部に書き込む。コマンドデータは、例えば、マルチプロジェクションのためのキャリブレーション時に利用するカメラの起動指示などである。

受信レスポンス制御部２３４は、独自転送プロトコル対応クライアントからリクエストされたアップロード用のＨＴＴＰＳセッションを管理する。このアップロード用のＨＴＴＰＳセッションのレスポンスはすぐに終了せず、一定時間（１〜数分）保持する。独自転送プロトコル対応クライアントは、独自転送プロトコル対応サーバ２１５に送るデータを動的にレスポンスのＢｏｄｙ部に書き込む。

受信データ分析部２３５は、独自転送プロトコル対応クライアントから送られてきたデータを種別ごとに分割し、必要なプロセスにデータを渡す。

ジェスチャ変換部２３６は、ユーザからのジェスチャイベントをクラウドブラウザ２０４が受け取れるかたちに変換する。

回線適応制御部（アップロード）２１６Ａは、端末５００からアップロードされる映像データの受信状況から、映像音声エンコーダ２１１のパラメータや再生遅延時間を決定し、映像音声デコーダ２１２や端末５００の映像音声エンコーダにパラメータの変更を伝える。

回線適応制御部（ダウンロード）２１６Ｂは、端末５００で受信される映像データや音声データの受信状況から、映像音声エンコーダ２１１のパラメータや再生遅延時間を決定し、映像音声エンコーダ２１１や端末５００の映像音声デコーダにパラメータの変更を伝える。

エンジンサーバ負荷状況報告部２１７は、エンジンサーバ２００の負荷状態を計測し、得られた負荷状態を、管理サーバ送信部２０２を介して管理サーバ１００に送信する。

＜クライアント端末＞
次に、クライアント端末３００の機能的な構成例について説明する。クライアント端末３００は、ユーザが映像音声処理システムへのログインや映像（および音声）の配信の開始・停止などを行うためのインターフェースとなる端末であり、デバイス４００としての機能も内包する。

図５は、クライアント端末３００の機能的構成の一例を示すブロック図である。図５に示すように、クライアント端末３００は、機能的な構成要素として、クライアント共通モジュール５１０と、クライアントＧＵＩ（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）３１１と、センサ送信部３１２と、映像音声デコーダ５５０と、映像音声エンコーダ５６０と、を備える。これらの構成要素は、例えば、クライアント端末３００のハードウェアとして用いるＰＣ、タブレット端末、モバイル端末などに、上述したクライアントアプリをインストールすることによって実現することができる。なお、クライアント端末３００は、図５に示すように、ハードウェアとして、例えば、入力デバイス３０１、センサ３０２、ディスプレイ３０３、スピーカ３０４、カメラ３０５、およびマイク３０６を備えた構成とすることができる。

クライアント共通モジュール５１０は、クライアントアプリとデバイスアプリとで共有できるモジュール群である。クライアント共通モジュール５１０は、独自転送プロトコル対応クライアント５２０、回線適応制御部５２１、ＲＴＰ作成部５２２、ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）作成部５２３、再生制御部５２４、デバイス設定制御部５２５、全体通信制御部５２６、クライアントコマンド受信部５２７、状態制御部５２８、定期通信部５２９、初期処理部５３０、および管理サーバ通信部５３１を有する。

独自転送プロトコル対応クライアント５２０は、エンジンサーバ２００との間のデータの送受信を行うためのＨＴＴＰＳセッションを管理する。

独自転送プロトコル対応クライアント５２０は、受信リクエスト制御部５４１、送信リクエスト制御部５４２、受信データ分析部５４３、および送信データ作成部５４４を有する。

受信リクエスト制御部５４１は、エンジンサーバ２００に対してリクエストしたダウンロード用のＨＴＴＰＳセッションを管理する。このダウンロード用のセッションのレスポンスは、すぐに終了せず、一定時間（１〜数分）保持する。エンジンサーバ２００の独自転送プロトコル対応サーバ２１５は、上述したように、独自転送プロトコル対応クライアント５２０に送るデータを動的にレスポンスのＢｏｄｙ部に書き込むため、独自転送プロトコル対応クライアント５２０は、レスポンスを受信しながらその都度、データに応じた処理を行う。

送信リクエスト制御部５４２は、エンジンサーバ２００に対してリクエストしたアップロード用のＨＴＴＰＳセッションを管理する。このアップロード用のリクエストはすぐに終了せず、一定時間（１〜数分）保持する。独自転送プロトコル対応クライアント５２０は、独自転送プロトコル対応サーバ２１５に送るデータを動的にリクエストのＢｏｄｙ部に書き込む。

受信データ分析部５４３は、受信データを種類ごとに分類し、適切なモジュールにデータを受け渡す。

送信データ作成部５４４は、入力デバイス３０１の操作に応じた操作情報を生成する。

回線適応制御部５２１は、ＲＴＰパケットの受信状況をエンジンサーバ２００に送信する。ＲＴＰパケットの受信状況の送信には、送信リクエスト制御部５４２のセッションを用いる。本実施形態の映像音声処理システムでは、独自転送プロトコル対応クライアント５２０の受信品質に応じて独自転送プロトコル対応クライアント５２０側でエンコードの品質が決定される。回線適応制御部５２１は、その品質を判断するソースとして、遅延時間を送信する。

ＲＴＰ作成部５２２は、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５から送られてきたＲＴＰデータを解析して映像音声デコーダ５５０に渡す。

ＲＴＣＰ作成部５２３は、独自転送プロトコル対応サーバ２１５から送られてきたＲＴＣＰ ＳＲパケットを解析し、それをもとにＲＴＣＰ ＲＲパケットを作成する。このＲＴＣＰ ＲＲパケットは、送信リクエスト制御部５４２から独自転送プロトコル対応サーバ２１５に送信される。

再生制御部５２４は、受信したＲＴＰパケットをバッファリングし、再生遅延時間を考慮して映像音声デコーダ５５０に渡す。

デバイス設定制御部５２５は、端末５００間の接続状況に応じて設定を制御する。クライアントアプリでは、デバイス設定制御部５２５により他のデバイス４００に対して接続情報をＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）で送信する。デバイスアプリでは、デバイス設定制御部５２５によりＵＰｎＰを受け付けて、それに応じて自身の設定を書き換える。

全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０を用いたエンジンサーバ２００との通信を制御する。例えば、全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０に対して、独自転送プロトコル対応サーバ２１５との間の時刻差を取得させる。また、全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０に対して、独自転送プロトコル対応サーバ２１５との間での独自転送プロトコルによる送信処理や受信処理の開始を指示する。

クライアントコマンド受信部５２７は、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５から送られてきたクライアントコマンドを解釈し、適切なモジュールに渡す。

状態制御部５２８は、端末５００の状態が変化したときに、状態変化を管理サーバ１００に報告する。また、状態制御部５２８は、端末５００のスリープ状態への移行と待機状態への復旧などを管理する。

定期通信部５２９は、管理サーバ１００への定期的なポーリング通信を行って、端末５００の生存を通知する。なお、初回のポーリングでは、デバイス４００の承認要求を通知して、管理サーバ１００への接続を認証する。また、端末５００に対する配信がある場合には、ポーリング通信のレスポンスとして配信元のエンジンサーバ２００の情報を取得することができる。端末５００は、指定されたエンジンサーバ２００に接続することで、映像（および音声）を受信することができるようになる。

初期処理部５３０は、端末５００の起動時に、管理サーバ１００のウェブサービス１０１に必要なデータを渡し、設定画面用の映像の受信を開始するなどの処理を行う。

管理サーバ通信部５３１は、管理サーバ１００との間で通信を行う。例えば、管理サーバ通信部５３１は、初期処理部５３０により生成された初期処理要求を管理サーバ１００に送信するために用いられる。また、管理サーバ通信部５３１は、定期通信部５２９が管理サーバ１００との間で定期的なポーリング通信を行うために用いられる。

クライアントＧＵＩ３１１は、キャリブレーションカメラ制御部３２１および手書き制御部３２２を有する。

キャリブレーションカメラ制御部３２１は、エンジンサーバ２００からのサーバコマンドによる指示に従い、キャリブレーション用にカメラ３０５の起動・停止を行う。また、キャリブレーションカメラ制御部３２１は、カメラ３０５で撮影されたキャリブレーション用の映像を、送信リクエスト制御部５４２よりエンジンサーバ２００に送信する。

手書き制御部３２２は、手書きモードの切り替えと、手書きデータの送信を行う。手書きデータの送信は、送信リクエスト制御部５４２を使用する。

センサ送信部３１２は、端末５００に搭載されている各種のセンサ３０２の情報をエンジンサーバ２００に送信する。センサ情報の送信には、送信リクエスト制御部５４２を使用する。センサ送信部３１２で扱うセンサ情報には、入力デバイス３０１を用いて配信された映像に対し行われるユーザの操作（マウスクリック、タップなど）、カメラ３０５の映像、マイク３０６で収録された音声、温度センサ、バイタルセンサなどのセンサ３０２の情報が含まれる。

映像音声デコーダ５５０は、エンジンサーバ２００から受信する圧縮映像（および圧縮音声）をデコードする。

映像音声エンコーダ５６０は、エンジンサーバ２００に対して送信するためにカメラ３０５などでキャプチャしたメディアファイルを圧縮映像（および圧縮音声）にエンコードする。

＜デバイス＞
次に、デバイス４００の機能的な構成例について説明する。デバイス４００は、デバイスアプリが組み込まれたプロジェクタ、カメラ、スピーカなどである。また、上述したように、映像音声処理システムのサービスに対応していないデバイスであっても、デバイスアプリを格納したドングルをに接続することで、当該デバイスを、映像音声処理システムのサービスに対応したデバイス４００として機能させることもできる。

図６は、デバイス４００の機能的構成の一例を示すブロック図であり、図６（ａ）は、デバイス４００の１つであるプロジェクタ４００Ａの構成例を示し、図６（ｂ）は、デバイス４００の１つであるスピーカユニット４００Ｂの構成例を示し、図６（ｃ）は、デバイス４００の１つであるカメラユニット４００Ｃの構成例を示している。なお、図６（ａ）のプロジェクタ４００Ａは、デバイスアプリが格納されたドングルが接続されたデバイス４００であり、ハードウェアとして映像を投影する投影エンジン４０１を備える。また、図６（ｂ）のスピーカユニット４００Ｂは、ハードウェアとしてスピーカ４０２を備える。また、図６（ｃ）のカメラユニット４００Ｃは、ハードウェアとしてカメラ４０３およびマイク４０４を備える。

プロジェクタ４００Ａのデバイスアプリは、図６（ａ）に示すように、クライアント共通モジュール５１０と、エンジンサーバ２００から配信された圧縮映像をデコードする映像音声デコーダ５５０とを含む。また、スピーカユニット４００Ｂのデバイスアプリは、図６（ｂ）に示すように、クライアント共通モジュール５１０と、エンジンサーバ２００から配信された圧縮音声をデコードする映像音声デコーダ５５０とを含む。また、カメラユニット４００Ｃのデバイスアプリは、図６（ｃ）に示すように、クライアント共通モジュール５１０と映像音声エンコーダ５６０とを含む。これらの構成要素は、例えば、デバイス４００に組み込まれた（あるいはドングルに格納された）デバイスアプリによって実現することができる。

＜映像音声処理システムの主要な処理＞
次に、本実施形態の映像音声処理システムの主要な処理について説明する。映像音声処理システムの処理は、主に、端末５００を起動する端末起動処理と、エンジンサーバ２００から配信される映像を端末５００で受信して再生する映像受信・再生処理と、エンジンサーバ２００から配信される音声を端末５００で受信して再生する音声受信・再生処理と、端末５００で映像として再生されたウェブコンテンツに対する操作に応じた操作情報をエンジンサーバ２００に送信する操作イベント送信処理と、１つのクラウドブラウザ２０４でレンダリングされたウェブコンテンツの映像（および音声）を複数の端末５００に同時に配信するマルチキャストと、回線の品質に応じてエンコーダパラメータ等の調整を行う回線適応制御処理と、１つのクラウドブラウザ２０４でレンダリングされたウェブコンテンツの映像（および音声）を分割して複数のプロジェクタ４００Ａを用いて再生するマルチプロジェクションと、端末５００の状態を管理する端末状態管理処理と、エンジンサーバ２００の負荷状態を判定するエンジンサーバ負荷判定処理と、ユーザセッション終了処理と、を含む。以下、各処理の詳細について説明する。

＜端末起動処理（デバイス）＞
まず、デバイス４００を起動するための端末起動処理について説明する。図７は、デバイス４００を起動するための端末起動処理の具体例を示すシーケンス図である。

まず、ユーザがデバイス４００に対して起動の操作を行うと、デバイス４００の初期処理部５３０が、管理サーバ通信部５３１を介して管理サーバ１００に対して初期処理要求（リクエスト）を送信する。初期処理要求には、端末タイプやデバイスＩＤなどの情報が付与される。また、管理サーバ１００に対するアクセスの際には、クライアント証明書による認証を行うものとする。なお、端末タイプは、クライアントアプリとデバイスアプリとを区別するためのコードであり、プログラム間の呼び出しの引数で使用される。

管理サーバ１００では、デバイス４００からの初期処理要求に応じて、まず、ウェブサービス１０１が接続ＩＤを発行する。次に、ウェブサービス１０１は、デバイス管理部１１２に対して、デバイスＩＤを指定してデバイス４００の登録を指示する。

デバイス管理部１１２は、ＤＢアクセサ１１３を介してシステムストレージサーバ６００Ａにアクセスし、指定されたデバイスＩＤで示されるデバイス４００がマスタデータに存在するか否かを確認する。ここで、指定されたデバイスＩＤで示されるデバイス４００がマスタデータに存在しない場合は、デバイス管理部１１２は、デバイス４００をマスタデータに新規に登録（新規保存）する処理を行う。

次に、ウェブサービス１０１は、定期通信の間隔などの初期パラメータの取得を行った後、エンジンサーバ準備処理を行う。なお、エンジンサーバ準備処理の詳細は後述する。

エンジンサーバ準備処理が終わると、初期処理要求に対する応答（レスポンス）として、管理サーバ１００のウェブサービス１０１からデバイス４００に対して、接続ＩＤ、配信ＩＤ、エンジンサーバＵＲＬ、および初期パラメータが送られる（「送信部」に相当）。エンジンサーバＵＲＬは、後述のエンジンサーバ準備処理によりエンジン制御部１１５によって選択されたエンジンサーバ２００に、端末５００がアクセスするための情報である。配信ＩＤは、配信が行われるたびに管理サーバ１００により発行される一意のＩＤである。発行された配信ＩＤは、端末５００、管理サーバ１００、およびエンジンサーバ２００で共有される。

デバイス４００では、管理サーバ１００から接続ＩＤ、配信ＩＤ、エンジンサーバＵＲＬ、および初期パラメータを取得すると、初期パラメータでコマンドの受信を開始するために、独自転送プロトコル対応クライアント５２０がセッション確立処理を行い、端末起動処理が終了する。なお、セッション確立処理の詳細は後述する。

＜端末起動処理（クライアント端末）＞
次に、クライアント端末３００を起動するための端末起動処理について説明する。図８は、クライアント端末３００を起動するための端末起動処理の具体例を示すシーケンス図である。

まず、ユーザがクライアント端末３００に対して起動の操作を行うと、クライアント端末３００の初期処理部５３０が、管理サーバ通信部５３１を介して、管理サーバ１００に対して初期処理要求を送信する。初期処理要求には、端末タイプやサービスＩＤなどの情報が付与される。サービスＩＤは、映像音声処理システム内でサービスを提供する場合のサービスＩＤ、もしくは連携サイトでサービスを提供する場合の連携サービスＩＤである。

管理サーバ１００では、クライアント端末３００からの初期処理要求に応じて、まず、ウェブサービス１０１が接続ＩＤを発行する。次に、ウェブサービス１０１は、定期通信の間隔などの初期パラメータの取得を行った後、エンジンサーバ準備処理を行う。なお、エンジンサーバ準備処理の詳細は後述する。

エンジンサーバ準備処理が終わると、初期処理要求に対する応答として、管理サーバ１００のウェブサービス１０１からからクライアント端末３００に対して、接続ＩＤ、配信ＩＤ、エンジンサーバＵＲＬ、および初期パラメータが送られる（「送信部」に相当）。

クライアント端末３００では、管理サーバ１００から接続ＩＤ、配信ＩＤ、エンジンサーバＵＲＬ、および初期パラメータを取得すると、初期パラメータでログイン画面の映像の受信を開始するために、独自転送プロトコル対応クライアント５２０がセッション確立処理を行い、端末起動処理が終了する。なお、セッション確立処理の詳細は後述する。

＜エンジン準備処理（デバイス）＞
次に、図７に示した端末起動処理（デバイス）において実施されるエンジン準備処理について説明する。このエンジン準備処理では、デバイス４００が起動時に配信を受けるために、管理サーバ１００が、エンジンサーバ２００に対して新規接続の開始を指示する。エンジンサーバ２００は、デバイス４００からの受信リクエストに備える。図９は、このエンジン準備処理の具体例を示すシーケンス図である。

まず、管理サーバ１００のウェブサービス１０１が、エンジン制御部１１５に対して端末タイプ、デバイスＩＤ、および接続ＩＤを渡して、エンジンサーバ２００の準備を指示する。エンジン制御部１１５は、この指示に従って、エンジンサーバ２００の負荷情報などをもとに、配信に使用するエンジンサーバ２００を決定し、エンジンサーバＩＤを発行する（「選択部」に相当）。エンジンサーバＩＤは、配信に使用するエンジンサーバ２００を一意に特定するためのＩＤである。

次に、エンジン制御部１１５は、配信情報の作成を行う。具体的には、エンジン制御部は、配信ＩＤを発行し、これを接続ＩＤやエンジンサーバＩＤなどと紐づけて管理する。また、配信ＩＤは、ウェブサービス１０１に渡される。

エンジン制御部１１５は、配信情報の作成を行った後、エンジンサーバ２００に対して準備要求を送信し、配信ＩＤ、接続ＩＤ、および端末タイプを渡す。

エンジンサーバ２００では、管理サーバ１００からの準備要求を対管理サーバウェブサービス２０１が受け取って、配信制御部２０３に対して準備を指示する。配信制御部２０３は、配信ＩＤ、接続ＩＤ、端末タイプを保持して、デバイス４００からの受信リクエストに備える。

＜エンジン準備処理（クライアント端末）＞
次に、図８に示した端末起動処理（クライアント端末）において実施されるエンジン準備処理について説明する。このエンジン準備処理では、クライアント端末３００が起動時に配信を受けるために、管理サーバ１００が、エンジンサーバ２００に対して新規配信の開始を指示する。エンジンサーバ２００は、クラウドブラウザ２０４、映像音声エンコーダ２１１、独自転送プロトコル対応サーバ２１５等を起動し、クライアント端末３００からの受信リクエストに備える。図１０は、このエンジン準備処理の具体例を示すシーケンス図である。

まず、管理サーバ１００のウェブサービス１０１が、エンジン制御部１１５に対して端末タイプ、接続ＩＤ、およびログインＵＲＬを渡して、エンジンサーバ２００の準備を指示する。エンジン制御部１１５は、この指示に従って、エンジンサーバ２００の負荷情報などをもとに、配信に使用するエンジンサーバ２００を決定し、エンジンサーバＩＤを発行する（「選択部」に相当）。

次に、エンジン制御部１１５は、配信情報の作成を行う。具体的には、エンジン制御部１１５は、配信ＩＤを発行し、これを接続ＩＤやエンジンサーバＩＤなどと紐づけて管理する。また、配信ＩＤは、ウェブサービス１０１に渡される。

エンジン制御部１１５は、配信情報の作成を行った後、エンジンサーバ２００に対して準備要求を送信し、配信ＩＤ、接続ＩＤ、および端末タイプを渡す。

エンジンサーバ２００では、管理サーバ１００からの準備要求を対管理サーバウェブサービス２０１が受け取って、配信制御部２０３に対して準備を指示する。配信制御部２０３は、配信ＩＤ、接続ＩＤ、端末タイプを保持する。

また、配信制御部２０３は、ブラウザＦＩＦＯ２０７を作成し、接続ＩＤおよびブラウザＦＩＦＯ２０７を渡してエンコーダブリッジ２０６を起動する。エンコーダブリッジ２０６は、映像音声エンコーダ２１１を起動する。そして、配信制御部２０３は、起動した映像音声エンコーダ２１１のエンコーダＩＤ（エンコーダブリッジ２０６のＰＩＤ）を保持する。エンコーダＩＤは、配信制御部２０３が映像音声エンコーダ２１１のプロセスを管理するために採番されるＩＤである。

次に、配信制御部２０３は、実行環境情報取得処理を行って、管理サーバ１００から実行環境情報を取得する。なお、実行環境情報取得処理の詳細は後述する。

次に、配信制御部２０３は、ブラウザＩＤを渡してクラウドブラウザ制御部２０５を起動する。クラウドブラウザ制御部２０５は、クラウドブラウザ２０４を起動する。そして、配信制御部２０３は、起動したクラウドブラウザ２０４のブラウザＩＤを保持して、クライアント端末３００からの受信リクエストに備える。ブラウザＩＤは、クラウドブラウザ制御部がクラウドブラウザ２０４のプロセスを管理するために採番されるＩＤである。

＜実行環境情報取得処理＞
次に、図１０に示したエンジン準備処理において実施される実行環境情報取得処理について説明する。クラウドブラウザ２０４は、エンジンサーバ２００上で実行されるため、ユーザごとの情報（Ｃｏｏｋｉｅ、ブラウザ設定情報、キャッシュ、閲覧履歴など）を保持することができない。そこで、それらの情報を管理サーバ１００に保存しておき、クラウドブラウザ２０４の起動時に取得して設定できるようにしている。図１１は、実行環境情報取得処理の具体例を示すシーケンス図である。

まず、エンジンサーバ２００の配信制御部２０３が、エンジンサーバＩＤの確認を行う。そして、現在のエンジンサーバ２００が、ユーザが前回使用したエンジンサーバ２００ではない場合は、配信制御部２０３は、管理サーバ送信部２０２を介して、管理サーバ１００に対して実行環境情報取得の要求を行う。

管理サーバ１００では、エンジンサーバ２００からの要求をエンジン用ウェブインターフェース１０２が受け取って、ブラウザ実行環境情報制御部１２１に実行環境情報の取得を指示する。

ブラウザ実行環境情報制御部１２１は、ＤＢアクセサ１２２を介してシステムストレージサーバ６００Ａにアクセスし、システムストレージサーバ６００Ａから、ユーザが前回使用したエンジンサーバ２００に関する実行環境情報を取得する。ブラウザ実行環境情報制御部１２１が取得した実行環境情報は、エンジン用ウェブインターフェース１０２を介してエンジンサーバ２００に送られる。エンジンサーバ２００の配信制御部２０３は、取得した実行環境情報を保存する。

その後、配信制御部２０３は、エンジンサーバ２００上のユーザデータフォルダ２５０（図４参照）からユーザＩＤを指定して実行環境情報を取得する。なお、ユーザＩＤは映像音声処理システムのサービスを受けるユーザに付与される一意のＩＤである。ユーザＩＤは、例えば外部認証サービス１０でユーザの認証を行う場合、最初にユーザが外部認証サービス１０で認証を受けて管理サーバ１００にログインした際に割り当てられる。ユーザＩＤは、端末５００、管理サーバ１００、およびエンジンサーバ２００で共有される。

＜セッション確立処理＞
次に、図７および図８に示した端末起動処理において実施されるセッション確立処理について説明する。端末５００は、初期処理が完了した後、指示されたエンジンサーバ２００との間でセッション確立処理を行い、独自転送プロトコルによる接続（独自転送プロトコルによる受信・送信）を開始する。また、端末５００は、すでにエンジンサーバ２００と接続している場合においても、接続先が変わる場合にはセッション確立処理を行って、エンジンサーバ２００との再接続を行う。図１２は、セッション確立処理の具体例を示すシーケンス図である。

まず、端末５００の初期処理部５３０が、再生制御部５２４に対して初期化処理を要求する。再生制御部５２４は、この要求に応じて、新たに映像音声デコーダ５５０を起動する。このとき、再生制御部５２４は、すでに起動している映像音声デコーダ５５０があれば先にその映像音声デコーダ５５０を終了させた後に、新たに映像音声デコーダ５５０を起動する。

次に、初期処理部５３０は、全体通信制御部５２６に対して、エンジンサーバＵＲＬと配信ＩＤを指定して、セッション確立処理を指示する。

全体通信制御部５２６は、この指示に従って、まず、独自転送プロトコル対応クライアント５２０に対して時刻差異の取得要求を出す。独自転送プロトコル対応クライアント５２０は、この要求に応じて、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５との間で時刻合わせ処理を行い、独自転送プロトコル対応サーバ２１５との間の時刻差を全体通信制御部５２６に返す。全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０から取得した時刻差の設定（時刻差異設定）を再生制御部５２４に指示する。なお、独自転送プロトコル対応クライアント５２０と独自転送プロトコル対応サーバ２１５との間の時刻合わせ処理の詳細は後述する。

次に、全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０に送信処理の開始を指示する。これにより、独自転送プロトコル対応クライアント５２０とエンジンサーバ２００の独自転送プロトコル対応サーバ２１５との間で、独自転送プロトコルによる送信処理が行われる。また、全体通信制御部５２６は、独自転送プロトコル対応クライアント５２０に受信処理の開始を指示する。これにより、独自転送プロトコル対応クライアント５２０とエンジンサーバ２００の独自転送プロトコル対応サーバ２１５との間で、独自転送プロトコルによる受信処理が行われる。なお、独自転送プロトコルによる送信処理および受信処理の詳細は後述する。

＜時刻合わせ処理＞
次に、図１２に示したセッション確立処理において実施される時刻合わせ処理について説明する。

時刻合わせ処理では、まず、端末５００の独自転送プロトコル対応クライアント５２０が、管理サーバ１００から指定されたエンジンサーバ２００（エンジンサーバＵＲＬによりアクセスできるエンジンサーバ２００）に対して時刻差異の取得要求を送信する。このとき、独自転送プロトコル対応クライアント５２０は、例えば、時刻合わせの通信であることを示す情報の入ったＨＴＴＰリクエストのヘッダのみを送り（Ｂｏｄｙ部は送らない）、セッションを確立させる。そして、独自転送プロトコル対応クライアント５２０は、セッションが確立したのを確認した後、ＨＴＴＰリクエストのＢｏｄｙ部に独自転送プロトコル対応クライアント５２０上の時刻ｔ１を記述する。

エンジンサーバ２００の独自転送プロトコル対応サーバ２１５では、受信レスポンス制御部２３４が、ＨＴＴＰリクエストのヘッダを参照して時刻合わせの通信であることを確認し、ＨＴＴＰリクエストのＢｏｄｙ部の到着を待つ。そして、受信レスポンス制御部２３４は、ＨＴＴＰリクエストのＢｏｄｙ部が６４ビット長分受信できたときの独自転送プロトコル対応サーバ２１５上の時刻Ｔ１を取得する。

次に、受信レスポンス制御部２３４は、レスポンスを作成する。具体的には、受信レスポンス制御部２３４は、レスポンスのヘッダを送信した後、レスポンスのＢｏｄｙ部に、そのときの独自転送プロトコル対応サーバ２１５上の時刻Ｔ２を記述する。

独自転送プロトコル対応クライアント５２０は、レスポンスのＢｏｄｙ部の到着を待ち、６４ビット長分受信できたときの独自転送プロトコル対応クライアント５２０上の時刻ｔ２を取得する。そして、独自転送プロトコル対応クライアント５２０は、下記式（１）により、時刻の差異θを求める。
θ＝（Ｔ１＋Ｔ２）／２−（ｔ１＋ｔ２）／２ ・・・（１）

独自転送プロトコル対応クライアント５２０は、初期パラメータで定められた規定回数だけ、独自転送プロトコル対応サーバ２１５との間で上記の処理を繰り返し、規定回数分のθの平均値を、独自転送プロトコル対応サーバ２１５との間の時刻差とする。なお、時刻はすべて、例えば６４ビットのＵＴＣ（Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ
Ｔｉｍｅ）タイムスタンプとする。

＜独自転送プロトコルによる受信処理＞
次に、独自転送プロトコルによる受信処理について説明する。独自転送プロトコルによる受信処理では、例えば、ＨＴＴＰＳベースの独自転送プロトコルにより、独自転送プロトコル対応サーバ２１５から独自転送プロトコル対応クライアント５２０に対して、映像（および音声）のデータやコマンドのデータをリアルタイムに送信する（「配信部」に相当）。つまり、映像（および音声）のＲＴＰデータだけでなく、端末５００に送信するコマンド（配信開始、配信先切り替えやキャリブレーション用のカメラ起動のコマンドなど）についても、独自転送プロトコルによる受信処理で独自転送プロトコル対応クライアント５２０に送信する。

独自転送プロトコルによる受信処理では、１つのリクエストに対して１つのパケットを処理するのではなく、独自転送プロトコル対応サーバ２１５側でレスポンスを切らずに一定時間（初期パラメータにより設定）持続させ、その間にリクエストのＢｏｄｙ部に動的にデータの書き込みを行う。これにより、１つのパケットごとにリクエストを発行する場合に懸念される遅延の発生を有効に抑制することができる。

リクエストは、一定時間が経過すると切断され、新たなリクエストに切り替えられる。ただし、リクエストの切り替え時に、セッションを完全に切断してから新しいセッションを確立すると、データ受信の連続性が失われる。そのため、受信中のセッションが切れる前に新しいセッションを確立することとする。この方法を採用することにより、ＨＴＴＰＳのセッションが切れた場合にも一定時間経過すると新しいセッションが確立されるため、再接続できるようになる。

＜独自転送プロトコルによる送信処理＞
次に、独自転送プロトコルによる送信処理について説明する。独自転送プロトコルによる送信処理では、例えば、ＨＴＴＰＳベースの独自転送プロトコルにより、独自転送プロトコル対応クライアント５２０から独自転送プロトコル対応サーバ２１５に対して、端末５００での映像（および音声）のデータ受信状況、入力デバイス３０１の操作に応じた操作情報、温度センサなどのセンサ３０２が検知したセンサ情報、カメラ３０５，４０３で撮影した画像データなどをリアルタイムに送信する。

独自転送プロトコルによる送信処理では、独自転送プロトコルによる受信処理と同様に、セッションを持続させてデータを送信する。独自転送プロトコルによる送信処理が受信処理と異なるところは、リクエストのヘッダを送信し、接続が確立した後にリクエストのＢｏｄｙ部を終了せずに、動的にデータを書き込むことである。

＜映像受信・再生処理＞
次に、映像受信・再生処理について説明する。映像受信・再生処理では、エンジンサーバ２００が、クラウドブラウザ２０４が出力するブラウザ画像を映像エンコーダ２１１ａで即時に圧縮映像の１フレームにエンコード（圧縮）し、ＲＴＰパケットを生成して、端末５００に配信する。端末５００は、エンジンサーバ２００から配信されるＲＴＰパケットを受信してデコード（伸張）し、ディスプレイ３０３や投影エンジン４０１で映像を再生する。図１３は、映像受信・再生処理の具体例を示すシーケンス図である。

まず、エンジンサーバ２００のクラウドブラウザ２０４からブラウザＦＩＦＯ２０７へのブラウザ画像の書き出しが行われる。このブラウザ画像の書き出しは、クラウドブラウザ２０４で画像の更新があるたびに繰り返し行われる。

次に、エンコーダブリッジ２０６が、ブラウザＦＩＦＯ２０７からのブラウザ画像の読み込みを行い、映像エンコーダ２１１ａに対して、読み込んだブラウザ画像のエンコードを指示する。このとき、エンコーダブリッジ２０６は、ブラウザＦＩＦＯ２０７にブラウザ画像がない場合は、映像エンコーダ２１１ａに対して、スキップフレームを返すように要求する。

映像エンコーダ２１１ａは、ブラウザ画像を圧縮映像の１フレームとしてエンコード（圧縮）して、得られたＲＴＰデータをエンコーダブリッジ２０６に返す。なお、マルチプロジェクションを行う場合は、映像エンコーダ２１１ａは、１つのブラウザ画像を複数の映像に分割する映像分割処理を行った後、送信映像音声処理部２０９を用いて映像補正処理を行い、複数のＲＴＰデータを作成してエンコーダブリッジ２０６に返す。

次に、エンコーダブリッジ２０６は、独自転送プロトコル対応サーバ２１５に対して、ＲＴＰ送信を指示する。これにより、独自転送プロトコル対応サーバ２１５と端末５００の独自転送プロトコル対応クライアント５２０との間で独自転送プロトコルによる受信処理が行われ、エンジンサーバ２００のクラウドブラウザ２０４でレンダリングされたウェブコンテンツの画像が圧縮映像として端末５００にリアルタイムに送信される。独自転送プロトコルによる受信処理を行った端末５００の独自転送プロトコル対応クライアント５２０は、再生制御部５２４に対して、独自転送プロトコル対応サーバ２１５から受信したＲＴＰデータを渡して再生処理を指示する。

次に、再生制御部５２４は、回線適応制御部５２１に対する受信状況の報告を行い、回線適応の判定に用いる遅延時間情報を渡す。そして、再生制御部５２４は、再生時間調整を行う。再生時間調整とは、適切な再生遅延時間を設定することで映像や音声を再生する時間を調整する処理である。再生遅延時間は、端末５００で再生までにバッファリングする時間を定める基準となる時間であり、端末５００が使用する回線の品質等に応じた時間差を吸収するために設定される。再生制御部５２４は、この設定された再生遅延時間に基づいて、ＲＴＰパケットのヘッダに書き込まれたタイムスタンプに対して、どれだけ遅延して（バッファして）再生するかを決定する。

次に、再生制御部５２４は、映像音声デコーダ５５０に対してＲＴＰデータを渡してデコードを指示する。映像音声デコーダ５５０は、この指示に従って、ＲＴＰデータをデコードし、ディスプレイ３０３や投影エンジン４０１に映像を再生させる。ブラウザ画像の読み込みから映像再生までの処理は、クラウドブラウザ２０４からブラウザＦＩＦＯ２０７へのブラウザ画像の書き出しがあるたびに繰り返し行われる。

＜音声受信・再生処理＞
次に、音声受信・再生処理について説明する。音声受信・再生処理では、エンジンサーバ２００が、クラウドブラウザ２０４から出力される音声データを音声エンコーダ２１１ｂで圧縮音声の１フレームに即時にエンコードし、ＲＴＰパケットを生成して端末５００に配信する。端末５００は、エンジンサーバ２００から配信されるＲＴＰパケットを受信してデコードし、スピーカ３０４，４０２で音声を再生する。図１４は、音声受信・再生処理の具体例を示すシーケンス図である。

まず、エンジンサーバ２００のクラウドブラウザ２０４からブラウザＦＩＦＯ２０７への音声出力が行われる。この音声出力は、音声フレーム単位で繰り返し行われる。１つの音声フレームは、例えば１０２４サンプルで構成されるものとする。音声が途中で停止した場合は、１０２４サンプルに満たない場合でも無音サンプルを付加することで１０２４サンプルの音声フレームを出力するものとする。

次に、エンコーダブリッジ２０６が、ブラウザＦＩＦＯ２０７からの音声の読み込みを行い、音声エンコーダ２１１ｂに対して、読み込んだ音声のエンコードを指示する。音声エンコーダ２１１ｂは、音声をエンコードしてＲＴＰデータを生成し、エンコーダブリッジ２０６に返す。

次に、エンコーダブリッジ２０６は、独自転送プロトコル対応サーバ２１５に対して、ＲＴＰ送信を指示する。これにより、独自転送プロトコル対応サーバ２１５と端末５００の独自転送プロトコル対応クライアント５２０との間で独自転送プロトコルによる受信処理が行われ、エンジンサーバ２００のクラウドブラウザ２０４でレンダリングされたウェブコンテンツの音声が圧縮音声として端末５００にリアルタイムに送信される。独自転送プロトコルによる受信処理を行った端末５００の独自転送プロトコル対応クライアント５２０は、再生制御部５２４に対して独自転送プロトコル対応サーバ２１５から受信したＲＴＰデータを渡して再生処理を指示する。

次に、再生制御部５２４は、回線適応制御部５２１に対する受信状況の報告を行い、回線適応の判定に用いる遅延時間情報を渡す。そして、再生制御部５２４は、再生時間調整を行う。

次に、再生制御部５２４は、映像音声デコーダ５５０に対してＲＴＰデータを渡してデコードを指示する。映像音声デコーダ５５０は、再生制御部の指示に従って、ＲＴＰデータをデコードし、スピーカ３０４，４０２に音声を再生させる。音声の読み込みから再生までの処理は、音声フレームの出力があるたびに繰り返し行われる。

＜操作イベント送信処理＞
次に、操作イベント送信処理について説明する。ユーザは、端末５００に表示されているウェブコンテンツの映像を、例えば、クライアント端末３００の入力デバイス３０１などを用いて通常のブラウザのように操作することができる。操作イベント送信処理では、ユーザの操作に応じたデータを直ちにエンジンサーバ２００に送信し、クラウドブラウザ２０４に渡して操作のエミュレートを行う。なお、入力デバイス３０１を用いた操作のうちジェスチャ操作は、クライアントの環境ごとに操作情報が異なるため、エンジンサーバ２００のジェスチャ変換部２３６でクラウドブラウザ２０４用の操作イベントに変換して、クラウドブラウザ２０４に渡すこととする。図１５は、操作イベント送信処理の具体例を示すシーケンス図である。

まず、ユーザがクライアント端末３００の入力デバイス３０１を操作すると、入力デバイス３０１からセンサ送信部３１２を介して送信データ作成部５４４に操作情報が渡される。送信データ作成部５４４は、この情報をもとにエンジンサーバ２００に送信する操作情報を生成し、ユーザＩＤと操作情報とを独自転送プロトコル対応クライアント５２０に渡して、操作情報の送信を指示する。これにより、独自転送プロトコル対応クライアント５２０とエンジンサーバ２００の独自転送プロトコル対応サーバ２１５との間で独自転送プロトコルによる送信処理が行われ、クライアント端末３００の入力デバイス３０１の操作に応じた操作情報が、ユーザＩＤとともにエンジンサーバ２００に送信される。

エンジンサーバ２００の独自転送プロトコル対応サーバ２１５は、ユーザＩＤと操作情報を受信すると、これを操作イベントとしてジェスチャ変換部２３６を介してクラウドブラウザ制御部２０５に渡す。クラウドブラウザ制御部２０５は、ユーザＩＤと紐付けられている配信情報を配信制御部２０３から取得してクラウドブラウザ２０４を特定し、そのクラウドブラウザ２０４に操作イベントを渡す。クラウドブラウザ２０４は、操作イベントの内容をもとにユーザの操作をエミュレートする。

＜マルチキャスト＞
次に、マルチキャストについて説明する。マルチキャストは、クラウドブラウザ２０４でレンダリングされたウェブコンテンツの映像（および音声）を複数の端末５００に送信して再生する配信方式である。マルチキャストを行うことにより、ユーザが端末５００でブラウジングしているクラウドブラウザ２０４の映像（および音声）を、自身が管理する他の端末５００または他のユーザが使用する端末５００に対して配信することができる。図１６は、マルチキャストの具体例を示すシーケンス図である。この図１６では、映像の配信を指示するユーザ（以下、配信元ユーザという。）が、他のユーザ（以下、配信先ユーザという。）の端末５００に映像を配信する例を示している。

まず、配信元ユーザが端末５００を用いて配信設定を行うと、管理サーバ１００のウェブサービス１０１がこの設定を受け付ける。そして、ウェブサービス１０１は、ＤＢアクセサ１１３を介してシステムストレージサーバ６００Ａにアクセスし、配信元ユーザのユーザＩＤをキーとして、配信元ユーザが配信先として設定している配信先ユーザまたはデバイス４００の一覧をシステムストレージサーバ６００Ａから取得する。

また、配信元ユーザが端末５００を用いて配信先の追加を指示すると、管理サーバ１００のウェブサービス１０１がこの指示を受け付ける。そして、ウェブサービス１０１は、ＤＢアクセサ１１３を介してシステムストレージサーバ６００Ａにアクセスし、指示された配信先を追加して配信情報の更新を行う。

次に、配信元ユーザが端末５００を用いて配信開始を指示すると、管理サーバ１００のウェブサービス１０１がこの指示を受け付ける。そして、ウェブサービス１０１は、エンジン制御部１１５に配信開始を指示する。エンジン制御部１１５は、配信先ユーザが利用しているエンジンサーバ２００を特定し、特定したエンジンサーバ２００に対して、配信元ユーザが利用しているエンジンサーバ２００のエンジンサーバＵＲＬおよび配信ＩＤを指定して、配信開始要求を送信する。

配信先ユーザが利用しているエンジンサーバ２００では、対管理サーバウェブサービス２０１が、管理サーバ１００のエンジン制御部１１５からの要求に従って、配信先ユーザが使用する端末５００に対して、配信元ユーザが利用しているエンジンサーバ２００のエンジンサーバＵＲＬおよび配信ＩＤを指定して、配信開始要求を送信する。

配信先ユーザが使用する端末５００では、独自転送プロトコル対応クライアント５２０が配信開始要求を受け付ける。このとき、配信先ユーザが使用する端末５００がクライアント端末３００である場合は、配信元ユーザに対して配信開始確認を行い、配信可能か不可能かの応答を取得する。

配信先ユーザが使用する端末５００が配信可能の端末５００である場合は、配信元ユーザが利用しているエンジンサーバ２００のクラウドブラウザ２０４でレンダリングされ、映像音声エンコーダ２１１でエンコードされた圧縮映像が、独自転送プロトコルによる受信処理により、独自転送プロトコル対応サーバ２１５から配信先ユーザが使用する端末５００の独自転送プロトコル対応クライアント５２０に送信される。そして、配信先ユーザが使用する端末５００において、圧縮映像がデコードされて映像が再生される。管理サーバ１００のエンジン制御部１１５が配信開始の指示を受けた後の処理は、すべての配信先ユーザまたは配信先となる端末５００の数だけ繰り返される。

その後、既に開始している配信に対して配信先を追加する場合は、配信元ユーザが、端末５００を用いた操作により、管理サーバ１００に対して配信先に追加したいユーザまたは端末５００を指定して配信開始を指示する。管理サーバ１００では、ウェブサービス１０１がこの配信開始の指示を受け付けて、エンジン制御部１１５に渡す。以降、配信先を指定せずに配信開始した場合と同様の処理が行われる。

＜回線適応制御処理＞
次に、回線適応制御処理について説明する。独自転送プロトコルによる受信処理を行っている際に、端末５００においてＲＴＰデータの受信状況が悪化すると、映像をスムーズに再生できない懸念がある。その場合は、上述した再生遅延時間を延ばしたり、エンジンサーバ２００の映像音声エンコーダ２１１が映像データをエンコードする際のビットレートを落としたりすることで、スムーズな再生を可能にする。このため、端末５００での映像データの受信状況を一定間隔（初期パラメータで設定）ごとにエンジンサーバ２００に伝え、回線適応制御処理により適切なエンコードパラメータや再生遅延時間の調整を行う。

エンコードパラメータは、ビットレート、フレームレートなどの各パラメータを個別に変更するのではなく、それらを複数のセットにしてランク付けする。それを品質判定テーブルとして、端末５００がＲＴＰデータの受信に利用する回線の品質にあわせて、ランクを選択する。

また、独自転送プロトコルによる送信処理においても、受信処理と同様に、回線の品質に応じてエンコーダパラメータを調整し、リアルタイム性が損なわれないようにすることが望まれる。そこで、エンジンサーバ２００側で端末５００から送られてくるデータの受信状況を取得し、回線の品質に応じた適切なビットレート、フレームレートを算出して、エンコーダパラメータを調整する。

なお、回線の品質判定により得られたエンコードパラメータや再生遅延時間が現在のものと異なるとき、品質判定の結果に変化があるたびにエンコードパラメータや再生遅延時間を変更していると、評価対象の値が閾値付近にある場合に再生品質が目まぐるしく変化してしまい、スムーズな再生の妨げとなる。そこで、回線の品質が上がる場合と下がる場合とで異なる閾値を持つことで、これを回避することが望ましい。

＜マルチプロジェクション＞
本実施形態の映像音声処理システムでは、複数のプロジェクタ４００Ａを用いてマルチプロジェクションを行うことができる。マルチプロジェクションを行う際は、映像を表示するプロジェクタ４００Ａごとに専用の映像音声エンコーダ２１１を起動して、それぞれ個別の映像を配信する。マルチプロジェクションを行う前には、キャリブレーションを実施して、使用するプロジェクタ４００Ａの配置等に応じた映像の歪みを画像処理によって補正する。補正に用いる補正データは、例えば、映像の配信前に特定の校正パターンをプロジェクタ４００Ａで表示させてそれをカメラユニット４００Ｃで撮影し、その画像をエンジンサーバ２００で分析することで算出される。

マルチプロジェクションにより映像を結合して再生させるためには、映像再生のタイミングを複数のプロジェクタ４００Ａの間で同期させる必要がある。同期の方法としては、例えば以下の方法が考えられる。まず、ＲＴＰパケットのヘッダにエンジンサーバ２００でブラウザ画像のサンプリングを開始した時刻（サンプリング時刻）をタイムスタンプとして設定する。そして、複数のプロジェクタ４００Ａの間で、タイムスタンプからの再生遅延時間を同じにする。各プロジェクタ４００Ａは、そのタイムスタンプと内部クロック、および再生遅延時間に基づいて再生時間を決める。タイムスタンプは、エンジンサーバ２００の内部クロックを基準とするが、その基準時間と、各プロジェクタ４００Ａの内部クロックはずれていることが考えられる。そこで、プロジェクタ４００Ａごとに、エンジンサーバ２００との間の時刻差を求めておき、再生時間の補正に使用する。

＜端末状態管理処理＞
次に、端末状態管理処理について説明する。端末状態管理処理では、端末５００が定期的に管理サーバ１００へ自身の状態（切断、待機中、使用中などのステータス）をポーリングすることで、端末５００の状態を管理する。端末５００は、起動直後から一定時間（ポーリング間隔）ごとに自身の状態の通知を行い、状態が変化したときは、ポーリング間隔を無視して直ちに状態変更通知を行う。図１７は、端末状態管理処理の具体例を示すシーケンス図である。

端末５００の状態が変化すると、状態制御部５２８が、定期通信部５２９に状態変更通知を指示する。定期通信部５２９は、次回の定期通信時までに端末５００の状態に変更がない場合は同じ状態を送り続けることになるため、端末５００の現在の状態を保持する。そして、定期通信部５２９は、管理サーバ通信部５３１を介して、管理サーバ１００のウェブサービス１０１に対してデバイスＩＤと端末５００の状態を送る。

ウェブサービス１０１は、端末５００から受信したデバイスＩＤと端末５００の状態を端末状態管理部１１７に渡して、端末５００の状態の更新を要求する。端末状態管理部１１７は、この要求に応じて、ＤＢアクセサ１１３を介してシステムストレージサーバ６００Ａにアクセスし、ウェブサービス１０１から受け取ったデバイスＩＤをキーとして、システムストレージサーバ６００Ａが保持する端末５００の状態を更新する。端末５００の定期通信部５２９が端末５００の状態を保持した後の処理は、ポーリング間隔ごとに繰り返し行われる。

上記の処理とは別に、端末状態管理部１１７は、切断状態ではない端末５００の定期通信を監視し、定期通信が一定時間（初期パラメータで設定）が行われていない端末５００を検知して、システムストレージサーバ６００Ａが保持する端末５００の状態を切断状態に更新するとともに、その端末５００に対する配信の終了を指示する。端末５００に対する配信の終了は、ユーザセッション終了処理により行われる。

＜エンジンサーバ負荷判定処理＞
次に、エンジンサーバ負荷判定処理について説明する。エンジンサーバ負荷判定処理では、エンジンサーバ２００の負荷状態を管理サーバ１００に定期的に通知する。管理サーバ１００のエンジン制御部１１５は、上述したエンジン準備処理において、エンジンサーバ２００から通知された負荷状態をもとに、負荷の低いエンジンサーバ２００の選定を行う。図１８は、エンジンサーバ負荷判定処理の具体例を示すシーケンス図である。

まず、エンジンサーバ２００のエンジン負荷状況報告部２１７が、エンジンサーバ２００の負荷状態を計測し、得られた負荷状態を、管理サーバ送信部２０２を介して管理サーバ１００に送信する。エンジンサーバ２００の負荷状態としては、例えば、前回の負荷状態の送信時からの平均ＣＰＵ負荷率、平均メモリ使用率、平均ネットワーク帯域負荷率、および端末接続数などが挙げられる。

管理サーバ１００のエンジン用ウェブインターフェース１０２は、エンジンサーバ２００から負荷状態を受け取ると、エンジン制御部１１５に対して、エンジンサーバＩＤと負荷状態を渡し、システムストレージサーバ６００Ａに保存されている負荷情報の更新を指示する（「取得部」に相当）。

エンジン制御部１１５は、ＤＢアクセサ１１３を介してシステムストレージサーバ６００Ａにアクセスし、エンジンサーバＩＤで特定されるエンジンサーバ２００の負荷情報を、エンジンサーバ２００で計測された負荷状態をもとに更新する。以上の処理は、初期パラメータで設定される一定時間ごとに繰り返し行われる。

エンジン制御部１１５は、エンジンサーバ２００の負荷情報をもとに、例えば以下の手順に従って、使用するエンジンサーバ２００の選定を行う。まず、平均メモリ使用率が初期パラメータで定められる一定量（例えば８５％）以上のエンジンサーバ２００を除外する。次に、平均ネットワーク帯域負荷率が初期パラメータで定められる一定量（例えば８５％）以上のエンジンサーバ２００を除外する。そして、残ったエンジンサーバ２００のうち、平均ＣＰＵ負荷率が初期パラメータで定められる一定量（例えば９０％）以下で最も低いものを、配信に使用するエンジンサーバ２００に選定する。なお、上記の条件を満たすエンジンサーバ２００が存在しない場合には、ユーザに対して映像音声処理システムが混み合っている旨のメッセージを通知するようにしてもよい。

＜ユーザセッション終了処理＞
次に、ユーザセッション終了処理について説明する。ユーザセッション終了処理は、端末５００が切断された場合に、管理サーバ１００が、端末５００の切断を検知してエンジンサーバ２００による映像（および音声）の配信を停止させる処理である。図１９は、ユーザセッション終了処理の具体例を示すシーケンス図である。

まず、端末状態管理処理により端末５００の切断が検知されると、管理サーバ１００の端末状態管理部１１７がエンジン制御部１１５に対して、配信終了を指示する。端末５００の切断は、端末５００から切断の状態更新が送信される、あるいは定期通信が一定時間行われていないことにより検知される。

エンジン制御部１１５は、ユーザＩＤまたはデバイスＩＤに基づいて配信情報を取得し、配信を行っているエンジンサーバ２００を特定する。そして、エンジン制御部１１５は、配信を行っているエンジンサーバ２００に対して配信終了を指示する。この際、エンジン制御部１１５からエンジンサーバ２００に対して配信ＩＤが渡される。

エンジンサーバ２００では、対管理サーバウェブサービス２０１が、管理サーバ１００のエンジン制御部１１５からの配信終了の指示を受け取って配信制御部２０３に渡す。配信制御部２０３は、配信終了の指示を受け取ると、配信ＩＤに基づいて配信情報を特定し、配信情報に基づいて停止する各プロセスを特定する。

そして、配信制御部２０３は、独自転送プロトコル対応サーバ２１５を停止する。次に、配信制御部２０３は、エンコーダブリッジ２０６を停止する。エンコーダブリッジ２０６は、映像音声エンコーダ２１１を停止する。

次に、配信制御部２０３は、クラウドブラウザ制御部２０５にブラウザ停止の指示を送る。クラウドブラウザ制御部２０５は、この指示に従って、クラウドブラウザ２０４とブラウザＦＩＦＯ２０７を停止する。そして、配信制御部２０３は、自身の持つ配信情報を削除する。

＜映像音声個別配信＞
本実施形態の映像音声処理システムでは、上述したように、エンジンサーバ２００のクラウドブラウザ２０４でレンダリングされたウェブコンテンツの映像と音声を、それぞれ別個の端末５００に配信し、別個の端末で同期をとりながらこれら映像と音声とを再生させることができる。以下、ハードウェアとして投影エンジン４０１を備えるプロジェクタ４００Ａ（「第１端末」に相当）でウェブコンテンツの映像を再生し、ハードウェアとしてスピーカ４０２を備えるスピーカユニット４００Ｂ（「第２端末」に相当）で音声を再生する例を挙げて、この処理の概要を説明する。

図２０は、ウェブコンテンツの映像をプロジェクタ４００Ａで再生し、音声をスピーカユニット４００Ｂで再生する場合の映像音声個別配信の概要を説明する概念図である。映像音声個別配信を行う場合、まず、ユーザがクライアント端末３００を操作して、映像の配信先と音声の配信先とを指定する（１）。また、ユーザは、映像の配信先となるプロジェクタ４００Ａと、音声の配信先となるスピーカユニット４００Ｂとをそれぞれ起動する。この操作により、プロジェクタ４００Ａおよびスピーカユニット４００Ｂのそれぞれで上述した端末起動処理が行われ、管理サーバ１００からプロジェクタ４００Ａとスピーカユニット４００Ｂの双方に対して、共通のエンジンサーバＵＲＬが通知される（２）。

プロジェクタ４００Ａとスピーカユニット４００Ｂは、それぞれ、管理サーバ１００から通知されたエンジンサーバＵＲＬにアクセスし、上述したセッション確立処理を行う。これにより、エンジンサーバ１００の独自転送プロトコル対応サーバ２１５とプロジェクタ４００Ａの独自転送プロトコル対応クライアント５２０、エンジンサーバ１００の独自転送プロトコル対応サーバ２１５とスピーカユニット４００Ｂの独自転送プロトコル対応クライアント５２０との間で、それぞれ、独自転送プロトコルによる受信処理が開始される。また、上述したセッション確立処理（時刻合わせ処理）により得られたエンジンサーバ１００との時刻差が、プロジェクタ４００Ａの再生制御部５２４と、スピーカユニット４００Ｂの再生制御部５２４とにそれぞれ設定される。

プロジェクタ４００Ａの独自転送プロトコル対応クライアント５２０は、独自転送プロトコルによる受信処理が開始されると、映像の配信要求であることを示す情報を入れたＨＴＴＰＳリクエストのヘッダを、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５に送る（３）。エンジンサーバ２００の独自転送プロトコル対応サーバ２１５は、このＨＴＴＰＳリクエストのヘッダに基づいて映像の配信要求であることを認識し、映像エンコーダ２１１ａによりエンコードされた圧縮映像のＲＴＰパケットを、レスポンスのＢｏｄｙ部に書き込んでプロジェクタ４００Ａに送信する（４）。このとき、独自転送プロトコル対応サーバ２１５は、ＲＴＰパケットのヘッダに、当該ＲＴＰパケットに含まれるＲＴＰデータ（ブラウザ画像）のサンプリング時刻をタイムスタンプ（時刻情報）として書き込む。なお、ブラウザ画像のサンプリング時刻は、例えば、クラウドブラウザ２０４がブラウザ画像の最初の走査線の描画を開始する時刻である。

また、スピーカユニット４００Ｂの独自転送プロトコル対応クライアント５２０は、独自転送プロトコルによる受信処理が開始されると、音声の配信要求であることを示す情報を入れたＨＴＴＰＳリクエストのヘッダを、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５に送る（３）。エンジンサーバ２００の独自転送プロトコル対応サーバ２１５は、このＨＴＴＰＳリクエストのヘッダに基づいて音声の配信要求であることを認識し、音声エンコーダ２１１ｂによりエンコードされた圧縮音声のＲＴＰパケットを、レスポンスのＢｏｄｙ部に書き込んでスピーカユニット４００Ｂに送信する（４）。このとき、独自転送プロトコル対応サーバ２１５は、ＲＴＰパケットのヘッダに、当該ＲＴＰパケットに含まれるＲＴＰデータ（音声）のサンプリング時刻をタイムスタンプ（時刻情報）として書き込む。なお、音声のサンプリング時刻は、例えば、クラウドブラウザ２０４が１フレーム分の音声データの最初のサンプルをキャプチャした時刻である。

同一のウェブコンテンツの映像と音声をプロジェクタ４００Ａとスピーカユニット４００Ｂとで個別に再生させる場合、同じタイミングでサンプリングされた映像（ブラウザ画像）と音声を、プロジェクタ４００Ａとスピーカユニット４００Ｂとで同期させながら再生する必要がある。このような再生同期は、プロジェクタ４００Ａの再生制御部５２４とスピーカユニット４００Ｂの再生制御部５２とが、それぞれ、共通の再生遅延時間に基づいてＲＴＰデータのバッファリング時間を調整し、同じタイミングでサンプリングされた映像（ブラウザ画像）と音声について、プロジェクタ４００Ａの投影エンジン４０１が映像の再生を開始する再生開始時刻と、スピーカユニット４００Ｂのスピーカ４０２が音声の再生を開始する再生開始時刻を合わせることで実現することができる。

図２１は、再生遅延時間を説明する概念図であり、（ａ）は映像（ブラウザ画像）のサンプリングから再生開始までに要する時間、（ｂ）は音声のサンプリングから再生開始までに要する時間をそれぞれ示している。

映像は、エンジンサーバ２００でのサンプル取得とエンコードに要する時間がＡ１、エンジンサーバ２００からプロジェクタ４００Ａへの伝送時間がＢ１、プロジェクタ４００Ａでデコードに要する時間がＤ１であるとする。一方、音声は、エンジンサーバ２００でのサンプル取得とエンコードに要する時間がＡ２、エンジンサーバ２００からスピーカユニット４００Ｂへの伝送時間がＢ２、スピーカユニット４００Ｂでデコードに要する時間がＤ２であるとする。

図２１の例では、Ａ１とＢ１とＤ１を足し合わせた時間が、Ａ２とＢ２とＤ２を足し合わせた時間よりも長くなっており、プロジェクタ４００Ａとスピーカユニット４００Ｂが、受信したＲＴＰデータをすぐにデコードして再生すると、映像と音声の同期がとれなくなる。そこで、エンジンサーバ２００が、映像や音声を送信する回線の品質などに応じて、サンプリング時刻から再生開始時刻までの時間である再生遅延時間を決定する。そして、プロジェクタ４００Ａの再生制御部５２４と、スピーカユニット４００Ｂの再生制御部５２４は、エンジンサーバ２００が決定した共通の再生遅延時間に基づいて、バッファリング時間Ｃ１，Ｃ２を調整し、同じ時刻にサンプリングされた映像（ブラウザ画像）と音声の再生開始時刻を合わせることで、映像と音声の再生を同期させる。図２１の例では、音声のＲＴＰデータをバッファリングするバッファリング時間Ｃ２を、映像のＲＴＰデータをバッファリングするバッファリング時間Ｃ１よりも長くすることで、映像と音声の再生を同期させる。

再生遅延時間は、エンジンサーバ２００が上述した回線適応制御処理を行うことで決定され、プロジェクタ４００Ａとスピーカユニット４００Ｂとに通知される。そして、プロジェクタ４００Ａの再生制御部５２４と、スピーカユニット４００Ｂの再生制御部５２４とに、同じ再生遅延時間が設定される。プロジェクタ４００Ａの再生制御部５２４と、スピーカユニット４００Ｂの再生制御部５２４は、それぞれ、独自転送プロトコル対応クライアント５２０が受信したＲＴＰパケットのヘッダに書き込まれたサンプリング時刻と、時刻合わせ処理により得られたエンジンサーバ２００との間の時刻差と、上述した再生遅延時間とに基づいてバッファリング時間Ｃ１，Ｃ２を決定する。これにより、同じ時刻にサンプリングされた映像（ブラウザ画像）と音声の再生が同じ時刻に開始されることになり、同一のウェブコンテンツの映像と音声とを同期させながら再生することができる。

＜矩形検出によるフレーム差分軽量化方式＞
つぎに、本実施形態にかかる映像音声エンコーダ２１１の動作について、図面を用いて詳細に説明する。

映像音声処理システムでは、エンジンサーバ２００の映像音声エンコーダ２１１（図４参照）が、クラウドブラウザ２０４の出力画像を静止画（以下、ブラウザ出力画像という）として取り出し、取り出したブラウザ出力画像を映像の１フレームとして圧縮する。このようにして生成された圧縮映像は、１枚のフレーム内で完結している先頭フレーム（以下、Ｉフレームという）と、時間的に前のフレームとの差分を記録する差分フレーム（以下、Ｐフレームという）との複数のフレームが時系列に沿って配列したデータ構造を有する。ここで、Ｐフレームは、前フレームとの差分について記述されたものであるため、静止画全体が記述されたものであるＩフレームよりもデータ量が小さい。そのため、エンコードに要するデータ処理量や時間、および、映像配信時のトラフィックを削減することができる。

クラウドブラウザ２０４は、現在のブラウザ出力画像のうち、直前のブラウザ出力画像から変更となった領域（以下、更新領域という）を検知することができる。たとえばクラウドブラウザ２０４は、表示するウェブコンテンツにおける変更部分を特定してその部分をレンダリングし、これにより得られた部分的な画像で元のブラウザ出力画像を更新することで、つぎに表示するブラウザ出力画像を生成する。その際、クラウドブラウザ２０４は、レンダリングに使用した座標を用いることで、前のブラウザ出力画像から更新された更新領域を特定することができる。

映像音声エンコーダ２１１は、クラウドブラウザ２０４から更新領域に関する情報（以下、ブラウザ更新情報という）を取得し、この更新領域の部分について差分を検出してＰフレームを生成する。

図２２は、本実施形態にかかるブラウザ出力画像と更新領域との一例を示す図である。図２２に示すように、クラウドブラウザ２０４は、ウェブコンテンツ等をレンダリングすることで生成したブラウザ出力画像のうち、レンダリングに使用した座標を用いることで、前のブラウザ出力画像に対する更新領域Ｒ１１を特定し、この更新領域Ｒ１１を特定するためのブラウザ更新情報を生成する。更新領域Ｒ１１は、たとえばレンダリングに使用された座標のうち、最小のＸ座標（Ｘｍｉｎ）および最大のＸ座標（Ｘｍａｘ）と、最小のＹ座標（Ｙｍｉｎ）および最大のＹ座標（Ｙｍａｘ）とで規定される矩形状の領域であってもよい。その場合、ブラウザ更新情報には、たとえば基準座標（たとえば更新領域Ｒ１１の左上の座標（Ｘｍｉｎ，Ｙｍｉｎ））と、縦横のサイズ（Ｘｍａｘ−Ｘｍｉｎ，Ｙｍａｘ−Ｙｍｉｎ）との情報が含まれる。ただし、これに限定されず、ブラウザ出力画像中の更新領域Ｒ１１を特定し得る情報であれば如何様にも変形することができる。

図２３は、本実施形態にかかる映像音声エンコーダの概略機能構成例を示すブロック図である。図２３に示すように、映像音声エンコーダ２１１は、更新領域特定部２１１１と、フレーム生成部２１１２と、フレーム出力部２１１３とを備える。

映像音声エンコーダ２１１は、クラウドブラウザ２０４がレンダリング等で生成したブラウザ出力画像を取得する。その際、ブラウザ出力画像にブラウザ更新情報が付加されている場合には、このブラウザ更新情報も合わせて取得する。ブラウザ出力画像がＰフレーム生成用の画像である場合、ブラウザ出力画像には、ブラウザ更新情報が付加されている。一方、ブラウザ出力画像がＩフレーム生成用の画像である場合、ブラウザ出力画像には、ブラウザ更新情報が付加されていなくともよいし、ブラウザ出力画像がＩフレーム生成用の画像であることを示す情報、全領域が更新領域Ｒ１１であることを示す情報などを含むブラウザ更新情報が付加されていてもよい。

更新領域特定部２１１１は、クラウドブラウザ２０４からブラウザ更新情報を取得し、これに基づいてブラウザ出力画像の更新領域Ｒ１１を特定する。ただし、ブラウザ出力画像にブラウザ更新情報が付加されていない場合、または、Ｉフレーム生成用の画像であることを示す情報もしくは全領域が更新領域Ｒ１１であることを示す情報を含むブラウザ更新情報を取得した場合、更新領域特定部２１１１は、ブラウザ出力画像をＩフレーム生成用の画像として特定する。

フレーム生成部２１１２は、ブラウザ出力画像がＩフレーム生成用の画像である場合、最新のブラウザ出力画像のＩフレームを生成する。一方、ブラウザ出力画像がＰフレーム生成用の画像である場合、フレーム生成部２１１２は、ブラウザ更新情報に基づき、時間的に前のブラウザ出力画像と最新のブラウザ出力画像とから更新領域Ｒ１１についての差分を検出してＰフレームを生成する。生成されたＩフレームまたはＰフレームは、フレーム出力部２１１３から独自転送プロトコル対応サーバ２１５へ出力され、独自転送プロトコル対応サーバ２１５から端末５００へ配信される。

つぎに、映像音声エンコーダ２１１の動作を、図面を用いて詳細に説明する。図２４は、本実施形態にかかる映像音声エンコーダの動作例を示すフローチャートである。図２４に示すように、映像音声エンコーダ２１１は、たとえば毎秒３０フレームの更新サイクルであるとすると、その１つの更新サイクル（１／３０秒）が経過したか否かを判定し（ステップＳ１０１）、１つの更新サイクルが経過した場合（ステップＳ１０１；ＹＥＳ）、クラウドブラウザ２０４から最新のブラウザ出力画像を取得する（ステップＳ１０２）。その際、映像音声エンコーダ２１１は、ブラウザ出力画像にブラウザ更新情報が付加されていれば、そのブラウザ更新情報も取得する。

つぎに、映像音声エンコーダ２１１は、ブラウザ更新情報の有無またはブラウザ更新情報に含まれる情報に基づいて、最新のブラウザ出力画像がＩフレーム生成用の画像であるか否かを判定する（ステップＳ１０３）。Ｉフレーム生成用の画像である場合（ステップＳ１０３；ＹＥＳ）、映像音声エンコーダ２１１は、最新のブラウザ出力画像全体をスキャンして（ステップＳ１０４）、Ｉフレームを生成し（ステップＳ１０５）、生成したＩフレームを独自転送プロトコル対応サーバ２１５へ出力して（ステップＳ１０６）、ステップＳ１１２へ進む。

一方、ブラウザ出力画像がＩフレーム生成用の画像ではない場合（ステップＳ１０２；ＮＯ）、映像音声エンコーダ２１１は、ブラウザ更新情報から最新のブラウザ出力画像における更新領域を特定し（ステップＳ１０７）、特定した更新領域をスキャンして（ステップＳ１０８）、直前のブラウザ出力画像との差分を検出し（ステップＳ１０９）、検出した差分に基づいてＰフレームを生成する（ステップＳ１１０）。つぎに、映像音声エンコーダ２１１は、生成したＰフレームを独自転送プロトコル対応サーバ２１５へ出力して（ステップＳ１１１）、ステップＳ１１２へ進む。

ステップＳ１１２では、映像音声エンコーダ２１１は、本動作を終了するか否かを判定し、終了する場合（ステップＳ１１２；ＹＥＳ）、本動作を終了し、終了しない場合（ステップＳ１１２；ＮＯ）、ステップＳ１０１へリターンして以降の動作を実行する。

つぎに、図２５〜図２７を用いて、図２４に示した動作を具体的に説明する。図２５は、最新のブラウザ出力画像がＩフレーム生成用の画像である場合を説明するための模式図であり、図２６は、最新のブラウザ出力画像がＩフレーム生成用の画像の次のＰフレーム生成用の画像である場合を説明するための模式図であり、図２７は、最新のブラウザ出力画像がＰフレーム生成用の画像のさらに次のＰフレーム生成用の画像である場合を説明するための模式図である。なお、ここでは、説明の明確化のため、図２５に示すブラウザ出力画像を先頭（１番目）のブラウザ出力画像とし、図２６に示すブラウザ出力画像を２番目のブラウザ出力画像とし、図２７に示すブラウザ出力画像を３番目以降のブラウザ出力画像とする。

図２５に示すように、最新のブラウザ出力画像が先頭のブラウザ出力画像である場合、映像音声エンコーダ２１１は、ブラウザ出力画像全体をスキャンして（Ｓ１１）、Ｉフレームを生成し（Ｓ１２）、生成したＩフレームを独自転送プロトコル対応サーバ２１５へ出力する（Ｓ１３）。

また、図２６に示すように、最新のブラウザ出力画像が先頭から２番目のブラウザ出力画像であってＰフレーム生成用の画像である場合、映像音声エンコーダ２１１は、ブラウザ出力画像におけるブラウザ更新情報で特定される更新領域Ｒ１１をスキャンして（Ｓ２１）、更新領域Ｒ１１における先頭のブラウザ出力画像との差分を検出する（Ｓ２２）。また、映像音声エンコーダ２１１は、検出した差分に基づいて、更新領域Ｒ１１のＰフレームを生成し（Ｓ２３）、生成したＰフレームを独自転送プロトコル対応サーバ２１５へ出力する（２４）。

また、図２７に示すように、最新のブラウザ出力画像が先頭から３番目以降のブラウザ出力画像であってＰフレーム生成用の画像である場合、映像音声エンコーダ２１１は、ブラウザ出力画像におけるブラウザ更新情報で特定される更新領域Ｒ１１をスキャンして（Ｓ３１）、更新領域Ｒ１１における時間的に前のブラウザ出力画像との差分を検出する（Ｓ３２）。また、映像音声エンコーダ２１１は、検出した差分に基づいて、更新領域Ｒ１１のＰフレームを生成し（Ｓ３３）、生成したＰフレームを独自転送プロトコル対応サーバ２１５へ出力する（３４）。

以上のように動作することで、ブラウザ出力画像に更新がある場合に、画像の全領域では無く、更新が含まれる領域を処理対象とすることが可能となるため、映像音声エンコーダ２１１にかかる負荷を軽減することができる。また、更新領域のＰフレームは、ブラウザ出力画像全体のＰフレームに比べてデータ量が小さいため、ネットワークへ送信するデータ量を削減することも可能となる。その結果、端末５００側の負荷を低減させつつ、リッチなウェブコンテンツをブラウジングさせることが可能となる。

＜矩形検出によるフレーム差分軽量化方式の変形例＞
また、上記では、レンダリングに使用した座標を用い、その最小のＸ座標（Ｘｍｉｎ）および最大のＸ座標（Ｘｍａｘ）と、最小のＹ座標（Ｙｍｉｎ）および最大のＹ座標（Ｙｍａｘ）とで規定される矩形状の領域を更新領域Ｒ１１としたが、本実施形態はこれに限定されない。たとえば、クラウドブラウザ２０４の表示領域をメッシュ状に分割して管理し、その区画（以下、メッシュという）単位で更新の有無を特定してもよい。

図２８は、本変形例にかかるブラウザ出力画像と更新領域との一例を示す図である。図２８に示すように、クラウドブラウザ２０４は、表示領域を２次元配列する複数のメッシュＭ１１に分割して管理する。なお、図２８において、表示領域とブラウザ出力画像とは、同じサイズである。

クラウドブラウザ２０４は、更新領域Ｒ１１を少なくとも一部に含む１つ以上のメッシュＭ１１を特定し、このメッシュ単位で更新領域Ｒ２１を特定する。メッシュ単位での更新領域Ｒ２１の特定は、たとえばウェブコンテンツ等のレンダリングに使用した座標と、各メッシュＭ１１の座標領域とから、レンダリングに使用した座標を含むメッシュＭ１１を特定し、特定されたメッシュＭ１１をまとめて更新領域Ｒ２１として特定するなどの処理が考えられる。ただし、これに限定されず、更新領域Ｒ１１を包含する更新領域Ｒ２１を特定し得る方法であれば如何様にも変形することができる。

なお、本変形例にかかる映像音声エンコーダおよびその動作は、たとえば図２３に示す映像音声エンコーダ２１１および図２４に示す動作と同様であるため、ここでは詳細な説明を省略する。

＜スキップフレーム＞
また、通常の映像エンコードでは、たとえば表示の更新サイクルを３０ｆｐｓとすると、毎秒３０フレーム分のエンコード処理が必要となる。しかしながら、ブラウザの更新がない期間は、クラウドブラウザ２０４は同じ静止画を表示し続けている。その場合、エンコード処理を省略することができる。そこで本実施形態では、クラウドブラウザ２０４のブラウザ更新情報を参照し、一定期間ブラウザの更新がなければ、クラウドブラウザ２０４が静止画を表示していると判断して、エンコード処理を省略するとともに、Ｐフレームの代わりに更新情報のないＰフレーム（以下、スキップフレームという）を端末５００へ配信する。

図２９は、スキップフレームを利用しない場合の映像配信の流れを示す概念図である。図３０は、スキップフレームを利用した場合の映像配信の流れを示す概念図である。なお、図２９および図３０では、説明の都合上、先頭フレームをＩフレームとする。

図２９に示すように、スキップフレームを利用しない通常の映像配信では、映像音声エンコーダ２１１は、最初にＩフレームＦ１を生成して送信後、次のＩフレームを生成するまで、ＰフレームＦ２を生成して送信する。その際、期間Ｔｎの間、ユーザによるタッチイベントなどに起因したクラウドブラウザ２０４の更新がなかったとすると、その期間Ｔｎ、映像音声エンコーダ２１１は、実質的に更新情報を含まないＰフレームＦ２ａを生成して送信することとなる。ただし、この期間Ｔｎ中も、映像音声エンコーダ２１１は、ＰフレームＦ２ａを生成するエンコード処理を実行することとなる。

一方、図３０に示すように、スキップフレームを利用した場合の本実施形態にかかる映像配信では、クラウドブラウザ２０４の更新のない期間Ｔｎが開始されてから所定時間Ｔｗ経過後、クラウドブラウザ２０４の更新が発生するタイミングｔ１まで、映像音声エンコーダ２１１は、エンコード処理を実行せずに、代わりにスキップフレームＦ２ｓを生成して送信する。このスキップフレームＦ２ｓは、更新情報を含まない定型のデータ構造でよいため、映像音声エンコーダ２１１にかかる負荷を低減することができるとともに、短いデータ構造とすることが可能であるため、端末５００へ配信するデータ量を最小限に抑えることができる。

つぎに、スキップフレームを利用する映像音声エンコーダ２１１の動作について、図面を用いて詳細に説明する。図３１は、スキップフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。なお、図３１において、図２４と同様の動作については、それを引用することで、詳細な説明を省略する。

図３１に示すように、映像音声エンコーダ２１１は、起動後、まず、不図示のタイマによる計時を開始する（ステップＳ２０１）。つぎに、図２４のステップＳ１０１〜Ｓ１０３と同様の動作により、更新サイクルごとにブラウザ出力画像（およびブラウザ更新情報）を取得し、これがＩフレーム生成用の画像であるか否かを判定する。なお、更新サイクルの計時には、ステップＳ２０１で開始したタイマとは別の不図示のタイマが用いられてもよい。

ブラウザ出力画像がＩフレーム生成用の画像である場合（ステップＳ１０３；ＹＥＳ）、映像音声エンコーダ２１１は、図２４のステップＳ１０４〜Ｓ１０６と同様の動作により、Ｉフレームを生成して送信し、その後、ステップＳ２０５へ進む。

ブラウザ出力画像がＩフレーム生成用の画像ではない場合（ステップＳ１０３；ＮＯ）、映像音声エンコーダ２１１は、ブラウザ更新情報に基づいてクラウドブラウザ２０４に更新があるか否かを判定し（ステップＳ２０２）、更新がある場合（ステップＳ２０２；ＹＥＳ）、図２４のステップＳ１０７〜Ｓ１１１と同様の動作により、更新領域についてのＰフレームを生成して出力し、その後、ステップＳ２０５へ進む。

クラウドブラウザ２０４に更新がない場合（ステップＳ２０２；ＮＯ）、映像音声エンコーダ２１１は、タイマにより計時された経過時間が所定時間Ｔｎに達したか否かを判定し（ステップＳ２０３）、所定時間Ｔｎに達していない場合（ステップＳ２０３；ＮＯ）、図２４のステップＳ１０７〜Ｓ１１１と同様の動作により、更新領域についてのＰフレームを生成して出力し、その後、ステップＳ２０５へ進む。

一方、タイマにより計時された経過時間が所定時間Ｔｎに達している場合（ステップＳ２０３；ＹＥＳ）、映像音声エンコーダ２１１は、Ｐフレームの代わりにスキップフレームを出力し（ステップＳ２０４）、ステップＳ１０１へリターンする。なお、スキップフレームは、たとえば図２３に示すフレーム出力部２１１３が不図示のメモリから読み出して出力してもよい。また、スキップフレームを受信した端末５００は、ディスプレイ３０３の表示を更新しないように動作してよい。

また、ステップＳ２０５では、映像音声エンコーダ２１１は、タイマをリセットする。リセットされたタイマは、その後、初期値からカウントを再開する。

以上のように、スキップフレームを利用することで、映像音声エンコーダ２１１にかかる負荷を低減することができるとともに、端末５００へ配信するデータ量を最小限に抑えることが可能となる。

＜強制Ｉフレーム＞
また、ブラウザの更新が一定期間以上なく、クラウドブラウザ２０４が同じ静止画を表示し続けている場合には、一度、Ｉフレーム（以下、強制Ｉフレームという）を配信することで、端末５００側に表示される映像の品質を向上させてもよい。その際、映像音声エンコーダ２１１が生成する強制Ｉフレームの解像度を通常のＩフレームおよびＰフレームよりも上げることで、より高画質の画像を端末５００に表示させるようにしてもよい。

図３２は、強制Ｉフレームを利用した場合の映像配信の流れを示す概念図である。なお、図３２では、説明の都合上、先頭フレームをＩフレームとする。また、強制Ｉフレームを利用しない場合の映像配信の流れは、図２９または図３０と同様である。

図３２に示すように、強制Ｉフレームを利用した映像配信では、映像音声エンコーダ２１１は、最初にＩフレームＦ１を生成して送信後、次のＩフレームを生成するまでの間にユーザによるタッチイベントなどに起因したクラウドブラウザ２０４の更新がない期間Ｔｎが開始されると、期間Ｔｎの開始から所定時間Ｔｗ経過後、エンコード処理を実行して強制ＩフレームＦ１ｆを生成して送信する。この強制ＩフレームＦ１ｆは、通常のＩフレームおよびＰフレームよりも高い解像度であってもよい。これにより、端末５００に静止画として表示されるブラウザ画面の品質を向上することが可能となる。

つぎに、強制Ｉフレームを利用する映像音声エンコーダ２１１の動作について、図面を用いて詳細に説明する。図３３は、強制Ｉフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。なお、図３３において、図２４または図３１と同様の動作については、それを引用することで、詳細な説明を省略する。

図３３に示すように、映像音声エンコーダ２１１は、起動後、図３１のステップＳ２０１、Ｓ１０１〜１０３と同様に、タイマによる計時を開始するとともに、更新サイクルごとにブラウザ出力画像（およびブラウザ更新情報）を取得し、これがＩフレーム生成用の画像であるか否かを判定する。ブラウザ出力画像がＩフレーム生成用の画像である場合（ステップＳ１０３；ＹＥＳ）、映像音声エンコーダ２１１は、図３１のステップＳ１０４〜Ｓ１０６と同様の動作により、Ｉフレームを生成して送信し、その後、ステップＳ２０５へ進む。

ブラウザ出力画像がＩフレーム生成用の画像ではない場合（ステップＳ１０３；ＮＯ）、映像音声エンコーダ２１１は、図３１のステップＳ２０２と同様の動作により、ブラウザ更新情報に基づいてクラウドブラウザ２０４に更新があるか否かを判定し、更新がある場合（ステップＳ２０２；ＹＥＳ）、図３１のステップＳ１０７〜Ｓ１１１と同様の動作により、更新領域についてのＰフレームを生成して出力し、その後、ステップＳ２０５へ進む。

クラウドブラウザ２０４に更新がない場合（ステップＳ２０２；ＮＯ）、映像音声エンコーダ２１１は、図３１のステップＳ２０３に示す動作と同様の動作により、タイマにより計時された経過時間が所定時間Ｔｎに達したか否かを判定し、所定時間Ｔｎに達していない場合（ステップＳ２０３；ＮＯ）、図３１のステップＳ１０７〜Ｓ１１１と同様の動作により、更新領域についてのＰフレームを生成して出力し、その後、ステップＳ２０５へ進む。

一方、タイマにより計時された経過時間が所定時間Ｔｎに達している場合（ステップＳ２０３；ＹＥＳ）、映像音声エンコーダ２１１は、ステップＳ１０２で取得した最新のブラウザ出力画像全体をスキャンして（ステップＳ３０１）、強制Ｉフレームを生成し（ステップＳ３０２）、生成した強制Ｉフレームを独自転送プロトコル対応サーバ２１５へ出力する（ステップＳ３０３）。その際、映像音声エンコーダ２１１は、通常のＩフレームおよびＰフレームよりも高い解像度で、強制Ｉフレームを生成してもよい。

その後、映像音声エンコーダ２１１は、タイマをリセットし（ステップＳ３０４）、ステップＳ１０１へリターンする。なお、リセットされたタイマは、その後、初期値からカウントを開始する。

以上のように、強制Ｉフレームを利用することで、端末５００側に表示される映像の品質を向上させることができる。また、映像音声エンコーダ２１１が生成する強制Ｉフレームの解像度を通常のＩフレームおよびＰフレームよりも上げることで、より高画質の画像を端末５００に表示させることが可能となる。

＜スキップフレームおよび強制Ｉフレームの組み合わせ＞
また、上述したスキップフレームと強制Ｉフレームとを併用することも可能である。すなわち、ブラウザの更新が一定期間以上なく、クラウドブラウザ２０４が同じ静止画を表示し続けている場合には、一度、Ｉフレーム（以下、強制Ｉフレームという）を配信することで端末５００側に表示される映像の品質を向上させ、その後、クラウドブラウザ２０４の更新が発生するまで、スキップフレームを配信することで、映像音声エンコーダ２１１にかかる負荷を低減するとともに、端末５００へ配信するデータ量を最小限に抑えるように構成することも可能である。

図３４は、スキップフレームおよび強制Ｉフレームを利用した場合の映像配信の流れを示す概念図である。なお、図３４では、説明の都合上、先頭フレームをＩフレームとする。また、スキップフレームおよび／または強制Ｉフレームを利用しない場合の映像配信の流れは、図２９、図３０および図３２のいずれかと同様である。

図３４に示すように、スキップフレームおよび強制Ｉフレームを利用した映像配信では、映像音声エンコーダ２１１は、最初にＩフレームＦ１を生成して送信後、次のＩフレームを生成するまでの間にユーザによるタッチイベントなどに起因したクラウドブラウザ２０４の更新がない期間Ｔｎが開始されると、期間Ｔｎの開始から所定時間Ｔｗ経過後、エンコード処理を実行して強制ＩフレームＦ１ｆを生成して送信する。また、映像音声エンコーダ２１１は、強制Ｉフレームの送信以降、クラウドブラウザ２０４の更新が発生するタイミングｔ１まで、エンコード処理を実行せずに、代わりにスキップフレームＦ２ｓを生成して送信する。これにより、端末５００に静止画として表示されるブラウザ画面の品質を向上するとともに、映像音声エンコーダ２１１にかかる負荷の低減、および、端末５００へ配信するデータ量の最小化が可能となる。

つぎに、スキップフレームおよび強制Ｉフレームを利用する映像音声エンコーダ２１１の動作について、図面を用いて詳細に説明する。図３５は、スキップフレームおよび強制Ｉフレームを利用する映像音声エンコーダの動作例を示すフローチャートである。なお、図３５において、図２４、図３１または図３３と同様の動作については、それを引用することで、詳細な説明を省略する。

図３５に示すように、ステップＳ２０１、Ｓ１０１〜１０３、Ｓ２０２のＹＥＳ、Ｓ１０４〜Ｓ１１１、Ｓ２０５およびＳ１１２までの動作、ならびに、ステップＳ２０２のＮＯ、Ｓ２０３、Ｓ３０１〜Ｓ３０３までの動作は、図３３に示す動作と同様の動作である。

その後、図３５に示すように、ステップＳ３０３において強制Ｉフレームを出力すると、映像音声エンコーダ２１１は、１つの更新サイクルが経過したか否かを判定し（ステップＳ３０１）、１つの更新サイクルが経過した場合（ステップＳ４０１；ＹＥＳ）、クラウドブラウザ２０４から最新のブラウザ出力画像（およびブラウザ更新情報）を取得する（ステップＳ４０２）。つぎに、映像音声エンコーダ２１１は、ブラウザ更新情報に基づいてクラウドブラウザ２０４に更新があるか否かを判定し（ステップＳ４０３）、更新がある場合（ステップＳ４０３；ＹＥＳ）、図３３のステップＳ１０７〜Ｓ１１１と同様の動作により、更新領域についてのＰフレームを生成して出力し、その後、ステップＳ２０５へ進む。

一方、クラウドブラウザ２０４に更新がない場合（ステップＳ４０３；ＮＯ）、映像音声エンコーダ２１１は、Ｐフレームの代わりにスキップフレームを出力し（ステップＳ２０４）、ステップＳ４０１へリターンする。

以上のように、スキップフレームと強制Ｉフレームと併用することで、端末５００に静止画として表示されるブラウザ画面の品質を向上するとともに、映像音声エンコーダ２１１にかかる負荷の低減、および、端末５００へ配信するデータ量の最小化が可能となる。

＜実施形態の効果＞
以上、具体的な例を挙げながら詳細に説明したように、本実施形態の映像音声処理システムでは、ウェブコンテンツのリッチ化に対応させて常に最新化されるクラウドブラウザ２０４により、連携サイト４０や一般サイト５０が提供するウェブコンテンツがレンダリングされ、その結果が映像音声エンコーダ２１１により圧縮映像や圧縮音声の１フレームとして即時にエンコードされて、ＲＴＰデータとして端末５００に配信される。したがって、本実施形態の映像音声処理システムによれば、端末５００は、ＲＴＰデータを受信、デコードして再生する機能だけを備えていればよく、端末５００側をウェブコンテンツのリッチ化に対応させるための負荷を低減させつつ、リッチなウェブコンテンツを端末５００でブラウジングすることができる。

また、本実施形態の映像音声処理システムでは、ユーザの指定に従って、ウェブコンテンツから生成された圧縮映像のＲＴＰデータをプロジェクタ４００Ａ等の端末５００に配信するとともに、同一のウェブコンテンツから生成された圧縮音声のＲＴＰデータをスピーカユニット４００Ｂ等の端末５００に配信することができるので、映像と音声を別個の端末５００で再生することができる。

また、本実施形態の映像音声処理システムでは、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５が、映像を再生するプロジェクタ４００Ａ等の端末５００および音声を再生するスピーカユニット４００Ｂ等の端末５００の独自転送プロトコル対応クライアント５２０に対して、映像や音声のサンプリング時刻を示すタイムスタンプを付加したＲＴＰデータを配信するので、端末５００側でこのタイムスタンプを基準にＲＴＰデータのバッファリング時間を調整することで、プロジェクタ４００Ａ等の端末５００とスピーカユニット４００Ｂ等の端末５００とで、映像と音声とを同期させながら再生することができる。

また、本実施形態の映像音声処理システムによれば、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５が、一つのクラウドブラウザ２０４によりレンダリングされた同一のウェブコンテンツの映像や音声を複数の端末５００に同時に配信（マルチキャスト）することができるので、ブラウジングの内容を多拠点で共有することができる。

また、本実施形態の映像音声処理システムによれば、エンジンサーバ２００の独自転送プロトコル対応サーバ２１５が、端末５００との間の一つのセッションの間に、複数のＲＴＰデータをレスポンスのＢｏｄｙ部に動的に書き込むことで、圧縮映像や圧縮音声を端末５００に送信するので、クラウドブラウザ２０４によるウェブコンテンツのブラウジングの内容をリアルタイムに途切れることなく、端末５００に配信することができる。また、独自転送プロトコル対応サーバ２１５は、初期パラメータで設定された一定時間の間、端末５００との間のセッションを保持するので、映像や音声を効率よく端末５００に送信することができる。

なお、本実施形態の映像音声処理システムを構成する管理サーバ１００やエンジンサーバ２００は、ＣＰＵやＲＯＭ、ＲＡＭ、入出力インターフェースなどを備えた通常のコンピュータを利用したハードウェア構成を採用し、上述した各機能をソフトウェア（プログラム）として実装することができる。また、管理サーバ１００やエンジンサーバ２００の機能の少なくとも一部を、例えばＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ
Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などの専用のハードウェアを用いて実現することもできる。

また、本実施形態の映像音声処理システムでは、管理サーバ１００とエンジンサーバ２００とを互いに別個の装置として構成しているが、例えば、エンジンサーバ２００に管理サーバ１００の機能を持たせるなどにより、管理サーバ１００とエンジンサーバ２００とを一体の装置として構成するようにしてもよい。

１００ 管理サーバ
１０１ ウェブサービス
１０２ エンジン用ウェブインターフェース
１１５ エンジン制御部
２００ エンジンサーバ
２０４ クラウドブラウザ
２１１ 映像音声エンコーダ
２１５ 独自転送プロトコル対応サーバ
３００ クライアント端末
４００ デバイス
５００ 端末
５２０ 独自転送プロトコル対応クライアント
２００ エンジンサーバ
２０４ クラウドブラウザ
２１１ 映像音声エンコーダ
２１１１ 更新情報取得部
２１１２ フレーム生成部
２１１３ フレーム出力部

特開２００７−２２１２２９号公報

Claims (7)

1. コンテンツをレンダリングして出力画像を生成するブラウザを備えたサーバに組み込まれるエンコーダであって、
   前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成するフレーム生成部と、
   前記フレーム生成部が生成したフレームを出力するフレーム出力部と、
   前記ブラウザに更新が発生していない期間を計測するタイマと、
   を備え、
   前記フレーム生成部は、前記タイマによって計時された前記ブラウザに更新が発生していない期間が所定時間以上となった場合、第２先頭フレームを生成することを特徴とするエンコーダ。
2. 前記フレーム生成部は、前記第１先頭フレームよりも解像度が高い前記第２先頭フレームを生成することを特徴とする請求項１に記載のエンコーダ。
3. 前記フレーム出力部は、前記第２先頭フレームを出力後、前記ブラウザに更新が発生するまでの間、定型のスキップフレームを出力することを特徴とするエンコーダ。
4. １つ以上の端末にネットワークを介して接続された映像処理サーバであって、
   コンテンツをレンダリングして出力画像を生成するブラウザと、
   請求項１〜３のいずれか一つに記載のエンコーダと、
   前記フレーム出力部が出力した前記フレームを前記１つ以上の端末に前記ネットワークを介して配信する配信部と、
   を備えることを特徴とする映像処理サーバ。
5. ネットワークを介して１つ以上の端末とサーバとが接続された映像処理システムであって、
   前記サーバは、
   コンテンツをレンダリングして出力画像を生成するブラウザと、
   請求項１〜３のいずれか一つに記載のエンコーダと、
   前記前記フレーム出力部が出力した前記フレームを前記１つ以上の端末に前記ネットワークを介して配信する配信部と、
   を備え、
   各端末は、
   前記フレームをデコードするデコーダと、
   前記デコーダでデコードされた画像を表示する表示部と、
   を備えることを特徴とする映像処理システム。
6. コンテンツをレンダリングして出力画像を生成するブラウザを備えたクラウドサーバにおける配信画像のエンコード方法であって、
   前記ブラウザに更新が発生していない期間を計測し、
   前記ブラウザに更新が発生していない期間が所定時間未満である場合、前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成し、
   前記ブラウザに更新が発生していない期間が前記所定時間以上となった場合、第２先頭フレームを生成する
   ことを含むことを特徴とするエンコード方法。
7. ブラウザを備えたクラウドサーバに組み込まれたコンピュータを機能させるためのプログラムであって、
   前記ブラウザに更新が発生していない期間を計測する計時処理と、
   前記ブラウザに更新が発生していない期間が所定時間未満である場合、前記ブラウザで生成された出力画像の第１先頭フレームまたは前記出力画像よりも時間的に前の出力画像に対する差分フレームを生成し、前記ブラウザに更新が発生していない期間が前記所定時間以上となった場合、第２先頭フレームを生成するフレーム生成処理と、
   を前記コンピュータに実行させるためのプログラム。

Images