"ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとを備え、前記ストリームゲートウェイは、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断し、当該配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動し、これら再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成する一方、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送することを特徴とする映像配信プラットフォーム。請求項1に記載の映像配信プラットフォームにおいて、前記モジュールは、入力された複数のコンテンツを一つにまとめる映像合成処理を行うものであることを特徴とする映像配信プラットフォーム。請求項1に記載の映像配信プラットフォームにおいて、前記モジュールは、入力されたコンテンツを複数のブロックに分割してそのうちの少なくとも一つを出力する映像分割処理を行うものであることを特徴とする映像配信プラットフォーム。請求項1に記載の映像配信プラットフォームにおいて、前記モジュールは、入力されたコンテンツのフレームレートを変換する品質変換処理を行うものであることを特徴とする映像配信プラットフォーム。請求項1に記載の映像配信プラットフォームにおいて、前記モジュールは、入力されたコンテンツのパケットロスを前方誤り訂正や再送制御等によって補正するロス補正処理を行うものであることを特徴とする映像配信プラットフォーム。ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとによる映像配信方法であって、前記ストリームゲートウェイが、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断するステップと、前記ストリームゲートウェイが、前記配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動するステップと、前記ストリームゲートウェイが、前記再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成するステップと、前記ストリームゲートウェイが、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送するステップとを備えていることを特徴とする映像配信方法。映像配信プラットフォームは視聴者が要求するコンテンツや視聴形態を提供するものであるものの、Ustream等既存の映像配信プラットフォームの多くは定型的な形態で配信されることが多く、前述のようなコンテンツの加工等新たな機能追加が容易ではない。また、画面分割や符号化形式の変換等の加工機能をプラットフォームが提供する場合も、視聴者個々の要望にあわせて加工するため、視聴者の要望ごとに同様の加工処理を行う場合が多い。このように現在の映像配信プラットフォームではコンテンツに対する新規の加工要望に対して柔軟性がなく、コンテンツの再利用が難しいので、コンテンツの加工効率が悪い。今後の映像配信プラットフォームでは、映像品質、映像効果に関する視聴者からの多様な要求に対して、柔軟に対応できるプラットフォームであることが望まれる。配信コンテンツの加工がネットワーク上のユーザ側エッジに近いところでなされるほど、プラットフォーム上でのコンテンツ加工の効率やネットワークトラフィックの分散効率が悪くなる。言い換えると、加工後に共通に使えるコンテンツをネットワーク上に適切に配置することにより、エッジで個別加工する必要もなく、かつ、ネットワーク資源も共有に使える可能性が高くなる。そこで本発明は、コンテンツ配信に関する機能拡張を容易に行うことができ、また、コンテンツの加工効率に優れた映像配信プラットフォームを提供することを目的とする。本発明に係る映像配信プラットフォームでは、多様な加工要求を集中型で処理するのではなく、プラットフォーム内にコンテンツの加工変換を行うゲートウェイを分散設置し、個々のゲートウェイの加工状況を管理することで、加工後の出力ストリームをプラットフォームの共有資源として、複数の同一要求に対しても再利用できるようにする。また、ゲートウェイでは新たな加工要求機能実現が容易となるように、ゲートウェイの各機能をブロック化して構成する。これらを実現するために、ワンソースマルチユース、ビルディングブロック方式、および機能ブロック間連携管理の3つの要素技術を採用する。ワンソースマルチユースとは、一つの情報を多目的な利用用途へ用いることを示す。例えば、撮影した映像を映画またはDVD等に利用することが挙げられる。本明細書では、一つのストリームに対して様々な加工処理を行い複数のストリームへと変換し配信を行うことを指す。ビルディングブロック方式とは、システム構築を行う際、ハードウェア、OS等のように要素を分解させ必要な機能を選択させ積み木のように構築していくことを示す。本明細書では、図1のように一つの映像加工機能を一つのブロックとし加工要求に応じて必要なブロックをつなぎ合わせる方式を指す。これにより、各ブロックのインタフェースを共通化しておくことで、機能拡張はブロック単位で独立して実装できるため、機能の再構築が不要で、容易かつ迅速に拡張が可能である。柔軟なコンテンツの再利用を可能にするために、ビルディングブロック方式に加え、ゲートウェイでは図2のような機能ブロック間連携管理機構を持つ。機能ブロック間連携管理とは、機能ブロックの入出力を制御管理することを指す。これにより、視聴者からの要求に応じた機能ブロックの柔軟な組み替えや、ストリーム生成の途中状態を取り出すことや機能ブロック単位でのマルチユースが可能となり、柔軟なコンテンツ再利用が可能となる。上記のことを踏まえ、本発明の一局面に従った映像配信プラットフォームは、ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとを備え、それらが連携したストリーム処理を行う。そして、前記ストリームゲートウェイは、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断し、当該配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動し、これら再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成する一方、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送する。本発明によると、コンテンツ配信に関する機能拡張を容易に行うことができる。また、複数の受信クライアントから同一要求が出た場合も迅速に対応できるようになり、ゲートウェイの加工処理負荷の分散化や同一形式のストリームの配信トラフィックの削減などプラットフォーム全体の効率化を図ることができる。以下、図面を参照しながら本発明を実施するための形態について説明する。なお、本発明は、以下の実施形態に限定されるものではない。全体構成図3は、本発明の一実施形態に係る映像配信プラットフォームの構成を示す。本実施形態に係る映像配信プラットフォームは、クライアントが所属するISPInternetServiceProvider等の組織単位であるデリバリードメインDD10、クライアントが視聴する際に利用する視聴webアプリケーションであるビューアインタフェースVI12、映像加工処理を行うストリームゲートウェイSTGW14、コンテンツやユーザ、各STGW14の情報を管理し、ユーザからの要求に応じた制御と視聴webアプリケーションの提供を行う管理サーバMGSV16によって構成される。STGW14はDD単位に配置され,MGSV16が各STGW14の情報を管理することでユーザに応じたSTGW14へ処理を要求することを可能としている。負荷分散のために複数配置も想定している。DD内はIPマルチキャスト以下、マルチキャストが利用可能であるものとし、複数の映像と音声の配信はマルチキャストが用いられる。異なるDD間の配送は、マルチキャストもしくはユニキャストへの変換により行われる。MGSV16はコンテンツ情報として配信先アドレスや品質情報等の管理を行い、ユーザからの要求に従いコンテンツ情報の送信や視聴画面の提供を行う。また、定期的なSTGW14からのフィードバック情報を基にユーザに適したSTGW14の選択や負荷分散を行う。VI12はwebブラウザ上でストリームを再生するソフトウェアを用いて、画面レイアウトの共有とマルチストリームを受信可能としている。webブラウザ上で提供するので視聴端末自身に専用ソフトウェアをインストールする必要はない。映像配信の流れ図4は、ユーザからの映像配信要求から配信までの流れを示す。また、表1は、MGSV16が管理している情報を示す。MGSV16はコンテンツの情報や各STGW14、STGW14間の配信状況を管理している。これらの情報によって、コンテンツの再利用やSTGW14の状態に応じた分散処理が可能となる。また、MGSV16はSTGW14間で配信されているコンテンツとそれに対する視聴者数をStreaminfoによって管理している。映像配信停止要求時には、Streaminfo情報に基づき配信先に視聴者が存在しなくなったと判断したときに限り、それぞれのSTGW14へ配信に利用している処理を停止するよう要求を送信する。図4の5のように、必要に応じてコンテンツ配信を行う前に事前にプラットフォーム状態をコンテンツ配信に適した形へと変更する処理を行う。例えば、異なるDD間での配信到達性を確保したい場合は、マルチキャスト到達性の確保のためのユニキャストへのカプセル化をする。STGW14が保有していない加工機能の拡張をする場合はMGSV16から必要な加工機能をダウンロードする処理をする。STGWの構成モデル図5は、STGW14の構成モデルを模式的に示す。映像に対する処理を行う機能ブロックはSTGW14で起動するモジュールによって実現される。STGW14はモジュールを制御するコントローラ、モジュールの状態を管理するデータベースDB、モジュール群にネットワーク側に対して映像取得配信を行うINPUTOUTPUTモジュールと映像加工を行うProcessingモジュール群によって構成される。また、各モジュールにはコントローラからの制御メッセージ受信用、データ送受信用のインタフェースを持ち、それぞれControlInterFaceC-IF、StreamInterFaceS-IFと定義する。C-IF、S-IFはブロック間連携管理がしやすいインタフェースとし、入出力の処理負荷を小さくするためにパイプではなくソケット通信をローカルホスト内で使うとよい。これにより各モジュールのインタフェースを共通化する。具体的には、モジュールは、入力された複数のコンテンツを一つにまとめる映像合成処理、入力されたコンテンツを複数のブロックに分割してそのうちの少なくとも一つを出力する映像分割処理、入力されたコンテンツのフレームレートを変換する品質変換処理、入力されたコンテンツのパケットロスを前方誤り訂正や再送制御等によって補正するロス補正処理などを行う。STGW処理例次に、RTPRealtimeTransportProtocolマルチキャストストリームの送受信を前提とするSTGW14の処理例について説明する。図6は、MGSV16からの要求受信からそれに応答するまでの処理の流れを示す。また、表2は、STGW14が管理している情報を示す。なお、STGW-Cの管轄ドメインに所属するユーザ端末Src_hostからSTGW-Bを経由してSTGW-Aの管轄ドメインに所属するユーザ端末Dst_hostにコンテンツが配信されるものとする。STGW14STGW-AのコントローラはMGSV16からの要求メッセージに応じて処理に必要なモジュールを判断する。このとき加工要求に対して必要なモジュールと組み合わせる順序も事前に定義する。DB内のModulestateinfoテーブルにて各モジュール状態を管理しておき、起動停止処理が必要か判断し処理を行う。映像配信処理としてマルチユースに関する処理を行い、S-IFに割り当てる利用可能な識別子情報をPortinfoテーブルから検索し、C-IFに対して各モジュールへS-IFを作成するよう伝達する。要求を受信した各モジュールは、S-IFの生成削除を行い伝達に対する応答を行う。コントローラは全てのモジュールから伝達に対する応答を受信後、各DBを更新後MGSV16へコンテンツの受信待ちポートを通知する。MGSV16はSTGW-Aからコンテンツ受信待ちポートの通知を受けると、上流のSTGW-BにcontentidとSTGW-Aのアドレスおよび受信待ちポートの情報を添えてコンテンツ転送を要求する。STGW-Bは当該転送要求を受けてネットワーク透過処理の準備をしてMGSV16へコンテンツの受信待ちポートを通知する。MGSV16はSTGW-Bからコンテンツ受信待ちポートの通知を受けると、さらに上流のSTGW-CにcontentidとSTGW-Bのアドレスおよび受信待ちポートの情報を添えてコンテンツ転送を要求する。STGW-Cは当該転送要求を受けてSrc_hostからアップロードされるコンテンツをSTGW-Bに転送するための準備をしてMGSV16へ応答を返す。MGSV16はSTGW-Cからの応答を受けると、ContentinfoテーブルおよびStreaminfoテーブルを更新してDst_hostに要求に係るコンテンツの配信先アドレスを通知する。これにより、Src_hostからDst_hostにユーザ所望の映像加工が施されたコンテンツが配信される。機能ブロック間連携管理の処理機能ブロック間連携の管理は各モジュールのS-IFを用いて行う。STGW14はDB内のProcessinfoテーブル内に受信しているストリーム識別子であるcontentidとそれに対して処理を行っている各モジュールのS-IF識別子ifidを管理している。さらに、Ifinfoテーブル内で各S-IFがいくつのストリーム処理に使われているか管理している。これによって加工処理を行っているコンテンツ毎に利用しているモジュールの入出力を制御することが可能となり、加工処理に応じたS-IFの生成や削除、連結を行う。続いて、機能ブロック間連携管理を用いたマルチユースに関する処理について図6を用いて述べる。以下に、箇条書きで処理を示す。説明のためにモジュールを3つ図6のmodule123用いて行うTRANS処理を例に挙げ、図中には利用例の情報を記載している。また、マルチユースは各モジュールのS-IFを起点に行われる。そのため、各S-IFにはdummy情報を持たせ、マルチユースした回数を管理しておくことで、S-IFを削除する必要があるか判断が可能となる。1Processinfoテーブル内から加工したいストリームに利用しているifidを検索する。この例では、ifid123456が該当する。2検索したifidを基にIfinfoテーブル内からifidに関する情報を取得し、modulenameとoptionを抽出する。例えば、モジュールがCODEC処理を行うものである場合、そのフレームレートや解像度は様々であるため、optionとしてフレームレートや解像度を指定することができる。32の情報と加工処理に必要なモジュール名とMGSV16からのメッセージに含まれるoptionとのマッチングを行う。この例では、ifid4までマッチング成立となる。4マッチングが成立していた場合、そのifid情報を保管し、dummy情報を1する。5マッチングが不成立の場合、保管しているifidがマルチユースを行うS-IFと判断し、マルチユースに関する処理を終える。この例では、ifid5のとき、DB内のoption内容がメッセージのoption内容と異なるため不成立と判断する。上記の処理を1によって取得したifidの数分またはマッチングが不成立になるまで繰り返す。マッチングの不成立は必要なモジュール名に加えてoption内容も同じかマッチングすることによって判断している。これは、加工処理単位の処理内容まで同様かを意味しており、これによって加工要求に類似している処理レベルまでS-IFを検知することが可能である。既存システムとの比較表3は、本発明に係る映像配信プラットフォームと既存システムとの比較結果を示す。比較対象として、非特許文献1の映像配信システム、非特許文献2のスケーラブルゲートウェイ、非特許文献3のGstreamerとし、それぞれ安部、SG、Gstと表記する。SGとGstは単一のゲートウェイなので、ゲートウェイの分散配置に関しては比較できないが、本発明と安部らのシステムでは複数の分散配置をすることで、ゲートウェイ内だけでなく、プラットフォーム全体で加工機能の共有化が図れる。また、本発明は、安部らのシステムにはない、ストリームの再利用および機能拡張の容易性を達成している。"