(57)【要約】【課題】受信装置側で映像の方向を適切に知ることができるようにすることを課題とする。【解決手段】映像送信装置１０１のＣＰＵ１１７は、第１の映像から二つ以上の異なる方向に対応した二つ以上の第２の映像が生成された際の二つ以上の方向を表す方向データを生成する。また、ＣＰＵ１１７は、映像受信装置１０２が第２の映像を取得する際に用いられる送信ＵＲＬを生成する。そして、ＣＰＵ１１７は、第２の映像と送信ＵＲＬおよび方向データとをそれぞれ関連付けたメタデータを生成する。【選択図】図１
2019118026.tif 000002
【特許請求の範囲】
【請求項１】
第１の映像から二つ以上の異なる方向に対応した二つ以上の第２の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成手段と、
受信装置が前記第２の映像を取得する際に用いられるアドレス情報を生成するアドレス生成手段と、
前記二つ以上の前記第２の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記メタデータを前記受信装置に送信する送信手段を更に有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第１の映像から前記二つ以上の異なる方向に対応した前記二つ以上の前記第２の映像を生成する映像生成手段を更に有することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記映像生成手段は、前記第１の映像から、画像の特徴が異なる前記二つ以上の前記第２の映像を生成することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記映像生成手段は、前記第１の映像から、それぞれ中心が異なる前記二つ以上の前記第２の映像を生成することを特徴とする請求項３または４に記載の情報処理装置。
【請求項６】
前記映像生成手段は、前記二つ以上の前記第２の映像に対し、前記方向に応じた所定の処理を行うことを特徴とする請求項４または５に記載の情報処理装置。
【請求項７】
前記映像生成手段は、前記方向に応じて映像圧縮のビットレートを変える前記所定の処理を行うことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記映像生成手段は、前記方向に応じて画質を変える前記所定の処理を行うことを特徴とする請求項６に記載の情報処理装置。
【請求項９】
前記映像生成手段は、更に映像の中心領域と周辺領域とで異なる画質となるように前記所定の処理を行うことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記二つ以上の前記第２の映像が生成される際の前記第１の映像は３６０度全方位映像であり、
前記映像生成手段は、前記二つ以上の第２の映像として、前記３６０度全方位映像から二つ以上の正距円筒映像を生成することを特徴とする請求項３から９のいずれか１項に記載の情報処理装置。
【請求項１１】
前記二つ以上の前記第２の映像が生成される際の前記第１の映像は３６０度全方位映像であり、
前記映像生成手段は、前記二つ以上の第２の映像として、前記３６０度全方位映像から二つ以上の立方体投影映像を生成することを特徴とする請求項３から９のいずれか１項に記載の情報処理装置。
【請求項１２】
前記方向情報生成手段は、回転座標系のロール、ピッチ、ヨーの各方向を表す方向情報を生成することを特徴とする請求項１から１１のいずれか１項に記載の情報処理装置。
【請求項１３】
前記方向情報生成手段は、予め定めた方向を表す記号を前記方向情報として用いることを特徴とする請求項１から１２のいずれか１項に記載の情報処理装置。
【請求項１４】
前記アドレス情報は、ＵＲＬ、もしくはＵＲＬにより特定されるメディアファイルの一部を特定する情報の組み合わせであることを特徴とする請求項１から１３のいずれか１項に記載の情報処理装置。
【請求項１５】
請求項１から１４のいずれか１項に記載の情報処理装置を備える送信装置と、
前記情報処理装置により生成された前記メタデータの前記アドレス情報および前記方向情報を基に、前記第２の映像を取得する前記受信装置と、
を有することを特徴とするシステム。
【請求項１６】
情報処理装置が実行する情報処理方法であって、
第１の映像から二つ以上の異なる方向に対応した二つ以上の第２の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成工程と、
受信装置が前記第２の映像を取得する際に用いられるアドレス情報を生成するアドレス生成工程と、
前記二つ以上の前記第２の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成工程と、
を有することを特徴とする情報処理方法。
【請求項１７】
コンピュータを、請求項１から１５のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像データ等に関するメタデータを扱う技術に関する。
【背景技術】
【０００２】
近年、ＨＴＴＰを代表とするＷｅｂ技術を用いて映像データを送信し、Ｗｅｂブラウザを用いてこの映像を再生する映像ストリーミング技術が広く使われるようになっている。特に広く使われる技術の特徴の一つは、送信しようとする映像データに関するメタデータを先に交換し、このメタデータを用いて実際の映像データを受信装置から送信装置に要求する形式である。
【０００３】
このような形式において、映像データの解像度への要求の高まりと共に、高解像度映像の特定部分を取得する方法が提案されている。
従来、例えば映像データから映像の特定位置部分を空間的に切り出して送信するメタデータの記載方法として、ＭＰＥＧ−ＤＡＳＨ  ＳＲＤ仕様があり、これは例えば非特許文献１に開示されている。なお、メタデータには、全方位映像等の映像全体に対する相対位置と切り出される矩形映像のサイズとを記述することが可能となされている。また、例えば魚眼画像のような全方位画像を視覚的に見やすいパノラマ展開画像として再生する際に、容易に方向を特定するために、基準となる方向をメタデータとして映像に付随させる方法があり、これは特許文献１等に開示されている。その他にも、全方位映像等から、中央位置や主要な位置を変えた複数の映像を生成する技術も知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−２７０１２号公報
【非特許文献】
【０００５】
【非特許文献１】ＩＳＯ／ＩＥＣ  ２３００９−１：２０１４／Ａｍｄ２：２０１５
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、受信装置側では、前述したメタデータの記述を基に映像データの配信を要求する際、全方位映像等の映像全体から切り出し等された矩形映像が、その全方位映像の中の何れの方向に相当する映像であるのかを知ることができない。このため、受信装置は、全方位映像の中で表示したい方向の映像の配信を要求することが難しい。
【０００７】
そこで、本発明は、受信装置側で映像の方向を適切に知ることができるようにすること目的とする。
【課題を解決するための手段】
【０００８】
本発明は、第１の映像から二つ以上の異なる方向に対応した二つ以上の第２の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成手段と、受信装置が前記第２の映像を取得する際に用いられるアドレス情報を生成するアドレス生成手段と、前記二つ以上の前記第２の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成手段と、を有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、受信装置側で映像の方向を適切に知ることができるようになる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態の情報処理システムの構成を示すブロック図である。
【図２】３６０度映像を正距円筒映像へと変換する例を示す図である。
【図３】映像の変換から伝送までの流れを示すフローチャートである。
【図４】ＭＰＥＧ−ＤＡＳＨを例としたメタデータの例を示す図である。
【図５】３６０度映像を立方体へと変換した例を示す図である。
【図６】ＭＰＥＧ−ＤＡＳＨを例としたメタデータの他の例を示す図である。
【図７】円筒から２４０度映像を生成する例を示す図である。
【図８】マニフェストファイルの他の例を示す図である。
【図９】マニフェストファイルのさらに他の例を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態を添付の図面を参照して詳細に説明する。なお、以下に説明する実施形態は、本発明を具体的に実施した場合の一例を示すものであり、本発明は以下の実施形態に限定されるものではない。
＜第１実施形態＞
図１は、第１実施形態の映像送信装置１０１と映像受信装置１０２を有する情報処理システムの構成例を示す図である。
【００１２】
映像送信装置１０１は、映像データを、ネットワーク１０３を介して送信可能な情報処理装置である。映像受信装置１０２は、映像データを、ネットワーク１０３を介して受信可能な情報処理装置である。本実施形態では、一例としてＭＰＥＧ−ＤＡＳＨを用いた映像ストリーミング送信を行う例を挙げる。詳細については後述するが、映像送信装置１０１は、ＭＰＥＧ−ＤＡＳＨに準拠した映像データを生成するような映像生成処理を行い、また、送信する映像に関するメタデータを生成して送信可能となされている。映像受信装置１０２は、先に取得したメタデータを用いて、ＭＰＥＧ−ＤＡＳＨに準拠した映像データの配信を要求可能となされている。なお、映像送信装置１０１により生成された映像データは、映像受信装置１０２からの要求に応じて送信されるが、例えばＷｅｂサーバ１０４に蓄積された後に映像受信装置１０２へ配信されてもよい。
【００１３】
映像送信装置１０１は、通信機能を備えたカメラとして実現してもよいし、必要に応じて一つ以上のコンピュータ装置により実現するようにしてもよい。本実施形態では、一例として、二つの魚眼レンズ１１１を備えた全方位カメラを備えた映像送信装置１０１を挙げている。
【００１４】
映像受信装置１０２は、通信機能を備えたテレビジョン受像機といった専用装置として実現してもよいし、必要に応じて一つ以上のコンピュータからなる装置として実現するようにしてもよい。また、映像受信装置１０２は、ヘッドマウントディスプレイ（ＨＭＤ）などで実現されてもよい。本実施形態では、コンピュータとそこで動作する映像再生アプリケーションプログラム（以下、映像再生アプリとする。）により映像受信装置１０２の機能を実現する例を挙げる。
【００１５】
図１において、映像送信装置１０１では、魚眼レンズ１１１から取り込まれた光が光学センサ１１２により電気信号に変換され、さらにＡ／Ｄコンバータ１１３によりデジタル化されて画像信号処理回路１１４で映像としての処理が行われる。なお、本実施形態の映像送信装置１０１は、魚眼レンズ１１１と光学センサ１１２の撮像系の組み合わせを二組備えている。本実施形態では、二組の撮像系のうち、一方が１８０度の画角で空間領域を撮像し、もう一方が隣接する１８０度の画角で空間領域を撮像することで、全方位の３６０度映像を取得可能としている。Ａ／Ｄコンバータ１１３は、二つの光学センサ１１２に対応して物理的に二つ設けられているが、図１では図示の簡略化のために一つだけを記載している。
【００１６】
このように二組の撮像系によりそれぞれ取得された画角１８０度の魚眼画像の信号は、画像信号処理回路１１４に送られる。画像信号処理回路１１４は、二組の撮像系にて取得された１８０度魚眼画像から３６０度全方位映像を生成し、その３６０度映像を後述する正距円筒図法（Equirectangular）と呼ばれる形式の映像に変換する。圧縮符号化回路１１５は、画像信号処理回路１１４により正距円筒図法の形式に変換された３６０度映像データから、ＭＰＥＧ−ＤＡＳＨに準拠した圧縮映像データを生成する。本実施形態の場合、圧縮符号化回路１１５で生成された圧縮映像データは、例えばメモリ１１９に一時的に保持され、映像受信装置１０２からの送信要求に応じて通信回路１１６からネットワーク１０３に出力される。なお、圧縮符号化回路１１５で生成された圧縮映像データは、Ｗｅｂサーバ１０４等に蓄積された後、映像受信装置１０２等からの要求に応じてＷｅｂサーバ１０４から配信されてもよい。
【００１７】
ＲＯＭ１１８は、変更を必要としないプログラムやパラメータを格納するリードオンリメモリである。メモリ１１９は、外部装置などから供給されるプログラムやデータを一時記憶するＲＡＭ（ランダムアクセスメモリ）である。ＣＰＵ１１７は、映像送信装置１０１全体を制御する中央処理ユニットであり、例えばＲＯＭ１１８から読み出されてメモリ１１９に展開された本実施形態に係るプログラムを実行する。また、ＣＰＵ１１７は、プログラムの実行により、映像データに関するメタデータを生成する処理も行う。本実施形態の場合、詳細は後述するが、メタデータには、送信される映像に関する送信ＵＲＬと方向データが含まれる。なお、図示は省略しているが、映像送信装置１０１は、映像データを記録するなどの目的で、着脱可能な半導体メモリ等の記憶メディアとその記憶メディアの書込み／読出し装置等を備えていてもよい。
【００１８】
映像受信装置１０２は、コンピュータ等からなり、ＣＰＵ１２１、通信Ｉ／Ｆ部１２２、ＲＯＭ１２３、ＲＡＭ１２４、操作部１２５、表示部１２６、大容量記憶部１２７等を有する。
通信Ｉ／Ｆ部１２２は、ネットワーク１０３を介してＷｅｂサーバ１０４や映像送信装置１０１等と通信可能となされている。本実施形態の場合、通信Ｉ／Ｆ部１２２は、前述したメタデータの受信、映像ストリーミングの圧縮映像データの配信要求の送信、当該配信要求に応じて配信された圧縮映像データの受信等を行う。
【００１９】
ＲＯＭ１２３は、各種プログラムやパラメータを格納し、ＲＡＭ１２４はプログラムやデータを一時記憶する。大容量記憶部１２７はハードディスクドライブやソリッドステートドライブであり、通信Ｉ／Ｆ部１２２により受信された圧縮映像データや、映像再生アプリ等を記憶可能となされている。ＣＰＵ１２１は、大容量記憶部１２７から読み出されてＲＡＭ１２４に展開された映像再生アプリ等を実行する。本実施形態の場合、ＣＰＵ１２１は、映像再生アプリの実行により、先に取得したメタデータに含まれる後述する送信ＵＲＬに基づき、ＭＰＥＧ−ＤＡＳＨに準拠した映像データの取得を行わせるように各部を制御する。そして、圧縮映像データを取得すると、ＣＰＵ１２１は、その圧縮映像データを伸張復号化して、表示部１２６に送る。表示部１２６は、液晶等のディスプレイ装置を有し、ＣＰＵ１２１により伸張復号化された映像データに基づく映像を表示する。操作部１２５は、ユーザが指示等を入力する際のマウスやキーボード、タッチパネル等を有し、ユーザからの指示入力をＣＰＵ１２１に出力する。なお、映像受信装置１０２がＨＭＤである場合には、姿勢変化を検出可能なセンサ等も有する。
【００２０】
＜正距円筒図法の概要説明＞
本実施形態では、映像送信装置１０１の画像信号処理回路１１４において、３６０度映像を正距円筒映像へと変換する例を挙げている。３６０度映像を正距円筒映像へと変換しているのは、一般的な矩形映像を生成することで映像圧縮や表示が行い易くなるといった理由からである。なお、画像信号処理回路１１４では、後述する第２実施形態で説明するような正立方体へ投影（Cubic  Projection）する変換処理が行われても良いし、さらに後述する第３実施形態等のような他の変換処理が行われてもよい。また本実施形態では、二つの魚眼レンズ１１１からなる全方位カメラを例示したが、一般的なレンズを多数組み合わせた全方位カメラでも良いし、一つの魚眼レンズ１１１のみで画角１８０度を撮影する１８０度カメラでもよい。なお、１８０度カメラを用いた場合には、レンズを例えば天空（上方向）に向けたときには下方向の画角１８０度分が撮像されない映像となるだけである。
【００２１】
ここで、３６０度映像を正距円筒映像へと変換する例について、後の説明をより明確にするため、図２（ａ）〜図２（ｄ）を用いてもう少し説明を行う。
図２（ａ）において、球状の仮想的な映像面２０１は、その中心部に位置する３６０度カメラから見た３６０度映像を表し、映像面２０１を包み込む円筒２０２は、球状の仮想的な映像面２０１を正距円筒映像へと変換した面を表している。円筒２０２上の一点鎖線Ａ，Ｂ，Ｃは、球面での経線にあたる線を表している。球状の映像面２０１における回転座標系の方向をロール（ｒ）、ピッチ（ｐ）、ヨー（ｙ）の各方向で表した場合に、一点鎖線Ａは、ヨー方向の角度０度で表される経線にあたる線（ｙ：０）である。同様に、一点鎖線Ｂはヨー方向の角度１２０度で表される経線にあたる線（ｙ：１２０）、一点鎖線Ｃはヨー方向の角度２４０度で表される経線にあたる線（ｙ：２４０）である。
【００２２】
図２（ｂ）〜図２（ｄ）は、３６０度映像である図２（ａ）の球状の仮想的な映像面２０１を、正距円筒映像へと変換した例を示した図である。
図２（ｂ）は、図２（ａ）の映像面２０１を正距円筒映像へと変換し、ヨー方向の角度０度の経線にあたる一点鎖線Ａ（線（ｙ：０））を中心線として、円筒２０２を展開した映像を表している。なお、この図２（ｂ）に示した正距円筒映像は、映像受信装置１０２において表示が行われる際に、例えば水平方向の両端部が繋がれた場合、水平方向３６０度の全方位映像としての表示が可能となる。
【００２３】
また、図２（ｃ）は、ヨー方向の角度１２０度の経線にあたる一点鎖線Ｂ（線（ｙ：１２０））を中心として円筒２０２を展開した正距円筒映像である。同様に、図２（ｄ）は、ヨー方向の角度２２０度の経線にあたる一点鎖線Ｃ（線（ｙ：２４０））を中心として円筒２０２を展開した正距円筒映像である。これら図２（ｃ）、図２（ｄ）に示した正距円筒映像も図２（ｂ）と同様に、映像受信装置１０２で表示される際に、正距円筒映像を水平方向の両端部で繋ぐことで、水平方向の３６０度全方位映像として表示可能となる。
【００２４】
これら各円筒２０２，２０６，２０７は、仮想的な映像面２０１を正距円筒映像へと変換した図という点で同じであり、異なるのは正距円筒映像へと変換された矩形の中心線が一点鎖線Ａ，Ｂ，Ｃとなっている点である。これは正距円筒映像への変換の際にどこを中心として切り出すかの違いと言い換えることもできる。
【００２５】
また、これら図２（ａ）〜図２（ｄ）からも明らかなように、球の天頂にあたる部分はそれぞれ円筒２０２，２０６，２０７の上端の円へと拡大されている。このため、正距円筒図法で変換された映像は、球の赤道面から極方向へ離れるにしたがって拡大されて、いびつな形となる。また、図２（ａ）中の太陽の形のオブジェクト２０３と星形のオブジェクト２０５は、球の中心に置かれた３６０度カメラにより写されるオブジェクトの一例を示している。図２（ａ）に示したオブジェクト２０３，２０５は、正距円筒図法で変換された図２（ｂ）〜図２（ｃ）の円筒２０２，２０６，２０７上では、それぞれオブジェクト２０４，２０８のように映ることになる。
【００２６】
＜ＭＰＥＧ−ＤＡＳＨに準拠した映像データ及びメタデータ生成処理と送信＞
次に、正距円筒図法で変換された映像を圧縮符号化して伝送する際の流れを、ＭＰＥＧ−ＤＡＳＨの例を用いて説明する。
図３は、本実施形態の映像送信装置１０１において、正距円筒図法で変換された映像を圧縮符号化して伝送するまでの制御処理の流れを示すフローチャートである。以下の説明では、図３のフローチャートの各ステップＳ３０１〜ステップＳ３０７をＳ３０１〜Ｓ３０７と略記する。図３のフローチャートの処理は、ソフトウェア構成またはハードウェア構成により実行されてもよいし、一部がソフトウェア構成で残りがハードウェア構成により実現されてもよい。ソフトウェア構成により処理が実行される場合、例えばＲＯＭ１１８に記憶されている本実施形態に係るプログラムをＣＰＵ１１７が実行して各部を制御することにより実現される。本実施形態に係るプログラムは、ＲＯＭ１１８に予め用意されていてもよく、また着脱可能な半導体メモリ等から読み出されたり、インターネット等のネットワークからダウンロードされたりしてもよい。この図３のフローチャートの処理は、３６０度映像の取得がなされる毎に行われる。
【００２７】
先ず、Ｓ３０１において、ＣＰＵ１１７は、前述した３６０度映像を正距円筒映像へと変換する際の中心方向を複数決定する。本実施形態の場合、複数の中心方向は、前述の図２（ａ）〜図２（ｄ）で説明したヨー方向における経線の角度で表される三つの線（ｙ：０），（ｙ：１２０），（ｙ：２４０）にそれぞれ対応した三つの中心方向が決定される。なお、本実施形態では、三つの中心方向を例に挙げたが、これは一例であり三つの方向に限定する必要はない。例えば、角度０度の経線にあたる線（ｙ：０）と、角度１８０度の経線にあたる線（ｙ：１８０）のように１８０度分だけ回転した二つ方向であってもよい。角度０度の経線にあたる線（ｙ：０）の方向を正面とすると、角度１８０度の経線にあたる線（ｙ：１８０）の方向は背面となる。また、ヨー方向にも限定されず、緯度方向に相当するピッチ方向等であってもよい。
【００２８】
次に、Ｓ３０２において、ＣＰＵ１１７は、画像信号処理回路１１４を制御し、前述のように撮像されて取得された３６０度映像から、Ｓ３０１で決定した三つの中心方向にそれぞれ対応した三つの正距円筒映像を生成させる。すなわちこの時の画像信号処理回路１１４は、一つの３６０度映像から、正距円筒図法への変換により、それぞれ中心方向が異なる図２（ｂ）〜図２（ｄ）で示したような三つの正距円筒映像を生成する。
【００２９】
次に、Ｓ３０３において、ＣＰＵ１１７は、圧縮符号化回路１１５を制御し、Ｓ３０２で生成された三つの正距円筒映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路１１５からは、三つの正距円筒映像にそれぞれ対応した三つの圧縮映像データが生成される。そして、これら三つの圧縮映像データは、映像受信装置１０２からの要求があった場合に、当該映像受信装置１０２へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置１０２へ送信可能な場所にコピー等される。具体的には、メモリ１１９、或いはＷｅｂサーバ１０４等に格納される。
【００３０】
次に、Ｓ３０４において、ＣＰＵ１１７は、それら三つの圧縮映像データの場所を表すアドレス情報であるＵＲＬを生成するアドレス生成処理を行う。すなわち、ＣＰＵ１１７は、アドレス生成処理として、映像受信装置１０２が映像データの配信を要求する際に使用される送信ＵＲＬを生成する。そして、Ｓ３０５において、ＣＰＵ１１７は、それら三つの圧縮映像データにそれぞれ対応した送信ＵＲＬを、ＭＰＥＧ−ＤＡＳＨのメタデータに記録する。本実施形態において、メタデータは、ＭＰＥＧ−ＤＡＳＨにおけるマニフェストファイル或いはＭＰＤファイルである。
【００３１】
さらに、Ｓ３０６において、ＣＰＵ１１７は、Ｓ３０１で決定した中心方向を表す方向情報（以下、方向データとする。）を生成する方向情報生成処理を行う。本実施形態の場合、三つの圧縮映像データに応じた三つの送信ＵＲＬが生成されるため、ＣＰＵ１１７は、方向情報生成処理として、それら三つの送信ＵＲＬに対応した三つの方向データを生成する。
【００３２】
そして、ＣＰＵ１１７は、Ｓ３０７において、それら各方向データをそれぞれ対応した送信ＵＲＬと関連付けて、メタデータに記録する。このＳ３０７の後、図３のフローチャートの処理は終了する。その後、このメタデータは、通信回路１１６からネットワーク１０３を介して映像受信装置１０２に送られる。これにより、映像受信装置１０２は、受信したメタデータに記録されている送信ＵＲＬと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
【００３３】
＜メタデータの概要＞
図４は、ＭＰＥＧ−ＤＡＳＨを例とした場合のメタデータ（ＭＰＤ）の一例を示した図である。なお、ＭＰＥＧ−ＤＡＳＨにおいてメタデータはマニフェストファイルと呼ばれることがあり、図４ではマニフェストファイル４０１として示している。
【００３４】
図４に示したマニフェストファイル４０１には、３つのリプリゼンテーション４０２，４０３，４０４が含まれている。リプリゼンテーションは、ＭＰＥＧ−ＤＡＳＨにおいて一つの映像や音声などを状況によって切り替えられるようにする単位である。一番目のリプリゼンテーション４０２には、映像を取得するためのＵＲＬに加えて、ｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：０"の記述を含んでおり、これが前述のＳ３０６で生成された方向データである。方向データは、回転座標系のロール（ｒ）、ピッチ（ｐ）、ヨー（ｙ）の各方向を表すデータを含んでいる。二番目のリプリゼンテーション４０３も同様に方向データを含んでいる。リプリゼンテーション４０３の方向データは、ヨー（ｙ）方向のみが１２０（ｙ：１２０）となっており、リプリゼンテーション４０２で示される方向に対しヨー方向（水平方向）に１２０度回転したものであることを示している。三番目のリプリゼンテーション４０４も同様に方向データを含んでいる。リプリゼンテーション４０４の方向データは、ヨー（ｙ）方向のみが２２０（ｙ：２２０）となっており、リプリゼンテーション４０２で示される方向に対しヨー方向に２４０度回転したものであることを示している。そして、これらリプリゼンテーション４０２〜４０４の何れの方向データを選ぶかにより、前述した図２（ｂ）〜図２（ｄ）の線（ｙ：０）〜（ｙ：２４０）の何れかを中心とした映像の送信を要求するかを決定できることになる。
【００３５】
例えば、図４のマニフェストファイル４０１を受信した映像受信装置１０２のユーザが再生表示を望む方向が、例えば図２（ｂ）の線（ｙ：０）を中心（ｒ：０，ｐ：０，ｙ：０）とした映像の方向であるとする。この場合、映像受信装置１０２のＣＰＵ１２１は、ｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：０"の方向データに対応した、リプリゼンテーション４０２に記述された送信ＵＲＬに基づいて、圧縮映像データを取得する。これにより、映像受信装置１０２では、図２（ｂ）の線（ｙ：０）を中心とした正面（ｒ：０，ｐ：０，ｙ：０）の映像の再生表示が可能となる。例えば、再生表示を望む方向が図２（ｃ）の線（ｙ：１２０）を中心とした映像である場合には、ｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：１２０"に対応したリプリゼンテーション４０３の送信ＵＲＬから圧縮映像データが取得される。これにより、映像受信装置１０２では、図２（ｃ）の線（ｙ：１２０）を中心とした映像の再生表示が可能となる。
【００３６】
また例えば、再生表示を望む方向が、線（ｙ：０）を正面とした場合の背面、つまり経線の１８０度（ｙ：１８０）の方向であるような場合、ＣＰＵ１２１は、リプリゼンテーション４０３又は４０４の送信ＵＲＬの何れかを取得する。これは、リプリゼンテーション４０３による中心の線（ｙ：１２０）とリプリゼンテーション４０３による中心の線（ｙ：２４０）は、経線の１８０度（ｙ：１８０）から何れも６０度のずれがあり、同等であると考えられるからである。したがって、再生表示を望む方向が１８０度（ｙ：１８０）の背面映像に指定された場合、映像受信装置１０２では、リプリゼンテーション４０３又は４０３の何れか選択された送信ＵＲＬから取得された映像が再生表示されることになる。
【００３７】
なお、再生表示を望む方向が、図２（ｂ）の線（ｙ：０）を中心とした映像の方向である場合、水平方向の３６０度全方位映像の繋ぎ目は、中心の線（ｙ：０）に対して経線で１８０度分だけずれた位置（正面に対し真後ろの位置）となる。つまりこの場合の繋ぎ目は、映像受信装置１０２のユーザからみて背面側となるため、ユーザから目につき難くできるメリットがある。また、再生表示を望む方向が１８０度の線（ｙ：１８０）を中心とする方向の場合、取得されるのは中心線が線（ｙ：１２０）又は線（ｙ：２４０）の映像となる。このため、水平方向の３６０度全方位映像の繋ぎ目は、１８０度の線（ｙ：１８０）から近い方が経線で６０度分だけずれた位置となるが、映像の中央からは離れているためユーザから見てさほど目立たないと考えられる。
【００３８】
ここでは、水平方向（ヨー方向）の３６０度全方位映像の表示を行う場合の映像の繋ぎ目について述べたが、前述したような方向データを記録することによるメリットは、必ずしも繋ぎ目の処理に関するものだけではない。
【００３９】
＜パン方向の映像を生成する例＞
先に述べたように、正距円筒図法で変換された映像は、球の赤道面から極方向に距離が離れるに従いゆがみが大きくなっていく。このため、例えば線（ｙ：０）を正面（ｒ：０，ｐ：０，ｙ：０）とした映像を用いて、天頂（ｒ：０，ｐ：９０，ｙ：０）の映像を得ることは、必ずしも好ましくない。この場合、天頂（ｒ：０，ｐ：９０，ｙ：０）の映像が予め生成されているのであれば、この映像を用いて天頂側の映像を再生表示することが望ましい。
したがって、本実施形態では、パン方向（球の緯度方向）についても、前述したヨー方向の場合と同様にして複数の映像データを生成し、また前述同様のメタデータ生成処理も行う。これにより、天頂側でもゆがみの少ない映像を得ることが可能となる。
【００４０】
＜映像圧縮ビットレートを変更する例＞
さらに本実施形態の他の例として、中心となる線からの距離に応じて映像圧縮のビットレートを変更する例について、前述した図２（ａ）〜図２（ｄ）を流用して説明する。
【００４１】
図２（ａ）や図２（ｂ）に示した円筒２０２は、前述したように、一点鎖線Ａが中心となる正距円筒映像である。ここで、映像受信装置１０２において映像が再生される際に、再生表示を望む方向として、一点鎖線Ａが中央になる方向に指定されて映像表示が行われると仮定する。この場合、例えば一点鎖線Ｂと一点鎖線Ｃとの間の映像部分、つまり一点鎖線Ａの中心部分を正面とした場合の後ろ側に相当する部分の映像は、正面部分の映像よりも重要度が低いと考えられる。すなわち、図２（ｂ）の円筒２０２の場合、例えば太陽の形のオブジェクト２０４の重要度は高く、星形のオブジェクト２０５の重要度は低いと考えられる。そして、重要度が低い映像部分については、例えば映像圧縮のビットレートを低くしたとしても、視認性に及ぼす影響は少ないと考えられる。
【００４２】
このため、本実施形態において、映像送信装置１０１のＣＰＵ１１７は、圧縮符号化回路１１５を制御し、中心となる線（Ａ）からヨー方向に離れるに従い、映像圧縮のビットレートを例えば低くする。言い換えると、中心となる線に近くなるほど、映像圧縮のビットレートが高くなるようにする。これにより、図２（ｂ）の太陽の形のオブジェクト２０４を含む領域の映像圧縮ビットレートは高く、一方、星型のオブジェクト２０８を含む慮域の映像圧縮ビットレートは低くなされる。同様に、図２（ｃ）の円筒２０２の場合には、中心となる線（Ｂ）から離れるに従い映像圧縮のビットレートが低くなされる。これにより、太陽の形のオブジェクト２０４を含む領域の映像圧縮ビットレートは低く、星型のオブジェクト２０８を含む慮域の映像圧縮ビットレートは低くなされる。
【００４３】
また前述したように、映像受信装置１０２では、線（ｙ：０）を正面とした映像の再生表示がなされる場合には、図４のリプリゼンテーション４０２に記述された送信ＵＲＬを基に映像データが取得される。また、線（ｙ：１２０）を中心とした映像の再生表示がなされる場合には、図４のリプリゼンテーション４０３に記述された送信ＵＲＬを基に映像データが取得される。ここで、前述のように中心の線に近いほど映像圧縮ビットレートが高くなる制御が行われているため、それら何れの場合も、中央部の映像は画質劣化が少ない映像となり、ユーザは視認性の良い映像を鑑賞できる。一方で、中心の線から離れるほど映像圧縮ビットレートが低くなる制御が行われているため、映像データを取得する際の伝送ビットレートが全体として低く保たれることになる。
【００４４】
＜回転座標系以外の記述例＞
前述した説明では、方向データとして、例えば（ｒ：０，ｐ：０，ｙ：０）のような回転座標系で表される情報を用いた例を挙げた。ここで、このような回転座標系の情報は、例えば正規化された直交座標系の情報に容易に変換することができる。すなわち、回転座標系の方向データ（ｒ：０，ｐ：０，ｙ：０）は、（ｘ，ｙ，ｚ）＝（０，０，０）のような直交座標系の方向データとして記述されてもよい。
或いは、方向データは、図４の一番目のリプリゼンテーション４０２やその他の所定の方向を基準として、相対角による表される方向データとして記述されても良い。例えば（ｒ：０，ｐ：０，ｙ：０）を正面とした映像に対して、後ろ側（ｒ：０，ｐ：０，ｙ：１８０）のようにして方向を示す代わりに、（ｙａｗ＋１８０）といった記述例も考えられる。方向データとしてこれら何れの記述形式を用いるかは、本実施形態が適用されるシステムに応じて適宜設定可能である。
【００４５】
以上説明したように、第１実施形態においては、メタデータを用いて映像の場所（送信ＵＲＬ）を特定する形式において、全方位映像等の広視野映像から方向を変えて生成した複数の映像と各方向データとを関連付けてメタデータに記述する。したがって、映像受信装置１０２は、メタデータに記述された送信ＵＲＬと方向データを参照することにより、全方位画像等の広視野映像のなかで、再生表示したい方向に応じた好適な映像を取得可能となる。
【００４６】
＜第２実施形態＞
第１実施形態では、３６０度映像を正距円筒映像へと変換する例を挙げた。以下の第２実施形態では、３６０度映像を立方体（Cubic）の形式に変換する例を説明する。第２実施形態における映像送信装置１０１、映像受信装置１０２等の構成は、図１と同様であるため、図示は省略する。
【００４７】
第２実施形態の場合、映像送信装置１０１の画像信号処理回路１１４は、前述した３６０度映像を後述するように立方体の形式に変換し、さらに当該立方体を展開して立方体展開映像を生成する。そして、圧縮符号化回路１１５は、画像信号処理回路１１４により立方体を展開した立方体展開映像の映像データから、ＭＰＥＧ−ＤＡＳＨに準拠した圧縮映像データを生成する。また、ＣＰＵ１１７は、立方体展開映像に関するメタデータ生成処理を行う。第２実施形態の場合のメタデータに記述される方向データの詳細は後述する。そして、第２実施形態の映像受信装置１０２は、メタデータに含まれる送信ＵＲＬと方向データに基づき、ＭＰＥＧ−ＤＡＳＨに準拠した映像データを取得して表示部１２６に表示する。
【００４８】
以下、第２実施形態において３６０度映像を立方体の形式に変換して立方体展開映像を生成する例について、図５（ａ）〜図５（ｄ）、及び前述の図３のフローチャートを流用して説明する。
図５（ａ）において、球状の仮想的な映像面２０１は、前述同様に、その中心部に位置する３６０度カメラから見た３６０度映像を表している。太陽の形のオブジェクト２０３、星形のオブジェクト２０５についても前述同様のものである。第２実施形態の場合、球状の仮想的な映像面２０１は、立方体５０１に投影される。図５（ｂ）は、図５（ａ）の立方体５０１の面ｃを中心に展開した立方体投影映像５０２を示した図である。また、図５（ｂ）のオブジェクト２０４，２０８は、立方体投影映像５０２上に映っている図５（ａ）のオブジェクト２０３、２０５を表している。なおこの例では、立方体投影映像５０２は、面ｃを中心にして展開した形になっているが、例えば面ｂが面ｃを挟んで面ａの左側に、面ｅが面ａの右側に置かれるように展開して、横に３／４、縦に２／３の大きさの矩形とされても良い。
【００４９】
図５（ｃ）には、図５（ａ）の立方体５０１の面ａを中心に展開した立方体投影映像５０３を示している。別な表現をするならば、図５（ｂ）の立方体投影映像５０２は手前の太陽の形のオブジェクト２０４を中心としているのに対し、図５（ｃ）の立方体投影映像５０３では立方体の上側の面ａを中心とした例である。そして、第２実施形態において、これら図５（ｂ）の立方体投影映像５０２や図５（ｃ）の立方体投影映像５０３の映像データも前述同様に圧縮符号化されることになる。なお、立方体５０１の展開方法はこれらの例に限定されない。
【００５０】
ここで、図５（ｂ）の立方体投影映像５０２の場合、中心領域である面ｃを高画質化し、それ以外の周辺領域の面（ａ，ｂ，ｄ，ｅ，ｆ）は符号量を低下させる（画質を落とす）ように、画像の特徴を異ならせるとする。すなわち、図５（ｂ）の例の場合、映像送信装置１０１のＣＰＵ１１７は、立方体投影映像５０２に描かれた円５０５の中の領域が高画質となるように圧縮符号化回路１１５を制御する。図５（ｃ）の立方体投影映像５０３についても同様とする。これにより、太陽の形のオブジェクト２０４を中心に考えた場合、図５（ｂ）の立方体投影映像５０２を圧縮符号化した映像データを映像受信装置１０２で再生表示した場合、高画質のオブジェクト２０４の表示が可能となる。一方、映像受信装置１０２で再生表示する際に面ａを中心に考えた場合、図５（ｃ）の立方体投影映像５０３を圧縮符号化した映像データを再生表示すれば、面ａが高画質となった映像の表示が可能となる。
【００５１】
なお、図５（ｄ）の立方体投影映像５０４は図５（ｃ）の立方体投影映像５０２と同じ面の配置であり、この図５（ｃ）の例は高画質化する領域を表す円５０５の配置が、図５（ｂ）とは異なるだけであり、同様に処理を行うことができる。図５（ｄ）の立方体投影映像５０４の場合、円５０５で示される高画質化される領域は、面ａと面ｃの一部だけでなく、立方体において面ａとそれぞれ接する面ｄ、面ｆ、面ｅの一部も含まれることになる。
【００５２】
また、立方体投影映像５０２〜５０４の図中斜線の部分は映像が存在しないため、例えばスキップドマクロブロック（skipped macroblock）として符号化しないことで、大幅な符号量削減が可能となる。このようなことにより、第２実施形態では、ネットワーク１０３の全体としての通信量を下げながら、所定の面を高画質化した映像を映像受信装置１０２に対して送信することが可能となる。
【００５３】
第２実施形態において、変換された立方体投影映像を圧縮符号化して伝送する際の流れは、前述した図３のフローチャートと概ね同様である。ただし、第２実施形態の場合、３６０度映像を立方体投影映像に変換し、立方体投影映像と中心或いは高画質化等する所定の面とを関連付けた送信ＵＲＬがメタデータに記録される。
【００５４】
第２実施形態の場合、図３のＳ３０１において、映像送信装置１０１のＣＰＵ１１７は、３６０度映像を立方体投影映像へと展開する際の中心或いは高画質化等する所定の面を複数決定する。ここで決定される複数の所定の面は、例えば前述したような図５（ｂ）の面ｃや図５（ｃ）の面ａ、図５（ｄ）の面ａ等である。
【００５５】
次に、Ｓ３０２において、ＣＰＵ１１７は、画像信号処理回路１１４を制御し、前述した３６０度映像から、Ｓ３０１で中心面として決定された面を中心とした立方体投影映像をそれぞれ生成する。
さらに、Ｓ３０３において、ＣＰＵ１１７は、圧縮符号化回路１１５を制御し、Ｓ３０２で生成した各立方体投影映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路１１５からは、各立方体投影映像にそれぞれ対応した圧縮映像データが生成される。このとき、Ｓ３０１で高画質化するとして決定された面（円５０５に対応した円）については、圧縮符号化の際に前述するように高画質化の処理が行われる。そして、これら各立方体投影映像の各圧縮映像データは、映像受信装置１０２からの要求があった場合に、当該映像受信装置１０２へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置１０２へ送信可能な場所にコピー等される。
【００５６】
次に、ＣＰＵ１１７は、Ｓ３０４において、それぞれ圧縮映像データの場所を表すアドレス情報である送信ＵＲＬを決定し、さらにＳ３０５において、それら圧縮映像データにそれぞれ対応した送信ＵＲＬをメタデータに記録する。
【００５７】
さらに、ＣＰＵ１１７は、Ｓ３０６において、Ｓ３０１で中心或いは高画質化するものとして決定された所定の面を表す方向データを生成する。すなわち、第２実施形態の場合の方向データは、例えば図５（ａ）の映像面２０１の３６０度映像を立方体に投影した際の各面のうち、中心或いは高画質化される所定の面を表すデータとなされる。そして、ＣＰＵ１１７は、Ｓ３０７において、それら各方向データをそれぞれ対応した送信ＵＲＬと関連付けて、メタデータに記録する。
【００５８】
第２実施形態においても、このメタデータは、通信回路１１６からネットワーク１０３を介して映像受信装置１０２に送られる。これにより、第２実施形態の映像受信装置１０２は、受信したメタデータに記録されている送信ＵＲＬと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
【００５９】
＜第２実施形態の場合のメタデータの概要＞
図６は、第２実施形態において、ＭＰＥＧ−ＤＡＳＨを例としたメタデータの一例を示した図である。図６においても前述した図４と同様に、ＭＰＥＧ−ＤＡＳＨにおけるメタデータをマニフェストファイル６０１として示している。
【００６０】
図６のマニフェストファイル６０１には、第１実施形態で説明したのと同様に、三つのリプリゼンテーション６０３，６０４，６０５が含まれている。第２実施形態の場合、第１実施形態とは異なり、図３のＳ３０６で生成された方向データであるｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：０"といった記述が別途予め定義されている。ここでは、これをマップ６０２と呼ぶものとする。もちろん、このようなマップを使用せずに第１実施形態の例と同様に記述されていてもよい。マップ６０２には、さらにｖｉｅｗ＝"ｔｐ"といった記述も含まれている。これは、例えばｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：９０，ｙ：０"が上の方向を意味していることを、記号として記述したものである。また例えば、ｖｉｅｗ＝"ｆｒ"が前面、ｖｉｅｗ＝"ｂｋ"が背面のように方向を予め記号などで決めておくことで、より簡易に方向を示すことも可能となる。
【００６１】
図６において一番目のリプリゼンテーション６０３には、映像を取得するためのＵＲＬに加えてｄｉｒ＿ｉｄ＝"ｃ"の記述が含まれている。これは、マップ６０２におけるｒｐｙ＿ｍａｐｐｉｎｇ  ｄｉｒ＿ｉｄ＝"ｃ"を参照するよう指示するものである。このようにすることによって、リプリゼンテーションの記載を簡略化したり、柔軟な方向データ記載を可能としたりすることが可能となる。詳細な説明は省略するが、リプリゼンテーション６０４やリプリゼンテーション６０５も同様である。また、図６のような方向データの記述は、投影手法に依存せずに適用可能である。
【００６２】
前述したように、第２実施形態の映像送信装置１０１においては、３６０度映像を立方体投影映像に変換し、投影された所定の面を表す方向データをメタデータに記述する。これにより、第２実施形態の映像受信装置１０２においても、メタデータを基に、再生表示したい方向に応じた好適な映像を取得可能となる。
【００６３】
＜第３実施形態＞
前述した第１実施形態において、図２を用いて説明した３６０度映像を正距円筒映像へと変換する例は、円筒２０２の一部を用いて全周とならない映像を生成する場合にも適用可能である。第３実施形態は、円筒２０２の一部を用いて全周とならない映像を生成する場合の適用例である。
【００６４】
第３の実施形態では、円筒２０２の一部の全周とならない映像として、２４０度映像を生成する例を図７（ａ）〜図７（ｄ）を用いて説明する。
図７（ａ）は、前述した図２（ａ）と同様に、球状の仮想的な映像面２０１と、その中心部に位置する３６０度カメラから見た映像とを表しており、円筒２０２は映像面２０１を正距円筒図法で変換した映像である。また、円筒２０２上の一点鎖線Ａ，Ｂ，Ｃは、前述同様に球面での経線にあたる線である。
【００６５】
図７（ｂ）は、図７（ａ）の映像面２０１を正距円筒図法へと変換し、一点鎖線Ａ（線（ｙ：０））を中心線として円筒２０２から２４０度分を切り出した部分円筒映像７０１を表している。同様に、図７（ｃ）は一点鎖線Ｂ（線（ｙ：１２０））を中心線とし、図７（ｄ）は一点鎖線Ｃ（線（ｙ：２４０））を中心線として、円筒２０２からそれぞれ２４０度分を切り出した部分円筒映像７０２，７０３を表している。
【００６６】
これら図７（ｂ）〜図７（ｄ）のようにそれぞれ異なる中心線により２４０度分だけ切り出されたことで、例えば部分円筒映像７０２と７０３の中には部分円筒映像７０１に含まれていない映像部分が存在することになる。同様に、部分円筒映像７０１と７０３の中には部分円筒映像７０２に含まれていない映像部分が、部分円筒映像７０１と７０２の中には部分円筒映像７０３に含まれていない映像部分が、それぞれ存在することになる。すなわち例えば、映像受信装置１０２で部分円筒映像７０１により太陽の形のオブジェクト２０３を鑑賞するような場合、その投影されたオブジェクト２０４は鑑賞できるが、星形のオブジェクト２０５の投影されたオブジェクト２０８は鑑賞できない。但し、映像受信装置１０２が例えばＨＭＤであるような場合、ＨＭＤの装着者が例えば一定方向を見ている場合には、その反対側の映像は不要であることから、映像の一部が含まれていない場合でもさほど問題は生じないと考えられる。したがって、第３実施形態の場合も、前述の図４のマニフェストファイル４０１で示したように、方向データを用いて最適なリプリゼンテーションを取得すれば良い。
【００６７】
図８には、第３実施形態におけるメタデータの一例としてのマニフェストファイルの記述例を示している。第３実施形態においても前述したマニフェストファイル４０１を適用することは可能であるが、図８のマニフェストファイルには、さらにｒａｎｇｅ＝"ｙ：２４０"が記述されている。このように記述することで、図８のマニフェストファイルを参照した映像受信装置１０２は、対応するリプリゼンテーションがヨーの方向で２４０度の角度の映像を保持していることを知ることができる。なお、第３実施形態の場合においても、言うまでもなくロール方向やピッチ方向などを同時に用いてもよい。
【００６８】
前述したように、第３実施形態においては、円筒２０２の一部の全周とならない映像データが伝送されることになるため、伝送ビットレートを更に低減することが可能となる。また、第３実施形態においても第１実施形態の場合と同様に、中心の線に対応する中心領域の映像圧縮ビットレートを高くし、周辺領域の映像圧縮ビットレートを低くしてもよい。
【００６９】
＜第４実施形態＞
前述した第１〜第３実施形態では、ＭＰＥＧ−ＤＡＳＨ及びマニフェストファイルの例を用いて説明を行ってきた。第４実施形態では、このマニフェストファイルの異なる例を挙げる。図９は、図４を用いて説明したマニフェストファイルのさらに別な例を表した図である。
【００７０】
図９に示したマニフェストファイル９０１は、一見図４で説明したマニフェストファイル４０１と似た構造を持っている。しかしながら、図９のマニフェストファイル９０１の場合、一番目のリプリゼンテーション９０２のＳｅｇｍｅｎｔＵＲＬには、ｔｒａｃｋ＝"１"及びｔｒａｃｋ＝"２"が追記されている。これは、それぞれ、ｖｉｄｅｏ３１．ｍｐ４およびｖｉｄｅｏ３２．ｍｐ４の指定されたｔｒａｃｋ（トラック）を参照することを示している。すなわち、ｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：０"が指定されたリプリゼンテーション９０２は、ＳｅｂｍｅｎｔＵＲＬで指定されたメディアファイルの特定のトラックを取得することを意図して記載されている。
【００７１】
ここで、トラックについて簡単に説明する。この例では、メディアファイルは、ファイルの拡張子から想定できるように、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ  １４４９６−１２）を基礎としたファイル形式のメディアデータとなっている。このようなファイルでは、トラックと呼ばれる複数のメディアを格納する仕組みを備えている。すなわち、リプリゼンテーション９０２は、指定されたファイルの指定されたトラックに格納されたメディアファイル（メディアデータ）を用いることで、方向に合致したメディアを得るよう記載されている。連続した二つのメディアファイルが異なるトラックを指定しているのは、それぞれのメディアファイルが独立しており、異なるトラックに方向に合致したメディアが格納されていることを仮定しているためである。
【００７２】
一方、リプリゼンテーション９０３およびリプリゼンテーション９０４では、ｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：１２０"のような方向の記載の後に、ｔｒａｃｋ＝"１"及びｔｒａｃｋ＝"２"のような記載がある。また、リプリゼンテーション９０３及びリプリゼンテーション９０４のメディアデータは、同じものを指示している。すなわち、リプリゼンテーション９０３及びリプリゼンテーション９０４は、同じメディアデータを参照する。ここでは連続したメディアデータに共通のトラックが指定されているため、例えばリプリゼンテーション９０３では、同じトラックのｔｒａｃｋ＝"１"が連続したメディアデータに適用される。第３実施形態によれば、このようにすることで、同じメディアデータを用いながら方向を記載することができる。
【００７３】
＜その他の実施形態＞
以上、これまでＭＰＥＧ−ＤＡＳＨを例として説明してきたが、本実施形態は、ＭＰＥＧ−ＤＡＳＨに限らず、メタデータファイルとメディアファイルを組み合わせて映像を送信・受信するシステムにも適用できる。例えば、ＨＴＴＰ  ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇと通称される形式では、マニフェストファイルにｍ３ｕと呼ばれる形式を採用している。ここでは、同様にメディアデータの取得位置を記録するが、これに例えばｄｉｒｅｃｔｉｏｎ＝"ｒ：０，ｐ：０，ｙ：１２０"といった方向データを付加情報として追記することで前述同様のことを実現可能となる。
【００７４】
また、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、Ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、複数の分散した仮想コンピュータ群からなるクラウドシステムであってもよい。
【００７５】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００７６】
上述の実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明は、その技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００７７】
１０１：映像送信装置、１０２：映像受信装置、１０３：ネットワーク、１１４：映像信号処理回路、１１７：ＣＰＵ
【図１】
2019118026.tif 000003
【図２】
2019118026.tif 000004
【図３】
2019118026.tif 000005
【図４】
2019118026.tif 000006
【図５】
2019118026.tif 000007
【図６】
2019118026.tif 000008
【図７】
2019118026.tif 000009
【図８】
2019118026.tif 000010
【図９】
2019118026.tif 000011