(57)【特許請求の範囲】
【請求項１】
それぞれが少なくともビデオ情報を含む複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置であって、
情報送信装置から、予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求があった場合に、当該情報送信装置を当該グループに参加する中継情報の送信元として許容し、該情報送信装置から送信される中継情報をミキシング処理の対象とするミキシング参加制御手段を有するミキサ装置。
【請求項２】
前記グループを設定するソースグループ設定手段を有する請求項１記載のミキサ装置。
【請求項３】
前記ミキシング参加制御手段は、
前記情報送信装置からの前記グループへの参加要求があったときに、参加許可または参加拒否の応答を当該情報送信装置に送る可否応答制御手段を有し、
参加許可の応答を前記情報送信装置に送った後に、前記情報送信装置から送信される中継情報をミキシング処理の対象とする請求項１または２記載のミキサ装置。
【請求項４】
ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があった場合に、当該情報送信装置をミキシング処理の対象となる中継情報の送信元から外し、該情報送信装置からの中継情報のミキシング処理を行わないミキシング退出制御手段を有する請求項１乃至３のいずれかに記載のミキサ装置。
【請求項５】
前記グループへの参加要求がある毎に、その要求元の情報送信装置に対応したバッファ部を形成する入力制御手段を有し、
前記ミキシング処理の対象とする前記情報送信装置からの中継情報を当該情報送信装置に対応する前記バッファ部を介してミキシング処理に供する請求項１乃至４のいずれかに記載のミキサ装置。
【請求項６】
前記ミキシング中継情報を所定のネットワーク上のライブ中継用サービスサイトに提供する出力制御手段を有する請求項１乃至５のいずれかに記載のミキサ装置。
【請求項７】
他のミキサ装置に対して設定されている他のグループへの参加要求を送信するソースグループ参加要求制御手段を有し、
前記他のグループへの参加要求を前記他のミキサ装置に送信した後に、前記ミキシング中継情報を前記他のミキサ装置におけるミキシング処理の対象とすべき中継情報として当該他のミキサ装置に提供する請求項１乃至６のいずれかに記載のミキサ装置。
【請求項８】
前記他のグループからの退出要求を前記他のミキサ装置に送信するソースグループ退出要求制御手段を有し、
ミキシング処理の対象となるミキシング中継情報の前記他のミキサ装置に対する送信元から外れる請求項７記載のミキサ装置。
【請求項９】
少なくともビデオ情報を含む中継情報を送信する複数の情報送信装置と、
複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置を有し、
前記複数の情報送信装置のそれぞれは、
予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求を前記ミキサ装置に送るソースグループ参加要求制御手段を有し、
前記ミキサ装置は、
前記複数の情報送信装置のいずれかから前記グループへの参加要求があった場合に、当該情報送信装置を当該グループに参加する中継情報の送信元として許容し、該情報送信装置から送信される中継情報をミキシング処理の対象とするミキシング参加制御手段を有するライブ中継システム。
【請求項１０】
前記ミキサ装置は、前記グループを設定するソースグループ設定手段を有する請求項９記載のライブ中継システム。
【請求項１１】
前記ミキサ装置の前記ミキシング参加制御手段は、
前記複数の情報送信装置のいずれかからの前記グループへの参加要求があったときに、参加許可または参加拒否の応答を当該情報送信装置に送る可否応答制御手段を有し、
前記複数の情報送信装置のそれぞれは、前記ミキサ装置から前記参加許可の応答を受信した後に、前記中継情報を前記ミキサ装置へ送信し、
前記ミキサ装置は、前記参加許可の応答を情報送信装置に送った後に、当該情報送信装置から送信される中継情報をミキシング処理の対象とする請求項９または１０記載のライブ中継システム。
【請求項１２】
前記複数の情報送信装置のそれぞれは、
前記グループからの退出要求を前記ミキサ装置に送るソースグループ退出要求制御手段を有し、
前記ミキサ装置は、
ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があった場合に、当該情報送信装置をミキシング処理の対象となる中継情報の送信元から外し、該情報送信装置からの中継情報のミキシング処理を行わないミキシング退出制御手段を有する請求項９乃至１１のいずれかに記載のライブ中継システム。
【請求項１３】
前記ミキサ装置は、
前記グループへの参加要求がある毎に、その要求元の情報送信装置に対応したバッファ部を形成する入力制御手段を有し、
前記ミキシング処理の対象とする前記情報送信装置からの中継情報を当該情報送信装置に対応する前記バッファ部を介してミキシング処理に供する請求項９乃至１２のいずれかに記載のライブ中継システム。
【請求項１４】
前記ミキサ装置は、
前記ミキシング中継情報を所定のネットワーク上のライブ中継用サービスサイトに提供する出力制御手段を有する請求項９乃至１３のいずれかに記載のライブ中継システム。
【請求項１５】
他のミキサ装置を有し、
前記ミキサ装置は、情報送信装置として、前記他のミキサ装置に対して設定されている他のグループへの参加要求を送信するソースグループ参加要求制御手段を有し、
前記他のグループへの参加要求を送信した後に、前記ミキシング中継情報を前記他のミキサ装置におけるミキシング処理の対象となる中継情報として当該他のミキサ装置に送信する請求項９乃至１４のいずれかに記載のライブ中継システム。
【請求項１６】
前記ミキサ装置は、
前記他のグループからの退出要求を前記他のミキサ装置に送信するソースグループ退出要求制御手段を有し、
ミキシング処理の対象となるミキシング中継情報の送信元から外れる請求項１５記載のライブ中継システム。
【請求項１７】
少なくともビデオ情報を含む複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力する複数の第１ミキサ装置と、
前記複数の第１ミキサ装置に対して設定されるミキシング処理の対象となる中継情報の送信元のグループに参加し、当該第１ミキサ装置にミキシング処理の対象となる中継情報を送る複数の情報送信装置と、
ミキシング処理の対象となるミキシング中継情報の送信元のグループとして設定し、前記複数の第１ミキシング装置を、ミキシング処理の対象となるミキシング中継情報の送信元のグループに参加するミキシング中継情報の送信元として許容し、当該複数の第１ミキサ装置からのミキシング中継情報をミキシング処理して統合されたミキシング中継情報を出力する第２ミキサ装置とを有するライブ中継システム。
【請求項１８】
少なくともビデオ情報を含む中継情報を送信する複数の情報送信装置と、
所定のネットワーク上に配置され、複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置と、
前記ミキシング装置でのミキシング処理の遠隔操作を行う操作装置とを有し、
前記複数の情報送信装置のそれぞれは、
予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求を前記操作装置に送るソースグループ参加要求制御手段を有し、前記グループへの参加要求を行った後に前記操作装置により当該グループに参加する中継情報の送信元として許容され、
前記ミキサ装置は、
前記グループに参加する中継情報の送信元として許容された複数の情報送信装置からの中継情報を、前記操作装置での遠隔操作に従ってミキシング処理するグループミキシング処理手段と、
該グループミキシング処理手段により得られたミキシング中継情報を前記操作装置に送る出力制御手段とを有するライブ中継システム。
【請求項１９】
前記操作装置は、前記グループを設定するソースグループ設定手段を有する請求項１８記載のライブ中継システム。
【請求項２０】
前記複数の情報送信装置のそれぞれは、
前記グループからの退出要求を前記操作装置に送るソースグループ退出要求制御手段を有し、
前記操作装置は、
ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があった場合に、当該情報送信装置をミキシング処理の対象となる中継情報の送信元から外すミキシング退出制御手段を有する請求項１８または１９記載のライブ中継システム。
【請求項２１】
前記ネットワーク上に配置され、当該ネットワーク上に配置された複数のミキサ装置のいずれかを前記操作装置による遠隔操作の対象となる前記ミキサ装置として割り付ける制御装置を有する請求項１８乃至２０のいずれかに記載のライブ中継システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の情報送信装置からの少なくともビデオ情報を含む複数種の中継情報をミキシング処理し、該ミキシング処理にて得られたミキシング中継情報を出力するミキサ装置及びライブ中継システムに関する。
【背景技術】
【０００２】
インターネットを利用したライブ中継用サービス（非特許文献１〜３参照）の台頭と、インターネットの末端において使用可能な通信速度の向上、および個人で利用可能な計算機端末の性能向上により、ライブ中継は容易に実施可能となった。民生品のビデオカメラと汎用PC、またはスマートデバイス（スマートフォン、タブレットPC）を用いる簡単な構成であれば、業務用の機器を用いずともインターネットを利用したライブ中継が可能である。実施されているライブ中継の数は増加し、その内容も多様なものとなっている。ライブ中継の実施に係る敷居が下がり実施者の裾野が広がるに伴い、単一のビデオカメラを用いる簡単な構成のライブ中継のみならず、複数のビデオカメラを用いた複数ビデオソースによるライブ中継も、より容易に実施を可能とするシステムの実現への期待が高まっている。
【０００３】
例えば、特許文献１に記載されるミキシングシステムが知られている。このミキシングシステムでは、コンサート会場において複数のマイクで取得された複数の音声信号（中継情報）が、各音声信号に対応する符号化オーディオデータを含むフレームデータに変換され、そのフレームデータが会場ゲートウェイから所定のネットワークを介してスタジオのミキサ装置に提供される。そして、ミキサ装置が受信したフレームデータから抽出される複数の音声信号に対応したオーディオデータをミキシング処理し、得られるミキシングオーディオデータが当該ミキサ装置から前記ネットワークを介して会場ゲートウェイに送信され、そのミキシングオーディオデータに対応した音声がコンサート会場に設置されたスピーカから出力される。
【０００４】
このようなミキシングシステムによれば、コンサート会場にミキサ装置を持ち込むことなく、当該コンサート会場で取得されるオーディオデータやビデオデータを遠隔のスタジオに設置されたミキサ装置によりミキシング処理することができる。そして、スタジオに設置されたミキシング装置でのミキシング処理により得られたミキシングオーディオデータやミキシングビデオデータに基づいてミキシング後の音声や映像をコンサート会場で出力させることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−１９２２４４号公報
【非特許文献】
【０００６】
【非特許文献１】Ustream - The leading HD streaming video platform, available from < http:// http://www.ustream.tv> (accessed 2015-10-13)
【非特許文献２】Live - YouTube, available from < https://www.youtube.com/live> (accessed 2015-10-13)
【非特許文献３】ニコニコ生放送, 入手先 < http://live.nicovideo.jp> (参照 2015-10-13)
【非特許文献４】OpenLDAP Foundation: OpenLDAP, Main Page, available from <http://www.openldap.org> (accessed 2015-10-13).
【非特許文献５】Koji Hashimoto and Yoshitaka Shibata: MidField: An Adaptive Middleware System for Multipoint Digital Video Communication, Digital Video, Floriano De Rango (Ed.), ISBN: 978-953-7619-70-1, InTech, DOI: 10.5772/8032 (2010). available from: http://www.intechopen.com/books/digital-video/midfield-an-adaptive-middleware-system-for-multipoint-digital-video-communication (accessed 2015-10-13).
【非特許文献６】MSDN Library: DirectShow, available from < https://msdn.microsoft.com/en-us/library/windows/desktop/dd375454(v=vs.85).aspx > (accessed 2015-10-13).
【非特許文献７】Download Microsoft Expression Encoder 4 with Service Pack 2 (SP2) from Official Microsoft Download Center, available from <http://www.microsoft.com/en-us/download/details.aspx?id=27870> (accessed 2015-10-13).
【非特許文献８】AWT Native Interface, available from < http://docs.oracle.com/javase/7/docs/technotes/guides/awt/AWT_Native_Interface.html> (accessed 2015-10-13).
【非特許文献９】Roland VR-3EX | AV Mixer, 入手先 < http://www.roland.co.jp/products/vr-3ex> (参照 2015-10-13).
【非特許文献１０】鎧沢勇, 滝川啓, 大久保栄, 渡辺義郎: 衛星通信を利用した画像会議におけるエコー及び伝搬遅延の影響, 電子情報通信学会論文誌B, Vol.J64-B, No.11, pp.1281-1288 (1981).
【非特許文献１１】Roland VR-50HD | Multi-Format AV Mixer, 入手先 < http://www.roland.co.jp/products/vr-50hd> (参照 2015-10-13).
【非特許文献１２】media encoder, video capture software, audio capture software | Adobe Flash Media Live Encoder, available from < http://www.adobe.com/products/flash-media-encoder.html> (accessed 2015-10-13).
【非特許文献１３】Live Webcasting Software | Telestream Wirecast | Overview, available from < http://www.telestream.net/wirecast> (accessed 2015-10-13).
【非特許文献１４】Niconico Live Encoder - ニコニコ生放送, 入手先 < http://live.nicovideo.jp/s/encoder> (参照 2015-10-13).
【非特許文献１５】media encoder, video capture software, audio capture software | Adobe Flash Media Live Encoder, available from <http://www.adobe.com/products/flash-media-encoder.html> (accessed 2015-08-05).
【非特許文献１６】Live Webcasting Software | Telestream Wirecast | Overview, available from <http://www.telestream.net/wirecast> (accessed 2015-08-05).
【非特許文献１７】Niconico Live Encoder - ニコニコ生放送, 入手先 <http://live.nicovideo.jp/s/encoder> (参照 2015-08-05).
【非特許文献１８】Koji Hashimoto and Yoshitaka Shibata: MidField: An Adaptive Middleware System for Multipoint Digital Video Communication, Digital Video, Floriano De Rango (Ed.), ISBN: 978-953-7619-70-1, InTech, DOI: 10.5772/8032 (2010). available from: http://www.intechopen.com/books/digital-video/midfield-an-adaptive-middleware-system-for-multipoint-digital-video-communication (accessed 2015-08-05).
【非特許文献１９】MSDN Library: DirectShow, available from <https://msdn.microsoft.com/en-us/library/windows/desktop/dd375454(v=vs.85).aspx>(accessed 2015-08-05).
【非特許文献２０】Roland VR-3EX | AV Mixer, 入手先 < http://www.roland.co.jp/products/vr-3ex> (参照 2015-08-05).
【非特許文献２１】森安辰, 大島浩太, 高田治, 寺田松昭: オンデマンド型動画同時視聴における端末間高精度再生同期方式, 情報処理学会論文誌, Vol.54, No.2, pp.538-550 (2013).
【非特許文献２２】SLA（サービス品質保証制度） | サービス・ソリューション | IIJ, 入手先 <http://www.iij.ad.jp/svcsol/sla> (参照 2015-11-15).
【非特許文献２３】サービス品質保証制度（SLA） | サービス紹介 | NTT Communications ntt.net, 入手先 <http://www.ntt.net/service/sla_ts.html> (参照 2015-11-15).
【非特許文献２４】KDDI インターネットゲートウェイ: サービス品質保証 (SLA) | インターネット | 法人・ビジネス向け | KDDI株式会社, 入手先 <http://www.kddi.com/business/network/internet/internet-gateway/sla> (参照 2015-11-15).
【非特許文献２５】鎧沢勇, 滝川啓, 大久保栄, 渡辺義郎: 衛星通信を利用した画像会議におけるエコー及び伝搬遅延の影響, 電子情報通信学会論文誌B, Vol.J64-B, No.11, pp.1281-1288 (1981).
【非特許文献２６】玉木秀和, 東野豪, 小林稔, 井原雅行: 音声遅延が遠隔会議中の発話衝突と精神的ストレスに与える影響, 電子情報通信学会論文誌D, Vol.J96-D, No.1, pp.35-45 (2013).
【発明の概要】
【発明が解決しようとする課題】
【０００７】
例えば、複数の会場で同時に開催されるスポーツイベントや、神輿／山車／踊り手等が長い列を作る祭りのライブ中継を想定した場合、中継情報（ビデオ情報、オーディオ情報を含み得る）の送信元は特定の１地点のみでなく物理的に離れた複数の地点となり得る。複数の送信元からのビデオソースをまとめて、最終的にライブ中継用のサービスを用いてストリーミング配信するためには、複数の送信元から提供されるビデオストリームをミキシングしたり切り替えたりする必要がある。また、例えば、比較的広い範囲を対象とした移動する物についてのライブ中継では、中継情報の送信元の数が対象の物の移動とともに増加し得る。
【０００８】
しかし、前述した特許文献１に記載の従来のミキサシステムでは、複数の会場で同時に開催されるイベントにおける映像や音声の中継等、複数の地点の送信元から送信される中継情報をミキシングすることは考慮されておらず、また、その中継情報の送信元の数を容易に増やすことができない。
【０００９】
本発明は、このような事情に鑑みてなされたもので、ミキシング処理の対象となる中継情報の送信元を容易に増やすことのできるミキサ装置及び該ミキサ装置を用いたライブ中継システムを提供するものである。
【課題を解決するための手段】
【００１０】
本発明に係るミキサ装置は、それぞれが少なくともビデオ情報を含む複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置であって、情報送信装置から、予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求があった場合に、当該情報送信装置を当該グループに参加する中継情報の送信元として許容し、該情報送信装置から送信される中継情報をミキシング処理の対象とするミキシング参加制御手段を有する構成となる。
【００１１】
このような構成により、情報送信装置からグループへの参加要求があると、当該情報送信装置が中継情報の送信元として許容され、該情報送信装置からの中継情報がミキシング処理の対象となってミキシング処理される。
【００１２】
本発明に係るミキサ装置において、前記グループを設定するソースグループ設定手段を有する構成とすることができる。
【００１３】
このような構成により、ミキサ装置側で、当該ミキサ装置でのミキシング処理の対象となる中継情報の送信元のグループを自由に設定することができる。
【００１４】
本発明に係るミキサ装置において、前記ミキシング参加制御手段は、前記情報送信装置からの前記グループへの参加要求があったときに、参加許可または参加拒否の応答を当該情報送信装置に送る可否応答制御手段を有し、参加許可の応答を前記情報送信装置に送った後に、前記情報送信装置から送信される中継情報をミキシング処理の対象とする構成とすることができる。
【００１５】
このような構成により、参加許可の応答を送った情報送信装置からの中継情報だけをミキシング処理の対象とすることができる。
【００１６】
本発明に係るミキサ装置において、ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があった場合に、当該情報送信装置をミキシング処理の対象となる中継情報の送信元から外し、該情報送信装置からの中継情報のミキシング処理を行わないミキシング退出制御手段を有する構成とすることができる。
【００１７】
このような構成により、ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があると、当該情報送信装置がミキシング処理の対象となる中継情報の送信元から外されて、該情報送信装置からの中継情報のミキシング処理が行われなくなるので、キシング処理の対象となる中継情報の送信元を容易に減らすことのできるようになる。その結果、ミキシング処理の対象となる中継情報の送信元の数を動的に増減させることができるようになる。
【００１８】
本発明に係るミキサ装置において、前記グループへの参加要求がある毎に、その要求元の情報送信装置に対応したバッファ部を形成する入力制御手段を有し、前記ミキシング処理の対象とする前記情報送信装置からの中継情報を当該情報送信装置に対応する前記バッファ部を介してミキシング処理に供する構成とすることができる。
【００１９】
このような構成により、前記グループへの参加要求がある毎に作成されるバッファを介してその要求元の情報送信装置からの中継情報がミキシング処理に供されるので、異なるタイミングでグループに参加する複数の情報送信装置からの複数種の中継情報を同時にミキシング処理することができる。
【００２０】
本発明に係るミキサ装置において、前記ミキシング中継情報を所定のネットワーク上のライブ中継用サービスサイトに提供する出力制御手段を有する構成とすることができる。
【００２１】
このような構成により、複数種の中継情報をミキシング処理して得られるミキシング中継情報をライブ中継用サービスサイトから多くの端末装置に配信することができる。
【００２２】
本発明に係るミキサ装置において、他のミキサ装置に対して設定されている他のグループへの参加要求を送信するソースグループ参加要求制御手段を有し、前記他のグループへの参加要求を前記他のミキサ装置に送信した後に、前記ミキシング中継情報を前記他のミキサ装置におけるミキシング処理の対象とすべき中継情報として当該他のミキサ装置に提供する構成とすることができる。
【００２３】
このような構成により、複数種の中継情報をミキシング処理した結果得られるミキシング中継情報を、他のミキシング装置において、他の中継情報とともにミキシング処理することができるようになる。
【００２４】
本発明に係るミキサ装置において、前記他のグループからの退出要求を前記他のミキサ装置に送信するソースグループ退出要求制御手段を有し、ミキシング処理の対象となるミキシング中継情報の前記他のミキサ装置に対する送信元から外れる構成とすることができる。
【００２５】
このような構成により、他のミキサ装置において、ミキシング処理の対象となるミキシング中継情報の送信元となる当該ミキサ装置から前記他のグループからの退出要求があると、当該ミキサ装置がミキシング処理の対象となるミキシング中継情報の送信元から外されて、該ミキサ装置からのミキシング中継情報のミキシング処理が行われなくなるので、ミキシング処理の対象となるミキシング中継情報の送信元を容易に減らすことのできるようになる。
【００２６】
本発明に係るライブ中継システムは、少なくともビデオ情報を含む中継情報を送信する複数の情報送信装置と、複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置とを有し、前記複数の情報送信装置のそれぞれは、予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求を前記ミキサ装置に送るソースグループ参加要求制御手段を有し、前記ミキサ装置は、前記複数の情報送信装置のいずれかから前記グループへの参加要求があった場合に、当該情報送信装置を当該グループに参加する中継情報の送信元として許容し、該情報送信装置から送信される中継情報をミキシング処理の対象とするミキシング参加制御手段を有する構成となる。
【００２７】
このような構成により、情報送信装置からミキサ装置に対してグループへの参加要求があると、ミキサ装置は、当該情報送信装置が中継情報の送信元として許容し、該情報送信装置からの中継情報をミキシング処理の対象としてミキシング処理を実行する。
【００２８】
また、本発明に係るライブ中継システムは、少なくともビデオ情報を含む複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力する複数の第１ミキサ装置と、前記複数の第１ミキサ装置に対して設定されるミキシング処理の対象となる中継情報の送信元のグループに参加し、当該第１ミキサ装置にミキシング処理の対象となる中継情報を送る複数の情報送信装置と、ミキシング処理の対象となるミキシング中継情報の送信元のグループとして設定し、前記複数の第１ミキシング装置を、ミキシング処理の対象となるミキシング中継情報の送信元のグループに参加するミキシング中継情報の送信元として許容し、当該複数の第１ミキサ装置からのミキシング中継情報をミキシング処理して統合されたミキシング中継情報を出力する第２ミキサ装置とを有する構成となる。
【００２９】
このような構成により、複数の第１ミキサ装置それぞれでの複数の情報送信装置からの複数種の中継情報に対するミキシング処理によりミキシング中継情報が得られ、それら複数の第１ミキサ装置にて得られた複数種のミキシング中継情報が第２ミキサ装置にてミキシング処理され、統合されたミキシング中継情報が得られる。
【００３０】
また、本発明に係るライブ中継システムは、少なくともビデオ情報を含む中継情報を送信する複数の情報送信装置と、所定のネットワーク上に配置され、複数種の中継情報のミキシング処理を行って該ミキシング処理により得られるミキシング中継情報を出力するミキサ装置と、前記ミキシング装置でのミキシング処理の遠隔操作を行う操作装置とを有し、前記複数の情報送信装置のそれぞれは、予め設定されたミキシング処理の対象となる中継情報の送信元のグループへの参加要求を前記操作装置に送るソースグループ参加要求制御手段を有し、前記グループへの参加要求を行った後に前記操作装置により当該グループに参加する中継情報の送信元として許容され、前記ミキサ装置は、前記グループに参加する中継情報の送信元として許容された複数の情報送信装置からの中継情報を、前記操作装置での遠隔操作に従ってミキシング処理するグループミキシング処理手段と、該グループミキシング処理手段により得られたミキシング中継情報を前記操作装置に送る出力制御手段とを有する構成となる。
【００３１】
このような構成により、情報送信装置から操作装置に対してグループへの参加要求があると、操作装置により当該情報送信装置が前記グループに参加する中継情報の送信元として許容され、該情報送信装置からの中継情報が操作装置での遠隔操作に従ってミキシング処理され、当該ミキシング処理により得られたミキシング中継情報が操作装置に送信される。これにより、操作装置では、ミキシング中継情報を確認しつつ複数種の中継情報のミキシング処理を遠隔操作することができる。
【００３２】
本発明に係るライブ中継システムにおいて、前記操作装置は、前記グループを設定するソースグループ設定手段を有する構成とすることができる。
【００３３】
このような構成により、ミキサ装置を遠隔操作する操作装置により、当該ミキサ装置でのミキシング処理の対象となる中継情報の送信元のグループを自由に設定することができる。
【００３４】
本発明に係るライブ中継システムにおいて、前記複数の情報送信装置のそれぞれは、前記グループからの退出要求を前記操作装置に送るソースグループ退出要求制御手段を有し、前記操作装置は、ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があった場合に、当該情報送信装置をミキシング処理の対象となる中継情報の送信元から外すミキシング退出制御手段を有する構成とすることができる。
【００３５】
このような構成により、ミキシング処理の対象となる中継情報の送信元となる情報送信装置から前記グループからの退出要求があると、当該情報送信装置がミキシング処理の対象となる中継情報の送信元から外されて、該情報送信装置からの中継情報のミキシング処理が行われなくなるので、キシング処理の対象となる中継情報の送信元を容易に減らすことのできるようになる。その結果、ミキシング処理の対象となる中継情報の送信元の数を動的に増減させることができるようになる。
【００３６】
本発明に係るライブ中継システムにおいて、前記ネットワーク上に配置され、当該ネットワーク上に配置された複数のミキサ装置のいずれかを前記操作装置による遠隔操作の対象となる前記ミキサ装置として割り付ける制御装置を有する構成とすることができる。
【００３７】
このような構成により、ミキシング処理の負荷を考慮して複数のミキサ装置から適切なミキサ装置を操作装置に割り付けることができる。
【発明の効果】
【００３８】
本発明に係るミキサ装置及びライブ中継システムによれば、情報送信装置からグループへの参加要求があると、当該情報送信装置が中継情報の送信元として許容され、該情報送信装置からの中継情報がミキシング処理の対象となってミキシング処理されるので、前記グループに参加するミキシング処理の対象となる中継情報の送信元を容易に増やすことができる。
【図面の簡単な説明】
【００３９】
【図１】本発明の第１の実施の形態に係るライブ中継システムを示す図である。
【図２】本発明の第１の実施の形態に係るライブ中継システムの基本構成例を示すブロック図である。
【図３】カスケード接続された複数のミキサ端末（ミキサ装置）を含むライブ中継システムの第１の基本構成例を示すブロック図である。
【図４】カスケード接続された複数のミキサ端末を含むライブ中継システムの第２の基本構成例を示すブロック図である。
【図５】ライブ中継システムにおけるソースグループの登録及び該ソースグループへの参加に際してのメッセージフローを示す図である。
【図６】ライブ中継システムにおけるストリームノードとストリームコネクションの確率／解放に際してのメッセージフローを示す図である。
【図７】ミキサ端末の機能構成例を示すブロック図である。
【図８】ミキサ端末での表示に係るビューワの構成例を示す図である。
【図９】ミキサ端末におけるプレビューワ及びミキシングビューワの構成例を示す図である。
【図１０】ミキサ端末における操作GUIの画面イメージの一例を示す図である。
【図１１】第１の実施の形態に係るライブ中継システムの評価実験環境を示すブロック図である。
【図１２】単一のミキサ端末を用いた評価実験用のライブ中継システムの基本構成例を示す図である。
【図１３】カスケード接続される複数のミキサ端末を用いた評価実験用のライブ中継システムの基本構成例を示す図である。
【図１４】ミキサ端末におけるＣＰＵの利用率及び出力フレームレートについての評価実験結果を示す図である。
【図１５】ミキサ端末におけるＣＰＵの利用率及び出力フレームレートについての他の評価実験結果を示す図である。
【図１６】中継サーバを経由した送信端末（情報提供装置）とミキサ端末との間の遅延についての評価実験結果を示す図である。
【図１７】中継サーバ用いない状態での送信端末とミキサ端末との間の遅延についての評価実験結果を示す図である。
【図１８】単一のミキサ端末を有するシステムにおけるミキサ端末のＣＰＵの利用効率についての評価実験結果を示す図である。
【図１９】単一のミキサ装置を有するすステムにおけるミキサ装置の出力フレームレートについての評価実験結果を示す図である。
【図２０】単一のミキサ装置を有するシステムにおけるミキサ端末と送信端末との間の遅延時間についての評価実験結果を示す図である。
【図２１】カスケード接続される複数のミキサ端末を有するシステムにおけるミキサ端末と送信端末との間の遅延時間についての評価実験結果を示す図である。
【図２２】本発明の第２の実施の形態に係るライブ中継システムの第１の構成例（パブリックビューイングを想定）を示す図である。
【図２３】本発明の第２の実施の形態に係るライブ中継システムの第２の構成例（プライベートビューイングを想定）を示す図である。
【図２４】ライブ中継システムにおけるソースグループの登録、ミキササーバの選択及びソースグループへの参加に際してのメッセージフローを示す図である。
【図２５】第１の構成例（パブリックビューイング）のライブ中継システムにおけるストリームノードの接続状態を示す図である。
【図２６】第２の構成例（プライベートビューイング）のライブ中継システムにおけるストリームノードの接続状態を示す図である。
【図２７】ミキサ部（ミキサストリームノード）の遠隔操作機能について示す図である。
【図２８】ミキササーバにおいてビデオのミキシング機能を実現させるフィルタグラフの構成例を示すブロック図である。
【図２９】ミキササーバにおいてオーディオのミキシング機能を実現させるフィルタグラフの構成例を示すブロック図である。
【図３０】利用者端末における表示に係るビューワの構成例を示す図である。
【図３１】利用者端末におけるミキシング操作用GUIのコンポーネントの画面の構成例を示す図である。
【図３２】第２の実施の形態に係るライブ中継システムの第１の構成例（パブリックビューイング）の評価実験環境を示すブロック図である。
【図３３】第２の実施の形態に係るライブ中継システムの第２の構成例（プライベートビューイング）の評価実験環境を示すブロック図である。
【図３４】ミキササーバにおけるCPUの利用率についての評価実験結果を示す図である。
【図３５】ミキサストリームノードの出力フレームレートについての評価実験結果を示す図である。
【図３６】送信端末とミキササーバとの間の往復遅延についての評価実験結果を示す図である。
【図３７】利用者端末からミキササーバを操作した際の応答遅延についての評価実験結果を示す図である。
【図３８】中継サーバの入力スループットについての評価実験結果を示す図である。
【図３９】中継サーバの出力スループットについての評価実験結果を示す図である。
【図４０】ミキササーバのCPUの利用率の送信端末の数に対する予測特性（多項式近似）を示す図である。
【発明を実施するための形態】
【００４０】
以下、本発明の実施の形態について図面を用いて説明する。
【００４１】
本発明の第１の実施の形態に係るミキサ装置が適用されるライブ中継システムの基本的な構成は図１に示されるようになっている。
【００４２】
図１に示すライブ中継システムにおいて、ミキサ端末１０（Mixer Terminal：ミキサ装置）は、複数（例えば４台）の送信端末２０（Source Terminal：情報送信装置）のそれぞれが送信するストリームデータを受信し、ミキシングや切り替え処理を行う。ミキサ端末１０は、そのミキシングや切り替えにより得られた映像出力や音声出力（ミキシング中継情報）をライブ中継用サービスサイト６０へ送信する（出力制御手段）。そして、最終的に複数の受信端末３０（Sink Terminal）においてライブ中継用サービスサイト６０から提供されるそれら映像及び音声の視聴可が能となる。
【００４３】
ミキサ端末１０は、ビデオカメラとマイクロフォンに加えて、ネットワーク２００経由のストリームを入力として扱う。キャプチャデバイスからの入力を処理するためには、通常、キャプチャデバイスと端末を予め物理的に接続しておく必要がある。一方、ネットワーク２００経由のストリームをミキサ端末１０の入力として扱う際は、有線／無線を問わず、ストリーム用の論理的なコネクション（ストリームコネクション）を確立して利用する。予め物理的な接続をしておく形態の入力と異なり、必要な時にストリームコネクションを確立してミキサ端末１０の入力として扱う機能が実現し易い。複数の送信端末２０のそれぞれは、ビデオカメラとマイクロフォンからの入力データをリアルタイムに圧縮してミキサ端末１０へ送信する。ここで、送信端末２０からミキサ端末１０へストリームコネクションを直接確立できる場合は直接ストリームの転送を行う。一方、送信端末２０とミキサ端末１０が異なるプライベートネットワークに繋がっていて、ストリームコネクションを直接確立できないなどの場合も考慮し、ネットワーク２００内の中継サーバ５０（Relay Server）経由でストリーム転送できるような仕組みとなっている。
【００４４】
そして、ミキサ端末１０への入力となるストリーム数の増減に対応するために、ミキサ端末１０はライブ中継実施時に論理的なソースグループを設定（ソースグループ設定手段）し、送信端末２０のそれぞれはそのグループに参加したうえでビデオの送信を行う。図２は、ソースグループ（Source Group：ＳＧＰ）を含むシステムの基本構成を示している。ミキサ端末１０が設定するソースグループＳＧＰには、送信端末２０及び前段のミキサ端末１０のそれぞれが任意の時間に参加／退出できる。ソースグループＳＧＰに参加している端末２０、１０（Ｓ、Ｍ）からのストリームを中継サーバ５０経由で受信したミキサ端末１０は、ミキシング処理後のストリームを出力する。その出力先は、後段のミキサ端末またはライブ中継用のソフトウェアとなる。また、ソースグループＳＧＰ内の端末２０、１０（Ｓ、Ｍ）とミキサ端末１０間で直接ストリームコネクションを確立できる場合は、中継サーバ５０による中継処理が省略される。
【００４５】
図２に示す基本構成をもとに、カスケードミキサの構成例を図３と図４に示す。
【００４６】
図３に示す構成例では、ミキサ端末１０（M0：第２ミキサ装置）が設定したソースグループＳＧＰ（M0）に、ミキサ端末１０（M1）〜１０（Mn）（第１ミキサ装置）が参加している。また、ミキサ端末１０（M1）〜１０（Mn）のそれぞれもソースグループＳＧＰ（M1）〜ＳＧＰ（Mn）を設定しており、各ソースグループＳＧＰ（M1）、・・・、ＳＧＰ（Mn）には複数の送信端末２０が参加している。ミキサ端末１０（M0）とミキサ端末１０（M1）〜１０（Mn）のそれぞれはストリームコネクションを直接確立できるネットワークに繋がっている一方、ミキサ端末１０（M1）〜１０（Mn）と各ソースグループＳＧＰ（M1）〜ＳＧＰ（Mn）内の送信端末２０（S）間には中継サーバ５０（R1）〜５０（Rn）が必要なネットワーク構成となっている。この構成例は、ソースグループＳＧＰを意味的に分ける場合を想定している。例えば、スポーツの試合において特定の選手毎にソースグループＳＧＰを用意し、マルチアングルで撮影した複数のビデオを、ミキサ端末１０（M0）とミキサ端末１０（M1）〜１０（Mn）が設置されている場所に集め、各ミキサ操作者がミキシング処理を行うような場合である。
【００４７】
図４に示す例でも図３に示す例と同様に、ミキサ端末１０（M0）が設定したソースグループＳＧＰ（M0）へミキサ端末１０（M1）〜１０（Mn）が参加し、ミキサ端末１０（M1）〜１０（Mn）のソースグループＳＧＰ（M１）〜ＳＧＰ（Mn）のそれぞれに複数の送信端末２０が参加している。図３に示す構成と異なり、ミキサ端末１０（M0）とミキサ端末１０（M1）〜１０（Mn）の間には中継サーバ５０があり、ミキサ端末１０（M1）〜１０（Mn）と各ソースグループＳＧＰ内の送信端末２０間はストリームコネクションを直接確立できるネットワーク構成となっている。この構成例は、ソースグループを物理的に分ける場合を想定している。例えば、長い列を作る祭りを中継する際、その祭りの中継ポイントとなる複数の地点毎にソースグループＳＧＰを用意する場合である。中継ポイント毎にミキサ端末１０（M1）〜１０（Mn）のミキサ操作者は複数のビデオソースをミキシングしたり切り替えたりした結果を物理的に離れたミキサ端末１０（M0）へネットワーク２００上の中継サーバ５０経由で送信し、ミキサ端末１０（M0）で最終的なライブ中継用のストリームを作ることが可能となる。
【００４８】
つづいて、ソースグループＳＧＰを構成するためのメッセージフローを図５に示す。
【００４９】
まず、ミキサ端末１０は、ソースグループ登録要求メッセージ（Register Source Group Request）をネットワーク２００中に含まれる中継サーバ５０へ送り（１）、ソースグループＳＧＰに関する情報を表すソースグループプロパティを中継サーバ５０へ登録する（ソースグループ設定手段）。ソースグループプロパティには、そのソースグループＳＧＰがどのようなライブ中継用のソースグループなのかを説明するテキストが含まれている。また必要に応じて、そのソースグループＳＧＰに参加できる利用者のIDを含めることもできる。前記ソースグループプロパティを登録した中継サーバ５０は、その応答（Response）メッセージを当該ソースグループプロパティの送信元のミキサ端末１０に送る（２）。
【００５０】
一方、送信側の端末（送信端末２０（S）または前段のミキサ端末１０（M））は、ソースグループプロパティ要求メッセージ（Source Group Property Request）を中継サーバ５０へ送信する（３）。ソースグループプロパティ要求メッセージ（Source Group Property Request）を受信した中継サーバ５０は、その応答として、登録されたソースグループプロパティのリストを前記送信側の端末（２０（S）、１０（M））に送る（４）。これにより、送信側の端末（２０（S）、１０（M））は、登録されているソースグループプロパティのリストを取得することができる。そして、送信側の端末（２０（S）、１０（M））は、例えば、操作者による操作に従って、そのリストの中から参加すべきソースグループＳＧＰを選び、ソースグループ参加要求メッセージ（Join Source Group Request）を中継サーバ５０経由でミキサ端末１０へ送る（５：ソースグループ参加要求制御手段）。ミキサ端末１０は必要に応じて利用者認証を行い、送信側の端末（２０（S）、１０（M））へ参加の可否（参加許可または参加拒否）の応答メッセージを送り返す（６：可否応答制御手段）。
【００５１】
また、図５には示されていないが、送信側の端末（２０（S）、１０（M））が、ソースグループＳＧＰから退出する際は、送信側の端末（２０（S）、１０（M））から中継サーバ５０経由でミキサ端末１０へ、ソースグループ退出要求メッセージ（Leave Source Group Request）を送る（ソースグループ退出要求制御手段）。ミキサ端末１０は、送信側の端末（２０（S）、１０（M））の退出による終了処理を行い、送信側の端末（２０（S）、１０（M））へ中継サーバ５０経由でソースグループ退出応答メッセージ（Leave Source Group Response）を送り返す。
【００５２】
さらに、ライブ中継を終了する等、ミキサ端末１０がソースグループＳＧＰを必要としなくなった場合、ミキサ端末１０はソースグループ登録解除要求メッセージ（Unregister Source Group Request）を中継サーバ５０へ送る。中継サーバ５０ではソースグループＳＧＰの登録解除処理を行い、ソースグループ登録解除応答メッセージ（Unregister Source Group Response）をミキサ端末１０に送る。
【００５３】
なお、図５において、ソースグループＳＧＰを設定するミキサ端末１０と送信側の端末（２０（S）、１０（M））との間でストリームコネクションを直接確立できるネットワーク構成の場合は、メッセージのやり取りに関して中継サーバ５０を必要とせず、ソースグループ登録要求メッセージ（Register Source Group Request）（１）とその応答メッセージ（Response）（２）は省略され、ソースグループ登録解除要求メッセージ（Unregister Source Group Request）とソースグループ登録解除応答メッセージ（Unregister Source Group Response）も省略される。 
【００５４】
前述したように送信側の端末（２０（S）、１０（M））がミキサ端末１０からの参加許可の応答メッセージを受信してソースグループＳＧＰへ参加すると、その端末はミキサ端末１０へストリームを送信できる状態となり、ミキサ端末１０は、当該送信側の端末（２０（S）、１０（M））から送信されるストリームをミキシング処理の対象とするようになる（ミキシング参加制御手段）。一方、ミキサ端末１０は、送信側の端末（２０（S）、１０（M））からのソースグループ退出要求メッセージ（Leave Source Group Request）に応答して、ソースグループ退出応答メッセージ（Leave Source Group Response）を送ると、当該送信側の端末（２０（S）、１０（M））をミキシング処理の対象となるストリームの送信元から外し、以後、当該端末からのストリームのミキシング処理を行わない（ミキシング退出制御手段）。
【００５５】
図６は、送信側の端末（２０（S）、１０（M））がソースグループＳＧＰに参加した際における、ストリーム処理を行うストリームノードと、ストリームノードを繋ぐストリームコネクションの確立／解放に必要となるメッセージフローを示している。本実施の形態に係るライブ中継システムにおいて、ストリームノードはビデオまたはオーディオストリームの入出力を伴うストリーム処理機能の単位である。ストリームノード間を接続しているのがストリームコネクション（Stream Connection）であり、ストリームノードとストリームコネクションの一連のまとまりをフローパス（Flow Path）と呼ぶ。
【００５６】
送信側の端末（２０（S）、１０（M））からミキサ端末１０までのストリームコネクションの確立と解放手順を、図６のメッセージフローに従って説明する。
【００５７】
図６において、まず、送信側の端末（２０（S）、１０（M））は、ストリーム送信を行うソースストリームノード（Source Stream Node：src）を生成する。次に、送信側の端末（２０（S）、１０（M））は、中継ノードセットアップ要求メッセージ（Setup Relay Node Request）を中継サーバ６０へ送り（１）、中継サーバ５０は、内部に中継処理のみを行う中継ストリームノード（Relay Stream Node：rly）を生成する。中継サーバ５０は、中継ストリームノード（rly）を生成すると、フローパス更新メッセージ（Flow Path Update [+]）を送信側の端末（２０（S）、１０（M））へ送信する（２）。そして、送信側の端末（２０（S）、１０（M））と中継サーバ５０間でストリームコネクションが確立される（Establishes Stream Connection）。ストリームコネクションの確立が終了すると、中継サーバ５０は中継ノードセットアップ応答メッセージ（Setup Relay Node Response）を送信側の端末（２０（S）、１０（M））へ送り返す（３）。その後、中継サーバ５０は、ソースノード更新レポートメッセージ（Source Node Update Report）をミキサ端末１０へ送ることにより、ビデオソースが追加されたことをミキサ端末１０へ通知する（４）。
【００５８】
ソースノード更新レポートメッセージ（Source Node Update Report）を受信したミキサ端末１０は、フローパス更新メッセージ（Flow Path Update [+]）を中継サーバ５０経由で送信側の端末（２０（S）、１０（M））へ送信し（５、６）、中継サーバ５０とミキサ端末１０間のストリームコネクションが確立される（Establishes Stream Connection）。ミキサ端末１０内には、ミキシング処理を行うミキサストリームノード（Mixer Stream Node：mix）が生成されるとともにその前段に中継ストリームノード（rly）が生成される。中継サーバ５０内の中継ストリームノード（rly）はストリーム用のパケットを中継するが、ミキサ端末１０内の中継ストリームノード（rly）は、ミキサ端末１０の入力となるビデオまたはオーディオデータを端末１０内のミキサストリームノード（mix）へ直接渡す。
【００５９】
上述した手順に従って送信側の端末（２０（S）、１０（M））と中継サーバ５０を介したミキサ端末１０との間のストリームコネクションが確立すると、送信側の端末（２０（S）、１０（M））のソースストリームノード（src）で生成されるストリームデータ（ビデオ、オーディオ）の中継サーバ５０の中継ストリームノード（rly）を介したミキサ端末１０への提供が可能になる。ミキサ端末１０では、入力したストリームデータが中継ストリームノード（rly）を介してミキサストリームノード（mix）に提供され、当該ストリームデータのミキシング処理がなされてそのミキシング処理により得られた映像や音声が出力される。
【００６０】
一方、前記ストリームコネクションの解放時のメッセージフローは、図６の手順７〜１１に従ってなされる。
【００６１】
即ち、ストリームコネクションの解放操作のなされた送信側の端末（２０（S）、１０（M））は、ソースストリーム閉鎖メッセージ（Close Source Stream）を中継サーバ５０経由でミキサ端末１０へ送信する（７、８）。これにより、送信側の端末（２０（S）、１０（M））につながるミキサ端末１０と中継サーバ５０との間のストリームコネクションが解放（Shutdowns Stream Connection）され、ミキサ端末１０は、フローパス更新メッセージ（Flow path Update [-]）を中継サーバ５０経由で送信側の端末（２０（S）、１０（M））に送信する（９、１０）。これにより、中継サーバ５０とストリームコネクションの解放操作のなされた送信側の端末（２０（S）、１０（M））との間のストリームコネクションが解放され（Shutdown Stream Connection）、中継サーバ５０内の当該送信側の端末（２０（S）、１０（M））のための中継ストリームノード（rly）が削除される（Deletes Relay Node）。中継ストリームノード（rly）が削除されると、中継サーバ５０は、フローパス更新メッセージ（Flow Path Update [-]）を当該送信側の端末（２０（S）、１０（M））に送信する（１１）。それにより、フローパスが更新される。
【００６２】
ここまで、図６のメッセージフローに従って、送信端末側（２０（S）、１０（M））からストリームコネクションを確立／解放する流れを示したが、ミキサ端末１０側から確立／解放を行う場合は、フローパス更新メッセージ（Flow Path Update [+/-]）を利用する。図６において、ソースノード更新レポートメッセージ（Source Node Update Report）を受信したミキサ端末１０では、そのソースストリームノード（src）からの中継を自動的または選択的に受信することができる。受信する場合は、フローパス更新メッセージ（Flow Path Update [+]）を中継サーバ５０へ送り、ストリームコネクションを確立する。一方、ミキサ端末１０側からストリームコネクションを解放する場合は、ストリームコネクションを解放した後にフローパス更新メッセージ（Flow Path Update [-]）を中継サーバ５０に送る。
【００６３】
本実施の形態に係るライブ中継システムでは、フローパス（Flow Path）とストリームコネクション（Stream Connection）を論理的に分けて管理することにより、局所的な通信断と復帰にも柔軟に対応できる。想定しているライブ中継では、送信端末２０が移動することも考慮している。例えば、送信端末２０がネットワーク２００へ無線で繋がっている場合、突然の通信断へ対応できる仕組みが必要となる。そこでフローパス（Flow Path）が確立されていれば、ストリームコネクション（Stream Connection）の一部で一時的な通信断が発生したとしても、該当箇所のストリームコネクション（Stream Connection）のみを接続し直すことが可能な設計とした。ここで、ストリームコネクション（Stream Connection）の一時的な切断後、一定時間以上再接続が行われない場合は、中継ストリームノード（rly）とフローパス（Flow Path）は解放される。また、ストリームコネクション（Stream Connection）が確立されていても、何らかの原因により送信端末２０側からのストリームデータをミキサ端末１０で受信できない場合も、中継ストリームノード（rly）とフローパス（Flow Path）を解放する。受信側のストリームノードでは、送信側のストリームノードに対して定期的に受信状況を報告するが、送信側ではその報告を受けていない時間を計測し、受信側ではストリームデータを受信していない時間を計測している。これらの時間に閾値を設け、その閾値を超えた場合、送信側または受信側からフローパス（Flow Path）を解放する。その際、ストリームコネクション（Stream Connection）が確立されていれば、ストリームコネクション（Stream Connection）を解放した後にフローパス（Flow Path）を解放する。正常な処理としては、図６に示すフローパス更新メッセージ（Flow Path Update [-]）によりフローパスは解放されるが、メッセージ用のコネクションが利用できない状況も考慮し、送信側と受信側それぞれでタイムアウトによるフローパス（Flow Path）の解放が行われる。
【００６４】
ミキサ端末１０における中継ストリームノード（rly）とミキサストリームノード（mix）の機能モジュール構成を図７に示す。ミキサ端末１０への入力の動的な増減へ対応するため、ミキサストリームノード（mix）では入力用のリングバッファ１３（Ring Buffer）の追加／削除を可能としている。リングバッファ１３（Ring Buffer）は、ミキサストリームノード１２（mix）の入力となる中継ストリームノード１１（rly）毎に生成される。中継ストリームノード１１（rly）では、パケット受信部１１１（Packet Receiver/Depacketizer）が受信したパケットからビデオフレームデータまたはオーディオサンプルデータを作り、それをデコーダ１１２（Decoder）がデコードする。その後、デコードされたデータをプレビューワ１１３（Previewer）によりプレビュー表示すると共に、リングバッファ１３（Ring Buffer）へもデータをコピーする。ミキサストリームノード１２（mix）内ではオーディオ・ビデオミキサモジュール１２１（Audio Video Mixer）がリングバッファ１３（Ring Buffer）からデータを読み込み、ミキシング処理を行い、その結果をミキシングビューワ１２２（Mixing Viewer）に表示させる。
【００６５】
ミキシング処理後のデータを、さらに後段のミキサ端末１０へ送信する場合は、エンコーダモジュール１２３（Encoder）によりエンコードされたデータがパケット送信部１２４によりパケットに分割され、送信される。一方、ミキシング処理後のデータをライブ中継用ソフトウェアやライブ中継用サービスサイトへ送信する場合は、ストリーム・エクスポートモジュール１２５（Stream Exporter）を利用する。
【００６６】
ミキシング操作は、ミキサストリームノード（mix）のミキサ制御インタフェース１４（Mixer Control Interface）を通して行われる。ビデオをタイル状に並べるタイルビュー（Tiled View）と、縦または横に並べるボックスビュー（Box View）をレイアウトの基本とし、そのレイアウトを切り替える機能も実現する。図８は、ミキサ端末１０上でミキシング操作をする際の空間的な配置の例を示している。中継ストリームノード（rly）でデコード（Decoder）されたビデオデータはプレビューワ１１３（Previewer）上に自動的にプレビュー表示されると共に、ミキシング処理の入力データとして利用可能な状態になる。ミキサ端末１０の操作者は、プレビューワ１１３（Previewer）に表示されたビデオを確認し、必要に応じてミキシングビューワ１２２（Mixing Viewer）上でミキシング処理の対象とすることができる。ミキシングビューワ１２２は、背景を表示する背景層（Background Layer）上にタイルビュー層（Tiled View Layer）とボックスビュー層（Box View Layer）とが重なる３層構造となっている。ボックスビュー層（Box View Layer）は、タイルビュー層（Tiled View Layer）上でピクチャ・イン・ピクチャ（Picture-in-Picture）の機能を提供する層である。
【００６７】
中継ストリームノード（rly）が削除された場合は、ビューワにおける表示も自動的に除去されて背景が表示される。ライブ中継の内容にもよるが、予測が困難な原因による中継ストリームノード（rly）の削除が発生することを想定すると、今まで表示されていたビデオが突然背景表示に変わることは望ましくない。一方、数秒間のビデオの停止は許容できることがある。これらを考慮し、中継ストリームノード（rly）の削除時には、最後に表示していたビデオフレームを一定時間表示させる。その時間は設定値として与える。この機能により、中継ストリームノード（rly）の削除後、背景が表示されるまでの間に、ミキサ端末１０の操作者にはミキサを操作する時間的な余裕ができる。
【００６８】
以上、本発明の第１の実施の形態に係るミキサ装置（ミキサ端末１０）及びライブ中継システムの機能について述べた。引き続き、プロトタイプシステムの実装についてまとめる。
【００６９】
複数ビデオソースの動的な構成を可能とするミキサ装置に対して、実機を用いた機能的な検証を行うため、Windows 7（登録商標）を搭載した汎用PC上にプロトタイプシステムを実装した。
【００７０】
＜メッセージ通信と利用者認証＞
提案するプロトタイプのライブ中継システムは分散システムであり、システムを構成する各端末は、図５と図６に示したメッセージを含む多くのメッセージを相互にやりとりする必要がある。プロトタイプシステムでは、TCP上にテキストベースの簡単なメッセージプロトコルを実装した。また、送信側の端末（Ｓ、Ｍ）がソースグループへ参加する際には、必要に応じて利用者認証を行えるよう、企業内ネットワーク等で利用されているLDAP（Lightweight Directory Access Protocol）を用いた利用者認証機能を適用した。プロトタイプシステムではWindows（登録商標）用のOpen LDAP（非特許文献４参照）を中継サーバ５０またはミキサ端末１０上で動作させ、メッセージ通信用のTCPコネクションを確立する際に、利用者認証を可能としている。
【００７１】
＜ストリームノードおよびミキサの実装＞
各ストリームノードは、既存システム（非特許文献５参照）のストリーミング機能を改良して実装した。ビデオとオーディオの伝送にはRTPを基本とした簡易ストリーミングプロトコルを、TCPまたはUDP上で動作するよう実装し、ストリームノード内部におけるメディア処理にはDirect Show（非特許文献６参照）を用いている。ビデオおよびオーディオのミキシング機能も既存システム（非特許文献５参照）におけるミキシング機能を改良して実装した。非特許文献５記載のミキサは、図８に示す３層構造には対応していない。また、入力の動的な追加／削除機能も実装されていないので、動的に追加／削除可能かつスレッドセーフなリングバッファをミキサの入力として繋ぐ仕組みを新たに実装した。図７に示すオーディオ・ビデオミキサ１２１（Audio Video Mixer）は、リングバッファ１３から一定間隔（評価実験では、ビデオは1/30sec.、オーディオは1/25sec.）でビデオとオーディオのデータを取得する。その際、時間的な揺らぎを吸収するため、リングバッファ１３内でバッファリング（ビデオは2/30sec.、オーディオは2/25sec.）を行っており、その分はミキシング処理の遅延となる。一方、ミキサ端末１０の入力となる中継ストリームノード（rly）とミキサストリームノード（mix）におけるミキシング処理を異なるスレッドに分けることにより処理の並列性を高めている。また、ビデオデータのミキシングの際は、ビデオデータをRGB（各8bit、計24bit/pixel）に統一し、オーディオデータはPCM（サンプリング周波数48kHz、量子化ビット数16bit）に統一した入力データをミキシングしている。
【００７２】
また、図７におけるストリーム・エクスポートモジュール１２５（Stream Exporter）では、ローカルTCPコネクションを用いて、ビデオとオーディオデータを他のプロセス（Another Process for Live Video streaming）へ渡す仕組みを実装した。プロトタイプシステムでは、ライブ配信ソフトウェアの１つとしてMicrosoft （登録商標）Expression Encoder 4（非特許文献７参照）を想定し、Microsoft （登録商標）Expression Encoder 4における入力として利用できるDirectShowのソースフィルタも実装した。そのソースフィルタとストリーム・エクスポートモジュール１２５（Stream Exporter）間でローカルTCPコネクションを確立し、ミキシングされたビデオとオーディオデータをMicrosoft （登録商標）Expression Encoder 4の入力としている。
【００７３】
＜ビューワと操作用GUI＞
ビューワと操作用のGUIは、Java言語を用いて実装した。図８で示したプレビューワ１１３（Previewer）とミキシングビューワ１２２（Mixing viewer）を、図９に示す通り実現した。タイルビュー層（Tiled View Layer）では、列と行を任意の数に変更したり、表示区画をまとめたりすることができる。ボックスビュー層（Box View Layer）では、縦また横に並べたビデオをまとめて、配置位置を変更したり大きさや透明度を変更したりすることが可能である。図１０はミキシング操作用GUIの画面イメージである。図７におけるミキサ制御インタフェース１４（Mixer Control Interface）を用いて、ビデオ（Video Mixer）に関してはタイルビュー（Tiled View）およびボックスビュー（Box View）の操作とレイアウトの切り替えが可能であり、オーディオ（Audio Mixer）に関しては音量調整が可能である。
【００７４】
Windows（登録商標）以外のプラットフォームへの移植も考慮し、GUIはJava言語を用いている一方、ストリームの送受信やミキシング処理には、パフォーマンスを上げるためC言語およびC++言語を用いて実装している。ここで、C/C++側のメモリ領域で処理しているビデオデータをJava側のGUIコンポーネント上で表示するためには、通常、大量のメモリコピーが発生する。これを回避するために、プロトタイプシステムではAWT Native Interface（非特許文献８参照）を用いた。AWT Native InterfaceによりJavaのGUIコンポーネントに内包されているWindows（登録商標）のネイティブなウィンドウハンドラをC/C++側で扱うことが可能となる。プロトタイプシステムでは、C/C++側のDirectShowの画面描画用フィルタで処理されたビデオデータを、効率良くJavaのGUIコンポーネント上で表示している。
【００７５】
図１１に示す実験環境において、図１２と図１３に示す構成でライブ中継システムの評価実験を行った。
【００７６】
図１２に示す単一構成では、ミキサ端末１０（M0）がソースグループを設定し、そのソースグループに参加した送信端末２０（S0〜S9）からのストリームを中継サーバ５０（R）経由でミキサ端末１０（M0）が受信し、ミキシング処理を行った。また、ミキシングしたストリームデータをミキサ端末１０（M0）内で動作しているMicrosoft （登録商標）Expression Encoder 4へ送り、最終的に利用者端末４０（U）内のWindows （登録商標）Media Playerで再生表示できることを確認した。この構成では、送信端末２０（S0〜S9）がそれぞれビデオストリームとオーディオストリームを1本ずつ送信した場合の、ミキサ端末１０（M0）におけるCPU利用率と出力フレームレート、および送信端末２０とミキサ端１０末間の遅延を測定した。
【００７７】
一方、図１３のカスケード構成ではミキサ端末１０（M0）がソースグループを設定し、そのソースグループに参加した前段のミキサ端末１０（M1〜M3）からのストリームを中継サーバ５０（R）経由でミキサ端末１０（M0）が受信し、ミキシング処理を行った。ミキサ端末１０（M1〜M3）は、それぞれ送信端末２０（S0~S9）からのストリームを直接受信してミキシング処理を行った。この構成は、図４に示したカスケードミキサの構成における前段のミキサ端末１０を３台としたものである。実際のライブ中継としては、長い列を作り行進するような祭りにおいて、その行進開始地点と終了地点および中間地点を中継元とした場合の３地点を想定している。ここで、送信端末２０は１０台であるが、実験では送信端末２０から複数本のストリームを送出することで、ミキサ端末１０（M1〜M3）への入力ストリーム数を確保した。１台のミキサ端末１０で処理可能な入力ストリーム数は図１２の構成における実験から明らかになるので、図１３の構成における実験では、カスケードミキサの構成における、送信端末２０（S0~S9）とミキサ端末１０（M0）間の遅延を測定した。
【００７８】
実験で用いた中継端末５０（R）とミキサ端末１０（M0、M1〜M3）のスペックとして、CPUと搭載メモリおよびNICを表1に示す。
【表１】
0006651197.tif 000002
プロトタイプシステムではミキシング処理をCPUで行っているので、ミキサ端末１０の性能はCPUの性能に依存する。評価実験を行うにあたっては、専用機器としてのミキサ端末１０のうち、比較的入手し易い機器（非特許文献９参照）と同程度の価格で入手可能なPCを用いた。ミキサ端末１０（M0、M1〜M3）は全て同型のPCである。送信端末２０（S0〜S9）としては、今回の実験で利用するビデオとオーディオストリームの送信に充分対応でき、ビデオカメラとマイクロフォンを搭載しているPCを用いた。また、送信端末２０（S0〜S9）とミキサ端末１０（M0）間の遅延を測定するに当たり、ネットワーク２００内の遅延は無視できるよう、図１１に示すように、ギガビットスイッチングハブ７０に各端末１０、２０、３０、４０、５０を接続して実験を行った。また、LANを利用しているので、中継サーバ５０を利用せずともストリームの中継は可能であるが、実際のライブ中継ではバックエンドの中継サーバ５０が必要である場合が多いことを想定し、中継サーバ５０を含めた構成としている。加えて、プロトタイプシステムのストリーミングプロトコルはTCPとUDPに対応しているが、インターネットの末端からバックエンドの中継サーバ５０を利用することを想定し、実験ではTCPを用いた。一方、中継サーバ５０の有無による遅延の比較を行うため、図１２に示す単一構成における送信端末２０とミキサ端末１０（M0）間の遅延の測定実験のみ、中継サーバ５０を利用しなかった場合の実験も行った。
【００７９】
送信端末２０から送信するビデオストリームのフォーマットは、720p（ピクセル解像度：1280×720pixel、フレームレート：30fps）および360p（ピクセル解像度：640×360pixel、フレームレート：30fps）を用いた。圧縮にはWMV（Windows （登録商標）Media Video）のCBR（Constant Bit Rate）を用い、720pの場合は4Mbps、360pの場合は1Mbpsの設定を利用した。オーディオストリームのフォーマットはPCM（チャンネル数：1、サンプリング周波数：44.1kHz、量子化ビット数：16bit、キャプチャ間隔：1/25sec.）を用いており、キャプチャしたPCMデータを圧縮せず705.6Kbpsのオーディオストリームとして利用した。また、ミキサ端末１０（M0）内で動作させたMicrosoft （登録商標）Expression Encoder 4では、実際の配信を考慮し、720pのビデオデータについてはVC-1アドバンストのエンコーダを用いてCBR 2Mbpsのストリームを生成し、360pのビデオデータについてはCBR 500Kbpsのストリームを生成した。オーディオデータについては、WMAのエンコーダを用いてCBR 64Kbpsのストリームを生成した。実際に配信をする場合は、通常、生成したビデオとオーディオのストリームを配信ポイントとなるWindows （登録商標）MediaサーバかIISスムーズストリーミングサーバーへ送信するが、実験ではミキサ端末１０（M0）から利用者端末３０（U）上のWindows （登録商標）Media Playerへストリーミング再生を行った。
【００８０】
また、プロトタイプシステムではビデオとオーディオデータにタイムスタンプが付加され、ストリーム毎に同期をとって処理される実装となっている。送信端末２０ではビデオとオーディオデータのキャプチャ時にタイムスタンプを付加しており、ミキサ端末１０ではビデオとオーディオデータをそれぞれミキシングした後にタイムスタンプを付加している。一方、現在のプロトタイプシステムでは送信端末２０間の同期は考慮していない。
【００８１】
プロトタイプシステムとして実装したミキサ端末１０の性能評価として、ミキサ端末１０（M0）におけるCPU利用率と出力フレームレート、および送信端末とミキサ端末１０間の遅延を測定した。
【００８２】
＜入力の動的な追加／削除機能＞
まず、ミキサ端末１０（M0）に対して入力を動的に追加／削除した場合の実験結果をまとめる。実験では、ミキサ端末（M0）が設定したソースグループへ送信端末２０（S0〜S9）が参加し、各送信端末２０からのビデオとオーディオストリームを１０秒毎に追加した。送信端末２０（S0〜S9）全てからのストリームをミキサ端末１０（M0）の入力として１０秒間処理した後、同じく１０秒毎にビデオとオーディオストリームを削除した。この間１秒間隔でCPU利用率とミキサ端末１０の出力フレームレートを測定し、720pと360pに分けてグラフにしたのが図１４と図１５である。グラフ左の縦軸はミキサ端末１０（M0）のCPU利用率を、グラフ右の縦軸は出力フレームレートを示している。横軸は経過時間であり、グラフの上部には送信端末２０の数を示している。前述した通り、この出力フレームレートは図１２におけるミキサストリームノード（mix）から、他プロセスとして動作しているMicrosoft （登録商標）Expression Encoder 4へのフレームレートである。また、送信端末２０とミキサ端末１０（M0）間の遅延は、送信端末２０においてビデオカメラからキャプチャしたビデオフレームのキャプチャ時刻に対して、そのビデオフレームがミキサ端末１０（M0）上のミキシングビューワで表示されるまでの時間である。図１６は中継サーバ５０を経由した場合の遅延を、図１７は中継サーバ５０を利用しなかった場合の遅延を示している。
【００８３】
図１４と図１５に示すグラフからは、入力の追加／削除に対するCPU利用率と出力フレームレートの変化の概要がわかる。CPU利用率は測定値をそのままグラフにしているのでバラつきはあるが、入力数に応じて増減していることがわかる。また、図１４からは、追加のタイミングでCPU利用率が大きく変化する傾向も見て取れる。これは、資源の確保と追加した入力に対する処理の開始による変化である。削除のタイミングでもその傾向は見受けられるが、追加のタイミングに比べると変化は少ない。一方、出力フレームレートの測定結果を見てみると、追加／削除のタイミングでフレームレートは一瞬下がる。プロトタイプシステムにおけるミキサ端末１０の実装では、図７におけるオーディオ・ビデオミキサ１２１（Audio Video Mixer）へリングバッファ１３（Ring Buffer）を追加／削除する際、中継ストリームノード（Relay Stream Node：rly）とミキサストリームノード（Mixer Stream Node：mix）それぞれのスレッド間で処理の同期をとっている。その同期処理が、出力フレームレートに影響しているものと考えられる。また、図１４に示すグラフから720pの場合は、入力数が７〜１０の区間でフレームレートにバラつきが見られる。後の実験結果として示すが、入力数７までは平均的には充分なフレームレートを確保することができる。しかし、入力数が８〜１０の区間はCPU利用率も高く、プロトタイプシステムにおけるミキサ端末の処理能力がフレームレートに影響していると考えられる。
【００８４】
次に、図１６と図１７に示すグラフからは、入力の追加／削除に対する送信端末２０とミキサ端末１０（M0）との間の遅延の変化の概要がわかる。中継サーバ５０の有無によらず720pの場合は、入力数が増えると遅延も増加傾向にあることが見て取れる。一方、360pの場合、入力数の増加による遅延の増加は顕著には現れていない。ここで、遅延の測定については中継サーバ５０を経由する場合としない場合の実験を行ったので、その結果を比較する。入力を追加／削除した全１９区間毎の平均遅延の差を求めると、360pを用いた実験では、１１区間で中継サーバ５０無しの場合の方が遅延は少なかった。720pを用いた実験では、８区間で中継サーバ５０無しの場合の方が遅延は少なかった。逆に、中継サーバ５０経由の方が平均遅延は少ない区間がある。中継サーバ５０の有無による、区間毎の平均遅延の差は±20msecの範囲であった。遅延の測定には、前述した通りビデオカメラからキャプチャしたビデオフレームのキャプチャ時刻と、そのビデオフレームがミキサ端末１０上のミキシングビューワ１２２で表示される時刻との差を求めている。従って30fpsのビデオフレームを1枚表示している時間、約33msec分の誤差が含まれる。よって、この実験における遅延測定方法では、中継サーバ５０の有無による遅延の差は測定誤差の範囲に収まる程度である。一方、全サンプルデータの標準偏差を算出したところ、360pの場合はほとんど変化が無い（中継サーバ経由: 14.1msec、中継サーバ無し: 14.8msec）が、720pの場合は中継サーバ５０経由の方が若干大きい（中継サーバ経由: 19.0msec、中継サーバ無し: 15.7msec）結果となった。720pの場合は、中継サーバ５０を経由することで若干遅延のバラつきが増えたとも考えられるが、結果としては、中継サーバ５０の有無による遅延には顕著な差は見られない。
【００８５】
以上、入力の動的な追加／削除機能の動作に合わせて、CPU利用率と出力フレームレート、および送信端末２０とミキサ端末１０（M0）間の遅延に関する実験結果をまとめた。動的な追加／削除機能を試すため、比較的短い間隔でストリームの追加と削除を行ったので、そのタイミングにおける各測定値の変化は確認できた。一方、ミキサ端末１０の入力数に対する平均的な性能を確認するためには、入力数毎の測定時間を増やし、各測定値のサンプル数を増やす必要がある。引き続き、ミキサ端末１０の入力数に対する評価実験結果をまとめる。
【００８６】
＜入力数に対するミキサの性能評価＞
先の実験同様、ミキサ端末１０（M0）が設定したソースグループへ送信端末２０（S0〜S9）が参加し、各送信端末２０はビデオとオーディオストリームを送信した。各送信端末２０からのストリームをミキサ端末１０（M0）が受信し、ミキシング処理を開始した後３分間、ミキサ端末１０（M0）のCPU利用率とフレームレート、および送信端末２０とミキサ端末１０（M0）間の遅延を測定した。CPU利用率の平均値をグラフにしたのが図１８である。図１８に示す縦軸およびグラフの下表はミキサ端末１０（M0）のCPU利用率を示しており、横軸は送信端末数を示している。また、グラフには送信端末数毎の標準偏差も合わせて示してある。同様に図１９は、出力フレームレートの平均値と標準偏差を、図２０は送信端末２０とミキサ端末１０（M0）間の遅延の平均値と標準偏差を示している。
【００８７】
720pのミキシング処理を行った場合、図１８より、送信端末２０の数が１台から８台目まではCPU利用率がほぼ単調増加している。これはデコード処理の増加によるもので、プロトタイプシステムでは、１台の送信端末２０につき約7%〜10%のCPU資源を必要とする。一方、８台目から９台目に送信端末２０が増加した際にはCPU利用率の平均で3.91%増加しているが、これは、９台目の送信端末２０から受信したストリームのデコード処理を充分に行えていないことを示している。また、送信端末２０の数が７台目以降、CPU利用率の標準偏差の幅が小さくなることも図１８から確認できる。これは、ミキサ端末１０（M0）における処理に余裕が無くなっていることを示しており、CPU利用率がほぼ単調増加していた８台目でもミキシング処理の結果である出力フレームレートに影響していることが図１９から見てとれる。図１９における720pの場合の平均出力フレームレートは、送信端末２０の数が７台目までは、ほぼ30fpsであるが、送信端末２０の８台目は29.97fpsとなる。標準偏差の幅も送信端末の数が８台目から明らかに増え、一定のフレームレートによる処理ができない状態となっている。図２０における720pの場合の送信端末２０とミキサ端末１０（M0）間の遅延を見ても、送信端末２０が７台目までは多少のばらつきはあるものの、ほぼ一定であるが、送信端末２０が８台目以降は増加していることがわかる。以上により、この実験で用いたコーデックの設定において、プロトタイプシステムのミキサ端末１０では、720pの場合、送信端末２０が７台までミキシング処理できたことがわかる。一方、360pのミキシング処理を行った場合、送信端末２０が１０台までのミキシング処理は充分可能であることが図１８〜図２０に示す実験結果より確認できる。
【００８８】
引き続き、カスケード構成の場合の、送信端末２０とミキサ端末１０（M0）間における遅延の測定結果を図２１に示す。図１３に示すカスケード構成において、後段のミキサ端末１０（M0）への入力ストリームは前段のミキサ端末１０（M1〜M3）３台分となる。これは図１８〜図２０における送信端末２０が３台の場合と同じである。一方、カスケード構成により送信端末２０とミキサ端末１０（M0）との間の遅延は単一構成の場合より増加する。どの程度の遅延が発生するかを確認するため、前段のミキサ端末１０の１つであるミキサ端末１０（M1）に対して送信端末２０の数を１台〜１０台まで変化（増加）させ、遅延の測定を行った。ここで、図７におけるミキサ端末１０の機能モジュールのうち、カスケード構成の前段のミキサ装置１０では、オーディオ・ビデオミキサ１２１（Audio Video Mixer）の出力をエンコーダモジュール１２３（Encoder）でエンコードした後、パケット化し中継サーバ５０経由で後段のミキサ端末１０宛に送信する。単一構成の場合同様、送信端末２０から受信したストリームのデコード処理とミキシング操作後のエンコード処理はCPUで行っている。前段のミキサ１０から後段のミキサ１０へ送信されるストリームのフォーマットは、送信端末２０の送信ストリームフォーマットと同じ設定としている。前段のミキサ端末１０における処理と後段のミキサ端末１０における処理はほぼ同じであり、その結果として、前段のミキサ端末１０（M1）におけるCPU負荷が、送信端末２０と後段のミキサ端末１０（M0）間の遅延にも反映される。720pの場合、図２１に示すグラフから送信端末２０が8台目まではほぼ変化しないが、送信端末２０が９台目と１０台目では、８台目までより遅延が増加していることがわかる。360pの場合は、送信端末２０が３台目までに比べて４台目以降で遅延が若干増加するが、実験した送信端末が１０台までの範囲では、顕著な遅延の増加は発生していない。
【００８９】
以上、プロトタイプシステムのライブ中継システムの性能評価として、ミキサ端末１０（M0）におけるCPU利用率と出力フレームレート、および送信端末２０とミキサ端末１０（M0）間の遅延の測定結果を示した。測定結果から、実験で用いた720pのフォーマットであれば、最大で送信端末２０が７台分のストリームを１台のミキサ端末１０で処理できることが確認できた。360pのフォーマットについては、少なくとも送信端末２０が１０台分のストリームまで処理できることも確認した。
【００９０】
また、送信端末２０とミキサ端末１０（M0）間の遅延については、単一構成の場合とカスケード構成の場合の測定結果を示した。 前述したように、中継元におけるビデオ撮影者とミキサ操作者との間でタイミングをとれる程度のエンド間遅延内でストリーミングとミキシング処理が行われる必要がある。ここで、過去に実施された遠隔会議における伝播遅延の影響の実験（非特許文献１０参照）を参照すると、往復遅延250msではほとんどの会議場面が許容されるが、500msでは一部適さない会議場面（速くてひん度の高いやりとりが要求される会議場面）が生ずる、とする一方で、討論、意見交換が主体である一般の会議では500msでもほとんど支障がない、と報告されている。この文献の実験結果を参照し、中継元におけるビデオ撮影者とミキサ操作者間のやりとりが、速くてひん度の高いやりとりではない場合を想定し、ここでは、往復遅延500msを許容値の目安とする。
【００９１】
プロトタイプシステムを用いた実験では、送信端末２０からミキサ端末１０（M0）までの片方向の遅延を測定しているので、単純に500msの半分の250msを許容値とすると、図２０から、ミキサ端末１０で処理可能なストリーム数の範囲ではこの値以下の遅延であることがわかる。しかし、カスケード構成の場合、720pのストリームでは全て250msを超えている。カスケード構成の場合でも、中継元におけるビデオ撮影者と前段のミキサ操作者間のやりとりには支障がないと考えられるが、中継元におけるビデオ撮影者と後段のミキサ操作者間でタイミングをとるためには、より遅延を少なくする工夫が必要となる。プロトタイプシステムでは時間的な揺らぎを吸収するため、リングバッファにてバッファリング（ビデオは2/30sec.、オーディオは2/25sec.）を行っているので、カスケード構成の場合はミキサストリームノードにおいて少なくとも4/25sec.（=160ms）分の遅延が発生する。片方向の遅延を250ms内に抑えるためには、ビデオ1フレーム分（対応するオーディオデータを含む）のエンド間におけるデータ処理を平均90ms以内で行う必要があることになる。実験環境はネットワーク２００の遅延をほぼ無視できる環境であることも考慮すると、遅延は可能な限り抑えられることが望ましい。前述したように、プロトタイプシステムではミキサ端末１０の入力となる中継ストリームノード（rly）とミキサストリームノード（mix）におけるミキシング処理を異なるスレッドに分けることにより、処理の並列性を高めているが、より遅延を抑えるためには今後検討の余地がある。
【００９２】
評価実験の結果を踏まえ、ライブ配信ソフトウェア（非特許文献１２〜１４）、および専用機器として比較的入手しやすいAVミキサ（非特許文献９参照）とその上位機種（非特許文献１１参照）の機能を参照し、本実施の形態に係るシステムの機能的な考察を以下に述べる。 
【００９３】
＜入力の動的な追加／削除機能と入力数＞
本実施の形態に係るミキサ装置（ミキサ端末１０）において実現した、ミキサへの入力となるビデオソースの動的な追加／削除機能は、既存のライブ配信ソフトウェアや専用機器では実現されておらず、本実施の形態に係るシステムにおける機能の新規性を示すものである。入力として扱えるビデオソースの数は、ライブ配信ソフトウェアではPCの構成や性能および利用するビデオとオーディオのフォーマットに依存する一方、参照した専用機器では４系統のビデオ入力を扱え、その他の専用機器における主流は４系統または８系統である。プロトタイプシステムの評価結果から、本実施の形態に係るシステムでは720pの場合で７入力、360pでは少なくとも１０入力のミキシング処理が可能であることを示した。プロトタイプシステムは、ビデオソースの動的な追加／削除に対応し、既存の専用機器と同等の入力数を処理することができる。また、ソフトウェアとしてミキサ装置を実現しているので、必要に応じて高性能なPCを使用することにより、操作や設定の大きな変更無しに処理可能な入力数を増やすことも可能である。これは、入力数が固定である専用機器に対し、ソフトウェアとして動作するミキサ装置の利点である。
【００９４】
＜カスケードミキサの動的構成機能＞
専用機器をカスケード接続し、カスケードミキサとして利用することは以前より可能であるが、物理的にケーブルを用いた接続が必要であり、比較的広い範囲を想定するとカスケード接続は困難である。専用機器のミキサ機能とライブ配信ソフトウェアのミキサ機能を組み合わせて、予め物理的または論理的にカスケードミキサを構成することも可能である。しかし、ネットワーク２００経由でミキサを動的に追加／削除できる機能は、ライブ配信ソフトウェアや専用機器では実現されていない。対象としている複数の会場で同時に実施されるスポーツイベントや、神輿／山車／踊り手等が長い列を作る祭りのライブ中継を容易に実現することを考慮した場合、複数の送信端末２０とミキサ端末１０を１つの送信グループとして扱い、それを動的に追加／削除できる機能は実用性がある。
【００９５】
＜既存ストリーミングサービスを利用した配信機能＞
ライブ配信ソフトウェアは、既存のストリーミングサービスを利用した配信機能を搭載している。専用機器を用いる場合は、通常、専用機器をPCへ接続し、ライブ配信ソフトウェアを用いて既存のストリーミングサービスを利用する。通常、既存のストリーミングサービスを利用するためには、そのサービスに適合しているライブ配信ソフトウェアを用いる。本実施の形態に係るミキサ装置（ミキサ端末１０）は、ミキシング処理後のデータをプロセス間通信により既存のライブ配信ソフトウェアへ渡す機能を実現した。プロトタイプシステムではMicrosoft （登録商標）Expression Encoder 4の入力として利用可能なDirectShowのソースフィルタを実装し、接続できることを確認した。同様の仕組みにより、ビデオカメラやマイクロフォン用のデバイスドライバとしてソフトウェアモジュールを実装することで、Microsoft （登録商標）Expression Encoder 4以外の既存システムへもビデオとオーディオデータを渡すことは可能である。実装したプロトタイプシステムにより、その実現可能性を確認できた。様々な既存のライブ配信ソフトウェアから見て、本システムの出力がビデオカメラとマイクロフォンとして扱える機能の実装を今後も継続して行う。
【００９６】
本実施の形態に係るミキサ装置は、複数のビデオソースを扱うライブ中継を支援するために必要となる機能を備え、複数ビデオソースの動的な構成を可能とする。ライブ中継システムの要件としては、（1）ミキサへの入力となるビデオソースの数の動的な増減に対応できること、（2）ミキサのカスケード構成が可能であること、（3）ビデオソースからミキサまでの遅延がタイミングをとれる程度に小さいことが挙げられる。これらの要件を満たすためには、送信側の端末が任意の時間に送信するストリームを自動的にミキサ端末１０の入力とする機能と、その機能をミキサ装置間でも利用できる仕組みが必要となる。そこで、ミキサ端末１０はソースグループを設定し、送信端末２０はそのソースグループに参加した上でストリーム送信を行うためのプロトコルを設計・実装した。ソースグループに参加している送信端末２０からのストリームは、ミキサ端末１０へ自動的に中継されプレビュー表示される。ミキサ操作者は必要に応じて自動的に中継されるビデオソースに対してミキシング操作をすることが可能となる。また、既存のライブ配信ソフトウェアを利用してミキシング処理後のストリームを配信するための仕組みも実装した。そしてプロトタイプシステムを用いた評価実験では、単一構成とカスケード構成のミキサ装置に対してビデオソースの動的な追加／機能を確認するとともに、既存の専用機器と同程度の入力数を処理できることを確認した。送信端末２０とミキサ端末１０との間の遅延については、実装上の検討の余地も残るが、機能的な要件を満たすミキサ装置をPC上で実現できる。
【００９７】
次に第２の実施の形態に係るミキサ装置及びそれを用いたライブ中継システムについて説明する。この第２の実施の形態に係るミキサ装置は、ネットワーク（バックエンド）中に配置されるミキサ部を操作部にて遠隔操作する構成となる。
【００９８】
本発明の第２の実施の形態に係るライブ中継システムは、パブリックビューイング用の第１の構成例と、プライベートビューイング用の第２の構成例の２種類に分けられ、それぞれのシステム構成の概要が図２２と図２３に示される。図２２及び図２３において、各システムは、中継元の送信端末２０（S）、ネットワーク２００内のバックエンドにおいてミキシング処理を行うミキササーバ１０（M：オンデマンド型ミキサ（ミキサ装置））、及びそのミキササーバ１０（M）を利用する利用者端末８０（U：操作装置）を有している。そして、送信端末２０（S）、ミキササーバ１０（M）および利用者端末８０（U）の間におけるストリームデータ（ビデオ、オーディオ）とメッセージの中継を、中継サーバ５０（R：制御装置）が行う。中継されるメッセージには、各端末２０、８０やミキササーバ１０でやりとりされる制御情報と、ミキササーバ１０の遠隔操作コマンドが含まれる。また中継サーバ５０は、負荷分散を考慮して適切なミキササーバ１０を利用者端末８０（U）へ割り当てたり、利用者端末８０（U）とミキササーバ１０（M）との間における遠隔操作コマンドを転送したりする。
【００９９】
図２２で示すシステム構成は、パブリックビューイング用のものであり、最終的には既存のライブ中継用サービスサイト６０を利用して多くの視聴者へのライブビデオ中継を想定した構成である。図２２の利用者端末８０（操作部）は、ミキササーバ１０内で動作するミキシング処理機能（ミキサ部）を遠隔から操作する。ミキササーバ１０を利用する際、利用者端末８０は、ソースグループＳＧＰ（Source Group）を設定し（ソースグループ設定手段）、送信端末２０はそのソースグループに参加する。送信端末２０が中継を開始すると、送信端末２０からのビデオが自動的にミキササーバ１０の入力として扱われ、ミキササーバ１０の出力は中継サーバ５０経由で利用者端末８０と送信端末２０へ送信される（出力制御手段）。また、利用者端末８０におけるミキシング後のビデオストリームは、エンコーダ８５（E）へ渡され、エンコーダ８５（E）からライブ中継用サービスサイト６０を利用して複数の端末３０（P）に配信される。そして、各端末３０から出力されるビデオが視聴者によって視聴される。このパブリックビューイング用のシステムでは、図２２におけるエンコーダ８５として汎用PCが利用され、エンコーダ８５以降の中継には、既存のライブ中継用ソフトウェア（非特許文献１５〜１７参照）の適用を想定している。
【０１００】
一方、図２３に示すシステ構成はプライベートビューイング用を想定したものであり、複数の送信端末２０からのビデオストリームを、利用者端末８０（操作装置）毎のミキササーバ１０（ミキサ装置）で処理している。同じソースグループＳＧＰに参加している複数の送信端末２０からのビデオを、中継サーバ５０が各ミキササーバ１０へ分配する。各ミキササーバ１０では、利用者毎に独立したミキシング処理を実行し、その出力結果をそれぞれの利用者端末８０へ送信する（出力制御手段）。この場合、送信端末２０から見ると複数のミキササーバ１０の出力結果に、自身が送信しているビデオストリームが含まれている可能性がある。そこで、送信端末２０側では任意のミキササーバ１０の出力結果を選択的に受信して確認する。
【０１０１】
図２２および図２３のどちらの構成においても、バックエンド（ネットワーク２００内）のミキササーバ１０を利用する際には利用者端末８０がソースグループＳＧＰを設定し、送信端末２０はそのソースグループＳＧＰに参加する。遠隔地からのビデオストリームを容易にミキササーバ１０の入力として扱うためには、送信端末２０から任意の時間に送信されるビデオストリームを自動的に処理できる必要がある。次に、ソースグループＳＧＰの設定とミキササーバ１０の選択に必要となるメッセージフローを示す。
【０１０２】
利用者端末８０（操作部）がオンデマンドでミキササーバ１０の機能（ミキサ部）を利用する際は、ソースグループＳＧＰを設定する一方、中継サーバ５０はミキシング処理の負荷分散も行う。図２４はそのメッセージフローを示している。
【０１０３】
図２４において、まず、利用者端末８０（U）はソースグループ登録要求メッセージ（Register Source Group Request）を中継サーバ５０（R）へ送る（１：ソースグループ設定手段）。その際、ソースグループプロパティ（ソースグループに関する情報）を中継サーバ５０へ送信する。このソースグループプロパティは、ソースグループＳＧＰの説明や利用するミキサ部のフォーマット情報を含んでおり、送信端末２０がソースグループＳＧＰへ参加する際に参照することができる。また、ソースグループプロパティには、必要に応じて、そのソースグループＳＧＰに参加できる送信端末２０側の利用者IDを含めることもできる。次に中継サーバ５０は、利用可能な複数のミキササーバ１０へ資源状態要求メッセージ（Resource Status Request）を送信し（２）、その応答メッセージ（Resource Status Response）を受ける。応答メッセージ（Response）にはミキササーバ１０の資源利用状況（CPU利用率、ストリーム入出力スループット等）が含まれており、中継サーバ５０はその資源利用状況に基づいて適切なミキササーバ１０を選択する。中継サーバ５０は選択したミキササーバ１０上に新しいミキサ部を生成した後、利用者端末８０へソースグループ登録応答メッセージ（Register Source Group Response）を送り返す（３）。
【０１０４】
送信端末２０はソースグループプロパティ要求メッセージ（Source Group Property Request）およびその応答メッセージ（Response）により、登録されているソースグループプロパティのリストを中継サーバ５０から取得する（４）。送信端末２０は、例えば、操作部での操作に従って、参加すべきソースグループＳＧＰを選び、中継サーバ５０を経由して、ソースグループ参加要求メッセージ（Join Source Group Request）を利用者端末８０に送り（ソースグループ参加要求制御手段）、利用者端末８０からその応答メッセージ（Response）を受信する（５）。これにより、送信端末２０は、ビデオストリーム及びオーディオストリームを送信することが可能となる。そして、送信端末２０は、ビデオストリームまたはオーディオストリームを送信する際には、ソースグループＳＧＰを設定した利用者端末８０に対してソースノード追加要求メッセージ（Add Source Node Request）を送り、ミキサ部からの入力が追加されることを利用者端末８０に伝える（６）。
【０１０５】
なお、ライブ中継の開始時には、中継サーバ５０が負荷分散を考慮してミキササーバ１０を選択するが、ここではそのアルゴリズム自体は定めない。一方、後述するプロトタイプシステムではミキササーバ１０として汎用PCを用いており、ミキシングとエンコード処理に対して多くのCPU資源を必要とするので、CPU利用率の移動平均値を用いてミキササーバ１０の選択を行っている。
【０１０６】
また、図２４には示されていないが、送信端末２０が、ソースグループＳＧＰから退出する際は、送信端末２０から中継サーバ５０経由で利用者端末８０へ、ソースグループ退出要求メッセージ（Leave Source Group Request）を送る（ソースグループ退出要求制御手段）。利用者端末８０は、送信端末２０の退出による終了処理を行い、送信端末２０へ中継サーバ５０経由でソースグループ退出応答メッセージ（Leave Source Group Response）を送り返す。
【０１０７】
更に、ライブ中継を終了する等、利用者端末８０がソースグループＳＧＰを必要としなくなった場合、利用者端末８０は、ソースグループ登録解除要求メッセージ（Unregister Source Group Request）を中継サーバ５０に送る。中継サーバ５０は、ソースグループＳＧＰの登録解除処理を行い、ソースグループ登録解除応答メッセージ（Unregister Source Group Response）を利用端末８０に送る。また、中継サーバ５０は、ミキササーバ１０の利用者端末８０への割り当てを解放する。
【０１０８】
前述したように送信装置２０が利用者端末８０からの参加許可の応答メッセージを受信してソースグループＳＧＰへ参加すると、利用者端末８０は、その送信装置２０を当該ソースグループＳＧＰに参加するストリームの送信元として許容し、ミキササーバ１０は、利用者端末８０の遠隔操作に従って、該ソースグループＳＧＰに参加する複数の送信端末２０からの複数のストリームをミキシング処理する（グループミキシング処理手段）。一方、利用者端末８０は、送信装置２０からのソースグループ退出要求メッセージ（Leave Source Group Request）を受信すると、その送信端末２０へソースグループ退出応答メッセージ（Leave Source Group Response）を送り返し、その送信装置２０をミキササーバ１０でのミキシング処理の対象となるストリームの送信元から外す（ミキシング退出制御手段）。
【０１０９】
前述したように送信端末２０がソースグループＳＧＰに参加した際において、図２４に示すメッセージフローに合わせて、ビデオストリームやオーディオストリームを処理するためのストリームノードを各端末間で接続する。図２５と図２６は、その接続パターンを示している。図２５に示す接続パターンは、図２２に示すパブリックビューイングを想定したシステムに対応しており、図２６に示す接続パターンは、図２３に示すプライベートビューイングを想定したシステムに対応している。図２５および図２６において、Ａに含まれるストリームノード（利用者端末８０のシンクストリームノードsnk、中継サーバ５０の中継ストリームノードrly、ミキササーバ１０のミキサストリームノードmix）は、図２４に示すフローにおいて、ソースグループ登録要求メッセージ（Register Source Group Request）の応答メッセージ（Response）を利用者端末８０が受信した後に接続される。Ｂに含まれるストリームノード（送信端末２０のシンクストリームノードsnk、中継サーバ５０の中継ストリームノードrly）（図２６では省略）は、送信端末２０がソースグループ参加要求メッセージ（Join Source Group Request）の応答メッセージ（Response）を受信した後に必要に応じて接続される。また、送信端末２０がビデオストリーム送信を開始する場合、送信端末２０がソースノード追加要求メッセージ（Add Source Node Request）の応答メッセージ（Response）を受信した後にＣに含まれるストリームノード（送信端末２０のソースストリームノードsrc、中継サーバ５０の中継ストリームノードrly、ミキササーバ１０の中継ストリームノードrly）が接続される。
【０１１０】
ここで、送信端末２０からの同一ビデオストリームが複数のミキサ部（mix）の入力に成り得ることを想定すると、そのストリームの中継は効率よく行われるべきである。図２６は、３台の利用者端末８０が、２台のミキササーバ１０に生成される独立した３つのミキサ部（ミキサストリームノードmix）を利用している例を示している。図２６に示すように、第２の実施の形態に係るシステム（プライベートビューイング用のシステム）では、ミキサーストリームノード（mix）の入力となるストリームをミキササーバ１０が既に受信している場合、同一ストリームを入力とする異なるミキサーストリームノード（mix）に対しては、ミキササーバ１０内でストリームが分配される。
【０１１１】
利用者端末８０におけるミキサ部（ミキサストリームノードmix）に対する操作としては、パブリックビューイングやプライベートビューイング等、用途に応じて選択可能な操作機能を実現する。パブリックビューイングのシステム（図２２、図２５参照）では、予め決められた中継元からのビデオをそのシーンに応じてミキシングする際、プリセットされたレイアウトを用いることが多い。多くの視聴者がいることを想定し、どの入力をどのタイミングで出力するかを決めるのはミキサ操作者となる。そこで、プリセット可能なレイアウトの機能を各種のGUIコンポーネントで実現する。一方、プライベートビューイングのシステム（図２３、図２６参照）で任意のビデオストリームを視聴する際は、より直感的な操作が必要である。前述したように、スポーツイベントやコンサートに集まる観客のスマートデバイスもミキサ部（mix）の入力として考慮すると、ミキサ部（mix）の入力は任意の時間に生成され、任意の時間に終了することが想定される。したがって、プリセット可能なレイアウトの切り替え機能等よりも、ビューワ上に表示されているビデオに対するミキシングをマウスやタッチ操作で行えることが有用である。
【０１１２】
こうした利用形態を考慮したミキサ部（mix）の遠隔操作機能を図２７に示す。ミキササーバ１０（M）内のミキサストリームノード（mix）では、前述した第１の実施の形態に係るシステムと同様に、ビデオをタイル状に配置可能なタイルビュー層（Tiled View Layer）と、縦/横に並べて配置するボックスビュー層（Box View Layer）の２つのレイヤーを持つミキシング機能（Layered Mixing Function）を実現する。タイルビュー層（Tiled View Layer）では、どのタイルにどの入力を表示させるか、および、タイルのサイズと位置を遠隔の利用者端末８０での操作により変更できる。ボックスビュー層（Box View Layer）では、縦／横にビデオを並べたボックスのサイズと位置、ビデオの並び順、透明度を遠隔の利用者端末８０での操作により変更できる。オーディオの音量も含めて、これらの操作を行うために利用者端末８０は、操作者による操作に従ってミキサ制御コマンド（Mixer Control Commands）をミキササーバ１０に送る。一方、ミキサ部（ミキサストリームノードmix）の入力が追加／削除されるタイミングでミキササーバ１０は利用者端末８０へミキサ更新レポート（Mixer Update Report）を送信する。ミキサ更新レポート（Mixer Update Report）には、追加／削除された中継ストリームノード（rly ミキサの入力）のノードID（Node ID）と、その中継ストリームノード（rly）の情報、および現在ミキサ部（mix）の入力として接続されている中継ストリームノード（rly）の情報の配列が含まれている。これにより、利用者端末８０側でミキサ更新レポート（Mixer Update Report）を受信すると、追加／削除されたミキサ部（mix）の入力に対するGUIの追加／削除も可能となる。
【０１１３】
以上、第２の実施の形態に係るミキサ装置（オンデマンド型ミキサ）の機能の概要を述べた。次に、プロトタイプシステムの実装について説明する。
【０１１４】
複数ビデオストリームの統合中継を可能とするオンデマンド型ミキサに対して、実機を用いた機能評価を行うため、汎用PC（OS: Windows（登録商標）7）上にプロトタイプシステムを実装した。メッセージ通信とGUIにはJava言語を用い、ストリーム処理にはC++言語を用いている。まず、遠隔ミキサの操作に関するメッセージや、図２４で示したメッセージの送受信に対しては、テキストベースの簡単なメッセージ通信機能をTCP上に実装した。ビデオとオーディオのストリーム処理機能は、既存システム（非特許文献１８参照）を改良して実現した。この既存システムにおけるストリーム処理機能には、複数の端末間でストリームノードを多段接続する機能が実装されているので、プロトタイプシステムでもその機能を使い、図２５と図２６に示したストリームノードの接続を実装した。一方、図２７で示した遠隔操作可能なミキサ部の機能は 前記既存システムに含まれていないので新たに実装を行った。
【０１１５】
＜ミキサストリームノードの実装＞
既存システム（非特許文献１８参照）ではビデオとオーディオの処理にDirect Show（非特許文献１９参照）を用いており、プロトタイプシステムにおける遠隔操作可能なミキサ部の機能もDirect Showをベースに実装した。Direct Showでは、ビデオフレームやオーディオサンプルデータの単位で処理を行うモジュールをフィルタと呼んでいる。通常は、一連の処理に必要なフィルタを１つのフィルタグラフ内で繋ぎ合せて利用する。
【０１１６】
プロトタイプシステムでは、Direct Showのフィルタグラフを複数用いてミキサの機能を実装した。図２８及び図２９は、ミキササーバ１０におけるフィルタグラフとフィルタの構成を示している。図２８は、ビデオについてのフィルタグラフの構成を示しており、図２９は、オーディオについてのフィルタグラフの構成を示している。
【０１１７】
フィルタグラフのインタフェースを用いることで、フィルタグラフ内のフィルタの動作をまとめて操作（開始／停止／各種パラメータの設定と取得）することができる。しかし、ミキサ部への入力が動的に追加／削除されることを考慮すると、ミキサ部への入力処理とミキシング処理とは別々に機能させる必要がある。そこで、プロトタイプシステムでは、フィルタグラフを分けてミキサ部（mix）への入力処理（入力処理部）とミキシング処理（ミキシング処理部）を実装した。
【０１１８】
図２８に示すビデオに関する構成では、各中継ストリームノード（rly）に対応して構成される入力処理部１５（フィルタグラフ）は、入力パケットをビデオデータ化するデパケタイザ（Depacketizer）１５１、ビデオデコーダ（Video Decoder）１５２及びビデオミキサへの入力データを出力するRGBミキサコネクタ（RGB Mixer Connector）１５３の各フィルタを有している。そして、ミキサストリームノード（ミキサ部：mix）に対応して構成されるビデオミキシング処理部１６（フィルタグラフ）は、ビデオのミキシング処理を行うビデオミキサソース（Vide Miser Source）１６１、ビデオエンコーダ（Video Encoder）１６２及びビデオミキシングデータをパケット化するパケタイザ（Packetizer）１６３の各フィルタを有している。
【０１１９】
また、図２９に示すオーディオに関する構成では、各中継ストリームノード（rly）に対応して構成される入力処理部１７（フィルタグラフ）は、ビデオに関する構成（図２８参照）と同様に、入力パケットをオーディオデータ化するデパケタイザ（Depacketizer）１７１、オーディオデコーダ（Audio Decoder）１７２及びオーディオミキサへの入力データを出力するPCMミキサコネクタ（PCM Mixer Connector）１７３の各フィルタを有している。そして、ミキサストリームノード（mix）に対応して構成されるオーディオミキシング処理部１８（フィルタグラフ）は、オーディオのミキシング処理を行うオーディオミキサソース（Audio Mixer Source）１８１、オーディオエンコーダ１（Audio Encoder）８２及びオーディオデータをパケット化するパケタイザ（Packetizer）１８３の各フィルタを有している。
【０１２０】
更に、図２８に示すビデオに関する構成において、異なるフィルタグラフ（入力処理部１５とビデオミキシング処理部１６）内のフィルタであるRGBミキサコネクタ（RGB Mixer Connector）１５３とビデオミキサソース（Video Mixer Source）１６１とを直接つなげるために、ビデオミキサソース（Vide Mixer Source）１６１内に独自のリングバッファ（Ring Buffer）１６５を設け、RGBミキサコネクタ（RGB Mixer Connector）１５３から直接そのリングバッファ（Ring Buffer）１６５にRGBデータを渡す仕組みを実装した。また、図２９に示すオーディオに関する構成においても同様に、オーディオミキサソース（Audio Mixer Source）１８１内に独自のリングバッファ（Ring Buffer）１８５を設け、PCMミキサコネクタ（PCM Mixer Connector）１７３から直接そのリングバッファ（Ring Buffer）１８５にPCMデータを渡す仕組みを実装した。
【０１２１】
また、プロトタイプで実装したミキシング処理部１６、１８では、ビデオデータはRGB（各8bit、24bit/pixel）に、オーディオデータはPCM（サンプリング周波数48kHz、量子化ビット数16bit）に統一したフォーマットが用いられる。ビデオミキサソース（Vide Mixer Source）１６１及びオーディオミキサソース（Audio Mixer Source）１８１の各フィルタがリングバッファ（Ring Buffer）１６５、１８５から入力データを取得する間隔は、デフォルトではビデオデータが1/30sec.、オーディオデータは1/25sec.としている。
【０１２２】
＜ミキサ部の遠隔操作機能＞
ミキサ部の遠隔操作機能としては、表２に示すメソッドを実装した。
【表２】
0006651197.tif 000003
これらのメソッドは、図２７で示した利用者端末８０内のビューワとミキシング操作用GUIから呼ばれ、メソッドの中からミキササーバ１０に対して操作コマンドが送信される。ここで、プロトタイプシステムのミキササーバ１０では、利用者端末８０が指定したピクセル解像度でのミキシング処理が行われる。その際の座標系をミキサ座標系とする。これに対し、利用者端末８０における操作用GUIの座標系は異なる。図２７で示したビューワおよびミキシング操作用GUIコンポーネントそれぞれのローカル座標系からミキサ座標系に座標変換した矩形情報を用いて、表２のメソッドを使うことによりビデオミキサを操作する。
【０１２３】
図３０は、利用者端末８０におけるビューワを示し、図３１は、ミキシング操作用GUIのコンポーネントの画面を示す。図３０に示すビューワ上では、マウスまたはタッチ操作により入力ビデオの配置を変更することができる。また、マウスの右ボタン押下または長押しによりプルダウンメニューを表示して各操作機能を使うことが可能である。図３１にミキシング操作用のGUIにおいて示す操作コンポーネント８１のGUIを用いてタイルビュー層（Tiled View Layer）の複数のレイアウトをプリセットしておきレイアウトの切り替えを行ったり、操作コンポーネント８２のGUIを用いてボックスビュー層（Box View Layer）のビデオボックスの位置やボックス内のビデオのローテーション、透明度とサイズの調整を行ったりすることができる。また、操作コンポーネント８３のGUIを用いてオーディオのボリューム調整用を行うことができる。
【０１２４】
上述したように実装したプロトタイプシステムを用いて、評価実験を行った。実験で用いた中継サーバ５０とミキササーバ１０のスペックは表３に示すとおりである。
【表３】
0006651197.tif 000004
評価実験においては、専用機器として販売されているAVミキサのうち、比較的入手し易い機器（非特許文献２０参照）と同程度の価格で入手可能なPCをミキササーバ１０として利用した。送信端末２０と利用者端末８０としては、評価実験で利用するビデオとオーディオの処理に十分対応可能なPCを利用している。また、送信端末２０における往復遅延の測定では、ネットワーク２００内の遅延を考慮せずプロトタイプシステムとしての遅延を測定するため、図３２（パブリックビューイング用を想定）及び図３３（プライベートビューイングを想定）に示すように、ギガビットスイッチングハブ７０に中継サーバ５０、ミキササーバ１０、送信端末２０及び利用者端末８０に相当する各PCを接続して実験を行った。
【０１２５】
送信端末２０が送信するビデオストリームのフォーマットは、1080p（1920×1080pixel）、720p（1280×720pixel）、480p（854×480pixel）および360p（640×360pixel）の４種類を用い、フレームレートは全て30fpsとした。圧縮にはWMV（Windows Media Video）のCBR（Constant Bit Rate）を用い、フォーマット毎に、1080p:8Mbps、720p:4Mbps、480p:2Mbps、360p:1Mbpsの設定を利用している。オーディオストリームのフォーマットはPCM（チャンネル数：1、サンプリング周波数：44.1kHz、量子化ビット数：16bit、キャプチャ間隔：1/25sec.）を用いており、キャプチャしたPCMデータを圧縮せず705.6Kbpsのオーディオストリームとして利用した。
【０１２６】
まず、プロトタイプシステムのミキササーバ１０上で、開発したオンデマンド型ミキサの性能を評価するために、図３２の評価実験環境を用いて実験を行った。実験では、利用者端末８０（U1）とミキササーバ１０（M1）および中継サーバ５０（R）に対して、送信端末２０（S1〜S12）を１台から１２台まで追加した場合の、ミキササーバ１０（M1）におけるCPU利用率と出力フレームレートを測定した。また、送信端末２０（S1）が送信したビデオストリームがミキササーバ１０（M1）によりミキシング処理され、送信端末２０（S1）に戻って表示されるまでの往復遅延も合わせて測定した。実験では、まず利用者端末８０（U1）が中継サーバ５０（R）上に生成したソースグループＳＧＰへ送信端末２０（S1〜S12）が順番に参加し、各送信端末２０はビデオストリームを送信する。次に、各送信端末２０からのストリームを中継サーバ５０（R）を経由してミキササーバ１０（M1）が受信し、ミキササーバ１０（M1）は利用者端末８０（U1）からの遠隔操作を受けてミキシング処理を行う。実験では、ミキサ部の遠隔操作機能を用いて１つのビデオをタイルビュー層（Tiled View Layer）全体に配置し、その他のビデオはボックスビュー層（Box View Layer）内で横に並べて配置している（図３０参照）。また、ソースグループＳＧＰに参加している送信端末２０（S1〜S12）および利用者端末８０（U1）へ、ミキササーバ１０（M1）におけるミキシング処理の出力を中継サーバ５０（R）を経由して中継した。
【０１２７】
各送信端末２０が順番にビデオストリームを送信し、ミキササーバ１０（M1）の入力が増える毎に３分間、ミキササーバ１０（M1）のCPU利用率と出力フレームレート、そして送信端末２０（S1）とミキササーバ１０（M1）との間の往復遅延を測定した。ミキササーバ１０（M1）におけるCPU利用率の平均値をグラフにしたのが図３４である。横軸は送信端末数を示している。図３５は出力フレームレートの平均値を示しており、送信端末数毎の標準偏差の値も合わせて示す。同様に図３６は往復遅延の平均値と標準偏差の値を示している。
【０１２８】
ミキシング処理と入力数に応じて、ミキササーバ１０（M1）では計算機及びネットワーク資源を消費する。プロトタイプシステムでは、まず、利用者端末８０（U1）が中継サーバ５０（R）を経由してミキササーバ１０（M1）の利用を開始すると、ミキササーバ１０（M1）にはミキサーストリームノード（mix）が生成される。ミキササーバ１０（M1）は、ミキシングとエンコードおよびパケット化までの処理を１つのスレッドで行い、パケット化されたストリームデータは別の送信スレッドで中継サーバ５０（R）へ送信する。その後、送信端末２０が１台増える毎にミキササーバ１０（M1）では２つのスレッドが生成される。１つはパケット受信用のスレッドであり、もう１つは中継ストリームノード（rly）におけるデパケット化とデコード処理を行うスレッドである。送信端末２０の数が増える毎に、ミキササーバ１０（M1）では、ネットワークI/O（受信）処理とスレッドの数、および単位時間当たりに処理すべきデータ量が増加する。これに応じてCPU利用率は増加し、出力フレームレートと往復遅延も変化する。
【０１２９】
ここで、ミキササーバ１０（M1）における平均出力フレームレートが30.0fpsであることを、処理可能な入力数（送信端末１台をミキササーバ１０（M1）における１入力とする）の条件とすると、1080pでは３入力、720pでは１０入力、480pと360pの場合は１２入力以上の入力を処理できたことが図３５からわかる。720pの場合、１１入力でも平均フレームレートは29.94fpsと、比較的高い値となっているが、グラフに示している標準偏差の値が示す通り１０入力までに比べると１１入力の場合のフレームレートは安定しない。一方、送信端末２０（S1）における往復遅延（図３６参照））を見ると、1080pでは１〜３入力に対して４入力の往復遅延は大きく増加しており、720pでも１〜１０入力に対して１１入力の往復遅延は明らかに増加している。ここで図３４に示すCPU利用率を見ると、1080pの場合は３入力（約63%）から４入力（約75%）の間、720pの場合は１０入力（約80%）から１１入力（約94%）の間で、単位時間当たりに処理すべきデータを十分に処理できなくなったことが分かる。480pと360pの場合における処理可能な入力数については、１２入力までの実験結果を示したが、その上限については、図３４の結果をもとに後に考察としてまとめる。
【０１３０】
一方、図３７は利用者端末８０（U1）からミキササーバ１０（M1）を操作した際の応答遅延の測定結果を示している。応答遅延の評価実験では、利用者端末８０（U1）のビューワ上に表示されている任意のビデオの配置場所をマウス操作により変更した。その変更処理を開始した時刻から、変更が利用者端末８０（U1）のビューワ上に反映されるまでの時間を応答遅延としている。ミキササーバ１０（M1）への入力を増やす毎に利用者端末８０（U1）では配置場所の変更を１０回行い、その応答遅延の平均と標準偏差を求めた。1080pに関しては、平均フレームが30.0fps未満となる４入力までの実験を行った。30fps（1フレーム約33ms）のビデオストリームを利用しているので、応答遅延の平均値から、360pと480pの場合はほぼ２フレーム（約67ms）以内でビューワに反映されたことが分かる。720pの場合９入力までは、ほぼ３フレーム（約100ms）以内でビューワに反映され、１０入力でもほぼ４フレーム（約133ms）以内にはビューワへ反映された。同様に、1080pの場合２入力までは３フレーム前後、３入力では５フレーム（約167ms）前後でビューワへ反映されたことが分かる。また、720pと1080pにおいては、それぞれフレームレートが平均で30.0fps未満となる１１入力と４入力の時点で応答遅延も大幅に増加する結果となった。
【０１３１】
次に、複数のミキササーバ１０を用いた場合の負荷分散機能を評価するために、図３３に示す評価実験環境を用いて実験を行った。４台の送信端末２０（S1〜S4）と４台のミキササーバ１０（M1〜M4）に対して、１２台の利用者端末８０（U1〜U12）がそれぞれ個別のミキサ（プライベートミキサ）機能を利用した場合の、ミキササーバ１０におけるCPU利用率を測定した。また、中継サーバ５０（R）におけるビデオストリームの入出力スループットを測定し、図２６で示したストリームの中継が行われていることも確認した。
【０１３２】
この実験では、利用者端末８０毎に割り当てられたミキササーバ１０内で、利用者端末８０毎のミキサストリームノードが生成される。４台の送信端末２０は、それぞれビデオストリームを中継サーバ５０（R）を経由して各ミキササーバ１０へ送信し、そのビデオストリームは各ミキササーバ１０におけるミキサーストリームノード（mix）の入力となる。ここで、送信端末２０がミキシング処理後のストリームを選択的に受信することは可能であるが、この実験ではミキシング後のストリームを送信端末２０では受信していない。
【０１３３】
図３８〜図３９は、中継サーバ５０（R）における入出力スループットの測定結果を示している。上述した通り、ビデオストリームは１本につき、720p:4Mbps、480p:2Mbps、360p:1Mbpsのフォーマットを利用しており、オーディオストリームは１本につき705.6Kbpsのフォーマットを利用している。ビデオとオーディオストリームに必要となるビットレートを足した値が１組のストリームに必要なビットレートとなる。図３８と図３９は、測定結果（meas.）と合わせて、必要となるビットレートの計算値（calc.）も示している。
【０１３４】
利用者端末８０（U1）がプライベートミキサの利用を開始すると、中継サーバ５０（R）は、送信端末２０（S1〜S4）からのストリームとミキササーバ１０（U1）用のプライベートミキサからのストリーム、計５組のストリームを受信し、その後は利用者端末８０が増えるたびに１組分のストリームを追加受信することになる。利用者端末８０（U2）以降の利用者端末がプライベートミキサを利用しても、送信端末（S1〜S4）からのストリームの入力数に変化は無く、追加されたプライベートミキサからの入力が1組分増えるのみとなる。図３８に示すグラフから、中継サーバ５０（R）における入力スループットの測定値は、ほぼ計算値通り増加していることが確認できる。 
【０１３５】
一方、中継サーバ５０（R）における出力スループットはミキササーバ１０の数によって増加分が変わる。まず、利用者端末８０（U1）がプライベートミキサの利用を開始すると、中継サーバ５０（R）では送信端末２０（S1〜S4）からのストリームを、そのプライベートミキサが動作しているミキササーバ１０へ送信する。また、プライベートミキサの出力を受けて利用者端末８０（U1）へ送信するので、計５組のストリームを送信することになる。この実験では、４台のミキササーバ１０が用いられ、利用者端末２０が増えるごとにCPU利用率の低いミキササーバ１０でプライベートミキサを動作させている。したがって利用者端末８０（U1〜U4）それぞれのプライベートミキサがミキササーバ１０（M1〜M4）のいずれかで処理を開始するまでは、利用者端末８０が増えるたびに５組分のストリーム送信処理が追加される。一方、各ミキササーバ１０で送信端末２０（S1〜S1）からのストリームを受信した後、利用者端末８０が増えると、その利用者端末８０用のプライベートミキサへの入力は、ミキササーバ１０内で分配される。図３９のグラフが示す通り、利用者端末８０（U5）以降の利用者端末８０の増加に対しては、ストリーム１組分の出力スループットが増えるのみとなる。これは図２６で示したパターン通りにストリームの接続が行われたことを示している。また図３８から、中継サーバ５０（R）における出力スループットの測定値も、入力スループットと同様にほぼ計算値通り増加していることが確認できる。
【０１３６】
上述したような実験結果を踏まえて、開発したオンデマンド型ミキサの機能に関する考察を述べる。
【０１３７】
＜ミキササーバの入力数＞
プロトタイプシステムではCPUがミキシング処理を行っているので、処理可能な入力数は、PCの構成や性能および利用するビデオとオーディオのフォーマットに依存する。これは、既存のライブ中継用ソフトウェア（非特許文献１５〜１７参照）と同じである。一方、参照している専用機器（非特許文献２０参照）では４系統のビデオ入力を扱え、その他の専用機器においても４系統または８系統が主流である。ここで、第２の実施の形態に係る中継用ミキサ装置（オンデマンドミキサ）は、多くの送信端末２０からの入力を想定しているので、少なくとも専用機器における入力数と同等以上の入力を処理できるべきである。プロトタイプシステムにおける性能評価実験結果からは、1080pの場合は３入力、720pの場合は１０入力のミキシング処理が可能であることを確認した。一方、前記専用機（非特許文献２０参照）におけるミキシング処理は、NTSC設定の場合480/59.94p、PAL設定の場合は576/50pで行われる。プロトタイプシステムによる評価実験では、入出力を1080pまたは720pとした場合、ミキシング処理も1080/30pまたは720/30pで行っている。ミキシング処理時のフレームレートはプロトタイプシステムの方が低いが、単位時間当たりに処理すべきデータ量はプロトタイプシステムの方が多い。
【０１３８】
ここで、実験に用いた端末の数の関係上480pと360pの入力数の上限を評価実験では確認できていないが、少なくとも、それぞれ１６入力または３２入力程度を処理できるものと推察する。480pと360pにおいて単位時間に処理すべきデータ量は720pに比べるとそれぞれ約1/2と1/4になる。図３４〜図３６の結果から720pの入力数の上限は１０入力であった。720pの１０入力に相当するデータ量は、480pと360pの場合それぞれ約２０入力分と４０入力分となる。しかし、これはデータ量のみを考慮した場合の数なので、実際には、より少ない入力数が上限になると予想される。一方、前述したように、プロトタイプシステムにおいて出力フレームレートを十分に確保できなくなるのはCPU利用率が70%から80%を越える付近だと考えられる。加えて、単位時間当たりに処理すべきデータを十分に処理できない状態になるにつれ、CPU利用率は急激に増加することを考慮し、図３４における480pと360pのグラフに対して２次の多項式近似を行った結果が図４０のグラフである。図４０のグラフにおいて、CPU利用率が70%と80%の時の送信端末数を見てみると、480pの場合は１６〜１７、360pの場合は３２〜３６となる。この入力数はデータ量のみで見積もった概数未満であり、入力数の上限として妥当な数である。
【０１３９】
また、ミキサ部を遠隔操作する際の応答遅延も、利用する端末やフォーマットに依存するが、ここでは非特許文献２１同様に100msを応答性の目安として検討する。評価実験で用いたネットワーク環境においては、360pと480pの場合、実験した１２入力全てにおいて応答遅延の平均値は100ms未満であった。720pでは9入力まで、1080pでは２入力までが100ms未満の平均値となっている。一方、実際のライブ中継におけるネットワーク環境では、ネットワーク内の遅延を考慮する必要がある。参考値ではあるが、インターネット接続サービスや各種のクラウドサービスを展開している国内のISPでは、SLA（サービス品質保証制度）としてネットワーク内の国内における平均往復遅延を25msで保証している（非特許文献２２〜２４参照）。近年では、このように短い遅延を保証するインターネットサービスの利用が可能であり、ミキサ部の遠隔操作に対しても、インターネットを利用することが現実的な選択肢になり得る。
【０１４０】
一方、応答性を損なう長さの応答遅延が発生する場合においても、利用者の操作感を損なわないような仕組みが必要である。例えば、利用者端末８０におけるミキシング操作開始後、利用者端末８０上でミキシング操作の対象となったビデオフレームのデータを用いてアニメーションによるトランジション効果を開始し、そのトランジション効果を、遠隔操作結果が反映されたビデオへシームレスに繋げる。これにより、利用者がミキシング操作を開始した直後から、表示されているビデオは変化することになるので、応答性の確保に効果がある。
【０１４１】
以上、プロトタイプシステムにおけるミキササーバ１０の入力数について述べた。プロトタイプシステムにおけるミキサ部は、1080pと720pの場合は専用機器と同等以上、480pと360pの場合は、より多くの入力を処理できる。一方で４台のミキササーバ１０を用いた実験からは、負荷分散しながらオンデマンドミキサを利用できることも確認した。よって、バックエンドシステム上で、ミキサ部の機能に対してスケーラビリティを確保する仕組みと、ミキサ部の機能を遠隔からオンデマンドで利用するための機能をプロトタイプシステムとして実装できた。
【０１４２】
＜送信端末におけるビデオの確認＞
ミキシング処理後のビデオを、中継元の送信端末へも中継できる機能を実装したが、中継元では、ある程度の往復遅延の範囲内でミキシング後のビデオを確認できる必要がある。ここでは、遠隔会議における往復遅延の許容値を既出の文献から引用し、往復遅延の測定結果について考察する。まず非特許文献２５によると、往復遅延250msではほとんどの会議場面が許容されるが、500msでは一部適さない会議場面（速くてひん度の高いやりとりが要求される会議場面）が生ずる、と述べられている。また、非特許文献２６では、発話衝突や、それに起因して起こる精神的ストレスを低減するための遠隔会議の要件として、音声遅延量を200ms以内に抑えれば良いことが実験から示されている。非特許文献２５は映像と音声を用いた実験結果であり、非特許文献２６では音声のみの実験結果が報告されている。送信端末２０から送信するストリームにはオーディオデータも含まれており、ミキシング後のビデオのみならずオーディオデータを含めた確認が行われることも想定し、これらの文献における250msと200msを往復遅延の許容値として検討する。
【０１４３】
図３６における送信端末２０とミキササーバ１０との間の往復遅延の測定結果より、360pおよび480pの場合は往復遅延が200ms未満であることがわかる。また、720pにおいても入力数の上限とした１０入力までは200msを下回っている。1080pの場合は１入力でも約240ms、３入力では約256msの往復遅延であった。結果として、評価実験で用いたネットワーク環境においては、720p以下のフォーマットを利用する場合、遠隔会議中に発話衝突が発生しない程度の往復遅延でミキシング後のビデオを確認でき、1080pの場合は、ほとんどの会議場面で許容できる250ms前後での確認ができる。当然、実際のライブ中継におけるネットワーク環境ではネットワーク内の遅延を考慮する必要があるが、短い遅延が保証されたインターネットサービスを利用することが選択肢の１つになる。
【０１４４】
以上、説明したように、本発明の第２の実施の形態に係るミキサ装置（オンデマンド型ミキサ）では、前述した第１の実施の形態の場合と同様に、ソースグループＳＧＰを設定し、各送信端末２０がそのソースグループＳＧＰに参加して、ビデオストリームやオーディオストリームを送信する仕組みにより、ミキサへの入力となるビデオソースの数の動的な増減に対応できる。それに加えて、このライブ中継システムは、ライブ中継用のバックエンドシステム内で動作可能なミキサ部の機能を遠隔からオンデマンドで利用でき、中継元のビデオ撮影者（送信端末２０の操作者）が必要に応じてミキシング後のビデオを確認でき、更に、バックエンドシステムがミキサ部の機能に対してスケーラビリティを確保するための仕組みを備えている。
【０１４５】
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。上述したこれら新規な実施の形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施の形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１４６】
１０  ミキサ端末  ミキササーバ（ミキサ装置）
２０  送信端末（情報送信装置）
３０  受信端末
４０  利用者端末
５０  中継サーバ（制御装置）
６０  ライブ中継用サービスサイト
ギガビットスイッチングハブ
８０  利用者端末（操作装置）
２００  ネットワーク
【図１】
0006651197.tif 000005
【図２】
0006651197.tif 000006
【図３】
0006651197.tif 000007
【図４】
0006651197.tif 000008
【図５】
0006651197.tif 000009
【図６】
0006651197.tif 000010
【図７】
0006651197.tif 000011
【図８】
0006651197.tif 000012
【図９】
0006651197.tif 000013
【図１０】
0006651197.tif 000014
【図１１】
0006651197.tif 000015
【図１２】
0006651197.tif 000016
【図１３】
0006651197.tif 000017
【図１４】
0006651197.tif 000018
【図１５】
0006651197.tif 000019
【図１６】
0006651197.tif 000020
【図１７】
0006651197.tif 000021
【図１８】
0006651197.tif 000022
【図１９】
0006651197.tif 000023
【図２０】
0006651197.tif 000024
【図２１】
0006651197.tif 000025
【図２２】
0006651197.tif 000026
【図２３】
0006651197.tif 000027
【図２４】
0006651197.tif 000028
【図２５】
0006651197.tif 000029
【図２６】
0006651197.tif 000030
【図２７】
0006651197.tif 000031
【図２８】
0006651197.tif 000032
【図２９】
0006651197.tif 000033
【図３０】
0006651197.tif 000034
【図３１】
0006651197.tif 000035
【図３２】
0006651197.tif 000036
【図３３】
0006651197.tif 000037
【図３４】
0006651197.tif 000038
【図３５】
0006651197.tif 000039
【図３６】
0006651197.tif 000040
【図３７】
0006651197.tif 000041
【図３８】
0006651197.tif 000042
【図３９】
0006651197.tif 000043
【図４０】
0006651197.tif 000044