(57)【要約】  本開示は、時間情報を持たないPoint Cloudの再生に対応することができるようにする情報処理装置および情報処理方法に関する。Point Cloudの１フレーム分がV-PCCまたはG-PCCで符号化された符号化データを再生するのに必要な再生情報、および、符号化データの再生の可否を判断するのに用いられる再生可否情報を含むメタデータを生成し、符号化データおよびメタデータを、所定のISOBMFFの技術を利用したファイル構造のファイルに格納する。本技術は、例えば、時間情報を持たないPoint Cloudの符号化データを格納するファイルを生成するデータ生成装置に適用できる。
2020137854.tif 000002
【特許請求の範囲】
【請求項１】
時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
前記ビットストリームおよび前記メタデータを格納したファイルを生成するファイル生成部と
を備える情報処理装置。
【請求項２】
前記再生情報には、前記ビットストリームを構成するVideo data unitに対し、再生時に用いる前記Video data unitの組み合わせを示す組み合わせ情報が含まれる
請求項１に記載の情報処理装置。
【請求項３】
前記再生可否判断情報には、前記ビットストリームのパラメータセットが含まれる
請求項２に記載の情報処理装置。
【請求項４】
前記再生可否判断情報には、さらに、前記Video data unitごとに対応するSub-Sampleのパラメータセットが含まれる
請求項３に記載の情報処理装置。
【請求項５】
前記ファイル生成部は、前記再生可否判断情報を、Item Propertyに格納する
請求項４に記載の情報処理装置。
【請求項６】
前記ファイル生成部は、前記再生可否判断情報に含まれるパラメータセットのうち、前記Video data unitごとのProfile情報を、Item Propertyに格納する
請求項４に記載の情報処理装置。
【請求項７】
前記メタデータ生成部は、Attributeデータを選択して再生をするための前記メタデータを生成する
請求項１に記載の情報処理装置。
【請求項８】
1itemである場合において前記メタデータはSubSampleItemPropertyであり、multi itemにすることで選択再生を可能にする
請求項７に記載の情報処理装置。
【請求項９】
前記メタデータ生成部は、再生の組合せを示す前記メタデータを生成する
請求項７に記載の情報処理装置。
【請求項１０】
情報処理装置が、
時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
を含む情報処理方法。
【請求項１１】
時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
前記ビットストリームおよび前記メタデータを、格納したファイルを生成するファイル生成部と
を備える情報処理装置。
【請求項１２】
前記再生情報には、再生時に用いる前記ビットストリームの組み合わせを示すビットストリーム組み合わせ情報と、再生の起点を示す再生起点情報とを含む
請求項１１に記載の情報処理装置。
【請求項１３】
前記再生起点情報は、最初に再生すべきビットストリームを示すitem_idである
請求項１２に記載の情報処理装置。
【請求項１４】
前記再生情報は、更に、前記ビットストリームから前記３Ｄデータを再構成するための情報として、各前記ビットストリームのTypeを識別する情報であるV-PCC Unit Headerを含む
請求項１２に記載の情報処理装置。
【請求項１５】
前記再生可否判断情報は、各前記ビットストリームが前記３Ｄデータを構成するデータの一部であることを示す情報を含み、
前記ファイル生成部は、前記再生可否判断情報をItem Propertyに格納する
請求項１４に記載の情報処理装置。
【請求項１６】
前記再生可否判断情報には、更に、各前記ビットストリームが前記３Ｄデータの構成であるとして処理できるか否かの処理を行うことを示す処理判断情報を含む
請求項１５に記載の情報処理装置。
【請求項１７】
前記再生可否判断情報には、item単体で表示不可である判断を可能にする判断情報として、さらに、hidden imageであることを示す情報を含み、
前記ファイル生成部は、前記hidden imageを示す情報を、ItemInfoEntryに格納する
請求項１５に記載の情報処理装置。
【請求項１８】
情報処理装置が、
時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および情報処理方法に関し、特に、時間情報を持たないPoint Cloudの再生に対応することができるようにした情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
従来、非特許文献１および２で開示されているように、３次元空間上に位置情報および属性情報（特に色情報）を同時に持った点の集合であるPoint Cloudの圧縮方法が規定されている。【０００３】
例えば、Point Cloudの圧縮方法の一つとして、Point Cloudを複数の領域に分割（以下、セグメンテーションと称する）し、領域毎に平面投影してtexture画像およびgeometry画像を生成した後、それらを動画像コーデックにより符号化する方法である。ここで、geometry画像は、Point Cloudを構成する点群のdepth情報から構成される画像である。この方法は、V-PCC（Video-based Point Cloud Coding）と称されており、その詳細は非特許文献１に記載されている。【０００４】
また、もう一つの圧縮方法として、Point Cloudを、３次元形状を示すgeometryと、属性情報として色や反射情報などを示すattributeとに分離して、それらを符号化する方法がある。この方法は、G-PCC（Geometry based Point Cloud Coding）と称されている。【０００５】
そして、これらの符号化によって生成されたV-PCC streamまたはG-PCC streamを、ダウンロード再生したり、over IP（Internet Protocol） networkで配信したりするユースケースが期待されている。【０００６】
そこで、非特許文献３で開示されているように、既存の配信プラットフォームへのインパクトを抑制し、早期のサービス実現を目指すべく、MPEG（Moving Picture Experts Group）において、既存の枠組みであるISOBMFF/DASH（ISO Base Media File Format / Dynamic Adaptive Streaming over HTTP）による配信技術についての検討が開始された。【０００７】
また、非特許文献４には、ISOBMFFの技術を利用したファイル構造のファイルにV-PCC streamを格納する格納方法に関する手法が開示されている。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】m45183 second working draft for Video-based Point Cloud Coding (V-PCC).
【非特許文献２】m45183 working draft for Geometry-based Point Cloud Coding (G-PCC).
【非特許文献３】w17675, First idea on Systems technologies for Point Cloud Coding, April 2018, San Diego, US
【非特許文献４】w18059, Working Draft of Storage of V-PCC in ISOBMFF Files
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、従来、動画像のように、所定の時間間隔の複数のフレームからなるPoint CloudをV-PCCまたはG-PCCで符号化することによって生成されたV-PCC streamまたはG-PCC streamを、ISOBMFFの技術を利用したファイル構造のファイルに格納するようなユースケースで用いられていた。これに対し、例えば、地図データのように、時間情報を持たないPoint Cloud（即ち、１フレーム分のPoint Cloud）をV-PCCまたはG-PCCで符号化したものを、ISOBMFFの技術を利用したファイル構造のファイルに格納するようなユースケースが必要になることが想定され、そのユースケースに対応することが求められている。【００１０】
本開示は、このような状況に鑑みてなされたものであり、時間情報を持たないPoint Cloudの再生に対応することができるようにするものである。
【課題を解決するための手段】
【００１１】
本開示の第１の側面の装置は、時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、前記ビットストリームおよび前記メタデータを格納したファイルを生成するファイル生成部とを備える。【００１２】
本開示の第１の側面の情報処理方法は、時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、前記ビットストリームおよび前記メタデータを格納したファイルを生成することとを含む。【００１３】
本開示の第１の側面においては、時間情報を持たない３Ｄデータのから生成されたビットストリームを再生するのに必要な再生情報、および、そのビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータが生成され、ビットストリームおよびメタデータが格納されたファイルが生成される。【００１４】
本開示の第２の側面の装置は、時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、前記ビットストリームおよび前記メタデータを、格納したファイルを生成するファイル生成部とを備える。【００１５】
本開示の第２の側面の情報処理方法は時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、前記ビットストリームおよび前記メタデータを格納したファイルを生成することとを含む。【００１６】
本開示の第２の側面においては、時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、そのビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータが生成され、ビットストリームおよびメタデータを格納したファイルが生成される。
【図面の簡単な説明】
【００１７】
【図１】V-PCCを用いたPoint Cloudの圧縮方法を説明する図である。
【図２】V-PCC streamの構造の一例を示す図である。
【図３】V-PCC動画像フォーマットのファイル構造の一例を示す図である。
【図４】V-PCC静止画streamの構造の一例を示す図である。
【図５】G-PCC streamの構造の一例を示す図である。
【図６】V-PCC静止画フォーマット（1item版）のファイル構成の一例を示す図である。
【図７】VPCCConfigurationBox(‘vpcC’)の構造の一例を示す図である。
【図８】V-PCC静止画streamの再生処理を説明するフローチャートである。
【図９】図８のステップＳ１１におけるmeta Box処理を説明するフローチャートである。
【図１０】V-PCC静止画フォーマット（1item版）のItemProperty(‘sube’)のファイル構成の一例を示す図である。
【図１１】ItemProperty(‘sube’)の構造の一例を示す図である。
【図１２】data_typeの定義の一例を示す図である。
【図１３】attribute_typeの定義の一例を示す図である。
【図１４】ItemPropertyの構造を用いたシグナリングの一例を示す図である。
【図１５】V-PCC静止画streamのファイル構成（multi item版）の一例を示す図である。
【図１６】V-PCC静止画stream(multi item)の再生処理を説明するフローチャートである。
【図１７】拡張されたPrimaryItemBoxの一例を示す図である。
【図１８】PrimaryGroupBoxの一例を示す図である。
【図１９】ItemPropertyのシンタックスの一例を示す図である。
【図２０】図１９のシンタックスを利用したファイル構成の一例を示す図である。
【図２１】ItemProperty(‘vrps’)のシンタックスの一例を示す図である。
【図２２】図２１のシンタックスを利用したItemPropertyの構造の一例を示す図である。
【図２３】vpcc_unit_headerをシグナリングするItemProperty(‘vuhd’)の一例を示す図である。
【図２４】vpccParameterSetProperty(‘vpss’)のシンタックスの一例を示す図である。
【図２５】図２４のシンタックスを利用したファイル構成の一例を示す図である。
【図２６】ItemProerty(‘frma’)の一例を示す図である。
【図２７】ItemProperty(‘schm’)の一例を示す図である。
【図２８】Restricted schemeを用いたファイル構成の一例を示す図である。
【図２９】Restricted schemeを用いたシグナリングの一例を示す図である。
【図３０】G-PCC静止画streamのファイル構成の一例を示す図である。
【図３１】GPCCConfigurationBox(‘gpcC’)の構造の一例を示す図である。
【図３２】既存規格のSubSampleItemProperty (‘subs’)の一例を示す図である。
【図３３】codec_specific_parametersの定義の一例を示す図である。
【図３４】data_typeの定義の一例を示す図である。
【図３５】attribute_typeの定義の一例を示す図である。
【図３６】GPCCMultiItemPropertyの構造の一例を示す図である。
【図３７】EntityToGroupBoxを起点としたG-PCC multi itemの一例を示す図である。
【図３８】Item_idを起点としたG-PCC multi itemの一例を示す図である。
【図３９】Attributeの組合せシグナリングの一例を示す図である。
【図４０】データ生成装置の一例を示すブロック図である。
【図４１】データ再生装置の一例を示すブロック図である。
【図４２】V-PCC静止画streamが格納されたファイルを生成するファイル生成処理を説明するフローチャートである。
【図４３】G-PCC静止画streamが格納されたファイルを生成するファイル生成処理を説明するフローチャートである。
【図４４】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００１８】
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００１９】
＜従来のV-PCCおよびG-PCC＞
まず、従来のV-PCCおよびG-PCCについて説明する。
【００２０】
例えば、３次元形状を表すPoint Cloudで表現されるデータ（以下、３Ｄデータとも称する）の１つとして地図データがあり、地図データは、時間によって形状が変わるようなオブジェクトと異なって変形することがなく、時間情報を持たないということができる。そこで、地図データのように時間情報を持たないPoint Cloud（即ち、Point Cloudでの１フレーム分に該当する1PCサンプル）を、V-PCCまたはG-PCCを用いて符号化するようなユースケースが想定される。なお、以下の説明では、時間情報を持たないPoint CloudをV-PCCで符号化した符号化データをV-PCC静止画データと称し、時間情報を持たないPoint CloudをG-PCCで符号化した符号化データをG-PCC静止画データと称する。
【００２１】
例えば、従来、時間情報を持たないデータをISOBMFFの技術を利用したファイル構造のファイルに格納する規格として、ISO/IEC 23008-12 MPEG-H Image File Format（以下、HEIFと称する）がある。一方、２次元画像を、例えば、AVC（Advanced Video Coding）やHEVC（High Efficiency Video Coding）などの動画像コーデックで符号化し、時間情報を持たない２次元画像データとしてISOBMFFを利用したファイル構造のファイルに格納することも可能である。
【００２２】
従って、V-PCC静止画データおよびG-PCC静止画データを、動画像コーデックを用いて圧縮した時間情報を持たない２次元画像データと同様に見なしてISOBMFFに格納することは、例えば、HEIFを拡張することにより実現する可能性が高い。
【００２３】
図１乃至図４を参照して、V-PCCについて説明する。
【００２４】
図１は、上述した非特許文献１で開示されているV-PCCを用いたPoint Cloudの圧縮方法を、簡略的に説明するための図である。
【００２５】
図１に示すように、まず、３次元構造を表すPoint Cloudが入力され、そのPoint Cloudがセグメンテーションされる。図１に示す例では、半球形状と円錐形状とが組み合わされた３次元構造を表すPoint Cloudが入力され、半球形状を１領域に、円錐形状を２領域に分割した３つの領域にセグメンテーションが行われる。
【００２６】
次に、領域ごとに平面投影が行われ、それぞれの領域の表面の見た目を表す色情報からなるtexture画像、および、それぞれの領域の表面までの奥行（depth）を表す位置情報からなるgeometry画像が生成される。そして、texture画像およびgeometry画像が、例えば、AVCやHEVCなどの動画像コーデックで符号化される。
【００２７】
図２には、上述した非特許文献１で開示されているV-PCCで符号化された従来のstream構造が示されている。このようなstreamは、V-PCC streamと称される。
【００２８】
図２に示すように、V-PCC streamは1 streamで構成されており、複数のV-PCC unitから構成される。また、V-PCC unitは、V-PCC Unit headerおよびV-PCC Unit payloadで構成される。
【００２９】
例えば、V-PCC Unit headerは、V-PCC unit payloadに含まれるDataの種類を示すunit typeと、unit typeごとの追加情報（例えば、attributeのtypeや、どのPoint Cloud frameの情報であるか）とが示される。ここで、Point Cloud frame（以下、PC frameとも称する）は、同時刻に表示されるPoint Cloudのことである。
【００３０】
また、V-PCC Unit payloadには、図示するように、Video unit，Auxiliary information unit、およびParameter Setにより構成される。Attribute video data unitには、符号化されたtexture画像が格納され、geometry video data unitには、符号化されたgeometry画像が格納される。auxiliary information data unitおよびoccupancy video data unitには、2D3D変換に用いる３次元情報メタデータが格納される。各Parameter Setには、各data unit のメタデータや、Sequenceで共通のメタデータ、Frameで共通のメタデータなどが格納される。
【００３１】
例えば、クライアントは、PC stream内のgeometry video data、textureのattribute video data、および、occupancy dataデコードし、デコードしたoccupancy dataを用いてgeometryパッチとtextureパッチとを生成する。その後、クライアントは、auxiliary information dataを用いて、まずはgeometryパッチから色のないPoint Cloudを生成し、続いて、そのPoint Cloudに対してtextureパッチにより色を付ける。
【００３２】
また、上述の非特許文献４において、既存の動画像コーデックを用いるgeometry video data，attribute video data（非特許文献４ではtextureと記載）、およびoccupancy video dataを独立したvideo trackとして取り扱い、その他のparameter setやauxiliary information dataなどを、metadata trackとして格納する手法が開示されている。
【００３３】
そして、この手法では、例えば、図３のV-PCC動画像フォーマットのファイル構造に示すように、V-PCC streamを構成するtrackを示すためにEntityToGroupBox(‘vpcg’)を利用している。即ち、EntityToGroupBox(‘vpcg’)には、PCC metadata，geometry，texture(attribute)、およびoccupancyのtrack_idがシグナリングされており、再生の起点となる情報である。
【００３４】
ここで、V-PCC静止画データのV-PCC stream構成について検討する。
【００３５】
一般的に、動画像の場合、V-PCC streamは、特定の時間幅で連続的に表示される複数のPC frameが含まれる構成となる。これに対し、V-PCC静止画データの場合、１つのPC frameのみで十分であって時間情報が必要とならないため、V-PCC streamは、１つのPC Frameのみが含まれる構成となる。
【００３６】
例えば、図４に示すようなV-PCC静止画データのV-PCC streamを、V-PCC静止画streamと称し、そのフォーマットをV-PCC静止画フォーマットと称する。
【００３７】
上述した非特許文献４では、動画像であるV-PCC streamをISOBMFFの技術を利用したファイル構造のファイルに格納する格納方法が提案されており、V-PCC静止画streamの格納方法に関しては記載も示唆もされていない。そこで、以下で説明するように、V-PCC静止画streamを、HEIFを用いて格納する方法を新たに提案する。
【００３８】
図５を参照して、G-PCCについて説明する。
【００３９】
図５には、上述した非特許文献２で開示されているG-PCCで符号化された従来のstream構造が示されている。このようなstreamは、G-PCC stream（または、単にPC stream）と称される。
【００４０】
例えば、G-PCC streamは、1 streamで構成されており、デコード順に並んだpoint cloud frameの連続である。ここで、point cloud frame（以下、PC frameとも記載する）とは、同時刻に表示されるPoint Cloudのことである。PC frameは、３次元情報を示すgeometry bitstream（図５に示すGeom）と、色や反射といった属性情報を示すattribute bitstream（図５に示すAttr）から構成される連続する１つのbitstreamである。
【００４１】
なお、１つのPC frameは、１つのgeometry bitstreamと複数のattribute bitstream（図５の例では、２つのattribute bitstream）とを有する。また、SPS（Sequence Parameter Set）には、geometry bitstreamおよびattribute bitstreamのデコードに必要な共通情報として、G-PCC streamのシーケンスごとのメタ情報が格納されている。そして、GPS（Geometry Parameter Set）には、geometry bitstreamのデコードに必要な情報が格納されており、APS（Attribute Parameter Set）には、attribute bitstreamのデコードに必要な情報が格納されている。
【００４２】
そして、クライアントは、G-PCC stream内のgeometry bitstreamおよびattribute bitstreamを、それぞれ個別のデコーダでデコードする。まず、クライアントは、geometry bitstreamをデコードし、色のないPoint Cloudを生成する。その後、クライアントは、デコードされたgeometry bitstreamの情報を参照した上でattribute bitstreamをデコードし、その情報に基づいて色や反射といった属性を付加する。
【００４３】
ここで、G-PCC静止画データのG-PCC stream構成について検討する。動画像の場合、G-PCC streamは、特定の時間幅で連続的に表示される複数のPC frameが含まれる構成になる。これに対し、G-PCC静止画データの場合、１つのPC frameのみで十分であって時間情報は必要とならないため、G-PCC streamは、１つのPC Frameのみが含まれる構成になる。以下、G-PCC静止画データのG-PCC streamを、G-PCC静止画streamと称し、そのフォーマットをG-PCC静止画フォーマットと称する。
【００４４】
そして、以下で説明するように、G-PCC静止画streamを、HEIFを用いて格納する方法を新たに提案する。
【００４５】
ところで、V-PCC streamおよびG-PCC streamのユースケースとして、色付きのPoint Cloudを再生するという一般的なユースケースの他に、色や反射といった属性情報が不要で、Point Cloudの３次元形状情報だけを利用するユースケースがある。具体的には、LiDAR（Light Detection and Ranging）およびカメラで取得した色付きの地図情報をPoint Cloudとして保持し、その中の地形情報（即ち、３次元形状情報）のみを抽出して自動車の運転制御などに利用するユースケースが考えられる。
【００４６】
また、色や反射といった属性情報が複数ついている場合には、例えば、プレビュー用にはgeometryとともに、反射の属性を利用せずに、色の属性だけ利用したいユースケースがある。また、複数の属性がある場合には、それらのうちの１つの属性だけ利用するなど、１つのattributeのみ抽出して利用したいユースケースもある。
【００４７】
しかしながら、例えば、V-PCC静止画フォーマット（1item版）およびG-PCC静止画フォーマットは、geometryと複数のattributeとを含めて１つのImage dataとして扱う必要があり、明示的な境界情報が存在しない。このため、これらのユースケースにおいて、クライアントは、geometryおよびattributeを全て取得した上で、ストリームの先頭から順に全てをデコードする必要がある。即ち、複数のattributeのうち、利用するattributeだけでなく、利用しないattributeもデコードすることになってしまい、処理効率が低下することになる。
【００４８】
従って、これらのユースケースにおいて、例えば、利用しないattributeをデコードすることを回避して、処理効率の低下を抑制することが求められる。
【００４９】
＜V-PCC静止画フォーマット＞
ここで、V-PCC静止画streamをHEIFに格納する方法を、V-PCC静止画フォーマット（1item版）と、V-PCC静止画フォーマット（multi item版）とに分けて定義する。
【００５０】
まず、図６乃至１４を参照して、V-PCC静止画フォーマット（1item版）について説明する。
【００５１】
上述した図２に示したように、V-PCC静止画streamは、V-PCC unitで構成される。さらに、V-PCC unitは、再生可否判断およびデコードおよびレンダリングに利用するメタデータであるParameter Setや、符号化データであるData unitなどから構成される。
【００５２】
従来、HEIFでは、動画像コーデックであるHEVCを用いてエンコードした画像をISOBMFFの技術を利用したファイル構造のファイルへ格納する際には、HEVC streamをitemとして格納する。そして、itemとして格納するために、HEVC streamであることを示すitem_typeを定義している。さらに、HEVC stream中で再生可否判断およびデコードまたはレンダリングに利用するメタデータをItem Propertyとして格納し、HEVC stream中の符号化データをImage dataとして格納している。
【００５３】
そこで、V-PCC静止画stremをHEIFに格納する場合も、このような基本的な考え方に基づいて格納することを提案する。具体的には、V-PCC静止画streamであることを示すitem_typeを定義し、Parameter SetをItem Propertyとして格納し、Data unitをImage dataとして格納することができる。
【００５４】
図６には、V-PCC静止画フォーマット（1item版）の具体的なファイル構成が示されている。
【００５５】
まず、ItemInfoEntry(‘infe’)で、Itemのtypeを指定している。図６に示す例では、item_type=’vpc1’とすることで、V-PCCを示すcodingnameを指定している。また、Parameter Setは、Item Propertyで’vpcC’としてシグナリングし、例えば、図７で示すような構造である。また、Image dataは、各種のData unitに格納されている。
【００５６】
図８および図９には、図６に示したV-PCC静止画フォーマット（1item版）のファイルを再生する再生処理を説明するフローチャートが示されている。なお、図８および図９に示す再生処理は、後述する図４１のデータ解析・復号部５３において実行され、データ解析・復号部５３は、ファイル解析部５５、復号部５６、および表示情報生成部５７を有している。
【００５７】
ステップＳ１１において、ファイル解析部５５は、Imageファイル処理を実行して再生データを取得して、復号部５６に供給する。
【００５８】
ここで、ファイル解析部５５は、Imageファイル処理として図示するようなmeta Box処理を実行し、ステップＳ２１においてmeta Box(‘meta’)を取得する。そして、ファイル解析部５５は、図９を参照して後述するように、ステップＳ２２で第１の再生可否判断処理、ステップＳ２３で再生Item決定処理、ステップＳ２４で第２の再生可否判断処理、ステップＳ２５で第３の再生可否判断処理、ステップＳ２６で再生データ取得処理を行う。
【００５９】
ステップＳ１２において、復号部５６は、デコード処理を実行して、ステップＳ１１でファイル解析部５５から供給された再生データをデコードする。例えば、復号部５６は、ステップＳ２５の第３の再生可否判断処理で取得されるProperty（後述するステップＳ４０参照）でデコードに必要な’vpcC’のPropertyと、ステップＳ２６の再生データ取得処理で取得されるデータ（後述するステップＳ４３参照）とを用いて、デコード処理を実行することができる。そして、復号部５６は、デコード処理によって再構成したPointCloudを、表示情報生成部５７に供給する。例えば、図６に示したファイルの例では、’vpcC’のPropertyが用いられる。
【００６０】
ステップＳ１３において、表示情報生成部５７は、レンダリング処理を実行して、ステップＳ１２で復号部５６から供給されたPoint Cloudから、表示画面をレンダリングする。
【００６１】
そして、ステップＳ１３の処理後、表示情報生成部５７によりレンダリングされた表示画面が、図４１の表示部５４に表示される。
【００６２】
図９は、図８のステップＳ１１においてImageファイル処理として実行されるmeta Box処理を説明するフローチャートである。
【００６３】
ステップＳ２２の第１の再生可否判断処理（HandlerBox(‘hdlr’)の処理）では、ステップＳ３１乃至Ｓ３３の処理が行われる。
【００６４】
ステップＳ３１において、ファイル解析部５５は、HandlerBox(‘hdlr’)を取得する。
【００６５】
ステップＳ３２において、ファイル解析部５５は、ステップＳ３１で取得したHandlerBox(‘hdlr’)のhandler_typeが’pict’であるか否かを判定する。
【００６６】
ステップＳ３２において、ファイル解析部５５が、handler_typeが’pict’でないと判定した場合、処理はステップＳ３３に進み、再生できないファイルとして処理が終了される。一方、ステップＳ３２において、ファイル解析部５５が、handler_typeが’pict’であると判定した場合、処理はステップＳ３４に進む。
【００６７】
ステップＳ２３の再生Item決定処理（PrimaryItemBox(‘pitm’)の処理）では、ステップＳ３４の処理が行われる。
【００６８】
ステップＳ３４において、ファイル解析部５５は、PrimaryItemBox(‘pitm’)を取得し、item_idを取得する。例えば、図６に示したファイルの例では、item_id=1が取得される。
【００６９】
ステップＳ２４の第２の再生可否判断処理（ItemInfoBox(‘iinf’)の処理）では、ステップＳ３５乃至Ｓ３７の処理が行われる。
【００７０】
ステップＳ３５において、ファイル解析部５５は、ItemInfoBox(‘iinf’)を取得し、含まれるItemInfoEntry(‘infe’)から、ステップＳ３４で取得したitem_idと一致するitem_idのEntryを取得する。例えば、図６に示したファイルの例では、item_id=1のEntryが取得される。
【００７１】
ステップＳ３６において、ファイル解析部５５は、ステップＳ３５で取得したEntryに含まれるitem_typeを処理することができるか否かを判定する。例えば、図６に示したファイルの例では、vpc1に対応しているか否かが判定される。
【００７２】
ステップＳ３６において、ファイル解析部５５が、item_typeを処理することができないと判定した場合、処理はステップＳ３７に進み、再生できないファイルとして処理が終了される。一方、ステップＳ３６において、ファイル解析部５５が、item_typeを処理することができると判定した場合、処理はステップＳ３８に進む。
【００７３】
ステップＳ２５の第３の再生可否判断処理（ItemPropertiesBox(‘iprp’)の処理）では、ステップＳ３８乃至Ｓ４２の処理が行われる。
【００７４】
ステップＳ３８において、ファイル解析部５５は、ItemPropertiesBox(‘iprp’)を取得する。
【００７５】
ステップＳ３９において、ファイル解析部５５は、ItemPropertyAssociationBox(‘ipma’)を取得し、ステップＳ３４で取得したitem_idと一致するitem_idのPropertyリンク情報（property_indexおよびessential flag）を取得する。
【００７６】
ステップＳ４０において、ファイル解析部５５は、ItemPropertyContainerBox(‘ipco’)を取得し、ステップＳ３９で取得したProperty_indexのPropertyを取得する。
【００７７】
ステップＳ４１において、ファイル解析部５５は、ステップＳ４０で取得したpropertyがessentialである全てのPropertyに対応して処理を行う事が可能であるか否かを判定する。例えば、図６に示したファイルの例では、vpcCに対応して処理を行うことが可能であるか否かが判定される。
【００７８】
ステップＳ４１において、ファイル解析部５５が、処理を行う事が可能でないと判定した場合、処理はステップＳ４２に進み、再生できないファイルとして処理が終了される。一方、ステップＳ４１において、ファイル解析部５５が、処理を行う事が可能であると判定した場合、処理はステップＳ４３に進む。
【００７９】
ステップＳ２６の再生データ取得処理（ItemLocationBox(‘iloc’)の処理）では、ステップＳ４３の処理が行われる。
【００８０】
ステップＳ４３において、ファイル解析部５５は、ItemLocationBox(‘iloc’)を取得し、ステップＳ３４で取得したitem_idで示されるitem_idのデータのoffset/lengthからデータを取得する。
【００８１】
その後、meta Box処理は終了して、処理は図８のステップＳ１２に進む。
【００８２】
以上のように、V-PCC静止画streamを再生する再生処理は、基本的には、HEVCやAVCなどがHEIFに格納されたファイルを再生する処理と同様である。ただし、ステップＳ２４の第２の再生可否判断処理において、ItemInfoBox(‘iinf’)でvpc1を用いて再生可否判断を行う点、および、ステップＳ２５の第３の再生可否判断処理において、vpcCを用いて再生可否判断をする点が、V-PCC静止画streamを再生する際に特徴となる処理である。また、ステップＳ１２のデコード処理、および、ステップＳ１３のレンダリング処理は、V-PCCにおける独自の処理となる。
【００８３】
ところで、図８および図９を参照して説明した再生処理では、V-PCCを用いていることがItemInfoBox(‘iinf’)の’vpc1’を用いて再生可否判断を行うことができるとともに、ItemPropertyの’vpcC’からV-PCCのprofileやlevelを認識することができる。
【００８４】
ここで、ステップＳ１２のデコード処理に注目する。デコード処理おいては、各video data unit（geometry画像やtexture画像など）を、既存の動画像コーデックでデコードする。また、クライアントは’vpcC’を用いて再生可否判断を行うが、現状、occupancy parameter set，geometory parameter set，attribute parameter setそれぞれに含まれるcodec_idでcodecの種類程度がシグナリングされているだけである。
【００８５】
例えば、HEVCの場合、HEVCConfigurationBox(‘hvcC’)に含まれるHEVCのProfileやLevelなどの情報に基づいて、再生可否判断が行われる。一方、’vpcC’のみでは、含まれるvideo data unitごとのprofileやlevelなどの再生可否判断を行うための情報がないため、実際にデコード処理を必要があり処理効率が低下することが想定される。そこで、video data unitの再生可否判断を行うことができるように、Video data unitの再生可否判断情報をシグナリングすることが必要となる。
【００８６】
＜Video data unitの再生可否判断情報のシグナリング＞
図１０乃至図１４を参照して、Video data unitの再生可否判断情報をシグナリングする第１乃至３の手法について説明する。
【００８７】
第１の手法では、ItemPropertyで各Video data unitの再生可否判断情報を、VideoのSampleEntryを用いてシグナリングする。例えば、ItemProperty(‘sube’)を定義し、各video data unitのコーデックや、decoder configuration情報をシグナルすることができる。
【００８８】
図１０には、上述した図６のファイルに、ItemProperty(‘sube’)を付加した例が示されている。
【００８９】
例えば、図１０において太字で示すように、ItemPropertyContainerBox(‘ipco’)で、ItemProperty(‘sube’)をシグナリングし、ItepPropertyAssociationBox(‘ipma’)で、item_id=1に、ItemProperty(‘sube’)を紐づける。
【００９０】
図１０では、essentail flagは、必ず処理が必要であるPropertyであることを示す１としている。なお、図１０に示す例では、essential flagを１に設定しているが、essential flagを０に設定すれば、このItemPropertyを扱えない機器においても、再生処理を許すことが可能である。また、property_index[2]で、ItemProperty(‘sube’)と紐づけている。
【００９１】
図１１には、ItemProperty(‘sube’)の構造例が示されている。また、図１２には、data_typeの定義の一例が示されており、図１３には、attribute_typeの定義の一例が示されている。
【００９２】
例えば、SubSampleEntryPropertyには、V-PCCに含まれるvideo data unitの数だけcomponentSampleEntryBoxが含まれる。それぞれのcomponentSampleEntryBoxには、typeフィールドでvideo data unitのcomponent type（図１２参照）を識別するtype情報が格納される。さらに、video data unitのcomponent typeがattributeである場合には、attribute_typeフィールドで、attribute typeを識別するattributeのtype情報（図１３参照）と、video data unitのSampleEntryとが格納される。また、SampleEntry()は、componentの符号化コーデックに応じて変化し、例えば、HEVC符号化されているならHEVCSampleEntryとなる。
【００９３】
このような第１の手法でVideo data unitの再生可否判断情報をシグナリングすることで、クライアントの再生処理におけるステップＳ２５（上述の図８参照）において、SubSampleEntryPropertyを用いて再生可否判断を行うことができる。また、再生時において、SubSampleEntryPropertyでシグナリングされているSampleEntry情報を処理することで、各video data unitのコーデックの他に、ProfileやLevel情報、さらにParameter Set情報などを用いた再生可否判断が可能となる。
【００９４】
なお、図１１に示す例では、typeおよびattribute typeのみをシグナリングしているが、例えば、layerの識別情報、同じattribute_typeの場合における識別情報などをシグナリングしてもよい。
【００９５】
第２の手法では、各Video data unitの再生可否判断情報を、既存のItemPropertyEntryを利用してシグナリングする。即ち、上述した第１の手法では、各Video data unitの再生可否判断情報にSampleEntryの構造を用いてシグナリングするのに対し、第２の手法では、ItemPropertyの構造を用いてシグナリングすることができる。
【００９６】
図１４には、シンタックスの一例が示されている。
【００９７】
図１４において太字で示すように、再生可否判断情報のItemPropertyとして、HEIFで規定済みのものを利用する。例えば、Video data unitの動画像コーデックがHEVCの場合は、ItemProperty (‘hvcC’)およびItemProperty (‘ispe’)がSubItemPropertyに含まれる。
【００９８】
第３の手法では、各Video data unitの再生可否判断情報を、V-PCCのProfile/Levelでシグナリングする。例えば、図７に示したVPCCConfigurationBox(‘vpcC’)のProfile/Levelでシグナリングすることができる。
【００９９】
例えば、以下に記載するようにProfileおよびLevelを決めることで、VPCCConfigurationBox(‘vpcC’)のみで、利用しているVideo data unitの再生判断ができるようになる。
【０１００】
・Profile 1: main (hevc)  profile
V-PCC全体はmain profile
Video data unitはHEVC codec(main profile)のみ利用
・Profile 2: main (avc)  profile
V-PCC全体はmain profile
Video data unitはAVC codec(high profile)のみ利用
・Level 1
V-PCCのlevelは１．
HEVCを利用している場合はHEVCのLevel4まで
AVCを利用している場合はAVCのLevel4まで
・Level 2
V-PCCのlevelは2．
HEVCを利用している場合はHEVCのLevel5まで
AVCを利用している場合はAVCのLevel5まで
【０１０１】
なお、第３の手法では、video data unitのcodecのprofileやlevelの組合せが規定されることより、規定以外のものが利用できなくなるため、video data unitのcodecやprofile、levelの自由度が低下すると考えられる。
【０１０２】
次に、図１５および図１６を参照して、V-PCC静止画フォーマット（multi item版）について説明する。
【０１０３】
例えば、上述の図３に示したようなファイル構造のV-PCC動画像フォーマットを参考にして、各Trackをitemとすることで、V-PCC静止画フォーマットにマッピングすることが可能である。具体的には、図３のPCC metadata，geometry，texture(attribute)、およびoccupancyの各trackを、image itemとする。また、コンテンツ再生のエントリーポイントを示すEntityToGroupBoxは、既にMetaboxに含まれるBoxであるので、そのまま利用する。
【０１０４】
図１５には、実際にV-PCC静止画フォーマットにマッピングした例が示されており、この例では、各Video dataはHEVCでエンコードされている。
【０１０５】
例えば、図１５に示すItemInfoEntryのitem_id=1に、図３のPCC Metadata Trackがマッピングされている。item_typeとして、PCCのMetadataのみを含むtrackであることを示す’vpcm’をシグナリングしている。item_id=1のItemPropertyは、’vpcC’を紐づけている。’vpcC’には、各種Paramete Setが入り、例えば、図７に示したのと同じ構造である。Item Dataとしては、Auxiliary Information Data unitのみを格納するようにしている。
【０１０６】
また、図１５に示すItemInfoEntryのitem_id=2のImage itemに、図３のGeometry trackがマッピングされている。例えば、HEIFで規定されているHEVCコーデックのImage dataを格納する既存の方法を、そのまま利用することが可能である。
【０１０７】
また、図１５に示すItemInfoEntryのitem_id=3のImage itemに、図３のTexture trackがマッピングされている。例えば、HEIFで規定されているHEVCコーデックのImage dataを格納する既存の方法をそのまま利用することが可能である。
【０１０８】
また、図１５に示すItemInfoEntryのitem_id=4のImage itemに、図３のOccupancy trackがマッピングされている。例えば、HEIFで規定されているHEVCコーデックのImage dataを格納する既存の方法をそのまま利用することが可能である。
【０１０９】
ここで、図１５に示すように、エントリーポイントを示す、EntityToGroup Box(‘vpcg’)は、図３と同様に、そのまま利用される。EntityToGroup Boxは、V-PCCコンテンツに含まれるitemと、そのitemのdata_typeとが格納される。例えば、図１５では、item_id=1,2,3,4を１つのV-PCCコンテンツとして、item_id=1はmetadataであること、item_id=2はgeometryあること、item_id=3はtextureあること、item_id=4はoccupancyであることを、それぞれ示している。
【０１１０】
図１６には、図１５に示したV-PCC静止画フォーマット（multi item版）のファイルを再生する再生処理を説明するフローチャートが示されている。
【０１１１】
図１６に示す再生処理では、ステップＳ６１乃至Ｓ６３において、図８のステップＳ２１乃至２３と同様の処理が行われ、ステップＳ６５乃至Ｓ６７において、図８のステップＳ２４乃至２６と同様の処理が行われる。また、ステップＳ５２およびＳ５３において、図８のステップＳ１２および１３と同様の処理が行われる。
【０１１２】
即ち、図１６に示す再生処理では、ステップＳ６４において再生Item一覧取得処理（GroupListBox(‘grpl’)の処理）が追加される点で、図８の再生処理と異なる。また、ItemInfoBox(‘iinf’)，ItemPropertiesBox(‘iprp’)、およびItemLocationBox(‘iloc’)は、itemの数だけの処理が必要になる点で、図８の再生処理と異なる。
【０１１３】
ところで、V-PCC静止画フォーマット（multi item版）では、クライアントは、再生の起点を認識することができない。
【０１１４】
即ち、図１６を参照して説明した再生処理において、再生の起点は、PrimaryItemBoxでシグナリングすることが想定されている。ただし、PrimaryItemBoxは、最初に再生すべきitemを指し示すことしかできない。従って、図１５に示した構造では、EntityToGroup Box(‘vpcg’)で示されるgroupが再生の起点となるべきであるが、現状のフォーマットでは、シグナリングすることができない。
【０１１５】
そこで、後述するように再生の起点のシグナリングを行い、クライアントが、再生の起点を認識できるようにすることが必要となる。
【０１１６】
また、V-PCC静止画フォーマット（multi item版）では、Decode処理において、各Image dataをDecode後、V-PCCのパラメータセットと紐づけができないため、クライアントは、Point Cloudを再構成することができない。
【０１１７】
即ち、図１５に示したように、Geometry item，Attibute item、およびOccupancy itemが、それぞれ１つしか存在しない場合は、metadata itemのItemProperty(‘vpcC’)に含まれるParameter Setとの紐づけは可能である。しかしながら、例えば、Geometry画像を複数のLayer持つことが可能である。この場合は、それぞれのLayerでGeometry itemがあり、Metadata itemにはそれぞれのLayerのGeometry Parameter Setが存在する。ところが、各Geometory itemと、Metadata itemのGeometory Paramaeter Setとが紐づけされていないため、Point Cloudを再構成することができない。なお、Videoの場合も同様である。
【０１１８】
そこで、後述するように、Point Cloudを再構成するためのシグナリングを行い、クライアントは、Point Cloudを再構成できるようにすることが必要となる。
【０１１９】
また、V-PCC静止画フォーマット（multi item版）では、クライアントは、各Image itemが単体で再生できてしまう。
【０１２０】
即ち、V-PCC静止画フォーマット（multi item版）では、V-PCCを処理できないが、HEVC Imageを再生できるクライアントが、図１５のデータを処理すると、item_id=2、item_id=3、item_id=4はHEVC Imageのitemであると認識できてしまうため、再生することができてしまう。このように、各Image itemが単体で再生された場合、図２に示したような展開された状態の画像がそのまま表示されるため、その様な表示が行われないようにする必要がある。
【０１２１】
そこで、後述するように、Item単体での再生をさせないためのシグナリングを行って、クライアントが、各Image itemが単体で再生できないようにすることが必要となる。
【０１２２】
＜再生の起点のシグナリング＞
図１７乃至図２０を参照して、再生の起点をシグナリングする第１乃至第３の手法について説明する。
【０１２３】
第１の手法では、Primary item Boxを拡張することにより、再生の起点をシグナリングする。
【０１２４】
例えば、上述の図１５に示したように、再生の起点がEntityToGroup Box(‘vpcg’)のgroupで示されている場合に、Primary item boxを用いて、再生の起点をシグナリングできるようにする。
【０１２５】
具体的には、図１７において太字で示すように、PrimaryItemBoxのversion=2を追加して、そこで、EntityToGroup Boxで示されるgroup_idをシグナリングできるようにする。
【０１２６】
また、PrimaryItemBoxを拡張する変形例として、元々のPrimaryItemBoxのシンタックスは変更せず、32bitのitem_IDで、group_idを示せるように、semanticsを変更する。具体的には、PrimaryItemBoxのitem_IDをentity_IDと名前を変え、item_idおよびgroup_idのどちらでも利用できるようにする。ここで、gorup_idが使われることを明示するために（‘pitm’，version，flags）として、flags&1を１に設定してもよい。
【０１２７】
第２の手法では、新しいboxで、再生の起点をシグナリングする。
【０１２８】
例えば、上述の図１５に示したように、再生の起点がEntityToGroup Box(‘vpcg’)のgroupで示されている場合に、起点を示す新しいBoxで、再生の起点をシグナリングする。
【０１２９】
具体的には、図１８に示すように、PrimaryGroupBox(‘pgrp’)を定義し、そのBoxは、最初に再生すべき起点であるgroupを示す。これにより、クライアントは、このboxがある場合は、このboxからgroup_idを取得し、そのgroup_idと一致するEntityToGroup Boxを検索することで、起点から再生することができる。
【０１３０】
例えば、上述の図１６を参照して説明した再生処理におけるPrimaryItemBoxの処理（ステップＳ６３）に替えて、図１８のPrimaryGroupBoxの処理が行われて再生されるようにすることができる。
【０１３１】
第３の手法として、再生の起点をitemにするように、V-PCC静止画streamのファイル構成（multi item版）の構造を変更する。
【０１３２】
例えば、再生の起点をEntityToGroupBoxではなく、ItemReferenceを用いmetadata itemを参照元とし、参照先としてそれ以外のitemを示すことで、参照元のitemのitem_idを起点とすることで、既存のPrimaryItemBoxを拡張なしに示すことができるようにする。つまり、PrimaryItemBoxからは、metadata itemのitem_idをシグナリングする。
【０１３３】
具体的には、図１９および図２０に示すように、ItemReferenceを用いる。ItemReference(‘vpcg’)を新しく定義し、metadata itemからGeometry，Attribute、およびOccupancy itemへの紐づけを行うことで１つのV-PCCコンテンツを示す。さらに、EntityToGroupBoxでシグナリングされていた情報をVPCCMultiItemPropertyでシグナリングする。なお、typeおよびattribute_typeは、それぞれ図１２および図１３と同様に定義される。
【０１３４】
このように、V-PCC静止画streamのファイル構成（multi item版）の構造を変更することで、再生の起点のmetadata itemを最初に取得し、次にItemReference(‘vpcg’)を取得することができる。
【０１３５】
例えば、上述の図１６を参照して説明した再生処理におけるGroupListBoxの処理（ステップＳ６４）に替えて、図２０のItemReferenceを処理し、必要なItemのリストを得る。
【０１３６】
＜Point Cloudを再構成するためのシグナリング＞
図２１乃至図２５を参照して、Point Cloudを再構成するためにシグナリングする第１乃至第３の手法について説明する。
【０１３７】
上述したように、V-PCC静止画フォーマット（multi item版）では、Geometry item，Attibute item、およびOccupancy itemがmetadata itemのItemProperty(‘vpcC’)に含まれるParameter Setとの紐づけができず、Point Cloudを再構成することができない。なお、図３に示したV-PCC動画像フォーマットでも同様に、Point Cloudを再構成することができない。そこで、本実施の形態で説明するような拡張されるImageProperty情報と同等の内容を、図３の各TrackのSampleEntryや、schemeInfomationBox以下に配置すること、または、Track GroupやSample Group、EntityToGroupの仕組みでシグナリングすることで、Point Cloudを再構成することを可能とする。
【０１３８】
第１の手法では、Point Cloudを再構成するために、Geometry item，Attibute item、およびOccupancy itemに、新しいItemPropertyを追加する。
【０１３９】
図２１には、新しく追加するItemProperty(‘vrps’)のシンタックスが示されており、図２２には、そのシンタックスを利用した際のItemPropertyの構造が示されている。
【０１４０】
まず、Point Cloudの再構築でGeometry item，Attibute item、およびOccupancy itemと紐づけが必要となるParameter Setは、metadata item（図２２のitem_id=1）で利用するItemProperty(‘vpcC’)に格納されている。ItemProperty(‘vpcC’)は、図７で示されている構造である。ここで、ItemProperty(‘vpcC’)に格納されているvpccUnitに格納されている順に０からindex番号を付ける。これを、vpcC_vpccUnit_indexと称する。ItemProperty(‘vrps’)は、Point Cloudの再構築でGeometry item，Attibute item、およびOccupancy itemと紐づけが必要となるParameter Setの一覧を格納する。その際に、vpcC_vpccUnit_indexで紐づけを行う。
【０１４１】
このように、第１の手法により、Point Cloudの再構築時に必要なParameter Setが一意に特定でき、Point Cloudの再構築が可能になる。
【０１４２】
例えば、上述の図１６を参照して説明した再生処理におけるDecode処理（ステップＳ１２）の際に、第１の手法で拡張したItemProperty(‘vrps’)、および、metadata itemのItemProperty(‘vpcC’)に従って、Parameter Setを特定し、Point Cloudを再構成するのに利用する。
【０１４３】
また、第１の手法を動画フォーマットで利用する場合、例えば、ItemProperty('vprs')と同様のfieldを持つvpccReferenceParameterBox('vrps')を定義して、geomotry，attribute、およびoccpancy trackに格納することで実施可能である。
【０１４４】
第２の手法では、Point Cloudを再構成するために、V-PCC unit headerをシグナリングする。
【０１４５】
例えば、第２の手法では、vpcc_unit_headerをシグナリングするItemProperty(‘vuhd’)を、上述した第１の手法のItemProperty(‘vrps’)と同様にシグナリングする。
【０１４６】
図２３には、ItemProperty(‘vuhd’)のシンタックスが示されている。
【０１４７】
このように、第２の手法のポイントは、V-PCC静止画フォーマット（1item版）のbitstreamではシグナリングされていたが、V-PCC静止画フォーマット（multi item版）のbitstreamではシグナリングされていないvpcc_unit_headerをシグナリングする。従って、V-PCC静止画フォーマット（multi item版）を、V-PCC静止画フォーマット（1item版）のbitstreamに容易に戻すことが可能になり、Point Cloudの再構築も可能になる。
【０１４８】
なお、第２の手法では、vpcc_unit_headerをシグナリングするようにしたが、vpcc_unit_payloadの一部も含むようにしてもよい。
【０１４９】
また、第２の手法を動画フォーマットで利用する場合、例えば、ItemProperty('vuhd')と同様のfieldを持つvpccUnitHeaderBox('vuhd')を定義して、geomotry，attribute、およびoccpancy trackに格納することで実施可能である。
【０１５０】
第３の手法では、Point Cloudを再構成するために、Parameter Setを各Itemでシグナリングする。
【０１５１】
例えば、第３の手法では、Geometry item，Attibute item、およびOccupancy itemで参照するParameter Setを、それぞれのitemのItemPropertyでシグナリングすることで、Point Cloudの再構築に必要なParameter Setと紐づける。
【０１５２】
図２４には、ItemProperty(‘vpss’)のシンタックスが示されており、図２５には、そのシンタックスを利用した際のItemPropertyの構造が示されている。
【０１５３】
図２５に示すように、新しく定義したvpccParameterSetPropertyは、ItemProperty (‘vpcC’)で、parameter setをシグナリングする部分を抜き出したシンタックスになっている。例えば、item_id=2のgeometry itemではItemProperty (‘vpss’)[3]が紐づけられている。また、ItemProperty (‘vpss’)[3]は、Geometory Parameter Set(GPS)およびGeometory Patch Parameter Set(GPPS)を含んでいる。Point Cloudの再構築の際は、このItemProperty (‘vpss’)[3]と組み合わせることで、再構築が可能になる。
【０１５４】
なお、第３の手法では、ItemProperty (‘vpcC’)[1]では、ItemProperty (‘vpss’)でシグナリングされているParameter Setはシグナリングしないようにしているが、含むようにしてもよい。その場合においても、Point Cloudの再構築の際はItemに紐づけられているParameter Setを利用する。
【０１５５】
また、第３の手法を動画フォーマットで利用する場合、例えば、ItemProperty('vpss')と同様のfieldを持つvpccParameterSetBox('vpss')を定義しgeomotry、attribute、occpancy trackに格納することで実施可能である。
【０１５６】
＜Item単体での再生をさせないためのシグナリング＞
図２６乃至２９を参照して、Item単体での再生をさせないためにシグナリングする第１および第２の手法について説明する。
【０１５７】
第１の手法では、HEVC Image を再生できるクライアントが、Geometory item，Attirbute item、およびOccupancy itemを単体で再生をさせないために、Restricted schemeであることを示すItemPropertyをシグナリングする。
【０１５８】
例えば、Itemが既存のCodecを利用しているが、制限がかかっていることを、ItemInfoEntryおよびItemPropertyを用いてシグナリングをする。
【０１５９】
まず、Item自体が表示するにあたり制限がかかっていることを示す。そのために、IntemInfoEntryのitem_typeを’resi’とする。このとき、元々のitem_typeが認識できなくなるため、OriginalFormatPeopertyを規定する。また、どのような方式の制限がかかっているかを示すために、SchemeTypePropertyを規定する。
【０１６０】
図２６には、OriginalFormatPeopertyの構造例が示されており、図２７には、SchemeTypePropertyの構造例が示されている。
【０１６１】
例えば、図２６に示すように、ItemProerty(‘frma’)のdata_formatは、例えば、HEVC Imageである場合は’hvc1’となる。
【０１６２】
また、図２７に示すように、ItemProperty(‘schm’)のscheme_typeは、vpccで利用するためのitemであることを示すために、例えば、”pvcc”をシグナリングする。その他のfieldは、shcme_versionは１を設定しておき、scheme_uriは利用しない。
【０１６３】
図２８には、item_type=’resi’，ItemProerty(‘frma’)、およびItemProperty(‘schm’)を用いた例が示されている。
【０１６４】
図２８に示すように、Geometory item(item_id=2)，Attirbute item(item_id=3)、およびOccupancy item(item_id=4)それぞれで、ItemProerty(‘frma’)およびItemProperty(‘schm’)を紐づける。
【０１６５】
なお、変形例として、item_type=resiおよびItemProerty(‘frma’)を利用せずに、ItemProperty(‘schm’)のみを利用するようにしてもよい。その場合は、ItemProperty(‘schm’)のみで、Restricted schemeであることを判別することになる。
【０１６６】
また、これと同時にItemInfoEntryにおいて、flag&1=1を設定してhidden imageであるとシグナリングしてもよい。
【０１６７】
例えば、第１の手法は、既存のCodecを用いているが、レンダリングで特別な処理が必要である静止画itemに対して一般的に利用が可能なシグナリングである。
【０１６８】
第２の手法では、HEVC Image を再生できるクライアントが、Geometory item，Attirbute item、およびOccupancy itemを単体で再生をさせないために、V-PCCであることを示すItemPropertyをシグナリングする。
【０１６９】
例えば、第２の手法では、Image itemが、V-PCCの一部のデータであることを示すItemPropertyを追加し、このItemPropertyを処理できないクライアントは再生ができないようにする。
【０１７０】
ここでは、上述した図１９に示したVPCCMultiItemPropertyをシグナリングすればよい。その際に、図２０に示したItemPropertyAssociationBox(‘ipma’)のessential flagを必ず１に設定する。
【０１７１】
そして、図２９に示すように、VPCCMultiItemPropertyを定義する。このItemPropertyは、Multi Itemで１つのV-PCCコンテンツを構成している場合に、Image itemがGeometry，Attribute、およびOccupancyのどれであるかを示している。
【０１７２】
なお、Image itemがGeometry，Attribute、およびOccupancyであることの識別はEntityToGroupBoxで可能なため、何もシグナリングされなく（空のItemProperty）てもよい。
【０１７３】
また、これと同時にItemInfoEntryにおいて、flag&1=1を設定してhidden imageであるとシグナリングしてもよい。
【０１７４】
＜G-PCC静止画フォーマット＞
図３０および図３１を参照して、G-PCC静止画 streamのHEIFへの格納方法の定義について説明する。
【０１７５】
まず、動画像の場合は、特定の時間幅で連続的に表示される複数のPC frameから構成される。これに対し、G-PCC静止画 streamの場合は、１つのPC frameのみで十分であり、時間情報は必要ない。
【０１７６】
このG-PCC静止画streamをISOBMFFの技術を利用したファイル構造のファイルに格納する際は、V-PCC静止画 streamと同様に、再生可否判断およびデコードまたはレンダリングに利用するメタデータをItemPropertyとして定義し、ItemPropertyBox(‘iprp’)でシグナリングする。また、メタデータ以外のデータはItem dataとする。例えば、全てのParameter SetをItemPropertyに格納し、全てのGeomおよびAttrをItem dataとして格納する。
【０１７７】
図３０には、G-PCC静止画フォーマットのファイル構成が示されている。
【０１７８】
まず、ItemInfoEntry(‘infe’)で、Itemのtypeを指定する。図３０に示す例では、item_type=’gpc1’としている。再生可否判断およびデコード・レンダリングに利用するデータは、Item Propertyで、’gpcC’としてシグナリングする。
【０１７９】
例えば、gpcCは、図３１で示すような構造である。
【０１８０】
＜V-PCC/G-PCCの再生を効率よく行う手法＞
図３２乃至図３９を参照して、V-PCC/G-PCCにおいて、属性情報を利用せず３次元形状のみで再生する、もしくは３次元形状と一部の属性情報のみを利用して再生するユースケースを効率よく行う第１および第２の手法について説明する。
【０１８１】
第１の手法は、V-PCC/G-PCCの再生を効率よく行うために、SubSampleItemPropertyをシグナリングする。
【０１８２】
例えば、第１の手法は、V-PCC静止画フォーマット（1item版）およびG-PCC静止画フォーマットの両方で利用可能であり、再生で利用するVideo data unitを容易に判別し取得できるように、ItemDataの部分アクセス情報をSubSampleEntryPropertyでシグナリングする。
【０１８３】
図３２には、既存規格のSubSampleItemPropertyが示されている。
【０１８４】
例えば、図３２に示す既存規格のSubSampleItemPropertyで、ItemDataの一部分をSubSampleとして示すことができる。しかしながら、そのSubSampleがどのようなデータであるか認識できない。
【０１８５】
そこで、図３３乃至図３５に示すように、codec_specific_parametersを定義することで、部分アクセスを可能にする。
【０１８６】
即ち、図３３乃至図３５に示すようにcodec_specific_parametersを設定することで、V-PCC静止画フォーマット（1item版）およびG-PCC静止画フォーマットのどちらにおいても、効率よくデータにアクセスできるようになる。
【０１８７】
なお、図３３乃至図３５に示す例では、codec_specific_parametersで共通としているのに対し、例えば、将来の拡張性を踏まえて、V-PCCおよびG-PCCを別に規定してもよい。そのように規定する場合は、data_type=0(Auxiliary information data)およびdata_type=2(occupancy data)は、G-PCCではreservedとなる。
【０１８８】
第２の手法では、G-PCC静止画フォーマットにおいて、再生で利用するVideo data unitを容易に判別し取得できるように、multi itemでシグナリングする。
【０１８９】
例えば、G-PCC streamは、１つのgeometry bitstreamと複数のattribute bitstreamとを有する。そこで、それぞれのbitstreamをitemとして格納し、必要なデータに効率よくアクセスを可能にする。
【０１９０】
即ち、第２の手法では、geometoryのitemをベースのitemとし、Parameter Setも全て持つ。そして、全てのitemには、multi itemの情報を示すGPCCMultiItemPropertyを持つ。
【０１９１】
図３６には、GPCCMultiItemPropertyが持つ構造の一例が示されている。
【０１９２】
例えば、図３６に示すように、GPCCMultiItemPropertyで、Itemがgeometory itemである場合、isGeometoryStream=1となる。また、G-PCC streamに含まれるattribute bitstreamの数をnum_attribute_bitstreamで示す。Itemがattiribute itemである場合は、attributeの種類（色、反射）を示すattribute_typeを示す。なお、attribute_typeは、図１３と同様に定義される。
【０１９３】
図３７には、GPCCMultiItemPropertyを用いたファイル構造が示されている。
【０１９４】
図３７に示すように、まず、ItemInfoEntryのitem_typeを、multi itemであることを示す’gpc2’とする。そして、item_id=1は、GeometoryのItemで、ItemProperty(‘gpcC’)とItemProperty(‘gpcM’)のItemPropertyを持つ。また、ItemProperty(‘gpcC’)は、図３１と同じ構造である。また、ItemProperty(‘gpcM’)は、isGeometoryStream=1，num_attribute_bistream=1となる。
【０１９５】
さらに、item_id=2はテクスチャ（attribute）のitemで、ItemProperty(‘gpcM’)のItemPropertyを持つ。また、ItemProperty(‘gpcM’)は、isGeometoryStream=0，attribute_type=0(texture)となる。
【０１９６】
そして、再生の起点をEntityToGroupBox(’gpcg’)で示す。この場合の、再生の起点を示す手法は、上述した再生の起点のシグナリングの第１および第２の手法を用いることができる。
【０１９７】
なお、変形例として、上述した再生の起点のシグナリングの第３の手法を用いてもよく、例えば、図３８に示すように、geometory itemをベースにして、ItemReference(‘gpcg’)を用いることもできる。ここで、図３７のEntityToGroupBoxではなくItemReferenceを用いる点が異なるが、その他のBoxは同様である。
【０１９８】
また、V-PCC/G-PCCの再生を効率よく行う手法の変形例として、再生に利用するAttributeの組合せをシグナリングすることができる。
【０１９９】
例えば、Attribute情報は、利用しなければ３次元形状のみの表示ができ、テクスチャ情報やTransparency情報などで色付けや透過度を示すことが可能になる。クライアントは、Attributeを自由に選択して再生が可能になる。ところが、コンテンツオーサはコンテンツごとで、最低限利用しなければいけないAttributeを利用してレンダリングを行って欲しいが、現状では、それをシグナリングする方法がない。
【０２００】
そこで、ItemPropertyでコンテンツオーサの意図する再生時の組合せ情報をシグナリングする。
【０２０１】
例えば、図３９に示すように、組み合わせるAttributeの一覧をItemPropertyでシグナリングする。
【０２０２】
図３９に示すように、V−PCC/G-PCCのgeomeotry、並びに、V-PCCのoccupancyおよびauxiliary informationは、３次元形状を表示するために必須のため、Attributeのみの選択情報を示す。
【０２０３】
例えば、selection_entry_countはAttributeの組合せの数を示し、attribute_numは組み合わせに含まれるattributeの数を示す。例えば、attribute_numが0である場合は、attributeは利用しない再生が許可されていることを示す。また、attribute_numが0より大きい場合は、その組合せに含まれるattributeをattribute_typeで示す。
【０２０４】
この変形例では、組み合わせを示すようにしたが、個々のAttributeが再生必須およびoptionalのいずれであるかを示すだけでもよい。例えば、個々のAttributeが再生必須およびopitonalのいずれであるかを示す情報の場合は、V-PCC/G-PCCの再生を効率よく行う第１の手法のcodec_specific_parametersや、同じく第２の手法のGPCCMultiItemPropertyまたはEntityToGroupBox(’gpcg’)などでシグナリングされてもよい。
【０２０５】
また、V-PCC静止画streamのファイル構成（multi item版）の場合は、EntityToGroup Box(‘vpcg’)でシグナリングされたり、上述した再生の起点のシグナリングの第３の手法のVPCCMultiItemPropertyでシグナリングされてもよい。
【０２０６】
なお、このようなシグナリングを動画フォーマットで利用してもよい。その場合は、例えば、ItemProperty('atsl')と同様のfieldを持つAttributeSelectionBox('atsl')を定義して、metadata trackなどに格納することで実施可能である。
【０２０７】
＜システム構成＞
図４０および図４１を参照して、本技術を適用したデータ生成装置およびデータ再生装置のシステム構成について説明する。
【０２０８】
図４０には、データ生成装置の構成例を示すブロック図が示されている。
【０２０９】
図４０に示すように、データ生成装置１１は、制御部２１、メモリ２２、およびファイル生成部２３を備えて構成される。例えば、メモリ２２には、制御部２１がファイル生成部２３を制御するのに必要な各種のデータが記憶されており、制御部２１は、そのデータを参照して、ファイル生成部２３におけるファイルの生成を制御する。
【０２１０】
ファイル生成部２３は、データ入力部３１、データ符号化・生成部３２、記録部３３、および出力部３４を備えて構成される。例えば、データ入力部３１に入力されたデータは、データ符号化・生成部３２に供給される。そして、データ符号化・生成部３２で生成されたファイルが、記録部３３を介して出力部３４から出力され、例えば、記録メディアなどに記録される。
【０２１１】
データ符号化・生成部３２は、前処理部３５、符号化部３６、およびファイル生成部３７を有している。
【０２１２】
前処理部３５は、データ入力部３１から入力されるPoint Cloudから、geometry画像やtexture画像、各種のメタデータなどを生成する処理を実行する。
【０２１３】
符号化部３６は、V-PCCまたはG-PCCを用いてPoint Cloudを符号化する処理を実行する。
【０２１４】
ファイル生成部３７は、V-PCC静止画データまたはG-PCC静止画データとともに、前処理部３５において生成されたメタデータを、ISOBMFFの技術を利用したファイル構造のファイルに格納し、そのファイルを生成する処理を実行する。
【０２１５】
図４１には、データ再生装置の構成例を示すブロック図が示されている。
【０２１６】
図４１に示すように、データ再生装置１２は、制御部４１、メモリ４２、および再生処理部４３を備えて構成される。例えば、メモリ４２には、制御部４１が再生処理部４３を制御するのに必要な各種のデータが記憶されており、制御部４１は、そのデータを参照して、再生処理部４３におけるPoint Cloudの再生を制御する。
【０２１７】
再生処理部４３は、取得部５１、表示制御部５２、データ解析・復号部５３、および表示部５４を備えて構成される。例えば、取得部５１により取得された、例えば、記録メディアなどから読み出されたファイルは、データ解析・復号部５３に供給される。そして、表示制御部５２による表示制御に従ってデータ解析・復号部５３において生成された表示画面が、表示部５４において表示される。
【０２１８】
データ解析・復号部５３は、ファイル解析部５５、復号部５６、および表示情報生成部５７を有しており、上述の図８および図９を参照して説明した再生処理を実行する。
【０２１９】
ファイル解析部５５は、ISOBMFFの技術を利用したファイル構造のファイルからV-PCC静止画データまたはG-PCC静止画データを抽出するとともに、メタデータを解析する処理を実行する。
【０２２０】
また、復号部５６は、ファイル解析部５５において取得されたメタデータに従い、V-PCC静止画データまたはG-PCC静止画データを、V-PCCまたはG-PCCを用いて復号する処理を実行する。
【０２２１】
また、表示情報生成部５７は、Point Cloudを構築しPoint Cloudをレンダリングして表示画面を生成する。
【０２２２】
＜ファイル生成処理＞
【０２２３】
図４２は、データ生成装置１１のデータ符号化・生成部３２が、V-PCC静止画streamが格納されたファイルを生成するファイル生成処理を説明するフローチャートである。
【０２２４】
ステップＳ１０１において、前処理部３５は、Point Cloudデータから、geometry画像、texture画像、およびメタデータを生成して、符号化部３６に供給する。
【０２２５】
ステップＳ１０２において、符号化部３６は、ステップＳ１０１で前処理部３５から供給されたgeometry画像、texture画像、およびメタデータをそれぞれ符号化する。これにより、符号化部３６は、geometry video data，texture video data，occupancy video data，auxiliary information data、および各parameter setを生成して、ファイル生成部３７に供給する。
【０２２６】
ステップＳ１０３において、ファイル生成部３７は、ステップＳ１０２において符号化部３６により符号化された各種のデータをV-PCC unitに格納し、V-PCC 静止画streamを生成する。
【０２２７】
ステップＳ１０４において、ファイル生成部３７は、ステップＳ１０４で生成したV-PCC静止画streamを、メタデータを含むISOBMFFの技術を利用したファイル構造のファイルに格納し、記録部３３に供給した後、処理は終了される。
【０２２８】
図４３は、データ生成装置１１のデータ符号化・生成部３２が、G-PCC静止画streamが格納されたファイルを生成するファイル生成処理を説明するフローチャートである。
【０２２９】
ステップＳ１１１において、前処理部３５は、Point Cloudデータの位置情報および属性情報を分離して、符号化部３６に供給する。
【０２３０】
ステップＳ１１２において、符号化部３６は、ステップＳ１１１で前処理部３５から供給された位置情報および属性情報をそれぞれ符号化する。これにより、符号化部３６は、geometry bitstream，attribute bitstream、および各parameter setを生成して、ファイル生成部３７に供給する。
【０２３１】
ステップＳ１１３において、ファイル生成部３７は、ステップＳ１１２で符号化部３６から供給されたgeometry bitstream、attribute bitstream、および各parameter setから、G-PCC静止画streamを生成する。
【０２３２】
ステップＳ１１４において、ファイル生成部３７は、ステップＳ１１３で生成したG-PCC静止画streamを、メタデータを含むISOBMFFの技術を利用したファイル構造のファイルに格納し、記録部３３に供給した後、処理は終了される。
【０２３３】
以上のように、本技術は、時間情報を持たないV-PCC静止画データまたはG-PCC静止画データを、ISOBMFFの技術を利用したファイル構造のファイルに格納することができる。
【０２３４】
例えば、V-PCC静止画streamを1itemとして格納する場合には、クライアントは、Video data unitをデコードすることなく、容易に再生可否の判断ができるようになる。
【０２３５】
また、V-PCC静止画streamをmulti itemで格納する場合には、上述した第１乃至３の手法を用いることにより、下記の点を可能とした。即ち、第１の手法により、再生の起点を明示することで、クライアントが、容易にV-PCCを構成するitemにアクセスすることを可能とした。また、第２の手法により、デコードしたデータと、Point Cloudを再構成するためのメタデータとを紐づけることで、例えば、複数のattributeを持つV-PCC静止画データでもPoint Cloudの再構成を可能とした。また、第３の手法により、Image Itemとして格納されるGeometry，Occupancy、およびAttributeのデータが単体で再生されるのを禁止することを可能とした。
【０２３６】
そして、V-PCCまたはG-PCCにおいて、geometory，attribute、およびデータ(metadata (V-PCCのみ Auxiliary information、occupancy))へのアクセスが可能になり、クライアントは、属性情報の選択再生処理を容易に行うことができる。これにより、色や反射といった属性情報が不要で、Point Cloudの３次元形状情報だけを利用するユースケースにおけるクライアント処理を容易にすることができる。同様に、色や反射といった属性情報が複数ついている場合、例えば、プレビュー用にはgeometryとともに色の属性だけ利用するようなユースケースにおけるクライアント処理を容易にすることができる。また、再生に利用する属性情報の組合せにより、特定の組合せのみの再生を、コンテンツオーナが指定することが可能となる。
【０２３７】
＜コンピュータの構成例＞
次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
【０２３８】
図４４は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
【０２３９】
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５やROM１０３に予め記録しておくことができる。
【０２４０】
あるいはまた、プログラムは、ドライブ１０９によって駆動されるリムーバブル記録媒体１１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体１１１は、いわゆるパッケージソフトウェアとして提供することができる。ここで、リムーバブル記録媒体１１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
【０２４１】
なお、プログラムは、上述したようなリムーバブル記録媒体１１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク１０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
【０２４２】
コンピュータは、CPU(Central Processing Unit)１０２を内蔵しており、CPU１０２には、バス１０１を介して、入出力インタフェース１１０が接続されている。
【０２４３】
CPU１０２は、入出力インタフェース１１０を介して、ユーザによって、入力部１０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)１０３に格納されているプログラムを実行する。あるいは、CPU１０２は、ハードディスク１０５に格納されたプログラムを、RAM(Random Access Memory)１０４にロードして実行する。
【０２４４】
これにより、CPU１０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU１０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース１１０を介して、出力部１０６から出力、あるいは、通信部１０８から送信、さらには、ハードディスク１０５に記録等させる。
【０２４５】
なお、入力部１０７は、キーボードや、マウス、マイク等で構成される。また、出力部１０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
【０２４６】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
【０２４７】
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０２４８】
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０２４９】
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０２５０】
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０２５１】
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
【０２５２】
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
【０２５３】
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
【０２５４】
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
【０２５５】
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
前記ビットストリームおよび前記メタデータを格納したファイルを生成するファイル生成部と
を備える情報処理装置。
（２）
前記再生情報には、前記ビットストリームを構成するVideo data unitに対し、再生時に用いる前記Video data unitの組み合わせを示す組み合わせ情報が含まれる
上記（１）に記載の情報処理装置。
（３）
前記再生可否判断情報には、前記ビットストリームのパラメータセットが含まれる
上記（２）に記載の情報処理装置。
（４）
前記再生可否判断情報には、さらに、前記Video data unitごとに対応するSub-Sampleのパラメータセットが含まれる
上記（３）に記載の情報処理装置。
（５）
前記ファイル生成部は、前記再生可否判断情報を、Item Propertyに格納する
上記（３）に記載の情報処理装置。
（６）
前記ファイル生成部は、前記再生可否判断情報に含まれるパラメータセットのうち、前記Video data unitごとのProfile情報を、Item Propertyに格納する
上記（４）に記載の情報処理装置。
（７）
前記メタデータ生成部は、Attributeデータを選択して再生をするための前記メタデータを生成する
上記（１）から（６）までのいずれかに記載の情報処理装置。
（８）
1itemである場合において前記メタデータはSubSampleItemPropertyであり、multi itemにすることで選択再生を可能にする
上記（７）に記載の情報処理装置。
（９）
前記メタデータ生成部は、再生の組合せを示す前記メタデータを生成する
上記（７）に記載の情報処理装置。
（１０）
情報処理装置が、
時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
を含む情報処理方法。
（１１）
時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
前記ビットストリームおよび前記メタデータを、格納したファイルを生成するファイル生成部と
を備える情報処理装置。
（１２）
前記再生情報には、再生時に用いる前記ビットストリームの組み合わせを示すビットストリーム組み合わせ情報と、再生の起点を示す再生起点情報とを含む
上記（１１）に記載の情報処理装置。
（１３）
前記再生起点情報は、最初に再生すべきビットストリームを示すitem_idである
上記（１２）に記載の情報処理装置。
（１４）
前記再生情報は、更に、前記ビットストリームから前記３Ｄデータを再構成するための情報として、各前記ビットストリームのTypeを識別する情報であるV-PCC Unit Headerを含む
上記（１２）に記載の情報処理装置。
（１５）
前記再生可否判断情報は、各前記ビットストリームが前記３Ｄデータを構成するデータの一部であることを示す情報を含み、
前記ファイル生成部は、前記再生可否判断情報をItem Propertyに格納する
上記（１４）に記載の情報処理装置。
（１６）
前記再生可否判断情報には、更に、各前記ビットストリームが前記３Ｄデータの構成であるとして処理できるか否かの処理を行うことを示す処理判断情報を含む
上記（１５）に記載の情報処理装置。
（１７）
前記再生可否判断情報には、item単体で表示不可である判断を可能にする判断情報として、さらに、hidden imageであることを示す情報を含み、
前記ファイル生成部は、前記hidden_imageを示す情報を、ItemInfoEntryに格納する
上記（１５）に記載の情報処理装置。
（１８）
情報処理装置が、
時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
を含む情報処理方法。
【０２５６】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【符号の説明】
【０２５７】
１１  データ生成装置，  １２  データ再生装置，  ２１  制御部，  ２２  メモリ，  ２３  ファイル生成部，  ３１  データ入力部，  ３２  データ符号化・生成部，  ３３  記録部，  ３４  出力部，  ３５  前処理部，  ３６  符号化部，  ３７  ファイル生成部，  ４１  制御部，  ４２  メモリ，  ４３  再生処理部，  ５１  取得部，  ５２  表示制御部，  ５３  データ解析・復号部，  ５４  表示部，  ５５  ファイル解析部，  ５６  復号部，  ５７  表示情報生成部
【図１】
2020137854.tif 000003
【図２】
2020137854.tif 000004
【図３】
2020137854.tif 000005
【図４】
2020137854.tif 000006
【図５】
2020137854.tif 000007
【図６】
2020137854.tif 000008
【図７】
2020137854.tif 000009
【図８】
2020137854.tif 000010
【図９】
2020137854.tif 000011
【図１０】
2020137854.tif 000012
【図１１】
2020137854.tif 000013
【図１２】
2020137854.tif 000014
【図１３】
2020137854.tif 000015
【図１４】
2020137854.tif 000016
【図１５】
2020137854.tif 000017
【図１６】
2020137854.tif 000018
【図１７】
2020137854.tif 000019
【図１８】
2020137854.tif 000020
【図１９】
2020137854.tif 000021
【図２０】
2020137854.tif 000022
【図２１】
2020137854.tif 000023
【図２２】
2020137854.tif 000024
【図２３】
2020137854.tif 000025
【図２４】
2020137854.tif 000026
【図２５】
2020137854.tif 000027
【図２６】
2020137854.tif 000028
【図２７】
2020137854.tif 000029
【図２８】
2020137854.tif 000030
【図２９】
2020137854.tif 000031
【図３０】
2020137854.tif 000032
【図３１】
2020137854.tif 000033
【図３２】
2020137854.tif 000034
【図３３】
2020137854.tif 000035
【図３４】
2020137854.tif 000036
【図３５】
2020137854.tif 000037
【図３６】
2020137854.tif 000038
【図３７】
2020137854.tif 000039
【図３８】
2020137854.tif 000040
【図３９】
2020137854.tif 000041
【図４０】
2020137854.tif 000042
【図４１】
2020137854.tif 000043
【図４２】
2020137854.tif 000044
【図４３】
2020137854.tif 000045
【図４４】
2020137854.tif 000046
【国際調査報告】
2020137854.tif 000047
2020137854.tif 000048
2020137854.tif 000049