JPWO2020137854A1 - 情報処理装置および情報処理方法 - Google Patents

Abstract

本開示は、時間情報を持たないPoint Cloudの再生に対応することができるようにする情報処理装置および情報処理方法に関する。Point Cloudの１フレーム分がV-PCCまたはG-PCCで符号化された符号化データを再生するのに必要な再生情報、および、符号化データの再生の可否を判断するのに用いられる再生可否情報を含むメタデータを生成し、符号化データおよびメタデータを、所定のISOBMFFの技術を利用したファイル構造のファイルに格納する。本技術は、例えば、時間情報を持たないPoint Cloudの符号化データを格納するファイルを生成するデータ生成装置に適用できる。

Description

本開示は、情報処理装置および情報処理方法に関し、特に、時間情報を持たない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に格納する
上記（１５）に記載の情報処理装置。
（１８）
情報処理装置が、
時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
を含む情報処理方法。

なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。

１１ データ生成装置， １２ データ再生装置， ２１ 制御部， ２２ メモリ， ２３ ファイル生成部， ３１ データ入力部， ３２ データ符号化・生成部， ３３ 記録部， ３４ 出力部， ３５ 前処理部， ３６ 符号化部， ３７ ファイル生成部， ４１ 制御部， ４２ メモリ， ４３ 再生処理部， ５１ 取得部， ５２ 表示制御部， ５３ データ解析・復号部， ５４ 表示部， ５５ ファイル解析部， ５６ 復号部， ５７ 表示情報生成部

Claims (18)

1. 時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
   前記ビットストリームおよび前記メタデータを格納したファイルを生成するファイル生成部と
   を備える情報処理装置。
2. 前記再生情報には、前記ビットストリームを構成するVideo data unitに対し、再生時に用いる前記Video data unitの組み合わせを示す組み合わせ情報が含まれる
   請求項１に記載の情報処理装置。
3. 前記再生可否判断情報には、前記ビットストリームのパラメータセットが含まれる
   請求項２に記載の情報処理装置。
4. 前記再生可否判断情報には、さらに、前記Video data unitごとに対応するSub-Sampleのパラメータセットが含まれる
   請求項３に記載の情報処理装置。
5. 前記ファイル生成部は、前記再生可否判断情報を、Item Propertyに格納する
   請求項４に記載の情報処理装置。
6. 前記ファイル生成部は、前記再生可否判断情報に含まれるパラメータセットのうち、前記Video data unitごとのProfile情報を、Item Propertyに格納する
   請求項４に記載の情報処理装置。
7. 前記メタデータ生成部は、Attributeデータを選択して再生をするための前記メタデータを生成する
   請求項１に記載の情報処理装置。
8. 1itemである場合において前記メタデータはSubSampleItemPropertyであり、multi itemにすることで選択再生を可能にする
   請求項７に記載の情報処理装置。
9. 前記メタデータ生成部は、再生の組合せを示す前記メタデータを生成する
   請求項７に記載の情報処理装置。
10. 情報処理装置が、
    時間情報を持たない３Ｄデータから生成されたビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
    前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
    を含む情報処理方法。
11. 時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成するメタデータ生成部と、
    前記ビットストリームおよび前記メタデータを、格納したファイルを生成するファイル生成部と
    を備える情報処理装置。
12. 前記再生情報には、再生時に用いる前記ビットストリームの組み合わせを示すビットストリーム組み合わせ情報と、再生の起点を示す再生起点情報とを含む
    請求項１１に記載の情報処理装置。
13. 前記再生起点情報は、最初に再生すべきビットストリームを示すitem_idである
    請求項１２に記載の情報処理装置。
14. 前記再生情報は、更に、前記ビットストリームから前記３Ｄデータを再構成するための情報として、各前記ビットストリームのTypeを識別する情報であるV-PCC Unit Headerを含む
    請求項１２に記載の情報処理装置。
15. 前記再生可否判断情報は、各前記ビットストリームが前記３Ｄデータを構成するデータの一部であることを示す情報を含み、
    前記ファイル生成部は、前記再生可否判断情報をItem Propertyに格納する
    請求項１４に記載の情報処理装置。
16. 前記再生可否判断情報には、更に、各前記ビットストリームが前記３Ｄデータの構成であるとして処理できるか否かの処理を行うことを示す処理判断情報を含む
    請求項１５に記載の情報処理装置。
17. 前記再生可否判断情報には、item単体で表示不可である判断を可能にする判断情報として、さらに、hidden imageであることを示す情報を含み、
    前記ファイル生成部は、前記hidden imageを示す情報を、ItemInfoEntryに格納する
    請求項１５に記載の情報処理装置。
18. 情報処理装置が、
    時間情報を持たない３Ｄデータから生成された複数のビットストリームを再生するのに必要な再生情報、および、前記ビットストリームの再生の可否を判断するのに用いられる再生可否判断情報を含むメタデータを生成することと、
    前記ビットストリームおよび前記メタデータを格納したファイルを生成することと
    を含む情報処理方法。

Images