(57)【要約】  本開示は、コンテンツ再生のロバスト性を向上させることができるようにする情報処理装置および方法に関する。３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する。例えば、その情報として、コンテンツの再生を制御する制御ファイルのアクセス情報を含むメタデータを生成する。本開示は、例えば、画像処理装置、画像符号化装置、または画像復号装置等に適用することができる。
2020116154.tif 000002
【特許請求の範囲】
【請求項１】
３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部
を備える情報処理装置。
【請求項２】
前記生成部は、前記情報として、前記コンテンツの再生を制御する制御ファイルのアクセス情報を含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項３】
前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含む前記メタデータを生成する
請求項２に記載の情報処理装置。
【請求項４】
前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトに対応するAdaptationSetの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含む前記メタデータを生成する
請求項２に記載の情報処理装置。
【請求項５】
前記生成部は、所望の前記MPDのアクセス情報、前記MPD内の所望のAdaptationSetを指定する情報、および前記AdaptationSet内の所望のRepresentationを指定する情報からなる前記アクセス情報を含む前記メタデータを生成する
請求項４に記載の情報処理装置。
【請求項６】
前記生成部は、さらに、互いに同一のビットレートバリエーションをグループ化する情報を含む前記MPDを生成する
請求項４に記載の情報処理装置。
【請求項７】
前記生成部は、さらに、前記メタデータへのアクセス情報を含まない前記MPDを生成する
請求項２に記載の情報処理装置。
【請求項８】
前記メタデータは、前記コンテンツの、視点位置に基づく空間表示制御情報であり、
前記生成部は、前記コンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する前記視点位置に基づく空間表示制御情報を生成する
請求項１に記載の情報処理装置。
【請求項９】
前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む前記視点位置に基づく空間表示制御情報を生成する
請求項８に記載の情報処理装置。
【請求項１０】
前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む前記視点位置に基づく空間表示制御情報を生成する
請求項８に記載の情報処理装置。
【請求項１１】
前記生成部は、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項１２】
前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項１３】
前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含む前記メタデータを生成する
請求項１２に記載の情報処理装置。
【請求項１４】
前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含む前記メタデータを生成する
請求項１２に記載の情報処理装置。
【請求項１５】
前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な前記３次元オブジェクトの各ビットレートバリエーションを示す情報を含む前記メタデータを生成する
請求項１２に記載の情報処理装置。
【請求項１６】
前記生成部は、前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項１７】
前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報に基づいて前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項１８】
前記生成部は、前記３次元オブジェクトの重要度を示す情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項１９】
前記生成部は、注目する３次元オブジェクトの重要度を指定する情報をさらに含む前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項２０】
３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および方法に関し、特に、コンテンツ再生のロバスト性を向上させることができるようにした情報処理装置および方法に関する。
【背景技術】
【０００２】
従来、３次元空間（3D空間とも称する）の３次元オブジェクト（3Dオブジェクトとも称する）を表現する３次元コンテンツ（3Dコンテンツとも称する）の配信が提案された。また、この3Dコンテンツとしては、例えば、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能な6DoFコンテンツが提案された。【０００３】
6DoFコンテンツの配信方法として、例えば、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームとして伝送する方法が提案された。そして、その際、例えば、Scene Descriptionという記述法を用いることが提案された。このScene Descriptionとして、シーンをシーングラフと呼ばれるツリー階層構造のグラフで表現し、そのシーングラフをバイナリ形式またはテキスト形式で表現する方法（MPEG-4 Scene Description）が提案された（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】"ISO/IEC 14496-11", Second Edition, 2015-05-29
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、伝送帯域に関しては、Scene Descriptionは、伝送帯域に応じてアダプティブに配信する機能を有していない。そのため、Scene Descriptionデータおよびメディアデータを伝送するだけの十分な伝送帯域が確保できる場合は再生が可能であるが、伝送帯域が限られてしまうと、クライアントはデータの取得ができず、再生ができないまたは途切れるといったことが起きるおそれがあった。【０００６】
本開示は、このような状況に鑑みてなされたものであり、コンテンツ再生のロバスト性を向上させることができるようにするものである。
【課題を解決するための手段】
【０００７】
本技術の一側面の情報処理装置は、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部を備える情報処理装置である。【０００８】
本技術の一側面の情報処理方法は、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する情報処理方法である。【０００９】
本技術の一側面の情報処理装置および方法においては、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータが生成される。
【図面の簡単な説明】
【００１０】
【図１】シーングラフの例について説明する図である。
【図２】ノードの例について説明する図である。
【図３】ノードのシンタックスの例について説明する図である。
【図４】LODノードの例について説明する図である。
【図５】シーングラフの例について説明する図である。
【図６】配信システムの主な構成例を示すブロック図である。
【図７】ファイル生成装置の主な構成例を示すブロック図である。
【図８】クライアント装置の主な構成例を示すブロック図である。
【図９】ファイル生成処理の流れの例を説明するフローチャートである。
【図１０】再生処理の流れの例を説明するフローチャートである。
【図１１】Scene Descriptionの例について説明する図である。
【図１２】MPDの例について説明する図である。
【図１３】Scene Descriptionの例について説明する図である。
【図１４】MPDの例について説明する図である。
【図１５】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図１６】ファイル生成処理の流れの例を説明するフローチャートである。
【図１７】再生処理の流れの例を説明するフローチャートである。
【図１８】Scene Description処理の流れの例を説明するフローチャートである。
【図１９】レンダリング処理の流れの例を説明するフローチャートである。
【図２０】Scene Descriptionの例について説明する図である。
【図２１】MPDの例について説明する図である。
【図２２】Scene Descriptionの例について説明する図である。
【図２３】MPDの例について説明する図である。
【図２４】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図２５】Scene Descriptionの例について説明する図である。
【図２６】MPDの例について説明する図である。
【図２７】MPDの例について説明する図である。
【図２８】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図２９】配信システムの主な構成例を示すブロック図である。
【図３０】ファイル生成装置の主な構成例を示すブロック図である。
【図３１】クライアント装置の主な構成例を示すブロック図である。
【図３２】ファイル生成処理の流れの例を説明するフローチャートである。
【図３３】再生処理の流れの例を説明するフローチャートである。
【図３４】ClientSelectionノードの例について説明する図である。
【図３５】Scene Descriptionの例について説明する図である。
【図３６】ファイル生成処理の流れの例を説明するフローチャートである。
【図３７】再生処理の流れの例を説明するフローチャートである。
【図３８】Scene Description処理の流れの例を説明するフローチャートである。
【図３９】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図４０】ファイル生成処理の流れの例を説明するフローチャートである。
【図４１】再生処理の流れの例を説明するフローチャートである。
【図４２】MPDの例について説明する図である。
【図４３】MPDの例について説明する図である。
【図４４】再生処理の流れの例を説明するフローチャートである。
【図４５】Scene Description処理の流れの例を説明するフローチャートである。
【図４６】ファイル生成処理の流れの例を説明するフローチャートである。
【図４７】再生処理の流れの例を説明するフローチャートである。
【図４８】ClientSelectionノードの例について説明する図である。
【図４９】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図５０】ファイル生成処理の流れの例を説明するフローチャートである。
【図５１】再生処理の流れの例を説明するフローチャートである。
【図５２】MPDの例について説明する図である。
【図５３】MPDの例について説明する図である。
【図５４】再生処理の流れの例を説明するフローチャートである。
【図５５】ファイル生成処理の流れの例を説明するフローチャートである。
【図５６】再生処理の流れの例を説明するフローチャートである。
【図５７】ClientSelectionノードの例について説明する図である。
【図５８】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図５９】Qualityの種類の例について説明する図である。
【図６０】MPDの例について説明する図である。
【図６１】ClientSelectionノードの例について説明する図である。
【図６２】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図６３】MPDの例について説明する図である。
【図６４】ClientSelectionノードの例について説明する図である。
【図６５】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図６６】MPDの例について説明する図である。
【図６７】再生処理の流れの例を説明するフローチャートである。
【図６８】ビットレート選択処理の流れの例を説明するフローチャートである。
【図６９】ClientSelectionノードの例について説明する図である。
【図７０】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図７１】LODノードの例について説明する図である。
【図７２】ClientSelectionノードの例について説明する図である。
【図７３】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図７４】LODノードの例について説明する図である。
【図７５】ClientSelectionノードの例について説明する図である。
【図７６】MPDの例について説明する図である。
【図７７】ビットレート選択処理の流れの例を説明するフローチャートである。
【図７８】ClientSelectionノードの例について説明する図である。
【図７９】BitWrapperノードおよびMovieTextureノードの例について説明する図である。
【図８０】Transformノードの例について説明する図である。
【図８１】ビットレート選択処理の流れの例を説明するフローチャートである。
【図８２】部分３Dオブジェクトの例を示す図である。
【図８３】部分３DオブジェクトをシグナルするScene Descriptionの例を示す図である。
【図８４】部分３DオブジェクトをシグナルするScene Descriptionの例を示す図である。
【図８５】物体全体をシグナルするScene Descriptionの例を示す図である。
【図８６】BitwrapperノードとMovieTextureノードの例を示す図である。
【図８７】物体Ａが４つの部分３Ｄオブジェクトで構成される場合のMPDの例を示す図である。
【図８８】Periodで物体を構成するAdaptationSetをシグナルするMPDの例を示す図である。
【図８９】BitwrapperノードとMovieTextureノードの例を示す図である。
【図９０】BitwrapperノードとMovieTextureノードの例を示す図である。
【図９１】コンピュータの主な構成例を示すブロック図である。
【発明を実施するための形態】
【００１１】
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．技術内容・技術用語をサポートする文献等
２．6DoFコンテンツの配信
３．第１の実施の形態（ビットレートアダプテーション）
４．第２の実施の形態（ビットレートを一律に制御するためのシグナリング）
５．第３の実施の形態（取得するビットレートの組み合わせを示すシグナリング）
６．第４の実施の形態（Level of Detailの制御によりビットレートを選択するためのシグナリング）
７．第５の実施の形態（コンテンツオーサ等の意図を示すシグナリング）
８．第６の実施の形態（注目オブジェクトのLevel of Detailを保つための実装法）
９．第７の実施の形態（部分３Ｄオブジェクトで構成される場合のシグナリング）
１０．付記
【００１２】
＜１．技術内容・技術用語をサポートする文献等＞
本技術で開示される範囲は、実施例に記載されている内容だけではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
【００１３】
非特許文献１：（上述）
非特許文献２：R. Mekuria, Student Member IEEE, K. Blom, P. Cesar., Member, IEEE, "Design, Implementation and Evaluation of a Point Cloud Codec for Tele-Immersive Video",tcsvt_paper_submitted_february.pdf
非特許文献３：TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU（International Telecommunication Union）, "Advanced video coding for generic audiovisual services", H.264, 04/2017
非特許文献４：TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU（International Telecommunication Union）, "High efficiency video coding", H.265, 12/2016
非特許文献５：Jianle Chen, Elena Alshina, Gary J. Sullivan, Jens-Rainer, Jill Boyce, "Algorithm Description of Joint Exploration Test Model 4", JVET-G1001_v1, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 7th Meeting: Torino, IT, 13-21 July 2017
【００１４】
つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、非特許文献４に記載されているQuad-Tree Block Structure、非特許文献５に記載されているQTBT（Quad Tree Plus Binary Tree） Block Structureが実施例において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。また、例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、実施例において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
【００１５】
＜２．6DoFコンテンツの配信＞
＜２−１：コンテンツ＞
現在の映像配信においては、映画などの配信で利用されている２次元映像（2Dコンテンツとも称する）の配信が主流である。さらに、全方位が見まわし可能である360度映像配信も行われている。360度映像は、3DoF（Degree of Freedom）映像や3DoFコンテンツとも称する。2Dコンテンツ、3DoFコンテンツどちらも、基本は２次元にエンコードされた映像が配信され、クライアントで表示される。
【００１６】
また、3DoF+コンテンツと称するコンテンツもある。この3DoF+コンテンツは、3DoFコンテンツのように全方位の見回しが可能であり、さらに、視点位置を少し動かすことが可能であるコンテンツである。視点位置の動かせる範囲は、座っている状態で頭を動かせる程度が想定されている。3DoF+コンテンツは、２次元にエンコードされた映像を１つまたは複数使うことにより、視点位置の移動を実現している。
【００１７】
これに対して、全方位見回し（視線方向を自由に選択）することができ、さらに空間の中を歩いて回れる（視点位置を自由に選択することができる）6DoF映像（6DoFコンテンツとも称する）もある。6DoFコンテンツは、時刻毎に１つもしくは複数の３次元オブジェクト（3Dオブジェクトとも称する）で３次元空間（3D空間とも称する）を表現したものである。つまり、6DoFコンテンツは、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツである。
【００１８】
3Dオブジェクトとは、（１）3D空間内にある１つの物体、（２）（１）の物体の一部、（３）3D空間内の複数の物体の集合のいずれかを示している。3Dオブジェクトのデータとしては、多面体の形状データとして表すことのできるメッシュデータとその面に張り付けるデータであるテクスチャデータで構成する方法や、複数の点の集合で構成するもの（Point Cloud）がある。
【００１９】
6DoFコンテンツを伝送する方法としては、3D空間を１つの3Dオブジェクトで構成し１つのオブジェクトストリームで伝送する方法と、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームで伝送する方法が考えられる。
【００２０】
3D空間の表現として、6DoFコンテンツを2D DisplayやHMD（Head Mounted Display）で表示する場合、視点位置から離れている物体は、表示が小さくなり、近い場合は表示が大きくなるという6DoFコンテンツの表現特性がある。表示が小さい物体は解像度が低くてもよい。しかしながら、前者のように、広い領域の6DoFコンテンツを１つのオブジェクトストリームで伝送する場合、このような表示特性に関係なく6DoFコンテンツ全体の解像度が均一となってしまう。全体の解像度が均一であるということは、表示画面をレンダリングする場合、適切な解像度である部分もあれば、不必要に高い解像度の部分が存在することになる。不必要に高い解像度の部分は、余分なデコード・レンダリング処理が必要となる。すなわち、不要に負荷が増大するおそれがあった。
【００２１】
後者のように、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームで伝送する方法では、6DoFコンテンツを複数のオブジェクトストリームで構成し、視点位置からの距離に応じて適切に表示するための情報を示すScene Descriptionという記述法が用いられる。
【００２２】
このScene Descriptionの規格は、複数存在する。基本的には、シーンをシーングラフと称するツリー階層構造のグラフで表現し、そのシーングラフをバイナリ形式またはテキスト形式で表現する。ここで、シーングラフは、視点位置に基づく空間表示制御情報であり、その視点位置における3Dオブジェクトの表示に関する情報を、ノードを構成単位として定義し、複数のノードを階層的に組合せることで構成される。ノードは、3Dオブジェクトの位置情報や大きさ情報のノード、メッシュデータやテクスチャデータへのアクセス情報のノード、視点位置からの距離に応じて適切に表示するための情報などのためのノードがあり、3Dオブジェクト毎にこれらのノードを用いる。
【００２３】
なお、以下においては、6DoFコンテンツは、そのメタデータであるScene Descriptionデータ（Scene Descriptionのストリームデータ）と、複数の3Dオブジェクトのメディアデータ（3Dオブジェクトのメッシュデータとテクスチャデータを合わせて表現したもの）とで構成されるものとする。3DオブジェクトのメディアデータはPoint Cloudといった別の形式も適用可能である。また、Scene Descriptionデータは、MPEG-4 Scene Description（ISO/IEC 14496-11）に準拠するものとする。
【００２４】
MPEG-4 Scene Descriptionデータは、シーングラフをBIFS（BInary Format for Scenes）という形式でバイナリ化してものである。このシーングラフをBIFSへ変換するのは決められたアルゴリズムで可能である。また、ISO base media file formatに格納することで時刻ごとにシーンを規定することができ、動いている物体などの表現が可能である。
【００２５】
6DoFコンテンツを表現した場合、シーングラフは例えば、図１のようになる。図１のシーングラフ１０により表現される6DoFコンテンツには、複数の3Dオブジェクトが含まれている。図１においては、3Dオブジェクト１の構成のみが詳細に示されており（3Dオブジェクト１のTransformノード１２−１の子ノード以下が示されており）、3Dオブジェクト２乃至3Dオブジェクトｎの詳細な構成（3Dオブジェクト２のTransformノード１２−２乃至3DオブジェクトｎのTransformノード１２−ｎの子ノード以下）は、省略されている。
【００２６】
ルートのGroupノード１１は、子ノードとしてTransformノード１２を有する。Transformノード１２には、3Dオブジェクトの位置や大きさ等の情報がまとめられている。つまり、各Transformノード１２により、3D空間内の各3Dオブジェクトの情報がまとめられている。Transformノード１２は、子ノードとしてShapeノード１３を有する。Shapeノード１３には、その3Dオブジェクトの形状に関する情報がまとめられている。Shapeノード１３は、子ノードとして、Appearanceノード１４およびBitwrapperノード１５を有する。Appearanceノード１４には、テクスチャデータの情報がまとめられている。Bitwrapperノード１５には、メッシュデータの情報がまとめられている。Bitwrapperノード１５は、別ファイルになっているメッシュデータへのアクセス情報を有する。Appearanceノード１４は、子ノードとして、MovieTextureノード１６を有する。MovieTextureノード１６は、別ファイルになっているテクスチャデータへのアクセス情報を有する。
【００２７】
図２にこれらの各ノードが有する情報の例を示す。これらのノードには、情報（の種類）毎にフィールド（field）が設定され、各フィールドにそのフィールドに対応する情報が格納される。このノードのシンタックスの例を図３に示す。
【００２８】
Scene Descriptionの機能に、１つの3Dオブジェクトに対して複数のLevel of detailのデータをもち、表示の状態に合わせて切り替えることのできる機能がある。Level of detailとは、例えば、メッシュデータの頂点数およびテクスチャデータの解像度の内、少なくともいずれか一方が異なるデータである。例えば、メッシュデータの頂点数が多い程、または、テクスチャデータが高解像度である程、より高Level of detailである。
【００２９】
この機能は、3D空間の表現として、視点位置から離れている3Dオブジェクトは、2D DisplayやHMDで表示するとき、表示が小さくなり、近い場合は表示が大きくなるという6DoFコンテンツの表現特性を利用している。例えば、視点位置から近い場合は、大きく表示されることから、高Level of detailのデータ（頂点数が多いメッシュデータと、解像度の高いテクスチャデータ）を用いる必要がある。これに対して、視点位置から遠い場合は、小さく表示されることから、低Level of detailのデータ（頂点数が少ないメッシュデータと、解像度の低いテクスチャデータ）を用いれば十分である。
【００３０】
この機能は、Scene DescriptionのLODノードにより実現される。LODノードが有する情報の例を図４に示す。図４に示されるように、LODノード３１には、3DオブジェクトのLevel of detailを切り替えるための情報が含まれており、例えば、「距離を求めるための3Dオブジェクトの中心点」(図４のcenter field)、「視点位置と3Dオブジェクトの距離」(図４のrange field)、および「距離ごとで利用するべき3Dオブジェクトのデータ」(図４のlevel field)が含まれている。
【００３１】
LODノードの機能を用いることにより、視点位置に応じて3Dオブジェクトの適切なLevel of detailを選択することができ、表示品質を適切に保ちつつ、処理量を減らすことが可能になる。以下において、視点位置に応じたアダプテーションとも称する。
【００３２】
例えば、LODノード３１はTransformノード１２とShapeノード１３との間に配置される。LODノード３１の「距離ごとで利用するべき3Dオブジェクトのデータ」（図４のlevel field）は、選択すべきShapeノード１３にアドレスするものとなる。
【００３３】
LODノードを用いたシーングラフ１０の例を図５に示す。図５に示されるように、このシーングラフ１０においては、各Transformノード１２の子ノードとして、LODノード３１が設けられている。LODノード３１は、視点位置と3Dオブジェクトとの距離を用いてLevel of detailを切り替える。LODノード３１には、3Dオブジェクトとの距離を求めるために利用する中心位置の座標が記述され、距離ごとに利用する3Dオブジェクトのデータを示す、子ノードのShapeノード１３を持つ（Shapeノード１３−１乃至Shapeノード１３−３）。それぞれのShapeノード１３では、割り当てられたレベルの異なるメッシュデータとテクスチャデータへのアクセス情報を有するノードの情報が設定される。
【００３４】
これによって、距離が近い場合は、高Level of detailのデータを、中間距離の場合は、中Level of detailのデータを、遠い場合は、低Level of detailのデータを用いることができ、視点に応じて適切なLevel of detailのデータを用いることが可能になる。
【００３５】
ここで、6DoFコンテンツの配信を考える。6DoFコンテンツは、Scene Descriptionデータと、そこから参照されるメディアデータ（メッシュデータとテクスチャデータ）とを、ネットワーク経由で取得することで再生することができる。これに対して、Scene Descriptionを用いた6DoFコンテンツの再生には、以下のような前提がある。
【００３６】
・主に6DoFコンテンツ配信サーバがローカルにあるような、十分な伝送帯域が確保できるネットワーク環境かストレージある。
・クライアントの処理能力が十分にある。つまり、取得した全てのメッシュ・テクスチャのデコードと、表示処理（レンダリング）が決められた時間内にできる。
【００３７】
クライアントの処理量に関しては、視点位置に応じたアダプテーションを用いることで処理量を減らすことをScene Descriptionでは実現している。しかしながら、伝送帯域に関しては、Scene Descriptionは、伝送帯域に応じてアダプティブに配信する機能を有していない。そのため、Scene Descriptionデータおよびメディアデータを伝送するだけの十分な伝送帯域が確保できる場合は再生が可能であるが、伝送帯域が限られてしまうと、クライアントはデータの取得ができず、再生ができなかったり、途切れたりするおそれがあった。
【００３８】
なお、6DoFコンテンツの場合、再生時の品質の低減を抑制するために、3Dオブジェクト間の品質の相関性を維持する必要がある。したがって、仮に2Dコンテンツのようにビットレートアダプティブな配信手法を行うとしても、ビットレートを適応的に操作した場合に視点位置に応じた3Dオブジェクト間の品質の相関性を維持するための手段がなく、クライアントの状況に応じた適切な配信ができないおそれがあった。
【００３９】
＜２−２：コンセプト＞
そこで、Scene Descriptionを拡張し、ビットレートアダプテーションを可能にするシグナリングを行うようにする（第１の実施の形態（実施の形態１とも称する））。このようにすることにより、Scene Descriptionを用いた6DoFコンテンツ配信における伝送帯域制限による再生への影響を抑制し、コンテンツ再生のロバスト性を向上させることができる。
【００４０】
また、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングを追加するようにしてもよい（第２の実施の形態（実施の形態２とも称する））。このようにすることにより、クライアントがどのビットレートを選択すれば良いかが明らかになり、視点位置に最適な3Dオブジェクト間の相対的な品質を維持することができる。
【００４１】
さらに、各テクスチャやメッシュの、どのビットレートを同時に取得すると品質を維持できるかを示すメタ情報を追加するようにしてもよい（第３の実施の形態（実施の形態３とも称する））。このようにすることにより、ビットレートを一律に下げるビットレートアダプテーションでは3Dオブジェクト間の相対的な品質を維持することが困難な場合であっても、3Dオブジェクト間の相対的な品質を維持することができる。
【００４２】
また、それぞれの3DオブジェクトのLevel of detailを下げることで伝送帯域を削減するためのシグナリングを追加するようにしてもよい（第４の実施の形態（実施の形態４とも称する））。このようにすることにより、例えば、全て最低のビットレートのメッシュやテクスチャを選択しても、その合計ビットレートよりも伝送帯域の方が狭い場合であっても、再生が途切れるのを抑制することができる。
【００４３】
さらに、3Dオブジェクトの重要度情報のシグナリングを追加するようにしてもよい（第５の実施の形態（実施の形態５とも称する））。このようにすることにより、コンテンツオーサ等の意図において重要な3DオブジェクトのLevel of detailを維持することができる。
【００４４】
また、注目している3Dオブジェクトを識別して、その3DオブジェクトのLevel of detailを保つようにしてもよい（第６の実施の形態（実施の形態６とも称する））。このようにすることにより、ユーザの注目している3DオブジェクトのLevel of detailを維持することができる。
【００４５】
以下に、各実施の形態について説明する。なお、以下においては、Scene Descriptionとして、MPEG-4 Scene descriptionを適用して説明する。しかしながら、Scene Descriptionの規格は任意であり、例えば、VRML（Virtual Reality Modeling Language）、Open Scene Graph（http://www.openscenegraph.org/）、Universal Scene Description（https://graphics.pixar.com/usd/docs/index.html）、X3D（ISO/IEC 19775-1）、glTF（https://www.khronos.org/gltf/）等であってもよい。
【００４６】
＜３．第１の実施の形態（実施の形態１）＞
第１の実施の形態においては、各3DオブジェクトのLevel of detail毎にビットレートアダプテーションすることができるようにシグナリングを拡張する。例えば、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータを生成するようにする。例えば、情報処理装置において、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータを生成する生成部を備えるようにする。
【００４７】
このようにすることにより、Scene Descriptionを用いた6DoFコンテンツ配信における伝送帯域制限による再生への影響を抑制し、コンテンツ再生のロバスト性を向上させることができる。
【００４８】
＜３−１：実施の形態１−１＞
コンテンツの配信の際にビットレートを選択可能にする情報として、そのコンテンツの再生を制御する制御ファイルのアクセス情報を含むメタデータを生成するようにしてもよい。つまり、例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレートアダプテーション実現するようにしてもよい。現在の2Dコンテンツや3DoFコンテンツにおいては、DASH（Dynamic Adaptive Streaming over HTTP、ISO/IEC 23009-1）を用いて、ビットレートの異なるデータに切り替えることで、伝送帯域が狭くなった際にも途切れることなく再生が可能である仕組みがある。この方法は、DASHのマニフェストファイルであるMPDファイルのAdaptationSetでビットレートの異なるデータをRepresentationでシグナリングしている。
【００４９】
そこで、このようなMPDで実現しているビットレートアダプテーションの仕組みを利用し、Scene Descriptionと組み合わせることで、再生の途切れ等の発生を抑制するようにする。例えば、Scene Descriptionの外部メディアデータのアクセス情報で、MPDファイルのAdaptationSetを参照することができるようにしてもよい（実施の形態１−１−１）。この場合、クライアント装置１０３は、外部メディアデータとして示されたMPDのAdaptationSetの中から、ビットレートを選択する。
【００５０】
Scene DescriptionにおいてLODノードが存在する場合、視点位置に応じて各3Dオブジェクトに対して適切なLevel of detailが決まる。そこで、本実施の形態１−１では、Level of detail毎にビットレートバリエーションを持つことにより、Level of detail毎にビットレートアダプテーションを可能にする。
【００５１】
＜配信システム＞
図６は、本技術を適用したシステムの一態様である配信システムの主な構成の一例を示すブロック図である。図６に示される配信システム１００は、6DoFコンテンツをサーバからクライアントに配信するシステムである。
【００５２】
図６に示されるように、この配信システム１００は、ファイル生成装置（File generation apparatus）１０１、配信サーバ（Web server）１０２、およびクライアント装置（Client apparatus）１０３を有する。配信サーバ１０２とクライアント装置１０３とは、インターネット１１０を介して接続される。なお、図６においては、各装置を１台ずつ示しているが、配信システム１００は、各装置を任意の台数有することができる。つまり、ファイル生成装置１０１、配信サーバ１０２、およびクライアント装置１０３は、それぞれ、複数台であってもよい。
【００５３】
ファイル生成装置１０１は、Scene Descriptionデータ（Scene Description data）１２１、MPDファイル（MPD file）１２２、およびメディアデータ（media data）１２３を生成する（メディアデータ１２３−１、メディアデータ１２３−２、・・・）。ファイル生成装置１０１は、生成したそれらのデータを配信サーバ１０２にアップロードする。
【００５４】
クライアント装置１０３は、Scene Descriptionデータ１２１、MPDファイル１２２、メディアデータ１２３等を配信サーバ１０２に要求し、配信させる。クライアント装置１０３は、配信されたそれらのデータを取得すると、レンダリングを行って表示用の画像を生成し、その画像をモニタ（Display）に表示させる。
【００５５】
＜ファイル生成装置＞
図７は、ファイル生成装置１０１の主な構成例を示すブロック図である。図７に示されるように、ファイル生成装置１０１は、制御部１５１およびファイル生成部１５２を有する。
【００５６】
制御部１５１は、ファイル生成部１５２の制御に関する処理を行う。ファイル生成部１５２は、制御部１５１に制御されて、Scene Descriptionデータ１２１（Scene Descriptionとも称する）、MPDファイル１２２（MPDとも称する）、およびメディアデータ１２３等のデータの生成に関する処理を行う。ファイル生成部１５２は、データ入力部１６１、Scene Description生成部１６２、メディアデータ生成部１６３、MPDファイル生成部１６４、セグメントファイル生成部１６５、記録部１６６、およびアップロード部１６７を有する。
【００５７】
データ入力部１６１は、データの入力を受け付ける。データ入力部１６１は、受け付けたデータを、Scene Description生成部１６２、メディアデータ生成部１６３、およびMPDファイル生成部１６４に供給する。
【００５８】
Scene Description生成部１６２は、Scene Descriptionデータ１２１の生成に関する処理を行う。例えば、Scene Description生成部１６２は、データ入力部１６１から供給されるデータに基づいて、Scene Descriptionデータ１２１を生成し、それをセグメントファイル生成部１６５に供給する。
【００５９】
メディアデータ生成部１６３は、メディアデータ１２３の生成に関する処理を行う。例えば、メディアデータ生成部１６３は、データ入力部１６１から供給されるデータに基づいて、メディアデータ１２３を生成し、それをセグメントファイル生成部１６５に供給する。
【００６０】
MPDファイル生成部１６４は、MPDファイル１２２の生成に関する処理を行う。例えば、MPDファイル生成部１６４は、データ入力部１６１から供給されるデータに基づいて、MPDファイル１２２を生成し、それを記録部１６６に供給する。
【００６１】
セグメントファイル生成部１６５は、セグメントファイルの生成に関する処理を行う。例えば、セグメントファイル生成部１６５は、Scene Description生成部１６２から供給されたScene Descriptionデータ１２１を取得し、そのScene Descriptionデータ１２１をセグメント毎にファイル化し、Scene Descriptionデータ１２１のセグメントファイル（Scene Descriptionセグメントファイルとも称する）を生成する。また、セグメントファイル生成部１６５は、メディアデータ生成部１６３から供給されたメディアデータ１２３を取得し、そのメディアデータ１２３をセグメント毎にファイル化し、メディアデータ１２３のセグメントファイル（メディアデータセグメントファイルとも称する）を生成する。セグメントファイル生成部１６５は、生成したScene Descriptionセグメントファイルやメディアデータセグメントファイルを記録部１６６に供給する。
【００６２】
記録部１６６は、MPDファイル生成部１６４から供給されるMPDファイル１２２、並びに、セグメントファイル生成部１６５から供給されるScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを、自身が有する記録媒体に記録する。また、記録部１６６は、所定のタイミングにおいてまたはユーザ等の要求に基づいて、記録媒体に記録しているそれらのファイルを読み出し、それをアップロード部１６７に供給する。
【００６３】
アップロード部１６７は、記録部１６６からMPDファイル１２２、Scene Descriptionセグメントファイル、およびメディアデータセグメントファイルを取得し、それらを配信サーバ１０２にアップロードする（送信する）。
【００６４】
＜クライアント装置＞
図８は、クライアント装置１０３の主な構成例を示すブロック図である。図８に示されるように、クライアント装置１０３は、制御部１７１および再生処理部１７２を有する。制御部１７１は、再生処理部１７２の制御に関する処理を行う。再生処理部１７２は、制御部１７１に制御されて、6DoFコンテンツの再生に関する処理を行う。再生処理部１７２は、MPDファイル取得部１８１、MPDファイル処理部１８２、Scene Descriptionセグメントファイル取得部１８３、Scene Descriptionセグメントファイル処理部１８４、表示制御部１８５、計測部１８６、メディアデータセグメントファイル選択部１８７、メディアデータセグメントファイル取得部１８８、復号処理部１８９、表示情報生成部１９０、および表示部１９１を有する。
【００６５】
MPDファイル取得部１８１は、MPDファイル１２２の取得に関する処理を行う。例えば、MPDファイル取得部１８１は、配信サーバ１０２にアクセスしてMPDファイル１２２を要求し、取得する。MPDファイル取得部１８１は、取得したMPDファイル１２２をMPDファイル処理部１８２に供給する。
【００６６】
MPDファイル処理部１８２は、MPDファイルに関する処理を行う。例えば、MPDファイル処理部１８２は、MPDファイル取得部１８１から供給されるMPDファイル１２２を取得し、そのMPDファイルをパースし、MPDファイル１２２やそのパース結果をScene Descriptionセグメントファイル取得部１８３に供給する。
【００６７】
Scene Descriptionセグメントファイル取得部１８３は、Scene Descriptionセグメントファイルの取得に関する処理を行う。例えば、Scene Descriptionセグメントファイル取得部１８３は、MPDファイル処理部１８２から供給される情報（MPDファイル１２２やそのパース結果）を取得し、その情報に基づいて配信サーバ１０２にアクセスし、Scene Descriptionセグメントファイルを取得する。Scene Descriptionセグメントファイル取得部１８３は、取得したScene Descriptionセグメントファイルを、Scene Descriptionセグメントファイル処理部１８４に供給する。
【００６８】
Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルに関する処理を行う。例えば、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイル取得部１８３から供給されるScene Descriptionセグメントファイルを取得する。また、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。Scene Descriptionセグメントファイル処理部１８４は、取得したそれらの情報に基づいて、MPDファイルのアクセス先を決定する。Scene Descriptionセグメントファイル処理部１８４は、その決定したアクセス先をメディアデータセグメントファイル選択部１８７に供給する。
【００６９】
表示制御部１８５は、6DoFコンテンツの表示制御に関する処理を行う。例えば、表示制御部１８５は、視点位置を示す情報をScene Descriptionセグメントファイル処理部１８４、メディアデータセグメントファイル選択部１８７、表示情報生成部１９０等に供給する。計測部１８６は、配信サーバ１０２からクライアント装置１０３までの伝送路の伝送帯域を計測し、その計測結果をメディアデータセグメントファイル選択部１８７に供給する。
【００７０】
メディアデータセグメントファイル選択部１８７は、メディアデータセグメントファイルの選択に関する処理を行う。例えば、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、表示制御部１８５から供給される視点位置を示す情報や、計測部１８６から供給される伝送帯域を示す情報等に基づいて、再生するメディアデータセグメントファイルを選択する。メディアデータセグメントファイル選択部１８７は、その選択結果を示す情報をメディアデータセグメントファイル取得部１８８に供給する。
【００７１】
メディアデータセグメントファイル取得部１８８は、メディアデータセグメントファイルの取得に関する処理を行う。例えば、メディアデータセグメントファイル取得部１８８は、メディアデータセグメントファイル選択部１８７から供給されるメディアデータセグメントファイルの選択結果を示す情報を取得する。それらの情報に基づいて、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、メディアデータセグメントファイル選択部１８７により選択されたメディアデータセグメントファイルを要求し、取得する。メディアデータセグメントファイル取得部１８８は、取得したメディアデータセグメントファイルを復号処理部１８９に供給する。
【００７２】
復号処理部１８９は、メディアデータセグメントファイル取得部１８８から供給されるメディアデータセグメントファイルを取得し、復号する。復号処理部１８９は、その復号したメディアデータセグメントファイルを表示情報生成部１９０に供給する。表示情報生成部１９０は、復号処理部１８９から供給されるメディアデータセグメントファイルに基づいてレンダリングを行い、表示用の画像を生成する。表示情報生成部１９０は、生成した表示用の画像を表示部１９１に供給し、表示させる。
【００７３】
＜ファイル生成処理の流れ＞
次に、ファイル生成装置１０１が実行するファイル生成処理の流れの例を、図９のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ１０１において、MPDファイル１２２を生成する。
【００７４】
ステップＳ１０２において、Scene Description生成部１６２は、ステップＳ１０１において生成されたMPDファイルへのリンクを含むScene Descriptionデータ１２１を生成する。
【００７５】
ステップＳ１０３において、メディアデータ生成部１６３は、メディアデータ１２３を生成する。
【００７６】
ステップＳ１０４において、セグメントファイル生成部１６５は、ステップＳ１０２において生成されたScene Descriptionデータ１２１を用いて、Scene Descriptionセグメントファイルを生成する。また、セグメントファイル生成部１６５は、ステップＳ１０３において生成されたメディアデータ１２３を用いて、メディアデータセグメントファイルを生成する。
【００７７】
ステップＳ１０５において、記録部１６６は、ステップＳ１０１において生成されたMPDファイル１２２を記録する。また、ステップＳ１０６において、記録部１６６は、ステップＳ１０４において生成されたセグメントファイル（Scene Descriptionセグメントファイルおよびメディアデータセグメントファイル）を記録する。
【００７８】
ステップＳ１０７において、アップロード部１６７は、ステップＳ１０５において記録されたMPDファイル１２２を読み出し、配信サーバ１０２にアップロードする。
【００７９】
ステップＳ１０８において、アップロード部１６７は、ステップＳ１０６において記録されたセグメントファイル（Scene Descriptionセグメントファイルおよびメディアデータセグメントファイル）を読み出し、配信サーバ１０２にアップロードする。
【００８０】
ステップＳ１０８の処理が完了すると、ファイル生成処理が終了する。
【００８１】
＜再生処理の流れ＞
次に、クライアント装置１０３により実行される再生処理の流れの例を、図１０のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ１２１において、配信サーバ１０２にアクセスし、MPDファイル１２２を取得する。
【００８２】
ステップＳ１２２において、MPDファイル処理部１８２は、ステップＳ１２１において取得したMPDファイル１２２をパースし、Scene Descriptionデータ１２１を最初に取得することを認識し、そのScene Descriptionデータ１２１のAdaptationSetを参照し、Scene Descriptionデータ１２１のアクセス情報（URL（Uniform Resource Locator））を取得する。
【００８３】
ステップＳ１２３において、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ１２２において取得したURLから、現在時刻に対応するScene Descriptionセグメントファイルを取得する。
【００８４】
ステップＳ１２４において、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。
【００８５】
ステップＳ１２５において、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ１２３において取得したScene Descriptionデータ１２１をパースし、ステップＳ１２４において取得した情報により示される視点位置に基づいて、MPDファイル１２２内のアクセス先を決定する。
【００８６】
ステップＳ１２６において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。メディアデータセグメントファイル選択部１８７は、その計測結果（つまり伝送帯域を示す情報）を取得する。
【００８７】
ステップＳ１２７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、ステップＳ１２６において取得した伝送帯域を示す情報に基づいて、メディアデータセグメントファイルを選択する。
【００８８】
ステップＳ１２８において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ１２７において選択されたメディアデータセグメントファイルを取得する。
【００８９】
ステップＳ１２９において、復号処理部１８９は、ステップＳ１２８において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリングを行い、表示用画像を生成する。
【００９０】
ステップＳ１２９の処理が終了すると再生処理が終了する。このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
【００９１】
＜３−２：実施の形態１−１−１＞
＜Scene DescriptionとMPDの構成＞
MPDにおいて、Scene DescriptionデータのAdaptationSetと、そこから参照されるメディアデータのビットレートバリエーションのAdaptationSetをシグナリングするようにしてもよい。つまり、例えば、制御ファイルであるMPD（Media Presentation Description）の、３次元オブジェクトのLevel of Detailに対応し、そのLevel of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含むメタデータを生成するようにしてもよい。
【００９２】
図１１は、その場合のScene Descriptionデータ１２１の例を示す。図１２は、その場合のMPDファイル１２２の例を示す。図１１および図１２において、丸囲みの数字は、各図の矢印の対応関係を示す。MPDファイル１２２（図１２）には、Scene Descriptionデータ１２１を示すためのAdaptationSetや、各3DオブジェクトのLevel of detail毎のメッシュデータとテクスチャデータを示すAdaptationSetが記述されている。例えば3DオブジェクトAの高Level of Detail AHのメッシュデータの、ビットレートバリエーションが１つのAdaptationSetに記述されている。
【００９３】
＜MPDのシグナリング拡張＞
図１２に示されるように、本実施の形態のMPDファイル１２２には、Scene Descriptionデータ１２１のAdaptatioSetと各メディアデータ１２３のAdaptatonSetが示される。この構成の場合、クライアント装置１０３は、最初にMPDファイル１２２を取得し、そのMPDファイル１２２を解析する。その際、Scene Descriptionデータ１２１のAdaptationSetを最初に処理する必要がある。しかしながら、既存のシグナリングでは、どのAdapttionSetを最初に処理すべきかがわからない。
【００９４】
そこで、（１）最初に処理すべきAdaptationSetをシグナリングする、（２）最初に処理すべきでないAdaptationSetであることをシグナリングする、（３）（１）と（２）を同時にシグナリングする、の３つの実施方法を示す。
【００９５】
（１）最初に処理すべきAdaptationSetをシグナリングする。
最初に処理すべきAdaptationSetを示すシグナリングのためにSupplementalPropertyを利用する。以下の例のように、schemeIdUriで、InitialSelectionを設定する。value値は設定しない。
【００９６】
例 :< SupplementalProperty schemeIdUri="InitialSelection" />
【００９７】
（２）最初に処理すべきでないAdaptationSetであることをシグナリングする。
最初に処理すべきでない各メディアデータのAdapttionSetは、Scene Descriptionデータ１２１から参照されるデータである。他から参照されるデータであり、最初に処理すべきでないことを示す。例えば、以下の例のように、各メディアデータのAdaptationSetに、EssentialPropertyを設定し、そのEssentialPropertyのschemeIdUriはExternalReferencedDataを示し、value値でどのデータから参照されているかAdaptationSet@idを示す。
【００９８】
例 :< EssentialProperty schemeIdUri=" ExternalReferencedData " value="AdaptationSet@id"/>
【００９９】
EssentialPropertyで指定することにより、既存のクライアントは、このPropertyを知らなければ単体で再生はできない。また、このPropertyがわかるクライアントも、外部から参照されるデータであることがわかるため、単体で再生しなくなる。つまり、過去互換性を持つMPDファイルとなる。
【０１００】
（３）（１）と（２）を同時にシグナリングする。
（１）と（２）を同時にシグナリングすることで実現する。
【０１０１】
＜変形例＞
（１）および（２）は、以下の例のように、AdaptationSetのattributeでシグナリングするようにしてもよい。
【０１０２】
例 :< AdaptationSet  InitialSelection="TRUE" />
例 :< AdaptationSet  ExternalReferencedData ="TRUE"/>
【０１０３】
また、（２）はAdaptationSetではなく、ExternalReferencedAdaptationSetと名前を変えることで利用のされ方がいままでと違うことを示すようにしてもよい。
【０１０４】
さらに、最初に処理すべきAdaptationSetと、処理すべきでないAdaptationSetをPreselectionで同時にシグナリングするようにしてもよい。
【０１０５】
Preselectionは、EssentialPropertyもしくはSupplementalProperty でschemeIdURI="urn:mpeg:dash:preselection:2016"とvalue="tag, media component list"をシグナルする。media component listはspace区切りでmedia componentを複数シグナルすることができ、１つ目がmain media componentとなる。main media componentは例えばAdaptationSet@idでシグナルする。Preselectionは1decodeで処理することが前提であるが、ここでは拡張し、同時にレンダリング処理されるものを扱えるものと拡張する。
【０１０６】
この場合、main media componentとして、Scene DescriptionのAdaptationSet@idを示し、media component listの２つ目以降にScene Descriptionから参照されるメディアデータAdaptatioSet@idを並べる。つまり、main media componentが最初に処理すべきAdaptationSetであり、２つ目以降は最初に処理すべきでないAdaptationSetとなる。この手法においては、EssentialPropertyでシグナリングする。この手法は、既存のpreselectionのschmeIdUriを使っているが、別のschmeIdUriで実現してもよい。
【０１０７】
また、最初に処理すべきAdaptationSetと、処理すべきでないAdaptationSetをRoleでシグナリングするようにしてもよい。例えば、AdaptationSetでRole elementをシグナリングし、Role elementのvalueを設定する。RoleのSchemeIdUriで"urn:mpeg:dash:role:2018"をシグナリングする。最初に処理すべきAdaptationSetは、以下の例のように、value="initial"を指定する。
【０１０８】
例：<Role schemeIdUri="urn:mpeg:dash:role:2018" value=" initial"/>
【０１０９】
最初に処理すべきでないAdaptationSetは、以下の例のように、value=" ExternalReferencedData"をシグナリングする。
【０１１０】
例：<Role schemeIdUri="urn:mpeg:dash:role:2018" value=" ExternalReferencedData"/>
【０１１１】
＜Scene Descriptionのシグナリング拡張＞
図１１に示されるように、Scene Description１２１のメッシュ、テクスチャを示すノードであるBitwrapperノード１５、MovieTextureノード１６からMPDファイル１２２のAdaptationSetへアクセスすることができるように拡張する。
【０１１２】
Bitwrapperノード１５、MovieTextureノード１６ではURLを用いて外部メディアデータへのアクセス情報をシグナルしている。MPEG-4 Scene Description(ISO/IEC 14496-11)のBitwrapperノード１５およびMovieTextureノード１６の構造例は、図２に示した通りである。外部メディアデータへのアクセスに使われるフィールド（field）はどちらのノードもurl fieldである。本実施の形態では、Bitwrapperノード１５およびMovieTextureノード１６のsyntaxは拡張せず、それぞれのurl fieldの表記方法を拡張する。
【０１１３】
本実施の形態では、url fieldで示すURLをMPDファイル１２２へのURLに加えてURLパラメータでAdaptationSet@idをシグナリングし、Level of Detail違いのメディアデータを示す。具体的には、例えばAdaptationSetを表すURLパラメータの変数"AS"を用い、その値でAdaptationSet@idをシグナリングする。例えば、AdaptationSet@id=1のAdaptationSetを示す場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
【０１１４】
URLの例：http://www.6dofserver.com/6dof.mpd?AS=1
【０１１５】
既存の手法ではurlでは１つのメディアデータを示すために利用していたが、本手法により、複数のメディアデータの集合を示すことができるようにする。これにより、クライアントは示された複数のメディアデータの集合から、ビットレートを選択することができる。
【０１１６】
図１１の例でのScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図１３に示し、図１２の例のMPDファイル１２２の記述の例を図１４に示す。この場合、MPDファイル１２２のシグナリング拡張は、上述の（２）を用いている。このような記述により、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLから、MPDファイル１２２のAdaptationSetへのリンクを示すことができる。
【０１１７】
＜変形例＞
なお、URLパラメータで指定するのではなく、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６に、AdaptationSet@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイル１２２へのアクセス情報を記述する。
【０１１８】
また、以上においてはBitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。また、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDファイル１２２のURLを記述するようにしてもよい。この場合、URLパラメータ付きURLを格納してもよいし、図１５に示されるように、MPDファイル１２２へのURLだけを示し、AdaptatonSet@idは別のfieldとしてもよい。
【０１１９】
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図１６のフローチャートを参照して説明する。
【０１２０】
ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ１４１において、Scene DescriptionのAdaptationSetと、ビットバリエーション毎のRepresentationを有するLevel of Detail毎のAdaptationSetとを含むMPDファイル（図１２や図１４の例のようなMPDファイル）を生成する。
【０１２１】
ステップＳ１４２において、Scene Description生成部１６２は、Level of Detailのビットバリエーション毎のMPDのAdaptationSetへのリンクを含むScene Descriptionデータ（図１１や図１３の例のようなMPDファイル）を生成する。
【０１２２】
ステップＳ１４３乃至ステップＳ１４８の各処理は、ステップＳ１０３乃至ステップＳ１０８（図９）の各処理と同様に実行される。ステップＳ１４８の処理が終了すると、ファイル生成処理が終了する。
【０１２３】
以上のようにファイル生成処理を実行することにより、ファイル生成装置１０１は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
【０１２４】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図１７のフローチャートを参照して説明する。再生処理が開始されると、ステップＳ１６１乃至ステップＳ１６４の各処理が、ステップＳ１２１乃至ステップＳ１２４（図１０）の各処理と同様に実行される。
【０１２５】
ステップＳ１６５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Description処理を実行し、MPDのアクセス先（AdaptationSet）を決定する。
【０１２６】
ステップＳ１６６において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。メディアデータセグメントファイル選択部１８７は、その計測結果（つまり伝送帯域を示す情報）を取得する。
【０１２７】
ステップＳ１６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、取得する全セグメントファイルのビットレートの合計がステップＳ１６６において取得した伝送帯域より小さくなるように、Representationを選択する。
【０１２８】
ステップＳ１６８において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ１６７において選択されたRepresentationにより指定されるメディアデータセグメントファイル（全ての3Dオブジェクトのメッシュファイルおよびテクスチャファイル）を取得する。
【０１２９】
ステップＳ１６９において、復号処理部１８９は、ステップＳ１６８において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリング処理を行い、表示用画像を生成する。ステップＳ１６９の処理が終了すると、再生処理が終了する。
【０１３０】
＜Secene Description処理の流れ＞
次に、図１７のステップＳ１６５において実行されるScene Description処理の流れの例を、図１８のフローチャートを参照して説明する。
【０１３１】
Scene Description処理が開始されると、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ１８１において、Scene Descriptionデータ１２１について、RootのGroupノード１１を取得し、全ての子ノード（Transformノード１２）を取得する。
【０１３２】
ステップＳ１８２において、Scene Descriptionセグメントファイル処理部１８４は、RootのGroupノード１１について、未処理の子ノード（Transformノード１２）が存在するか否かを判定する。存在すると判定された場合、処理はステップＳ１８３に進む。
【０１３３】
ステップＳ１８３において、Scene Descriptionセグメントファイル処理部１８４は、未処理のTransformノード１２を処理対象として選択し、その処理対象のTransformノード１２を処理する。この処理により、レンダリングする位置や大きさが決まる。
【０１３４】
ステップＳ１８４において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionデータ１２１について、Transformノード１２の子ノードのLODノード３１を取得する。
【０１３５】
ステップＳ１８５において、Scene Descriptionセグメントファイル処理部１８４は、そのLODノード３１の中心座標パラメータと視点位置の距離を求める。
【０１３６】
ステップＳ１８６において、Scene Descriptionセグメントファイル処理部１８４は、そのLODノード３１の距離パラメータと求めた距離とを比較し、処理する子ノードを決定する。
【０１３７】
ステップＳ１８７において、Scene Descriptionセグメントファイル処理部１８４は、決定した子ノードを取得して、メッシュファイルおよびテクスチャファイルのアクセス情報（例えばURL）からMPDのAdaptationSetを取得する。
【０１３８】
ステップＳ１８７の処理が終了すると、処理はステップＳ１８２に戻り、それ以降の処理が繰り返される。つまり、ステップＳ１８２乃至ステップＳ１８７の各処理が、各Transformノード１２について実行される。
【０１３９】
ステップＳ１８２において、未処理のTransformノードが存在しないと判定された場合、処理は、ステップＳ１８８に進む。ステップＳ１８８において、Scene Descriptionセグメントファイル処理部１８４は、利用する全てのAdaptationSetを決定する。ステップＳ１８８の処理が終了すると、Scene Description処理が終了し、処理は図１７に戻る。
【０１４０】
＜レンダリング処理の流れ＞
次に、図１７のステップＳ１６９において実行されるレンダリング処理の流れの例を、図１９のフローチャートを参照して説明する。
【０１４１】
レンダリング処理が開始されると、表示情報生成部１９０は、ステップＳ２０１において、Scene Descriptionデータ１２１の情報を利用して取得した各3Dオブジェクトのメッシュファイルおよびテクスチャファイルのデータを用いて、シーンを構成する。
【０１４２】
ステップＳ２０２において、表示情報生成部１９０は、そのシーンの各3Dオブジェクトを、視点位置、視線方向、および画角に基づいてレンダリングし、表示用画像を生成する。ステップＳ２０２が終了すると、レンダリング処理が終了し、処理は図１７に戻る。
【０１４３】
以上のように、各処理を実行することにより、クライアント装置１０３は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
【０１４４】
＜３−３：実施の形態１−１−２＞
＜Scene DescriptionとMPDの構成＞
MPDのAdaptationSetの構成は任意であり、実施の形態１−１−１の例に限定されない。例えば、同じ3DオブジェクトのメッシュデータはMPDの１つのAdaptationSetでシグナリングするようにしてもよい。同様に、同じ3DオブジェクトのテクスチャデータはMPDの１つのAdaptationSetでシグナリングするようにしてもよい。つまり、１つの3Dオブジェクトの全てのLevel of Detailのビットレートバリエーションがメッシュとテクスチャそれぞれ１つのAdaptationSetに含まれるようにしてもよい。なお、この場合もMPDシグナリング拡張は、上述の実施の形態１−１−１の場合と同様である。換言するに、制御ファイルであるMPDの、３次元オブジェクトに対応するAdaptationSetの、その３次元オブジェクトのLevel of Detailに対応し、そのLevel of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含むメタデータを生成するようにしてもよい。
【０１４５】
図２０は、この場合のScene Descriptionデータ１２１の例を示す。図２１は、この場合のMPDファイル１２２の例を示す。図２０および図２１において、丸囲みの数字は、各図の矢印の対応関係を示す。
【０１４６】
この場合、MPDファイル１２２（図２１）には、Scene Descriptionデータ１２１のAdaptationSet、各3Dオブジェクトのメッシュデータとテクスチャデータ毎のAdaptationSetとが記述されている。例えば、図２０および図２１に示されるように、3DオブジェクトAの高Level of Detail AH、中Level of Detail AM、低Level of Detail ALのメッシュデータのビットレートバリエーションが１つのAdaptationSetに記述される。
【０１４７】
＜３−４：実施の形態１−１−２−１＞
以上のようなMPDファイル１２２およびScene Descriptionデータ１２１の構成を、Scene Descriptionデータ１２１を拡張することで実現するようにしてもよい。例えば、所望のMPDのアクセス情報、そのMPD内の所望のAdaptationSetを指定する情報、およびそのAdaptationSet内の所望のRepresentationを指定する情報からなるアクセス情報を含むメタデータを生成するようにしてもよい。
【０１４８】
＜Scene Descriptionのシグナリング＞
図２０および図２１を参照して説明した構成において、Scene Descriptionデータ１２１のメッシュを示すノードであるBitwrapperノード１５や、テクスチャを示すノードであるMovieTextureノード１６の、Level of detailに含まれるビットレートバリエーションは、MPDファイル１２２のそれぞれのAdaptationSet内のいくつかのRepresentationになる。
【０１４９】
そこで、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６において、アクセス情報（例えばURL）により、ビットレートバリエーションである、MPDファイル１２２のRepresentationをシグナリングするようにしてもよい。
【０１５０】
より具体的には、Representationを表すURLパラメータの変数である"RS"とその値によりRepresentation@idが示されるようにする。Bitwrapperノード１５やMovieTextureノード１６においては、ビットレートバリエーションの数のRepresentation@idを記述することができる。例えば、Representation@id=1、Representation@id=2、Representation@id=3があるLevel of detailに含まれるメッシュのビットレートバリエーションを示す場合は、以下の例のようにURLパラメータのついたURLを、アクセス情報として、Bitwrapperノード１５やMovieTextureノード１６に記述する。
【０１５１】
URLの例：http://www.6dofserver.com/6dof.mpd?RS=1&RS=2&RS=3
【０１５２】
図２０のScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図２２に示す。また、図２１のMPDファイル１２２の記述例を、図２３に示す。図２２および図２３において、丸囲みの数字は、各図の矢印の対応関係を示す。
【０１５３】
これらの図に示されるように、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６において、変数RSの値として、AHm-n、AHt-m（n, mは、任意の自然数）を記述することにより、そのノードを、MPDファイル１２２の3Dオブジェクトに対応するAdaptationSetの、その値のRepresentationidを有するRepresentationに紐づけることができる。つまり、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLのフィールドにおいて、MPDファイル１２２のビットレートバリエーションの数のRepresentationへのリンクを示すことができる。
【０１５４】
＜変形例＞
なお、URLパラメータでAdaptationSetの@idも同時にシグナリングするようにしてもよい。シグナリングの仕方は、実施の形態１−１−１において上述したのと同様である。
【０１５５】
また、URLパラメータで指定するのではなく、例えば図２４に示されるように、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６において、Representation@idを示すフィールド（field）を拡張するようにしてもよい。この場合、url fieldには、MPDファイル１２２へのアクセス情報が記述される。
【０１５６】
さらに、AdaptationSet@idを示すfieldを追加する拡張をしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードにおいて、これらと同様にfieldを拡張するようにしてもよい。
【０１５７】
また、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDのURLを記述するようにしてもよい。この場合、URLパラメータ付きURLを格納してもよいし、MPDファイル１２２へのURLだけを示し、Representation@idは別のfieldとするようにしてもよい。
【０１５８】
＜３−５：実施の形態１−１−２−２＞
また、MPDファイル１２２も拡張するようにしてもよい。例えば、MPDファイル１２２において、互いに同一のLevel of DetailのRepresentationをグルーピングし、Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６に記述されるアクセス情報が、そのグループを示すようにしてもよい。つまり、互いに同一のビットレートバリエーションをグループ化する情報を含むMPDを生成するようにしてもよい。このようにすることにより、実施の形態１−１−２−１の場合と比較して、Scene Descriptionデータ１２１に記述されるメディアデータのURLのURLパラメータを、ビットレート数によらず、一定にすることができる。またScene Descriptionデータ１２１を作成した後に、ビットレートバリエーションを増大させる場合に、Scene Descriptionデータ１２１のシグナリングに影響が出ないようにすることができる。
【０１５９】
＜MPDのシグナリング＞
MPDファイル１２２のRepresentationをグルーピングし、Scene Descriptionデータ１２１のLevel of detailで利用するビットレートバリエーションがわかるシグナリングをする。
【０１６０】
そのために、以下の例のように、Level of detailで利用するビットレートバリエーションは、同じValue値を持つSupplementalPropertyをRepresentationにシグナリングするようにする。
【０１６１】
例 :<SupplementalProperty schemeIdUri="RepresentationGroup" value="1"/>
【０１６２】
このSupplementalPropertyにおいて、schemeIdUriでRepresentationGroupを示し、value値でグループ番号を示す。同じAdaptationSetに含まれ、同じValue値を持つRepresentaitonが、同一のグループに属していることを示す。
【０１６３】
＜変形例＞
なお、上述の例では、RepresentationGroupが何のGroupであるかがわからないので、value値をコンマ区切りにして、"group番号, グループ種類"として、グループの種類も同時にシグナリングするようにしてもよい。以下にその例を示す。この例において、"LOD"は、Level of detailのグループであることを示す。
【０１６４】
例 : <SupplementalProperty schemeIdUri="RepresentationGroup" value="1, LOD"/>
【０１６５】
＜Scene Descriptionのシグナリング＞
また、Scene Descriptionデータ１２１においては、Bitwrapperノード１５およびMovieTextureノード１６のアクセス情報（URL）により上述のRepresentationのグループを示すようにする。ただし、どのAdaptationSetに含まれるRepresentationのグループかわからないので、AdaptationSetも同時に示すようにする。
【０１６６】
MPDファイル１２２のURLパラメータに、AdaptationSetを示すパラメータと、RepresentationGroupを示すパラメータをシグナルする。AdaptationSetを示すパラメータは、実施の形態１−１−１において上述したものと同じである。RepresentationGroupを示すパラメータとしては、変数であるReplesentationGroupを与え、その値には、MPDファイル１２２のRepresentationGroupのvalueをシグナリングするようにする。以下にそのURLの例を示す。
【０１６７】
URLの例：http://www.6dofserver.com/6dof.mpd?AS=1&ReplesentationGroup=1
【０１６８】
図２０のScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図２５に示す。また、図２１のMPDファイル１２２の記述例を、図２６に示す。図２５および図２６において、丸囲みの数字は、各図の矢印の対応関係を示す。
【０１６９】
このように記述することにより、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLから、MPDファイル１２２のAdaptationSetおよびその中のLevel of DetailのビットレートバリエーションのRepresentationの集合を示す、RepresentationGroupへのアクセス情報を示すことができる。
【０１７０】
＜変形例＞
以上においては、シグナリングを各Representationに行うように説明したが、AdaptationSetにシグナリングしてもよい。その場合、例えば、schmeIdUriでReplesentationGroupを示すようにしてもよい。グルーピング情報は、グループ毎にSupplementalPropertyのエレメント（element）としてRepresentationGroupを新しく追加する。RepresentationGroupは、id（RepresentationGroupのvalueと同じ意味）と、グループに含まれるRepresentationのidのリストから成る。以下にその例を示す。
【０１７１】
<SupplementalProperty schemeIdUri=" ReplesentationGroup " >
<RepresentationGroup id=1 member="representaiton@id1 representation@id2..."/>
< RepresentationGroup id=2 member=" epresentaiton@id4 representation@id5..."/>
</SupplementalProperty>
【０１７２】
この場合のMPDファイル１２２の記述例を図２７に示す。図２７の例においては、MPDファイル１２２において上述の例のような記述がされ、RepresentationGroup id=1は、高Level of Detailのビットバリエーションのグループに紐づけられている。
【０１７３】
なお、Scene Descriptionデータ１２１のurlのURLパラメータで指定するのではなく、例えば、図２８に示されるように、Bitwrapperノード１５やMovieTextureノード１６において、AdaptationSet@idとRepresentationGroupを示すfieldを拡張するようにしてもよい。この場合、url fieldは、MPDファイル１２２へのアクセス情報が記述される。
【０１７４】
また、以上においては、Bitwrapperノード１５やMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。さらに、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDファイル１２２のURLを記述するようにしてもよい。
【０１７５】
＜３−６：実施の形態１−１−３＞
＜起点をScene Descriptionにする＞
実施の形態１−１−１および実施の形態１−１−２においては、最初にMPDファイル１２２を取得し、その後Scene Descriptionデータ１２１を取得し、視点に応じた適切な構成を選択し、さらにその後にMPDファイル１２２のAdaptationSetからビットレートを選択するように説明した。すなわち、最初にMPDファイル１２２を取得しているので、処理の起点がMPDファイル１２２になっている。
【０１７６】
この処理の起点をScene Descriptionデータ１２１にするようにしてもよい。その場合、それ以降の処理は、実施の形態１−１−１または実施の形態１−１−２において説明したのと同様である。つまり、最初に取得するファイルがScene Descriptionデータ１２１になり、視点に応じた適切な構成を選択した後に、MPDファイル１２２を取得し、指示されているAdaptationSetからビットレートを選択することになる。その場合、例えば、図１４のMPDファイル１２２の、下記の部分（すなわち、Scene Descriptionデータ１２１のAdaptationSet）が不要になる。つまり、メタデータへのアクセス情報を含まないMPDを生成するようにしてもよい。
【０１７７】
<AdaptationSet id="0" > // Scene Description
<Representation id="sd" bandwidth="500000"><BaseURL> SD.mp4 </BaseURL></Representation>
</AdaptationSet>
【０１７８】
また、各メディアデータのAdaptationSetにシグナリングされる、< EssentialProperty schemeIdUri=" ExternalReferencedData " value="AdaptationSet@id"/>のvalue値のシグナリングが不要になる。
【０１７９】
＜３−７：実施の形態１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
実施の形態１−１においては、Scene Descriptionデータ１２１およびMPDファイル１２２を用いてビットレートアダプテーションを実現する場合について説明したが、Scene Descriptionデータ１２１を拡張することでビットレートアダプテーションを実現するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。換言するに、メタデータは、コンテンツの、視点位置に基づく空間表示制御情報であり、そのコンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する視点位置に基づく空間表示制御情報を生成するようにしてもよい。
【０１８０】
＜Scene Descriptionの拡張＞
既存のScene Descriptionデータ１２１の場合、図５に示されるように、3DオブジェクトのLevel of detail毎にBitwrapperノード１５とMovieTextureノード１６がそれぞれ１つずつシグナルすることができるのみであり、各Level of detailにおいて、複数のBitwrapperノード１５とMovieTextureノード１６をシグナルすることができない。つまり、ビットバリエーションをもつことができない。
【０１８１】
そこで、メッシュデータおよびテクスチャデータ毎に複数のビットレートのデータから選択できるようにScene Descriptionデータ１２１を拡張する。
【０１８２】
＜配信システム＞
この場合の配信システム１００の構成は、図２９に示されるように、図６の例と同様である。ただし、ファイル生成装置１０１は、Scene Descriptionデータ１２１やメディアデータ１２３を生成するが、MPDファイル１２２は、生成しない。したがって、配信サーバ１０２もMPDファイル１２２をクライアント装置１０３に供給しない。クライアント装置１０３は、配信サーバ１０２よりScene Descriptionデータ１２１を取得し、そのScene Descriptionデータ１２１に基づいて、メディアデータを配信サーバ１０２から取得し、再生する。
【０１８３】
＜ファイル生成装置＞
この場合のファイル生成装置１０１の主な構成例を図３０に示す。図３０に示されるように、この場合のファイル生成装置１０１は、図７の場合と同様に、制御部１５１およびファイル生成部１５２を有する。
【０１８４】
ただし、ファイル生成部１５２は、データ入力部１６１、Scene Description生成部１６２、メディアデータ生成部１６３、セグメントファイル生成部１６５、記録部１６６、およびアップロード部１６７を有する。つまり、図７の場合と比べて、MPDファイル生成部１６４が省略される。
【０１８５】
記録部１６６は、セグメントファイル生成部１６５から供給されるScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを、自身が有する記録媒体に記録する。また、記録部１６６は、所定のタイミングにおいてまたはユーザ等の要求に基づいて、記録媒体に記録しているそれらのセグメントファイルを読み出し、それをアップロード部１６７に供給する。
【０１８６】
アップロード部１６７は、記録部１６６からScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを取得し、それらを配信サーバ１０２にアップロードする（送信する）。
【０１８７】
＜クライアント装置＞
この場合のクライアント装置１０３の主な構成例を図３１に示す。図３１に示されるように、この場合のクライアント装置１０３は、図８の場合と同様に、制御部１７１および再生処理部１７２を有する。
【０１８８】
ただし、再生処理部１７２は、Scene Descriptionセグメントファイル取得部１８３、Scene Descriptionセグメントファイル処理部１８４、表示制御部１８５、計測部１８６、メディアデータセグメントファイル取得部１８８、復号処理部１８９、表示情報生成部１９０、および表示部１９１を有する。つまり、図８の場合と比べて、MPDファイル取得部１８１、MPDファイル処理部１８２、およびメディアデータセグメントファイル選択部１８７が省略される。
【０１８９】
Scene Descriptionセグメントファイル取得部１８３は、配信サーバ１０２にアクセスし、6DoFコンテンツおよび視点位置に対応するScene Descriptionセグメントファイルを取得し、それをScene Descriptionセグメントファイル処理部１８４に供給する。つまり、Scene Descriptionセグメントファイル取得部１８３は、MPDファイル１２２無しにScene Descriptionセグメントファイルを取得する。
【０１９０】
Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイル、視点位置、伝送帯域等の情報に基づいて、再生するメディアデータセグメントファイルを選択する。Scene Descriptionセグメントファイル処理部１８４は、その決定したメディアデータセグメントファイルのアクセス先をメディアデータセグメントファイル取得部１８８に供給する。
【０１９１】
メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、Scene Descriptionセグメントファイル処理部１８４により選択されたメディアデータセグメントファイルを要求して取得し、復号処理部１８９に供給する。
【０１９２】
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図３２のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ２２１において、Level of Detailのビットバリエーション毎のメディアデータへのリンクを含むScene Descriptionを生成する。
【０１９３】
ステップＳ２２２乃至ステップＳ２２５の各処理は、ステップＳ１０３、ステップＳ１０４、ステップＳ１０６、およびステップＳ１０８の各処理と同様に実行される。ステップＳ１０８の処理が完了すると、ファイル生成処理が終了する。
【０１９４】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図３３のフローチャートを参照して説明する。再生処理が開始されると、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ２４１において、現在時刻の、Level of Detailのビットバリエーション毎のメディアデータへのリンクを含むScene Descriptionを取得する。
【０１９５】
ステップＳ２４２において、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。ステップＳ２４３において、Scene Descriptionセグメントファイル処理部１８４は、その情報により示される視点位置に基づいて、Level of Detailを選択する。
【０１９６】
ステップＳ２４４において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。Scene Descriptionセグメントファイル処理部１８４は、その計測結果（つまり伝送帯域を示す情報）を取得する。
【０１９７】
ステップＳ２４５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、ステップＳ２４４において取得した伝送帯域を示す情報に基づいて、ノードを選択する。
【０１９８】
ステップＳ２４６において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ２４５において選択されたノードのメッシュファイルまたはテクスチャファイルを取得する。
【０１９９】
ステップＳ２４７において、復号処理部１８９は、ステップＳ２４６において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリングを行い、表示用画像を生成する。
【０２００】
ステップＳ２４７の処理が終了すると再生処理が終了する。このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
【０２０１】
＜３−８：実施の形態１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。つまり、３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む視点位置に基づく空間表示制御情報を生成するようにしてもよい。
【０２０２】
＜Scene Descriptionのシグナリング＞
例えば、複数のノードからクライアントが選択をすることができることを示す、ClientSelectionノードを新たに定義するようにしてもよい。ClientSelectionノードは、複数のノードとそれぞれのノードで示されるデータのビットレートをシグナリングすることができるノードである。そのClientSelectionノードの例を図３４に示す。
【０２０３】
図３４に示されるように、ClientSelectionノード３０１は、複数の子ノードを示すSelectionNode fieldと、それぞれの子ノードのビットレートを示すbitrate fieldを有する。つまり、SelectionNode fieldには、子ノードのリストが記述され、bitrate fieldには、各子ノードのビットレートのリストが記述される。両フィールドのリストの順は対応しており、SelectionNode fieldのn番目の子ノードのビットレート情報は、bitrate fieldのn番目のビットレート情報で示される。
【０２０４】
このようなClientSelectionノード３０１を利用して複数のビットレートから選択をできるようにしたScene Descriptionデータ１２１のシーングラフの例を図３５に示す。図３５においては、3DオブジェクトAの高Level of Detailに関してのみビットレートバリエーションのグラフのみが示されている。その他のLevel of Detail、3Dオブジェクトも同様のため、省略している。
【０２０５】
図３５の3DオブジェクトAの高Level of Detailのメッシュデータでは、Shapeノード１３−１の子ノードをClientSelectionノード３０１−１としている。そのClientSelectionノード３０１−１は、17Mbps、15Mbps、13MbpsのビットレートバリエーションのBitwrapperノード１５（Bitwrapperノード１５−１−１、Bitwrapperノード１５−１−２、Bitwrapperノード１５−１−３）を子ノードとしている。テクスチャデータのビットレートバリエーションは、Appearanceノードの子ノードをClientSelectionノード３０１−２としている。そのClientSelectionノード３０１−２は、17Mbps、15Mbps、13MbpsのビットレートバリエーションのMovieTextureノード１６（MovieTextureノード１６−１−１、MovieTextureノード１６−１−２、MovieTextureノード１６−１−３）を子ノードとしている。
【０２０６】
以上のように、ClientSelectionノード３０１を用いることにより、メッシュデータやテクスチャデータの複数のビットレートバリエーションを、その子ノードとして表現することができる。したがって、その各子ノードにより、各ビットレートバリエーションのメディアデータへのアクセス情報を記述することができるので、このようなClientSelectionノード３０１を用いたScene Descriptionデータを用いることにより、配信における適応的なビットレートの制御（配信のビットレートアダプテーション）を実現することができる。つまり、伝送帯域幅が狭くなることによる再生の途切れの発生等を抑制することができ、コンテンツ再生のロバスト性を向上させることができる。
【０２０７】
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図３６のフローチャートを参照して説明する。
【０２０８】
ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ２６１において、上述のようなClientSelectionノード３０１を含むScene Descriptionデータ１２１を生成する。
【０２０９】
ステップＳ２６２乃至ステップＳ２６５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理と同様に実行される。ステップＳ２６５の処理が終了すると、ファイル生成処理が終了する。
【０２１０】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図３７のフローチャートを参照して説明する。再生処理が開始されると、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ２８１において、現在時刻の、ClientSelectionノード３０１を含むScene Descriptionデータ１２１を取得する。ステップＳ２８２の処理は、ステップＳ２４２の処理（図３３）と同様に実行される。
【０２１１】
ステップＳ２８３において、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ２８２において取得した情報に基づいてScene Description処理を実行し、メッシュデータやテクスチャデータのビットレートバリエーションを決定する。
【０２１２】
ステップＳ２８４の処理は、ステップＳ２４４の処理（図３３）と同様に実行される。
【０２１３】
ステップＳ２８５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、利用するLevel of Detailのメッシュファイルおよびテクスチャファイルのビットレートバリエーション（ClientSelectionノードの子ノード）を選択する。その際、Scene Descriptionセグメントファイル処理部１８４は、取得する全セグメントファイルのビットレートの合計がステップＳ２８４において取得した伝送帯域より小さくなるような子ノードを選択する。
【０２１４】
ステップＳ２８６の処理は、ステップＳ２４６の処理（図３３）と同様に実行される。
【０２１５】
ステップＳ２８７において、復号処理部１８９は、ステップＳ２８６において取得したメディアデータセグメントファイル（メッシュファイルやテクスチャファイル）を復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリング処理を行い、表示用画像を生成する。このレンダリング処理は、図１９のフローチャートを参照して説明した場合と同様に実行される。ステップＳ２８７の処理が終了すると、再生処理が終了する。
【０２１６】
このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
【０２１７】
＜Secene Description処理の流れ＞
次に、図３７のステップＳ２８３において実行されるScene Description処理の流れの例を、図３８のフローチャートを参照して説明する。
【０２１８】
Scene Description処理が開始されると、ステップＳ３０１乃至ステップＳ３０６の各処理が、ステップＳ１８１乃至ステップＳ１８６の各処理と同様に実行される。
【０２１９】
ステップＳ３０７において、Scene Descriptionセグメントファイル処理部１８４は、決定した子ノードを取得して、ClientSelectionノード３０１から、メッシュファイルおよびテクスチャファイルのノードのバリエーションをリストする。
【０２２０】
ステップＳ３０７の処理が終了すると、処理はステップＳ３０２に戻り、それ以降の処理が繰り返される。つまり、ステップＳ３０２乃至ステップＳ３０７の各処理が、各Transformノード１２について実行される。
【０２２１】
ステップＳ３０２において、未処理のTransformノードが存在しないと判定された場合、処理はステップＳ３０８に進む。
【０２２２】
ステップＳ３０８において、Scene Descriptionセグメントファイル処理部１８４は、利用する全てのLevel of Detailのメッシュファイルとテクスチャファイルのバリエーションを決定する。ステップＳ３０８の処理が終了すると、Scene Description処理が終了し、処理は図３７に戻る。
【０２２３】
以上のように、各処理を実行することにより、クライアント装置１０３は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
【０２２４】
＜３−９：実施の形態１−２−２＞
＜既存のノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。例えば、３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む視点位置に基づく空間表示制御情報を生成するようにしてもよい。
【０２２５】
＜Scene Descriptionのシグナリング＞
例えば、既存のBitwrapperノード１５およびMovieTextureノード１６で複数のアクセス情報をリストし、それぞれのアクセス情報のビットレートを指定できるように拡張してもよい。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図３９に示す。この場合、Bitwrapperノード１５は、url fieldをurllist fieldに拡張し、複数のメッシュデータファイルを指定できるようになされている。それぞれのurllistで示されるメッシュデータファイルのビットレートは、bitrate fieldで示されている。urllist fieldのn番目に示されるurlのメッシュデータファイルのビットレートは、bitrate fieldのn番目のビットレート情報で示される。
【０２２６】
同様にMovieTextureノード１６は、url fieldをurllist fieldに拡張し、複数のテクスチャデータファイルを指定できるようになされている。それぞれのurllistで示されるテクスチャデータファイルのビットレートがbitrate fieldで示されている。
【０２２７】
上述の拡張したノードのシーングラフは図５と同様である。ただし、この場合、Bitwrapperノード１５およびMovieTextureノード１６からビットレートの異なるメディアデータにアクセスすることができる。なお、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０２２８】
＜４．第２の実施の形態（実施の形態２）＞
＜ビットレートを一律に下げるためのシグナリング＞
さらに、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングを追加するようにしてもよい。換言するに、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
【０２２９】
帯域幅が十分でない場合、各メッシュとテクスチャのビットレートをより下げたセグメントファイルを取得する必要があるが、この時に、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示す情報をシグナリングすることにより、再生側（クライアント装置１０３）において、各3Dオブジェクトを、どのようにビットレートを下げるのが適切であるかを容易に把握することができる。したがって、その情報に基づいて、6DoFコンテンツの表示の際に維持すべき視点位置で決めた3Dオブジェクト間の品質の相対性を維持するように、全てのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、6DoFコンテンツの品質の低減を抑制することができる。
【０２３０】
＜メッシュおよびテクスチャのビットレートアダプテーションの構成方法＞
本実施の形態においては、次の２つの条件を満たすようにビットレートアダプテーションを構成するものとする。
【０２３１】
（１）各メッシュ、テクスチャのビットレートバリエーションの数は等しい。
（２）ビットレートバリエーション間の品質の違いは、他の3Dオブジェクトと相対的に同じである。
【０２３２】
例えば、メッシュの場合は、エンコードパラメータ（量子化ビット数）でビットレートバリエーションを作成する（例えば３つビットレートバリエーションを作成する場合、どのメッシュのビットレートバリエーションも量子化ビット数を10,8,6の３パターンで作成する）ものとする。テクスチャの場合も同様にエンコードパラメータ（量子化パラメータ）でビットレートバリエーションを作成するものとする。
【０２３３】
＜４−１：実施の形態２−１＞
＜ビットレート順に相対的な品質が維持されていることを示すシグナリングの追加＞
テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングとして、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
【０２３４】
＜４ー２：実施の形態２−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
【０２３５】
つまり、実施の形態１−１と同様のシステムにおいて、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図６の例と同様であり、ファイル生成装置１０１の構成は図７の例と同様であり、クライアント装置１０３の構成は図８の例と同様である。
【０２３６】
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図４０のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ３２１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を生成する。
【０２３７】
ステップＳ３２２乃至ステップＳ３２８の各処理は、ステップＳ１０２乃至ステップＳ１０８の各処理（図９）と同様に実行される。ステップＳ３２８の処理が終了すると、ファイル生成処理が終了する。
【０２３８】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図４１のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ３４１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を取得する。
【０２３９】
ステップＳ３４２乃至ステップＳ３４６の各処理は、ステップＳ１２２乃至ステップＳ１２６の各処理（図１０）と同様に実行される。
【０２４０】
ステップＳ３４７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、伝送帯域と、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されることを示す情報とに基づいて、メディアデータセグメントファイルを選択する。
【０２４１】
ステップＳ３４８およびステップＳ３４９の各処理は、ステップＳ１２８およびステップＳ１２９の各処理（図１０）と同様に実行される。ステップＳ３４９の処理が終了すると、再生処理が終了する。
【０２４２】
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０２４３】
＜４−３：実施の形態２−１−１−１＞
＜MPDのみ拡張＞
その場合、例えば、MPDファイルの拡張のみにより、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
【０２４４】
＜MPDのシグナリング＞
例えば、MPDファイル１２２の、全てのメッシュおよび、テクスチャのAdaptationSetにおいて、ビットレート順(Representation@bandwidth順)に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す品質相関情報を追加するようにしてもよい。
【０２４５】
具体的には、Periodに、SupplementalPropertyで、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetのidリストをスペース区切りでシグナリングする。以下にその例を示す。
【０２４６】
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder"
value="as1@id as2@id ・・・">
【０２４７】
このSupplementalPropertyは、複数シグナリングしてもよい。例えば、6DoFコンテンツではなく、Audioにも同様に適用してもよい。
【０２４８】
本実施の形態の場合のMPDファイル１２２の例を図４２に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャに３つのビットレートバリエーションを持つ。
【０２４９】
例えば、図４２で、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、ビットレートの組合せ（Representationの組み合わせ）は以下の３パターンから選択すると相対的な品質を維持した表示が可能となる。
【０２５０】
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-2、Representation@id=BMt-2、Representation@id=CMm-2、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-3、Representation@id=CMt-3
【０２５１】
＜変形例＞
図４２においてはPeriodにシグナリングする例を書いたが、AdaptationSetにシグナリングするようにしてもよい。ただし、その場合、value値は指定せず、このPropertyをもつAdaptationSetがビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetであることを示すようにする。以下に例を示す。また、この場合のMPDファイル１２２の例を図４３に示す。
【０２５２】
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder">
【０２５３】
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてグループ番号を指定し、同じグループ番号間では一律に下げるようにしてもよい。例えば、以下の例のように、valueの先頭にGroupIdをシグナリングするようにしてもよい。
【０２５４】
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder"
value="G
roupId, as1@id as2@id ・・・">
【０２５５】
また、以下の例のように、SupplementalPropertyではなく、Periodもしくは、AdaptationSetのAttributeとして、@ RelativeQualityIsEnsuredByBitrateOrderをシグナルし、値としてTrue/Falseもしくはグループ番号をシグナルするようにしてもよい。
【０２５６】
例：<Period RelativeQualityIsEnsuredByBitrateOrder="as1@id as2@id ・・・">
例：<ApdationSet  RelativeQualityIsEnsuredByBitrateOrder="True">
【０２５７】
上述した実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３の全てにおいて、本実施の形態において説明した方法を適用することができる。本手法を実施の形態１−１−２に適用する場合、URLパラメータや、MPDのRepresentationGroupで示された中で、ビットレート順で処理するようにすればよい。
【０２５８】
＜再生処理の流れ＞
この場合のファイル生成処理は、図４０のフローチャートと同様に実行される。この場合の再生処理の流れの例を、図４４のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ３６１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を取得する。
【０２５９】
ステップＳ３６２乃至ステップＳ３６６の各処理は、ステップＳ１６２乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
【０２６０】
ステップＳ３６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、ビットレートの順番が同じであるRepresentationを選択し、取得する全セグメントファイルのビットレートの合計がステップＳ３６６において取得した伝送帯域より小さくなるように、Representationを選択する。
【０２６１】
ステップＳ３６８およびステップＳ３６９の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ３６９の処理が終了すると、再生処理が終了する。
【０２６２】
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０２６３】
＜４−４：実施の形態２−１−１−２＞
＜Scene Descriptionの拡張＞
実施の形態２−１−１−１において説明した方法のようにMPDファイル１２２ではシグナリングせずに、Scene Descriptionデータ１２１においてシグナリングするようにしてもよい。
【０２６４】
＜Scene Descriptionのシグナリング＞
Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６のurl fieldの記述を拡張するようにしてもよい。例えば、URLにビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すURLパラメータを付加するようにする。より具体的には、例えば、RelativeQualityIsEnsuredByBitrateOrderをURLパラメータの変数とし付加する。このURLパラメータを持つ場合、ビットレート順（Representation@bandwidth順）に取得すると3Dオブジェクト間の相対的な品質が維持できることを示すものとする。以下に例を示す。
【０２６５】
URLの例：
http://www.6dofserver.com/6dof.mpd?AS=1&RelativeQualityIsEnsuredByBitrateOrder
【０２６６】
この場合のScene Descriptionデータ１２１の例を図４５に示す。図４５に示されるように、Bitwrapperノード１５およびMovieTextureノード１６のurl fieldのURLに、URLパラメータの変数として、RelativeQualityIsEnsuredByBitrateOrderが付加されている。
【０２６７】
このようにすることにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を、Scene Descriptionデータ１２１においてシグナリングすることができる。したがって、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０２６８】
以上においては、実施の形態１−１−１に適用する場合について説明したが、本手法は、実施の形態１−１−２や実施の形態１−１−３にも同様に適用することができる。実施の形態１−１−２に適用する場合、URLパラメータや、MPDのRepresentationGroupで示された中で、ビットレート順で処理するようにすればよい。
【０２６９】
＜変形例＞
本拡張においても、実施の形態２−１−１の変形例のように、ビットレート順に取得するグルーピングを示すために、URLパラメータの値としてグルーピング番号を示すようにしてもよい。
【０２７０】
＜４−５：実施の形態２−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、ビットレートを一律に下げるためのシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０２７１】
つまり、実施の形態１−２と同様のシステムにおいて、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図２９の例と同様であり、ファイル生成装置１０１の構成は図３０の例と同様であり、クライアント装置１０３の構成は図３１の例と同様である。
【０２７２】
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図４６のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ３８１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むScene Descriptionデータ１２１を生成する。
【０２７３】
ステップＳ３８２乃至ステップＳ３８５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理（図３２）と同様に実行される。ステップＳ３８５の処理が終了すると、ファイル生成処理が終了する。
【０２７４】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図４７のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のScene Descriptionセグメントファイル取得部１８３は、ステップＳ４０１において、現在時刻の、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むScene Descriptionセグメントファイルを取得する。
【０２７５】
ステップＳ４０２乃至ステップＳ４０４の各処理は、ステップＳ２４２乃至ステップＳ２４４の各処理（図３３）と同様に実行される。
【０２７６】
ステップＳ４０５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、伝送帯域と、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されることを示す情報とに基づいて、ノードを選択する。
【０２７７】
ステップＳ４０６およびステップＳ４０７の各処理は、ステップＳ２４６およびステップＳ２４７の各処理（図３３）と同様に実行される。ステップＳ４０７の処理が終了すると、再生処理が終了する。
【０２７８】
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０２７９】
＜４−６：実施の形態２−１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。
【０２８０】
＜Scene Descriptionのシグナリング＞
例えば、全てメッシュとテクスチャにおいて、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す品質相関情報を追加するようにしてもよい。より具体的には、ClientSelectionノード３０１にビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すRelativeQualityIsEnsuredByBitrateOrderFlag fieldを追加するようにしてもよい。そのClientSelectionノードの拡張例を図４８に示す。
【０２８１】
このRelativeQualityIsEnsuredByBitrateOrderFlagがTRUEであるメッシュおよびテクスチャは、ビットレートを変更する際に、bitrate fieldで示されているビットレート順に同時に下げることにより、3Dオブジェクト間の相対的な品質を変えずにビットレートを下げることができることを示す。
【０２８２】
＜変形例＞
なお、本拡張においても、ビットレート順に取得するグルーピングを示すために、RelativeQualityIsEnsuredByBitrateOrderFlag ではなく、RelativeQualityIsEnsuredByBitrateOrderとし、SFint型でシグナルしグルーピング番号を示すようにしてもよい。
【０２８３】
＜４−７：実施の形態２−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。
【０２８４】
＜Scene Descriptionのシグナリング＞
例えば、実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のRelativeQualityIsEnsuredByBitrateOrderFlag fieldを拡張するようにしてもよい。図４９にその場合の、Bitwrapperノード１５およびMovieTextureノード１６の例を示す。
【０２８５】
＜変形例＞
本拡張においても、ビットレート順に取得するグルーピングを示すために、RelativeQualityIsEnsuredByBitrateOrderFlag ではなく、RelativeQualityIsEnsuredByBitrateOrderとし、SFint型でシグナルしグルーピング番号を示すようにしてもよい。
【０２８６】
また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０２８７】
＜５．第３の実施の形態（実施の形態３）＞
＜取得するビットレート組合せ示すシグナリング＞
さらに、各テクスチャ、メッシュのバリエーションに対して、どのビットレートのものを同時に取得すれば相対的な品質の関係を維持できるかを示す品質相関情報を追加するようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報をさらに含むメタデータを生成するようにしてもよい。
【０２８８】
3Dオブジェクト毎にビットレートバリエーション数やその中の品質の変化は異なることがある。例えば、メッシュデータは、頂点数の多い3Dオブジェクト（例えば人）は複数のビットレートを作成することができるが、頂点数の少ない3Dオブジェクト(例えば箱)はエンコードパラメータを変えてもビットレートは変わらないため、同じ数のビットレートが準備できない。
【０２８９】
そのような場合に、第２の実施の形態のように一律にビットレートを下げてしまうと、視点位置で決めた3Dオブジェクト間の相対的な品質の関係が大きく崩れる可能性があった。3Dオブジェクトによってはビットレートバリエーションがなく対応できないこともあり得る。その場合、取得できるビットレートのファイルが存在しないので、コンテンツを再生できなくなることもあり得る。
【０２９０】
上述のように、品質相関情報を追加することにより、そのような場合であっても3Dオブジェクト間の相対的な品質の関係を維持するようにビットレートを制御することができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０２９１】
＜５−１：実施の形態３−１＞
＜品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリング＞
3Dオブジェクトの各Level of Detailのメッシュおよびテクスチャそれぞれのビットレートバリエーションに品質のランキングをシグナリングする。さらに、それの値を元に取得することで、相対的な品質が維持できることを示すシグナリグを行うようにしてもよい。例えば、３次元オブジェクトの間の相対的な品質を示す情報として、３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含むメタデータを生成するようにしてもよい。この際に、QualityRankingの値で相対的な品質が変わらないようにエンコードする。例えば、実施の形態２のビットレートアダプテーションの構成方法でエンコードし、エンコードパラメータ順にQualityRankingを決め、その後、ビットレートの変化が少ないものを間引くようにしてもよい。
【０２９２】
＜５−２：実施の形態３−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、QulityRanking（品質相関情報）をシグナリングするようにしてもよい。このQualityRankingは既存のDASH規格（ISO/IEC 23009-1）のRepresentation@QualityRankingを用いる。
【０２９３】
つまり、実施の形態１−１と同様のシステムにおいて、QulityRankingをシグナリングするようにしてもよい。つまり、この場合の配信システム１００の構成は図６の例と同様であり、ファイル生成装置１０１の構成は図７の例と同様であり、クライアント装置１０３の構成は図８の例と同様である。
【０２９４】
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図５０のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ４２１において、QualityRankingを含むMPDファイル１２２を生成する。
【０２９５】
ステップＳ４２２乃至ステップＳ４２８の各処理は、ステップＳ１０２乃至ステップＳ１０８の各処理（図９）と同様に実行される。ステップＳ３２８の処理が終了すると、ファイル生成処理が終了する。
【０２９６】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図５１のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ４４１において、QualityRankingを含むMPDファイル１２２を取得する。
【０２９７】
ステップＳ４４２乃至ステップＳ４４６の各処理は、ステップＳ１２２乃至ステップＳ１２６の各処理（図１０）と同様に実行される。
【０２９８】
ステップＳ４４７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、伝送帯域と、QualityRankingとに基づいて、メディアデータセグメントファイルを選択する。
【０２９９】
ステップＳ４４８およびステップＳ４４９の各処理は、ステップＳ１２８およびステップＳ１２９の各処理（図１０）と同様に実行される。ステップＳ３４９の処理が終了すると、再生処理が終了する。
【０３００】
以上のように各処理を実行することにより、QualityRankingに基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０３０１】
＜５−３：実施の形態３−１−１−１＞
＜MPDのみ拡張＞
その場合、例えば、MPDファイルの拡張のみにより、全てのメッシュおよび、テクスチャのAdaptationSetにおいて、RepresentationでシグナリングされるQualityRanking順（Representation＠QualityRanking）に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す情報を追加するようにしてもよい。
【０３０２】
より具体的には、Periodに、SupplementalPropertyで、QualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetのidリストをスペース区切りでシグナリングする。以下に例を示す。
【０３０３】
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByQualityRanking"
value="as1@id as2@id ・・・">
【０３０４】
同じQualityRanking値のRepresentationがない場合、近いQualityRanking値のRepresentationを選択するようにしてもよい。このSupplementalPropertyは複数シグナリングされることもできる。例えば、6DoFコンテンツではなく、Audioにも同様に適用する場合である。
【０３０５】
この場合のMPDファイル１２２の例を図５２に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャのビットレートバリエーションは、異なっている。
【０３０６】
図５２において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、ビットレートの組合せはQualityRankingを参考に次の３パターンから選択すると相対的な品質を維持した表示が可能となる。
【０３０７】
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
【０３０８】
実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３のいずれにおいても本手法の適用が可能である。ただし、実施の形態１−１−２の場合、QualityRankingが1から始まらないRepresentationGroupが選択される場合があるが、クライアントの実装で、QualityRankingの値ではなく、QualityRankingの差を用いることで適用が可能である。
【０３０９】
＜変形例＞
以上においてはPeriodにシグナリングする例を書いたが、AdaptationSetにシグナリングしてもよい。ただし、その場合は、value値は指定せず、このPropertyをもつAdaptationSetでQualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetであることを示す。以下に例を示す。また、この場合のMPDファイル１２２の例を図５３に示す。
【０３１０】
例：<SupplementalProperty
schemeIdUri="RelativeQualityIsEnsuredByQualityRanking">
【０３１１】
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてグループ番号を指定し、同じグループ番号間では一律に下げるようにしてもよい。例えば、valueの先頭にGroupIdをシグナリングする。以下にその例を示す。
【０３１２】
例：<SupplementalProperty schemeIdUri=" RelativeQualityIsEnsuredByQualityRanking"
value="G
roupId, as1@id as2@id ・・・">
【０３１３】
＜その他の変形例＞
PeriodのAttributeにRelativeQualityIsEnsuredByQualityRankingを追加してもよい。また、AdaptationSetのAttributeにRelativeQualityIsEnsuredByQualityRankingを追加してもよい。以下にその例を示す。
【０３１４】
例：<Period RelativeQualityIsEnsuredByQualitRanking="1 2 3 … 17 18">
例：<AdaptatonSet RelativeQualityIsEnsuredByQualitRanking="TRUE">
【０３１５】
＜再生処理の流れ＞
この場合のファイル生成処理は、図５０のフローチャートと同様に実行される。この場合の再生処理の流れの例を、図５４のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ４６１において、QualityRankingを含むMPDファイル１２２を取得する。
【０３１６】
ステップＳ４６２乃至ステップＳ４６６の各処理は、ステップＳ１６２乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
【０３１７】
ステップＳ４６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、SupplementalPropertyで示されるAdaptationSetについては、QualityRankingの値が同じか、近い値のRepresentationを選択し、取得する全セグメントファイルのビットレートの合計が伝送帯域より小さくなる組み合わせを選択する。
【０３１８】
ステップＳ４６８およびステップＳ４６９の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ４６９の処理が終了すると、再生処理が終了する。
【０３１９】
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０３２０】
つまり、クライアント装置１０３は、各3DオブジェクトのメッシュデータおよびテクスチャデータのAdaptationSetから、ビットレートを選択する際に、QualityRankingの値が１である組合せ、次に２である組合せと、順に選択していくことで、ビットレートアダプテーションをしても相対的な品質の変わらないようにデータの選択が可能になる。QualityRankingの値が存在しない場合は近い値のQualityRankingのRepresentationを利用するようにしてもよい。
【０３２１】
本実施の形態において、QualityRankingをある一定以上存在していない場合がある。その場合、それ以上Qualityを下げることができないため、最低のQualityになるものを選び続けるしかない。しかしながら、QualityRankingが離れすぎてしまい、相対的な品質が維持できないかもしれない。それを回避するために次のような手法をできるようにしてもよい。
【０３２２】
（１）クライアント装置１０３が、他のQualityに合うように表示時のQualityを下げて表示する。たとえば、クライアント装置１０３が、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１および実施の形態１−１−２に本技術を適用する場合、クライアント装置１０３が、配信サーバ１０２にQualityRankingの低いビットレートを作成させそれを取得する。
【０３２３】
クライアント装置１０３は、配信サーバ１０２にMPDファイル名、ApdaptationSetのid、作成してほしいQualityRankingをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetのメッシュデータもしくはテクスチャデータの指定されたQualityRankingのセグメントファイルを作成する。そして、配信サーバ１０２は、MPDファイル１２２をMPD updateの仕組みを利用してUpdateし、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２に基づいて、再度、品質のランキングを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityRankingのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
【０３２４】
＜５−４：実施の形態３−１−１−２＞
＜Scene Descriptionの拡張＞
実施の形態３−１−１−１において説明した方法のようにMPDファイル１２２ではシグナリングせずに、Scene Descriptionデータ１２１においてシグナリングするようにしてもよい。
【０３２５】
＜Scene Descriptionのシグナリング＞
その場合、実施の形態２−１−１−２の場合と同様に、Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６のurl fieldの記述を拡張するようにしてもよい。
【０３２６】
例えば、以下に示す例のように、Scene Descriptionデータ１２１のメッシュ、テクスチャを示すURLのURLパラメータで、QualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すようにしてもよい。
【０３２７】
URLの例：
http://www.6dofserver.com/6DoF.mpd?
AS=1&RelativeQualityIsEnsuredByByQualityRanking
【０３２８】
この場合のScene Descriptionデータ１２１の記述は、図４５の例のRelativeQualityIsEnsuredByBitrateOrderの部分がRelativeQualityIsEnsuredByByQualityRankingに置き換わったものになる。
【０３２９】
以上においては、実施の形態１−１−１に適用する場合について説明したが、本手法は、実施の形態１−１−２や実施の形態１−１−３にも同様に適用することができる。また、実施の形態３−１−１−１のQualityRankingの低くなるビットレートバリエーションが存在しない場合の処理を行うことができるようにしてもよい。
【０３３０】
＜変形例＞
また実施の形態３−１−１−１の変形例のようにグルーピング情報を追加するようにしてもよい。例えば、URLパラメータのRelativeQualityIsEnsuredByQualityRankingの値に、グルーピング情報を追加するようにしてもよい。以下にその例を示す。
【０３３１】
URLの例：
http://www.6dofserver.com/6DoF.mpd?
AS=1&RelativeQualityIsEnsuredByQualityRanking=1
【０３３２】
URLパラメータを拡張するのではなく、Bitwrapperノード１５、MovieTextureノード１６に、例えば、以下の例のような、新しいfieldを追加するようにしてもよい。
【０３３３】
例：field    SFBool    RelativeQualityIsEnsuredByQualityRankingFlag
【０３３４】
＜５−５：実施の形態３−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。なお、この実施の形態においては、（１）品質のランキングをシグナリングする拡張、（２）QualityRanking順に取得することで相対的な品質が維持できることを示すシグナリングの拡張、の２つの拡張が行われる。
【０３３５】
また、実施の形態１−２と同様のシステムにおいて、品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図２９の例と同様であり、ファイル生成装置１０１の構成は図３０の例と同様であり、クライアント装置１０３の構成は図３１の例と同様である。
【０３３６】
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図５５のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ４８１において、QualityRankingを含むScene Descriptionデータ１２１を生成する。
【０３３７】
ステップＳ４８２乃至ステップＳ４８５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理（図３２）と同様に実行される。ステップＳ４８５の処理が終了すると、ファイル生成処理が終了する。
【０３３８】
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図５６のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のScene Descriptionセグメントファイル取得部１８３は、ステップＳ５０１において、現在時刻の、QualityRankingを含むScene Descriptionセグメントファイルを取得する。
【０３３９】
ステップＳ５０２乃至ステップＳ５０４の各処理は、ステップＳ２４２乃至ステップＳ２４４の各処理（図３３）と同様に実行される。
【０３４０】
ステップＳ５０５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、伝送帯域と、QualityRankingとに基づいて、ノードを選択する。
【０３４１】
ステップＳ５０６およびステップＳ５０７の各処理は、ステップＳ２４６およびステップＳ２４７の各処理（図３３）と同様に実行される。ステップＳ５０７の処理が終了すると、再生処理が終了する。
【０３４２】
以上のように各処理を実行することにより、QualityRankingに基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０３４３】
＜５−６：実施の形態３−１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。例えば、実施の形態１−２−１において説明したClientSelectionノード３０１を拡張するようにしてもよい。
【０３４４】
そのClientSelectionノード３０１の拡張例を図５７に示す。例えば、ClientSelectionノード３０１において、SelectionNode fieldで示される子ノードの品質のランキングをQualityRanking fieldで記述する。QualityRanking[n]は、SelectionNode[n]の品質のランキングを示す。
【０３４５】
また、RelativeQualityIsEnsuredByQualityRankingFlagがTRUEであるメッシュおよびテクスチャは、QualityRanking fieldで示されているQualityRanking値が同じであるメッシュおよびテクスチャを選択することで、3Dオブジェクト間の相対的な品質を維持してビットレートを変更できることを示す。
【０３４６】
＜変形例＞
また実施の形態３−１−１−１の変形例のように、グルーピング情報をシグナルできるようにしてもよい。その場合、RelativeQualityIsEnsuredByQualityRankingFlagを以下の例に置き換え、値としてグルーピング情報を持つようにする。
【０３４７】
field    SFint32    RelativeQualityIsEnsuredByQualityRanking
【０３４８】
＜５−７：実施の形態３−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。
【０３４９】
＜Scene Descriptionのシグナリング＞
例えば、実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のQualityRanking fieldおよび、RelativeQualityIsEnsuredByQualityRankingFlag fieldを拡張するようにしてもよい。図５８にその場合の、Bitwrapperノード１５およびMovieTextureノード１６の例を示す。
【０３５０】
＜変形例＞
実施の形態３−１−２−１の変形例のように、グルーピング情報を扱えるようにしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０３５１】
＜５−８：実施の形態３−２＞
＜Qualityそのものをシグナリング＞
全てのビットレートバリエーションのQuality（例えばPSNRなど）をシグナリングする。この場合、クライアント装置１０３は、Qualityの変化が同じ程度になるようなデータを選択する。換言するに、３次元オブジェクトの間の相対的な品質を示す情報として、その３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含むメタデータを生成するようにしてもよい。
【０３５２】
＜５−９：実施の形態３−２−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレートバリエーションのQualityをシグナリングするようにしてもよい。
【０３５３】
＜MPDのシグナリング＞
例えば、QualityそのものをRepresentationでシグナリングするようにしてもよい。例えば、Representationにおいて、SupplementalPropertyを用いて、Qualityの種類や値をシグナリングするようにしてもよい。以下にその例を示す。
【０３５４】
<SupplementalProperty schemeIdUri="QualityValue" value="type,value">
【０３５５】
この例において、Qualityの種類はtypeにより、Qualityの値はvalueによりシグナリングされる。Qualityの種類によっては時間毎にQuality値が異なることや、3Dオブジェクトを見る位置や方向などでQuality値が変わる可能性もある。その場合、本手法では特定の時間、視点位置、視線方向を元に計算された代表値のQuality値を利用すればよい。また、typeは図５９の表のように示されればよい。
【０３５６】
クライアント装置１０３は、示されているtypeとvalue値を用いて、ビットレートを下げる際に、Qualityの変化が同じ程度になるようなRepresentationを選択することで、相対的な品質を維持したビットレート選択が可能になる。
【０３５７】
この場合のMPDファイル１２２の例を図６０に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャのビットレートバリエーションは、異なっている。
【０３５８】
図６０に示されるMPDファイル１２２において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合を考える。ビットレートの組合せはQualityのValueを参考に最もQualityの良いものからの差が同じもしくは近い値を選択すると、次の３パターンが相対的な品質を維持した表示が可能である組合せになる。
【０３５９】
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
【０３６０】
本実施の形態の手法は、実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３のいずれにも適用することができる。
【０３６１】
本実施の形態の手法において、Quality値がある一定以上存在しない場合がある。その場合、それ以上Qualityを下げることができないため、最低のQualityになるものを選び続けるしかない。しかしながら、Qualityの相関関係が崩れてしまう。それを回避するために次のような手法をできるようにしてもよい。
【０３６２】
（１）クライアントで他のQualityに合うように表示時のQualityを下げて表示する。例えば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、 クライアント装置１０３は、配信サーバ１０２にQualityの低いビットレートを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に、MPDファイル名、ApdaptationSetのid、作成してほしいQualityのtypeとvalueをリクエストする。配信サーバ１０２は、リクエストに応じて指定されたAdaptationSetのメッシュデータもしくはテクスチャデータの指定されたQualityのtypeとvalueになるセグメントファイルを作り、配置する。そして、MPDファイル１２２をMPD updateの仕組みを利用し Updateして、クライアント装置１０３に送信する。クライアント装置１０３は新しく取得したMPDファイルを基に、再度、Qualityを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityのtypeとvalueのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
【０３６３】
＜変形例＞
RepresentaitonのAttributeにQualityValueを追加するようにしてもよい。以下にその例を示す。
【０３６４】
例：<RepresentationAdaptatonSet  QualityValue="1,41">
【０３６５】
＜５−１０：実施の形態３−２−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Qualityそのもののシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０３６６】
＜５−１１：実施の形態３−２−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。
【０３６７】
本実施は、実施の形態１−２−１のClientSelectionノード３０１を拡張して実現する。この場合のClientSelectionノード３０１の構成例を図６１に示す。ClientSelectionノード３０１のSelectionNodeで示される子ノードのQualityそのものをQualityValue fieldで示す。QualityValue[n]は、SelectionNode[n]のQualityを示す。さらに、Qualityの種類をQualityType fieldで示す。QualityTypeは全てのQualityValueで共通である。QualityType fieldの値は、図５９の表４０１の値を利用する。
【０３６８】
＜５−１２：実施の形態３−２−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態３−２−２−１の変形例である。実施の形態１−２−２で拡張したBitwrapperノード１５およびMovieTextureノード１６に、QualityValue fieldおよび、QualityType fieldを拡張して実現する。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図６２に示す。
【０３６９】
なお、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０３７０】
＜５−１３：実施の形態３−３＞
＜同時に再生するメディアデータの組み合せをシグナリング＞
また、同時に再生するメディアデータの組み合せをシグナリングするようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な３次元オブジェクトの各ビットレートバリエーションを示す情報を含むメタデータを生成するようにしてもよい。
【０３７１】
＜５−１４：実施の形態３−３−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、同時に再生するメディアデータの組み合せをシグナリングするようにしてもよい。
【０３７２】
＜MPDのシグナリング＞
例えば、相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。
【０３７３】
クライアント装置１０３は、AdaptationSetからRepresentationを選択する際に、同じGroupを選択して再生する。１つのRepresentationが複数のGroupに所属する場合もある。より具体的には、各Representationに、SupplementalPropertyで、グループ番号を示し、このグループ番号をもとに同じグループ番号を選択すれば3Dオブジェクト間の相対的な品質が変わらないことを示す。value値がグループ番号を示す。スペース区切りで複数のグループを示すことができる。以下に例を示す。
【０３７４】
例：<SupplementalProperty schemeIdUri="KeepRelativeQualityConsiderationGroup"
value="1...">
【０３７５】
図６３は、その場合のMPDファイル１２２の記述例を示す図である。図６３において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail(AdaptationSet@id=15と16)が適切なLevel of detailであると選択されている場合を考える。ビットレートの組合せはKeepRelativeQualityConsiderationGroupの同じ値のRepresentaitonを選択することで、相対的な品質を維持することができる組合せである。この例では、次の３パターンが相対的な品質を維持した表示が可能である組合せになる。
【０３７６】
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
【０３７７】
本実施の形態において、最大の数値のGroup以上にQualityを下げることができない。その際、さらに低いQualityになるGroupを配信サーバ１０２に作成させ、それを取得できるようにしてもよい。クライアント装置１０３は、配信サーバ１０２に、MPDファイル名と、KeepReativeQualityGroupのさらに低い組合せをリクエストする。配信サーバ１０２はリクエストに応じて、KeepReativeQualityGroupの最大数値のGroupよりも低いQualityになる、つまり、全ての3Dオブジェクトで最も低いQualityのメディアデータを作成し、配置する。配信サーバ１０２は、そのMPDファイル１２２をUpdateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、KeepReativeQualityGroupを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityのgroupのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
【０３７８】
＜変形例＞
RepresentaitonのAttributeにKeepRelativeQualityGroupを追加するようにしてもよい。以下にその例を示す。
【０３７９】
例：<AdaptatonSet  KeepRelativeQualityGroup ="1">
【０３８０】
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてKeepRelativeQualityGroupをさらにグルーピングするidをシグナリングするようにしてもよい。例えば、valueの先頭にGroupIdをシグナリングするようにしてもよい。以下にその例を示す。
【０３８１】
例：<SupplementalProperty schemeIdUri=" KeepRelativeQualityGroup"
value="GroupId, as1@id as2@id ・・・">
【０３８２】
＜５−１５：実施の形態３−３−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
実施の形態１−２の、Scene Descriptionのみを拡張した手法において、相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。
【０３８３】
＜５−１６：実施の形態３−３−２−１＞
＜新しいノードを定義する＞
実施の形態１−２−１のClientSelectionノード３０１を拡張するようにしてもよい。この場合のClientSelectionノード３０１の例を図６４に示す。図６４において、ClientSelectionノード３０１のSelectionNodeで示される子ノードに相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。より具体的には、KeepRelativeQualityConsiderationGroupを各SelectionNodeに設定するようにしてもよい。SlectionNode[n]が属するGroup情報は、KeepRelativeQualityConsiderationGroup[n]に示される。Groupは、整数値を文字として示し、複数のgroupに属する場合は、スペース区切りで表記する。
【０３８４】
＜変形例＞
また実施の形態３−２−１の変形例のようにKeepRelativeQualityGroupをさらにグルーピングするidをシグナリングするようにしてもよい。その場合、以下の例のようなKeepRelativeQualityGroupId fieldを追加すればよい。
【０３８５】
field    SFint32    KeepRelativeQualityGroupId
【０３８６】
＜５−１７：実施の形態３−３−２−２＞
＜既存のノードを拡張する＞
実施の形態３−３−２−１の変形例である。実施の形態１−２−２で拡張した、Bitwrapperノード１５およびMovieTextureノード１６にKeepRelativeQualityConsiderationGroup fieldを拡張するようにしてもよい。図６５に拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。
【０３８７】
＜変形例＞
また、実施の形態の３−３−２−１のようにKeepRelativeQualityGroupId fieldを追加するようにしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例について説明したが、これに限らず、他のノードで同様のfieldを拡張するようにしてもよい。
【０３８８】
＜６：第４の実施の形態（実施の形態４）＞
＜Level of detailを切り替えてビットレート選択をするためのシグナリング＞
さらに、限界までビットレートを落とした後、視点位置に応じて決めた3DオブジェクトのLevel of detailから、１つ若しくは複数、または、全ての3Dオブジェクトに対するLevel of detailを下げて、ビットレートアダプテーションするためのシグナリングを追加するようにしてもよい。
【０３８９】
全ての3Dオブジェクトで最低のビットレートのメッシュ、テクスチャを選択しても、その合計ビットレートよりも伝送帯域が狭い場合、再生が途切れてしまう可能性があった。
【０３９０】
上述のように、Level of detailを下げてビットレートアダプテーションするためのシグナリングを行うことにより、上述のような場合に、6DoFコンテンツの品質の低減を抑制するように、Level of detailを一律に下げることができるようになる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０３９１】
＜６−１：実施の形態４−１＞
＜Level of detailを一律に下げると相対関係が崩れないことを示すシグナリング＞
Level of detailを切り替えてビットレート選択をするために、Level of detailを一律に下げると相対関係が崩れないことを示すシグナリングするようにしてもよい。換言するに、３次元オブジェクトのLevel of Detailを変更しても、その３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
【０３９２】
＜６−２：実施の形態４−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Level of detailを一律に下げると相対関係が崩れないことをシグナリングするようにしてもよい。
【０３９３】
＜MPDのシグナリング＞
実施の形態１−１−１を基にした実施の形態においては、Scene Descriptionの3DオブジェクトのLevel of detailごとにMPDのAdaptationSetにアクセスできるようになっている。しかしながら、実施の形態１−１−１を基にした実施の形態のMPDには、それぞれのAdaptationSetがどの3DオブジェクトのLevel of Detailに対応するかは示されていない。Level of Detailを切り替えるために、どの3DオブジェクトのLevel of Detailであるかを、Scene Descriptionから情報を取得するのは２度手間になる（煩雑・冗長な作業が必要になる）。
【０３９４】
そこで、まず、MPDで同じ3Dオブジェクトに含まれるLevel of Detailがどれであるかを示すようにする。つまり、同じ3DオブジェクトのメッシュのAdaptationSet（Level of Detail）をグルーピングする。同様に同じ3DオブジェクトのテクスチャのAdaptationSet（Level of Detail）をグルーピングする。さらに、Level of detailを一律に下げる場合において、各オブジェクトの表示の相対関係を極力維持することができることをシグナリングする。
【０３９５】
このような手法を実現する具体的なシグナリングは、Periodに、Level of detailを一律に下げる場合に、各オブジェクトの表示の相対関係を極力維持できることを示すSupplementalPropertyをシグナリングし、それが可能であるLevel of Detailのグループをシグナリングする。
【０３９６】
SupplementalPropertyを用いて、schemeIdUriで、Level of detailを一律に下げる場合において、各オブジェクトの表示の相対関係を極力維持することができることを示す、" LODRelativeQualityIsEnsuredByLODOrder"をシグナリングする。さらに、SupplementalPropertyのElementにLODGroupを追加する。LODGroupは同じ3Dオブジェクトのメッシュもしくは同じ3DオブジェクトのテクスチャのAdaptationSetのグルーピング情報である。LODGroupのmember attributeでグループに含まれるAdaptationSet@idをシグナリングする。シグナリングされるAdaptationSet@idの順は、高Level of detailから順に並べ、Level of Detailの下げる順を示す。以下に例を示す。
【０３９７】
例：
<SupplementalProperty schemeIdUri="LODRelativeQualityIsEnsuredByLODOrder">
<LODGroup member="as@id1 as@id2..."/>
<LODGroup member="as@id4 as@id5..."/>
</SupplementalProperty>
【０３９８】
クライアントは、第２の実施の形態や第３の実施の形態の手法でビットレートを下げることが困難になった場合、このSupplementalPropertyを基に１つLevel of detailの低いAdaptationSetの組合せを選択し、再び第２の実施の形態や第３の実施の形態の手法を用いてビットレート選択をする。その際に、低いLevel of Detailが存在しない場合は、最も低いLevel of detailの最低ビットレートのデータを使う。
【０３９９】
この場合のMPDファイル１２２の例を図６６に示す。この例では、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。それぞれの3DオブジェクトのLevel of detail違いのメッシュデータのグループおよびテクスチャデータのグループを、SupplementalPropertyで示している。
【０４００】
図６６において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている。その組合せの中でビットレートを下げても合計ビットレートが伝送帯域より多くなってしまう場合、Level of detailを変更する。この際に、SupplementalPropertyを参考に、全てで１つずつ低いLevel of detailを選択する。すると以下のような組み合わせになる。
【０４０１】
AdaptationSet@id=3  （3DオブジェクトA  中Level of detailのメッシュデータ）
AdaptationSet@id=4  （3DオブジェクトA  中Level of detailのテクスチャデータ）
AdaptationSet@id=11  （3DオブジェクトB  低Level of detailのメッシュデータ）
AdaptationSet@id=12  （3DオブジェクトB  低Level of detailのテクスチャデータ）
AdaptationSet@id=17  （3DオブジェクトC  低Level of detailのメッシュデータ）
AdaptationSet@id=18  （3DオブジェクトC  低Level of detailのテクスチャデータ）
【０４０２】
本手法は、実施の形態１−１−１にも適用することができる。なお、実施の形態１−１−１−１に本手法を適用する場合、実施の形態１−１−２−２のAdaptationSet内でRepresentationGroupを示すシグナリングを行い、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
【０４０３】
実施の形態１−１−２−２に本手法を適用する場合、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
【０４０４】
＜変形例＞
また、以下のようなシグナリングを行うようにしてもよい。
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順をSupplementalPropertyで各AdaptationSetにシグナリングする。もしくはAdaptationSetのAttributeに指定する。
（２）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順は、Scene Descriptionから取得する。
（３）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。その記述例を以下に示す。なお、このシグナリングは、AdaptationSetのAttributeで指定するようにしてもよい。
【０４０５】
<SupplementalProperty schemeIdUri="LowLevelAdaptationSet"
value="AdaptationSet@id">
<SupplementalProperty schemeIdUri="HighLevelAdaptationSet"
value="AdaptationSet@id">
【０４０６】
（４）上述の（１）乃至（３）において、さらに、Level of Detailを一律に下げると相対的な品質関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、Level of detailを一律に下げると相対関係を極力維持することができるAdaptationSetであることをシグナリングする。以下にその例を示す。なお、このシグナリングは、AdaptationSetのAttributeで指定するようにしてもよい。
【０４０７】
例：<SupplementalProperty schemeIdUri="LODRelativeQualityIsEnsuredByLODOrder">
【０４０８】
本手法は、実施の形態１−１−１に適用することができる。なお、本手法を実施の形態１−１−２−１に適用する場合、実施の形態１−１−２−２のAdaptationSet内でRepresentationGroupを示すシグナリングを行い、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
【０４０９】
また、本手法を実施の形態１−１−２−２に適用する場合、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
【０４１０】
＜再生処理の流れ＞
この場合の再生処理の流れの例を、図６７のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ５２１において、QualityGroup情報を含むMPDファイル１２２を取得する。
【０４１１】
ステップＳ５２２乃至ステップＳ５２６の各処理は、ステップＳ１６１乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
【０４１２】
ステップＳ５２７において、メディアデータセグメントファイル選択部１８７は、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが選択可能であるか否かを判定する。可能であると判定された場合、処理はステップＳ５２８に進む。
【０４１３】
ステップＳ５２８において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、取得する全セグメントファイルのビットレートの合計が伝送帯域より小さくなるようにRepresentationを選択する。ステップＳ５２８の処理が終了すると、処理はステップＳ５３０に進む。
【０４１４】
また、ステップＳ５２７において、現在のLevel of Detailでは伝送帯域より小さくなるビットレートの組み合わせを得ることは不可能であると判定された場合、処理はステップＳ５２９に進む。
【０４１５】
ステップＳ５２９において、メディアデータセグメントファイル選択部１８７は、ビットレート選択処理を行い、Level of Detailを下げて、ビットレートの選択を行う。ステップＳ５２９の処理が終了すると、処理はステップＳ５３０に進む。
【０４１６】
ステップＳ５３０およびステップＳ５３１の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ５３１の処理が終了すると、再生処理が終了する。
【０４１７】
＜ビットレート選択処理の流れ＞
次に、図６７のステップＳ５２９において実行されるビットレート選択処理の流れの例を、図６８のフローチャートを参照して説明する。
【０４１８】
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５５１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５５２に進む。
【０４１９】
ステップＳ５５２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyを基に１つずつLevel of Detailの低いAdaptationSetの組み合わせを選択する。
【０４２０】
ステップＳ５５３において、メディアデータセグメントファイル選択部１８７は、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせを選択することができるか否かを判定する。現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが存在しないと判定された場合、処理をステップＳ５５１に戻し、それ以降の処理を繰り返す。つまり、伝送帯域より小さくなるビットレートの組み合わせが見つかるか、全ての3DオブジェクトのLevel of Detailが最低になるまで、ステップＳ５５１乃至ステップＳ５５３の処理が繰り返される。
【０４２１】
そして、ステップＳ５５３において、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが存在すると判定された場合、処理はステップＳ５５４に進む。
【０４２２】
ステップＳ５５４において、メディアデータセグメントファイル選択部１８７は、各AdaptationSetから、ビットレートの合計が伝送帯域より小さくなるようにRepresentationを選択する。つまり、ステップＳ５５３において検出された「伝送帯域より小さくなるビットレートの組み合わせ」が選択される。ステップＳ５５４の処理が終了すると、ビットレート選択処理が終了し、処理は図６７に戻る。
【０４２３】
また、ステップＳ５５１において、全てのAdaptationSet（3Dオブジェクト）のLevel of Detailが最低であり、これ以上Level of Detailを下げる余地がないと判定された場合、処理はステップＳ５５５に進む。
【０４２４】
ステップＳ５５５において、メディアデータセグメントファイル選択部１８７は、選択されているAdaptationSetで最低のビットレートになるようにRepresentationを選択する。ステップＳ５５５の処理が終了すると、ビットレート選択処理が終了し、処理は図６７に戻る。
【０４２５】
以上のように各処理を実行することにより、3Dオブジェクト間の相対的な品質を維持するように、Level of Detailを下げて、ビットレートを制御することができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
【０４２６】
なお、Level of Detailがある一定以上存在していない場合がある。その場合、それ以上Level of Detailを下げることができないため、最低のLevel of Detailの最低のビットレートを選び続けるしかない。しかしながら、その場合、Level of Detailの相対関係が崩れてしまう。それを回避するために次のような手法をできるようにしてもよい。
【０４２７】
（１）クライアントで他のQualityに合うように表示時のQualityを下げて表示する。例えば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、クライアント装置１０３は、配信サーバ１０２にさらに低いLevel of Detailを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に対し、MPDファイル名、ApdaptationSetのidをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetよりさらに低いLevel of Detailのメッシュデータもしくはテクスチャデータのビットレートバリエーションを作成し、配置する。そして、そのMPDファイル１２２をMPD updateの仕組みを利用しUpdateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、Level of Detailを選択する。この場合に、サーバには存在しないが作成可能なLevel of DetailのセグメントファイルをあらかじめMPDとSecene Descriptionにシグナリングしておいてもよい。
【０４２８】
＜６−３：実施の形態４−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Level of detailを一律に下げると相対関係が崩れないことをシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０４２９】
＜６−４：実施の形態４−１−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態１−２−１のClientSelectionノード３０１を拡張し、そのClientSelectionノード３０１のSelectionNodeで示される子ノードにLevel of detailを一律に下げると相対的な品質が維持できることを示すフラグ情報（Flag）をシグナリングするようにしてもよい。より具体的には、LODRelativeQualityIsEnsuredByLODOrderFlagを追加するようにしてもよい。この場合のClientSelectionノード３０１の例を図６９に示す。
【０４３０】
＜６−５：実施の形態４−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、LODRelativeQualityIsEnsuredByLODOrderFlag fieldを拡張するようにしてもよい。図７０にその拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。この場合、Bitwrapperノード１５およびMovieTextureノード１６のそれぞれにおいて、LODRelativeQualityIsEnsuredByLODOrderFlag fieldが拡張されている。
【０４３１】
＜変形例＞
なお、本手法はLevel of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。図７１にその拡張したLODノード３１の例を示す。この場合、LODノード３１にLODRelativeQualityIsEnsuredByLODOrderFlag fieldが拡張されている。
【０４３２】
同様に、その他のノードを拡張するようにしてもよい。この場合、シグナリングするノードが少なくなる利点がある。
【０４３３】
＜６−６：実施の形態４−２＞
＜Qualityを基にLevel of detailを変更可能であることを示すシグナリング＞
Level of Detailを変更する際に、示されているQualityを基にLevel of Detailを変更することが可能であることを示すようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報に基づいて３次元オブジェクトのLevel of Detailを変更しても、その３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
【０４３４】
＜６−７：実施の形態４−２−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Qualityを基にLevel of detailを変更可能であることを示すシグナリングを行うようにしてもよい。
【０４３５】
＜MPDのシグナリング＞
実施の形態４−１−１の場合と同様に、3DオブジェクトのLevel of detailの異なるメッシュのAdaptationSet、または、同じ3Dオブジェクトのテクスチャをグルーピングし、さらに、Qualityを見てLevel of Detail変更をしてもよいことを示すようにしてもよい。
【０４３６】
例えば、SupplementalPropertyを用いて、schemeIdUriで、Level of detailを下げる場合にQualityの値を基準することで、各オブジェクトの表示の相対関係を極力維持することができることを示す、" LODRelativeQualityIsEnsuredByQualityValue"をシグナリングする。さらに、SupplementalPropertyのElementにLODGroupを追加する。LODGroupは同じ3Dオブジェクトのメッシュもしくは同じ3DオブジェクトのテクスチャのAdaptationSetのグルーピング情報である。LODGroup のmember attributeでグループに含まれるAdaptationSet@idをシグナリングする。シグナリングされるAdaptationSet@idの順は、高Level of detailから順に並べ、Level of Detailの下げる順を示す。以下に、その例を示す。なお、Quality値のシグナリングは、実施の形態３−２−１で示す手法を用いる。
【０４３７】
例：
<SupplementalProperty schemeIdUri= LODRelativeQualityIsEnsuredByQualityValue">
<LODGroup member="as@id1 as@id2..."/>
<LODGroup member="as@id4 as@id5..."/>
</SupplementalProperty>
【０４３８】
クライアント装置１０３は、実施の形態３−２−１のクライアント装置１０３の実装をLevel of Detailを下げる場合にも適応し、相対的な品質を維持した組合せでの取得を可能にする。
【０４３９】
実際のシグナリング例は、実施の形態３−２−１の図６０に示されるMPDファイル１２２に対し、図６６に示されるMPDファイル１２２のSupplementalPropertyのschemeIdUriをLODRelativeQualityIsEnsuredByQualityValueに変えたものを追加した形になる。
【０４４０】
なお、本手法は、実施の形態１−１−１に適用することができる。また、本手法は、LODGroupのmemberが１つのAdaptatonSet@idになり、その中のRepresentationGroupの順にQualityRankingを示すようにすることにより、実施の形態１−１−２にも適用することができる。
【０４４１】
＜変形例＞
以下に、他のシグナリング方法の例を示す。
【０４４２】
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順をSupplementalPropertyで各AdaptationSetにシグナリングする。AdaptationSetのAttributeにシグナリングしてもよい。
（２）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順は、Scene Descriptionから取得する。
（３）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。以下にその例を示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
【０４４３】
<SupplementalProperty schemeIdUri="LowLevelAdaptationSet"
value="AdaptationSet@id">
<SupplementalProperty schemeIdUri="HighLevelAdaptationSet"
value="AdaptationSet@id">
【０４４４】
（４）（１）乃至（３）においてはLevel of Detailを一律に下げると相対関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、Quality値を基にLevel of detailを下げてもよいAdaptationSetであることをシグナリングする。このシグナリングの例を以下に示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
【０４４５】
例：
<SupplementalProperty schemeIdUri=" LODRelativeQualityIsEnsuredByQualityValue">
【０４４６】
（５）Qualityそのものではなく、QulityRankingを用いてもよい。その場合は、3Dオブジェクトのメッシュもしくはテクスチャ全体でQualityRankingを付ける（Level of detailを超えた（AdaptationSetを超えた）QualityRankingになる）。
【０４４７】
なお、Level of Detailがある一定以上存在していない場合がある。その場合、それ以上Level of Detailを下げることができないため、最低のLevel of Detailの最低のビットレートを選び続けるしかない。しかしながら、その場合Level of Detailの相対関係が崩れてしまう。それを回避するために次のような手法を用いることができるようにしてもよい。
【０４４８】
（１）クライアント装置１０３で他のQualityに合うように表示時のQualityを下げて表示する。たとえば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、クライアント装置１０３は、配信サーバ１０２にさらに低いLevel of Detailを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に対し、MPDファイル名、ApdaptationSetのidをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetよりさらに低いLevel of Detailのメッシュデータまたはテクスチャデータのビットレートバリエーションを作成し、配置する。そして、そのMPDファイル１２２を、MPD updateの仕組みで Updateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、Level of Detailを選択する。この場合に、サーバには存在しないが作成可能なLevel of DetailのセグメントファイルをあらかじめMPDとSecene Descriptionにシグナリングしておいてもよい。
【０４４９】
＜６−８：実施の形態４−２−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Qualityを基にLevel of detailを変更可能であることを示すシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０４５０】
＜６−９：実施の形態４−２−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態３−２−２−１のClientSelectionノード３０１を拡張して、本手法のシグナリングを実現するようにしてもよい。この場合のClientSelectionノード３０１の例を図７２に示す。図７２に示されるように、このClientSelectionノード３０１において、SelectionNodeで示される子ノードがQuality値を基にLevel of detailを選択してもよいことを示すFlagがシグナリングされる。より具体的には、LODRelativeQualityIsEnsuredByQualityValueが追加される。
【０４５１】
＜変形例＞
例えば、Qualityそのものではなく、QualityRankingを用いるようにしてもよい。その場合、実施の形態４−２−１において説明したように、3Dオブジェクトのメッシュまたはテクスチャ全体でQualityRankingを付けるようにしてもよい。QualityRankingのシグナリングは、実施の形態３−１−２−１において説明した手法となり、それに、各オブジェクトの表示の相対関係を極力維持することができることを示す、LODRelativeQualityIsEnsuredByQualityRanking fieldを追加すればよい。
【０４５２】
＜６−１０：実施の形態４−２−２−２＞
＜既存のノードを拡張する＞
なお、実施の形態３−２−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを拡張するようにしてもよい。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図７３に示す。図７３に示されるように、この場合、Bitwrapperノード１５およびMovieTextureノード１６のいずれにも、上述のLODRelativeQualityIsEnsuredByLODOrderFlag fieldが追加されている。
【０４５３】
＜変形例＞
なお、Qualityそのものではなく、QualityRankingを用いるようにしてもよい。その場合、実施の形態４−２−１において上述したように、3Dオブジェクトのメッシュまたはテクスチャ全体でQualityRankingを付けるようにする。このQualityRankingのシグナリングは、実施の形態３−１−２−２の場合と同様に行えば良い。それに、LODRelativeQualityIsEnsuredByQualityRanking fieldを追加することにより、本手法を適用することができる。
【０４５４】
本手法はLevel of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。ただし、Quality値のシグナリングは必要であるため、実施の形態３−２−２−１において拡張したClientSelectionノード３０１または実施の形態３−２−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６のシグナリングは必要である。図７４にそのLODノード３１の拡張例を示す。この場合、シグナリングするノードが少なくなる利点がある。また、他のノードを同様に拡張するようにしてもよい。
【０４５５】
＜６−１１：実施の形態４−３＞
＜Level of detailにQualityRankingをシグナリングする＞
Level of detailにもQualityRankingをシグナリングし、クライアント装置１０３は、そのQualityRankingを基にLevel of Detailを切り替えるようにしてもよい。
【０４５６】
＜６−１２：実施の形態４−３−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Level of detailにQualityRankingをシグナリングするようにしてもよい。
【０４５７】
＜MPDのシグナリング＞
実施の形態４−１−１の場合と同様に、Periodにシグナリングする。例えば、実施の形態４−１−１に、LODGroupのattributeにQualityRankingを追加する。SupplementalProperty のLODRelativeQualityIsEnsuredByLODQualityRankingを示すことで、Level of detailごとに設定されているQualityRankingの相対関係を崩さないようにLevel of detailを選択することで、品質の相関を維持することができる。以下に例を示す。なお、membaer[n]のQualityRankingは、QualityRanking[n]である。
【０４５８】
例：
<SupplementalProperty 
schemeIdUri="LODRelativeQualityIsEnsuredByLODQualityRanking">
<LODGroup member="as@id1 as@id2..." QualityRanking="1 2…"/>
<LODGroup member="as@id4 as@id5..." QualityRanking="1 2…"/>
</SupplementalProperty>
【０４５９】
本手法は、例えば実施の形態１−１−１に適用することができる。なお、LODGroupのmemberが１つのAdaptatonSet@idになり、その中のRepresentationGroupの順にQualityRankingを示すことで、本手法を実施の形態１−１−２にも適用することができる。
【０４６０】
＜変形例＞
なお、シグナリング方法は上述の例に限らない。例えば、以下のようにしてもよい。
【０４６１】
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailのQualityRankingをSupplementalPropertyで各AdaptationSetにシグナリングする。AdaptationSetのAttributeでシグナリングしてもよい。
（２）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。以下にその例を示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
【０４６２】
<SupplementalProperty 
schemeIdUri="LowLevelAdaptationSet" value="AdaptationSet@id">
<SupplementalProperty 
schemeIdUri="HighLevelAdaptationSet" value="AdaptationSet@id">
【０４６３】
（３）（１）および（２）においては、Level of DetailのQualityRankingを基に選択すると相対関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、QualityRanking値を元にLevel of detailを下げると品質の相対関係が維持できるAdaptationSetであることを示すシグナリングを行う。以下にその例を示す。なお、AdaptationSetのAttributeでシグナリングするようにしてもよい。
【０４６４】
例：
<SupplementalProperty 
schemeIdUri=" LODRelativeQualityIsEnsuredByLODQualityRanking">
【０４６５】
＜６−１３：実施の形態４−３−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Level of detailにQualityRankingをシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０４６６】
＜６−１４：実施の形態４−３−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。例えば、実施の形態１−２−１において説明したClientSelectionノード３０１を拡張するようにしてもよい。
【０４６７】
そのClientSelectionノード３０１の拡張例を図７５に示す。例えば、ClientSelectionノード３０１において、SelectionNode fieldにLevel of detailを一律に下げると相対的な品質が維持できることを示すFlagをシグナリングする。より具体的には、LODRelativeQualityIsEnsuredByLODQualityRanking fieldを追加し、LODQualityRankingを設定する。
【０４６８】
＜６−１５：実施の形態４−３−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。例えば、実施の形態１−２−２のBitwrapperノード１５およびMovieTextureノード１６にLODRelativeQualityIsEnsuredByLODQualityRanking fieldを拡張するようにしてもよい。これは、図７０のBitwrapperノード１５およびMovieTextureノード１６のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを、図７５のClientSelectionノード３０１のLODRelativeQualityIsEnsuredByLODQualityRanking fieldで置き換えたものになる。
【０４６９】
＜変形例＞
本手法は、Level of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。この場合、シグナリングするノードが少なくなる利点がある。これは、図７１に示されLODノード３１のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを、図７５のLODRelativeQualityIsEnsuredByLODQualityRanking fieldで置き換えたものになる。もちろん、これ以外のノードを拡張するようにしてもよい。
【０４７０】
＜７．第５の実施の形態（実施の形態５）＞
＜コンテンツオーサなどの意図を示すシグナリング＞
さらに、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。なお、例えば、第４の実施の形態のフラグ情報（flag）があってもなくても、この手法を使うか否かはクライアントが選択するようにしてもよい。また、Level of detailのレベルによって重要度の有効・無効を設定することができるようにしてもよい。
【０４７１】
例えば、シーン中に、コンテンツオーサなどが意図する重要である3Dオブジェクトと、重要でない3Dオブジェクトとが混在する場合に、その情報には関係なく、Level of detailを下げてしまうと、ユーザがコンテンツオーサなどの意図が反映されたシーンを見ることができない可能性がある。
【０４７２】
そこで、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングすることにより、上述のような場合に、重要な3DオブジェクトのLevel of detailを下げることを抑制することができる。これにより、ユーザは、コンテンツオーサなどの意図が反映されたシーンを見ることができる。
【０４７３】
＜７−１：実施の形態５−１＞
＜重要度(数値)のシグナリング＞
例えば、3Dオブジェクトの重要度のシグナリングとして、各3Dオブジェクトがシーン中でどれぐらい重要であるかを数値で示すようにしてもよい。換言するに、３次元オブジェクトの重要度を示す情報をさらに含むメタデータを生成するようにしてもよい。
【０４７４】
＜７−２：実施の形態５−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、3Dオブジェクトの重要度のシグナリングを行うようにしてもよい。
【０４７５】
＜７−３：実施の形態５−１−１−１＞
＜MPDの拡張＞
各3DオブジェクトのメッシュおよびテクスチャのAdaptationSetに、その3Dオブジェクトの重要度を示す値をシグナリングする。重要度は、例えば値が小さいほど重要であるものとする。もちろん、重要度は、この例に限定されず、例えば、値が大きい程重要であるものとしてもよい。
【０４７６】
より具体的には、第４の実施の形態のSupplementalPropertyのLODGroupに、Important3Dobject attributeを追加し、そのvalue値で重要度情報をシグナリングするようにしてもよい。3DオブジェクトのメッシュのLODGroupとテクスチャのLODGroupは値を同じにしなければならない。以下にその例を示す。
【０４７７】
<LODGroup member="1 3 5" Important3Dobject="1"/>
【０４７８】
この場合のMPDファイル１２２の例を図７６に示す。この場合、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。各AdaptationSetに、重要度情報がImportant3Dobject attributeの値としてシグナリングされている。例えば、3DオブジェクトAは、重要度１、3DオブジェクトBとCは重要度２としている。
【０４７９】
この図７６のMPDファイル１２２において、3DオブジェクトAは、高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、その組合せの中でビットレートを下げても合計ビットレートが伝送帯域より多くなってしまうときは、Level of detailを変更する。その際、SupplementalPropertyを参考に、Important3Dobjectのvalue値の大きなものをまず、全てで１つずつ低いLevel of detailを選択する。つまり、Valueが２である3DオブジェクトBとCのLevel of detailを１つ下げ、3DオブジェクトBは低Level of detail（AdaptationSet@id=11と12）、3DオブジェクトCは低Level of detail（AdaptationSet@id=17と18）になり、その中からビットレートを選択する。それでも、足りない場合は、valueが1である3Dオブジェクトである3DオブジェクトAのLevel of detailを１つ下げ、中Level of detail（AdaptationSet@id=3と4）を選択し、ビットレートを下げる。
【０４８０】
＜変形例＞
この場合、LODGroupに含まれるLevel of Detailが全て同じ重要度となる。Level of Detailによって重要度を変えたい場合（例えば、高Level of detailの場合の重要度は高いが、それ以外の場合の重要度は低くするなど）もある。その場合には、Level of detail毎に値をコンマ区切りで指定すればよい。以下にその例を示す。
【０４８１】
<LODGroup member="1 3 5" Important3Dobject="1,2,2"/>
【０４８２】
また、一部の3Dオブジェクトのみにシグナリングがあってもよい。その場合、値を設定しない。シグナリングがないものは、重要度が存在しない、つまり、重要度が低いものとして扱えばよい。以下にその例を示す。
【０４８３】
<LODGroup member="1 3 5" Important3Dobject="1,,"/>
【０４８４】
その他、実施の形態４−１−１のその他のシグナリング例にあるようなAdaptationSet単位でシグナリングする場合は、Important3Dobject もAdaptationSetでシグナリングするようにしてもよい。その場合、SupplementalPropertyでImportant3Dobjectのみをシグナリングするようにしてもよい。
【０４８５】
また、重要であるか否かを示すだけでも良い。その際、Level of Detail毎に、重要であるか否かを１か０のフラグ情報（flag）で指定することができるようにしてもよい。
【０４８６】
重要度情報は、Level of Detailを切り替える際に利用するだけでなく、Level of detail内のビットレートを選択する際にも利用することができるようにしてもよい。
【０４８７】
＜ビットレート選択処理の流れ＞
クライアント装置１０３は、3Dオブジェクトの重要度で、どのLevel of Detailからビットレートを上げるか下げるかを決定する。たとえば、伝送帯域が足りない場合は、重要度の低いものからLevel of Detailを下げていく。クライアント装置１０３は、第４の実施の形態を適用する場合であってもなくても、この値のみからLevel of Detailの切り替えを制御するようにしてもよい。
【０４８８】
なお、この場合、再生処理は、図６７のフローチャートを参照して説明した場合と同様に実行される。図７７のフローチャートを参照して、この場合の、ステップＳ５２９において実行されるビットレート選択処理の流れの例を説明する。
【０４８９】
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５７１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５７２に進む。
【０４９０】
ステップＳ５７２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyから、Important3Dobjectの最大値を取得し、その最大値を変数ａに設定する。
【０４９１】
ステップＳ５７３において、メディアデータセグメントファイル選択部１８７は、その変数ａが０でないか否かを判定する。変数ａが０（a = 0）であると判定された場合、処理は、ステップＳ５７１に戻り、それ以降の処理が繰り返される。
【０４９２】
つまり、全てのAdaptationSetが最低のLevel of Detailであると判定されるか、または変数ａが０でないと判定されるまで、ステップＳ５７１乃至ステップＳ５７３の処理が繰り返される。そして、ステップＳ５７３において、変数ａが０でないと判定された場合、処理はステップＳ５７４に進む。
【０４９３】
ステップＳ５７４において、メディアデータセグメントファイル選択部１８７は、Improtant3DobjectがaであるLODGroupのAdaptationSetを１つLevel of detailの低いものを選択する。
【０４９４】
ステップＳ５７５において、メディアデータセグメントファイル選択部１８７は、Level of Detailを変更したAdaptationSetのみのビットレートを選択し直して、伝送帯域より小さくすることができるか否かを判定する。ビットレートを伝送帯域より小さくすることができないと判定された場合、処理はステップＳ５７６に進む。
【０４９５】
ステップＳ５７６において、変数aの値が−1される（１で減算される）。ステップＳ５７６の処理が終了すると、処理はステップＳ５７３に戻り、それ以降の処理が繰り返される。
【０４９６】
つまり、変数ａが０であると判定されるか、ビットレートを伝送帯域より小さくすることができると判定されるまで、ステップＳ５７３乃至ステップＳ５７６の処理が繰り返される。そして、ステップＳ５７５において、ビットレートを伝送帯域より小さくすることができると判定された場合、処理はステップＳ５７７に進む。
【０４９７】
ステップＳ５７７において、メディアデータセグメントファイル選択部１８７は、伝送帯域より小さくすることができるRepresentationを選択する。ステップＳ５７７の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
【０４９８】
また、ステップＳ５７１において、全てのAdaptationSetが最低のLevel of Detailであり、Level of Detailを下げる余地がないと判定された場合、処理はステップＳ５７８に進む。
【０４９９】
ステップＳ５７８において、メディアデータセグメントファイル選択部１８７は、選択されているAdaptationSetで最低のビットレートになるように、Representationを選択する。ステップＳ５７８の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
【０５００】
つまり、重要度の低い3DオブジェクトのLevel of detailを１つ下げ、次に重要度の低い3DオブジェクトのLevel of detailを１つ下げる・・・という順に処理を進める。このようにすることにより、コンテンツオーサ等の意図する重要度を反映した再生を行うことができる。
【０５０１】
なお、重要度の低い3DオブジェクトのLevel of detailを下げられるところまで下げて、その後に、次に重要度の低い3DオブジェクトのLevel of detailを下げられるところまで下げる・・・という順で処理を進めるようにしてもよい。
【０５０２】
＜７−４：実施の形態５−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
【０５０３】
＜７−５：実施の形態５−１−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態１−２−１のClientSelectionノード３０１を拡張し、3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。より具体的には、Important3Dobjectを追加するようにしてもよい。重要度は値が小さいほど重要であるとする。しかしながら、フィールドがない場合の初期値でもある0は重要度が設定されていないものとする。もちろん重要度の表現方法は任意であり、この例に限定されない。
【０５０４】
この場合のClientSelectionノード３０１の例を図７８に示す。図７８に示されるように、この場合のClientSelectionノード３０１には、3Dオブジェクトの重要度を設定するImportant3Dobject fieldが追加されている。
【０５０５】
＜７−６：実施の形態５−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、Important3Dobject fieldを拡張するようにしてもよい。図７９にその拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。この場合、Bitwrapperノード１５およびMovieTextureノード１６のそれぞれにおいて、Important3Dobject fieldが追加されている。
【０５０６】
＜変形例＞
なお、3Dオブジェクト毎に重要度が決まる場合にはTransformノード１２を拡張するようにしてもよい。図８０は、その拡張したTransformノード１２の例を示す図である。図８０に示されるように、この場合のTransformノード１２には、Important3Dobject fieldが追加されている。このようにすることにより、シグナリングするノードが少なくなる利点がある。なお、この例では、Transformノード１２を拡張したが、他のノードを新しく規定しても良いし、その他のノード（例えばShapeノード１３等）を拡張するようにしてもよい。
【０５０７】
＜８：第６の実施の形態（実施の形態６）＞
＜ユーザの注目している3DオブジェクトのLevel of detailを保つための実装法＞
さらに、ユーザが注目している3Dオブジェクトを識別して、その3DオブジェクトのLevel of detailを保つことができるようにしてもよい。
【０５０８】
＜８−１：実施の形態６−１＞
＜クライアント装置１０３の実装例＞
伝送帯域が不足する場合、クライアント装置１０３は、以下のルールを適用し、ビットレートを選択するようにしてもよい。換言するに、注目する３次元オブジェクトの重要度を指定する情報をさらに含むメタデータを生成するようにしてもよい。
【０５０９】
（１）ユーザの注目している点を取得する。
（２）その注目している点にある3Dオブジェクトを、Scene Descriptionの位置情報から求める。
（３）注目している3Dオブジェクトを重要度１とする。その他の3Dオブジェクトの重要度は２とする。
（４）そして、第５の実施の形態の場合と同様のアルゴリズムでビットレートを選択する。
【０５１０】
＜ビットレート選択処理の流れ＞
この場合、再生処理は、図６７のフローチャートを参照して説明した場合と同様に実行される。図８１のフローチャートを参照して、この場合の、ステップＳ５２９において実行されるビットレート選択処理の流れの例を説明する。
【０５１１】
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５９１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５９２に進む。
【０５１２】
ステップＳ５９２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyから、Important3Dobjectの最大値を取得し、その最大値を変数ａに設定する。
【０５１３】
ステップＳ５９３において、メディアデータセグメントファイル選択部１８７は、ユーザの位置や視線方向等と、Scene Descriptionデータ１２１に記述されている各3Dオブジェクトの位置情報とから、ユーザが注目している3Dオブジェクトを求める。
【０５１４】
ステップＳ５９４において、メディアデータセグメントファイル選択部１８７は、ステップＳ５９３において検出したユーザが注目している3Dオブジェクトの重要度を１とし、それ以外の3Dオブジェクト、すなわち、ユーザが注目していない3Dオブジェクトの重要度を２とする。さらに、変数a = 2とする。
【０５１５】
ステップＳ５９５乃至ステップＳ６００の各処理は、ステップＳ５７３乃至ステップＳ５７８の各処理（図７７）と同様に実行される。
【０５１６】
ステップＳ５９９またはステップＳ６００の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
【０５１７】
このようにビットレート選択処理を行うことにより、ユーザが注目している3Dオブジェクトを識別し、その3DオブジェクトのLevel of detailを下げないようにすることができる。したがって、ユーザの主観的な6DoFコンテンツの品質の低減を抑制することができる。
【０５１８】
＜変形例＞
なお、注目している3Dオブジェクトの重要度を１、注目されていないが表示されている3Dオブジェクトの重要度を２、それ以外の重要度を３として、表示されていないものからLevel of detailを下げるようにしてもよい。
【０５１９】
また、重要度の割り当てをより細分化して、注目されていないが表示されている3Dオブジェクトを、注目している3Dオブジェクトに近い表示されている3Dオブジェクトと、そうでない3Dオブジェクトとで重要度を変える（それぞれに互いに異なる重要度を割り当てる）ようにしてもよい。
【０５２０】
さらに、注目していない3DオブジェクトのLevel of Detailを最低レベルまで下げた後、注目している3DオブジェクトのLevel of Detailを下げるようにしてもよい。
【０５２１】
また、Level of detail内のビットレート選択の際にも同様に、注目していない3Dオブジェクトからビットレートを下げるようにしてもよい。
【０５２２】
＜９：第７の実施の形態（実施の形態７）＞
＜３D空間内にある１つの物体を複数の部分の３Dオブジェクトで構成する場合のシグナリング＞
第１の実施の形態は、３D空間内に存在する物体ごとに３Dオブジェクトとする場合である。物体が複数の部分の３Dオブジェクトで構成される場合においても、この第１の実施の形態の場合と同様にLevel of detail毎にビットレートアダプテーションすることができるようにしてもよい。
【０５２３】
例えば、図８２のように円柱の物体Aを分割し、３DオブジェクトA1、３DオブジェクトA2、３DオブジェクトA3、および３DオブジェクトA4の４つの部分に分けるとする。この場合、それぞれの３Dオブジェクトがメッシュデータとテクスチャデータで構成される。
【０５２４】
＜９−１：実施の形態７−１＞
＜Scene Descriptionにおいて部分毎の３Dオブジェクトをシグナルする＞
このような全ての部分毎の３DオブジェクトをScene Descriptionにおいてシグナルする。例えば、実施の形態１において説明した手法において、Scene Descriptionで部分毎の３Dオブジェクトをシグナリングする。このようにすることで、実施の形態１において説明した手法と同じ拡張を用いて実施することができる。
【０５２５】
例えば、Scene DescriptionとMPDの構成を用いる実施の形態１−１−１の拡張を適用することができる。図８２に示されるように物体Aを４つの３Ｄオブジェクトにする例について実施の形態１−１−１を適用した場合、Scene Descriptionデータ１２１は、例えば図８３に示されるような構成となる。図８３において、３ＤオブジェクトA2乃至３ＤオブジェクトA4についてLoDノード以下の構成は、３ＤオブジェクトA1の場合と同様であるので、その説明は省略する。
【０５２６】
図８３に示されるように、実施の形態１−１−１の拡張を適用することにより、物体Ａの一部分である３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれを、個別の3Dオブジェクトとしてシグナルすることができる。
【０５２７】
もちろん、実施の形態１−１−１だけでなく、実施の形態１−１以下にある全ての実施の形態（実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−２−１、実施の形態１−１−２−２、実施の形態１−１−３）において説明した各手法も、図８２の例のような、分割されている３Ｄオブジェクトに対して、適用することができる。
【０５２８】
例えば、Scene Descriptionのみを用いる実施の形態１−２−１の拡張を適用してもよい。図８２に示されるように物体Aを４つの３Ｄオブジェクトにする例について実施の形態１−２−１を適用した場合、Scene Descriptionデータ１２１は、例えば図８４に示されるような構成となる。図８４において、３ＤオブジェクトA2乃至３ＤオブジェクトA4についてLoDノード以下の構成は、３ＤオブジェクトA1の場合と同様であるので、その説明は省略する。また、3DオブジェクトA1の中Level of Detail A1MのShapeノード以下の構成は、3DオブジェクトA1の高Level of Detail A1Hの場合と同様であるので、その説明は省略する。同様に、3DオブジェクトA1の低Level of Detail A1LのShapeノード以下の構成も、3DオブジェクトA1の高Level of Detail A1Hの場合と同様であるので、その説明も省略する。
【０５２９】
図８４に示されるように、実施の形態１−２−１の拡張を適用することにより、物体Ａの一部分である３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれを、個別の3Dオブジェクトとしてシグナルすることができる。これにより、３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれに、個別にアクセスすることができる。
【０５３０】
もちろん、実施の形態１−２−１だけでなく、実施の形態１−２以下にある全ての実施の形態（実施の形態１−２−１および実施の形態１−２−２）において説明した各手法も、図８２の例のような、分割されている３Ｄオブジェクトに対して、適用することができる。
【０５３１】
以上のように実施の形態１を適用する手法は、部分毎の３DオブジェクトをScene Descriptionでシグナルし、個別にアクセス可能にする。ただし、この手法の場合は、元々１つの物体であるかどうかまではわからない。
【０５３２】
＜９−２：実施の形態７−２＞
＜Scene Descriptionにおいて、物体全体をシグナルし、その物体が複数の３Dオブジェクトで構成されることをシグナルする＞
そこで、Scene Descriptionにおいて、１つの物体が存在している情報までをシグナルし、さらに、MPDの複数のメッシュデータおよびテクスチャデータへアクセスできるようにシグナルしてもよい。
【０５３３】
例えば、図８５に示されるように、Scene Descriptionデータ１２１において物体Ａ全体の情報のみをシグナルする。そして、その物体ＡのBitwrapperノードおよびMovie textureノードのアクセス情報で、DASHのMPDファイル１２２の複数のメッシュデータまたはテクスチャデータをシグナルし、それらを全て利用することができるようにする。
【０５３４】
＜９−３：実施の形態７−２−１＞
＜部分ごとの３ＤオブジェクトのLevel of DetailごとにAdaptationSetとする場合＞
図１２および図１３に示される例のように、Level of Detail毎にAdaptationSetとする構成によって、複数の３Ｄオブジェクトで構成される物体を表現するようにしてもよい。この場合、物体が複数の３Ｄオブジェクトで構成されることを示すために、Scene DescriptionのBitwrapperノード１５およびMovieTextureノード１６のアクセス情報から複数のAdaptationSetをシグナルする必要がある。
【０５３５】
＜９−４：実施の形態７−２−１−１＞
＜URL queryを拡張し複数のAdaptationSetをシグナルする＞
Scene Descriptionの物体のメッシュデータへのアクセス情報を持つBitwrapperノード、テクスチャデータへのアクセス情報を持つMovieTextureノードから、MPDファイルの複数の部分のメッシュデータまたはテクスチャデータのAdaptationSetへアクセスすることができるように拡張し、それらのAdaptationSetを同時に利用する必要があることを示すようにしてもよい。
【０５３６】
Bitwrapperノード、MovieTextureノードではURLを用いて外部メディアデータへのアクセス情報をシグナルしている。MPEG-4 Scene Description(ISO/IEC 14496-11)のBitwrapperノードおよびMovieTextureノードの構造例は、図２に示した通りである。外部メディアデータへのアクセスに使われるフィールド（field）はどちらのノードもurl fieldである。本実施の形態では、BitwrapperノードおよびMovieTextureノードのsyntaxは拡張せず、それぞれのurl fieldの表記方法を拡張する。
【０５３７】
本実施の形態では、url fieldで示すURLをMPDファイルへのURLに加えてURLパラメータで複数のAdaptationSet@idをシグナリングし、これらを同時に利用しないといけないことを示す。具体的には、例えばAdaptationSetを表すURLパラメータの変数"requiredASList"を用い、その値で物体を構成する部分3DオブジェクトのテクスチャデータもしくはメッシュデータのAdaptationSet@idをセミコロン切りでシグナリングする。例えば、物体Aが、AdaptationSet@id=1、２、３、４から構成される場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
【０５３８】
URLの例：http://www.6dofserver.com/6dof.mpd?requiredASList=1;2;3;4
【０５３９】
＜９−５：実施の形態 ７−２−１−２＞
＜Scene Descriptionのノードを拡張する＞
Scene DescriptionデータのBitwrapperノードやMovieTextureノードに、物体を構成する複数の部分3DオブジェクトのテクスチャデータもしくはメッシュデータのAdaptationSet@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイルへのアクセス情報を記述する。
【０５４０】
例えば、図８６に示されるように、Scene DescriptionデータのBitwrapperノード１５やMovieTextureノード１６に、新しいfieldであるRequiredAdaptationSetIdsを追加し、このfieldで、物体を構成するのに必要なAdaptationSetの@idを文字列の配列として格納する。
【０５４１】
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０５４２】
＜９−６：実施の形態７−２−１−３＞
＜MPD拡張＋URL queryもしくはノード拡張でシグナルする＞
MPDにおいて１つの物体を構成する部分3DオブジェクトのAdaptationSetを識別できるように識別子をシグナルし、その識別子をScene Descriptionからシグナルするようにしてもよい。
【０５４３】
例えば、AdaptationSetにある物体のメッシュデータを示すidをシグナルするようにしてもよい。この場合、テクスチャとメッシュおよびLevel of Detailごとにidを変える。
【０５４４】
例えば、AdaptationSetに、SupplementalProperty descriptionをシグナルし、schemeIdUriで"ObjectPartsId"をシグナルする。これにより、3Dオブジェクトの一部であり、同じvalue値のAdaptationSetで1つの物体を示すことを表す。valueには識別するための値を入れる。
【０５４５】
例：<SupplementalProperty schemeIdUri="ObjectPartsID" value="1">
【０５４６】
さらに、図８７に、物体Ａが４つの部分３Ｄオブジェクトで構成される場合のMPDを示す。この例では、メッシュデータのみを示している。
【０５４７】
＜変形例＞
Periodで物体を構成する部分3Dオブジェクトのグループをシグナルしてもよい。例えば、schmeIdUriでObjectPartsGroupを示すようにする。グルーピング情報は、グループ毎にSupplementalPropertyのエレメント（element）としてOPGを新しく追加する。OPGは、id（ObjectPartsIdのvalueと同じ意味）と、グループに含まれるAdaptationSetのidのリストから成る。
【０５４８】
その例を図８８に示す。図８８は、物体Ａのメッシュデータが４つのAdaptationSetから構成されており、OPGのmemberで４つのAdaptationSet@idが紐づいている。
【０５４９】
＜Scene Descriptionのシグナリング＞
Scene DescriptionのBitwrapperノードやMovieTextureノードのアクセス情報として、MPDのObjectPartsIDの値、もしくは、OPG elementのidの値を示せばよい。
【０５５０】
例えば、BitwrapperノードやMovieTextureノードのUrl fieldで、MPDのURLにURL queryで示す。URLパラメータの変数"ObjectPartId"を用い、その値でMPDのObjectPartsIDもしくは、OPG elementのidを示す。図８７や図８８の例の場合、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
【０５５１】
URLの例：http://www.6dofserver.com/6dof.mpd?ObjectPartId=1
【０５５２】
別のシグナリングとしては、BitwrapperノードやMovieTextureノードにObjectPartIdを示すfiledを追加する手法である。図８９に示されるように、ObjectPartIdを追加し、その値でMPDのObjectPartsIDまたはOPG elementのidを示す。
【０５５３】
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０５５４】
＜９−７：実施の形態７−２−２＞
＜部分毎の３ＤオブジェクトのLevel of Detailに関わらず１つのAdaptationSetとする場合＞
図２１、図２２に示されるように、Level of Detailに関わらず１つのAdaptationSetで同じ部分の３Ｄオブジェクトがシグナルされる構成で、物体が複数の3Dオブジェクトで構成されてもよい。
【０５５５】
この場合、物体Ａが複数の３Ｄオブジェクトで構成されることを示すために、Scene DescriptionのBitwrapperノード、MovieTextureノードのアクセス情報から複数のAdaptationSetとそのAdaptationSetごとに複数のRepresentationをシグナルする必要がある。
【０５５６】
＜９−８：実施の形態７−２−２−１＞
＜URL queryで拡張する＞
SceneDescriptionは物体ごとでシグナルしているため、Scene Descriptionデータのメッシュを示すノードであるBitwrapperノードや、テクスチャを示すノードであるMovieTextureノードから、全ての部分の3DオブジェクトのAdaptationSetと、さらにそれらのAdaptationSetに含まれる、適切なLODのビットレートバリエーションのRepresentationを示す必要がある。
【０５５７】
そこで、Scene DescriptionデータのBitwrapperノードやMovieTextureノードのアクセス情報（例えばURL）を拡張する。
【０５５８】
より具体的には、AdaptationSetとそこに含まれるRepresentationを表すURLパラメータの変数である"requiredASRSList"とその値により全ての部分3DオブジェクトのAdaptationSet@idとその中で利用するRepresentation@idが示されるようにする。
【０５５９】
例えばURLパラメータの変数"requiredASRSList"を用い、その値で物体を構成する部分3Dオブジェクトのテクスチャデータもしくはメッシュデータを示す。値としては、AdaptationSet@idをコロンで区切りそのあとに利用するRepresentation@idをコンマ区切りで示す。さらに複数のAdaptationSetをシグナルするためにセミコロン切りでシグナリングする。例えば、物体Aが、AdaptationSet@id=1、２、３、４から構成され、AdaptationSet@id=1ではRepresentation@id=11,12を利用、AdaptationSet@id=2ではRepresentation@id=21,22を利用、AdaptationSet@id=3ではRepresentation@id=31,32を利用、AdaptationSet@id=4ではRepresentation@id=41,42を利用する場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
【０５６０】
http://www.6dofserver.com/6dof.mpd?requiredASRSList=1:11,12;2:21,22;3:31,32;4:41,42
【０５６１】
＜９−９：実施の形態７−２−２−２＞
＜Scene Descriptionのノードを拡張する＞
Scene DescriptionデータのBitwrapperノードやMovieTextureノードに、物体を構成する複数のAdaptationSet@idとビットレートバリエーションのRepresentation@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイルへのアクセス情報を記述する。
【０５６２】
図９０に示されるように、Scene DescriptionデータのBitwrapperノード１５やMovieTextureノード１６に、requiredASRSList fieldを追加する。fieldの値としては、実施の形態７−２−２−１で利用した構造である、AdaptationSet@idをコロンで区切りそのあとに利用するRepresentation@idをコンマ区切りにした文字列を複数格納する。
【０５６３】
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
【０５６４】
＜９−１０：実施の形態７−２−２−３＞
＜MPD拡張＋URL queryもしくはノード拡張でシグナルする＞
実施の形態１−１−２−２のRepresentationGroupを用いて、Scene Descriptionから複数の部分3Dオブジェクトをシグナルできるように拡張してもよい。
【０５６５】
また、Scene Descriptionデータにおいては、BitwrapperノードおよびMovieTextureノードのアクセス情報（URL）に実施の形態１−１−２−２のRepresentationのグループを複数示すようにする。
【０５６６】
MPDファイルのURLパラメータに、AdaptationSetを示すパラメータと、RepresentationGroupを示すパラメータを複数シグナルする。例えば、URLパラメータをrequiredASRGListとして、値としてAdaptationSet@idとコロンでRepresentationGroupのidを示す。複数部分の3Dオブジェクトを示すために、セミコロンで区切る。以下にそのURLの例を示す。
【０５６７】
URLの例：http://www.6dofserver.com/6dof.mpd?requiredASRGList =1:1;2:1;3:1;4:1
【０５６８】
変形例として、BitwrapperノードやMovieTextureノードを拡張してもよい。実施の形態７−２−２−２の拡張のように、上記のrequiredASRGListをBitwrapperノードやMovieTextureノードとして追加する。
【０５６９】
また、変形例として、実施の形態７−２−１−３のObjectPartIdを、Representationにシグナルしてもよい。この時には、LODごとにidを分ける。このようにすると、実施の形態７−２−１−３と同様のシグナルが可能である。実施の形態７−２−１−３のようにPeriodでシグナルする場合、以下のようなSupplementalPropertyを追加すればよい。OPG elementに新しくOPGmember elementを追加し、それぞれの部分3DオブジェクトのAdaptationSet@idと、ビットレートバリエーションのRepresentation@idをASIdおよびRSIdでシグナルする。
【０５７０】
<SupplementalProperty schemeIdUri="ObjectPartsGoup" >
<OPG id="1">  // 物体Aを構成する部分3Dオブジェクトのメッシュのグループ
<OPGmember ASid="1" RSid="11,12">
<OPGmember ASid="2" RSid="21,22">
<OPGmember ASid="3" RSid="31,32">
<OPGmember ASid="4" RSid="41,42">
</OPG>
<OPG id="2">  // 物体Aを構成する部分3Dオブジェクトのテクスチャのグループ
//略
</SupplementalProperty>
【０５７１】
＜１０．付記＞
＜まとめ＞
以上のように説明した各実施の形態の手法は、適宜、他の実施の形態の手法と組み合わせて用いたり、選択的に併用したりすることができる。
【０５７２】
以上のような本開示を適用することにより、6DoFコンテンツの配信でビットレートアダプテーションができるようになり、伝送帯域が限られる場合に再生が途切れることを抑制することができる。すなわち、コンテンツ再生のロバスト性を向上させることができる。
【０５７３】
また、クライアント装置１０３は、3Dオブジェクト間の相対的な品質を維持したビットレート選択が可能になる。
【０５７４】
さらに、視点位置で決められた3Dオブジェクトの組合せでの最低ビットレートより、さらに低いビットレートになる組み合わせの選択が可能になり、より狭い伝送帯域でも途切れない再生が可能になる。
【０５７５】
また、クライアント装置１０３は、コンテンツオーサなどの意図通りの順に3DオブジェクトのLevel of detailを下げることができ、コンテンツオーサなどの意図が反映されたシーンを表示することができる。
【０５７６】
さらに、帯域が変わる時に、オブジェクト毎のビットレートを上げる(下げる)アルゴリズム選択に有用である。
【０５７７】
また、クライアントは、ユーザの注目している3DオブジェクトのLevel of detailを極力維持して、全体のビットレートを下げることができる。注目している3DオブジェクトのLevel of detailを保つことができる。
【０５７８】
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
【０５７９】
図９１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０５８０】
図９１に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
【０５８１】
バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
【０５８２】
入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
【０５８３】
以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０５８４】
コンピュータ（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
【０５８５】
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
【０５８６】
その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
【０５８７】
＜本技術の適用対象＞
本技術は、任意の画像符号化・復号方式に適用することができる。つまり、上述した本技術と矛盾しない限り、変換（逆変換）、量子化（逆量子化）、符号化（復号）、予測等、画像符号化・復号に関する各種処理の仕様は任意であり、上述した例に限定されない。また、上述した本技術と矛盾しない限り、これらの処理の内の一部を省略してもよい。
【０５８８】
上述した実施の形態に係る画像処理装置、画像符号化装置、および画像復号装置は、例えば、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、およびセルラー通信による端末への配信などにおける送信機や受信機（例えばテレビジョン受像機や携帯電話機）、または、光ディスク、磁気ディスクおよびフラッシュメモリなどの媒体に画像を記録したり、これら記憶媒体から画像を再生したりする装置（例えばハードディスクレコーダやカメラ）などの、様々な電子機器に応用され得る。
【０５８９】
また、本技術は、任意の装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ（例えばビデオプロセッサ）、複数のプロセッサ等を用いるモジュール（例えばビデオモジュール）、複数のモジュール等を用いるユニット（例えばビデオユニット）、ユニットにさらにその他の機能を付加したセット（例えばビデオセット）等（すなわち、装置の一部の構成）として実施することもできる。
【０５９０】
さらに、本技術は、複数の装置により構成されるネットワークシステムにも適用することもできる。例えば、コンピュータ、AV（Audio Visual）機器、携帯型情報処理端末、IoT（Internet of Things）デバイス等の任意の端末に対して、画像（動画像）に関するサービスを提供するクラウドサービスに適用することもできる。
【０５９１】
なお、本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。また、その用途も任意である。
【０５９２】
例えば、本技術は、観賞用コンテンツ等の提供の用に供されるシステムやデバイスに適用することができる。また、例えば、本技術は、交通状況の監理や自動運転制御等、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、機械等の自動制御の用に供されるシステムやデバイスに適用することができる。さらに、例えば、本技術は、農業や畜産業の用に供されるシステムやデバイスにも適用することができる。また、本技術は、例えば火山、森林、海洋等の自然の状態や野生生物等を監視するシステムやデバイスにも適用することができる。さらに、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。
【０５９３】
＜その他＞
なお、本明細書において「フラグ」とは、複数の状態を識別するための情報であり、真(1)または偽(0)の２状態を識別する際に用いる情報だけでなく、３以上の状態を識別することが可能な情報も含まれる。したがって、この「フラグ」が取り得る値は、例えば1/0の２値であってもよいし、３値以上であってもよい。すなわち、この「フラグ」を構成するbit数は任意であり、1bitでも複数bitでもよい。また、識別情報（フラグも含む）は、その識別情報をビットストリームに含める形だけでなく、ある基準となる情報に対する識別情報の差分情報をビットストリームに含める形も想定されるため、本明細書においては、「フラグ」や「識別情報」は、その情報だけではなく、基準となる情報に対する差分情報も包含する。
【０５９４】
また、符号化データ（ビットストリーム）に関する各種情報（メタデータ等）は、符号化データに関連づけられていれば、どのような形態で伝送または記録されるようにしてもよい。ここで、「関連付ける」という用語は、例えば、一方のデータを処理する際に他方のデータを利用し得る（リンクさせ得る）ようにすることを意味する。つまり、互いに関連付けられたデータは、１つのデータとしてまとめられてもよいし、それぞれ個別のデータとしてもよい。例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の伝送路上で伝送されるようにしてもよい。また、例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の記録媒体（または同一の記録媒体の別の記録エリア）に記録されるようにしてもよい。なお、この「関連付け」は、データ全体でなく、データの一部であってもよい。例えば、画像とその画像に対応する情報とが、複数フレーム、１フレーム、またはフレーム内の一部分などの任意の単位で互いに関連付けられるようにしてもよい。
【０５９５】
なお、本明細書において、「合成する」、「多重化する」、「付加する」、「一体化する」、「含める」、「格納する」、「入れ込む」、「差し込む」、「挿入する」等の用語は、例えば符号化データとメタデータとを１つのデータにまとめるといった、複数の物を１つにまとめることを意味し、上述の「関連付ける」の１つの方法を意味する。
【０５９６】
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０５９７】
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０５９８】
なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、および、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０５９９】
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０６００】
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
【０６０１】
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
【０６０２】
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
【０６０３】
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
【０６０４】
なお、本技術は以下のような構成も取ることができる。
（１）  ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部
を備える情報処理装置。
（２）  前記生成部は、前記情報として、前記コンテンツの再生を制御する制御ファイルのアクセス情報を含む前記メタデータを生成する
（１）に記載の情報処理装置。
（３）  前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含む前記メタデータを生成する
（２）に記載の情報処理装置。
（４）  前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトに対応するAdaptationSetの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含む前記メタデータを生成する
（２）または（３）に記載の情報処理装置。
（５）  前記生成部は、所望の前記MPDのアクセス情報、前記MPD内の所望のAdaptationSetを指定する情報、および前記AdaptationSet内の所望のRepresentationを指定する情報からなる前記アクセス情報を含む前記メタデータを生成する
（４）に記載の情報処理装置。
（６）  前記生成部は、さらに、互いに同一のビットレートバリエーションをグループ化する情報を含む前記MPDを生成する
（４）または（５）に記載の情報処理装置。
（７）  前記生成部は、さらに、前記メタデータへのアクセス情報を含まない前記MPDを生成する
（２）乃至（６）のいずれかに記載の情報処理装置。
（８）  前記メタデータは、前記コンテンツの、視点位置に基づく空間表示制御情報であり、
前記生成部は、前記コンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する前記視点位置に基づく空間表示制御情報を生成する
（１）乃至（７）のいずれかに記載の情報処理装置。
（９）  前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む前記視点位置に基づく空間表示制御情報を生成する
（８）に記載の情報処理装置。
（１０）  前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む前記視点位置に基づく空間表示制御情報を生成する
（８）または（９）に記載の情報処理装置。
（１１）  前記生成部は、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）  前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報をさらに含む前記メタデータを生成する
（１）乃至（１１）のいずれかに記載の情報処理装置。
（１３）  前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含む前記メタデータを生成する
（１２）に記載の情報処理装置。
（１４）  前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含む前記メタデータを生成する
（１２）または（１３）に記載の情報処理装置。
（１５）  前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な前記３次元オブジェクトの各ビットレートバリエーションを示す情報を含む前記メタデータを生成する
（１２）乃至（１４）のいずれかに記載の情報処理装置。
（１６）  前記生成部は、前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１５）のいずれかに記載の情報処理装置。
（１７）  前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報に基づいて前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１６）のいずれかに記載の情報処理装置。
（１８）  前記生成部は、前記３次元オブジェクトの重要度を示す情報をさらに含む前記メタデータを生成する
（１）乃至（１７）のいずれかに記載の情報処理装置。
（１９）  前記生成部は、注目する３次元オブジェクトの重要度を指定する情報をさらに含む前記メタデータを生成する
（１）乃至（１８）のいずれかに記載の情報処理装置。
（２０）  ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する
情報処理方法。
【符号の説明】
【０６０５】
１００  配信システム，  １０１  ファイル生成装置，  １０２  配信サーバ，  １０３  クライアント装置，  １５１  制御部，  １５２  ファイル生成部，  １６１  データ入力部，  １６２  Scene Description生成部，  １６３  メディアデータ生成部，  １６４  MPDファイル生成部，  １６５  セグメントファイル生成部，  １６６  記録部，  １６７  アップロード部，  １７１  制御部，  １７２  再生処理部,  １８１  MPDファイル取得部，  １８２  MPDファイル処理部，  １８３  Secene Descriptionセグメントファイル取得部，  １８４  Scene Descriptionセグメントファイル処理部，  １８５  表示制御部，  １８６  計測部，  １８７  メディアデータセグメントファイル選択部，  １８８  メディアデータセグメントファイル取得部，  １８９  復号処理部、  １９０  表示情報生成部，  １９１  表示部
【図１】
2020116154.tif 000003
【図２】
2020116154.tif 000004
【図３】
2020116154.tif 000005
【図４】
2020116154.tif 000006
【図５】
2020116154.tif 000007
【図６】
2020116154.tif 000008
【図７】
2020116154.tif 000009
【図８】
2020116154.tif 000010
【図９】
2020116154.tif 000011
【図１０】
2020116154.tif 000012
【図１１】
2020116154.tif 000013
【図１２】
2020116154.tif 000014
【図１３】
2020116154.tif 000015
【図１４】
2020116154.tif 000016
【図１５】
2020116154.tif 000017
【図１６】
2020116154.tif 000018
【図１７】
2020116154.tif 000019
【図１８】
2020116154.tif 000020
【図１９】
2020116154.tif 000021
【図２０】
2020116154.tif 000022
【図２１】
2020116154.tif 000023
【図２２】
2020116154.tif 000024
【図２３】
2020116154.tif 000025
【図２４】
2020116154.tif 000026
【図２５】
2020116154.tif 000027
【図２６】
2020116154.tif 000028
【図２７】
2020116154.tif 000029
【図２８】
2020116154.tif 000030
【図２９】
2020116154.tif 000031
【図３０】
2020116154.tif 000032
【図３１】
2020116154.tif 000033
【図３２】
2020116154.tif 000034
【図３３】
2020116154.tif 000035
【図３４】
2020116154.tif 000036
【図３５】
2020116154.tif 000037
【図３６】
2020116154.tif 000038
【図３７】
2020116154.tif 000039
【図３８】
2020116154.tif 000040
【図３９】
2020116154.tif 000041
【図４０】
2020116154.tif 000042
【図４１】
2020116154.tif 000043
【図４２】
2020116154.tif 000044
【図４３】
2020116154.tif 000045
【図４４】
2020116154.tif 000046
【図４５】
2020116154.tif 000047
【図４６】
2020116154.tif 000048
【図４７】
2020116154.tif 000049
【図４８】
2020116154.tif 000050
【図４９】
2020116154.tif 000051
【図５０】
2020116154.tif 000052
【図５１】
2020116154.tif 000053
【図５２】
2020116154.tif 000054
【図５３】
2020116154.tif 000055
【図５４】
2020116154.tif 000056
【図５５】
2020116154.tif 000057
【図５６】
2020116154.tif 000058
【図５７】
2020116154.tif 000059
【図５８】
2020116154.tif 000060
【図５９】
2020116154.tif 000061
【図６０】
2020116154.tif 000062
【図６１】
2020116154.tif 000063
【図６２】
2020116154.tif 000064
【図６３】
2020116154.tif 000065
【図６４】
2020116154.tif 000066
【図６５】
2020116154.tif 000067
【図６６】
2020116154.tif 000068
【図６７】
2020116154.tif 000069
【図６８】
2020116154.tif 000070
【図６９】
2020116154.tif 000071
【図７０】
2020116154.tif 000072
【図７１】
2020116154.tif 000073
【図７２】
2020116154.tif 000074
【図７３】
2020116154.tif 000075
【図７４】
2020116154.tif 000076
【図７５】
2020116154.tif 000077
【図７６】
2020116154.tif 000078
【図７７】
2020116154.tif 000079
【図７８】
2020116154.tif 000080
【図７９】
2020116154.tif 000081
【図８０】
2020116154.tif 000082
【図８１】
2020116154.tif 000083
【図８２】
2020116154.tif 000084
【図８３】
2020116154.tif 000085
【図８４】
2020116154.tif 000086
【図８５】
2020116154.tif 000087
【図８６】
2020116154.tif 000088
【図８７】
2020116154.tif 000089
【図８８】
2020116154.tif 000090
【図８９】
2020116154.tif 000091
【図９０】
2020116154.tif 000092
【図９１】
2020116154.tif 000093
【国際調査報告】
2020116154.tif 000094
2020116154.tif 000095
2020116154.tif 000096
2020116154.tif 000097