JP2013132012A

JP2013132012A - 映像配信プラットフォームおよび映像配信方法

Info

Publication number: JP2013132012A
Application number: JP2011281996A
Authority: JP
Inventors: Toru Kondo; 徹近堂; Kaori Maeda; 香織前田; Yuichi Ishikuni; 裕一石國
Original assignee: Hiroshima University NUC; Hiroshima City University
Current assignee: Hiroshima University NUC; Hiroshima City University
Priority date: 2011-12-22
Filing date: 2011-12-22
Publication date: 2013-07-04
Anticipated expiration: 2031-12-22
Also published as: JP5842266B2

Abstract

【課題】コンテンツ配信に関する機能拡張を容易に行うことができ、また、コンテンツの加工効率に優れた映像配信プラットフォームを提供する。
【解決手段】ストリームゲートウェイ（１４）は、管理サーバ（１６）からコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断し、当該配信要求に係るコンテンツを処理している既起動のモジュールのうち必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動し、これら再利用および新たに起動したモジュールを判断した順序で連結して配信および加工要求に係るコンテンツを新たに生成する一方、管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送する。
【選択図】図３

Description

本発明は、映像配信プラットフォームに関し、特に、利用者の要望する映像の加工等の機能拡張が容易なビルディングブロック方式を採用したゲートウェイによる映像配信プラットフォームに関する。

近年のインターネットの広域化に伴い、映像配信サービスの開発が進み、Ustream（登録商標）等の個人の映像を気軽に不特定多数に配信するような映像配信プラットフォームが普及しつつある。既にこのようなサービスは商用化し、２０１０年度では広告や宣伝への利用で市場規模６．４億円、１０年後の２０２０年には７４００億円にもなると予想され今後も注目度は高まっている。

一方、近年の映像視聴形態にも変化が生じている。映像視聴者の環境や嗜好にあわせた映像を配信するパーソナライズ型配信や、同一の映像シーンを視聴し臨場感を共有するパブリックビューイングに関する研究も行われている（例えば、非特許文献１乃至３参照）。パーソナライズ型配信では無線環境に応じた映像品質の変換や前方誤り訂正（ＦＥＣ：Forward Error Correction）等のロス補正情報の付加、様々なエフェクト効果の追加等の要求が、パブリックビューイングではコンテンツ情報や映像シーンの同期、画面レイアウト情報の共有といった多種多様な要求が存在する。

また、本願発明者によるスケーラブル高精細映像配信基盤の研究発表も行われているが（例えば、非特許文献４参照）、ゲートウェイ処理の詳細については今後の研究を待つところである。

安部光一、前田香織、井上博之、近堂徹、"視聴体験の共有を可能にする映像配信システムの設計と実装"、情報処理学会研究報告、2010年、Vol.2010-IOT-8、No.34、pp.1-6 笠井裕之、富永英義、"マルチプルトランスコーダストリームスイッチングに基づくスケーラブルゲートウェイ方式"、電子情報通信学会論文誌、2003年、Vol.J86-B、No.10、pp.2229-2244 GStreamer、[online]、[2011年8月11日検索]、インターネット〈ＵＲＬ：http://gstreamer.freedesktop.org/〉近堂徹、"ビルディングブロック方式によるスケーラブル高精細映像配信基盤に関する研究"、[online]、[2011年11月1日検索]、インターネット〈ＵＲＬ：http://kaken.nii.ac.jp/pdf/2010/seika/mext/15401/20700066seika.pdf〉

映像配信プラットフォームは視聴者が要求するコンテンツや視聴形態を提供するものであるものの、Ustream等既存の映像配信プラットフォームの多くは定型的な形態で配信されることが多く、前述のようなコンテンツの加工等新たな機能追加が容易ではない。また、画面分割や符号化形式の変換等の加工機能をプラットフォームが提供する場合も、視聴者個々の要望にあわせて加工するため、視聴者の要望ごとに同様の加工処理を行う場合が多い。このように現在の映像配信プラットフォームではコンテンツに対する新規の加工要望に対して柔軟性がなく、コンテンツの再利用が難しいので、コンテンツの加工効率が悪い。

今後の映像配信プラットフォームでは、映像品質、映像効果に関する視聴者からの多様な要求に対して、柔軟に対応できるプラットフォームであることが望まれる。配信コンテンツの加工がネットワーク上のユーザ側（エッジ）に近いところでなされるほど、プラットフォーム上でのコンテンツ加工の効率やネットワークトラフィックの分散効率が悪くなる。言い換えると、加工後に共通に使えるコンテンツをネットワーク上に適切に配置することにより、エッジで個別加工する必要もなく、かつ、ネットワーク資源も共有に使える可能性が高くなる。

そこで本発明は、コンテンツ配信に関する機能拡張を容易に行うことができ、また、コンテンツの加工効率に優れた映像配信プラットフォームを提供することを目的とする。

本発明に係る映像配信プラットフォームでは、多様な加工要求を集中型で処理するのではなく、プラットフォーム内にコンテンツの加工（変換）を行うゲートウェイを分散設置し、個々のゲートウェイの加工状況を管理することで、加工後の出力ストリームをプラットフォームの共有資源として、複数の同一要求に対しても再利用できるようにする。また、ゲートウェイでは新たな加工要求（機能実現）が容易となるように、ゲートウェイの各機能をブロック化して構成する。これらを実現するために、ワンソースマルチユース、ビルディングブロック方式、および機能ブロック間連携管理の３つの要素技術を採用する。

ワンソースマルチユースとは、一つの情報を多目的な利用用途へ用いることを示す。例えば、撮影した映像を映画またはＤＶＤ等に利用することが挙げられる。本明細書では、一つのストリームに対して様々な加工処理を行い複数のストリームへと変換し配信を行うことを指す。

ビルディングブロック方式とは、システム構築を行う際、ハードウェア、ＯＳ等のように要素を分解させ必要な機能を選択させ積み木のように構築していくことを示す。本明細書では、図１のように一つの映像加工機能を一つのブロックとし加工要求に応じて必要なブロックをつなぎ合わせる方式を指す。これにより、各ブロックのインタフェースを共通化しておくことで、機能拡張はブロック単位で独立して実装できるため、機能の再構築が不要で、容易かつ迅速に拡張が可能である。

柔軟なコンテンツの再利用を可能にするために、ビルディングブロック方式に加え、ゲートウェイでは図２のような機能ブロック間連携管理機構を持つ。機能ブロック間連携管理とは、機能ブロックの入出力を制御・管理することを指す。これにより、視聴者からの要求に応じた機能ブロックの柔軟な組み替えや、ストリーム生成の途中状態を取り出すことや機能ブロック単位でのマルチユースが可能となり、柔軟なコンテンツ再利用が可能となる。

上記のことを踏まえ、本発明の一局面に従った映像配信プラットフォームは、ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとを備え、それらが連携したストリーム処理を行う。そして、前記ストリームゲートウェイは、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断し、当該配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動し、これら再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成する一方、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送する。

本発明によると、コンテンツ配信に関する機能拡張を容易に行うことができる。また、複数の受信クライアントから同一要求が出た場合も迅速に対応できるようになり、ゲートウェイの加工処理負荷の分散化や同一形式のストリームの配信トラフィックの削減などプラットフォーム全体の効率化を図ることができる。

ビルディングブロック方式の概念図機能ブロック間連携管理の概念図本発明の一実施形態に係る映像配信プラットフォームの構成図ユーザからの映像配信要求から配信までのフロー図ストリームゲートウェイの構成モデルの模式図ＳＴＧＷ処理のフロー図

以下、図面を参照しながら本発明を実施するための形態について説明する。なお、本発明は、以下の実施形態に限定されるものではない。

（全体構成）
図３は、本発明の一実施形態に係る映像配信プラットフォームの構成を示す。本実施形態に係る映像配信プラットフォームは、クライアントが所属するＩＳＰ（Internet Service Provider）等の組織単位であるデリバリードメイン（ＤＤ）１０、クライアントが視聴する際に利用する視聴ｗｅｂアプリケーションであるビューアインタフェース（ＶＩ）１２、映像加工処理を行うストリームゲートウェイ（ＳＴＧＷ）１４、コンテンツやユーザ、各ＳＴＧＷ１４の情報を管理し、ユーザからの要求に応じた制御と視聴ｗｅｂアプリケーションの提供を行う管理サーバ（ＭＧＳＶ）１６によって構成される。

ＳＴＧＷ１４はＤＤ単位に配置され，ＭＧＳＶ１６が各ＳＴＧＷ１４の情報を管理することでユーザに応じたＳＴＧＷ１４へ処理を要求することを可能としている。負荷分散のために複数配置も想定している。ＤＤ内はＩＰマルチキャスト（以下、マルチキャスト）が利用可能であるものとし、複数の映像と音声の配信はマルチキャストが用いられる。異なるＤＤ間の配送は、マルチキャストもしくはユニキャストへの変換により行われる。

ＭＧＳＶ１６はコンテンツ情報として配信先アドレスや品質情報等の管理を行い、ユーザからの要求に従いコンテンツ情報の送信や視聴画面の提供を行う。また、定期的なＳＴＧＷ１４からのフィードバック情報を基にユーザに適したＳＴＧＷ１４の選択や負荷分散を行う。

ＶＩ１２はｗｅｂブラウザ上でストリームを再生するソフトウェアを用いて、画面レイアウトの共有とマルチストリームを受信可能としている。ｗｅｂブラウザ上で提供するので視聴端末自身に専用ソフトウェアをインストールする必要はない。

（映像配信の流れ）
図４は、ユーザからの映像配信要求から配信までの流れを示す。また、表１は、ＭＧＳＶ１６が管理している情報を示す。

ＭＧＳＶ１６はコンテンツの情報や各ＳＴＧＷ１４、ＳＴＧＷ１４間の配信状況を管理している。これらの情報によって、コンテンツの再利用やＳＴＧＷ１４の状態に応じた分散処理が可能となる。また、ＭＧＳＶ１６はＳＴＧＷ１４間で配信されているコンテンツとそれに対する視聴者数をStream_infoによって管理している。映像配信停止要求時には、Stream_info情報に基づき配信先に視聴者が存在しなくなったと判断したときに限り、それぞれのＳＴＧＷ１４へ配信に利用している処理を停止するよう要求を送信する。

図４の（５）のように、必要に応じてコンテンツ配信を行う前に事前にプラットフォーム状態をコンテンツ配信に適した形へと変更する処理を行う。例えば、異なるＤＤ間での配信到達性を確保したい場合は、マルチキャスト到達性の確保のためのユニキャストへのカプセル化をする。ＳＴＧＷ１４が保有していない加工機能の拡張をする場合はＭＧＳＶ１６から必要な加工機能をダウンロードする処理をする。

（ＳＴＧＷの構成モデル）
図５は、ＳＴＧＷ１４の構成モデルを模式的に示す。映像に対する処理を行う機能ブロックはＳＴＧＷ１４で起動するモジュールによって実現される。ＳＴＧＷ１４はモジュールを制御するコントローラ、モジュールの状態を管理するデータベース（ＤＢ）、モジュール群にネットワーク側に対して映像取得・配信を行うINPUT/OUTPUTモジュールと映像加工を行うProcessingモジュール群によって構成される。また、各モジュールにはコントローラからの制御メッセージ受信用、データ送受信用のインタフェースを持ち、それぞれControl-InterFace（Ｃ−ＩＦ）、Stream-InterFace（Ｓ−ＩＦ）と定義する。Ｃ−ＩＦ、Ｓ−ＩＦはブロック間連携管理がしやすいインタフェースとし、入出力の処理負荷を小さくするためにパイプではなくソケット通信をローカルホスト内で使うとよい。これにより各モジュールのインタフェースを共通化する。

具体的には、モジュールは、入力された複数のコンテンツを一つにまとめる映像合成処理、入力されたコンテンツを複数のブロックに分割してそのうちの少なくとも一つを出力する映像分割処理、入力されたコンテンツのフレームレートを変換する品質変換処理、入力されたコンテンツのパケットロスを前方誤り訂正や再送制御等によって補正するロス補正処理などを行う。

（ＳＴＧＷ処理例）
次に、ＲＴＰ（Real-time Transport Protocol）マルチキャストストリームの送受信を前提とするＳＴＧＷ１４の処理例について説明する。図６は、ＭＧＳＶ１６からの要求受信からそれに応答するまでの処理の流れを示す。また、表２は、ＳＴＧＷ１４が管理している情報を示す。なお、ＳＴＧＷ−Ｃの管轄ドメインに所属するユーザ端末Ｓｒｃ＿ｈｏｓｔからＳＴＧＷ−Ｂを経由してＳＴＧＷ−Ａの管轄ドメインに所属するユーザ端末Ｄｓｔ＿ｈｏｓｔにコンテンツが配信されるものとする。

ＳＴＧＷ１４（ＳＴＧＷ−Ａ）のコントローラはＭＧＳＶ１６からの要求メッセージに応じて処理に必要なモジュールを判断する。このとき加工要求に対して必要なモジュールと組み合わせる順序も事前に定義する。ＤＢ内のModule_state_infoテーブルにて各モジュール状態を管理しておき、起動・停止処理が必要か判断し処理を行う。映像配信処理としてマルチユースに関する処理を行い、Ｓ−ＩＦに割り当てる利用可能な識別子情報をPort_infoテーブルから検索し、Ｃ−ＩＦに対して各モジュールへＳ−ＩＦを作成するよう伝達する。要求を受信した各モジュールは、Ｓ−ＩＦの生成・削除を行い伝達に対する応答を行う。コントローラは全てのモジュールから伝達に対する応答を受信後、各ＤＢを更新後ＭＧＳＶ１６へコンテンツの受信待ちポートを通知する。

ＭＧＳＶ１６はＳＴＧＷ−Ａからコンテンツ受信待ちポートの通知を受けると、上流のＳＴＧＷ−Ｂにcontent_idとＳＴＧＷ−Ａのアドレスおよび受信待ちポートの情報を添えてコンテンツ転送を要求する。ＳＴＧＷ−Ｂは当該転送要求を受けてネットワーク透過処理の準備をしてＭＧＳＶ１６へコンテンツの受信待ちポートを通知する。ＭＧＳＶ１６はＳＴＧＷ−Ｂからコンテンツ受信待ちポートの通知を受けると、さらに上流のＳＴＧＷ−Ｃにcontent_idとＳＴＧＷ−Ｂのアドレスおよび受信待ちポートの情報を添えてコンテンツ転送を要求する。ＳＴＧＷ−Ｃは当該転送要求を受けてＳｒｃ＿ｈｏｓｔからアップロードされるコンテンツをＳＴＧＷ−Ｂに転送するための準備をしてＭＧＳＶ１６へ応答を返す。ＭＧＳＶ１６はＳＴＧＷ−Ｃからの応答を受けると、Content_infoテーブルおよびStream_infoテーブルを更新してＤｓｔ＿ｈｏｓｔに要求に係るコンテンツの配信先アドレスを通知する。これにより、Ｓｒｃ＿ｈｏｓｔからＤｓｔ＿ｈｏｓｔにユーザ所望の映像加工が施されたコンテンツが配信される。

（機能ブロック間連携管理の処理）
機能ブロック間連携の管理は各モジュールのＳ−ＩＦを用いて行う。ＳＴＧＷ１４はＤＢ内のProcess_infoテーブル内に受信しているストリーム識別子であるcontent_idとそれに対して処理を行っている各モジュールのＳ−ＩＦ識別子if_idを管理している。さらに、If_infoテーブル内で各Ｓ−ＩＦがいくつのストリーム処理に使われているか管理している。これによって加工処理を行っているコンテンツ毎に利用しているモジュールの入出力を制御することが可能となり、加工処理に応じたＳ−ＩＦの生成や削除、連結を行う。

続いて、機能ブロック間連携管理を用いたマルチユースに関する処理について図６を用いて述べる。以下に、箇条書きで処理を示す。説明のためにモジュールを３つ（図６のmodule1,2,3）用いて行うＴＲＡＮＳ処理を例に挙げ、図中には利用例の情報を記載している。また、マルチユースは各モジュールのＳ−ＩＦを起点に行われる。そのため、各Ｓ−ＩＦにはdummy情報を持たせ、マルチユースした回数を管理しておくことで、Ｓ−ＩＦを削除する必要があるか判断が可能となる。

（１） Process_infoテーブル内から加工したいストリームに利用しているif_idを検索する。この例では、if_id=1,2,3,4,5,6が該当する。

（２）検索したif_idを基にIf_infoテーブル内からif_idに関する情報を取得し、module_nameとoptionを抽出する。例えば、モジュールがＣＯＤＥＣ処理を行うものである場合、そのフレームレートや解像度は様々であるため、optionとしてフレームレートや解像度を指定することができる。

（３）（２）の情報と加工処理に必要なモジュール名とＭＧＳＶ１６からのメッセージに含まれるoptionとのマッチングを行う。この例では、if_id=4までマッチング成立となる。

（４）マッチングが成立していた場合、そのif_id情報を保管し、dummy情報を＋１する。

（５）マッチングが不成立の場合、保管しているif_idがマルチユースを行うＳ−ＩＦと判断し、マルチユースに関する処理を終える。この例では、if_id=5のとき、ＤＢ内のoption内容がメッセージのoption内容と異なるため不成立と判断する。

上記の処理を（１）によって取得したif_idの数分またはマッチングが不成立になるまで繰り返す。マッチングの不成立は必要なモジュール名に加えてoption内容も同じかマッチングすることによって判断している。これは、加工処理単位の処理内容まで同様かを意味しており、これによって加工要求に類似している処理レベルまでＳ−ＩＦを検知することが可能である。

（既存システムとの比較）
表３は、本発明に係る映像配信プラットフォームと既存システムとの比較結果を示す。比較対象として、非特許文献１の映像配信システム、非特許文献２のスケーラブルゲートウェイ、非特許文献３のGstreamerとし、それぞれ安部、ＳＧ、Ｇｓｔと表記する。

ＳＧとＧｓｔは単一のゲートウェイなので、ゲートウェイの分散配置に関しては比較できないが、本発明と安部らのシステムでは複数の分散配置をすることで、ゲートウェイ内だけでなく、プラットフォーム全体で加工機能の共有化が図れる。また、本発明は、安部らのシステムにはない、ストリームの再利用および機能拡張の容易性を達成している。

本発明に係る映像配信プラットフォームは、コンテンツ配信に関する機能拡張を容易に行うことができ、また、コンテンツの加工効率に優れているため、同一の映像シーンを複数のユーザ端末で同時に視聴するパブリックビューイングなどに有用である。

１４ＳＴＧＷ（ストリームゲートウェイ）
１６ＭＧＳＶ（管理サーバ）

Claims

ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、
ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとを備え、
前記ストリームゲートウェイは、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断し、当該配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動し、これら再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成する一方、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送する
ことを特徴とする映像配信プラットフォーム。
請求項１に記載の映像配信プラットフォームにおいて、
前記モジュールは、入力された複数のコンテンツを一つにまとめる映像合成処理を行うものである
ことを特徴とする映像配信プラットフォーム。
請求項１に記載の映像配信プラットフォームにおいて、
前記モジュールは、入力されたコンテンツを複数のブロックに分割してそのうちの少なくとも一つを出力する映像分割処理を行うものである
ことを特徴とする映像配信プラットフォーム。
請求項１に記載の映像配信プラットフォームにおいて、
前記モジュールは、入力されたコンテンツのフレームレートを変換する品質変換処理を行うものである
ことを特徴とする映像配信プラットフォーム。
請求項１に記載の映像配信プラットフォームにおいて、
前記モジュールは、入力されたコンテンツのパケットロスを前方誤り訂正や再送制御等によって補正するロス補正処理を行うものである
ことを特徴とする映像配信プラットフォーム。
ネットワークの各ドメインに配置され、同一ソースのコンテンツに個々のユーザの要求に応じた映像加工を施して当該加工後のコンテンツを管轄ドメイン内にマルチキャスト配信する複数のストリームゲートウェイと、ユーザからの要求に応じて前記ストリームゲートウェイにコンテンツの配信および加工要求を出し、異ドメイン間でコンテンツを配信する場合には前記ストリームゲートウェイにコンテンツの転送要求を出す管理サーバとによる映像配信方法であって、
前記ストリームゲートウェイが、前記管理サーバからコンテンツの配信および加工要求を受けたとき、当該加工要求に係る映像加工に必要なモジュールおよびその連結順序を判断するステップと、
前記ストリームゲートウェイが、前記配信要求に係るコンテンツを処理している既起動のモジュールのうち前記必要と判断したモジュールに一致するものがあれば当該既起動のモジュールを再利用し、なければ新たにモジュールを起動するステップと、
前記ストリームゲートウェイが、前記再利用および新たに起動したモジュールを前記判断した順序で連結して前記配信および加工要求に係るコンテンツを新たに生成するステップと、
前記ストリームゲートウェイが、前記管理サーバからコンテンツの転送要求を受けたとき、受信したコンテンツを他のストリームゲートウェイに転送するステップとを備えている
ことを特徴とする映像配信方法。