第３部

特集3  Software Defined Mediaコンソーシアム2016年活動報告書

第３部
特集3 Software Defined Mediaコンソーシアム2016年活動報告書
SDM WGメンバー

第１章

はじめに

などの映画館やホームシアター，さらには個人向けモバ
イル機器を対象に，音のオブジェクトから三次元の音場を生成する立体音響システムが登場している．また，映2020年の東京オリンピック・パラリンピックの開催に向像においては，複数の地点・角度から撮影された映像・動

けて，世界からの訪問者への高度なおもてなしを目指し

画から，撮影した空間に存在する三次元オブジェクトのた社会インフラのスマート化が急がれている．中でも，オ抽出が可能であり，抽出した三次元オブジェクト情報をリンピックの理念である「スポーツを通して心身を向上さ用いて，任意の視点(自由視点)からの映像の作成・再構築

せ，さらには文化・国籍など様々な差異を超え，友情，連が可能となりつつある[4][5]．こうした流れに目を向ける

帯感，フェアプレーの精神をもって理解し合うことで，平と，今後はインターネットで収録環境と再生環境を双方

和でよりよい世界の実現に貢献する」という目標を支援す向で接続し，視聴オブジェクトを交換しながら，三次元るため，地球規模での一体感を生み出すような視聴メディ表現を持つ情報空間をエッジヘビーコンピューティング

アに関する研究開発の重要性が高まっている[1]．そのたまたはクラウドで計算処理することよって，映像音声がめには，グローバルなインターネットを前提とした映像・作り出されていくことになるであろう．

音響の視聴空間と視聴メディアの設計が必要である．
映像と音声のオブジェクト化が融合することで，従来の近年は，多くのスマートフォンに標準的に内蔵される収配布型コンテンツビジネスを超えた，新しい次元のイン録機器を常時持ち歩くことが増え，収録された映像音声

タラクティブなオリンピック・パラリンピックの視聴形の情報はインターネット上で瞬時に伝達・共有・加工さ態などこれまでにないビジネス領域や，これまでにないれる状況が出来上がった．さらには，収録対象から映像

ディジタルメディアを用いた表現方法などを開拓・開花

素子に入力されたビットマップ情報と，ステレオマイク

させることが期待される．例えば，音と映像をオブジェに入力された2チャネルの音声情報としてそのまま伝送クト化することで，スポーツ観戦者の要求に応じてリアし，受信側でそのまま再生するだけでなく，空間に存在

ルタイムに応援スタンド側からの視聴や，選手の一人称

する収録対象を三次元モデルとして解釈し複数の視聴オ視点からの視聴を切り替えることが可能になるだろう．

ブジェクトに分解して伝送し，受信側ではこれらのオブ

さらに，コンサートの視聴においては，複数の歌手の中ジェクトを用いて空間を再合成するオブジェクト指向のの一人や，演奏者のうちの一人をズームアップすると映方式が注目を集めている．これにより，ヘッドマウント

像に追従して音もズームアップするなどのインタラク

ディスプレイ（HMD），3Dテレビ，立体音響装置などの受ティブなコンテンツ制作が可能になる．

信側のシステムの構成に合わせた柔軟な三次元表現が可能となるだけではく，他のコンテンツの視聴オブジェク

さらに映像・音声を作り出す空間に目を向ければ，例えトを別途受信し組み合わせることで，今までにない表現

ば，劇場，ホームシアター，テレビ会議システム，講義室が可能になる．

など，様々な用途に対して専用に設計されたシステムが存在している．これらの映像・音響システムには，収音シ

例えば，音響においては，Dolby Atmos[2]やAuroMax[3]ステム，拡声システム，制作システム，BGMや館内放送

27

のためのシステムなどのサブシステムから構成されていてきた研究について報告する．2章では，SDMを実現す

る．こうしたサブシステム間で信号の伝送を行う場合はるためのアーキテクチャについて説明する．3章では，高精度同期と低遅延を求められるため，従来はアナログ

SDMアーキテクチャを利用した三次元映像音声コンテン

線でシステム間を結ぶ必要があった．例えば，劇場では，ツの協調制作フレームワークのコンセプトについて説明

演劇，軽音楽，講演といった様々な演目に対応する必要する．4章では，そのコンセプトに基づき，さらに，アプがあり，各演目によって要求される演出が異なるため音

リケーション非依存な視聴オブジェクトの管理を行うた

声信号の伝送路も必要に応じて組み替えるが，アナログ

めのオープンデータに関する研究を紹介する．オープン

パッチの差し替えや大規模なマトリクスなどによって組

データは，最大24名によるコンサートを，さまざまな方

み換えを実現しているため，処理が複雑になり，また事式のマイクとカメラで収録し，収録データのデータベー前の設定通りに組み替えるため，柔軟性に欠けていた．

ス化する．5章では，収録データを利用した，自由視聴
点インタラクティブ三次元映像音声アプリケーション

しかし現在では，IPを利用した1Gbps環境等の大容量「360Square」を紹介する．6章では，360Squareのデモ

通信環境の一般化により，各サブシステム間をIPによりンストレーション及び受賞の報告を行う7章で，関連する

ネットワーク化することが可能となった．これにより，研究・開発に関して記述する．8章にてまとめを行い，今映像音声の入力から制作，出力までの伝送路の組み換え

後の課題について述べる．

を一貫してソフトウェアによって制御するシステムの実現が期待される．ソフトウェアによって定義された演出を，目的に応じて柔軟に変更することが可能になれば，第２章

SDMアーキテクチャ

一つのシステムを講演会，遠隔会議，音楽イベント，映画や放送の上映など様々なアプリケーション向けに最適化

SDMとは，映像・音響システムのIPネットワーク化を背景し活用することも容易になる．例えば，アプリケーショに，これらの設備の機能に対して抽象化・仮想化を行い，ンを載せ換えることで，映画館を遠隔音楽教室として利サービスとしての映像・音響を提供するための基盤的な用するなどのユースケースが考えられる．演出者の意図アプローチである[6, 7, 8, 9]．

を汲み，柔軟に視聴空間をソフトウェア制御するためには，映像・音声の設備機能を抽象化して管理し，演出に関

これまでの研究で議論を進めた結果，SDM実現するSDM

する意思決定を行うアプリケーションと実際の映像・音アーキテクチャを図2.1に定めた．

響の入出力を行うデバイスを引き離して（decoupling）扱
うべきである．その際，実際の入出力デバイスを仮想化し，複数のアプリケーションから同時並列に利用可能にする．また，視聴空間のソフトウェア制御は，同じくIP
ネットワークの一般化により生まれた照明や空調などを
ソフトウェア制御するスマートビルディングの技術との親和性を持ったシステムであることが望ましい．
オブジェクト指向のディジタルメディアと，ネイティブ・
ディジタルなインターネット環境が前提の映像・音響空間を用いたビジネス創造を目指し，2014年1月にSoftware
Defined Media(SDM)コンソーシアム＊1を設立した．
本論文では，SDMの実現のためにコンソーシアムで行っ＊1

28

http://sdm.wide.ad.jp/

図2.1 SDMアーキテクチャ

SDMは図2.1左に示すように，視聴空間（実空間）に存在

SDM拠点を，他のSDM拠点からは放送局として機能させする収録対象を三次元モデルとして解釈し，複数の視聴

る．SDM拠点からの放送はリアルタイムに他のSDM拠点

オブジェクトに分解して情報空間に取り込み，視聴オブに転送されるだけでなく，視聴オブジェクトの蓄積・管ジェクトの交換など様々な計算処理を行って，その結果理などのコンテンツ管理を行う．SDMでは，放送局からを自在に視聴空間に投影することで視聴空間の再合成送信されるリアルタイムとアーカイブのコンテンツに対を行う仕組みである．上記の視聴空間と情報空間をつなし，標準化されたメタデータや，タグを付与することで，ぐ処理を行うSDMの基本単位をSDM拠点と呼ぶ．また，

ソフトウェアによって柔軟なコンテンツ管理や，状況にSDM拠点のシステムは，図2.1右に示す通り，設備層，サー

応じたコンテンツ選択を制御する．メディアデータとコ

ビス層，アプリケーション層に分けられる．

ンテンツ情報，位置情報などのメタデータを持つ視聴オ
ブジェクトを基本単位として扱う．

設備層には，収録する空間に存在する映像音声の収録対
象を三次元的に解釈しオブジェクト化するためのセン
サ，カメラ，マイクなどの設備と，再生空間において視聴
オブジェクトから三次元の映像音声を作り出すためのス

第３章

三次元映像音声コンテンツの協調制作フレームワーク

ピーカ，HMD，ディスプレイなどの設備がある．設備例
はこれに限らず，これから登場する革新的デバイスの機

現在，オーケストラやライブなどのイベント収録を，後能も取り込めるよう設備層の差異を吸収できる形で，上に視聴するためのパッケージメディアでは通常，カメラ

位のサービス層を設計する．また，SDM拠点は収録専用・とマイクの置かれた位置と角度によって，視聴するコン

再生専用の空間だけでなく，収録環境と再生環境は同一

テンツが大幅な制約を受け，視聴者の意思による自由なの実空間上に配置される可能性も想定して設計する．

場所と角度，距離での視聴は困難である．こうした課題を解決するため，収録されたメディアはアプリケーショ

サービス層は，設備層の設備機能を抽象化しアプリケー

ンに非依存に，複数の視聴オブジェクトなどに分解してションに対してApplication Programming Interface（API）

解釈し，管理する機構が必要であると考えられる．

を通じてサービスとして提供するための層である．視聴
オブジェクトと管理するための基礎となる空間三次元モこうした機構により自由度の高いシステムが構築可能とデルと地図を定義し，位置測位，音声オブジェクト化，映なり，汎用的な視聴オブジェクト管理によって様々なア像オブジェクト化，立体映像再生などのサービスを提供

プリケーション／コンテンツを様々な場所で提供するこ

する．APIは開発者が創造的なアプリケーションを実現とが可能となる．この結果，自由度の高いシステムによっできるよう柔軟かつ拡張性を持つ．

てより高い忠実度で音の場を収録したり，再生したり，共有したりすることが可能になるということが期待され

アプリケーション層は，APIを通じてSDMサービスを利る．例えば，ある映像が，ある奏者にズームアップすると用する任意のアプリケーションが動作する層である．こその奏者が奏でる音も連動してズームアップするなどのの層にローカルレンダラと呼ぶアプリケーションがあインタラクティブなコンテンツを簡単に作成することがり，インターネット上に存在するリアルタイムとアーカ可能になる．

イブのコンテンツを取得してSDMサービスと組み合わせてSDM拠点の視聴空間に対して視聴者の要望に合わせ

図3.1に示すとおり，収録を行う機器はイベント主催者がた映像音声を作り出す．レンダリングの機能は，ローカ

関わるプロ用の機器の他に，観客が持ち込む商用デバイ

ルだけではなく既存の放送システムやインターネット経スが考えられる．インタラクティブなコンテンツ制作に由で取得したコンテンツを共同編集するなどの機能を持は，両者の収録データを素材として利用できることが望

つパブリックレンダラにより前処理される．また，アプ

ましい．こうした収録データを自由に流通させることで，リケーション層に定義されるメディアエンコーダにより第三者クリエータが斬新な演出を加えたコンテンツを制29

作する土壌が整うと考えられる.

される．これはコンピュータを使って設計された映像音
声による効果をソフトウェアレンダリングによって組みしたがって，三次元映像音声コンテンツの協調制作フレー

合わせた拡張演出と考えられる．例えば実際のイベント

ムワークでは，以下の機能要件を満たすことが望ましい．

会場では，見たり聞こえたりしないような映像音声の効果を追加することで，現実拡張を行うといったことが想

三次元の映像・音声の演出をソフトウェアで制御：定できる．

収録対象から映像素子に入力されたビットマップ情報と，
ステレオマイクに入力された2チャネルの音声情報とし映像・音声の複数ソースのミキシング可能性：てそのまま伝送する従来方式では，映像音声の演出を制

放送側が作成した映像音声のコンテンツを単一のソース御することは難しいため，SDMでは，視聴オブジェクトからの受信だけでなく，複数のソースからコンテンツ素を三次元表現を持った情報空間上で管理しながら，ソフ

材の受信を可能にし，ソフトウェアによる受信側でのミトウェアの演出によって再生環境に適した映像と音響をキシングを実現する．さらに，複数ソースのコンテンツを作り出す．

ミキシングする主体は，放送側と受信側の中間に位置す
るクラウドでの共同でのミキシングを行うことも想定しユーザ・インタラクション性：た仕組みを構築する．これにより，創造性豊かなクリエー

SDMでは，視聴者の関心事を再生側のソフトウェアシス

ターの手によるコンテンツが，第三者クリエーターらのテムにフィードバックし，演出の制御や，視聴者の望む映共同作業によって進化し，視聴者の好みによって選択さ像音声のソースを選択可能にする．現在のコンテンツ視れる視聴環境を作る．

聴においては，放送局において制作されたコンテンツを受け取り再生するため，視聴者が特定の関心事に対して，

再利用性の高いデータ公開方式：

能動的にズームアップしたり，違うアングルから視聴を収録されたメディアはアプリケーションに非依存に，複行うことはできない．SDMでは，視聴者の関心事を再生

数の視聴オブジェクトなどに分解して解釈し，管理する側のソフトウェアシステムにフィードバックし，演出の機構が必要である．

制御や，視聴者の望む映像音声のソースを選択可能にする．ユースケースとしては，ファンの歌手の一人称視点での映像音声の視聴などが考えられる．

第４章

三次元映像音声メディアのオープンデータ化

ソフトウェアレンダリングによる拡張演出：

4.1

SDMで交換される視聴オブジェクトは実空間由来のもの

SDMコンソーシアムでは，試作システムとそのシステムである必要はなく，コンピュータを使って設計された映を用いたアプリケーションを開発する一方，アプリケー

像音声による効果を組み合わせることも可能であり、そション非依存な視聴オブジェクトの管理の研究のためれによって視聴者の臨場感や満足度を高めることが期待に，以下の収録を行いデータベースを構築する．本デー

素材データの収録

タベースは，実験素材としてコンソーシアムのメンバーに提供される．
4.1.1 慶應義塾大学コレギウムムジクム古楽アカデミーのコンサート収録
2016年01月10日，慶應義塾大学日吉キャンパス内に建つ509席の席数を有する藤原記念ホールにて開催された慶應義塾大学コレギウムムジクム古楽アカデミーのコン
図3.1 三次元映像音声コンテンツの協調制作フレームワーク

30

サートを収録した．収録対象は，17世紀のドイツ宮廷音楽であるヨハン・フリードリヒ・ファッシュの「管弦楽組で配置された．舞台内にはセクションごとに同じく録音

曲ト長調FaWV K:G2」など，最大24名の演奏家による全エンジニアの判断のもと標準的な個別録音として最適なてアコースティックの演奏である．楽器には，テオルベ，

位置を選んでマイクロホンを設置，それぞれのマイクロチェンバロ，バロック・ヴァイオリン，バロック・オーボ

ホンは単一指向性と双指向性の組合せとなっている．こエ，ヴィオラ・ダ・ガンバなどの現代では珍しい楽器が含の組合せは従来から使われているM/S型のマイク配置でまれており，楽器ごとの演奏と各楽器の合わさった音をあるため，マイクロホンからの出力に既存のマトリクス

分離して収録した[10]．

処理を施せばその係数を変えることでステレオ集音の拡がり感を変化させることができる．またさらに高度な処

図4.1にカメラとマイクの配置を示す．メインマイクロホ

理を使うことで，側方成分を利用した主方向成分の効果

ンとして単一指向性のSchoeps MK4+CMC6をプロセニア的な強調といったことも期待できる．

ム（客席からみて舞台を額縁のように区切る構造物）付近のステージバトンに左右それぞれ舞台中央から2メート

加えて音響的な出力レベルは弱いがユニークな楽器であルの位置に吊るした．アンビエントマイクとしては，無るテオルベ，チェンバロには個別集音のための近接マイ指向性のDPA4006を左右のサイドバルコニーにそれぞ

クが単一指向性マイクロホンを使って設置されている．

れ1つずつ設置するとともに，主階席の最後席にORTFマ

ポイントアレイマイクロホンとしては，それぞれ6個と8イクを設置した．これらは全て録音セッションを指示し個の単一指向性マイクロホンを利用した，3D XYZおよたプロの録音エンジニアの判断のもと，標準的な室内楽

び2D 360度アレイを設置すると共に，EigenmikeTMを設

オーケストラ録音用のマイクとして，最適な位置を選ん置した．3Dおよび2Dマイクは，それぞれGoProTMを6台

図4.1 オーケストラ収録のカメラとマイクの配置

31

組み合わせた三次元動画収録，およびRicoh ThetaTM Sを

4.1.2 Musilogue Bandジャズセッションの収録

使った二次元動画収録との組合せで収録された．また客2017年1月26日 に 六 本 木 ミ ッ ド タ ウ ン 内 に あ る

席エリア内の代表点にはダミーヘッドマイクと球体マイ

BillboardLiveTokyoでムジログプロジェクトのコンサー

クも設置されている．さらに主階席4点，バルコニー 2点トを収録した．リハーサル中に録音した映像，音声のコの合計6点にはスタンド上に取り付けたスマートフォン

ンテンツを格納し360Squareアプリケーションを作成しを設置し，これにより録画と録音を行った．2Dと3Dアレて，Live Music Hackasongで発表を行った（詳細は5章，

イマイク，Eigenマイク，スマートフォンはローカルのス

及び6章）
．

トレージに記録し，その他の全てのマイク出力はDante付のHead Amp Unitを介しIPネットワークで録音ブースに

編成はElectricPiano(Fender Rhodes)，Electric Bass，Drums

設置されたPC上のDAWに伝送された．また主階席後方にのinstrumentalである．会場のリスナーへの表現手法と設置したカメラで4k Videoも同時に撮影している．

しては全ての楽器にMic或いは電気信号を増幅する機材に接続し，SR(Sound Reinforcement)用MixingConsoleで収録した映像音声データはSDMによる魅力的なコンテ調整されたのちに大規模なSpeakerで再生される．音圧レンツ制作とアプリケーション開発に利用するため，視聴ベルは場所にもよるがおおよそ100dBsplとなる．

オブジェクトの概念を基礎とするデータベースを構築した．メディアデータとコンテンツ情報，位置情報などの映像データを収録するにあたりリコー社製品の全天球カ

メタデータを持つ視聴オブジェクトを基本単位として扱メラ「RICOH THETA S」
を8台配置した．

う．オブジェクト型の概念を使うことで，マイクで集音した複数の音から，音声オブジェクト化サービスによっ音声は全てSR(Sound Reinforcement)用Mixing-Consoleにてより上位の抽出された音を生成でき，それらに同じオ纏められていて，ConsoleのHA分岐をデジタルでDAWにブジェクトの構造を使うことが可能になる．次にこれら転送するシステムとなっている．録音される音量レベルのオブジェクトに意味情報を追加すれば，さらに上位層は全てMixingConsoleのSettingに依存する為，後に整音のオブジェクトを想定することができる．このようにこ作業が必須となる．

のデータベースには，下位層から意味情報を付加することで一つ上の層を生成できる再起的な構造を持たせた．

回線は図4.2の通りである．

さらに例えば従来型録音で典型的に使われるマイク群をひとまとめにしたさらに上位層のオブジェクトなども作成している．このデータベースはこのように階層的にオブジェクトを構成することでその意味的（Semantic）な価値を向上させることを意図している．
今回作成したデータベースでは，GoProTM，RicohThetaTM
S，4Kビデオカメラ，スマートフォンと4種類の映像デー
タを位置情報とコンテンツ情報を付与して管理している
ため，コンテンツやアプリケーションを作成する際，上記の音声データと組み合わせて利用することが容易である．音声データと同様，映像でも映像オブジェクト化サービスを利用し，収録対象を解釈したより上位のデータに変換し階層的にデータベースに格納することを想定するが，上位のデータの作成は今後の課題である．
図4.2 マイク回線のリスト

32

舞台内のMicrophoneSettingについては楽器単体の他に3つ目は，目的に応じた表現のレベルが設定出来るといAudienceマイクを4本設置する．音源より近いポジショ

うことである．汎用と固有の情報を分離することで，様々ンとしてステージ袖の上手，下手に1本ずつ、もう2本はなユースケースに対応可能となる．例えば「合唱コンクー

天井から無指向性のDPA4090を2本つりさげてのSetting

ル」のようなイベント単位から「演奏者」のようなユースとした．

ケース固有のレイヤまで表現出来る必要がある．

NearのMicはステージの角の位置，高さ1mくらいの所に

上記の条件を満たすデータベースの形式として，本研究

settingする．Farについてはステージから奥に5m，高さ5m

ではRDF・LODによるデータの管理を行う．

のところにセンターを中心に約1mの幅で2本設置した．
4.2.2 RDF・LOD
録音したデータを編集用のDAWにてDrmsMix，BassMix，

インターネットが普及した現代において，web上に存在

Piano(Rhose)Mix，Ambience near L，R Ambience far L，する無数のデータが検索によって容易に手に入るようにR，それぞれ楽器ごとの単体で纏め上げた音源に編集し，なった．また，自分の持つデータを世界中の人々とシェ

アプリケーションに組み込む作業を行う．

アするために，オープンデータとしてインターネット上に公開することも可能となった．こうした状況において

4.2

アプローチ

保有するデータをオープンデータとして広く利用しても4.2.1 要求事項

らうには，誰もが容易に利用できる形式，または機械がSDMは，3次元映像音声メディアをオブジェクト指向で管自動的に処理可能な形式で公開することが望ましい．

理し，映像・音響の視聴空間と視聴メディアの設計を行うことを目的としている．その実現には，上述のコンサート

データの公開方式の評価方法として，World Wide Web

ホールでの収録のように多数のデバイスを用いて記録しの考案者であるTimothy Berners-Leeは5 Star

た視聴空間のデータを管理する方法が必要となる．SDM

Open Data＊2というものを提案している．

のデータベースの要求事項は以下の3つが挙げられる．
これは，公開するデータの形式を5段階で評価したもので
1. 3次元映像音声メディアを管理出来ることあり，1段階目から3段階目までは次のような形式での公2. アプリケーションに非依存な形式で保存されていること開を表している．

3. 表現のレベルに応じてデータが取得できること
1. pdfやjpgでの公開：文章データをjpgで公開すると1つ目は，3次元映像音声メディアを管理するのに特化した形式，すなわちデータの性質を詳しく表せる形式で保存するということである．

いった，自動処理が困難である形式での公開
2. xlsやdocでの公開：特定のアプリケーション以外では前処理なしに扱うことのできない形式での公開
3. csvやtsvでの公開：データ解析において一般的に用い2つ目は，様々なアプリ開発に利用可能な形式で保存するられている形式での公開ということである．SDMデータを用いたアプリには，
ユー
ザとインタラクティブな挙動を示すアプリや，パッケー

こ の 指 標 の4段 階 目 で はRDF(Resource Description

ジメディアのミキシング，半自動ミキシングなどが考え

Framework)＊3という形式を推奨している．

られる．どのようなアプリでもデータを利用できるよう，
特定の用途にスペシフィックではなく汎用的な形式で保これによって記述されたデータはURIによって参照可能

存することが必要となる．

であり，機械による自動処理に適している．このRDFが外＊2＊3

http://5stardata.info/en/
https://www.w3.org/RDF/

33

部と連携したものはLOD(Linked Open Data)と呼ばれ，5ており，録音トラックには音声入力のためのマイク(Mic)Star Open Dataの最高レベルである5段階目となっている．

を関連付けてある．さらにマイクには録音対象の演者

LODの形式でデータを公開することでweb上のデータ同士(Performer)が関連付けてあり，録音データの内容を表現がリンクしあい，オープンデータの利用が推進される．

する手がかりとしている．また,録音トラックにはシグナ
ルオブジェクト(Signal)が関連付けてある．シグナルオブ

4.3

三次元視聴オブジェクトのデータ管理

ジェクトには録音データの格納場所のリンクが埋め込ま三次元視聴オブジェクトのデータ管理はデータの制作，れており,このリンクを辿ることでシグナルオブジェクト

加工，利用において想定される機能要求を満たすため，

から録音データを取り出すことができる．図中の色分け

以下の通り管理されるべきである．

は，データベースを作成する際に便宜上取り決めたグルー
プを表している．また，グレーアウトした部分は将来拡張

4.3.1 三次元視聴オブジェクトに関するLinkedOpen Dataの定義用とし今回は使用しなかったクラスである．以上のクラス
構造は音声データの記録にフォーカスして設計したもの

データの制作の利便性や，加工，利用における機能性や応である．映像データの記録を行う場合は，Micの代わりに用の自由度を高めるために，三次元視聴オブジェクトは記VideoCameraを 定 義 し，Recorder，Track，Signal各 ク ラ

録対象の構成や作業フローの実態に即したデータ構造をスの属性データを映像データの取扱に合わせて適切に変持たせる必要がある．図4.3はコンサート全体を表現する

更することで表現が可能である．

ことをスコープとして設計した三次元視聴オブジェクトのクラス構造である．一番上位にあるコンサートオブジェ

4.3.2 データベース構成とアプリケーション利用

クト(Concert)がコンサート全体を表現し，会場(Facility)と図4.4は三次元視聴オブジェクトを表現するLinked Open

そのコンサートの演目(Program)に関連付けてある．演目

Dataデータベースの構成である．
SDM LODServerには個々には楽曲(Song)を関係づける．演目を演じる側のオブジェの三次元視聴オブジェクトを表現しているjsonld形式のクトとして演者(Performer)を定義した．そのサブクラスとjsonファイルを格納する．データ制作の便宜を考慮し，1して演奏パート(Part)，楽器(Instrument)，演奏者(Player)，

つのjsonファイルには上記クラス構造をグループ化した

オーケストラ(Orchestara)がある．三次元視聴オブジェク

上で記述している．jsonファイルが表現するそれぞれのトを記録する行為及び記録物を定義するためのオブジェ

オブエクトファイルの記載内容は以下の通りである．

クトとしてレコーディングイベント(RecordingEvent)とシグナル(Signal)を定義した．レコーディングイベント

コンサートオブジェクトファイルはConcert，Facility，

は録音機器(Recorder)と録音トラック(Track)で構成されProgram，Songクラスの属性情報を、パフォーマーオブ
ジェクトファイルはInstrument等のPerformerクラスの属性情報を、レコーディングイベントオブジェクトファイ
ルはRecordingEvent, Recorder, Track, Micクラスの属性情図4.3 三次元視聴オブジェクトのクラス構造

34

図4.4 データベース構成

報を一括して記録している．またシグナルオブジェクト

有効化・無効化できるように管理される．

ファイルはSignalクラスを記述しており，そこからMedia

また，その3次元モデルの中に単一の視聴点を定義して，FileServer上のメディアファイルがリンクされている．

その場所で聞こえる音をバイノーラル合成する．その際，音の減衰率やリバーブ効果をつけるなどの処理を追加可

データベースを利用するアプリケーションは任意のキー能である．また，移動速度によって音声のドップラー効

ワードでデータベースクエリを行い，上記jsonファイル

果を付与することも想定する．同様に，その場所で見えを取得する．jsonldの規定に従いデータ構造とその表現る映像を生成しディスプレイで再生する．映像にも移動の意味を解釈・認識することで，リンクされたオブジェク

や実際には収録されてない物などを仮想的に追加するな

トを次々と取り出すことができる．結果的にアプリケー

どの処理を追加できる．

ションが必要とするメタデータやメディアファイルを取り出すことが可能となる．

ユーザのタッチ動作のインタラクションより，視聴オブジェクトの状態を有効化・無効化でき，さらに視聴点を自第５章 360Square:インタラクティブな自由視聴点での三次元映像音声の再生

由に移動したりできる．また，頭部動作により向いた方
向に視聴方向を移動できる．
5.1.2 ユーザインターフェイス

SDMコンソーシアムでは3章で述べた三次元映像音声コ「360Square」は，HMDで鑑賞に応用できるが，現在は簡ンテンツの協調制作フレームワークのコンセプトを元易なインタラクティブ性を重視してタブレットの入出力に，インタラクティブに自由視聴点での三次元映像音声機器を想定して開発する．

を再生するアプリケーション「360Square」を開発した．
ユーザは，ヘッドホンからバイノーラル出力を受け両耳
現在，360Squareでは，収録した慶應義塾大学のクラシッ

で音を聴取し，ディスプレイにより映像を視認する．

クコンサートと，ビルボードライブ・ジャパンで収録した
ジャズのセッション（4.1節参照）を視聴できる．

一方，ユーザからのインタラクションは，表5.1に示す，
スクリーンのタッチ動作で行う．視聴点自体を移動させユーザは，収録された演奏が行われている三次元空間をる通常モードと，位置は固定し視線を移動させる位置固ステージと観客席を含めインタラクティブに自由に移動

定モードによって，タッチ動作による結果が異なるが，そでき，360Squareはその地点で見える映像と聞こえる音

れぞれ1指ドラッグ，2指回転，2指ピンチをサポートする．

声を再生する．また，演奏されている楽器や演奏パート
を音声にズームインしたり，それらを自由に有効化・無効化することができる．
5.1

設計

360Squareの全体の設計概要を図5-1に示し，映像音声の処理とユーザインターフェイスに分けて解説する．
5.1.1 インタラクティブ映像音声の処理
視聴オブジェクトデータベースから取り出した映像と音声のメディアは，それに付随するメタデータを元にあらかじめ作成しておいた空間三次元モデルの上に配置され
る．配置された視聴オブジェクトは状態を持ち，自由に

図5.1 360 Squareの設計

35

また，視聴点の移動に関しては，画面に常に表示される体で示される音声オブジェクトの配置が見やすい視聴点

ボタンUIを設置し，プリセットされた位置と視線に移動に移動した時の映像である．実際に複数の場所で収録さできるように設計する．

れた音声は，3次元モデル上に配置され，UnityのAudio
Listernerと呼ばれるコンポーネントを利用して，その聴さらに視線移動に関しては，タブレットのジャイロセン

取点で聞こえるようバイノーラル合成されている．図中

サーを使い，タブレットの向いている方向を取得して，(1)で示されるように，実際には見えない音を音量に大き視点移動できるモードを用意する．

さの変化する白い輪によって可視化する映像効果を追加した．また，図中(2)で示される通り音声オブジェクトに5.2

タッチすることで，その音声のパートの有効化・無効化す

実装

360Squareは，Unity Version 5.5.0f3を用いて開発した．

ることができ，無効化された音声オブジェクトは回転が止まり，音声可視化の白い輪が消える．図中(3)に示す通本アプリケーションは起動すると360Squareロゴが現り，各音声オブジェクトにはメタデータが付属しており，

れ，コンテンツ選択画面へ遷移する．現在選択可能なコ

タッチによってそのメタデータが詳細表示に切り替わ

ンテンツは，慶應義塾大学のクラシックコンサートと，る．また，図中(4)の映像オブジェクトをタッチすること

ビルボードライブ・ジャパンでのジャズのセッション

で，視聴点がその映像オブジェクトの位置へ移動し，位（4.1節参照）である．

置固定モードに切り替わる．

クラシックコンサートを選択すると図5.2に示すクリー

位置固定モードのスクリーンショットを図5.4に示す．

ンショットのようなヘルプ画面に遷移して，使い方を提示する．ユーザは使い方を理解したのち，「Start」ボタンを押下することにより，コンテンツ視聴が開始する．
コンテンツ視聴は，図5.3に示すクリーンショットのような画面で行われる．図5.3は図中で音符を描画した立方表5.1 タッチ動作

図5.3 通常モードのスクリーンショット

図5.2 360 Squareのヘルプ画面

36

図5.4 位置固定モードのスクリーンショット

位置固定モードでは，Ricoh Theta Sで撮影された360

ファイラはCPU使用率，レンダリング，メモリ，オーディ度動画を，球体内部に投影して360度ビューを実現してオの4種類の結果を報告する．大きく影響すると思われる

い る．こ れ は，Easy Movie Texture(v3.56)が 提 供 す る

GPUについては，該当機器では情報を取得できなかった

MediaPlayerCtrlスクリプトによって実現している．位置ため，GPU使用率の分析は今後の課題である．

固定モードにおいても，同様にタッチ動作により音声オ
ブジェクトの有効化・無効化が可能である（図中(5)）．ま図5.5にビルボードでのジャズセッションのコンテンツ

た，図中(6)に示す通り，ドラッグによって視線を全周に（8個の360度動画と，7個のオーディオ音源が含まる）を移動させることができる．図中(7) 〜 (10)は，通常モード

表示した際のCPU使用率，レンダリング，メモリ，オーと位置固定モードの両方に常に表示されるボタンUIの説

ディオの変動を示す．X軸は，コンテンツ開始からのフ明である．図中(7)のボタン群は，タッチ動作によりステー

レームの番号である．変動は，全ての操作イベントの発ジや客席などのプリセット位置へと移動するためのボタ

生ではなく，視聴点が移動するイベントの影響が多かっンである．図中(8)は，音声オブジェクトを操作しやすい

たため，図5-5では，影響の大きかったイベントのみを表

ステージ上の視聴点へ移動するボタンであり，スクリー示した．

ンショットを図5-3に示した．図中(9)，(10)のボタンにより，ユーザはいつでも自由にヘルプ画面を参照し，コ全体として測定した値は，それぞれ図5.2 〜 5.4で示した，

ンテンツ選択画面へ遷移することができる．

ヘルプ画面，通常モード，位置固定モードの3つの傾向のカテゴリに別れた．図5.5のグラフでは，それぞれの代表

5.3

的な値を示す位置にY軸の値を示している．

性能評価

本節では前節で解説した実装を用いて実験による性能評価を行う．実験で用いた機器はmacOS Sierra(Version

CPU利用率では，全体として概ね30フレーム/秒を維持し10.12.3)が イ ン ス ト ー ル さ れ たMacBook Pro(15-inch,ていることがわかる．また，ヘルプ画面表示とイベント

2016)である．プロセッサは2.9 GHz Intel Core i7，メモリ発生時は，最も処理が遅くなっているが，それ以外の時は16 GB 2133 MHz LPDDR3であり，グラッフィックチッ

間には60フレーム/秒の性能を維持できている．全体としプはRadeon Pro 460 4096 MBと，Intel HD Graphics 530て最もCPU時間を消費しているプロセスは，360度動画

1536 MBを搭載している．

を球体内面に貼り付けるMediaPlayerCtrlスクリプトであり，8つの360度動画の貼り付けを行うためのCPU時間が実験は，Unity Version 5.5.0f3のエディタ上で360Square

全体の66.0%を占めている．図5.5では，MediaPlayerCtrl

を実行し，マウスで操作し，各イベントのタイムスタン

スクリプトの処理が大半を占めるスクリプト処理が，ヘプを記録することでイベント発生時のUnityのプロファ

ルプ画面，通常モード，位置固定モードの代表的な値そイラの分析結果を確認することで行った．Unityのプロ

れぞれで，11.4ms，11ms，9.6msの時間がかかってい図5.5 360Squareの性能評価

37

る．ヘルプ画面では，その他，ステージの全景を描画する

オ7つのコンテンツをインタラクティブに自由視聴点にための時間が，5.9msかかっており，フレームレートがおいて，問題なく再生を行うことができた．

落ちる原因となっている．
レ ン ダ リ ン グ で は，最 終 的 なDrawCall数 を 意 味 す る

第６章

SDM試作システムを利用したハッカソンの開催

Batches数，マ テ リ ア ル へ のDrawCall数 を 意 味 す る
SetPass calls数，三角メッシュ数，頂点数を示している．

2017年1月26日にビルボードライブ東京で「ライブ体験

表5.1に示すとおり，全ての値が，ヘルプ画面，通常モーの拡張」
をテーマとして行われたハッカソン【LIVE MUSICド，位置固定モードの順に減少していることがわかる．

HACKASONG】にて360Squareのデモンストレーションを行った．審査員と約100名の一般の来場者は，Musilogue

メモリ使用量は，全体を通して小刻みな増減を繰り返す

Bandの実際のジャズ演奏を聴いてから，事前にリハー

ものの，表示しているモードによる違いは見られなかっサル収録してあったデータから，360Squareで視聴できた．メモリ使用量は，実験を通して全体で2.5GB 〜 2.7GBるというデモンストレーションを行った．また，本イベほどであった．内訳としては，ネイティブコードへのメモ

ントは，イベント運営に当たったビルボードジャパンにリ割り当て量（Unity）が420MB，全体のヒープサイズとよってLINE live＊4を利用して，スマートフォン及びPCでマネージドコードが使用しているヒープサイズ（Mono）

ライブ視聴できるように放送されており，のべ3000人をが1.94GBほどであった．また，ドライバがTexture，レン

超える視聴があった．

ダリングのターゲット，Shader，Meshデータに使用している推定メモリ量（GfxDriver）が，約100MB，プロファ

また，審査員にはipad Pro及びipad air2を渡して手元でイラーデータに使用されているメモリ量（Profiler）が約鑑賞できるようにしたほか，一般の来場者にはUnityから20MBであった．

出力されるステレオ音声出力を舞台の左右に設置されているスピーカから放送し，スクリーンにはUnityのPlay画

オーディオは，実験を通してほぼ変動しなかった．実験

面を表示することで鑑賞できるようにした．

を通じて7つの音源が再生されていた．これは，ユーザ操
作によって無効化された音源も，有効化した時に演奏のまた，最終審査では360Squareが自由な視聴点から聞きずれがないように停止することなくミュートしていたたたい音にフォーカスできる点が評価され，審査員と一般めである．オーディオドライバが使用している推定メモの来場者からなる投票で，10組の中から優秀賞をを受賞

リ量（FMOD）が約300MB，CPU利用率は約1%であった．

した．デモンストレーション，及び審査・受賞の様子は，様々なメディアで掲載された．数例を以下に挙げる．

本 節 で は，360Squareを 動 作 さ せ たMacbook Proで のUnityのCPU使用量，メモリ使用量，レンダリング，オー
ディオの統計を調べた．360度動画の映像8つ，オーディ・（公式イベントサイト）LIVE MUSIC HACKASONG |Special | Billboard JAPAN＊5
・“ライブ体験の拡張”を目指すハッカソン，ビルボー

表5.1 各モードにおけるレンダリングの数

ド ラ イ ブ 東 京 に て 最 終 審 査 が 開 催| Daily News |Billboard JAPAN＊6
・“ラ イ ブ 体 験 の 拡 張”を テ ー マ に し た ハ ッ カ ソ ン「Live Music HACKASONG」最終審査・表彰式を開催|
Musicman-NET＊7

＊4
＊5
＊6
＊7

38

http://live.line.me
http://www.musicman-net.com/business/64896.html
http://www.billboard-japan.com/d_news/detail/46826/2
http://www.musicman-net.com/business/64896.html

図6.1は，最優秀賞と優秀賞のチームがステージ上で受賞や公式ホームページといったイベント関係の情報を記述している様子である．図6.2は，受賞後の懇談会で，SDMすることが出来る．

チームとスポンサー企業のNapsterの最高技術責任者
3つ目はFriend-of-a-friend ontology＊10である．これは“the（CTO）で行なった撮影である．

artist of this classic song is Johann Sebastian Bach”といっ
第７章

た，人物に関係する情報や人間関係を記述するための関連研究

ontologyであり，様々なLODにおいて広く用いられている．

RDF・LODを用いたデータ管理の研究は，データベースを以上のオントロジーを元に，音楽に関係する情報を記構築するための語彙の研究や，実際にRDF・LODを用いた

述するための語彙を追加・再定義したものがThe Music

アプリケーションの作成に関する研究などがある．

Ontologyである．具体的には“performed in”,“conductor”,“recorded in”,“remix of”などといった，演奏や楽曲の情報

語 彙 の 定 義 に 関 す る 研 究 と し て，Y.Raimondら[11]にを詳しく表すための語彙が定義されている．

よ るThe Music Ontologyの 研 究 が あ る．The Music
Ontologyは，音楽に関するメタデータを詳細に記述す

また，RDF・LODで管理されているデータを用いたアプることを目的として構築されたRDF Vocabularyである．

リケーションの研究例として，T. Di Noiaら[12]による映The Music Ontologyは，3つのontologyを元に構築され画のリコメンドシステムの研究を紹介する．この研究で＊8ている．1つ目のontologyはthe TimelineOntology であは，ユーザの嗜好を表すuser profileという値と，映画間る．これは時刻(time instant)・時間間隔(time interval)・時の類似度を表すsimilaritiesという値を組み合わせて学習

間の流れ(timeline)を表現することを目的として構築されさせている．

たオントロジーであり“this performance happened the
9th of March, 1984”といったデータをRDFで記述するこ

ユーザの嗜好を計算するのにNoiaらが用いたデータセッとが出来る．

トは，MovieLens＊11というものである．これはリコメン
デーションシステム開発やベンチマークのために作成さ2 つ 目 は the Event Ontology＊9で あ る．“this musical

れた，映画のレビューについてのデータセットである．

event was performed in Suntory Hall in Tokyo”のようなNoiaらが用いたバージョンには，6,040のユーザによる，イベントの情報を記述するためのontologyであり，場所

3,952の映画に対する，1,000,029のレビューが含まれて

図6.1 Live Music Hackasongでの授賞式の様子

図6.2 Live Music Hackasongでの授賞式の様子

＊8
＊9
＊10
＊11

http://purl.org/NET/c4dm/timeline.owl
http://purl.org/NET/c4dm/event.owl
http://xmlns.com/foaf/0.1/
https://movielens.org/

39

いる．このデータセットから，各ユーザの嗜好を計算する．

Dataに関する動向調査を行い，関連研究としてまとめた．

また，映画間の類似度を計算するのに用いたデータは，
DBpedia[13], LinkedMDB[14], Freebase[15]と い うLOD

SDMコンソーシアムでは，ソフトウェア処理による視聴から抽出された，MovieLensで扱っている映画に関係す

空間の制御，映像音声を制御するネットワーク機器，イ

るRDFのグラフである．類似度は，ある映画とある映画がンタラクティブ・ユーザインターフェイス，SDMプラッ「どれだけ同じ情報を共有しているか」によって計算されトホームを利用したコンテンツ作成など，共同研究活動

る．例えば「主演が同じである」「ジャンルが同じである」に参加するパートナーを募集しています．

といった内容がRDFで記述されている場合，高い類似度となる．

ご協力をよろしくお願いいたします．

こうしてRDF・LODから計算された映画間の類似度と，ユーザの嗜好のデータを組み合わせることで，高精度なリコメンドシステムを構築することに成功している．
これにより，あるユーザがある映画に対してどのような評価を下すかを推定し，高評価を下すと推定された映画がリコメンドされることとなる．

第８章

まとめ

本報告書では，2014年より開始したSDMコンソーシア
ムで進めて来た，視聴空間サービスのソフトウェア制御による研究で，2016年度に行なった活動について報告した．その中で，以前より策定を進めて来たSDMアーキ
テクチャに基づき，三次元映像コンテンツの協調制作のフレームワークを構想し，その開発を進めて来た．実際に，オーケストラのコンサートの収録とジャスセッショ
ンの収録を行い，実験を進めるための素材データを取得した．さらに，三次元映像メディアは収録データをオープンに公開し，自由なコンテンツ制作を促進するため，
オープンデータ化の仕様について策定を進めた．また，収録データを自由な視聴点においてインタラクティブに再生するアプリケーション「360Square」を設計，実装
し，評価を行なった．さらに，ビルボードジャパンが開催したLive Music Hackasongにおいて360Squareのデモン
ストレーションを行った．このインベントで，審査員と一般の来場者の投票により，優秀賞を受賞した．三次元
映像メディアのオープンデータ化を実施するにあたり，
様々なオープンデータがどのように定義，利用されている か，Resource Description FrameworkとOpen Linked

40