DEIM Forum 2016 P1-4

ライブ放送のための映像処理システムにおける負荷分散方式の設計と実装
川上朋也†,††

義久 智樹††

寺西裕一†††,††† 奈良先端科学技術大学院大学情報科学研究科 〒 630–0192 奈良県生駒市高山町 8916–5†† 大阪大学サイバーメディアセンター 〒 567–0047 大阪府茨木市美穂ヶ丘 5–1††† 国立研究開発法人情報通信研究開発機構 〒 184–8795 東京都小金井市貫井北町 4–2–1
E-mail: †kawakami@is.naist.jp
あらまし

著者らの研究グループでは，ライブ放送のための分散型映像処理システムを研究開発してきた．本システ

ムでは，映像処理サーバが映像撮影端末から依頼された映像処理を行う．多数の映像撮影端末が映像処理サーバに映像処理を依頼すると通信負荷や処理負荷が大きくなって映像処理に時間がかかり，ライブ放送を円滑に行えない．そこで本研究では，映像処理を依頼する映像処理サーバを選択して映像処理サーバにかかる負荷を分散させる方式を提案，実装する．提案方式では，複数の映像処理サーバがある場合に，映像処理内容や負荷に応じて処理を依頼する映像処理サーバを，P2P 型モバイルエージェントシステムを用いて選択する．複数の映像処理サーバと映像撮影端末を用いて実験し，映像処理を完了するまでの時間への影響を確認した．
キーワード

ストリーミング配信，インターネット放送，ビデオオンデマンド，リアルタイム

1. は じ め に

著者らの研究グループでは，ライブ放送のための分散型映像
処理システムを研究開発してきた [2]．本システムでは，サービ

近年の映像配信技術の発達に伴い，USTREAM やツイキャ

ス提供者が映像処理サーバを用意し，映像撮影端末（PC や携スといった，個人がインターネットを介してリアルタイムな帯情報端末）から依頼された映像処理を行う．また，映像撮影

映像配信を行えるインターネットライブ放送サービスが普及

端末は，映像処理に必要なプログラムライブラリである映像効

している [1]．例えば，USTREAM では，個人のパソコンで果ライブラリを映像処理サーバへ送信する．ライブ放送時には，USTREAM のホームページにブラウザでアクセスし，放送を映像撮影端末で撮影した映像を映像処理サーバに送信する．複開始するボタンをクリックすることで，パソコンに接続された雑な映像処理を計算能力の高い計算機で行うことで，映像処理

カメラで撮影された映像を配信できる．ツイキャスでは，主ににかかる時間を短縮しつつ，放送者は映像効果を付加できる．

スマートフォンからの配信を対象としており，専用アプリを用

映像撮影端末は，1 台の映像処理サーバを指定していたため，

いてスマートフォンのカメラで撮影された映像を配信できる．

複数の映像撮影端末が同じ映像処理サーバを指定している場合，視聴者は，インターネットブラウザや専用アプリの画面に列挙

映像処理に関わる負荷が大きくなって映像処理に時間がかかるされた配信中のインターネットライブ放送の中から興味のある問題がある．映像処理サーバが複数ある場合には，負荷が小さライブ放送を選択し，配信されている映像をブラウザや専用アい映像処理サーバを利用することで，短時間で映像処理を行え

プリで視聴する．

る．これまでに処理負荷を分散させる多数の方式が提案されてインターネットライブ放送サービスでは，放送者が重畳表示

いるが，あらかじめ負荷分散システムを構築するものがほとん

や画像処理といった映像効果を付加する場合がある．映像処理どであった．インターネットライブ放送では，ライブ放送できを短時間で行うことで，より多くの付加情報や重畳表示を行っるスマートフォンのような映像撮影端末が多数あり，あらかじてさらにライブ放送を盛り上げられたり，鮮明な画像処理をめ負荷分散システムを構築しておくことは困難である．ライブ

行ってライブ放送しやすくなったりする．しかし，現状では，放送を始めようとしてから既存方式を用いた負荷分散システム

個人が所有するパソコンやスマートフォンの計算能力に応じて，を構築すると，ライブ放送開始までの時間が長くなる．このた

短時間で処理できる簡易な映像効果しか付加できなかった．例

め，ライブ放送では，映像撮影端末を含めた負荷分散システム

えば，物体検出に時間がかかるため，あらかじめ付加情報を表をあらかじめ構築することなく（ゼロコンフィグ），負荷を分示させておいて，付加情報が表示されている位置に人や物が写散できる映像処理システムを用いることでライブ放送開始をす

るようにすることがあった．複雑な映像効果を付加すると，放ぐに行える．そこで本研究では，映像処理を依頼する映像処理

送者の所望のタイミングに映像効果を付加できなかったり，映サーバを選択して映像処理サーバにかかる負荷を分散させる方

像配信のビットレートが下がるといった問題が発生する．計算式を提案，実装する．提案方式では，あらかじめ映像撮影端末能力の高い計算機を用いることで映像処理にかかる時間を短縮

を含めずに負荷分散システムを構築できるように P2P 型の負できるが，高価で個人で導入しにくい．

荷分散システムを構築する．P2P 型の負荷分散システムでは，するライブ放送ソフトウェアもある．
近年のクラウドコンピューティング環境の普及に伴い，インターネットライブ放送サービス提供者が高性能な計算機を設置
し，放送者が利用する上記のようなシステム構成は現実的な構成といえる．

2. 2 要 求 機 能
本研究では，以下をインターネットライブ放送のための分散型映像処理システムへの機能要求と考える．

•

放送者の任意のタイミングに映像効果を付加できる

1 章で述べた例のように，ライブ放送中に一貫して付加される映像効果とは別に，付加情報を表示したり，放送を盛り上げたりするために，放送者の任意のタイミングで映像効果することがある．例えば，放送者の知人が写っている間，名前を表示させたり，放送者が楽しいと思ったときに音符マークを表示したりすることが考えられる．これらを実現するためには，放送
図 1 システム構成者の任意のタイミングに映像効果を付加できる必要がある．

•

放送者が所望の映像効果を付加できる

負荷分散システムに接続するとシステムが負荷が小さい映像処

ロゴを表示したり時計を表示するといった簡易な映像効果で理サーバを選択するため，映像撮影端末は負荷分散を意識するはなく，放送者の所望の任意の映像効果を付加することで，よことなくライブ放送を開始できる．提案方式では，複数の映像

りライブ放送を盛り上げたり，ライブ放送しやすくなる．例え

処理サーバがある場合に，映像処理内容や負荷に応じて処理をば，放送者独自の画像アイコンを表示させてライブ放送を盛り依頼する映像処理サーバを，P2P 型モバイルエージェントシス

上げたり，放送者の所望の明るさに映像を調整したりすること

テムを用いて選択する．

が考えられる．これらを実現するためには，放送者が所望の映

以下，2 章で想定する分散型映像処理システムについて述べ

像効果を付加できる必要がある．

る．3 章で負荷分散方式の提案と実装について述べ，4 章で実

2. 3 映像効果ライブラリ機を用いた実験について述べる．5 章で関連研究について説明

本研究で提案する分散型映像処理システムでは，放送者が所し，最後に 6 章で本稿をまとめる．

2. ライブ放送のための分散型映像処理システム

望の映像効果を付加できるように，放送者が映像効果を実装した映像効果ライブラリを用意する．映像効果ライブラリはプログラムライブラリであり，様々な映像効果を実装できる．ライ

著者らの研究グループでは，ライブ放送のための分散型映像

ブ放送中に映像効果ライブラリを映像処理サーバに送信すると，処理システムを研究開発してきた [2]．本章では，想定する分散通信帯域が低下するため，ライブ放送前に映像処理サーバに送型映像処理システムについて説明する．

信する．複数の放送者が送信した映像効果ライブラリを識別す

2. 1 システム構成

るため，ライブラリ ID を設定する．放送者は，映像効果を付

分散型映像処理システムのシステム構成を図 1 に示す．映像

加したいタイミングに，ライブラリ ID で指す映像効果ライブ

撮影端末は，インターネットライブ放送の放送者が映像を撮影

ラリに実装されている複数の関数の中から，付加したい映像効する計算機である．映像撮影端末は，接続されたカメラで映像

果を示す関数 ID を選択する．関数 ID が示す関数の引数としを撮影でき，映像のデータをインターネットを介して他の計算て渡すパラメタも渡せる．

機に送信できる．映像処理サーバは，インターネットライブ放映像処理サーバは，放送者からあらかじめ映像効果ライブラ

送サービス提供者が設置することを想定した高い計算能力をもリを受信して保存しておく．映像効果ライブラリの読み込み時

つ計算機であり，インターネットを介して映像データおよび映間を削減するため，映像処理サーバは，ライブ放送が開始され像効果ライブラリの送受信を行える．映像効果ライブラリは，ると，プログラムで放送者が送信した映像効果ライブラリを読放送者が用意した任意の映像処理を行えるプログラムライブラ

み込む．映像撮影端末からフレームデータを受信時にライブラ

リであり，映像処理サーバのプログラムで読み込んで実装されリ ID が指定されていると，映像効果ライブラリに実装されてた関数を呼び出すことで実行できる．詳細は次節で説明する．

いる関数の中から対応する関数呼び出し，放送者の所望の映像

例えば，放送者の所望の物体検出や重畳表示，画像処理を行う

効果を付加する．ライブ放送が終了すると，読み込んでいた映映像効果を実装した映像効果ライブラリが考えられる．ライブ

像効果ライブラリを開放する．

放送ソフトウェアは，インターネットライブ放送サービス提供

2. 4 映像撮影端末

者が公開するライブ放送のためのソフトウェアであり，映像撮

インターネットライブ放送では，通信量を削減するために映影端末から実行できる．インターネットブラウザを介して実行像の幾つかのフレームのデータをまとめて他の計算機に送信することがあるが，送信するフレームの取得を待つため，遅延時間が長くなる．遅延時間が長くなると，放送者の任意のタイミングに映像効果を付加しにくくなる．そこで，提案する分散

映像撮影端末・・・・・・

映像処理サーバ群

・・・・・・

型映像処理システムでは，1 フレーム毎に映像処理サーバにフレームデータを送信する．映像効果を付加する場合には，同時にライブラリ ID とパラメタも送信する．
フレームデータの送信後、映像処理サーバで映像処理された
フレームデータを受信すると，ライブ放送ソフトウェアに送信
し，インターネットで映像配信する．続けて次のフレームデー
タを映像処理サーバに送信する．ライブ放送が終了すると，映映像受信端末・・・・・・

像処理サーバに通知する．

2. 5 映像処理サーバ
インターネットライブ放送サービスのほとんどでは，放送者を識別するために，ライブ放送開始前にサービスにログインす

図 2 映像処理配信システムの配信環境

ることが多い．映像処理サーバが直接インターネットで映像配信すると，これらのログイン情報を映像処理サーバが保持する必要があり，セキュリティ等の問題が発生する可能性がある．

映像撮影端末そこで，提案する分散型映像処理サーバでは，映像処理サーバ
は映像処理を施したフレームデータを映像撮影端末に返信し，負荷分散機構映像撮影端末がライブ放送ソフトウェアを用いて映像配信する．
ログイン等の配信上の制約がなければ映像処理サーバから直接ライブ放送を行うことも考えられる．
映像処理サーバは，映像撮影端末からフレームデータを受信すると，関数 ID が指定されている場合には映像効果を施して映像撮影端末に返信する．ライブ放送が終了すると，読み込ん映像処理サーバ群

・・・・・・

でいた映像効果ライブラリを解放する．

3. 負荷分散方式の提案および実装
3. 1 概要

多数の映像撮影端末が映像処理サーバに映像処理を依頼する

図3

負荷分散の実現方式

映像撮影端末Client

映像処理サーバP

Server

Pと通信負荷や処理負荷が大きくなって映像処理に時間がかかり，
ライブ放送を円滑に行えない．そこで本研究では，映像処理を

映像撮影端末ソフトウェア

PIAX

プロセス 映像処理サーバソフトウェア

PIAX

プロセス

依頼する映像処理サーバを選択して映像処理サーバにかかる負荷を分散させる方式を提案し，負荷分散機構として実装する．
負荷分散機構の実装では，既存のシステムの変更を最小限にとどめることを基本方針とする．これは，既に映像撮影クライ
アントと映像処理サーバの各システムが存在することから，それらのシステムの大幅な改修は容易ではないためである．このため，原則として既存のシステムとは別プロセスで稼動させ，それぞれが独立して動作する疎結合な設計とする．最終的に負荷分散機構への適合のために既存システムに要した変更点は，映像処理サーバに負荷の通知機能を追加するのみとなった．
図 2 に本研究のシステムが想定している配信環境を示す．想定環境では映像撮影端末，映像処理サーバ，映像受信端末の 3
種の端末・サーバがそれぞれ複数台存在する．映像撮影端末は，必要な映像処理を行える映像処理サーバを選択して，映像効果
ライブラリや撮影した映像を送信する．映像処理サーバでは，
映像撮影端末から送られた映像を映像撮影端末からの指示に従い画像加工やエフェクト処理を施す．映像受信端末は，各々が受信したい映像を扱っている映像処理サーバに接続し，処理済
みの映像を随時受け取ることとなる．

図 4 映像撮影端末と映像処理サーバの内部構成

本研究では，映像撮影端末が映像処理サーバを選択する部分に着目して映像処理サーバの負荷分散を実現する．既存のシス
テムでは，映像撮影端末が映像を送信する時点において，映像
撮影端末ソフトウェア上の設定により固定的に映像処理サーバを選択している．このため，映像処理サーバが既に高負荷状態であっても映像撮影端末からのさらなる接続が行われ，結果として過負荷による遅延の増大や処理落ちが生じることとなる．
本研究では，映像撮影端末が映像処理サーバに接続する際に，その接続に割り込み，その接続先を複数台の映像処理サーバからランダムに選択することで負荷分散を行う（図 3）．

3. 2 負荷分散機構の実装
図 4 に映像撮影端末と映像処理サーバの内部構成を示す．映像撮影端末には映像撮影端末ソフトウェアと PIAX プロセス，
映像処理サーバには映像処理サーバソフトウェアと PIAX プロ
セスを配置する．この中で，映像撮影端末ソフトウェアと映像

映像処理サーバ PIAX プロセス

映像処理サーバ

映像撮影端末Client

0001

1723

2196

5021

9928

P

P

P

P

P

ServerP

P・・・

映像処理サーバ
Server

P

キー空間

7243
P

映像撮影端末 PIAX プロセス

図6

動作シーケンスと PIAX プロセス待ち受けポート番号を与える．映像撮影端図 5 MaxLessThan 検索による映像処理サーバの選択

末ソフトウェアは，事前にその接続先を localhost の PIAX プ
ロセスの映像待ち受けポート番号に設定しておく．また，映処理サーバソフトウェアは既存のシステムのものとなる．PIAX
プロセスは，PIAX のオーバレイネットワーク探索機能を用いて，複数ある映像処理サーバから 1 台をランダムに検索する機能を実現する．

PIAX [3] とは， Java ベースのプラットフォームミドルウェ
アで，オープンソースソフトウェアとして公開されている（注 1）．

PIAX では，構造化オーバレイネットワークの一種である
SkipGraph を用いることで，P2P ネットワークにおいて MaxLessThan 検索を実現している．MaxLessThan 検索とは，検索クエリに指定された値を超えない最大の値を持つ要素を抽出する検索で，例えば検索対象に 1, 6, 15, 24 という値がある場
合に，10 を検索すると 6 が抽出されるという検索となる．本
実装では，この MaxLessThan 検索により，複数ある映像処理
サーバから自律的に 1 台のみを選択する．図 5 に検索の模式図を示す．まず，映像処理サーバの PIAX プロセスでは，起動時にランダム値を生成し，その値を SkipGraph オーバレイ
ネットワーク上に公開する．この値は SkipGraph の特性により，オーバレイネットワークのキー空間に大小の従い順に整列する．映像撮影端末の PIAX プロセスでは，映像処理サーバを検索する際に，ランダムな値を生成し，この値を検索クエリとして MaxLessThan 検索を行う．図では，映像撮影端末が7243 を生成し，MaxLessThan 検索をした結果，7243 を超えない最大の値である 5021 を持つ映像処理サーバの PIAX プロ
セスが発見されている様子を示している．実際の検索クエリは，

SkipGraph の MaxLessThan 検索アルゴリズムに準じて PIAX
プロセス間を転送されることで，最終的に 5021 を持つ PIAX
プロセスに到達することとなるが，その詳細については本稿では触れないこととする．SkipGraph 上での MaxLessThan 検索の実現方法については，公開されている PIAX の実装を参照いただきたい．

3. 3 実装システムの動作初期設定として，各 PIAX プロセスには初期接続先として，

PIAX プロセスが動作する任意の端末・サーバの IP アドレス

像処理サーバでは，映像処理サーバソフトウェアの待ち受け
ポート番号と映像処理サーバの IP アドレスを映像処理サーバの PIAX プロセスに与える．それぞれのプロセスを起動すると，各 PIAX プロセスは，その初期接続先情報に従って接続を試み，SkipGraph をはじめとするオーバレイネットワークを構築し，相互に接続する．
起動が完了した後，映像撮影端末より配信を開始する際の動作シーケンスを図 6 に示す．
まず，映像撮影端末ソフトウェアがユーザの配信開始の指示により，配信先に接続する．この接続先は localhost の PIAX
プロセスとなっているため，図のように localhost 内での接続となる．映像撮影端末の PIAX プロセスは，この接続をきっかけとして，先述した MaxLessThan 検索により映像処理サーバの 1 台に検索要求が届く．映像処理サーバの PIAX プロセスは
この検索要求に対し，初期設定で与えられた映像処理サーバソ
フトウェアの待ち受けポート番号と映像処理サーバの IP アド
レスを応答する．その応答を元に，映像撮影端末の PIAX プロ
セスは映像処理サーバソフトウェアとの間に接続を確立し，映像撮影端末ソフトウェアと映像処理サーバソフトウェア間の通信を中継を始める．
映像処理サーバが高負荷となった場合に生じる動作を図 7 に示す．まず，自身が高負荷状態と判断した映像処理サーバソフ
トウェアは localhost の PIAX プロセスの制御ポートに接続し，検索からの離脱要求コマンドを送る．この検索からの離脱要求
コマンドを受けた PIAX プロセスは，図 5 に示したキー空間
より自身の値を削除する．これにより，それ以降の映像撮影端末からの検索の対象から外れ，現在以上の接続は生じないこととなる．映像処理サーバソフトウェアの負荷が下がり，再び新たな接続を許容できる状態となると再び localhost の PIAX プ
ロセスの制御ポートに接続し，検索からの離脱解除要求コマンドを送る．このコマンドを受けた PIAX プロセスは，再びキー空間上に自身の値を公開し，映像撮影端末からの検索を受け付ける状態となる．
以上の動作により，映像撮影端末からの新規接続先が映像処（注 1）：PIAX: P2P Interactive Agent eXtensions -http://www.piax.org/

理サーバソフトウェア負荷状態に応じて制御されることとなる

P

Server

P

映像処理サーバ・・・

Server

ϰϬϬ
P

間
期
外
象
対
索
検

図 7 映像処理サーバ高負荷時の動作シーケンスdƵƌŶƌŽƵŶĚdŝŵĞ΀ŵƐĞĐ΁

映像処理サーバ

映像撮影端末ClientůŝĞŶƚϭĨŽƌ^ĞƌǀĞƌϯϱϬůŝĞŶƚϯĨŽƌ^ĞƌǀĞƌůŝĞŶƚϮĨŽƌ^ĞƌǀĞƌϯϬϬůŝĞŶƚϯĨŽƌ^ĞƌǀĞƌ

ϮϱϬ
ϮϬϬ
ϭϱϬ
ϭϬϬ
ϱϬ
Ϭ
ϭ

ϱϭ

ϭϬϭ

ϭϱϭ

ϮϬϭ

Ϯϱϭ

ϯϬϭ

&ƌĂŵĞƐĨŽƌůŝĞŶƚϭŽƌϮ
ため，映像処理サーバソフトウェアの過負荷を避けることがで
図8きる．また，全てのサーバが検索の対象から外れている場合は，実験結果

映像撮影端末ソフトウェアは単純に接続に失敗する．これにより，ユーザは映像処理サーバ群の余剰リソースが枯渇している

4. 実

験

ことを知ることができる．
本負荷分散機構において，既存ソフトウェアに必要となる修本研究では，提案する負荷分散方式を用いて負荷を分散でき

正は，映像処理サーバソフトウェアの負荷計測と PIAX プロセ

るか実験を行った．

スへの通知部のみにとどまり，映像撮影端末ソフトウェアは接4. 1 実 験 環 境

続先を localhost に変更するのみで従来と透過的に扱う事がで2 コアの CPU を搭載したサーバ A と 4 コアの CPU を搭載

きる．一方で，負荷状況の計測と検索からの離脱・離脱解除のしたサーバ B の 2 台を用いる．3 台のクライアントには Web

判断を映像処理サーバの PIAX プロセスが行えば，映像処理

カメラが接続されており，取得した画像をサーバに送信して処サーバソフトウェアに修正は不要となる．しかしながら，その理する．クライアント 1 はサーバ A を利用しており，クライア

場合は CPU の負荷から間接的に映像処理サーバソフトウェア

ント 2 はサーバ B を利用している．各サーバを用いた場合の負の負荷を判断することになり，映像加工の推移を見越した負荷荷を調査するため，クライアント 3 はまずサーバ A を利用し，判断はできなくなるため，高負荷が続く状況にあるにも関わらその後サーバ B を用いる．これらの計算機は同一の無線 LAN

ず，一時的な負荷の現象により高負荷状態を脱したと誤判断し，に接続されている．

新たな接続を受けてしまう場合が生じる．現時点以降の負荷予

フレームあたりの映像処理にかかる時間を短縮することで高想ができるのは，処理を行っている映像処理サーバソフトウェ

いフレームレートを実現できるため，映像処理システムでは，

アのみであるため，精度よく負荷判断を行うためには，その判映像処理にかかる時間を短縮するために負荷を分散させること断を映像処理サーバソフトウェア自身がすることが望ましいとが考えられる．そこで，サーバに 1 フレームの画像を送信して考える．

から映像処理を完了するまでの時間（ターンアラウンドタイム）

また，本研究に類似する負荷分散手法として，リバースプロ

を負荷と捉え，ターンアラウンドタイムを計測した．

キシによる負荷分散が Web サーバの負荷分散などに一般的に

4. 2 実 験 結 果

用いられているが，本研究では P2P 技術を用いたことで，それ実験結果を図 8 に示す．横軸はクライアント 1 またはクライ

ぞれの端末・サーバが自律的に動作し，負荷分散先の端末の状

アント 2 が送信したフレームの数であり，縦軸はターンアラウ

態管理を集中して行うこと無く，任意の時点での映像処理サー

ンドタイムである．実験中，クライアント 1 はサーバ A，クラバの追加や削減を容易に実現できることとなった．

イアント 2 はサーバ B を常に利用している．クライアント 3 は本研究では実装負荷を軽減するため，負荷分散のアルゴリズ

50 番目のフレームから 150 番目のフレームが送信されている

ムとして実質的にランダムとなる手法を採用したが，映像処理

間サーバ A を利用し，200 番目のフレームが送信されるまで待サーバ群全体が均等な負荷となるように制御したい場合には不機した後，300 番目のフレームが送信されるまでサーバ B を利十分と考えられる．その場合は，映像撮影端末からの接続先を用する．

選択する際に，映像撮影端末が初期に送出する制御フレームのクライアント 1 のターンアラウンドタイムは，50 番目のフ情報を用いるとともに，映像処理サーバの負荷状況を収集し，レームを送信するまで約 90msec だが，その後，約 180msec に

これらの情報に基づき現時点で負荷が低い映像処理サーバに接なっている．これは，クライアント 3 がサーバ A を利用する

続を中継するという手法も考えられるため，前提条件も含めてことでサーバ A の負荷が上昇し，映像処理に時間がかかった検討を続けたい．

ためである．この間，クライアント 3 のターンアラウンドタイ
ムも約 180msec になっている．また，クライアント 2 のター
ンアラウンドタイムは，200 番目のフレームを送信するまで約32msec だが，その後，約 65msec になっている．これは同様

に，クライアント 3 がサーバ B を利用することでサーバ B の法を提案している．また，HD 法では，1 対 1 の通信と同時に，負荷が上昇し，映像処理に時間がかかったためである．これよ

1 対多の放送型配信を用いて同時に複数の視聴端末に映像デー

り，サーバ A にクライアント 1 が接続した時点でサーバ A はタを送信することで，通信量を削減している [11]．提案システ

高負荷と判断し，提案方式を用いて新たな接続を受け付けない

ムにおいても，映像配信時にこれらの遅延時間短縮手法を適用ようにすることで，クライアント 3 はサーバ B に接続することできるが，本研究とは映像処理システムを対象としている点がになってサーバ A に接続するよりもターンアラウンドタイムを異なる．

短くできることが分かる．クライアント 2 のターンアラウンド

さらに，保存された映像データに対して映像処理を行うシス

タイムが 32msec 程度長くなるが，サーバ A に接続してクライ

テムに関する研究が行われている．文献 [12] では，カメラで撮

アント 1 のターンアラウンドタイムが 90msec 程度長くなる場

影した映像データを，高い計算能力がある計算機に転送して映合に比べて影響を少なくできる．

像処理を行うシステムを提案している．文献 [13] では，スマー

クライアント 3 が接続した時点でクライアント 1 やクライア

トフォン等の計算能力が低い映像撮影端末で撮影した映像を映ント 2 のターンアラウンドタイムが非常に長くなっているが，像撮影端末に保存せずに直接，クラウドストレージ等の外部記

これは，クライアント 3 の接続開始処理に時間がかかるためで憶装置に保存するシステムを提案している．これらのシステムある．また，クライアント 2 のターンアラウンドタイムが周期は，保存された映像データを対象としており，インターネット

的に約 50msec になっている．これは，カメラから映像の取得

ライブ放送では利用できない．

に時間がかかっているためであり，ハードウェアの都合によるものと考えられる．

5. 関 連 研 究

6. ま と め
本研究では，ライブ放送のための分散型映像処理システムにおいて，映像処理サーバの負荷を分散させるため，複数の映像

本章では，本研究に関連する研究について説明する．

処理サーバから選択する方式を提案した．また，提案方式は映像撮影端末とは別の計算機で映像処理を行う分散型映像処

P2P 型エージェントプラットフォームである PIAX を用いて理システムに関する研究が幾つか行われている．MediaPaaS実装した．実装システムでは，映像撮影端末が映像処理サーバ

では，ライブ放送のための PaaS (Platform as a Service) 形式に接続する際に，その接続に割り込み，その接続先を複数台ののクラウドコンピューティングサービスを目的とし，映像の符

映像処理サーバからランダムに選択することで負荷を分散する．

号化，再符号化，配信および画像処理をサービス提供者側の計

さらに，複数の映像処理サーバと映像撮影端末を用いて実験し，算機で行えるシステムを提案している [4]．画像処理の内容は時映像処理を完了するまでの時間への影響を確認した．

刻を表示する，ロゴを表示するといったインターネットライブ

今後の課題としては，各映像処理サーバの負荷を収集し，負放送中に一貫して行われる内容であり，放送中に放送者の要求

荷の低い映像処理サーバへ優先的に中継する手法の検討が考えに応じて行えない．文献 [5] では，P2P ネットワークを用いてられる．

ライブ放送を行う場合に，通信状況に応じて映像の再符号化を行う手法を提案しているが，放送者が明示的に再符号化を指定

謝辞できない．また，静止画ではあるが，PictuAR では，撮影した

本研究の一部は，科学研究費補助金（基盤研究 A）「ユビキタ

静止画を動画サーバに転送して解析し，関連ある動画を検索しス環境のためのトポロジコーディングによる全体プログラミンている [6]．本研究で提案するシステムでは，放送者がプログラ

グ」（課題番号：23240010），および，NICT・大阪大学共同研

ムした任意の映像処理を，要求に応じて行える点が異なる．

究「大規模分散コンピューティングのための高機能ネットワー

また，インターネットライブ放送のための映像配信システム

クプラットフォーム技術の研究開発」，総務省戦略的情報通信研

に関する研究も行われている．文献 [7] では，パノラマ撮影さ究開発推進事業（SCOPE）「放送通信融合環境による次世代モれた映像から，あたかもカメラでズームやパンを行ったような

バイルビデオオンデマンド配信の研究開発」による成果である．

映像効果を与えて配信できるシステムを実装している．文献 [8]では P2P ネットワークを用いてライブ放送を行う場合に，少し前から視聴（追っかけ再生）できるシステムを実装している．
これらの映像配信システムでは，放送者が任意の映像処理を行えない点が本研究で提案するシステムとは異なる．
インターネットライブ放送において，映像配信の遅延時間を削減する幾つかの手法が提案されている．SmoothCache 2.0 では，P2P ネットワークを用いてライブ放送を行う場合に，他のピアに映像データをキャッシュし，キャッシュしたピアから配信することで映像撮影端末にかかる通信負荷を低減させて遅延時間を削減する手法を提案している [9]．文献 [10] では，遅延時間を理論上最小にする P2P ネットワーク上の配信経路決定手

文

献[1] I. Sodagar, “The MPEG-DASH standard for multimedia
streaming over the Internet,” IEEE MultiMedia, vol.18,
no.4, pp.62–67, April 2011.
[2] 義久智樹，川上朋也，石 芳正，寺西裕一，“ライブ放送のための分散型映像処理システムの設計と評価，” 情報処理学会研究報
告，第 2015-DCC-11 巻，pp.1–7，Nov. 2015．
[3] 吉田 幹，奥田 剛，寺西裕一，春本 要，下條真司，“マルチオーバレイと分散エージェントの機構を統合した P2P プ
ラットフォーム PIAX，” 情報処理学会論文誌，vol.49，no.1，
pp.402–413，Jan. 2008．
[4] B. Cheng, “MediaPaaS: A cloud-based media processing
platform for elastic live broadcasting,” Proceedings of the
7th IEEE International Conference on Cloud Computing

(CLOUD 2014), pp.713–720, June 2014.
[5] J.-C. Wu, P. Huang, J.J. Yao, and H.H. Chen, “A collaborative transcoding strategy for live broadcasting over peer-topeer IPTV networks,” IEEE Transactions on Circuits andSystems for Video Technology, pp.220–224, Feb. 2011.
[6] “スマートフォン向け AR（拡張現実）サービス”． Available at
http://www.nttcom.co.jp/ar-saas/．
[7] V.R. Gaddam, R. Langseth, H.K. Stensland, P. Gurdjos,
V. Charvillat, C. Griwodz, D. Johansen, and P. Halvorsen,“Be your own cameraman: Real-time support for zooming
and panning into stored and live panoramic video,” Proceedings of the 5th ACM Multimedia Systems Conference(MMSys 2014), pp.168–171, March 2014.
[8] Y. Gotoh, T. Yoshihisa, H. Taniguchi, and M. Kanazawa,“Brossom: a P2P streaming system for webcast,” Journal of
Networking Technology, vol.2, no.4, pp.169–181, Dec. 2011.
[9] R. Roverso, R. Reale, S. El-Ansary, and S. Haridi, “SmoothCache 2.0: CDN-quality adaptive HTTP live streaming on
peer-to-peer overlays,” Proceedings of the 6th ACM Multimedia Systems Conference (MMSys 2015), pp.61–72, March
2015.
[10] J. Dai, Z. Chang, and G.S.H. Chan, “Delay optimization
for multi-source multi-channel overlay live streaming,” Proceedings of the IEEE International Conference on Communications (ICC 2015), pp.6959–6964, June 2015.
[11] T. Yoshihisa and S. Nishio, “A division-based broadcasting method considering channel bandwidths for NVoD services,” IEEE Transactions on Broadcasting, vol.59, no.1,
pp.62–71, March 2013.
[12] D. Gibbon and L. Begaja, “Distributed processing for big
data video analytics,” IEEE ComSoc MMTC E-Letter,vol.9, no.3, pp.29–31, 2014.
[13] W.-C. Ting, K.-H. Lu, C.-W. Lo, S.-H. Chang, and P.C. Liu, “Smart video hosting and processing platform forInternet-of-Things,” Proceedings of the 2014 IEEE International Conference on Internet of Things (iThings 2014),
pp.169–176, Sept. 2014.