(57)【要約】  本開示は、サブピクチャのストリームの選択をより容易に行うことができるようにする情報処理装置および方法に関する。格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを生成する。本開示は、例えば、情報処理装置、画像処理装置、画像符号化装置、ファイル生成装置、ファイル送信装置、配信装置、ファイル受信装置、画像復号装置、または再生装置等に適用することができる。
2019138928.tif 000002
【特許請求の範囲】
【請求項１】
格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部
を備える情報処理装置。
【請求項２】
前記全体ピクチャは、全天球映像である
請求項１に記載の情報処理装置。
【請求項３】
前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
請求項１に記載の情報処理装置。
【請求項４】
前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ピクチャ領域ごとの配置情報は、Region Wise Packing Boxにシグナルされる情報であり、
前記領域に関する情報は、Region Wise Packing Boxとは異なる、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
請求項３に記載の情報処理装置。
【請求項５】
前記領域に関する情報は、全体ピクチャがプロジェクテッドピクチャと同一であるかを示す情報である
請求項１に記載の情報処理装置。
【請求項６】
前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Sub Picture Composition Boxに格納される特定のBoxの有無によって示される
請求項５に記載の情報処理装置。
【請求項７】
前記ファイルは、前記全体ピクチャのステレオ表示に関する情報であるステレオ情報をさらに含む
請求項１に記載の情報処理装置。
【請求項８】
前記全体ピクチャは、全天球映像である
請求項７に記載の情報処理装置。
【請求項９】
前記ステレオ情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
請求項７に記載の情報処理装置。
【請求項１０】
前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ステレオ情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
請求項９に記載の情報処理装置。
【請求項１１】
前記ファイルは、前記サブピクチャの表示サイズに関する情報をさらに含む
請求項７のいずれかに記載の情報処理装置。
【請求項１２】
前記ファイルは、前記サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含む
請求項７に記載の情報処理装置。
【請求項１３】
前記ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
請求項７に記載の情報処理装置。
【請求項１４】
前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
請求項１３に記載の情報処理装置。
【請求項１５】
格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成する
情報処理方法。
【請求項１６】
格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
【請求項１７】
前記全体ピクチャは、全天球映像である
請求項１６に記載の情報処理装置。
【請求項１８】
前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
請求項１６に記載の情報処理装置。
【請求項１９】
前記領域に関する情報は、ストリーム中で動的に変化する
請求項１６に記載の情報処理装置。
【請求項２０】
格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得し、
取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および方法に関し、特に、サブピクチャのストリームの選択をより容易に行うことができるようにした情報処理装置および方法に関する。
【背景技術】
【０００２】
従来、HTTP（Hypertext Transfer Protocol）プロトコルによるアダプティブなコンテンツ配信技術の標準化規格として、MPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）がある（例えば、非特許文献１、非特許文献２参照）。【０００３】
また、このMPEG-DASHのファイルフォーマットとして、動画圧縮の国際標準技術「MPEG-4（Moving Picture Experts Group - 4）」のファイルコンテナ仕様であるISOBMFF（International Organization for Standardization Base Media File Format）がある（例えば、非特許文献３参照）。【０００４】
ところで、所謂全天球映像のような、水平方向の周囲360度および垂直方向の周囲180度の画像を立体構造に投影した画像である立体構造画像を、平面画像にマッピングした全天球画像（投影平面画像とも称する）の配信にMPEG-DASHを利用することが考えられている。例えば、立体構造画像を単数の平面にマッピングし、その立体構造画像が平面にマッピングされた投影平面画像として配信することにより、MPEG-DASHを適用することができる。その際、１つの全天球映像の投影平面画像（全体ピクチャとも称する）を複数のサブピクチャ（sub-picture）に分割し、複数のトラック（track）に格納することも提案されている。なお、sub-pictureの表示領域を識別する場合 には、まずsub-picture分割情報をもとにsub-pictureから全体ピクチャを構築したのちに、region-wise packing情報をもとにregion-wise packingされた全体ピクチャを配置しなおす処理が必要である（例えば、非特許文献４参照）。【０００５】
【非特許文献１】"Information technology . Dynamic adaptive streaming over HTTP (DASH) . Part 1: Media presentation description and segment formats", ISO/IEC23009-1, 2014/05
【非特許文献２】"Information technology . Dynamic adaptive streaming over HTTP (DASH) . Part 1: Media presentation description and segment formats AMENDMENT2: Spatial relationship description, generalized URL parameters and other extensions", ISO/IEC 23009-1:2014/Amd 2:2015, 2015/07
【非特許文献３】"Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", ISO/IEC 14496-12, 2005-10-01
【非特許文献４】Ye-Kui Wang, Youngkwon Lim,"MPEG#120 OMAF meeting agenda and minutes", ISO/IEC JTC1/SC29/WG11 MPEG2017/M41823, October 2017, Macau, China
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、現在提案されている方法では、sub-picture化がなされた場合、ピクチャ領域毎にサイズ・位置を変更した配置情報（分割前の全体ピクチャのregion-wise packing情報）は、Sub Picture Composition Boxの下のRegion Wise Packing Boxにシグナルされる。その為、sub-picture trackを選択・再生する場合、sub-picture trackのprojected picture上の表示領域を識別するために、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報とを識別する必要があり、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。【０００７】
本開示は、このような状況に鑑みてなされたものであり、サブピクチャのストリームの選択をより容易に行うことができるようにするものである。
【課題を解決するための手段】
【０００８】
本技術の一側面の情報処理装置は、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部を備える情報処理装置である。【０００９】
本技術の一側面の情報処理方法は、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成する情報処理方法である。【００１０】
本技術の他の側面の情報処理装置は、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部と、前記ファイル取得部により取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部とを備える情報処理装置である。【００１１】
本技術の他の側面の情報処理方法は、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得し、取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う情報処理方法である。【００１２】
本技術の一側面の情報処理装置および方法においては、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルが生成される。【００１３】
本技術の他の側面の情報処理装置および方法においては、格納されるサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルが取得され、その取得されたファイルに含まれる領域に関する情報に基づいて、画像符号化データのストリームの選択が行われる。
【発明の効果】
【００１４】
本開示によれば、情報を処理することができる。特に、サブピクチャのストリームの選択をより容易に行うことができる。
【図面の簡単な説明】
【００１５】
【図１】ISOBMFFのsub-picture trackのBox階層構造の例を示す図である。
【図２】ISOBMFFのsub-picture trackでないtrackのBox階層構造の例を示す図である。
【図３】Sub Picture Composition Boxのシンタックスの例を示す図である。
【図４】Sub Picture Region Boxのシンタックスの例を示す図である。
【図５】Sub Picture Region Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図６】Region Wise Packing Boxのシンタックスの例を示す図である。
【図７】Region Wise Packing Structのシンタックスの例を示す図である。
【図８】Region Wise Packing Struct内で定義されるフィールドのセマンティクスの例を示す図である。
【図９】RectRegionPackingのシンタックスの例を示す図である。
【図１０】RectRegionPacking内で定義されるフィールドのセマンティクスの例を示す図である。
【図１１】ファイル生成装置の主な構成例を示すブロック図である。
【図１２】クライアント装置の主な構成例を示すブロック図である。
【図１３】表示領域情報の例を示す図である。
【図１４】アップロード処理の流れの例を説明するフローチャートである。
【図１５】コンテンツ再生処理の流れの例を説明するフローチャートである。
【図１６】2D Coverage Information Boxのシンタックスの例を示す図である。
【図１７】2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図１８】表示領域情報の例を示す図である。
【図１９】不連続な領域を含むsub-pictureの例を示す図である。
【図２０】2D Coverage Information Boxのシンタックスの例を示す図である。
【図２１】この場合に追加されるフィールドのセマンティクスの例を示す図である。
【図２２】Region Wise Packing Structのシンタックスの例を示す図である。
【図２３】この場合に追加されるフィールドのセマンティクスの例を示す図である。
【図２４】RectProjectedRegionのシンタックスの例を示す図である。
【図２５】RectProjectedRegion内で定義されるフィールドのセマンティクスの例を示す図である。
【図２６】Region Wise Packing Structのシンタックスの例を示す図である。
【図２７】RectRegionPackingのシンタックスの例を示す図である。
【図２８】Coverage Information Boxのシンタックスの例を示す図である。
【図２９】Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図３０】Spherical offset projection SEI messageのシンタックスの例を示す図である。
【図３１】Spherical offset projection SEI message内で定義されるフィールドのセマンティクスの例を示す図である。
【図３２】2D Coverage Information Sample Entryのシンタックスの例を示す図である。
【図３３】2D Coverage Information Sampleのシンタックスの例を示す図である。
【図３４】Sample Table Boxの例を示す図である。
【図３５】2D Coverage Information Sample Group Entryのシンタックスの例を示す図である。
【図３６】アップロード処理の流れの例を説明するフローチャートである。
【図３７】コンテンツ再生処理の流れの例を説明するフローチャートである。
【図３８】2D coverage information descriptorの属性値の例を示す図である。
【図３９】2D coverage information descriptorの属性値の例を示す図である。
【図４０】データタイプの例を示す図である。
【図４１】Region Wise Packing descriptorの属性値の例を示す図である。
【図４２】Region Wise Packing descriptorの属性値の例を示す図である。
【図４３】Content coverage descriptorの属性値の例を示す図である。
【図４４】Content coverage descriptorの属性値の例を示す図４３に続く図である。
【図４５】データタイプの例を示す図である。
【図４６】データタイプの例を示す、図４５に続く図である。
【図４７】データタイプの例を示す、図４６に続く図である。
【図４８】sub-picture化の例を示す図である。
【図４９】sub-picture化の例を示す図である。
【図５０】sub-picture化の例を示す図である。
【図５１】アップロード処理の流れの例を説明するフローチャートである。
【図５２】コンテンツ再生処理の流れの例を説明するフローチャートである。
【図５３】Original Stereo Video Boxのシンタックスの例を示す図である。
【図５４】Original Stereo Video Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図５５】表示サイズのシグナルの例を示す図である。
【図５６】Pixel Aspect Ratio Boxのシンタックスの例を示す図である。
【図５７】Pixel Aspect Ratio Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図５８】表示時のピクセル縦横比のシグナルの例を示す図である。
【図５９】Original Scheme Information Boxのシンタックスの例を示す図である。
【図６０】2D Coverage Information Boxのシンタックスの例を示す図である。
【図６１】2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図６２】stereo_presentation_suitableのシグナルの例を示す図である。
【図６３】Track Stereo Video Boxのシンタックスの例を示す図である。
【図６４】2D Coverage Information Boxのシンタックスの例を示す図である。
【図６５】2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。
【図６６】view_idcのシグナルの例を示す図である。
【図６７】アップロード処理の流れの例を説明するフローチャートである。
【図６８】コンテンツ再生処理の流れの例を説明するフローチャートである。
【図６９】2D coverage information descriptorの属性値の例を示す図である。
【図７０】2D coverage information descriptorの属性値の例を示す、図６９に続く図である。
【図７１】データタイプの例を示す図である。
【図７２】コンピュータの主な構成例を示すブロック図である。
【図７３】Sub Picture Composition Boxのシンタクスの例を示す図である。
【図７４】Supplemental Propertyのシンタクスの例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．sub-pictureに関する情報のシグナル
２．第１の実施の形態（sub-pictureの表示領域のシグナル、ISOBMFFの拡張）
３．第２の実施の形態（sub-pictureの表示領域のシグナル、MPDの拡張）
４．第３の実施の形態（全体ピクチャのステレオ情報のシグナル、ISOBMFFの拡張）
５．第４の実施の形態（全体ピクチャのステレオ情報のシグナル、MPDの拡張）
６．付記
【００１７】
＜１．sub-pictureに関する情報のシグナル＞
＜技術内容・技術用語をサポートする文献等＞
本技術で開示される範囲は、実施の形態に記載されている内容だけではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
【００１８】
非特許文献１：（上述）
非特許文献２：（上述）
非特許文献３：（上述）
非特許文献４：（上述）
【００１９】
つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、実施の形態において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
【００２０】
＜MPEG-DASH＞
従来、例えば非特許文献１や非特許文献２に記載のように、HTTP（Hypertext Transfer Protocol）プロトコルによるアダプティブなコンテンツ配信技術の標準化規格として、MPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）がある。
【００２１】
このMPEG-DASHにより、例えば、ウェブサイトからインターネットのウェブページをダウンロードする場合と同様の通信プロトコルであるHTTPを用いて、ネットワーク帯域の変動に応じた最適なビットレートでのビデオ再生を実現することができる。
【００２２】
この標準規格により、動画配信サービスのためのインフラや動画再生クライアント向けの技術開発をより容易にすることができる。特に、配信サービスを手掛ける事業者にとっては、動画配信サービスと動画再生クライアントとの間の互換性が向上する他、既存のコンテンツ資産を活用しやすい利点があり、市場の成長を促進する効果が期待される。
【００２３】
MPEG-DASHは、主に、２つの技術企画で構成されている。動画や音声ファイルを管理するメタデータを記述したMPD（Media Presentation Description）と称するマニュフェストファイル仕様を定めた規格と、実際に動画コンテンツを伝達するためのセグメントフォーマット(segment format)と称するファイルフォーマットの運用規格である。
【００２４】
このファイルフォーマットとして、例えば非特許文献３に記載のように、動画圧縮の国際標準技術「MPEG-4（Moving Picture Experts Group - 4）」のファイルコンテナ仕様であるISOBMFF（International Organization for Standardization Base Media File Format）がある。ISOBMFFには、MPEG-DASHの要件を満たすための機能拡張がISO/IEC（International Organization for Standardization / International Electrotechnical Commission） 14496-12の拡張仕様として加えられた。
【００２５】
＜MPEG-DASHを用いた全天球映像の配信＞
ところで、所謂全天球映像のように、水平方向の周囲360度および垂直方向の周囲180度の画像を立体構造に投影した立体構造画像を、平面画像にマッピングした投影平面画像がある。例えば、視点から見た周辺の画像（全天球映像）をその視点を中心とする立体構造にレンダリングして立体構造画像とすることにより、視点の周辺の画像をより自然に表現したり、その立体構造画像から所望の視線方向の画像を容易に生成したりすることができる。
【００２６】
近年、この投影平面画像（全天球映像等）の配信にMPEG-DASHを利用することが考えられている。例えば非特許文献４に記載のように、立体構造画像を単数の平面にマッピングし、その立体構造画像が平面にマッピングされた投影平面画像として配信することにより、MPEG-DASHを適用することができる。
【００２７】
立体構造に投影し、平面へマッピングする方法（プロジェクションフォーマット（projection format）とも称する）として、例えば、ERP（Equirectangular projection（正距円筒））やCMP（Cubemap projection（キューブマップ））等がある。例えば、ERPの場合、水平方向の周囲360度および垂直方向の周囲180度の画像が球状の立体構造に投影された立体構造画像が、単数の平面に、球状の立体構造の緯度方向と経度方向とが直交するようにマッピングされる。また、例えばCMPの場合、水平方向の周囲360度および垂直方向の周囲180度の画像が立方体の各面に投影された立体構造画像の各面が展開され、単数の平面に所定の順に並べるようにマッピングされる。
【００２８】
このように全天球映像が投影・マッピングされた投影平面画像をプロジェクテドピクチャ（projected picture）とも称する。つまり、projected pictureとは、projection format毎に決まる、全天球映像を表現する２次元画像（２次元picture）のことである。
【００２９】
非特許文献４に記載のMPEG-I Part2 Omnidirectional Media Format（ISO/IEC 23090-2）FDIS（Final Draft International Standards）（以下、OMAFとも称する）では、１つの全天球映像の投影平面画像（全体ピクチャとも称する）を複数のサブピクチャ（sub-picture）に分割し、複数のトラック（track）に格納する技術の議論がなされている。
【００３０】
例えば、特定の視野領域ごとに、視野に対応するサブピクチャトラック（sub-picture track）を構成し、クライアントは自身の視野領域に応じてそのsub-picture trackを選択・再生する、といったユースケースがある。
【００３１】
＜ISOBMFFファイルのBox階層構造＞
図１のBox階層構造１１は、全天球映像をsub-picture track化する場合のISOBMFFファイルのBox階層構造の例を示す。
【００３２】
Box階層構造１１に示されるように、この場合、Track Group Boxの下に全体ピクチャについての情報が格納される。例えば、Sub Picture Composition Box（spco）には、ピクチャがsub-picture化されているか等の、sub-picture trackのgroupingに使用される情報が格納される。また、その下には、Sub Picture Region Box（sprg）、Region Wise Packing Box（rwpk）、Stereo Video Box（stvi）等のBoxが形成される。
【００３３】
Sub Picture Region Boxには、sub-pictureの分割の仕方等を示すsub-picture分割情報が格納される。また、Region Wise Packing Boxには、分割前の全体ピクチャのregion-wise packing情報が格納される。また、Stereo Video Boxには、全体ピクチャのステレオ表示（立体視表示）に関する情報（ステレオ情報）が格納される。ステレオ情報とは、例えばサイドバイサイド（side by side）やトップアンドボトム（top & bottom）等、立体視表示用画像の種類などを示す情報である。
【００３４】
また、Media Box（mdia）の下のMedia Information Box（minf）の下のSample Table Box（stbl）の下のSample Description Box（stsd）の下のRestricted Sample Entry（resv）（Sample Entryの一種）の下のRestricted Scheme Information Box（rinf）の下のScheme Information Box（schi）の下には、Projected Omnidirectional Video Box（povd）、StereoVideoBox（stvi）等のBoxが形成される。
【００３５】
Projected Omnidirectional Video Boxには、全天球映像に関連するメタデータが格納される。StereoVideoBoxには、そのBoxが対応するsub-pictureについてのステレオ情報が格納される。
【００３６】
図２のBox階層構造１２は、全天球映像をsub-picture track化しない場合のISOBMFFファイルのBox階層構造の例を示す。
【００３７】
Box階層構造１２に示されるように、この場合、Track Group Boxは形成されず、Region Wise Packing Boxは、Projected Omnidirectional Video Boxの下に形成される。
【００３８】
つまり、sub-picture化がなされた場合、ピクチャ領域ごとにサイズ・位置を変更した配置情報を示すRegion Wise Packing Boxは、Sub Picture Composition Boxのみにシグナルされ、分割前の全体ピクチャのregion-wise packing情報を有する。これに対して、sub-picture化がなされていない場合、Region Wise Packing Boxは、Projected Omnidirectional Video Boxにシグナルされ、trackに格納されたピクチャのregion-wise packing情報を有する。以下において、Sub Picture Composition Boxを有するtrackをsub-picture trackと称する。
【００３９】
＜sub-picture trackの選択＞
その為、トラック（track）がsub-picture trackであるか、sub-picture化がなされていない通常のtrackであるかによって、クライアントがそのtrackの画像の、投影平面画像（projected picture）上における表示領域を識別するための処理が異なる。例えば、sub-picture trackを選択・再生する場合、sub-picture trackのprojected picture上の表示領域を識別するために、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報とを識別する必要がある。これに対して、sub-picture trackではないtrackを選択・再生する場合、この処理は不要である。
【００４０】
図３のシンタックス２１は、Sub Picture Composition Boxのシンタックスの例を示す。シンタックス２１に示されるように、このSub Picture Composition Boxにおいて、Sub Picture Region BoxとRegion Wise Packing Boxとがセットされる。
【００４１】
図４のシンタックス２２は、Sub Picture Region Boxのシンタックスの例を示す。シンタックス２２に示されるように、このSub Picture Region Boxにおいて、track_x、track_y、track_width、track_height、composition_width、composition_height等のフィールドが定義される。
【００４２】
図５のセマンティクス２３は、Sub Picture Region Box内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２３に示されるように、track_xは、trackに格納されるsub-pictureの、全体ピクチャ上での水平方向位置を示す。track_yは、trackに格納されるsub-pictureの、全体ピクチャ上での垂直方向位置を示す。track_widthは、trackに格納されるsub-pictureの幅を示す。track_heightは、trackに格納されるsub-pictureの高さを示す。composition_widthは、全体ピクチャの幅を示す。composition_heightは、全体ピクチャの高さを示す。
【００４３】
図６のシンタックス２４は、Region Wise Packing Boxのシンタックスの例を示す。シンタックス２４に示されるように、このRegion Wise Packing Boxにおいて、Region Wise Packing Structがセットされる。
【００４４】
図７のシンタックス２５は、Region Wise Packing Structのシンタックスの例を示す。シンタックス２５に示されるように、このRegion Wise Packing Structにおいて、constituent_picture_matching_flag、num_regions、proj_picture_width、proj_picture_height、packed_picture_width、packed_picture_height、guard_band_flag[i]、packing_type[i]、GuardBand(i)等のフィールドがセットされる。
【００４５】
図８のセマンティクス２６は、Region Wise Packing Struct内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２６に示されるように、constituent_picture_matching_flagは、ピクチャがステレオの場合、左目用ビュー（Left view）および右目用ビュー（Right view）に対して同じregion-wise packingが適用されるか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、モノ（単視点ビュー）であるか、または、Left viewおよびRight viewに互いに異なるpackingが適用されることを示す。また、このフィールドの値が１の場合、Left viewおよびRight viewに対して同じpackingが適用されることを示す。
【００４６】
また、num_regionsは、packed regionの数を示す。proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。packed_picture_widthは、packed picture（region-wise packingされたpicture）の幅を示す。packed_picture_heightは、packed pictureの高さを示す。
【００４７】
また、guard_band_flag[i]は、ガードバンドが存在するか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、packed regionにガードバンドが存在しないことを示し、このフィールドの値が１の場合、packed regionにガードバンドが存在することを示す。packing_type[i]は、packed regionの形状を示す。例えばこのフィールドの値が０の場合、packed regionが矩形であることを示す。GuardBand(i)は、領域周囲のガードバンド情報である。
【００４８】
また、シンタックス２５に示されるように、Region Wise Packing Structにおいては、さらに、RectRegionPackingがセットされる。図９のシンタックス２７は、このRectRegionPackingのシンタックスの例を示す。シンタックス２７に示されるように、このRectRegionPackingにおいて、 proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]、transform_type[i]、packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]、packed_reg_left[i]等のフィールドがセットされる。
【００４９】
図１０のセマンティクス２８は、RectRegionPacking内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２８に示されるように、proj_reg_width[i]は、region-wise packing適用元のprojected regionの幅を示す。proj_reg_height[i]は、region-wise packing適用元のprojected regionの高さを示す。proj_reg_top[i]は、region-wise packing適用元のprojected regionの垂直方向位置を示す。proj_reg_left[i]は、region-wise packing適用元のprojected regionの水平方向位置を示す。transform_type[i]は、packed regionの回転やミラーリングを示す。packed_reg_width[i]は、region-wise packingで再配置されたpacked regionの幅を示す。packed_reg_height[i]は、region-wise packingで再配置されたpacked regionの高さを示す。packed_reg_top[i]は、region-wise packingで再配置されたpacked regionの垂直方向位置を示す。packed_reg_left[i]は、region-wise packingで再配置されたpacked regionの水平方向位置を示す。
【００５０】
つまり、例えばクライアントがユーザの視野に応じてsub-picture trackを選択するような場合、これらの情報をパースする必要があり、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。
【００５１】
＜ステレオ情報の識別＞
また、ステレオ全天球映像の全体ピクチャをsub-picture化した場合、全体ピクチャのステレオ情報（全体ピクチャがどのような種類の立体視表示用画像であるか等）を示すStereo Video Boxは、Sub Picture Composition Boxにシグナルされ、sub-pictureのステレオ情報（sub-pictureがどのような種類の立体視表示用画像であるか等）を示すStereo Video Boxは、trackのSample EntryのScheme Information Box下にシグナルされる。これに対して、sub-picture化がなされていない場合、Stereo Video Boxは、Scheme Information Box下のみにシグナルされ、trackに格納されたピクチャのステレオ情報を有する。
【００５２】
その為、trackがsub-picture trackか、sub-picture化がなされていない通常のtrackかによって、クライアントがそのtrackのステレオ情報を識別するための処理が異なる。例えば、全体ピクチャがステレオ画像（立体視用画像）である場合、分割されたsub-picture trackは、L viewおよびR viewを含むが、フレームパッキングアレンジメントがtop & bottomでもside by sideでもない場合がある。
【００５３】
したがって、このようなsub-pictureがステレオで表示可能か否かを識別する場合、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報、およびステレオ情報を識別する処理が必要となる。これに対して、sub-picture trackではないtrackを選択・再生する場合、この処理は不要である。
【００５４】
つまり、例えばクライアントが自身のステレオ表示能力に応じてsub-picture trackを選択する場合、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。
【００５５】
以上においては、ISOBMFFファイルにおけるsub-picture trackの選択について説明したが、MPDファイルでは、sub-pictureは、アダプテーションセット（Adaptation Set）として管理される。このMPDファイルにおけるsub-pictureを参照するAdaptation Setの選択についても同様の理由により、処理の負荷が増大するおそれがあった。つまり、ISOBMFFファイルの場合またはMPDファイルの場合に関わらず、ストリームの選択の負荷が増大するおそれがあった。
【００５６】
＜sub-pictureの表示領域のシグナル＞
そこで、全体ピクチャをサブピクチャ（sub-picture）化する場合、そのsub-pictureの表示領域に関する情報をシグナルする（コンテンツの再生側に提供する）ようにする。表示領域とは、全体ピクチャにおける領域のことを示す。すなわち、sub-pictureの表示領域に関する情報とは、そのsub-pictureに対応するピクチャ全体における領域に関する情報、つまり、sub-pictureが全体ピクチャのどの部分の画像であるかを示す情報である。この情報により、例えば、sub-pictureに対応する領域の位置、大きさ、形状等が示される。領域の表現方法は任意であり、例えば、領域の範囲が座標等により示されるようにしてもよい。
【００５７】
このようにすることにより、コンテンツを再生するクライアントは、この情報に基づいて、sub-pictureが全天球映像において何処に表示されるかを把握することができる。
【００５８】
その際、このsub-pictureの表示領域に関する情報を、sub-picture毎の情報としてシグナルするようにする。このようにすることにより、クライアントは、容易にこの情報を得ることができる。したがって、クライアントは、所望のサブピクチャのストリームを容易に選択することができる。例えば、ユーザの視野に応じてストリームを選択する場合に、クライアントは、その視野の方向や範囲に対応する適切なストリームを容易に選択することができる。
【００５９】
＜sub-picture化される全体ピクチャのステレオ情報のシグナル＞
また、sub-picture化されるピクチャ全体のステレオ表示に関する情報であるステレオ情報をシグナルするようにする。このようにすることにより、コンテンツを再生するクライアントは、この情報に基づいて全体ピクチャがステレオ画像（立体視用画像）であるか否かや、ステレオ画像である場合はその種類（タイプ）等を容易に把握することができる。これにより、クライアントは、sub-pictureに含まれる画像がどのような画像であるか（例えばどのようなタイプのステレオ画像（またはモノ画像（単視点画像））のどの部分に対応するのか等）を容易に把握することができる。
【００６０】
したがって、クライアントは、所望のストリームを容易に選択することができる。例えば自身の能力（capability）に応じてストリームを選択する場合に、クライアントは、その自身の能力（capability）に応じた適切なストリームを容易に選択することができる。
【００６１】
＜ファイル生成装置＞
次に、sub-pictureに関するシグナルを行う装置の構成について説明する。図１１は、本技術を適用した情報処理装置の一態様であるファイル生成装置の構成の一例を示すブロック図である。図１１に示されるファイル生成装置１００は、ISOBMFFファイル（セグメントファイル）やMPDファイルを生成する装置である。例えば、ファイル生成装置１００は、非特許文献１乃至非特許文献４に記載されている技術を実装し、MPEG-DASHに準拠した方法で、ストリームを含むISOBMFFファイルや、ストリームの配信制御に用いられる制御ファイルであるMPDファイルを生成し、それらのファイルを、ネットワークを介して、それらのファイルを配信するサーバにアップロード（送信）する。
【００６２】
なお、図１１においては、処理部やデータの流れ等の主なものを示しており、図１１に示されるものが全てとは限らない。つまり、ファイル生成装置１００において、図１１においてブロックとして示されていない処理部が存在したり、図１１において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
【００６３】
図１１に示されるようにファイル生成装置１００は、制御部１０１、メモリ１０２、およびファイル生成部１０３を有する。
【００６４】
制御部１０１は、ファイル生成装置１００全体の動作を制御する。例えば制御部１０１は、ファイル生成部１０３を制御して、ISOBMFFファイルやMPDファイルを生成させたり、生成されたISOBMFFファイルやMPDファイルをアップロードさせたりする。制御部１０１は、このような制御に関する処理を、メモリ１０２を利用して行う。例えば、制御部１０１は、所望のプログラム等をメモリ１０２にロードして実行することにより、上述のような制御に関する処理を行う。
【００６５】
ファイル生成部１０３は、制御部１０１の制御に従って、ISOBMFFファイルやMPDファイルの生成やアップロード（送信）に関する処理を行う。図１１に示されるように、ファイル生成部１０３は、データ入力部１１１、データ符号化・生成部１１２、MPDファイル生成部１１３、記録部１１４、およびアップロード部１１５を有する。
【００６６】
データ入力部１１１は、データ入力の受け付けに関する処理を行う。例えば、データ入力部１１１は、テクスチャやメッシュの生成に必要な画像等のデータや、MPDファイルの生成に必要なメタデータ等の入力を受け付ける。また、データ入力部１１１は、受け付けたデータを、データ符号化・生成部１１２やMPDファイル生成部１１３に供給する。
【００６７】
データ符号化・生成部１１２は、データの符号化やファイルの生成に関する処理を行う。例えば、データ符号化・生成部１１２は、データ入力部１１１から供給された画像等のデータに基づいて、テクスチャやメッシュ等のストリームを生成する。また、データ符号化・生成部１１２は、生成したストリームを格納するISOBMFFファイルを生成する。また、データ符号化・生成部１１２は、生成したISOBMFFファイルを記録部１１４に供給する。
【００６８】
図１１に示されるように、データ符号化・生成部１１２は、前処理部１２１、エンコード部１２２、およびセグメントファイル生成部１２３を有する。
【００６９】
前処理部１２１は、符号化前の画像等のデータに対する処理を行う。例えば、前処理部１２１は、データ入力部１１１から供給された画像等のデータに基づいて、テクスチャやメッシュのストリームを生成する。また、例えば、前処理部１２１は、その生成したストリームをエンコード部１２２に供給する。
【００７０】
エンコード部１２２は、ストリームの符号化に関する処理を行う。例えば、エンコード部１２２は、前処理部１２１から供給されたストリームを符号化する。また、例えば、エンコード部１２２は、その符号化により得られた符号化データを、セグメントファイル生成部１２３に供給する。
【００７１】
セグメントファイル生成部１２３は、セグメントファイルの生成に関する処理を行う。例えば、セグメントファイル生成部１２３は、データ入力部１１１から供給されたメタデータ等に基づいて、エンコード部１２２から供給された符号化データをセグメント単位でファイル化する（セグメントファイルを生成する）。また、例えば、セグメントファイル生成部１２３は、セグメントファイルの生成に関する処理として、以上のように生成したISOBMFFファイルを記録部１１４に供給する。例えば、セグメントファイル生成部１２３は、セグメントファイルとしてISOBMFFファイルを生成し、生成したISOBMFFファイルを記録部１１４に供給する。
【００７２】
MPDファイル生成部１１３は、MPDファイルの生成に関する処理を行う。例えば、MPDファイル生成部１１３は、データ入力部１１１から供給されたメタデータ等に基づいて、MPDファイルを生成する。また、例えば、MPDファイル生成部１１３は、生成したMPDファイルを記録部１１４に供給する。なお、MPDファイル生成部１１３は、MPDファイルの生成に必要なメタデータ等をセグメントファイル生成部１２３から取得するようにしてもよい。
【００７３】
記録部１１４は、例えば、ハードディスクや半導体メモリ等の任意の記録媒体を有し、データの記録等に関する処理を行う。例えば、記録部１１４は、MPDファイル生成部１１３から供給されたMPDファイルを記録する。また、例えば、記録部１１４は、セグメントファイル生成部１２３から供給されたセグメントファイル（例えばISOBMFFファイル）を記録する。
【００７４】
アップロード部１１５は、ファイルのアップロード（送信）に関する処理を行う。例えば、アップロード部１１５は、記録部１１４に記録されているMPDファイルを読み出す。また、例えば、アップロード部１１５は、読み出したMPDファイルを、ネットワーク等を介して、MPDファイルをクライアント等に配信するサーバ（図示せず）にアップロード（送信）する。
【００７５】
また、例えば、アップロード部１１５は、記録部１１４に記録されているセグメントファイル（例えばISOBMFFファイル）を読み出す。また、例えば、アップロード部１１５は、読み出したそれらのセグメントファイルを、ネットワーク等を介して、セグメントファイルをクライアント等に配信するサーバ（図示せず）にアップロード（送信）する。
【００７６】
つまり、アップロード部１１５は、MPDファイルやセグメントファイル（例えばISOBMFFファイル）をサーバに送信する通信部として機能する。なお、アップロード部１１５によるMPDファイルの送信先とセグメントファイル（例えばISOBMFFファイル）の送信先は、互いに同一であってもよいし、互いに異なっていてもよい。また、ここでは、ファイル生成装置１００が、MPDファイルやセグメントファイル（例えばISOBMFFファイル）を、それらのファイルをクライアントに配信するサーバにアップロードする装置として機能する例について説明するが、ファイル生成装置１００がそのサーバとして機能するようにしてもよい。その場合、ファイル生成装置１００のアップロード部１１５が、ネットワークを介してMPDファイルやセグメントファイル（例えばISOBMFFファイル）をクライアントに配信するようにすればよい。
【００７７】
＜クライアント装置＞
図１２は、本技術を適用した情報処理装置の一態様であるクライアント装置の構成の一例を示すブロック図である。図１２に示されるクライアント装置２００は、MPDファイルやセグメントファイル（例えばISOBMFFファイル）を取得し、それらのファイルに基づいて、コンテンツを再生する装置である。例えば、クライアント装置２００は、非特許文献１乃至非特許文献４に記載されている技術を実装し、MPEG-DASHに準拠した方法でセグメントファイルをサーバ（または上述のファイル生成装置１００）より取得し、そのセグメントファイルに含まれるストリーム（コンテンツ）を再生する。その際、クライアント装置２００は、MPDファイルをサーバ（または上述のファイル生成装置１００）より取得し、そのMPDファイルを利用して所望のセグメントファイルを選択し、サーバより取得するようにしてもよい。
【００７８】
なお、図１２においては、処理部やデータの流れ等の主なものを示しており、図１２に示されるものが全てとは限らない。つまり、クライアント装置２００において、図１２においてブロックとして示されていない処理部が存在したり、図１２において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
【００７９】
図１２に示されるようにクライアント装置２００は、制御部２０１、メモリ２０２、および再生処理部２０３を有する。
【００８０】
制御部２０１は、クライアント装置２００全体の動作を制御する。例えば制御部２０１は、再生処理部２０３を制御して、サーバからMPDファイルやセグメントファイル（例えばISOBMFFファイル）を取得させたり、セグメントファイルに含まれるストリーム（コンテンツ）を再生させたりする。制御部２０１は、このような制御に関する処理を、メモリ２０２を利用して行う。例えば、制御部２０１は、所望のプログラム等をメモリ２０２にロードして実行することにより、上述のような制御に関する処理を行う。
【００８１】
再生処理部２０３は、制御部２０１の制御に従って、セグメントファイルに含まれるストリーム（コンテンツ）の再生に関する処理を行う。図１２に示されるように、再生処理部２０３は、計測部２１１、MPDファイル取得部２１２、MPDファイル処理部２１３、セグメントファイル取得部２１４、表示制御部２１５、データ解析・復号部２１６、および表示部２１７を有する。
【００８２】
計測部２１１は、計測に関する処理を行う。例えば、計測部２１１は、クライアント装置２００とサーバとの間のネットワークの伝送帯域を計測する。また、例えば、計測部２１１は、その計測結果をMPDファイル処理部２１３に供給する。
【００８３】
MPDファイル取得部２１２は、MPDファイルの取得に関する処理を行う。例えば、MPDファイル取得部２１２は、所望のコンテンツ（再生するコンテンツ）に対応するMPDファイルを、ネットワークを介してサーバから取得する。また、例えば、MPDファイル取得部２１２は、取得したMPDファイルをMPDファイル処理部２１３に供給する。
【００８４】
MPDファイル処理部２１３は、MPDファイルに基づく処理を行う。例えば、MPDファイル処理部２１３は、MPDファイル取得部２１２から供給されたMPDファイルに基づいて、取得するストリームを選択する。また、例えば、MPDファイル処理部２１３は、その選択結果をセグメントファイル取得部２１４に供給する。なお、取得するストリームの選択にあたっては、計測部２１１から供給された計測結果や、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報も適宜利用される。
【００８５】
セグメントファイル取得部２１４は、セグメントファイル（例えばISOBMFFファイル）の取得に関する処理を行う。例えば、セグメントファイル取得部２１４は、所望のコンテンツの再生に必要なストリームが格納されたセグメントファイルを、ネットワークを介してサーバから取得する。また、例えば、セグメントファイル取得部２１４は、取得したセグメントファイルをデータ解析・復号部２１６に供給する。
【００８６】
なお、セグメントファイル取得部２１４がセグメントファイル（例えばISOBMFFファイル）を取得するサーバは、MPDファイル取得部２１２がMPDファイルを取得するサーバと同一であってもよいし、異なっていてもよい。また、セグメントファイル取得部２１４が、MPDファイル処理部２１３から供給されるストリームの選択結果に基づいて、セグメントファイルを取得するようにしてもよい。つまり、セグメントファイル取得部２１４が、MPDファイル等に基づいて選択されたストリームが格納されたセグメントファイルをサーバから取得するようにしてもよい。
【００８７】
表示制御部２１５は、コンテンツの再生（表示）の制御に関する処理を行う。例えば、表示制御部２１５は、コンテンツを視聴するユーザの視点位置や視線方向の検出結果を取得する。また、例えば、表示制御部２１５は、その取得した検出結果（ユーザの視点位置や視線方向に関する情報）をMPDファイル処理部２１３やデータ解析・復号部２１６に供給する。
【００８８】
データ解析・復号部２１６は、データの解析や復号等に関する処理を行う。例えば、データ解析・復号部２１６は、セグメントファイル取得部２１４から供給されたISOBMFFファイルを処理し、コンテンツの表示用画像を生成する。また、データ解析・復号部２１６は、その表示用画像のデータを表示部２１７に供給する。
【００８９】
図１２に示されるように、データ解析・復号部２１６は、セグメントファイル処理部２２１、デコード部２２２、および表示情報生成部２２３を有する。
【００９０】
セグメントファイル処理部２２１は、セグメントファイル（例えばISOBMFFファイル）に対する処理を行う。例えば、セグメントファイル処理部２２１は、セグメントファイル取得部２１４から供給されたISOBMFFファイルから所望のストリームの符号化データを抽出する。また、例えば、セグメントファイル処理部２２１は、抽出した符号化データをデコード部２２２に供給する。
【００９１】
なお、セグメントファイル処理部２２１が、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報や計測部２１１において計測された伝送帯域等に基づいて、ストリームを選択し、そのストリームの符号化データをセグメントファイルから抽出するようにしてもよい。
【００９２】
デコード部２２２は、復号に関する処理を行う。例えば、デコード部２２２は、セグメントファイル処理部２２１から供給された符号化データを復号する。また、例えば、デコード部２２２は、その復号により得られたストリームを表示情報生成部２２３に供給する。
【００９３】
表示情報生成部２２３は、表示用画像のデータの生成に関する処理を行う。例えば、表示情報生成部２２３は、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報と、デコード部２２２から供給されたストリームとに基づいて、ユーザの視点位置や視線方向に応じた表示用画像のデータを生成する。また、例えば、表示情報生成部２２３は、生成された表示用画像のデータを、表示部２１７に供給する。
【００９４】
表示部２１７は、例えば液晶表示パネル等を用いたディスプレイやプロジェクタ等の任意の表示デバイスを有し、その表示デバイスを用いた画像表示に関する処理を行う。例えば、表示部２１７は、表示情報生成部２２３から供給されたデータに基づいて、画像表示等のコンテンツ再生を行う。
【００９５】
＜２．第１の実施の形態＞
＜ISOBMFFによるsub-pictureの表示領域情報のシグナル＞
上述したsub-pictureの表示領域に関する情報のシグナルを、セグメントファイルであるISOBMFFファイルにおいて行うようにしてもよい。
【００９６】
つまり、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを生成するようにしてもよい。
【００９７】
例えば、情報処理装置であるファイル生成装置１００において、セグメントファイル生成部１２３が、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばセグメントファイル生成部１２３）を備えるようにしてもよい。
【００９８】
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【００９９】
なお、ISOBMFFファイルにおいては、ストリームはトラック（track）として管理される。つまり、ISOBMFFファイルを用いる場合、trackを選択することにより、ストリームの選択が行われる。
【０１００】
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。全天球映像は、視点を中心とする全方位の画像（つまり、視点から見た周辺の画像）である。この全天球映像は、立体構造にレンダリングして水平方向の周囲360度および垂直方向の周囲180度の画像とすることができる。上述のように、立体構造画像を単数の平面にマッピングして投影平面画像とすることにより、MPEG-DASHを適用したストリーム配信制御が可能になる。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。なお、投影平面画像の一部を全体ピクチャとした場合においても、sub-pictureの投影平面画像全部における表示領域に関する情報がシグナルされる。
【０１０１】
例えば、図１３に示されるように、水平方向の周囲360度および垂直方向の周囲180度の画像がCubemap projectionにより立体構造（立方体）に投影されて立体構造画像３０１が生成される。また、その立体構造画像３０１が所定の方法で単数の平面にマッピングされ、投影平面画像（projected picture）３０２が生成される。ファイル生成装置１００は、このような投影平面画像３０２をsub-picture化して、sub-pictures（sub-picture３０３乃至sub-picture３０８）を生成し、それぞれを互いに異なるtrackに格納するISOBMFFファイルを生成する。
【０１０２】
その際、ファイル生成装置１００は、矢印３１１に示されるように、どのsub-pictureが、全体ピクチャ（投影平面画像３０２）のどの部分に対応するかを示す情報（表示領域情報）をISOBMFFファイルにおいてシグナルする。
【０１０３】
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０１０４】
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、sub-picture trackの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０１０５】
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図１４のフローチャートを参照して説明する。
【０１０６】
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ１０１において、画像とメタデータを取得する。
【０１０７】
ステップＳ１０２において、セグメントファイル生成部１２３は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むISOBMFFファイルを生成する。
【０１０８】
ステップＳ１０３において、記録部１１４は、ステップＳ１０２の処理により生成されたISOBMFFファイルを記録する。
【０１０９】
ステップＳ１０４において、アップロード部１１５は、ステップＳ１０３において記録されたISOBMFFファイルを記録部１１４より読み出し、それをサーバにアップロードする。
【０１１０】
ステップＳ１０４の処理が終了すると、アップロード処理が終了する。
【０１１１】
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むISOBMFFファイルを生成することができる。
【０１１２】
したがって、クライアントは、その情報に基づいて、ユーザの視野等に応じた適切なストリームをより容易に選択し、再生することができる。
【０１１３】
＜ISOBMFFにシグナルされたsub-pictureの表示領域情報の利用＞
また、ISOBMFFファイルにシグナルされたsub-pictureの表示領域に関する情報を利用してストリームの選択や再生を行うようにしてもよい。
【０１１４】
つまり、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを取得し、その取得されたファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
【０１１５】
例えば、情報処理装置であるクライアント装置２００において、セグメントファイル取得部２１４が、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部として機能し、データ解析・復号部２１６が、そのファイル取得部により取得されたファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばセグメントファイル取得部２１４）と、画像処理部（例えばデータ解析・復号部２１６）とを備えるようにしてもよい。
【０１１６】
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
【０１１７】
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
【０１１８】
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、sub-picture trackの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０１１９】
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図１５のフローチャートを参照して説明する。
【０１２０】
コンテンツ再生処理が開始されると、クライアント装置２００のセグメントファイル取得部２１４は、ステップＳ１２１において、sub-picture毎の情報としてprojected pictureにおける表示領域情報を含むISOBMFFファイルを取得する。
【０１２１】
ステップＳ１２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
【０１２２】
ステップＳ１２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
【０１２３】
ステップＳ１２４において、セグメントファイル処理部２２１は、クライアント装置２００のユーザの視野に相当する（対応する）sub-picture trackを、そのsub-pictureのprojected pictureにおける表示領域情報を基に選択する。
【０１２４】
ステップＳ１２５において、セグメントファイル処理部２２１は、ステップＳ１２４において選択されたtrackのストリームの符号化データを、ステップＳ１２１において取得されたISOBMFFファイルから抽出する。
【０１２５】
ステップＳ１２６において、デコード部２２２は、ステップＳ１２５において抽出されたストリームの符号化データを復号する。
【０１２６】
ステップＳ１２７において、表示情報生成部２２３は、ステップＳ１２６において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
【０１２７】
ステップＳ１２７の処理が終了すると、コンテンツ再生処理が終了する。
【０１２８】
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、ISOBMFFファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、ユーザの視野に応じた適切なストリームを容易に選択することができる。
【０１２９】
＜2D Coverage Information Boxによる定義＞
上述のように、ファイル生成装置１００のセグメントファイル生成部１２３は、OMAFのISOBMFFファイルにおいて、sub-pictureがprojected pictureにおいてどの部分の表示に相当するかを示すsub-pictureの表示領域情報を新規定義し、trackにシグナルする。つまり、セグメントファイル生成部１２３は、sub-pictureの表示領域情報をサブピクチャ毎の情報として定義する。
【０１３０】
例えば、セグメントファイル生成部１２３は、そのsub-pictureの表示領域情報として2D Coverage Information Boxを定義し、Region Wise Packing Boxと異なるBoxとしてシグナルする。例えば、セグメントファイル生成部１２３は、その2D Coverage Information Boxを、Scheme Information Boxに定義する。例えば、セグメントファイル生成部１２３が、その2D Coverage Information Boxを、Scheme Information Boxの下のProjected Omnidirectional Video Boxに定義するようにしてもよい。また、セグメントファイル生成部１２３が、その2D Coverage Information Boxを、その他のBoxに定義するようにしてもよい。
【０１３１】
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、Region Wise Packing Boxとは異なる、ISOBMFFファイルのScheme Information Box、または、そのScheme Information Boxの下階層のBoxに格納されるようにしてもよい。
【０１３２】
このようにすることにより、クライアント装置２００は、Sub Picture Composition Boxをパースせずに、容易にsub-picture trackを選択し、再生することができる。
【０１３３】
なお、この2D Coverage Information Box は、trackに格納されるピクチャ（picture）がsub-pictureでない場合や、Region Wise Packing Boxが存在しない場合（ピクチャがRegion Wise Packingされない場合）にも、表示領域情報のシグナルに使用可能である。
【０１３４】
図１６のシンタックス３３１は、この2D Coverage Information Boxのシンタックスの例を示す。シンタックス３３１に示されるように、2D Coverage Information Boxにおいては、proj_picture_width、proj_picture_height、proj_reg_width、proj_reg_height、proj_reg_top、proj_reg_left等のフィールドがセットされる。
【０１３５】
図１７のセマンティクス３３２は、この2D Coverage Information Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３３２に示されるように、proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。proj_reg_widthは、trackのpictureが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、trackのpictureが対応する、projected picture上における領域の高さを示す。proj_reg_topは、trackのpictureが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、trackのpictureが対応する、projected picture上における領域水平方向座標を示す。
【０１３６】
つまり、図１８に示されるような各種情報が、2D Coverage Information Boxにおいて定義される。
【０１３７】
なお、これらの各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width、proj_reg_height、proj_reg_top、およびproj_reg_leftが、proj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。実際のピクセル数で示される場合、クライアントのディスプレイの解像度に応じてtrackを選択する場合に有用である。
【０１３８】
クライアント装置２００は、このような構成のsub-picture trackの2D Coverage Information Boxを参照することで、Sub Picture Composition Boxをパースすることなくsub-picture trackの表示領域を容易に識別することができる。それによって、クライアント装置２００は、例えば、ユーザの視野に応じたsub-picture trackの選択をより容易に行うことができる。なお、sub-picture trackでないtrackについても、クライアント装置２００は、同様の処理により選択することができる。
【０１３９】
また、図３のシンタックス２１に示すSub Picture Composition Boxにおいて、図７３のシンタックス１００１に示すようにidentical_to_proj_pic_flagフィールドを追加で定義し、全体ピクチャがprojected pictureに同一か否かを示し、全体ピクチャがprojected pictureに同一である場合において、図４のシンタックス２２に示すSub Picture Region Boxがsub-picture trackの表示領域情報を示す、としてもよい。identical_to_proj_pic_flagフィールドの値は、例えば０が全体ピクチャがprojected pictureと異なることを示し、１が全体ピクチャがprojected pictureと同一であることを示す。
【０１４０】
このとき、identical_to_proj_pic_flagフィールドが1の場合において全体ピクチャはregion-wise packing処理がなされておらず、図５のセマンティクス２３に示すSub Picture Region Boxのtrack_x、track_y、track_width、track_height、composition_width、composition_heightフィールドのセマンティクスは、それぞれ図１７のセマンティクス３３２に示される2D Coverage Information Boxのproj_reg_left、proj_reg_top、proj_reg_width、proj_reg_height、proj_picture_width、proj_picture_heightフィールドのセマンティクスと同一となる。
【０１４１】
なお、identical_to_proj_pic_flagフィールドはSub Picture Region Boxに追加で定義されてもよいし、その他のBoxで定義してもよい。また、特定のBoxの有無で、全体ピクチャがprojected pictureに同一か否かを示してもよい。
【０１４２】
また、Sub Picture Composition Boxや、FullBoxを拡張したその他のBoxが共通に持つ２４bitのflagsの１bitを利用し、全体ピクチャがprojected pictureに同一か否かを示してもよい。
【０１４３】
＜sub-pictureに不連続となる領域が含まれる場合＞
なお、図１６のシンタックス３３１では、図１９のようにsub-pictureがprojected picture上で不連続となる領域を含む場合には対応することができない。図１９の例の場合、projected picture３５１がsub-picture化されて、sub-picture３５２乃至sub-picture３５５が形成される。この場合、sub-picture３５２には、立体構造画像におけるLeft面およびRight面が含まれている（Left面およびRight面が隣接している）。このLeft面およびRight面は、projected picture３５１において不連続である。また、sub-picture３５３には、立体構造画像におけるTop面およびBottom面が含まれている（Top面およびBottom面が隣接している）。このTop面およびBottom面は、projected picture３５１において不連続である。
【０１４４】
図１６のシンタックス３３１では、projected pictureの１つのまとまった領域しか指定することができないので、このような不連続な複数の領域を指定することができない。
【０１４５】
そこで、2D Coverage Information Boxにおいて、複数の領域を指定することができるようにし、projected pictureにおける不連続な複数の領域を指定することができるようにしてもよい。
【０１４６】
図２０のシンタックス３７１は、この場合の2D Coverage Information Boxのシンタックスの例を示す。シンタックス３７１に示されるように、この場合、num_regionsフィールドが、定義されるフィールドに追加される。図２１のセマンティクス３７２は、この場合の2D Coverage Information Boxにおいて追加されるフィールドのセマンティクスの例を示す。セマンティクス３７２に示されるように、num_regionsは、そのsub-pictureに含まれるprojected picture上の領域数を示す。
【０１４７】
つまり、この場合、2D Coverage Information Boxにおいて、num_regionsフィールドを用いて、projected pictureの領域毎に（互いに独立して）、図１７に示される各フィールドを定義するようにしている。したがって、projected pictureの複数の領域を指定することができる。これにより、projected pictureの不連続な表示領域のシグナルが可能となる。
【０１４８】
なお、2D Coverage Information BoxがSub Picture Composition Boxにシグナルされた場合、全体ピクチャ（projected picture）における表示領域をシグナルするようにしてもよい。
【０１４９】
また、2D Coverage Information BoxがtrackのProjected Omnidirectional Video Boxに存在しなければ、そのtrackが360°全天球の映像を格納していることを示すものとしてもよい。同様に、2D Coverage Information BoxがSub Picture Composition Boxに存在しなければ、sub-picture trackが構成する全体ピクチャは360°全天球の映像であることを示すものとしてもよい。
【０１５０】
＜Region Wise Packing Boxの拡張＞
OMAFで規定されているRegion Wise Packing Box内のRegion Wise Packing Structを拡張し、trackのsub-pictureが、projected pictureのどの部分の表示領域に相当するかをシグナルするようにしてもよい。Region Wise Packing Boxのシグナル場所は、sub-picture trackのSample EntryのProjected Omnidirectional Video Box下である。なお、このRegion Wise Packing Boxが、その他の場所にシグナルされるようにしてもよい。
【０１５１】
例えば、新たにsub-pictureの表示領域情報をシグナルすることを示すフラグと、sub-pictureの表示領域情報をシグナルするRect Projected Region構造を定義し、Region Wise Packing Structでシグナルする。なお、このRegion Wise Packing Structは、trackに格納されるpictureがsub-pictureでない場合にも、この表示領域情報のシグナルに使用可能である。
【０１５２】
図２２のシンタックス３７３は、その場合のRegion Wise Packing Structのシンタックスの例を示す。シンタックス３７３に示されるように、この場合、2D_coverage_flagフィールドが、Region Wise Packing Structにおいて定義されるフィールドに追加される。図２３のセマンティクス３７４は、この場合のRegion Wise Packing Structにおいて追加的に定義されるフィールドのセマンティクスの例を示す。セマンティクス３７４に示されるように、2D_coverage_flagは、projected picture上での表示領域のみをシグナルするか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、region-wise packing情報をシグナルすることを示す。また、このフィールドの値が１の場合、projected picture上での表示領域をシグナルすることを示す。
【０１５３】
なお、この場合のRegion Wise Packing Structにおいては、さらに、RectProjetedRegionが定義される。図２４のシンタックス３７５は、そのRectProjetedRegionのシンタックスの例を示す。シンタックス３７５に示されるように、このRectProjetedRegionにおいては、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]等のフィールドが定義される。
【０１５４】
図２５のセマンティクス３７６は、このRectProjetedRegionにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３７６に示されるように、proj_reg_widthは、trackのpictureが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、trackのpictureが対応する、projected picture上における領域の高さを示す。proj_reg_topは、trackのpictureが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、trackのpictureが対応する、projected picture上における領域水平方向座標を示す。
【０１５５】
なお、上記各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width, proj_reg_height, proj_reg_topおよびproj_reg_leftがRegion Wise Packing Structでシグナルされるproj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。
【０１５６】
また、Rect Wise Packing Structを拡張し、2D_coverage_flag==1のときにprojected pictureにおける表示領域情報のみをシグナルするようにしてもよい。
【０１５７】
図２６のシンタックス３７７は、その場合のRect Wise Packing Structのシンタックスの例を示す。図２７のシンタックス３７８は、この場合のRect Wise Packing StructにおいてセットされるRectRegionPackingのシンタックスの例を示す図である。
【０１５８】
＜Coverage Information Boxの拡張＞
OMAFで定義されたtrackの球面上における表示領域を示すCoverage Information Boxを拡張し、新たに定義する2D Content Coverage Structによりprojected picture上における表示領域をシグナル可能にするようにしてもよい。
【０１５９】
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルの、トラックの球面上における表示領域を示すCoverage Information Boxに格納されるようにしてもよい。
【０１６０】
図２８のシンタックス３７９は、拡張したCoverage Information Boxのシンタックスの例を示す。シンタックス３７９に示されるように、この場合のCoverage Information Boxにおいて、2D_coverage_flag、ContentCoverageStruct()、2DContentCoverageStruct()が定義される。
【０１６１】
図２９のセマンティクス３８０は、これらのフィールドのセマンティクスの例を示す。セマンティクス３８０に示されるように、2D_coverage_flagは、表示領域情報のタイプをシグナルするフラグ情報である。この値が０の場合、球面上表示領域情報をシグナルすることを示し、この値が１の場合、projected picture上での表示領域をシグナルすることを示す。ContentCoverageStruct()は、trackの球面上表示領域をシグナルする。2DContentCoverageStruct()は、trackのprojected picture上での表示領域をシグナルする。2D Content Coverage Struct内のフィールドは、図２０の場合の2D Coverage Information Boxと同様である。
【０１６２】
なお、Content Coverage Structを拡張し、球面上表示領域の他に、projected picture上での表示領域をシグナルするようにしてもよい。
【０１６３】
＜sub-pictureの分割方法が動的に変化する場合のシグナリング＞
以上においては、sub-pictureの分割方法がストリーム中で動的に変化しない場合のシグナリングについて説明した。これに対して、分割方法が動的に変化する場合、projected pictureにおけるsub-pictureの表示領域情報がストリーム中で動的に変化する。その場合、上述の例では対応することができない。
【０１６４】
そこで、sub-pictureの動的に変化する表示領域情報をシグナルするための追加シグナリング例を以下に説明する。なお、シグナルされる情報は、上述の2D Coverage Information Boxでシグナルされる情報（例えば、図１６等）と同一である。
【０１６５】
＜Supplemental Enhancement Information (SEI) message＞
HEVC、AVCにおいて、2D Coverage Information SEI messageを新規定義し、その中において、ストリーム中で動的に変化するsub-pictureの表示領域情報をアクセスユニット単位でシグナルするようにしてもよい。
【０１６６】
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのSupplemental Enhancement information messageに格納されるようにしてもよい。
【０１６７】
図３０のシンタックス３８１は、その場合の2D Coverage Information SEI messageのシンタックスの例を示す。シンタックス３８１に示されるように、2D Coverage Information SEI messageにおいては、2D_coverage_information_cancel_flag、2D_coverage_information_persistence_flag、2D_coverage_information reserved_zero_6bits、proj_picture_width、proj_picture_height、num_regions、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]等がセットされる。
【０１６８】
図３１のセマンティクス３８２は、その2D Coverage Information SEI messageにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３８２に示されるように、2D_coverage_information_cancel_flagは、2D_coverage_informationのキャンセルに関するフラグ情報である。この値が１の場合、出力順で先行するSEIの持続的適用がキャンセルされる。また、この値が０の場合、2D coverage情報がシグナルされる。
【０１６９】
2D_coverage_information_persitence_flagは、SEIの適用範囲に関するフラグ情報である。この値が０の場合、SEIが含まれるピクチャのみに、SEIの情報が適用される。また、この値が１の場合、SEIの適用は、新たなcoded video sequenceが開始されるか、ストリームの末尾に到達するかまで持続する。
【０１７０】
2D_coverage_information_reserved_zero_6bitsは、0で埋められる。proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。num_regionsは、projected picture上の領域数を示す。proj_reg_widthは、ストリームが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、ストリームが対応する、projected picture上における領域の高さを示す。proj_reg_topは、ストリームが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、ストリームが対応する、projected picture上における領域水平方向座標を示す。
【０１７１】
なお、上記各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width, proj_reg_height, proj_reg_topおよびproj_reg_leftがproj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。
【０１７２】
＜Timed metadata＞
また、時系列で変化するメタデータを格納するストリームであるtimed metadataの仕組みを利用し、2D Coverage Information timed metadataを新規定義し、その中において、参照するストリーム内で動的に変化するsub-pictureの表示領域情報をシグナルするようにしてもよい。2D Coverage Information timed metadataが紐づくtrackに対するtrack reference typeとしては、例えば'2dco'を用いる。
【０１７３】
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのtimed metadataに格納されるようにしてもよい。
【０１７４】
timed metadataを使用することで、クライアントはsub-pictureストリームをデコードせずとも、動的に変わる表示領域を事前に識別し、どのストリームを選択するかの基準とすることができる。
【０１７５】
図３２のシンタックス３８３は、2D Coverage Information Sample Entryのシンタックスの例を示す。図３３のシンタックス３８４は、2D Coverage Information Sampleのシンタックスの例を示す。
【０１７６】
2D Coverage Information Sample Entryには、一般的にストリーム中で不変となるproj_picture_width, proj_picture_heightがシグナルされる。なお、これらがストリーム中で変化する場合には、2DCoverageInformationSample内においてシグナルされるようにしてもよい。
【０１７７】
なお、2D Coverage Information Sample Entryおよび2D Coverage Information Sample内の各フィールド（field）のセマンティクスは、図１７および図２１と同様である。
【０１７８】
＜Sample Group＞
ISOBMFFで定義される、sample単位でメタ情報を紐づける仕組みであるSample Groupというツールを使用して、ストリーム内で動的に変化するsub-pictureの表示領域情報を、sample単位でシグナルするようにしてもよい。
【０１７９】
メタ情報が記述されるSample Groupは、図３４に示されるように、サンプルテーブルボックス（Sample Table Box）のサンプルグループディスクリプションボックス（Sample Group Description Box）にグループエントリ（Group Entry）としてシグナルされ、サンプルトゥグループボックス（Sample To Group Box）を介して、sampleと紐づけられる。
【０１８０】
図３４に示されるように、Sample To Group Boxのグルーピングタイプ（grouping_type）は、紐づけられるSample Group Description Boxのgrouping_typeを示す。１エントリ（1 entry）につき、サンプルカウント（sample_count）とグループディスクリプションインデックス（group_description_index）がシグナルされ、そのgroup_description_indexは、紐づくグループエントリ（Group Entry）のインデックス（index）を示し、sample_countはそのGroup Entryに属するサンプル（sample）の数を示す。
【０１８１】
例えば、新たに2D Coverage Information Sample Group Entryを定義し、ストリーム内で動的に変化するsub-pictureの表示領域情報を、その中に格納するようにしてもよい。
【０１８２】
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのSample Group Entryに格納されるようにしてもよい。
【０１８３】
図３５のシンタックス３９１は、その2D Coverage Information Sample Group Entryのシンタックスの例を示す。このSample Group Entryは、上述したように、Sample Group Description Boxにシグナルされ、Sample To Group Boxによって、sampleとSample Group Entryが紐づけられる。grouping_typeは'2cgp'となる。
【０１８４】
なお、この2D Coverage Information Sample Group Entry内の各フィールドのセマンティクスは、図１６および図２１と同様である。
【０１８５】
なお、上述した３つの例（Supplemental Enhancement Information (SEI) message、Timed metadata、Sample Group）は、trackに格納されるpictureがsub-pictureでない場合においても、動的に変化する表示領域情報のシグナルに使用することができる。
【０１８６】
また、以上のようにsub-pictureのprojected picture上における表示領域が動的に変化する場合、Projected Omnidirectional Video Boxにシグナルされる2D Coverage Information Boxの情報は、ストリームの表示領域の初期値とすることができる。
【０１８７】
また、ストリーム中でsub-pictureのprojected pictureにおける表示領域が動的に変化することを示すフラグを2D Coverage Information Box、またはその他のBox内でシグナルするようにしてもよい。この情報により、クライアントは、容易に、動的に表示領域が変化するストリームであることを識別することができる。
【０１８８】
＜３．第２の実施の形態＞
＜MPDファイルによるsub-pictureの表示領域に関する情報のシグナル＞
上述したsub-pictureの表示領域に関する情報のシグナルを、MPDファイルにおいて行うようにしてもよい。つまり、クライアントが、sub-pictureを参照するAdaptation Setを例えばユーザの視野に応じて選択・再生することを可能にするために、MPDファイルにおいて、sub-pictureのprojected picture上における表示領域情報を新規定義し、Adaptation Setにシグナルするようにしてもよい。
【０１８９】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを生成するようにしてもよい。
【０１９０】
例えば、情報処理装置であるファイル生成装置１００において、MPDファイル生成部１１３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばMPDファイル生成部１１３）を備えるようにしてもよい。
【０１９１】
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０１９２】
なお、MPDファイルにおいては、ストリーム毎のメタデータはアダプテーションセット（Adaptation Set）やリプレゼンテーション（Representation）として管理される。つまり、MPDファイルを用いる場合、アダプテーションセット（Adaptation Set）やリプレゼンテーション（Representation）を選択することにより、ストリームの選択が行われる。
【０１９３】
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
【０１９４】
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０１９５】
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０１９６】
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図３６のフローチャートを参照して説明する。
【０１９７】
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ２０１において、画像とメタデータを取得する。
【０１９８】
ステップＳ２０２において、セグメントファイル生成部１２３は、その画像のセグメントファイルを生成する。
【０１９９】
ステップＳ２０３において、MPDファイル生成部１１３は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むMPDファイルを生成する。
【０２００】
ステップＳ２０４において、記録部１１４は、ステップＳ２０２の処理により生成されたセグメントファイルを記録する。また、記録部１１４は、ステップＳ２０３の処理により生成されたMPDファイルを記録する。
【０２０１】
ステップＳ２０５において、アップロード部１１５は、ステップＳ２０４において記録されたセグメントファイルを記録部１１４より読み出し、それをサーバにアップロードする。また、アップロード部１１５は、ステップＳ２０４において記録されたMPDファイルを記録部１１４より読み出し、それをサーバにアップロードする。
【０２０２】
ステップＳ２０４の処理が終了すると、アップロード処理が終了する。
【０２０３】
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むMPDファイルを生成することができる。
【０２０４】
したがって、クライアントは、その表示領域情報に基づいて、例えばユーザの視野に応じた適切なストリームをより容易に選択し、再生することができる。
【０２０５】
＜MPDファイルにシグナルされたsub-pictureの表示領域に関する情報の利用＞
また、MPDファイルにシグナルされたsub-pictureの表示領域に関する情報を利用してストリームの選択を行うようにしてもよい。
【０２０６】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを取得し、その取得された制御ファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
【０２０７】
例えば、情報処理装置であるクライアント装置２００において、MPDファイル取得部２１２が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部として機能し、MPDファイル処理部２１３が、そのファイル取得部により取得された制御ファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばMPDファイル取得部２１２）と、画像処理部（例えばMPDファイル処理部２１３）とを備えるようにしてもよい。
【０２０８】
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
【０２０９】
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
【０２１０】
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０２１１】
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図３７のフローチャートを参照して説明する。
【０２１２】
コンテンツ再生処理が開始されると、クライアント装置２００のMPDファイル取得部２１２は、ステップＳ２２１において、sub-picture毎の情報としてprojected pictureにおける表示領域情報を含むMPDファイルを取得する。
【０２１３】
ステップＳ２２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
【０２１４】
ステップＳ２２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
【０２１５】
ステップＳ２２４において、MPDファイル処理部２１３は、クライアント装置２００のユーザの視野に相当する（対応する）sub-pictureを参照するAdaptation Setを、そのsub-pictureのprojected pictureにおける表示領域情報を基に選択する。
【０２１６】
ステップＳ２２５において、MPDファイル処理部２１３は、ステップＳ２２４において選択されたAdaptation Setの中から、ユーザの視点位置および視線方向やクライアントとサーバとの間のネットワークの伝送帯域幅等に応じたリプレゼンテーション（Representation）を選択する。
【０２１７】
ステップＳ２２６において、セグメントファイル取得部２１４は、ステップＳ２２５において選択されたリプレゼンテーション（Representation）に対応するセグメントファイルを取得する。
【０２１８】
ステップＳ２２７において、セグメントファイル処理部２２１は、ステップＳ２２６において取得されたセグメントファイルから符号化データを抽出する。
【０２１９】
ステップＳ２２８において、デコード部２２２は、ステップＳ２２７において抽出されたストリームの符号化データを復号する。
【０２２０】
ステップＳ２２９において、表示情報生成部２２３は、ステップＳ２２８において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
【０２２１】
ステップＳ２２９の処理が終了すると、コンテンツ再生処理が終了する。
【０２２２】
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、MPDファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、ユーザの視野に応じた適切なストリームを容易に選択することができる。
【０２２３】
＜2D Coverage Information descriptorによる定義＞
上述のように、ファイル生成装置１００のMPDファイル生成部１１３は、OMAFのMPDファイルにおいて、Adaptation setが参照するsub-pictureがprojected pictureにおいてどの部分の表示に相当するかを示すsub-pictureの表示領域情報を新規定義し、シグナルする。つまり、MPDファイル生成部１１３は、sub-pictureの表示領域情報をサブピクチャ毎の情報として定義する。
【０２２４】
例えば、MPDファイル生成部１１３は、そのsub-pictureの表示領域情報として2D Coverage Information descriptorを定義し、Region wise packing descriptorと異なるdescriptorとしてシグナルする。例えば、MPDファイル生成部１１３は、@schemeIdUri="urn:mpeg:mpegI:omaf:2017:2dco"のSupplemental Propertyを2D coverage information descriptorとして定義する。なお、MPDファイル生成部１１３が、同じschemeIdUriのEssential Propertyを用いて2D coverage information descriptorを定義するようにしてもよい。
【０２２５】
つまり、サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、sub-pictureの表示領域情報（アダプテーションセットにより参照されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、MPDファイルのSupplemental PropertyまたはEssential Propertyに定義されるようにしてもよい。
【０２２６】
なお、EssentialPropertyのschemeIdUriに対応していないDASHクライアントは、このPropertyの書かれているAdaptation Set（Representation等でもよい）は無視しなければならない。また、SupplementalPropertyのschemeIdUriに対応していないDASHクライアントは、このProperty値を無視して、AdaptationSet（Representation等でもよい）を利用してもよい。
【０２２７】
なお、この2D Coverage Information descriptorは、Adaptation Set以外に、MPDやRepresentationに存在するようにしてもよい。また、この2D Coverage Information descriptorは、Adaptation Setが参照するpictureがsub-pictureでなくても、または、region-wise packing処理がなされていなくても、適用可能である。
【０２２８】
図３８の属性値４１１は、この2D coverage information descriptorの属性値の例を示す。属性値４１１に示されるように、omaf:@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。omaf:@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。omaf:@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。omaf:@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。omaf:@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。omaf:@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
【０２２９】
上記各属性値は、実際のピクセル数で示されるようにしてもよいし、omaf:@proj_reg_width, omaf:@proj_reg_height, omaf:@proj_reg_topおよびomaf:@proj_reg_leftがomaf:@proj_picture_widthおよびomaf:@proj_picture_heightに対する相対値で示されるようにしてもよい。
【０２３０】
また、全体ピクチャがprojected pictureに同一であることを示す情報を、MPDファイルのSupplemental PropertyまたはEssential Propertyに定義されるようにしてもよい。例えば、MPDファイル生成部１１３は、図７４に示す@schemeIdUri="urn:mpeg:mpegI:omaf:2017:prid"のSupplemental PropertyをProjected picture identical descriptorとして定義する。例えばこのdescriptorがAdaptationSetに存在する場合、AdaptationSetが参照するsub-pictureから構成される全体ピクチャはregion-wise packing処理がなされておらず、projected pictureと同一であることを示す。
【０２３１】
このとき、Projected picture identical descriptorが存在するAdaptationSetが参照するsub-pictureの表示領域を、例えば、全体ピクチャを２以上の領域に分割して独立して符号化したときの各領域の表示領域を示すMPEG-DASH SRD（Spatial Relationship Description）で示してもよい。図示はしないが、SRDでは、図４のシンタックス２２に示すSub Picture Region Boxと同様に、sub-pictureの分割の仕方等を示すsub-picture分割情報が示される。
【０２３２】
このとき、Projected picture identical descriptorが存在するAdaptationSetにおいて、図示はしないが、SRDの属性値であるobject_x、object_y、object_width、object_height、total_width、total_heightのセマンティクスは、それぞれ図３８の属性値４４１に示される2D coverage information descriptorの属性値であるomaf:@proj_reg_left、omaf:@proj_reg_top、omaf:@proj_reg_width、omaf:@proj_reg_height、omaf:@proj_picture_width、omaf:@proj_picture_heightのセマンティクスと同一となる。
【０２３３】
なお、このProjected picture identical descriptorは、Adaptation Set以外に、MPDやRepresentationに存在するようにしてもよいし、全体ピクチャがprojected pictureに同一であることを示す情報をその他のdescriptor、要素、属性によって定義されるようにしてもよい。
【０２３４】
＜sub-pictureに不連続となる領域が含まれる場合＞
なお、上記の例では、sub-pictureがprojected picture上で不連続となる領域を含む場合の表示領域情報をシグナルできない。そこで、2D Coverage Information descriptorが、sub-pictureがprojected picture上で不連続となる領域を含む場合にも対応することができるようにしてもよい。
【０２３５】
図３９の属性値４１２は、その場合の2D Coverage Information descriptorの属性値の例を示す。属性値４１２に示されるように、twoDCoverageは、データタイプがomaf:twoDCoverageTypeのコンテナ要素である。twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。
【０２３６】
twoDCoverage.twoDCoverageInfoは、データタイプが、omaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素を示す。この属性値は、複数シグナルすることができる。twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
【０２３７】
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
【０２３８】
図４０のデータタイプ４１３は、この2D Coverage Information descriptorのデータタイプの定義の例を示す。
【０２３９】
以上のように、projected picture上の複数領域をシグナル可能にすることで、projected picture上で不連続な表示領域のシグナルが可能となる。
【０２４０】
＜Region-wise packing descriptorの拡張＞
OMAFで定義されているRegion-wise packing descriptorを拡張し、Adaptation Setが参照するsub-pictureの、projected picture上における表示領域情報をシグナルするようにしてもよい。
【０２４１】
図４１の属性値４１４は、図３８の属性値４１１のシグナルをもとに拡張したRegion-wise packing descriptorの属性値の例を示す。データタイプは、図４０と同様である。
【０２４２】
属性値４１４に示されるように、omaf: @packing_typeは、データタイプがomaf:OptionallistofUnsignedByteであり、region-wise packingのパッキングタイプを示す。この属性値が０の場合、矩形領域のパッキングであることを示す。
【０２４３】
omaf:@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。omaf:@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。omaf:@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。omaf:@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
【０２４４】
omaf:@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。omaf:@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標である。
【０２４５】
上記各属性値は、実際のピクセル数で示されるようにしてもよいし、omaf:@proj_reg_width, omaf:@proj_reg_height, omaf:@proj_reg_topおよびomaf:@proj_reg_leftがomaf:@proj_picture_widthおよびomaf:@proj_picture_heightに対する相対値で示されるようにしてもよい。
【０２４６】
図４２の属性値４１５は、図３９の属性値４１２のシグナルをもとに拡張したRegion-wise packing descriptorの属性値、すなわち、不連続な領域を含む場合に対応したRegion-wise packing descriptorの属性値の例を示す。データタイプは、図４０と同様である。
【０２４７】
属性値４１５に示されるように、omaf: @packing_typeは、データタイプがomaf:OptionallistofUnsignedByteであり、region-wise packingのパッキングタイプを示す。この属性値が０の場合、矩形領域のパッキングであることを示す。
【０２４８】
twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるコンテナ要素である。twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素を示す。この属性値は、複数シグナルすることができる。
【０２４９】
twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
【０２５０】
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
【０２５１】
＜Content coverage descriptorの拡張＞
また、OMAFで定義された、Adaptation Setの球面上における表示領域を示すContent coverage descriptorを拡張し、projected picture上における表示領域をシグナル可能にするようにしてもよい。
【０２５２】
つまり、サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、sub-pictureの表示領域情報（アダプテーションセットに参照されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、MPDファイルの、Adaptation Setの球面上における表示領域を示すCoverage Information descriptorにおいて定義されるようにしてもよい。
【０２５３】
図４３の属性値４１６および図４４の属性値４１７は、拡張したContent coverage descriptorの属性値の例を示す。Content coverage descriptorを拡張する場合、上述したISOBMFFファイルにおいてContent coverage Boxを拡張する場合と同様に、2D_coverage_flag属性によって、球面上領域をシグナルするか、projected picture上における表示領域をシグナルするかの切り替えを行う。
【０２５４】
属性値４１６に示されるように、ccは、データタイプがomaf:CCTypeであるコンテナ要素である。cc@2D_coverage_flagは、データタイプがxs:booleanであり、表示領域が球面上で定義されるか、projected picture上で定義されるか、を示すフラグ情報である。この属性値が０の場合、球面上で定義されることを示し、この値が１の場合、projected picture上で定義されることを示す。
【０２５５】
cc.sphericalCoverageは、データタイプがomaf:sphericalCoverageTypeである、球面上表示領域情報のコンテナ要素である。この要素は、cc@2D_coverage_flag=0のときのみ存在する。cc.sphericalCoverage @shape_typeは、データタイプがxs:unsignedByteであり、球面上領域の形状を示す。この属性値が０の場合、4 great circlesで囲まれる領域であることを示す。また、この属性値が１の場合、２つのazimuth circleと２つのelevation angleで囲まれる領域であることを示す。
【０２５６】
cc.sphericalCoverage @view_idc_presence_flagは、データタイプがxs:booleanであり、view_idc属性が存在するか否かを示すフラグ情報である。この属性値が０の場合、view_idc属性が存在しないことを示し、この属性値が１の場合、view_idc属性が存在することを示す。
【０２５７】
cc.sphericalCoverage @default_view_idcは、データタイプがomaf:ViewTypeであり、領域全てに共通なviewを示す。例えば、この属性値が０の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がモノビュー（mono view）であることを示す。また、この属性値が１の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がレフトビュー（left view）であることを示す。また、この属性値が２の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がライトビュー（right view）であることを示す。また、この属性値が３の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がステレオビュー（stereo view）であることを示す。この属性値は、cc@view_idc_presence_flag=0のとき、必ず存在する。また、cc@view_idc_presence_flag=1のとき、この属性は存在してはいけない。
【０２５８】
cc.sphericalCoverage.coverageInfoは、データタイプがomaf:coverageInfoTypeであり、球面上領域情報を示す要素である。この要素は、複数シグナルすることができる。
【０２５９】
cc.sphericalCoverage.coverageInfo@view_idcは、データタイプがomaf:ViewTypeであり、領域毎のviewを示す。例えば、この属性値が０の場合、その属性値が対応する領域のビュータイプ（view_idc）がモノビュー（mono view）であることを示す。また、この属性値が１の場合、その属性値が対応する領域のビュータイプ（view_idc）がレフトビュー（left view）であることを示す。また、この属性値が２の場合、その属性値が対応する領域のビュータイプ（view_idc）がライトビュー（right view）であることを示す。また、この属性値が３の場合、その属性値が対応する領域のビュータイプ（view_idc）がステレオビュー（stereo view）であることを示す。この属性値は、cc@view_idc_presence_flag=0のとき、存在してはいけない。また、cc@view_idc_presence_flag=1のとき、この属性は必ず存在する。
【０２６０】
cc.sphericalCoverage.coverageInfo@center_azimuthは、データタイプがomaf:Range1であり、球面上表示領域中心の方位角を示す。cc.sphericalCoverage.coverageInfo@center_elevationは、データタイプがomaf:Range2であり、球面上表示領域中心の仰角を示す。cc.sphericalCoverage.coverageInfo@center_tiltは、データタイプがomaf:Range1であり、球面上表示領域中心のチルト角を示す。cc.sphericalCoverage.coverageInfo@azimuth_rangeは、データタイプがomaf:HRangeであり、球面上表示領域の方位角レンジを示す。cc.sphericalCoverage.coverageInfo@elevation_rangeは、データタイプがomaf:VRangeであり、球面上表示領域の仰角レンジを示す。
【０２６１】
cc.twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるprojected picture上における表示領域情報のコンテナ要素である。cc@2D_coverage_flag=1のときのみ存在する。
【０２６２】
cc.twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。cc.twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。cc.twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素である。この要素は、複数シグナルすることができる。
【０２６３】
cc.twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。cc.twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
【０２６４】
cc.twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。cc.twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
【０２６５】
図４５のデータタイプ４１８、図４６のデータタイプ４１９、および図４７のデータタイプ４２０は、この拡張したContent coverage descriptorのデータタイプの定義の例を示す。
【０２６６】
＜sub-pictureの分割方法が動的に変化する場合のシグナリング＞
なお、ストリーム中でprojected pictureにおける表示領域が動的に変化する場合、上述のシグナリングに加え、2D coverage information descriptor, region-wise packing descriptorおよびContent coverage descriptorに追加でフラグをシグナルし、projected pictureにおける表示領域が動的に変化するストリームであることを示すようにしてもよい。
【０２６７】
＜４．第３の実施の形態＞
＜ステレオ情報のシグナル＞
＜１．sub-pictureに関する情報のシグナル＞の＜ステレオ情報の識別＞において上述したように、ステレオ全天球映像の全体ピクチャをsub-picture化した場合、全体ピクチャのステレオ情報はSub Picture Composition Box下にシグナルされるStereo Video Boxでシグナルされ、sub-pictureのステレオ情報はSample EntryのScheme Information Box下のStereo Video Boxでシグナルされる。
【０２６８】
全体ピクチャがステレオ画像である場合、生成可能なsub-pictureのバリエーションとして例えば以下の３パターンがある。
【０２６９】
図４８は、sub-picture化の第１のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４３１がsub-picture化されて、sub-picture４３２乃至sub-picture４３７が生成される。projected picture４３１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４３２乃至sub-picture４３７は、それぞれ、projected picture４３１上で同一の表示領域となるLeft viewとRight viewを含み、top & bottomやside by sideといったStereo Video Boxでシグナル可能なフレームパッキングアレンジメントとなっている。
【０２７０】
図４９は、sub-picture化の第２のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４４１がsub-picture化されて、sub-picture４４２乃至sub-picture４４６が生成される。projected picture４４１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４４２乃至sub-picture４４６は、それぞれ、Left viewおよびRight viewを含むが、各viewのprojected picture４４１上の表示領域が一致せず、top & bottomやside by sideといったStereo Video Boxでシグナル可能なフレームパッキングアレンジメントとならない。
【０２７１】
図５０は、sub-picture化の第３のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４５１がsub-picture化されて、sub-picture４５２およびsub-picture４５３が生成される。projected picture４５１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４５２は、Left viewのみを含むモノピクチャとなっている。sub-picture４５３は、Right viewのみを含むモノピクチャとなっている。
【０２７２】
第１のパタンーンの場合、sub-picture trackのSample Entry/rinf/schiにStereo Video Boxがシグナルされ、適切なフレームパッキングアレンジメント情報がシグナルされる。例えば図４８の場合、side by sideとなる。なお、sub-pictureのフレームパッキングアレンジメント情報ではなく、全体ピクチャのフレームパッキングアレンジメント情報がシグナルされてもよい。
【０２７３】
第２のパターンの場合、Sample Entry/rinf/schiにはStereo Video Boxがシグナルされない。したがって、クライアントは、sub-pictureがモノピクチャなのか、Left viewおよびRight viewを含んでいるがtop & bottomやside by sideといったフレームパッキングアレンジメントが適用されていないのかを識別することができないおそれがあった。
【０２７４】
第３のパターンの場合、Sample Entry/rinf/schiにはStereo Video Boxがシグナルされない。したがって、クライアントは、分割前の全体ピクチャがモノピクチャであるのかステレオ画像であるのかを識別することができないおそれがあった。レンダリング時のアップスケール（upscale）が必要であるか否かは、分割前の全体ピクチャがモノピクチャであるのかステレオ画像であるのかによって異なるため、その識別ができないと、クライアントが適切にレンダリングすることができないおそれがあった。
【０２７５】
例えば、図５０のように、全体ピクチャがside by sideのステレオ画像であり、そのうちのLeft viewのみを持つsub-pictureについては、レンダリングの際、水平方向に２倍のupscaleが必要である。これに対して、全体ピクチャがモノピクチャである場合、この処理は不要である。
【０２７６】
＜ISOBMFFによるsub-picture化される全体ピクチャのステレオ情報のシグナル＞
そこで、sub-picture化されるピクチャ全体のステレオ表示に関する情報であるステレオ情報を、セグメントファイルであるISOBMFFファイルにおいて行うようにしてもよい。
【０２７７】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するようにしてもよい。
【０２７８】
例えば、情報処理装置であるファイル生成装置１００において、セグメントファイル生成部１２３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばセグメントファイル生成部１２３）を備えるようにしてもよい。
【０２７９】
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０２８０】
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
【０２８１】
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０２８２】
なお、この全体ピクチャのステレオ情報は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、sub-picture trackの情報を参照するだけで、その全体ピクチャのステレオ情報（例えば、全体ピクチャステレオ画像であるか否かや、どのようなタイプのステレオ画像であるか等）を容易に把握することができる。
【０２８３】
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図５１のフローチャートを参照して説明する。
【０２８４】
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ３０１において、画像とメタデータを取得する。
【０２８５】
ステップＳ３０２において、セグメントファイル生成部１２３は、sub-picture毎の情報として、全体ピクチャ（projected picture）のステレオ情報を含むISOBMFFファイルを生成する。
【０２８６】
ステップＳ３０３において、記録部１１４は、ステップＳ３０２の処理により生成されたISOBMFFファイルを記録する。
【０２８７】
ステップＳ３０４において、アップロード部１１５は、ステップＳ３０３において記録されたISOBMFFファイルを記録部１１４より読み出し、それをサーバにアップロードする。
【０２８８】
ステップＳ３０４の処理が終了すると、アップロード処理が終了する。
【０２８９】
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureのステレオ情報を含むISOBMFFファイルを生成することができる。
【０２９０】
したがって、クライアントは、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
【０２９１】
＜ISOBMFFにシグナルされたsub-picture化される全体ピクチャのステレオ情報の利用＞
また、ISOBMFFファイルにシグナルされた、sub-picture化される全体ピクチャのステレオ情報を利用してストリームの選択や再生を行うようにしてもよい。
【０２９２】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得し、その取得されたファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
【０２９３】
例えば、情報処理装置であるクライアント装置２００において、セグメントファイル取得部２１４が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得するファイル取得部と、として機能し、データ解析・復号部２１６が、そのファイル取得部により取得されたファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばセグメントファイル取得部２１４）と、画像処理部（例えばデータ解析・復号部２１６）とを備えるようにしてもよい。
【０２９４】
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
【０２９５】
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
【０２９６】
また、この全体ピクチャのステレオ情報は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、sub-picture trackの情報を参照するだけで、その全体ピクチャのステレオ情報（例えば、全体ピクチャステレオ画像であるか否かや、どのようなタイプのステレオ画像であるか等）を容易に把握することができる。
【０２９７】
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図５２のフローチャートを参照して説明する。
【０２９８】
コンテンツ再生処理が開始されると、クライアント装置２００のセグメントファイル取得部２１４は、ステップＳ３２１において、sub-picture毎の情報として全体ピクチャ（projected picture）のステレオ情報を含むISOBMFFファイルを取得する。
【０２９９】
ステップＳ３２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
【０３００】
ステップＳ３２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
【０３０１】
ステップＳ３２４において、セグメントファイル処理部２２１は、クライアント装置２００がステレオ再生を行うか否か（またはステレオ再生を行う機能（capability）を有するか否か）を判定する。ステレオ再生を行う（またはステレオ再生の機能を有する）と判定された場合、処理はステップＳ３２５に進む。
【０３０２】
ステップＳ３２５において、セグメントファイル処理部２２１は、ステレオ表示可能なsub-picture trackを選択候補とする。その際、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第２のパターンのフレームパッキングアレンジメントが適用されていないステレオ表示可能なsub-picture track（例えば、図４９のsub-picture４４５やsub-picture４４６）も選択候補に含めることができる。ステップＳ３２５の処理が終了すると、処理はステップＳ３２７に進む。
【０３０３】
また、ステップＳ３２４において、クライアント装置２００がステレオ再生を行わない（またはステレオ再生の機能を有していない）と判定された場合、処理はステップＳ３２６に進む。
【０３０４】
ステップＳ３２６において、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報等に基づいて、モノピクチャのsub-picture trackを選択候補とする。その際、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第３のパターンのsub-picture track（例えば、図５０のsub-picture４５２やsub-picture４５３）について、レンダリングの際に水平方向に２倍のアップスケール（upscale）が必要であることを把握することができる。ステップＳ３２６の処理が終了すると、処理はステップＳ３２７に進む。
【０３０５】
ステップＳ３２７において、セグメントファイル処理部２２１は、ステップＳ３２５またはステップＳ３２６において設定した候補の中から、クライアント装置２００のユーザの視野に応じたsub-picture trackを選択する。
【０３０６】
ステップＳ３２８において、セグメントファイル処理部２２１は、ステップＳ３２７において選択されたsub-picture trackのストリームの符号化データを、ステップＳ３２１において取得されたISOBMFFファイルから抽出する。
【０３０７】
ステップＳ３２９において、デコード部２２２は、ステップＳ３２８において抽出されたストリームの符号化データを復号する。
【０３０８】
ステップＳ３３０において、表示情報生成部２２３は、ステップＳ３２９において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
【０３０９】
ステップＳ３３０の処理が終了すると、コンテンツ再生処理が終了する。
【０３１０】
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、ISOBMFFファイルに含まれるsub-picture化される全体ピクチャのステレオ情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
【０３１１】
＜全体ピクチャのステレオ情報をSample Entryにシグナル＞
例えば、分割前の全体ピクチャがステレオ画像である場合、ファイル生成装置１００のセグメントファイル生成部１２３が、sub-picture trackのSample Entryにおいて、全体ピクチャのステレオ情報をシグナルするようにしてもよい。
【０３１２】
例えば、ISOBMFFファイルの、そのSample Entryの下のScheme Information Box、または、そのScheme Information Boxの下階層のBoxに、全体ピクチャのステレオ情報が格納されるようにしてもよい。
【０３１３】
＜Original Stereo Video Box＞
例えば、分割前の全体ピクチャのステレオ情報をシグナルするために、ファイル生成装置１００のセグメントファイル生成部１２３が、Original Stereo Video Boxを新規定義し、sub-picture trackのSample EntryのScheme Information Box（schi）の下に、そのBoxをシグナルするようにしてもよい。つまり、このOriginal Stereo Video Boxに、分割前の全体ピクチャのステレオ情報が格納されるようにしてもよい。
【０３１４】
なお、このOriginal Stereo Video Boxの場所は任意であり、上述のScheme Information Boxに限定されない。また、Original Stereo Video Boxでシグナルされる情報は、Stereo Video Boxと同様である。
【０３１５】
図５３のシンタックス４６１は、このOriginal Stereo Video Boxのシンタックスの例を示す。シンタックス４６１に示されるように、Original Stereo Video Boxにおいては、single_view_allowed、stereo_scheme、length、stereo_indication_type等のフィールドが定義される。
【０３１６】
図５４のセマンティクス４６２は、このOriginal Stereo Video Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス４６２に示されるように、single_view_allowedは、許容されるビューの種類を示す情報である。例えばこのフィールドの値が０の場合、コンテンツはステレオスコピック対応のディスプレイでのみ表示されることを意図していることを示す。また、このフィールドの値が１の場合、コンテンツはモノスコピックディスプレイでright viewの表示が許されていることを示す。また、このフィールドの値が２の場合、コンテンツはモノスコピックディスプレイでleft viewの表示が許されていることを示す。
【０３１７】
stereo_schemeは、フレームパッキング方法に関する情報である。例えば、このフィールドの値が１の場合、フレームパッキング方法は、ISO/IEC 14496-10のFrame packing arrangement SEIに従うことを示す。また、このフィールドの値が２の場合、フレームパッキング方法は、ISO/IEC 13818-2のAnnex.Lに従うことを示す。また、このフィールドの値が３の場合、フレームパッキング方法は、ISO/IEC 23000-11のframe/sevice compatible および2D/3D Mixed seviceに従うことを示す。
【０３１８】
lengthは、stereo_indication_typeのバイト長を示す。また、stereo_indication_typeは、stereo_shcemeに従った、フレームパッキング方法を示す。
【０３１９】
クライアント装置２００のセグメントファイル処理部２２１は、Original Stereo Video Boxおよび2D Coverage Information Boxを参照することで、全体ピクチャのステレオ情報を取得することができる。そして、セグメントファイル処理部２２１は、この情報に基づいて、sub-picture trackのSample EntryにStereo Video Boxがシグナルされていない場合、sub-pictureがモノなのか、Left viewおよびRight viewを含むものの、Stereo Video Boxでシグナルされるフレームパッキングアレンジメントが適用されていないのか、をSub Picture Composition Boxをパースせずに、容易に識別することができる。つまり、sub-picture trackでないtrackの場合と同様、Sample Entryに格納された情報のみからステレオ情報の識別が可能となる。
【０３２０】
つまりクライアント装置２００は、Sub Picture Composition Boxをパースせず、sub-picture track単独の選択・再生することができる。
【０３２１】
＜表示サイズのシグナル＞
さらに、ステレオである全体ピクチャを分割して生成したモノsub-picture（モノピクチャであるsub-picture）を格納するsub-picture trackのTrack Headerのwidthおよびheightに、全体ピクチャのフレームパッキングアレンジメントをもとにupscaleした表示サイズをシグナルするようにしてもよい。
【０３２２】
つまり、ISOBMFFファイルに、sub-pictureの表示サイズに関する情報が含まれるようにしてもよい。
【０３２３】
その様子の例を図５５に示す。図５５に示されるように、ステレオ画像の全体ピクチャから生成されたsub-picture４７１およびsub-picture４７２は、各領域の画像が水平方向にダウンスケールされている。したがって、表示時（レンダリング）の際には、水平方向にupscaleする必要がある。そこで、この表示時の画像４７３の表示サイズをTrack Headerのwidthおよびheightとしてシグナルするようにする。これにより、クライアント装置２００が、モノsub-pictureを適切にレンダリングすることができる。
【０３２４】
なお、このTrack Headerのwidthおよびheightにおけるシグナリングの代わりに、ISOBMFFで定義される、表示時のピクセル縦横比情報をシグナルするPixel Aspect Ratio Box（pasp）をVisual Sample Entryにシグナルするようにしてもよい。この場合も、上述のTrack Headerのwidthおよびheightにおいてシグナルする場合と同等の効果を得ることができる。
【０３２５】
図５６のシンタックス４８１は、Pixel Aspect Ratio Boxのシンタックスの例を示す。シンタックス４８１に示されるように、Pixel Aspect Ratio Boxにおいては、例えば、hSpacing、vSpacing等のフィールドが定義される。
【０３２６】
図５７のセマンティクス４８２は、このPixel Aspect Ratio Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス４８２に示されるように、hSpacingおよびvSpacingは、相対的なピクセル高さ、幅を示す情報である。レンダリングの際には、この情報に基づいて、ピクセル幅がvSpace/hSpace倍されて表示される。
【０３２７】
その様子の例を図５８に示す。図５８に示されるsub-picture４９１およびsub-picture４９２は、ステレオ画像の全体ピクチャから生成されたsub-pictureであり、各領域の画像が水平方向にダウンスケールされている。そこで、hSpace=1、vSpase=2をシグナルすることにより、クライアント装置２００は、例えば、sub-picture４９１を表示（レンダリング）する際に、これらの情報に基づいて、ピクセル幅を２倍にしてレンダリングして、画像４９３のように、適切なアスペクト比で画像を表示させることができる。つまり、クライアント装置２００が、モノsub-picture（モノ画像からなるsub-picture）を適切にレンダリングすることができる。
【０３２８】
＜Original Scheme Information Box＞
また、sub-picture trackのSample EntryのRestricted Scheme Information Box（rinf）下に、Original Scheme Information Boxを新規定義し、そのBox内に分割前の全体ピクチャのステレオ情報をシグナルするようにしてもよい。なお、Original Scheme Information Boxを定義する場所は、任意であり、上述のrinfに限定されない。
【０３２９】
図５９のシンタックス５０１は、その場合のOriginal Scheme Information Boxのシンタックスの例を示す。シンタックス５０１に示されるように、Original Scheme Information Boxにおいては、例えば、scheme_specific_dataが定義される。
【０３３０】
このscheme_specific_dataには、sub-pictureに分割される前の全体ピクチャについての情報がシグナルされる。例えば、全体ピクチャがステレオであった場合には、全体ピクチャのステレオ情報を持つStereo Video Boxがシグナルされるようにしてもよい。このようにすることにより、クライアント装置２００は、Sub Picture Composition Boxをパースせず、sub-picture track単独の選択・再生することができる。
【０３３１】
なお、このscheme_specific_dataには、Stereo Video Boxに限らず、全体ピクチャに関するポストプロセッシング情報がシグナルされるようにしてもよい（例えば、Region Wise Packing Boxなど）。
【０３３２】
＜sub-picture track選択を容易にする追加情報＞
さらに、2D Coverage Information Boxを拡張し、track選択を容易にするステレオ関連情報をシグナルするようにしてもよい。
【０３３３】
例えば、2D Coverage Information Boxにstereo_presentation_suitable_flagを追加し、sub-picture trackがステレオ表示可能か否かをシグナルするようにしてもよい。この情報を参照することで、クライアント装置２００は、第３の実施の形態において上述した全体ピクチャのステレオ情報と、第１の実施の形態において定義した2D Coverage Information Boxでシグナルされるprojected picture上における領域情報に基づいてステレオ表示が可能であるか否かを識別する処理を行わずとも、ステレオ表示が可能であるか否かを識別することができる。
【０３３４】
つまり、ISOBMFFファイルが、サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含むようにしてもよい。
【０３３５】
図６０のシンタックス５０２は、この場合の2D Coverage Information Boxの例を示す。シンタックス５０２に示されるように、この場合、さらにstereo_presentation_suitableが定義される（定義されるフィールドにstereo_presentation_suitableが追加される）。
【０３３６】
図６１のセマンティクス５０３は、この追加されるフィールドのセマンティクスの例を示す。セマンティクス５０３に示されるように、stereo_presentation_suitableは、trackのピクチャのステレオ表示に関する情報である。このフィールドの値が０の場合、trackのピクチャがモノであるか、または、L view、R viewを含むがステレオ表示不可能であることを示す。このフィールドの値が１の場合、trackのピクチャは、一部領域のステレオ表示が可能であることを示す。このフィールドの値が２の場合、trackのピクチャは全ての領域がステレオ表示可能であることを示す。
【０３３７】
図６２は、stereo_presentation_suitableのシグナル例を示す図である。例えば、図６２の上側に示されるように、side by sideのステレオ画像である全体ピクチャ（projected picture）５１１を、sub-picture化して生成された、sub-picture５１２乃至sub-picture５１７は、L viewとR viewを含み、ステレオ表示可能である。したがって、これらのsub-pictureには、stereo_presentation_suitable=2がセットされる。
【０３３８】
これに対して、図６２の下側に示されるように、side by sideのステレオ画像である全体ピクチャ（projected picture）５２１を、sub-picture化して生成された、sub-picture５２２乃至sub-picture５２６は、L viewとR viewを含む。ただし、sub-picture５２２乃至sub-picture５２４は、ステレオ表示することができない。したがって、これらのsub-pictureには、stereo_presentation_suitable=0がセットされる。
【０３３９】
また、sub-picture５２５およびsub-picture５２６は、一部の領域をステレオ表示することができる。したがって、これらのsub-pictureには、stereo_presentation_suitable=1がセットされる。
【０３４０】
なお、ステレオ表示可能か否かの情報を、個別のBox（その情報を格納する為の専用のBox）、例えばTrack Stereo Video Boxを新規定義して、sub-picture trackのschi下にシグナルするようにしてもよい。
【０３４１】
図６３のシンタックス５３１は、その場合のTrack Stereo Video Boxのシンタックスの例を示す。
【０３４２】
また、sub-picture trackのSample EntryのProjected Omnidirectional Video Box下でシグナルされるRegion Wise Packing Box、または、第１の実施の形態において上述したRectProjected Region構造を拡張し、stereo_presentation_suitable_flagをシグナルするようにしてもよい。また、その他のBoxにstereo_presentation_suitable_flagをシグナルするようにしてもよい。
【０３４３】
さらに、ステレオ表示が不可能である場合においては、Track Header Boxのtrack_not_intended_for_presentation_aloneフラグを用い、sub-picture単独再生が望ましくないことをシグナルするようにしてもよい。
【０３４４】
なお、上述の各種情報は、trackに格納されるpictureがsub-pictureでない場合においても適用可能である。
【０３４５】
＜view情報のシグナル＞
また、2D Coverage Information Boxを拡張し、sub-pictureのprojected picture上における表示領域に対し、view情報を追加でシグナルするようにしてもよい。この情報を参照することで、クライアント装置２００は、第３の実施の形態において上述した全体ピクチャのステレオ情報と、第３の実施の形態において定義した2D Coverage Information Boxでシグナルされるprojected picture上における領域情報から各領域のview情報を識別する処理を行わずとも、sub-pictureがモノ画像であるか、L viewおよびR viewを含むのかを容易に識別することができる。
【０３４６】
つまり、ISOBMFFファイルが、サブピクチャのビュータイプを示すビュー情報をさらに含むようにしてもよい。
【０３４７】
図６４のシンタックス５３２は、この場合の2D Coverage Information Boxのシンタックスの例を示す図である。シンタックス５３２に示されるように、この場合、2D Coverage Information Boxにおいて、view_idc_presence_flag、default_view_idc、view_idc等のフィールドが追加的に定義される。
【０３４８】
図６５のセマンティクス５３３は、この2D Coverage Information Boxにおいて追加的に定義されるフィールドのセマンティクスの例を示す。セマンティクス５３３に示されるように、view_idc_presense_flagは、各領域に個別のview_idcが存在するか否かを示す。例えば、このフィールドの値が０の場合、各領域に個別のview_idcが存在しないことを示す。また、このフィールドの値が１の場合、各領域に個別のview_idcが存在することを示す。
【０３４９】
つまり、ISOBMFFファイルが、ビュー情報が領域毎に存在するかを示す情報をさらに含むようにしてもよい。
【０３５０】
default_view_idcは、領域全てに共通なviewを示す。例えば、このフィールドの値が０の場合、このsub-picture内の全ての領域がmono viewであることを示す。また、このフィールドの値が１の場合、このsub-picture内の全ての領域がleft viewであることを示す。また、このフィールドの値が２の場合、このsub-picture内の全ての領域がright viewであることを示す。また、このフィールドの値が３の場合、このsub-picture内の全ての領域がstereo viewであることを示す。
【０３５１】
view_idcは、領域毎のviewを示す。例えば、このフィールドの値が０の場合、その領域がmono viewであることを示す。また、このフィールドの値が１の場合、その領域がleft viewであることを示す。また、このフィールドの値が２の場合、その領域がright viewであることを示す。また、このフィールドの値が３の場合、その領域がstereo viewであることを示す。また、このフィールドが存在しない場合、default_view_idcが各領域のviewを示すことを示す。
【０３５２】
つまり、ビュー情報は、サブピクチャに含まれる領域毎の情報であってもよい。
【０３５３】
図６６は、このview_idcをシグナルする様子の例を示す図である。図６６に示されるように、side by sideの全体ピクチャ５４１を、sub-picture５４２およびsub-picture５４３のようにsub-picture化する場合、これらのsub-pictureには、それぞれ、view_idc=3がセットされる。
【０３５４】
これに対して、全体ピクチャ５４１を、sub-picture５４４およびsub-picture５４５のようにsub-picture化する場合、sub-picture５４４に対しては、view_idc=1がセットされ、sub-picture５４５に対しては、view_idc=2がセットされる。
【０３５５】
なお、trackに格納されるpictureがsub-pictureでない場合においても、これらの追加情報を適用することができる。
【０３５６】
同様に、Region Wise Packing Box、および第１の実施の形態において定義したRect Projected Region構造を拡張し、view情報をシグナルするようにしてもよい。
【０３５７】
＜５．第４の実施の形態＞
＜MPDファイルによるsub-picture化される全体ピクチャのステレオ情報のシグナル＞
上述したsub-picture化される全体ピクチャのステレオ情報のシグナルを、MPDファイルにおいて行うようにしてもよい。つまり、クライアントが、sub-pictureを参照するAdaptation Setを例えばクライアントの能力（capability）に応じて選択・再生することを可能にするために、MPDファイルにおいて、sub-picture化される全体ピクチャのステレオ情報を新規定義し、Adaptation Setにシグナルするようにしてもよい。
【０３５８】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを生成するようにしてもよい。
【０３５９】
例えば、情報処理装置であるファイル生成装置１００において、MPDファイル生成部１１３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばMPDファイル生成部１１３）を備えるようにしてもよい。
【０３６０】
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０３６１】
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
【０３６２】
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
【０３６３】
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０３６４】
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図６７のフローチャートを参照して説明する。
【０３６５】
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ４０１において、画像とメタデータを取得する。
【０３６６】
ステップＳ４０２において、セグメントファイル生成部１２３は、その画像のセグメントファイルを生成する。
【０３６７】
ステップＳ４０３において、MPDファイル生成部１１３は、sub-picture毎の情報として、全体ピクチャ（projected picture）のステレオ情報を含むMPDファイルを生成する。
【０３６８】
ステップＳ４０４において、記録部１１４は、ステップＳ４０２の処理により生成されたセグメントファイルを記録する。また、記録部１１４は、ステップＳ４０３の処理により生成されたMPDファイルを記録する。
【０３６９】
ステップＳ４０５において、アップロード部１１５は、ステップＳ４０４において記録されたセグメントファイルを記録部１１４より読み出し、それをサーバにアップロードする。また、アップロード部１１５は、ステップＳ４０４において記録されたMPDファイルを記録部１１４より読み出し、それをサーバにアップロードする。
【０３７０】
ステップＳ４０４の処理が終了すると、アップロード処理が終了する。
【０３７１】
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、全体ピクチャのステレオ情報を含むMPDファイルを生成することができる。
【０３７２】
したがって、クライアントは、その表示領域情報に基づいて、例えばクライアント装置２００の機能（capability）に応じた適切なストリームをより容易に選択し、再生することができる。
【０３７３】
＜MPDファイルにシグナルされたsub-picture化される全体ピクチャのステレオ情報の利用＞
また、MPDファイルにシグナルされた、sub-picture化される全体ピクチャのステレオ情報を利用してストリームの選択を行うようにしてもよい。
【０３７４】
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを取得し、その取得された制御ファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
【０３７５】
例えば、情報処理装置であるクライアント装置２００において、MPDファイル取得部２１２が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部として機能し、MPDファイル処理部２１３が、その取得された制御ファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばMPDファイル取得部２１２）と、画像処理部（例えばMPDファイル処理部２１３）とを備えるようにしてもよい。
【０３７６】
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
【０３７７】
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
【０３７８】
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
【０３７９】
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図６８のフローチャートを参照して説明する。
【０３８０】
コンテンツ再生処理が開始されると、クライアント装置２００のMPDファイル取得部２１２は、ステップＳ４２１において、sub-picture毎の情報として全体ピクチャ（projected picture）のステレオ情報を含むMPDファイルを取得する。
【０３８１】
ステップＳ４２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
【０３８２】
ステップＳ４２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
【０３８３】
ステップＳ４２４において、MPDファイル処理部２１３は、クライアント装置２００がステレオ再生を行うか否か（またはステレオ再生を行う機能（capability）を有するか否か）を判定する。ステレオ再生を行う（またはステレオ再生の機能を有する）と判定された場合、処理はステップＳ４２５に進む。
【０３８４】
ステップＳ４２５において、MPDファイル処理部２１３は、ステレオ表示可能なsub-pictureを参照するAdaptation Setを選択候補とする。その際、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第２のパターンのフレームパッキングアレンジメントが適用されていないステレオ表示可能なsub-picture（例えば、図４９のsub-picture４４５やsub-picture４４６）を参照するAdaptation Setも選択候補に含めることができる。ステップＳ４２５の処理が終了すると、処理はステップＳ４２７に進む。
【０３８５】
また、ステップＳ４２４において、クライアント装置２００がステレオ再生を行わない（またはステレオ再生の機能を有していない）と判定された場合、処理はステップＳ４２６に進む。
【０３８６】
ステップＳ４２６において、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報等に基づいて、モノピクチャのsub-pictureを参照するAdaptation Setを選択候補とする。その際、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第３のパターンのsub-picture（例えば、図５０のsub-picture４５２やsub-picture４５３）について、レンダリングの際に水平方向に２倍のアップスケール（upscale）が必要であることを把握することができる。ステップＳ４２６の処理が終了すると、処理はステップＳ４２７に進む。
【０３８７】
ステップＳ４２７において、MPDファイル処理部２１３は、ステップＳ４２５またはステップＳ４２６において設定した候補の中から、クライアント装置２００のユーザの視野に相当する（対応する）sub-pictureを参照するAdaptation Setを選択する。
【０３８８】
ステップＳ４２８において、MPDファイル処理部２１３は、ステップＳ４２４において選択されたAdaptation Setの中から、ユーザの視点位置および視線方向やクライアントとサーバとの間のネットワークの伝送帯域幅等に応じたリプレゼンテーション（Representation）を選択する。
【０３８９】
ステップＳ４２９において、セグメントファイル取得部２１４は、ステップＳ４２８において選択されたリプレゼンテーション（Representation）に対応するセグメントファイルを取得する。
【０３９０】
ステップＳ４３０において、セグメントファイル処理部２２１は、ステップＳ４２９において取得されたセグメントファイルから符号化データを抽出する。
【０３９１】
ステップＳ４３１において、デコード部２２２は、ステップＳ４３０において抽出されたストリームの符号化データを復号する。
【０３９２】
ステップＳ４３２において、表示情報生成部２２３は、ステップＳ４３１において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
【０３９３】
ステップＳ４３２の処理が終了すると、コンテンツ再生処理が終了する。
【０３９４】
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、MPDファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
【０３９５】
＜MPDファイルにおけるステレオ情報のシグナル詳細＞
例えば、2D coverage information descriptorを拡張し、第３の実施の形態において説明した場合と同様に、stereo_presentation_suitableフィールド、およびview情報をシグナルするようにしてもよい。
【０３９６】
つまり、MPDファイルは、サブピクチャのビュータイプを示すビュー情報をさらに含むようにしてもよい。
【０３９７】
また、そのビュー情報は、サブピクチャに含まれる領域毎の情報であるようにしてもよい。
【０３９８】
さらに、MPDファイルは、そのビュー情報が領域毎に存在するかを示す情報をさらに含むようにしてもよい。
【０３９９】
図６９の属性値５５１および図７０の属性値５５２は、拡張した2D coverage information descriptorの属性値の例を示す。属性値５５１および属性値５５２に示されるように、twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるコンテナ要素である。twoDCoverage@stereo_presentation_suitableは、データタイプがomaf:StereoPresentationTypeであり、Adaptation Setがステレオ表示可能かどうか示す。例えば、この属性値が０の場合、Adaptation Setが参照するピクチャがモノであるか、または、ステレオ表示不可能であることを示す。また、この属性値が１の場合、Adaptation Setが参照するピクチャは、一部の領域のステレオ表示が可能であることを示す。また、この属性値が２の場合、Adaptation Setが参照するピクチャは、全ての領域のステレオ表示が可能であることを示す。
【０４００】
twoDCoverage@view_idc_presence_flagは、データタイプがxs:booleanであり、各領域に個別のview_idcが存在するか否かを示す。例えばこの属性値が０の場合、各領域に個別のview_idcが存在しないことを示す。また、この属性値が１の場合、各領域に個別のview_idcが存在することを示す。twoDCoverage@default_view_idcは、データタイプがomaf:ViewTypeであり、領域全てに共通なviewを示す。例えば、この属性値が０の場合、mono viewであることを示し、この属性値が１の場合、left viewであることを示し、この属性値が２の場合、right viewであることを示し、この属性値が３の場合、stereo viewであることを示す。なお、twoDCoverage@view_idc_presence_flag=0のとき、この属性は必ず存在する。また、twoDCoverage@view_idc_presence_flag=1のとき、この属性は存在してはいけない。
【０４０１】
twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素である。この要素は、複数シグナルすることができる。
【０４０２】
twoDCoverage.twoDCoverageInfo@view_idcは、データタイプがomaf:ViewTypeであり、領域ごとのviewを示す。例えば、この属性値が０の場合、mono viewであることを示し、この属性値が１の場合、left viewであることを示し、この属性値が２の場合、right viewであることを示し、この属性値が３の場合、stereo viewであることを示す。なお、twoDCoverage@view_idc_presence_flag=0のとき、この属性は存在してはいけない。また、twoDCoverage@view_idc_presence_flag=1のとき、この属性は必ず存在する。
【０４０３】
twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCcoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
【０４０４】
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
【０４０５】
図７１のデータタイプ５５３は、この場合のデータタイプの定義の例を示す。
【０４０６】
なお、第２の実施の形態において説明した、拡張したRegion-wise packing descriptorおよびContent coverage descriptorをさらに拡張し、stereo_presentation_suitableおよびview情報をシグナルするようにしてもよい。また、その他のdescriptorを用いてこれらの情報をシグナルするようにしてもよい。
【０４０７】
＜６．付記＞
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
【０４０８】
図７２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０４０９】
図７２に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
【０４１０】
バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
【０４１１】
入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
【０４１２】
以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０４１３】
コンピュータ（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
【０４１４】
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
【０４１５】
その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
【０４１６】
＜本技術の適用対象＞
以上においては、ISOBMFFファイルまたはMPDファイルに本技術を適用する場合について説明したが、本技術は、これらの例に限らず、立体構造画像を単数の平面にマッピングした投影平面画像のストリームを配信する、任意の規格のファイルに対して適用することができる。つまり、上述した本技術と矛盾しない限り、配信制御、ファイル形式、符号化・復号方式等の各種処理の仕様は任意である。また、本技術と矛盾しない限り、上述した一部の処理や仕様を省略してもよい。
【０４１７】
また、以上においては、本技術の適用例としてファイル生成装置１００やクライアント装置２００について説明したが、本技術は、任意の構成に適用することができる。
【０４１８】
例えば、本技術は、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、およびセルラー通信による端末への配信などにおける送信機や受信機（例えばテレビジョン受像機や携帯電話機）、または、光ディスク、磁気ディスクおよびフラッシュメモリなどの媒体に画像を記録したり、これら記憶媒体から画像を再生したりする装置（例えばハードディスクレコーダやカメラ）などの、様々な電子機器に適用され得る。
【０４１９】
また、例えば、本技術は、システムLSI（Large Scale Integration）等としてのプロセッサ（例えばビデオプロセッサ）、複数のプロセッサ等を用いるモジュール（例えばビデオモジュール）、複数のモジュール等を用いるユニット（例えばビデオユニット）、または、ユニットにさらにその他の機能を付加したセット（例えばビデオセット）等、装置の一部の構成として実施することもできる。
【０４２０】
また、例えば、本技術は、複数の装置により構成されるネットワークシステムにも適用することもできる。例えば、本技術を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングとして実施するようにしてもよい。例えば、コンピュータ、AV（Audio Visual）機器、携帯型情報処理端末、IoT（Internet of Things）デバイス等の任意の端末に対して、画像（動画像）に関するサービスを提供するクラウドサービスにおいて本技術を実施するようにしてもよい。
【０４２１】
なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、および、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０４２２】
＜本技術を適用可能な分野・用途＞
本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。また、その用途も任意である。
【０４２３】
例えば、本技術は、観賞用コンテンツ等の提供の用に供されるシステムやデバイスに適用することができる。また、例えば、本技術は、交通状況の監理や自動運転制御等、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、機械等の自動制御の用に供されるシステムやデバイスに適用することができる。さらに、例えば、本技術は、農業や畜産業の用に供されるシステムやデバイスにも適用することができる。また、本技術は、例えば火山、森林、海洋等の自然の状態や野生生物等を監視するシステムやデバイスにも適用することができる。さらに、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。
【０４２４】
＜その他＞
なお、本明細書において「フラグ」とは、複数の状態を識別するための情報であり、真(1)または偽(0)の２状態を識別する際に用いる情報だけでなく、３以上の状態を識別することが可能な情報も含まれる。したがって、この「フラグ」が取り得る値は、例えば1/0の２値であってもよいし、３値以上であってもよい。すなわち、この「フラグ」を構成するbit数は任意であり、1bitでも複数bitでもよい。また、識別情報（フラグも含む）は、その識別情報をビットストリームに含める形だけでなく、ある基準となる情報に対する識別情報の差分情報をビットストリームに含める形も想定されるため、本明細書においては、「フラグ」や「識別情報」は、その情報だけではなく、基準となる情報に対する差分情報も包含する。
【０４２５】
また、符号化データ（ビットストリーム）に関する各種情報（メタデータ等）は、符号化データに関連づけられていれば、どのような形態で伝送または記録されるようにしてもよい。ここで、「関連付ける」という用語は、例えば、一方のデータを処理する際に他方のデータを利用し得る（リンクさせ得る）ようにすることを意味する。つまり、互いに関連付けられたデータは、１つのデータとしてまとめられてもよいし、それぞれ個別のデータとしてもよい。例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の伝送路上で伝送されるようにしてもよい。また、例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の記録媒体（または同一の記録媒体の別の記録エリア）に記録されるようにしてもよい。なお、この「関連付け」は、データ全体でなく、データの一部であってもよい。例えば、画像とその画像に対応する情報とが、複数フレーム、１フレーム、またはフレーム内の一部分などの任意の単位で互いに関連付けられるようにしてもよい。
【０４２６】
なお、本明細書において、「合成する」、「多重化する」、「付加する」、「一体化する」、「含める」、「格納する」、「入れ込む」、「差し込む」、「挿入する」等の用語は、例えば符号化データとメタデータとを１つのデータにまとめるといった、複数の物を１つにまとめることを意味し、上述の「関連付ける」の１つの方法を意味する。
【０４２７】
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０４２８】
例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０４２９】
また、例えば、上述したプログラムは、任意の装置において実行されるようにしてもよい。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
【０４３０】
また、例えば、１つのフローチャートの各ステップを、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。さらに、１つのステップに複数の処理が含まれる場合、その複数の処理を、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
【０４３１】
また、例えば、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
【０４３２】
また、例えば、本技術に関する複数の技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
【０４３３】
なお、本技術は以下のような構成も取ることができる。
（１）  格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部
を備える情報処理装置。
（２）  前記ピクチャは、全天球映像である
（１）に記載の情報処理装置。
（３）  前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（１）または（２）に記載の情報処理装置。
（４）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ピクチャ領域ごとの配置情報は、Region Wise Packing Boxにシグナルされる情報であり、
前記領域に関する情報は、Region Wise Packing Boxとは異なる、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（３）に記載の情報処理装置。
（５）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、トラックの球面上における表示領域を示すCoverage Information Boxに格納される
（３）に記載の情報処理装置。
（６）  前記領域に関する情報は、ストリーム中で動的に変化する
（１）乃至（５）のいずれかに記載の情報処理装置。
（７）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Supplemental Enhancement information messageに格納される
（６）に記載の情報処理装置。
（８）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、timed metadataに格納される
（６）に記載の情報処理装置。
（９）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Sample Group Entryに格納される
（６）に記載の情報処理装置。
（１０）  格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成する
情報処理方法。
【０４３４】
（１１）  格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（１２）  前記ピクチャは、全天球映像である
（１１）に記載の情報処理装置。
（１３）  前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（１１）または（１２）に記載の情報処理装置。
（１４）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（１３）に記載の情報処理装置。
（１５）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、トラックの球面上における表示領域を示すCoverage Information Boxに格納される
（１３）に記載の情報処理装置。
（１６）  前記領域に関する情報は、ストリーム中で動的に変化する
（１１）乃至（１５）のいずれかに記載の情報処理装置。
（１７）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Supplemental Enhancement information messageに格納される
（１６）に記載の情報処理装置。
（１８）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、timed metadataに格納される
（１６）に記載の情報処理装置。
（１９）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Sample Group Entryに格納される
（１６）に記載の情報処理装置。
（２０）  格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得し、
取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
【０４３５】
（２１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するファイル生成部
を備える情報処理装置。
（２２）  前記ピクチャは、全天球映像である
（２１）に記載の情報処理装置。
（２３）  前記ステレオ情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（２１）または（２２）に記載の情報処理装置。
（２４）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ステレオ情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（２３）に記載の情報処理装置。
（２５）  前記ファイルは、前記サブピクチャの表示サイズに関する情報をさらに含む
（２１）乃至（２４）のいずれかに記載の情報処理装置。
（２６）  前記ファイルは、前記サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含む
（２１）乃至（２５）のいずれかに記載の情報処理装置。
（２７）  前記ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（２１）乃至（２６）のいずれかに記載の情報処理装置。
（２８）  前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（２７）に記載の情報処理装置。
（２９）  前記ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（２８）に記載の情報処理装置。
（３０）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成する
情報処理方法。
【０４３６】
（３１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（３２）  前記ピクチャは、全天球映像である
（３１）に記載の情報処理装置。
（３３）  前記ステレオ情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（３１）または（３２）に記載の情報処理装置。
（３４）  前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ステレオ情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（３３）に記載の情報処理装置。
（３５）  前記ファイルは、前記サブピクチャの表示サイズに関する情報をさらに含む
（３１）乃至（３４）のいずれかに記載の情報処理装置。
（３６）  前記ファイルは、前記サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含む
（３１）乃至（３５）のいずれかに記載の情報処理装置。
（３７）  前記ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（３１）乃至（３６）のいずれかに記載の情報処理装置。
（３８）  前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（３７）に記載の情報処理装置。
（３９）  前記ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（３８）に記載の情報処理装置。
（４０）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得し、
取得された前記ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
【０４３７】
（４１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部
を備える情報処理装置。
（４２）  前記ピクチャは、全天球映像である
（４１）に記載の情報処理装置。
（４３）  前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
（４１）または（４２）に記載の情報処理装置。
（４４）  前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
（４３）に記載の情報処理装置。
（４５）  前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのContent coverage descriptorに定義される
（４３）に記載の情報処理装置。
（４６）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する
情報処理方法。
【０４３８】
（５１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（５２）  前記ピクチャは、全天球映像である
（５１）に記載の情報処理装置。
（５３）  前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
（５１）または（５２）に記載の情報処理装置。
（５４）  前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
（５３）に記載の情報処理装置。
（５５）  前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのContent coverage descriptorに定義される
（５３）に記載の情報処理装置。
（５６）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、
取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
【０４３９】
（６１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部
を備える情報処理装置。
（６２）  前記ピクチャは、全天球映像である
（６１）に記載の情報処理装置。
（６３）  前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（６１）または（６２）に記載の情報処理装置。
（６４）  前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（６３）に記載の情報処理装置。
（６５）  前記制御ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（６３）または（６４）に記載の情報処理装置。
（６６）  前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
（６３）乃至（６５）のいずれかに記載の情報処理装置。
（６７）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する
情報処理方法。
【０４４０】
（７１）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記制御ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（７２）  前記ピクチャは、全天球映像である
（７１）に記載の情報処理装置。
（７３）  前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（７１）または（７２）に記載の情報処理装置。
（７４）  前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（７３）に記載の情報処理装置。
（７５）  前記制御ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（７３）または（７４）に記載の情報処理装置。
（７６）  前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
（７３）乃至（７５）のいずれかに記載の情報処理装置。
（７７）  ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、
取得された前記制御ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
【符号の説明】
【０４４１】
１００  ファイル生成装置，  １０１  制御部，  １０２  メモリ，  １０３  ファイル生成部，  １１１  データ入力部，  １１２  データ符号化・生成部，  １１３  MPDファイル生成部，  １１４  記録部，  １１５  アップロード部，  １２１  前処理部，  １２２  エンコード部，  １２３  セグメントファイル生成部，  ２００  クライアント装置，  ２０１  制御部，  ２０２  メモリ，  ２０３  再生処理部，  ２１１  計測部，  ２１２  MPDファイル取得部，  ２１３  MPDファイル処理部，  ２１４  セグメントファイル取得部，  ２１５  表示制御部，  ２１６  データ解析・復号部，  ２１７  表示部，  ２２１  セグメントファイル処理部，  ２２２  デコード部，  ２２３  表示情報生成部，  ９００  コンピュータ
【図１】
2019138928.tif 000003
【図２】
2019138928.tif 000004
【図３】
2019138928.tif 000005
【図４】
2019138928.tif 000006
【図５】
2019138928.tif 000007
【図６】
2019138928.tif 000008
【図７】
2019138928.tif 000009
【図８】
2019138928.tif 000010
【図９】
2019138928.tif 000011
【図１０】
2019138928.tif 000012
【図１１】
2019138928.tif 000013
【図１２】
2019138928.tif 000014
【図１３】
2019138928.tif 000015
【図１４】
2019138928.tif 000016
【図１５】
2019138928.tif 000017
【図１６】
2019138928.tif 000018
【図１７】
2019138928.tif 000019
【図１８】
2019138928.tif 000020
【図１９】
2019138928.tif 000021
【図２０】
2019138928.tif 000022
【図２１】
2019138928.tif 000023
【図２２】
2019138928.tif 000024
【図２３】
2019138928.tif 000025
【図２４】
2019138928.tif 000026
【図２５】
2019138928.tif 000027
【図２６】
2019138928.tif 000028
【図２７】
2019138928.tif 000029
【図２８】
2019138928.tif 000030
【図２９】
2019138928.tif 000031
【図３０】
2019138928.tif 000032
【図３１】
2019138928.tif 000033
【図３２】
2019138928.tif 000034
【図３３】
2019138928.tif 000035
【図３４】
2019138928.tif 000036
【図３５】
2019138928.tif 000037
【図３６】
2019138928.tif 000038
【図３７】
2019138928.tif 000039
【図３８】
2019138928.tif 000040
【図３９】
2019138928.tif 000041
【図４０】
2019138928.tif 000042
【図４１】
2019138928.tif 000043
【図４２】
2019138928.tif 000044
【図４３】
2019138928.tif 000045
【図４４】
2019138928.tif 000046
【図４５】
2019138928.tif 000047
【図４６】
2019138928.tif 000048
【図４７】
2019138928.tif 000049
【図４８】
2019138928.tif 000050
【図４９】
2019138928.tif 000051
【図５０】
2019138928.tif 000052
【図５１】
2019138928.tif 000053
【図５２】
2019138928.tif 000054
【図５３】
2019138928.tif 000055
【図５４】
2019138928.tif 000056
【図５５】
2019138928.tif 000057
【図５６】
2019138928.tif 000058
【図５７】
2019138928.tif 000059
【図５８】
2019138928.tif 000060
【図５９】
2019138928.tif 000061
【図６０】
2019138928.tif 000062
【図６１】
2019138928.tif 000063
【図６２】
2019138928.tif 000064
【図６３】
2019138928.tif 000065
【図６４】
2019138928.tif 000066
【図６５】
2019138928.tif 000067
【図６６】
2019138928.tif 000068
【図６７】
2019138928.tif 000069
【図６８】
2019138928.tif 000070
【図６９】
2019138928.tif 000071
【図７０】
2019138928.tif 000072
【図７１】
2019138928.tif 000073
【図７２】
2019138928.tif 000074
【図７３】
2019138928.tif 000075
【図７４】
2019138928.tif 000076
【国際調査報告】
2019138928.tif 000077
2019138928.tif 000078
2019138928.tif 000079
2019138928.tif 000080