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

情報処理装置および方法 Download PDF

Info

Publication number
WO2022145357A1
WO2022145357A1 PCT/JP2021/048117 JP2021048117W WO2022145357A1 WO 2022145357 A1 WO2022145357 A1 WO 2022145357A1 JP 2021048117 W JP2021048117 W JP 2021048117W WO 2022145357 A1 WO2022145357 A1 WO 2022145357A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
file
data
tracks
track
Prior art date
Application number
PCT/JP2021/048117
Other languages
English (en)
French (fr)
Inventor
由佳 木山
遼平 高橋
光浩 平林
Original Assignee
ソニーグループ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニーグループ株式会社 filed Critical ソニーグループ株式会社
Priority to JP2022573052A priority Critical patent/JPWO2022145357A1/ja
Priority to EP21915217.0A priority patent/EP4270962A4/en
Priority to CN202180086825.8A priority patent/CN116636225A/zh
Priority to US18/268,620 priority patent/US20240046562A1/en
Publication of WO2022145357A1 publication Critical patent/WO2022145357A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • glTF The GL Transmission Format
  • glTF2.0 for example, as shown in FIG. 1, it is composed of a JSON format file (.glTF), a binary file (.bin), and an image file (.png, .jpg, etc.).
  • Binary files store binary data such as geometry and animation.
  • the image file stores data such as textures.
  • step S22 the glTF analysis unit 63 confirms the media associated with the 3D object (texture), the buffer that stores the media after processing, and the accessor.
  • step S23 the glTF analysis unit 63 notifies the media access function 52 of the information as a file acquisition request.
  • the multitrack structure is a method of storing geometry video subbitstreams, attribute video subbitstreams, occupancy video subbitstreams, and atlas subbitstreams in separate tracks. Since each video sub-bitstream is a conventional 2D video stream, it can be stored (managed) in the same manner as in the case of 2D.
  • FIG. 22 shows an example of file configuration when a multi-track structure is applied. As shown in FIG. 22, in the case of a multi-track structure, one track (V3C track) is information for accessing another track (also referred to as a component track) that stores a V3C bit stream. Stores track references. In other words, each component track is associated with a V3C track by this track reference.
  • the specification of the reference destination for some tracks among the plurality of tracks constituting the file container is omitted.
  • the reference relationship between tracks can be obtained in a file container such as ISOBMFF or a control file such as MPD. Therefore, the acquisition unit may omit the specification of the reference destination for some tracks in the track information. You can get the data of 3D object contents. Therefore, by doing so, it is possible to suppress an increase in the redundancy of the track information and suppress an increase in the amount of data in the scene description.
  • the data of the 3D object content may be a V3C (Visual Volumetric Video-based Coding) bitstream in which the point cloud is encoded by a method conforming to V-PCC (Video-based Point Cloud Compression).
  • V-PCC Video-based Point Cloud Compression
  • the file generation unit 114 applies the method 1 described above, and among a plurality of tracks of the file container that manages information about the data of the 3D object content, some tracks having information for accessing other tracks. You may generate a scene description file that contains track information that you specify as a reference.
  • the input unit 111 of the file generation device 100 acquires the data (3D data) of the 3D object in step S101.
  • the input unit 111 acquires point cloud data as this 3D data.
  • the 3D object content may be delivered by a method compliant with MPEG-DASH.
  • the control file may be an MPD.
  • step S205 the decoding unit 213 decodes the 3D object content data (bitstream of encoded data) acquired in step S204.
  • the file processing unit 212 is ⁇ 2.
  • various methods of this technique are applied to acquire a control file based on the track information, and the control file is specified by the track information. It refers to the tracks stored in the adaptation set and acquires the data of the 3D object content managed in all the tracks based on the reference relationship between the tracks. Therefore, by executing the client processing in this way, the client device 200 can suppress an increase in the redundancy of the track information of the scene description, and can suppress an increase in the amount of data in the scene description. can. Further, the client device 200 is described in ⁇ 2. It is possible to obtain the same effect as described in Suppressing redundancy of track information>.
  • the "POSITION" and “COLOR” properties of MPEG_vpcc can be omitted. It may be provided only when necessary.
  • FIG. 44 is a diagram showing an example of the configuration of the object in this case.
  • a new extension MPEG_vpcc
  • An attribute object (attribute) is provided in the MPEG_vpcc.
  • General-purpose objects (vpccattributes) that store information of arbitrary attributes are specified in the attribute object.
  • vpccattributes there are a property (acceId) that indicates the data to be stored, a property (attrId) that indicates the buffer that stores the data, and a property (attrType) that indicates the type of the data.
  • the data to be stored can be specified by using arbitrary information.
  • the above-mentioned method 2 (including method 2-1 to method 2-4) can be applied to any device.
  • it may be applied to a file generator that generates information for distribution of 3D object contents.
  • the configuration of the file generation device is the same as that described with reference to FIG. 28.
  • the file generation unit 114 may specify an object in mesh.primitives for storing information on the position, color, and attributes of the 3D object content. ..
  • step S402 the preprocessing unit 112 uses the information used to generate the scene description, which is the spatial arrangement information for arranging one or more 3D objects in the 3D space, from the data of the 3D objects acquired in step S401. To get. Then, the file generation unit 114 uses the information to generate a scene description file.
  • the scene description which is the spatial arrangement information for arranging one or more 3D objects in the 3D space
  • the file processing unit 212 applies the above method 2 and is based on information about attributes other than the color of the 3D object content stored in the object specified in the scene description file that describes the scene of the 3D object content. , You may get the data of that attribute.
  • the file processing unit 212 realizes such processing by controlling the file acquisition unit 211. That is, the file processing unit 212 can be said to be an acquisition unit.
  • the 3D object content may be a point cloud.
  • the scene description file may be described by a method conforming to glTF2.0.
  • the object may also be specified in mesh.primitives of the scene description file.
  • step S504 the decoding unit 213 decodes the coded data (V3C bit stream) acquired in step S503 and generates video data and the like. That is, the decoding unit 213 obtains atlas information, geometry frames, attribute frames, occupancy maps, and the like. The decoding unit 213 further reconstructs the point cloud using these obtained data, and generates the data (geometry, attributes, etc.) of the point cloud. Then, the decoding unit 213 stores the obtained point cloud data in a buffer designated by the scene description file.
  • step S505 the display information generation unit 214 acquires point cloud data (geometry, attributes, etc.) from the buffer based on the scene description. That is, the display information generation unit 214 acquires the position information, the color information, and other attribute information of the point cloud.
  • the display information generation unit 214 arranges the point cloud (3D object) in the three-dimensional space according to the scene description, renders the point cloud, and generates a display image.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Computer Graphics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本開示は、シーンディスクリプションのデータ量の増大を抑制することができるようにする情報処理装置および方法に関する。 3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含むシーン記述ファイルを生成する。また、そのファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含むシーン記述ファイル、および、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。本開示は、例えば、情報処理装置、または情報処理方法等に適用することができる。

Description

情報処理装置および方法
　本開示は、情報処理装置および方法に関し、特に、シーンディスクリプションのデータ量の増大を抑制することができるようにした情報処理装置および方法に関する。
　従来、3D（３次元）オブジェクトを３次元空間内に配置するためのシーンディスクリプション（Scene Description）のフォーマットであるglTF（The GL Transmission Format）（登録商標）2.0があった（例えば非特許文献１参照）。
　近年、MPEG（Moving Picture Experts Group）-I Scene Descriptionにおいて、glTF2.0を拡張し、Textureデータとして、符号化されISOBMFFなどに格納されたtimed mediaを扱う方法が提案された（例えば非特許文献２参照）。
　ところで、3次元空間上に位置情報と属性情報（色や反射等）を同時に持つ点の集合であるポイントクラウド（point cloud）の符号化方式として、ポイントクラウドをセグメンテーションして領域を形成し、その領域毎に平面投影して動画コーデックにより符号化するV-PCC（Video based Point Cloud Compression）が提案された（例えば、非特許文献３参照）。
　また、このV-PCCで符号化されたポイントクラウドの符号化データにより構成されるV3CビットストリームをISOBMFFに格納する方法が検討された（例えば、非特許文献４参照）。例えば、ISOBMFFが複数のトラックにより構成されるマルチトラックストラクチャの場合、シーンディスクリプションのMPEG_mediaにおいてV-PCCデータを指定する際は、全てのトラックが指定されていた。
Saurabh Bhatia, Patrick Cozzi, Alexey Knyazev, Tony Parisi, "Khronos glTF2.0", https://github.com/KhronosGroup/glTF/tree/master/specification/2.0, June 9, 2017 "Text of ISO/IEC CD 23090-14 Scene Description for MPEG Media", ISO/IEC JTC 1/SC 29/WG 3 N00026, 2020-12-07 "ISO/IEC FDIS 23090-5 Visual Volumetric Video-based Coding and Video-based Point Cloud Compression", ISO/IEC JTC 1/SC 29/ WG 11 N19579, 2020-09-21 "Text of ISO/IEC DIS 23090-10 Carriage of Visual Volumetric Video-based Coding Data", ISO/IEC JTC 1/SC 29/WG 11 N19285, 2020-06-1
　しかしながら、デコーダは、トラック間の参照関係をISOBMFF等から取得することができる。したがって、上述のような従来の方法の場合、シーンディスクリプションによる全トラックの指定が冗長であり、シーンディスクリプションのデータ量が不要に増大するおそれがあった。
　本開示は、このような状況に鑑みてなされたものであり、シーンディスクリプションのデータ量の増大を抑制することができるようにするものである。
　本技術の一側面の情報処理装置は、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部を備える情報処理装置である。
　本技術の一側面の情報処理方法は、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成する情報処理方法である。
　本技術の他の側面の情報処理装置は、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する取得部を備える情報処理装置である。
　本技術の他の側面の情報処理方法は、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する情報処理方法である。
　本技術の一側面の情報処理装置および方法においては、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルが生成される。
　本技術の他の側面の情報処理装置および方法においては、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータが取得される。
glTF2.0の主な構成例を示す図である。 glTFオブジェクトと参照関係の例を示す図である。 シーンディスクリプションの記述例を示す図である。 バイナリデータへのアクセス方法について説明する図である。 シーンディスクリプションの記述例を示す図である。 buffer object、buffer view object、accessor objectの関係を説明する図である。 buffer object、buffer view object、accessor objectの記述例を示す図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 シーンディスクリプションの記述例を示す図である。 オブジェクトの拡張方法について説明する図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 KHR_draco_mesh_compressionのシグナル内容について説明する図である。 シーンディスクリプションの記述例を示す図である。 クライアント処理の構成について説明する図である。 タイムドメタデータを扱うためのextensionの構成例を示す図である。 シーンディスクリプションの記述例を示す図である。 シーンディスクリプションの記述例を示す図である。 タイムドメタデータを扱うためのextensionの構成例を示す図である。 クライアントの主な構成例を示す図である。 クライアント処理の流れの例を説明するフローチャートである。 V-PCCの概要を説明する図である。 V3Cビットストリームを格納するISOBMFFの構造の例を示す図である。 MPDによるトラックの指定の例を示す図である。 シングルトラックストラクチャの場合のトラックの指定に関する記述例を示す図である。 マルチトラックストラクチャの場合のトラックの指定に関する記述例を示す図である。 トラックの指定方法について説明する図である。 マルチトラックストラクチャの場合のトラックの指定に関する記述例を示す図である。 ファイル生成装置の主な構成例を示すブロック図である。 ファイル生成処理の流れの例を示すフローチャートである。 クライアント装置の主な構成例を示すブロック図である。 クライアント処理の流れの例を示すフローチャートである。 クライアント処理の流れの例を示すフローチャートである。 クライアント処理の構成について説明する図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 クライアント処理の流れの例を示すフローチャートである。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 クライアント処理の流れの例を示すフローチャートである。 色以外のアトリビュートの指定の様子の例を示す図である。 アトリビュートの指定方法について説明する図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 シーンディスクリプションの記述例を示す図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 シーンディスクリプションの記述例を示す図である。 シーンディスクリプションのオブジェクトの構成例を説明する図である。 シーンディスクリプションの記述例を示す図である。 ファイル生成処理の流れの例を示すフローチャートである。 クライアント処理の流れの例を示すフローチャートである。 クライアント処理の流れの例を示すフローチャートである。 コンピュータの主な構成例を示すブロック図である。
　以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
　１．MPEG-I Scene Description
　２．トラック情報の冗長性の抑制
　３．アトリビュートの指定
　４．付記
　＜１．MPEG-I Scene Description＞
　　＜技術内容・技術用語をサポートする文献等＞
　本技術で開示される範囲は、実施の形態に記載されている内容だけではなく、出願当時において公知となっている以下の非特許文献等に記載されている内容や以下の非特許文献において参照されている他の文献の内容等も含まれる。
　非特許文献１：（上述）
　非特許文献２：（上述）
　非特許文献３：（上述）
　非特許文献４：（上述）
　つまり、上述の非特許文献に記載されている内容や、上述の非特許文献において参照されている他の文献の内容等も、サポート要件を判断する際の根拠となる。例えば、非特許文献１乃至非特許文献３に記載されるglTF2.0やそのextensionなどのシンタックスや用語が本開示において直接的に定義されていない場合でも、本開示の範囲内であり、請求の範囲のサポート要件を満たすものとする。また、例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、本開示において直接的に定義されていない場合でも、本開示の範囲内であり、請求の範囲のサポート要件を満たすものとする。
　　＜gltf2.0＞
　従来、例えば、非特許文献１に記載のように、3D（３次元）オブジェクトを３次元空間内に配置するためのフォーマットであるglTF（The GL Transmission Format）（登録商標）2.0があった。glTF2.0では、例えば図１に示されるように、JSONフォーマットファイル（.glTF）と、バイナリファイル（.bin）と、イメージファイル（.pngや.jpg等）とにより構成される。バイナリファイルは、ジオメトリやアニメーション等のバイナリデータを格納する。イメージファイルは、テクスチャ等のデータを格納する。
　JSONフォーマットファイルは、JSON（JavaScript（登録商標） Object Notation）で記述されたシーンディスクリプションファイル（scene description file）である。シーンディスクリプションとは、3Dコンテンツのシーン（の説明）を記述するメタデータである。このシーンディスクリプションの記述により、どのようなシーンであるかが定義される。シーンディスクリプションファイルは、そのようなシーンディスクリプションを格納するファイルである。本開示においては、シーンディスクリプションファイルのことをシーン記述ファイルとも称する。
　JSONフォーマットファイルの記述は、キー（KEY）とバリュー（VALUE）のペアの羅列により構成される。以下にその書式の例を示す。
　“KEY”:”VALUE”
　キーは文字列により構成される。バリューは数値、文字列、真偽値、配列、オブジェクト、またはnull等により構成される。
　また、複数のキーとバリューのペア（“KEY”:”VALUE”）を、｛｝（中かっこ）を用いてまとめることができる。この中かっこでまとめたものをJSONオブジェクトとも称する。以下にその書式の例を示す。
　“user”:{"id":1, "name":"tanaka”}
　この例の場合、キー（user）に対応するバリューとして、"id":1のペアと"name":"tanaka”のペアをまとめたJSONオブジェクトが定義されている。
　また、０個以上のバリューを、[]（大かっこ）を用いて配列化することもできる。この配列をJSON配列とも称する。このJSON配列の要素として、例えば、JSONオブジェクトを適用することもできる。以下にその書式の例を示す。
　test":["hoge", "fuga", "bar"]
　"users":[{"id":1, "name":"tanaka"},{"id":2,"name":"yamada"},{"id":3, "name":"sato"}]
　JSONフォーマットファイルの最上位に記載できるglTFオブジェクト（glTF object）と、それらが持てる参照関係を図２に示す。図２に示されるツリー構造の長丸がオブジェクトを示し、そのオブジェクト間の矢印が参照関係を示している。図２に示されるように、"scene"、"node"、"mesh"、"camera"、"skin"、"material"、"texture"等のオブジェクトがJSONフォーマットファイルの最上位に記述される。
　このようなJSONフォーマットファイル（シーンディスクリプション）の記述例を図３に示す。図３のJSONフォーマットファイル２０は、最上位の一部の記述例を示している。このJSONフォーマットファイル２０において、使用されるトップレベルオブジェクト（top-level object）２１は、全て最上位に記述される。このトップレベルオブジェクト２１は、図２に示されるglTFオブジェクトである。また、JSONフォーマットファイル２０においては、矢印２２として示されるように、オブジェクト（object）間の参照関係が示される。より具体的には、上位オブジェクトのプロパティ（property）で、参照するオブジェクトの配列の要素のインデックス（index）を指定することによりその参照関係が示される。
　図４は、バイナリデータへのアクセス方法について説明する図である。図４に示されるように、バイナリデータは、バッファオブジェクト（buffer object）に格納される。つまり、バッファオブジェクトにおいてバイナリデータにアクセスするための情報（例えばURI（Uniform Resource Identifier）等）が示される。JSONフォーマットファイルにおいては、図４に示されるように、例えばメッシュ（mesh）、カメラ（camera）、スキン（skin）等のオブジェクトから、そのバッファオブジェクトに対して、アクセサオブジェクト（accessor object）とバッファビューオブジェクト（bufferView object）を介してアクセスすることができる。
　つまり、メッシュ（mesh）、カメラ（camera）、スキン（skin）等のオブジェクトにおいては、参照するアクセサオブジェクトが指定される。JSONフォーマットファイルにおけるメッシュオブジェクト（mesh）の記述例を図５に示す。例えば、図５のように、メッシュオブジェクトにおいては、NORMAL、POSITION、TANGENT、TEXCORD_0等の頂点の属性（アトリビュート（attribute））がキーとして定義され、その属性毎に、参照するアクセサオブジェクトがバリューとして指定されている。
　バッファオブジェクト、バッファビューオブジェクト、アクセサオブジェクトの関係を図６に示す。また、JSONフォーマットファイルにおけるそれらのオブジェクトの記述例を図７に示す。
　図６において、バッファオブジェクト４１は、実データであるバイナリデータにアクセスするための情報（URI等）と、そのバイナリデータのデータ長（例えばバイト長）を示す情報とを格納するオブジェクトである。図７のＡは、そのバッファオブジェクト４１の記述例を示している。図７のＡに示される「"bytelength":102040」は、図６に示されるように、バッファオブジェクト４１のバイト長が102040バイト（bytes）であることを示している。また、図７のＡに示される「"uri":"duck.bin"」は、図６に示されるように、バッファオブジェクト４１のURIが"duck.bin"であることを示している。
　図６において、バッファビューオブジェクト４２は、バッファオブジェクト４１において指定されたバイナリデータのサブセット（subset）領域に関する情報（つまりバッファオブジェクト４１の一部の領域に関する情報）を格納するオブジェクトである。図７のＢは、そのバッファビューオブジェクト４２の記述例を示している。図６や図７のＢに示されるように、バッファビューオブジェクト４２は、例えば、そのバッファビューオブジェクト４２が属するバッファオブジェクト４１の識別情報、そのバッファオブジェクト４１内におけるそのバッファビューオブジェクト４２の位置を示すオフセット（例えばバイトオフセット）、そのバッファビューオブジェクト４２のデータ長（例えばバイト長）を示すレングス（例えばバイトレングス）等の情報を格納する。
　図７のＢに示されるように、バッファビューオブジェクトが複数存在する場合、そのバッファビューオブジェクト毎（つまりサブセット領域毎）に情報が記述される。例えば、図７のＢにおいて上側に示される、「"buffer":0」、「"bytelength":25272」、「"byteOffset":0」等の情報は、図６においてバッファオブジェクト４１内に示される１つ目のバッファビューオブジェクト４２（bufferView[0]）の情報である。また、図７のＢにおいて下側に示される、「"buffer":0」、「"bytelength":76768」、「"byteOffset":25272」等の情報は、図６においてバッファオブジェクト４１内に示される２つ目のバッファビューオブジェクト４２（bufferView[1]）の情報である。
　図７のＢに示される１つ目のバッファビューオブジェクト４２（bufferView[0]）の「"buffer":0」は、図６に示されるように、そのバッファビューオブジェクト４２（bufferView[0]）が属するバッファオブジェクト４１の識別情報が「0」（Buffer[0]）であることを示している。また、「"bytelength":25272」は、そのバッファビューオブジェクト４２（bufferView[0]）のバイト長が25272バイトであることを示している。さらに、「"byteOffset":0」は、そのバッファビューオブジェクト４２（bufferView[0]）のバイトオフセットが0バイトであることを示している。
　図７のＢに示される２つ目のバッファビューオブジェクト４２（bufferView[1]）の「"buffer":0」は、図６に示されるように、そのバッファビューオブジェクト４２（bufferView[0]）が属するバッファオブジェクト４１の識別情報が「0」（Buffer[0]）であることを示している。また、「"bytelength":76768」は、そのバッファビューオブジェクト４２（bufferView[0]）のバイト長が76768バイトであることを示している。さらに、「"byteOffset":25272」は、そのバッファビューオブジェクト４２（bufferView[0]）のバイトオフセットが25272バイトであることを示している。
　図６において、アクセサオブジェクト４３は、バッファビューオブジェクト４２のデータの解釈方法に関する情報を格納するオブジェクトである。図７のＣは、そのアクセサオブジェクト４３の記述例を示している。図６や図７のＣに示されるように、アクセサオブジェクト４３は、例えば、そのアクセサオブジェクト４３が属するバッファビューオブジェクト４２の識別情報、そのバッファビューオブジェクト４２の、バッファオブジェクト４１内における位置を示すオフセット（例えばバイトオフセット）、そのバッファビューオブジェクト４２のコンポーネントタイプ、そのバッファビューオブジェクト４２に格納されるデータ数、そのバッファビューオブジェクト４２に格納されるデータのタイプ等の情報を格納する。これらの情報は、バッファビューオブジェクト毎に記述される。
　図７のＣの例では、「"bufferView":0」、「"byteOffset":0」、「"componentType":5126」、「"count":2106」、「"type":"VEC3"」等の情報が示されている。「"bufferView":0」は、図６に示されるように、そのアクセサオブジェクト４３が属するバッファビューオブジェクト４２の識別情報が「0」（bufferView[0]）であることを示している。また、「"byteOffset":0」は、そのバッファビューオブジェクト４２（bufferView[0]）のバイトオフセットが0バイトであることを示している。さらに、「"componentType":5126」は、コンポーネントタイプが、FLOAT型（OpenGLマクロ定数）であることを示している。また、「"count":2106」は、そのバッファビューオブジェクト４２（bufferView[0]）に格納されるデータが2106個であることを示している。さらに、「"type":"VEC3"」は、そのバッファビューオブジェクト４２（bufferView[0]）に格納されるデータ（のタイプ）が３次元ベクトルであることを示している。
　イメージ（image）以外のデータへのアクセスは、全てこのアクセサオブジェクト４３への参照により（アクセサのインデックスを指定することにより）定義される。
　次に、このようなglTF2.0に準拠するシーンディスクリプション（JSONフォーマットファイル）において、ポイントクラウドの3Dオブジェクトを指定する方法について説明する。ポイントクラウドは、立体構造物（３次元形状のオブジェクト）を多数の点の集合として表現する3Dコンテンツである。ポイントクラウドのデータは、各点の位置情報（ジオメトリ（geometry）とも称する）と属性情報（アトリビュート（attribute）とも称する）とにより構成される。アトリビュートは任意の情報を含むことができる。例えば、各ポイントの色情報、反射率情報、法線情報等がアトリビュートに含まれるようにしてもよい。このようにポイントクラウドは、データ構造が比較的単純であるとともに、十分に多くの点を用いることにより任意の立体構造物を十分な精度で表現することができる。
　ポイントクラウドが時間方向に変化しない（静的であるとも称する）場合、glTF2.0のmesh.primitives objectを用いて3Dオブジェクトを指定する。図８は、ポイントクラウドが静的な場合の、シーンディスクリプションにおけるオブジェクトの構成例を示す図である。図９は、そのシーンディスクリプションの記述例を示す図である。
　図９に示されるように、primitives objectのmodeは、データ（data）がポイントクラウドの点（point）として扱われることを示す0に指定される。図８や図９に示されるように、mesh.primitives内のattributesオブジェクトのポジションプロパティ（POSITION property）において、点（Point）の位置情報を格納するバッファ（buffer）へのアクセサ（accessor）が指定される。同様に、attributesオブジェクトのカラープロパティ（COLOR property）において、点（Point）の色情報を格納するバッファ（buffer）へのアクセサ（accessor）が指定される。バッファ（buffer）とバッファビュー（bufferView）は１つであってもよい（１つのファイル（file）にデータ（data）が格納されてもよい）。
　次に、このようなシーンディスクリプションのオブジェクトの拡張について説明する。glTF2.0の各オブジェクトは、拡張オブジェクト（extension object）内に新たに定義されたオブジェクトを格納することができる。図１０は、新たに定義されたオブジェクト（ExtensionExample）を規定する場合の記述例を示す。図１０に示されるように、新たに定義されたextensionを使用する場合、“extensionUsed”と”extensionRequired”にそのextension object名（図１０の例の場合、ExtensionExample）が記述される。これにより、このextensionが、使用されるなextensionであること、または、ロード（load）に必要なextensionであることが示される。
　このオブジェクトの拡張例について説明する。図１１は、mesh.primitives内にextensionを規定する場合の、シーンディスクリプションにおけるオブジェクトの構成例を示す図である。図１１に示されるように、この例においては、mesh.primitives内にHKR_draco_mesh_compression extensionオブジェクトが規定されている。このHKR_draco_mesh_compression extensionは、draco mesh圧縮されたメッシュデータ（mesh data）をglTFのmeshオブジェクトのデータとして使用するための拡張オブジェクトである。dracoは、メッシュ（mesh）の符号化方式の１つである。
　HKR_draco_mesh_compression extensionには、圧縮データ（Compressed data）を指定するプロパティ（bufferView）が格納される。図１２に示されるように、復号部（Draco mesh decoder）は、この情報に基づいて圧縮データを取得することができる。また、HKR_draco_mesh_compression extensionには、その圧縮データを復号（decompress）して得られる複数の属性data（Raw data A, B）を、glTFのprimitives.attributesで示される属性データとして使用するため紐づけ情報をもつオブジェクト（attributes）が格納される。このattributeのプロパティの名称は、primitives.attributes内のプロパティの名称と同じものが使用される。また、そのプロパティの値は、復号部（draco mesh decoder）内で扱われるメッシュデータのattribute ID値が設定される。図１３は、このmeshオブジェクトの記述例を示す図である。
　　＜クライアント処理＞
　次に、MPEG-I Scene Descriptionにおけるクライアント装置の処理について説明する。クライアント装置は、シーンディスクリプションを取得し、そのシーンディスクリプションに基づいて3Dオブジェクトのデータを取得し、そのシーンディスクリプションや3Dオブジェクトのデータを用いて表示画像を生成する。
　非特許文献２に記載のように、クライアント装置では、プレゼンテーションエンジンやメディアアクセスファンクション等が処理を行う。例えば、図１４に示されるように、クライアント装置５０のプレゼンテーションエンジン（Presentation Engine）５１が、シーンディスクリプションの初期値やそのシーンディスクリプションを更新するための情報（以下、更新情報とも称する）を取得し、処理対象時刻のシーンディスクリプションを生成する。そして、プレゼンテーションエンジン５１は、そのシーンディスクリプションを解析し、再生するメディア（動画や音声等）を特定する。そして、プレゼンテーションエンジン５１は、メディアアクセスAPI（Media Access API（Application Program Interface））経由で、メディアアクセスファンクション（Media Access Function）５２に対してそのメディアの取得を要求する。また、プレゼンテーションエンジン５１は、パイプライン処理の設定やバッファの指定等も行う。
　メディアアクセスファンクション５２は、プレゼンテーションエンジン５１から要求されたメディアの各種データをクラウド（Cloud）やローカルストレージ（Local Storage）等から取得する。メディアアクセスファンクション５２は、取得したメディアの各種データ（符号化データ）をパイプライン（Pipeline）５３に供給する。
　パイプライン５３は、供給されたメディアの各種データ（符号化データ）を、パイプライン処理により復号し、その復号結果をバッファ（Buffer）５４に供給する。バッファ５４は、供給されたメディアの各種データを保持する。
　プレゼンテーションエンジン５１は、バッファ５４に保持されているメディアの各種データを用いてレンダリング（Rendering）等を行う。
　　＜Timed mediaの適用＞
　近年、例えば、非特許文献２に示されるように、MPEG-I Scene Descriptionにおいて、glTF2.0を拡張し、３Ｄオブジェクトコンテンツとしてタイムドメディア（Timed media）を適用することが検討されている。タイムドメディアとは、２次元画像における動画像のように、時間軸方向に変化するメディアデータである。
　glTFは、メディアデータ（3Dオブジェクトコンテンツ）として、静止画データのみ適用可能であった。つまり、glTFは、動画像のメディアデータには対応していなかった。3Dオブジェクトを動かす場合は、アニメーション（時間軸に沿って静止画を切り替える方法）が適用されていた。
　MPEG-I Scene Descriptionでは、そのglTF2.0を適用し、シーンディスクリプションとしてJSONフォーマットファイルを適用し、さらに、メディアデータとして、タイムドメディア（例えばビデオデータ）を扱うことができるようにglTFを拡張することが検討されている。タイムドメディアを扱うために、例えば以下のような拡張が行われる。
　図１５は、タイムドメディアを扱うための拡張について説明する図である。図１５の例において、MPEGメディアオブジェクト（MPEG_media）は、glTFのextensionであり、例えば、uri, track, renderingRate, startTime等、ビデオデータ等のMPEGメディアの属性を指定するオブジェクトである。
　また、図１５に示されるように、テクスチャオブジェクト（texture）の拡張オブジェクト（extensions）として、MPEGテクスチャビデオオブジェクト（MPEG_texture_video）が設けられる。そのMPEGテクスチャビデオオブジェクトには、アクセスするバッファオブジェクトに対応するアクセサの情報が格納される。すなわち、MPEGテクスチャビデオオブジェクトは、MPEGメディアオブジェクト（MPEG_media）で指定されたテクスチャメディア（texture media）が復号されて格納されるバッファ（buffer）に対応するアクセサ（accessor）のインデックスを指定するオブジェクトである。
　図１６は、タイムドメディアを扱うための拡張について説明するための、シーンディスクリプションにおけるMPEGメディアオブジェクト（MPEG_media）およびMPEGテクスチャビデオオブジェクト（MPEG_texture_video）の記述例を示す図である。図１６の例の場合、上から２行目において下記のように、テクスチャオブジェクト（texture）の拡張オブジェクト（extensions）として、MPEGテクスチャビデオオブジェクト（MPEG_texture_video）が設定されている。そして、そのMPEGビデオテクスチャオブジェクトのバリューとして、アクセサのインデックス（この例では「2」）が指定されている。
"texture":[{"sampler":0, "source":1, "extensions":{"MPEG_texture_video ":"accessor":2}}],
　また、図１６の例の場合、上から７行目乃至１６行目において下記のように、glTFの拡張オブジェクト（extensions）として、MPEGメディアオブジェクト（MPEG_media）が設定されている。そして、そのMPEGメディアオブジェクトのバリューとして、例えば、そのMPEGメディアオブジェクトの符号化やURI等といった、MPEGメディアオブジェクトに関する様々な情報が格納されている。
"MPEG_media":{
  "media":[
        {"name":"source_1", "renderingRate":30.0, "startTime":9.0, "timeOffset":0.0,
          "loop":"true", "controls":"false",
          "alternatives":[{"mimeType":"video/mp4;codecs=\"avc1.42E01E\"", "uri":"video1.mp4",
                                     "tracks":[{"track":""#track_ID=1"}]
                         }]
        }
  ]
}
　また、各フレームデータはデコードされ順次バッファに格納されるが、その位置などが変動するため、シーンディスクリプションには、その変動する情報を格納して、レンダラ（renderer）がデータを読みだせるようにする仕組みが設けられる。例えば、図１５に示されるように、バッファオブジェクト（buffer）の拡張オブジェクト（extensions）として、MPEGバッファサーキュラオブジェクト（MPEG_buffer_circular）が設けられる。そのMPEGバッファサーキュラオブジェクトには、バッファオブジェクト内にデータを動的に格納するための情報が格納される。例えば、バッファヘッダ（bufferHeader）のデータ長を示す情報や、フレーム数を示す情報等といった情報がこのMPEGバッファサーキュラオブジェクトに格納される。なお、バッファヘッダは、例えば、インデックス（index）、格納されるフレームデータのタイムスタンプやデータ長等といった情報を格納する。
　また、図１５に示されるように、アクセサオブジェクト（accessor）の拡張オブジェクト（extensions）として、MPEGアクセサタイムドオブジェクト（MPEG_timed_accessor）が設けられる。この場合、メディアデータは動画なので時間方向に参照するバッファビューオブジェクト（bufferView）が変化し得る（位置が変動し得る）。そこで、その参照するバッファビューオブジェクトを示す情報が、このMPEGアクセサタイムドオブジェクトに格納される。例えば、MPEGアクセサタイムドオブジェクトには、タイムドアクセサインフォメーションヘッダ（timedAccessor information header）が記述されるバッファビューオブジェクト（bufferView）への参照を示す情報が格納される。なお、タイムドアクセサインフォメーションヘッダは、例えば、動的に変化するアクセサオブジェクトとバッファビューオブジェクト内の情報を格納するヘッダ情報である。
　図１７は、タイムドメディアを扱うための拡張について説明するための、シーンディスクリプションにおけるMPEGバッファサーキュラオブジェクト（MPEG_buffer_circular）およびMPEGアクセサタイムドオブジェクト（MPEG_accessor_timed）の記述例を示す図である。図１７の例の場合、上から５行目において下記のように、アクセサオブジェクト（accessors）の拡張オブジェクト（extensions）として、MPEGアクセサタイムドオブジェクト（MPEG_accessor_timed）が設定されている。そして、そのMPEGアクセサタイムドオブジェクトのバリューとして、バッファビューオブジェクトのインデックス（この例では「1」）、アップデートレート（updataRate）、不変の情報（immutable）等のパラメータとその値が指定されている。
"MPEG_accessor_timed":{"bufferView":1, "updateRate":25.0, "immutable":1,"}
　また、図１７の例の場合、上から１３行目において下記のように、バッファオブジェクト（buffer）の拡張オブジェクト（extensions）として、MPEGバッファサーキュラオブジェクト（MPEG_buffer_circular）が設定されている。そして、そのMPEGバッファサーキュラオブジェクトのバリューとして、バッファフレームカウント（count）、ヘッダ長（headerLength）、アップデートレート（updataRate）等のパラメータとその値が指定されている。
"MPEG_buffer_circular":{"count":5, "headerLength":12, "updateRate":25.0}
　図１８は、タイムドメディアを扱うための拡張について説明するための図である。図１８において、MPEGアクセサタイムドオブジェクトやMPEGバッファサーキュラオブジェクトと、アクセサオブジェクト、バッファビューオブジェクト、およびバッファオブジェクトとの関係の例を示す。
　バッファオブジェクトのMPEGバッファサーキュラオブジェクトには、上述したように、バッファフレームカウント（count）、ヘッダ長（headerLength）、アップデートレート（updataRate）等といった、バッファオブジェクトによって示されるバッファ領域に時間変化するdataを格納するのに必要な情報が格納される。また、そのバッファ領域のヘッダであるバッファヘッダ（bufferHeader）には、インデックス（idex）、タイムスタンプ（timestamp）、データ長（length）等のパラメータが格納される。
　アクセサオブジェクトのMPEGアクセサタイムドオブジェクトには、上述したように、バッファビューオブジェクトのインデックス（bufferView）、アップデートレート（updataRate）、不変の情報（immutable）等といった、参照するバッファビューオブジェクトに関する情報が格納される。また、このMPEGアクセサタイムドオブジェクトには、参照するタイムドアクセサインフォメーションヘッダが格納されるバッファビューオブジェクトに関する情報が格納される。タイムドアクセサインフォメーションヘッダには、タイムスタンプデルタ（timestamp_delta）、アクセサオブジェクトの更新データ、バッファビューオブジェクトの更新データ等が格納され得る。
　　＜MPEG_texture_video使用時のクライアント処理＞
　シーンディスクリプションは、１つ以上の3Dオブジェクトを3D空間に配置するための空間配置情報である。このシーンディスクリプションは、時間軸に沿ってその内容を更新することができる。つまり、時間の経過とともに、3Dオブジェクトの配置を更新することができる。その際のクライアント装置において行われるクライアント処理について説明する。
　図１９は、クライアント装置の、クライアント処理に関する主な構成例を示し、図２０は、そのクライアント処理の流れの例を示すフローチャートである。図１９に示されるように、クライアント装置は、プレゼンテーションエンジン（PresentaionEngine（以下、PEとも称する））５１、メディアアクセスファンクション（MediaAccessFuncon（以下、MAFとも称する））５２、パイプライン（Pipeline）５３、およびバッファ（Buffer）５４を有する。
　クライアント処理が開始されると、プレゼンテーションエンジン（PE）５１のglTF解析部６３は、PE処理を開始し、ステップＳ２１において、シーンディスクリプションファイルであるSD(glTF)ファイル６２を取得し、そのシーンディスクリプションを解析（parse）する。
　ステップＳ２２において、glTF解析部６３は、3Dオブジェクト（texture）に紐づくメディア（media）と、そのメディアを処理後に格納するバッファ（buffer）と、アクセサ（accessor）を確認する。ステップＳ２３において、glTF解析部６３は、ファイル取得要求として、メディアアクセスファンクション５２にその情報を通知する。
　メディアアクセスファンクション（MAF）５２は、MAF処理を開始し、ステップＳ１１において、その通知を取得する。ステップＳ１２において、メディアアクセスファンクション５２は、その通知に基づいてメディア（3Dオブジェクトファイル（mp4））を取得する。
　ステップＳ１３において、メディアアクセスファンクション５２は、取得したメディア（3Dオブジェクトファイル（mp4））を復号する。ステップＳ１４において、メディアアクセスファンクション５２は、復号して得られたメディアのデータを、プレゼンテーションエンジン（PE５１）からの通知に基づいて、バッファ５４に格納する。
　ステップＳ２４において、プレゼンテーションエンジン５１のレンダリング（Rendering）処理部６４は、そのデータを適切なタイミングにおいてバッファ５４から読み出す（取得する）。ステップＳ２５において、レンダリング処理部６４は、取得したデータを用いてレンダリングを行い、表示用画像を生成する。
　メディアアクセスファンクション５２は、ステップＳ１３およびステップＳ１４の処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。また、プレゼンテーションエンジン５１のレンダリング処理部６４は、ステップＳ２４およびステップＳ２５の処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。全てのフレームについて処理が終了すると、メディアアクセスファンクション５２はMAF処理を終了し、プレゼンテーションエンジン５１はPE処理を終了する。つまり、クライアント処理が終了する。
　　＜V-PCCの概要＞
　ところで、例えば非特許文献３に記載のように、３次元空間上に位置情報と属性情報（色や反射等）を同時に持つ点の集合であるポイントクラウド（point cloud）の符号化方式として、ポイントクラウドをセグメンテーションして領域を形成し、その領域毎に平面投影して動画コーデックにより符号化するV-PCC（Video based Point Cloud Compression）が提案された。
　V-PCCでは、ポイントクラウドのジオメトリやアトリビュートが、小領域毎に２次元平面に投影される。本開示において、この小領域を部分領域という場合がある。このジオメトリやアトリビュートが２次元平面に投影された画像を投影画像とも称する。また、この小領域（部分領域）毎の投影画像をパッチ（patch）と称する。例えば、図２１のＡのオブジェクト７１（3Dデータ）が、図２１のＢに示されるようなパッチ７２（2Dデータ）に分解される。ジオメトリのパッチの場合、各画素値は、ポイントの位置情報を示す。ただし、その場合、ポイントの位置情報は、その投影面に対して垂直方向（奥行方向）の位置情報（デプス値（Depth））として表現される。
　そして、このように生成された各パッチがビデオシーケンスのフレーム画像（ビデオフレームとも称する）内に配置される。ジオメトリのパッチが配置されたフレーム画像をジオメトリビデオフレーム（Geometry video frame）とも称する。また、アトリビュートのパッチが配置されたフレーム画像をアトリビュートビデオフレーム（Attribute video frame）とも称する。例えば、図２１のＡのオブジェクト７１から、図２１のＣに示されるようなジオメトリのパッチ７３が配置されたジオメトリビデオフレーム８１と、図２１のＤに示されるようなアトリビュートのパッチ７４が配置されたアトリビュートビデオフレーム８２が生成される。例えば、ジオメトリビデオフレーム８１の各画素値は、上述のデプス値を示す。
　そして、これらのビデオフレームが、例えばAVC（Advanced Video Coding）やHEVC（High Efficiency Video Coding）等といった２次元画像用の符号化方法で符号化される。つまり、３次元構造を表す3Dデータであるポイントクラウドデータを、２次元画像用のコーデックを用いて符号化することができる。
　なお、オキュパンシーマップ（オキュパンシー画像とも称する）を用いることもできる。オキュパンシーマップは、ジオメトリビデオフレームやアトリビュートビデオフレームのNxN画素毎に、投影画像（パッチ）の有無を示すマップ情報である。例えば、オキュパンシーマップは、ジオメトリビデオフレームやアトリビュートビデオフレームの、パッチが存在する領域（NxN画素）を値「１」で示し、パッチが存在しない領域（NxN画素）を値「０」で示す。
　デコーダは、このオキュパンシーマップを参照することにより、パッチが存在する領域であるか否かを把握することができるので、符号化・復号により生じるノイズ等の影響を抑制することができ、より正確に3Dデータを復元することができる。例えば、符号化・復号によりデプス値が変化しても、デコーダは、オキュパンシーマップを参照することにより、パッチが存在しない領域のデプス値を無視することができる。つまり、デコーダは、オキュパンシーマップを参照することにより、3Dデータの位置情報として処理しないようにすることができる。
　例えば、ジオメトリビデオフレーム１１およびアトリビュートビデオフレーム１２に対して、図２１のＥに示されるようなオキュパンシーマップ８３を生成してもよい。オキュパンシーマップ８３において、白の部分が値「１」を示し、黒の部分が値「０」を示している。
　このようなオキュパンシーマップが、ジオメトリビデオフレームやアトリビュートビデオフレームとは別のデータ（ビデオフレーム）として符号化され、復号側に伝送され得る。つまり、オキュパンシーマップも、ジオメトリビデオフレームやアトリビュートビデオフレームと同様に、AVCやHEVC等の２次元画像用の符号化方法で符号化することができる。
　ジオメトリビデオフレームを符号化して生成される符号化データ（ビットストリーム）をジオメトリビデオサブビットストリーム（geometry video sub-bitstream）とも称する。アトリビュートビデオフレームを符号化して生成される符号化データ（ビットストリーム）をアトリビュートビデオサブビットストリーム（attribute video sub-bitstream）とも称する。オキュパンシーマップを符号化して生成される符号化データ（ビットストリーム）をオキュパンシーマップビデオサブビットストリーム（occupancy map video sub-bitstream）とも称する。なお、ジオメトリビデオサブビットストリーム、アトリビュートビデオサブビットストリーム、オキュパンシーマップビデオサブビットストリームを互いに区別して説明する必要が無い場合、ビデオサブビットストリーム（video sub-bitstream）と称する。
　さらに、パッチ（2Dデータ）からポイントクラウド（3Dデータ）を再構成するための情報であるアトラス情報（atlas）が符号化され、復号側に伝送される。アトラス情報の符号化方法（および復号方法）は任意である。アトラス情報を符号化して生成される符号化データ（ビットストリーム）をアトラスサブビットストリーム（atlas sub-bitstream）とも称する。
　なお、以下において、ポイントクラウド（のオブジェクト）は、２次元画像の動画像のように、時間方向に変化し得る（動的であるとも称する）ものとする。つまり、ジオメトリデータやアトリビュートデータは、時間方向の概念を有し、２次元画像の動画像のように、所定の時間毎にサンプリングされたデータとする。なお、２次元画像のビデオフレームのように、各サンプリング時刻のデータをフレームと称する。つまり、ポイントクラウドデータ（ジオメトリデータやアトリビュートデータ）は、２次元画像の動画像のように、複数フレームにより構成されるものとする。本開示において、このポイントクラウドのフレームのことを、ポイントクラウドフレームとも称する。V-PCCの場合、このような動画像（複数フレーム）のポイントクラウドであっても、各ポイントクラウドフレームをビデオフレーム化してビデオシーケンスとすることで、動画像の符号化方式を用いて高効率に符号化することができる。
　　＜ISOBMFFへの格納方法＞
　また、例えば非特許文献４に記載のように、このV-PCCで符号化されたポイントクラウドの符号化データにより構成されるV3CビットストリームをISOBMFFに格納する方法が検討された。非特許文献４には、V3CビットストリームをISOBMFFに格納する方法として、シングルトラックストラクチャ（single track structure）とマルチトラックストラクチャ（multi-track structure）との２種類が規定されている。
　シングルトラックストラクチャは、V3Cビットストリームを１つのトラックに格納する方法である。つまりこの場合、ジオメトリビデオサブビットストリーム、アトリビュートビデオサブビットストリーム、オキュパンシーマップビデオサブビットストリーム、およびアトラスサブビットストリームが互いに同一のトラックに格納される。
　マルチトラックストラクチャは、ジオメトリビデオサブビットストリーム、アトリビュートビデオサブビットストリーム、オキュパンシービデオサブビットストリーム、およびアトラスサブビットストリームをそれぞれ個別のトラック（track）に格納する方法である。各ビデオサブビットストリームは、従来の2Dビデオストリームであるので、2Dの場合と同様の手法で格納（管理）することができる。マルチトラックストラクチャを適用する場合のファイルの構成例を図２２に示す。図２２に示されるように、マルチトラックストラクチャの場合、１つのトラック（V3Cトラック）に、V3Cビットストリームを格納する他のトラック（コンポーネントトラック（component track）とも称する）にアクセスするための情報であるトラックリファレンスが格納される。つまり、各コンポーネントトラックは、このトラックリファレンスによりV3Cトラックに紐づけられている。
　なお、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP（Hypertext Transfer Protocol））を適用して3Dオブジェクトコンテンツを配信する場合、その配信を制御するための制御ファイルであるMPD（Media Presentation Description）に、V-PCCを構成するAdaptationSetを取りまとめるための情報として、preselection elementやpreselection Descriptorを格納してもよい。図２３にその記述例を示す。つまり、この場合、MPDのこれらの情報により、V3Cビットストリームを構成する各ビットストリームが互いに関連付けられる。
　　＜トラック情報＞
　シーンディスクリプションのMPEGメディアオブジェクト（MPEG_media）には、3Dオブジェクトコンテンツのデータ（V3Cビットストリーム）を取得するための情報が格納される。例えば、V3Cビットストリームを格納するファイル（例えば、MP4ファイル）、または、そのV3Cビットストリームの配信を制御するための制御ファイル（例えば、MPD）を、uriによって指定する情報が格納される。また、V3Cビットストリームを格納するトラックを参照先として指定するトラック情報（tracks配列）が格納される。このトラック情報は、トラックプロパティ（track property）において、トラックの識別情報（track ID）（MPDの場合はAdaptationSet ID）を用いて参照先とするトラックを指定する。
　図２４は、ISOBMFFがシングルトラックストラクチャの場合のMPEGメディアオブジェクト（MPEG_media）の記述例を示す図である。図２４の例の場合、トラック情報（tracks配列）において下記のように１つのトラック（またはアダプテーションセット）のみが参照先として指定される。
　track":"#track=1"
　"codecs":"v3e1"
　また、図２５は、ISOBMFFがマルチトラックストラクチャの場合のMPEGメディアオブジェクト（MPEG_media）の記述例を示す図である。図２５の例の場合、トラック情報（tracks配列）において下記のようにV3Cビットストリームを格納する全てのトラック（またはアダプテーションセット）が参照先として指定される。
"tracks": [
  {“track”:“#track=1”
  “codecs”: “v3c1”},
  {“track”:“#track=2”
  “codecs”: “resv.vvvc.hvc1”},
  {“track”:“#track=3”
  “codecs”: “resv.vvvc.hvc1”},
  {“track”:“#track=4”
  “codecs”: “resv.vvvc.hvc1”}
]
　　＜トラック情報の冗長性＞
　しかしながら、ISOBMFFがマルチトラックストラクチャの場合、V3Cトラックに紐づく他のコンポーネントトラックの情報は、DASHレイヤやISOBMFFレイヤの情報に格納されており、デコーダはそこからその情報を取得することができる。したがって、上述のようなシーンディスクリプション（のトラック情報）において、全てのトラックを参照先として指定することは冗長であり、シーンディスクリプションのデータ量が不要に増大するおそれがあった。
　＜２．トラック情報の冗長性の抑制＞
　そこで、図２６の表の最上段に示されるように、シーンディスクリプションにおいて、マルチトラックストラクチャのファイルコンテナの他のトラックの情報を持つ一部のトラックが参照先として指定されるようにしてもよい（方法１）。
　例えば、情報処理装置において、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部を備えてもよい。
　例えば、情報処理方法において、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成してもよい。
　例えば、情報処理装置において、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する取得部を備えてもよい。
　例えば、情報処理方法において、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。
　このようにすることにより、シーンディスクリプションにおいてトラック情報の冗長性の増大を抑制することができる。したがって、シーンディスクリプションのデータ量の増大を抑制することができる。
　換言するに、シーン記述ファイルのトラック情報において、ファイルコンテナを構成する複数のトラックの内の一部のトラックに対する参照先の指定を省略する。トラック間の参照関係は、上述したように、例えばISOBMFF等のファイルコンテナやMPD等の制御ファイルにおいて得られるので、取得部は、トラック情報において一部のトラックに対する参照先の指定を省略しても3Dオブジェクトコンテンツのデータを得ることができる。したがって、このようにすることにより、トラック情報の冗長性の増大を抑制し、シーンディスクリプションのデータ量の増大を抑制することができる。
　なお、トラック情報は、全ての他のトラックにアクセスするための情報を持つ単数のトラックを参照先として指定する情報であってもよい。全ての他のトラックにアクセスするための情報を持つトラックを参照すれば、取得部は、その情報から全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得することができる。したがって、このようにすることにより、トラック情報の冗長性の増大をさらに抑制することができ、シーンディスクリプションのデータ量の増大をさらに抑制することができる。
　また、ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFF（International Organization for Standardization Base Media File Format）であってもよい。このようにすることにより、マルチトラックストラクチャを適用するISOBMFFに対するトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　また、3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCC（Video-based Point Cloud Compression）に準拠する方式で符号化されたV3C（Visual Volumetric Video-based Coding）ビットストリームであってもよい。このようにすることにより、V3Cビットストリームを管理するファイルコンテナに対するトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　また、シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述されてもよい。このようにすることにより、glTF（The GL Transmission Format）2.0に準拠する方式で記述されたトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　　＜トラックリファレンスを持つトラックを参照先とする場合＞
　上述した方法１が適用される場合において、図２６の表の上から２段目に示されるように、ファイルコンテナのトラックリファレンスを格納するトラックが参照先として指定されてもよい（方法１－１）。
　例えば、ファイル生成部が、ファイルコンテナの複数のトラックの内、全ての他のトラックにアクセスするためのトラックリファレンスを持つ単数のトラックを参照先として指定するトラック情報を含むシーン記述ファイルを生成してもよい。
　また、トラック情報が、ファイルコンテナの複数のトラックの内、全ての他のトラックにアクセスするためのトラックリファレンスを持つ単数のトラックを参照先として指定する情報であり、取得部が、そのトラック情報に基づいてその単数のトラックを参照し、そのトラックリファレンスに基づいて全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。
　このように、トラックリファレンスを有するトラックを参照先として指定することにより、取得部は、他のトラックを参照先として指定する場合よりも容易に3Dオブジェクトコンテンツのデータを取得することができる。
　　＜制御ファイルのアダプテーションセットを参照先とする場合＞
　上述した方法１が適用される場合において、図２６の表の最下段に示されるように、MPD（Media Presentation Description）の、ファイルコンテナのトラックリファレンスを格納するトラックを管理するアダプテーションセットが参照先として指定されてもよい（方法１－２）。MPDは、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信される3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルである。
　例えば、ファイル生成部が、3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、全ての他のトラックにアクセスするための情報を持つ単数のトラックの情報を格納するアダプテーションセットを参照先として指定するトラック情報を含むシーン記述ファイルを生成してもよい。
　また、トラック情報が、3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、全ての他のトラックにアクセスするための情報を持つ単数のトラックの情報を格納するアダプテーションセットを参照先として指定する情報であり、取得部が、その制御ファイルを取得し、その制御ファイルの、トラック情報により指定されたアダプテーションセットの情報に基づいてその単数のトラックを参照し、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。
　このようにすることにより、制御ファイルを用いて3Dオブジェクトコンテンツのデータの配信が行われる場合も、トラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　なお、3Dオブジェクトコンテンツが、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信されてもよい。そして、制御ファイルが、MPD（Media Presentation Description）であってもよい。つまり、本技術は、MPEG-DASHを適用した3Dオブジェクトコンテンツの配信にも適用し得る。したがって、MPEG-DASHを適用して3Dオブジェクトコンテンツが配信される場合であっても、トラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　　＜記述例＞
　以上のような方法１が適用される場合のシーンディスクリプション（MPEGメディアオブジェクト（MPEG_media））の記述例を、図２７に示す。図２７においては、方法１－２が適用される場合の記述例、すなわち、参照先としてMPDのアダプテーションセットが指定される場合の記述例を、一例として示す。例えば、この記述例の下から８行目においては、V3Cビットストリームを取得するための情報として、V3Cビットストリームの配信を制御するためのMPDが、uriによって下記のように指定されている。
"uri": "manifest.mpd",
　また、この記述例の点線枠で囲まれる部分には、参照先とするV3Cトラックの情報を格納するアダプテーションセットを指定する、下記のようなトラック情報が格納されている。
"tracks": [{
    “tracks”:“#track=1”
    “codecs”: “v3c1”
}]
　つまり、ISOBMFFがマルチトラックストラクチャであっても、トラック情報においては、単数のトラックが参照先として指定されている。このようにすることにより、トラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　　＜ファイル生成装置＞
　上述した方法１（方法１－１および方法１－２を含む）は、任意の装置に適用し得る。図２８は、本技術を適用した情報処理装置の一態様であるファイル生成装置の構成の一例を示すブロック図である。図２８に示されるファイル生成装置１００は、3Dオブジェクトコンテンツの配信用の情報を生成する装置である。例えば、ファイル生成装置１００は、配信する3Dオブジェクトコンテンツファイルを生成したり、その3Dオブジェクトコンテンツのシーン記述ファイル（シーンディスクリプション）を生成したりする。
　なお、図２８においては、処理部やデータの流れ等の主なものを示しており、図２８に示されるものが全てとは限らない。つまり、ファイル生成装置１００において、図２８においてブロックとして示されていない処理部が存在したり、図２８において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
　図２８に示されるようにファイル生成装置１００は、制御部１０１およびファイル生成処理部１０２を有する。制御部１０１は、ファイル生成処理部１０２を制御する。ファイル生成処理部１０２は、制御部１０１により制御されて、ファイルの生成に関する処理を行う。例えば、ファイル生成処理部１０２は、配信する3Dオブジェクトコンテンツのデータを格納するコンテンツファイルである3Dオブジェクトコンテンツファイルを生成する。また、ファイル生成処理部１０２は、その3Dオブジェクトコンテンツに対応するシーンディスクリプションを格納するシーンディスクリプションファイルを生成する。ファイル生成処理部１０２は、生成したファイルをファイル生成装置１００の外部に出力する。例えば、ファイル生成処理部１０２は、生成したファイルを配信サーバ等にアップロードする。
　ファイル生成処理部１０２は、入力部１１１、前処理部１１２、符号化部１１３、ファイル生成部１１４、記録部１１５、および出力部１１６を有する。
　入力部１１１は、3Dオブジェクトコンテンツのデータとしてポイントクラウドのデータを取得し、それを前処理部１１２に供給する。前処理部１１２は、そのポイントクラウドのデータ等からシーンディスクリプションの生成に必要な情報を取得する。前処理部１１２は、取得した情報をファイル生成部１１４に供給する。また、前処理部１１２は、ポイントクラウドのデータを符号化部１１３に供給する。
　符号化部１１３は、前処理部１１２から供給されるポイントクラウドのデータを符号化し、その符号化データを生成する。符号化部１１３は、生成したポイントクラウドの符号化データをV3Cビットストリームとしてファイル生成部１１４に供給する。
　ファイル生成部１１４は、ファイル等の生成に関する処理を行う。例えば、ファイル生成部１１４は、符号化部１１３から供給されたV3Cビットストリームを取得する。また、ファイル生成部１１４は、前処理部１１２から供給された情報を取得する。また、ファイル生成部１１４は、符号化部１１３から供給されたV3Cビットストリームを格納するファイルコンテナであるISOBMFFを生成する。また、ファイル生成部１１４は、前処理部１１２から供給された情報を用いてシーンディスクリプションファイルを生成する。その際、ファイル生成部１１４は、V3CビットストリームやISOBMFF等の情報を用いてトラック情報等を生成し、シーンディスクリプションファイルに格納し得る。また、V3CビットストリームがMPEG-DASHに準拠する方式で配信される場合、ファイル生成部１１４は、MPDを生成する。ファイル生成部１１４は、生成したファイル等（ISOBMFF、シーンディスクリプションファイル、MPD等）を記録部１１５に供給する。
　記録部１１５は、例えば、ハードディスクや半導体メモリ等、任意の記録媒体を有し、ファイル生成部１１４から供給されるファイル等をその記録媒体に記録する。また、記録部１１５は、制御部１０１若しくは出力部１１６の要求に従って、または所定のタイミングにおいて、記録媒体に記録されているファイル等を読み出し、出力部１１６に供給する。
　出力部１１６は、記録部１１５から供給されるファイル等を取得し、そのファイル等をファイル生成装置１００の外部（例えば配信サーバや再生装置等）に出力する。
　以上のような構成のファイル生成装置１００において、ファイル生成部１１４は、本技術を適用してファイル等を生成する。
　例えば、ファイル生成部１１４は、上述した方法１を適用し、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含むシーンディスクリプションファイルを生成してもよい。
　このようにすることにより、ファイル生成装置１００は、シーンディスクリプションのトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　なお、そのトラック情報は、全ての他のトラックにアクセスするための情報を持つ単数のトラックを参照先として指定する情報であってもよい。
　また、ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFFであってもよい。3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCCに準拠する方式で符号化されたV3Cビットストリームであってもよい。シーンディスクリプションファイルは、glTF2.0に準拠する方式で記述されてもよい。
　また、ファイル生成部１１４は、上述した方法１－１を適用し、ファイルコンテナの複数のトラックの内、全ての他のトラックにアクセスするためのトラックリファレンスを持つ単数のトラックを参照先として指定するトラック情報を含むシーンディスクリプションファイルを生成してもよい。
　また、ファイル生成部１１４は、上述した方法１－２を適用し、3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、全ての他のトラックにアクセスするための情報を持つ単数のトラックの情報を格納するアダプテーションセットを参照先として指定するトラック情報を含むシーンディスクリプションファイルを生成してもよい。
　その場合の3Dオブジェクトコンテンツは、MPEG-DASHに準拠する方式で配信されてもよい。また、制御ファイルは、MPDであってもよい。
　これらの本技術の内のいずれか１つ以上を適用することにより、ファイル生成装置１００は、＜２．トラック情報の冗長性の抑制＞において説明したのと同様の効果を得ることができる。
　　＜ファイル生成処理の流れ＞
　このような構成のファイル生成装置１００が実行するファイル生成処理の流れの例を、図２９のフローチャートを参照して説明する。
　ファイル生成処理が開始されると、ファイル生成装置１００の入力部１１１は、ステップＳ１０１において、3Dオブジェクトのデータ（3Dデータ）を取得する。例えば、入力部１１１は、この3Dデータとして、ポイントクラウドのデータを取得する。
　ステップＳ１０２において、前処理部１１２は、ステップＳ１０１において取得された3Dオブジェクトのデータから、１つ以上の3Dオブジェクトを3D空間に配置するための空間配置情報であるシーンディスクリプションの生成に用いられる情報を取得する。そして、ファイル生成部１１４は、その情報を用いて、シーンディスクリプションファイルを生成する。
　ステップＳ１０３において、符号化部１１３は、ステップＳ１０１において取得されたポイントクラウドのデータ（3Dデータ）を符号化し、その符号化データ（V3Cビットストリーム）を生成する。
　ステップＳ１０４において、ファイル生成部１１４は、ステップＳ１０３において生成されたV3Cビットストリームを格納するファイルコンテナ（ISOBMFF）を生成する。また、ファイル生成部１１４は、例えば、MPD等の制御ファイルを生成し得る。
　ステップＳ１０５において、ファイル生成部１１４は、ステップＳ１０４において生成されたISOBMFF（やMPD）に基づいて、ISOBMFFを構成する複数のトラックの内の、他のトラックの情報を持つ一部のトラックを参照先として指定するトラック情報を生成し、ステップＳ１０２において生成されたシーンディスクリプションファイルに格納する。
　ステップＳ１０６において、記録部１１５は、生成されたファイルコンテナ（ISOBMFF）や、（MPDや、）シーンディスクリプションファイル等を記録媒体に記録する。
　ステップＳ１０７において、出力部１１６は、ステップＳ１０６において記録されたファイル等を記録媒体より読み出し、所定のタイミングにおいて、その読み出したファイルをファイル生成装置１００の外部に出力する。例えば、出力部１１６は、記録媒体より読み出したファイルを、ネットワーク等の通信媒体を介して、配信サーバや再生装置等の他の装置へ送信（アップロード）してもよい。また、出力部１１６は、記録媒体より読み出したファイル等を、リムーバブルメディア等の外部記録媒体に記録してもよい。その場合、その出力されたファイルは、例えば、その外部記録媒体を介して他の装置（配信サーバや再生装置等）に供給されてもよい。
　ステップＳ１０７の処理が終了すると、ファイル生成処理が終了する。
　このようなファイル生成処理のステップＳ１０５において、ファイル生成部１１４は、＜２．トラック情報の冗長性の抑制＞の＜ファイル生成装置＞において上述したように本技術の各種方法を適用して、トラック情報を生成し、それをシーンディスクリプションファイルに格納することができる。したがって、ファイル生成装置１００は、このようにファイル生成処理を実行することにより、シーンディスクリプションのトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。また、ファイル生成装置１００は、＜２．トラック情報の冗長性の抑制＞において説明したのと同様の効果を得ることができる。
　　＜クライアント装置＞
　図３０は、本技術を適用した情報処理装置の一態様であるクライアント装置の構成の一例を示すブロック図である。図３０に示されるクライアント装置２００は、シーン記述ファイル（シーンディスクリプション）に基づいて、3Dオブジェクトコンテンツの再生処理を行う再生装置である。例えば、クライアント装置２００は、ファイル生成装置１００により生成された3Dオブジェクトファイルに格納される3Dオブジェクトのデータを再生する。その際、クライアント装置２００は、シーンディスクリプションに基づいて、その再生に関する処理を行う。
　なお、図３０においては、処理部やデータの流れ等の主なものを示しており、図３０に示されるものが全てとは限らない。つまり、クライアント装置２００において、図３０においてブロックとして示されていない処理部が存在したり、図３０において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
　図３０に示されるようにクライアント装置２００は、制御部２０１および再生処理部２０２を有する。制御部２０１は、再生処理部２０２の制御に関する処理を行う。再生処理部２０２は、3Dオブジェクトのデータの再生に関する処理を行う。
　再生処理部２０２は、ファイル取得部２１１、ファイル処理部２１２、復号部２１３、表示情報生成部２１４、表示部２１５、および表示制御部２１６を有する。
　ファイル取得部２１１は、例えば配信サーバやファイル生成装置１００等、クライアント装置２００の外部から供給されるファイル等を取得する。例えば、ファイル取得部２１１は、クライアント装置２００の外部からシーンディスクリプションファイルを取得し、それをファイル処理部２１２に供給する。また、ファイル取得部２１１は、ファイル処理部２１２からの要求に従って、3Dオブジェクトコンテンツのビットストリームを格納するファイルコンテナ（ISOBMFF）を取得し、それをファイル処理部２１２へ供給する。また、ファイル取得部２１１は、ファイル処理部２１２からの要求に従って、3Dオブジェクトコンテンツのデータの配信を制御する制御ファイル（例えばMPD）を取得し、それをファイル処理部２１２へ供給することもできる。
　ファイル処理部２１２は、ファイル取得部２１１から供給されるファイル等を取得し、その取得したファイル等に関する処理を行う。例えば、ファイル処理部２１２は、ファイル取得部２１１から供給されるシーンディスクリプションファイル等を取得する。そして、ファイル処理部２１２は、そのシーンディスクリプションファイルに基づいて、ファイル取得部２１１を制御する等の処理を行う。また、ファイル処理部２１２は、ファイル取得部２１１から供給されるMPDを取得する。そして、ファイル処理部２１２は、そのMPDに基づいて、ファイル取得部２１１を制御する等の処理を行う。また、ファイル処理部２１２は、ファイル取得部２１１から供給されるファイルコンテナ（ISOBMFF）の情報を取得する。そして、ファイル処理部２１２は、そのISOBMFFから任意の情報を抽出し得る。そして、ファイル処理部２１２は、その抽出した情報に基づいて、ファイル取得部２１１を制御する等の処理を行う。また、ファイル処理部２１２は、ファイル取得部２１１から供給される3Dオブジェクトコンテンツのビットストリーム（例えばV3Cビットストリーム）を取得する。
　ファイル処理部２１２は、取得したビットストリーム等を復号部２１３に供給する。また、ファイル処理部２１２は、シーンディスクリプション等に含まれる表示情報の生成に有用な情報を表示制御部２１６に供給する。
　復号部２１３は、ファイル処理部２１２から供給されたビットストリームを復号する。復号部２１３は、その復号により得られた3Dオブジェクトコンテンツのデータ（例えばポイントクラウドのデータ）を表示情報生成部２１４に供給する。
　表示情報生成部２１４は、復号部２１３から供給される3Dオブジェクトのデータを取得する。また、表示情報生成部２１４は、表示制御部２１６の制御に従って、その3Dオブジェクトコンテンツのデータのレンダリングを行い、表示画像等を生成する。表示情報生成部２１４は、生成した表示画像等を、表示部２１５に供給する。
　表示部２１５は、表示デバイスを有し、表示情報生成部２１４から供給された表示画像をその表示デバイスを用いて表示する。
　表示制御部２１６は、ファイル処理部２１２から供給されるシーンディスクリプション等の情報を取得する。表示制御部２１６はその情報に基づいて表示情報生成部２１４を制御する。
　以上のような構成のクライアント装置２００において、ファイル処理部２１２は、本技術を適用してシーンディスクリプションファイルや、（MPDや、）3Dオブジェクトコンテンツのデータ等を取得する。
　例えば、ファイル処理部２１２は、上述した方法１を適用し、3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含むシーンディスクリプションファイル、および、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。ファイル処理部２１２は、ファイル取得部２１１を制御することにより、このような処理を実現する。つまり、ファイル処理部２１２は、取得部とも言える。
　このようにすることにより、クライアント装置２００は、シーンディスクリプションのトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。
　なお、そのトラック情報は、全ての他のトラックにアクセスするための情報を持つ単数のトラックを参照先として指定する情報であってもよい。
　また、ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFFであってもよい。3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCCに準拠する方式で符号化されたV3Cビットストリームであってもよい。シーンディスクリプションファイルは、glTF2.0に準拠する方式で記述されてもよい。
　また、ファイル処理部２１２は、上述した方法１－１を適用し、ファイルコンテナの複数のトラックの内、全ての他のトラックにアクセスするためのトラックリファレンスを持つ単数のトラックを参照先として指定するトラック情報に基づいてその単数のトラックを参照し、そのトラックリファレンスに基づいて全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。ファイル処理部２１２は、ファイル取得部２１１を制御することにより、このような処理を実現する。
　また、ファイル処理部２１２は、上述した方法１－２を適用し、3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルを取得し、その制御ファイルのアダプテーションセットの内、トラック情報により参照先として指定されるアダプテーションセットの情報に基づいて、全ての他のトラックにアクセスするための情報を持つ単数のトラックを参照し、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得してもよい。
　その場合の3Dオブジェクトコンテンツは、MPEG-DASHに準拠する方式で配信されてもよい。また、制御ファイルは、MPDであってもよい。
　これらの本技術の内のいずれか１つ以上を適用することにより、クライアント装置２００は、＜２．トラック情報の冗長性の抑制＞において説明したのと同様の効果を得ることができる。
　　＜クライアント処理の流れ１＞
　このような構成のクライアント装置２００が実行するクライアント処理の流れの例を、図３１のフローチャートを参照して説明する。図３１のフローチャートは、方法１－１が適用される場合のクライアント処理の流れの例である。
　クライアント処理が開始されると、クライアント装置２００のファイル処理部２１２は、ステップＳ２０１においてファイル取得部２１１を制御し、シーンディスクリプションファイルを取得する。
　ステップＳ２０２において、ファイル処理部２１２は、ステップＳ２０１において取得したシーンディスクリプションファイルを解析する。
　ステップＳ２０３において、ファイル処理部２１２は、ステップＳ２０２の処理により得られたシーンディスクリプションファイルの解析結果に基づいてファイル取得部２１１を制御し、シーンディスクリプションファイルのトラック情報により参照先に指定されたトラックを参照する。
　ステップＳ２０４において、ファイル処理部２１２は、ステップＳ２０３において参照したトラックに格納されるトラックリファレンスにより紐づけられた他のトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。
　ステップＳ２０５において、復号部２１３は、ステップＳ２０４において取得された3Dオブジェクトコンテンツのデータ（符号化データのビットストリーム）を復号する。
　ステップＳ２０６において、表示情報生成部２１４は、シーンディスクリプションファイルに基づいて3Dオブジェクトを3D空間に配置し、レンダリングを行って表示画像を生成する。
　ステップＳ２０７において、表示部２１５は、ステップＳ２０６において生成された表示画像を表示する。ステップＳ２０７の処理が終了すると、クライアント処理が終了する。
　このようなクライアント処理のステップＳ２０１乃至ステップＳ２０４の処理において、ファイル処理部２１２は、＜２．トラック情報の冗長性の抑制＞の＜クライアント装置＞において上述したように本技術の各種方法を適用して、トラック情報に基づいて全ての他のトラックにアクセスするためのトラックリファレンスを持つ単数のトラックを参照し、そのトラックリファレンスに基づいて全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。したがって、クライアント装置２００は、このようにクライアント処理を実行することにより、シーンディスクリプションのトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。また、クライアント装置２００は、＜２．トラック情報の冗長性の抑制＞において説明したのと同様の効果を得ることができる。
　　＜クライアント処理の流れ２＞
　次に、方法１－２が適用される場合のクライアント処理の流れの例を、図３２のフローチャートを参照して説明する。
　クライアント処理が開始されると、クライアント装置２００のファイル処理部２１２は、ステップＳ２２１においてファイル取得部２１１を制御し、シーンディスクリプションファイルを取得する。ステップＳ２２２において、ファイル処理部２１２は、そのシーンディスクリプションファイルを解析する。
　ステップＳ２２３において、ファイル処理部２１２は、ステップＳ２２２の処理により得られたシーンディスクリプションファイルの解析結果に基づいてファイル取得部２１１を制御し、そのシーンディスクリプションファイルにおいて指定される、3Dオブジェクトコンテンツのデータの配信を制御する制御ファイルを取得する。ステップＳ２２４において、ファイル処理部２１２は、その制御ファイルを解析する。
　ステップＳ２２５において、ファイル処理部２１２は、ステップＳ２２４の処理により得られた制御ファイルの解析結果に基づいてファイル取得部２１１を制御し、シーンディスクリプションファイルのトラック情報により参照先に指定されたアダプテーションセットに格納されるトラックを参照する。そして、ファイル処理部２１２は、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。例えば、ファイル処理部２１２は、参照したトラックに格納されるトラックリファレンスにより紐づけられた他のトラックに格納される情報を取得する。そして、ファイル処理部２１２は、各トラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。
　ステップＳ２２６において、復号部２１３は、ステップＳ２２５において取得された3Dオブジェクトコンテンツのデータ（符号化データのビットストリーム）を復号する。
　ステップＳ２２７において、表示情報生成部２１４は、シーンディスクリプションファイルに基づいて3Dオブジェクトを3D空間に配置し、レンダリングを行って表示画像を生成する。
　ステップＳ２２８において、表示部２１５は、ステップＳ２２７において生成された表示画像を表示する。ステップＳ２２８の処理が終了すると、クライアント処理が終了する。
　このようなクライアント処理のステップＳ２２１乃至ステップＳ２２５の各処理において、ファイル処理部２１２は、＜２．トラック情報の冗長性の抑制＞の＜クライアント装置＞において上述したように本技術の各種方法を適用して、トラック情報に基づいて制御ファイルを取得し、その制御ファイルの、トラック情報により指定されるアダプテーションセットに格納されるトラックを参照し、トラック間の参照関係に基づいて、全てのトラックにおいて管理される3Dオブジェクトコンテンツのデータを取得する。したがって、クライアント装置２００は、このようにクライアント処理を実行することにより、シーンディスクリプションのトラック情報の冗長性の増大を抑制することができ、そのシーンディスクリプションのデータ量の増大を抑制することができる。また、クライアント装置２００は、＜２．トラック情報の冗長性の抑制＞において説明したのと同様の効果を得ることができる。
　＜３．アトリビュートの指定＞
　　＜バッファに格納されるデータ＞
　ところで、例えば、gｌTF2.0でポイントクラウドの3Dオブジェクトコンテンツを提供するシステムにおいて、MPEG-I Part 14 Scene Description for MPEG Mediaの規定を適用してV3Cビットストリームを管理する場合について考える。
　クライアント装置は、図３３に示されるように、V3Cビットストリーム（V-PCC data）を復号（V-PCC decode）し、ポイントクラウドを再構成（Point cloud reconstruct）する。
　非特許文献２に記載のように、クライアント装置は、プレゼンテーションエンジン（PE）とメディアアクセスファンクション（MAF）は、バッファを介してデータを授受する。したがって、そのバッファ（circular buffer）に格納されるデータとして、以下の2種類が考えられる。
　ケース１：Point cloud reconstruct後のdata（すなわちpoint cloud data）
　ケース２：V-PCC decode後のdata（すなわちdecoded component video data）
　　＜ケース１＞
　ケース１の場合の、シーンディスクリプションにおけるオブジェクトの構成例を図３４に示す。このケース１の場合、バッファには再構成されたポイントクラウドデータ（ジオメトリとアトリビュート）が格納されるので、mesh.primitives内のアトリビュートオブジェクト（attribute）においては、位置情報（POSITION）と色情報（COLOR_0）のプロパティが設定され、それぞれのプロパティにおいて、それぞれの情報が格納されるバッファへのアクセサ（accessor）が指定される。
　バッファに格納されるデータが動的な（時間方向に変化する）ポイントクラウドデータであるため、glTF2.0のポイントクラウドデータを使用する場合のオブジェクト構成を利用する。さらにタイムドメディア（timed  media）を利用するために非特許文献２で拡張された機能（MPEG_accessor_timed,やMPEG_buffer_circular等）を適用する。MPEGメディア（MPEG_media）ではV-PCCデータ（V3C美とストリーム）が指定され、それがメディアアクセスファンクション（MAF）において復号および再構成されてバッファに格納される。プレゼンテーションエンジン（PE）は、バッファ内のデータを取得し、glTF2.0のポイントクラウドデータを処理するのと同じ方法で3Dオブジェクトコンテンツをレンダリングする。
　クライアント装置は、図１９を参照して説明したような構成を有し、クライアント処理を実行することにより3Dオブジェクトコンテンツを再生する。図３５は、ケース１の場合のクライアント処理の流れの例を示すフローチャートである。クライアント処理が開始されると、プレゼンテーションエンジン（PE）５１のglTF解析部６３は、は、PE処理を開始し、ステップＳ３２１において、シーンディスクリプションファイルであるSD(glTF)ファイル６２を取得し、そのシーンディスクリプションを解析（parse）する。
　ステップＳ３２２において、glTF解析部６３は、3Dオブジェクト（texture）に紐づくメディア（media）と、そのメディアを処理後に格納するバッファ（buffer）と、アクセサ（accessor）を確認する。ステップＳ３２３において、glTF解析部６３は、ファイル取得要求として、メディアアクセスファンクション（MAF）５２にその情報を通知する。
　メディアアクセスファンクション（MAF）５２は、MAF処理を開始し、ステップＳ３１１において、その通知を取得する。ステップＳ３１２において、メディアアクセスファンクション（MAF）５２は、その通知に基づいてメディア（3Dオブジェクトファイル（mp4））を取得する。
　ステップＳ３１３において、メディアアクセスファンクション（MAF）５２は、取得したメディア（3Dオブジェクトファイル（mp4））を2D動画像の復号方式で復号する。ステップＳ３１４において、メディアアクセスファンクション（MAF）５２は、復号して得られたビデオデータを用いてポイントクラウドを再構成する。ステップＳ３１５において、メディアアクセスファンクション（MAF）５２は、再構成されたポイントクラウドのデータを、プレゼンテーションエンジン（PE）５１からの通知に基づいて、バッファ５４に格納する。
　ステップＳ３２４において、プレゼンテーションエンジン（PE）５１のレンダリング処理部６４は、そのポイントクラウドのデータを適切なタイミングにおいてバッファ５４から読み出す（取得する）。ステップＳ３２５において、レンダリング処理部６４は、取得したデータを用いてレンダリングを行い、表示用画像を生成する。
　メディアアクセスファンクション（MAF）５２は、ステップＳ３１３乃至ステップＳ３１５の各処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。また、プレゼンテーションエンジン（PE）５１は、ステップＳ３２４およびステップＳ３２５の各処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。全てのフレームについて処理が終了すると、メディアアクセスファンクション（MAF）５２はMAF処理を終了し、プレゼンテーションエンジン（PE）５１はPE処理を終了する。つまり、クライアント処理が終了する。
　　＜ケース２＞
　ケース２の場合の、シーンディスクリプションにおけるオブジェクトの構成例を図３６に示す。このケース２の場合、バッファには復号されたビデオデータ（decoded component video data）等が格納される。つまり、ジオメトリビデオフレーム、アトリビュートビデオフレーム、オキュパンシーマップ、アトラス情報等がバッファに格納される。ただし、既存のglTF2.0でそのようなデータをシグナルする方法が無い。そのため、シーンディスクリプションにおいては、図３６に示されるように、mesh.primitives内において、extension（MPEG_vpcc）が規定され、それぞれのビデオデータ（decoded component video data）にアクセスするためのアクセサの識別情報が格納される。すなわち、MPEG_vpcc内においてオブジェクト（vpccattr）が規定され、そのvpccattrにおいて、アトラス（atras）、ジオメトリ（geometry）、アトリビュート（attributre）、オキュパンシー（occupancy）等のプロパティが設定され、それぞれのプロパティにおいて、それぞれのビットストリームが格納されるバッファへのアクセサ（accessor）が指定される。
　MPEGメディア（MPEG_media）ではV-PCCデータが指定され、それがメディアアクセスファンクション（MAF）において復号され、得られたビデオデータ（decoded component video data）等がバッファに格納される。プレゼンテーションエンジン（PE）は、バッファ内のデータを取得し、それらを用いてポイントクラウドを再構成し、ケース１の場合と同様にレンダリングする。
　ケース２の場合もクライアント装置は、図１９を参照して説明したような構成を有し、クライアント処理を実行することにより3Dオブジェクトコンテンツを再生する。図３７は、ケース２の場合のクライアント処理の流れの例を示すフローチャートである。クライアント処理が開始されると、プレゼンテーションエンジン（PE）５１のglTF解析部６３は、PE処理を開始し、ステップＳ３４１において、シーンディスクリプションファイルであるSD(glTF)ファイル６２を取得し、そのシーンディスクリプションを解析（parse）する。
　ステップＳ３４２において、glTF解析部６３は、3Dオブジェクト（texture）に紐づくメディア（media）と、そのメディアを処理後に格納するバッファ（buffer）と、アクセサ（accessor）を確認する。ステップＳ３４３において、glTF解析部６３は、ファイル取得要求として、メディアアクセスファンクション（MAF）５２にその情報を通知する。
　メディアアクセスファンクション（MAF）５２は、MAF処理を開始し、ステップＳ３３１において、その通知を取得する。ステップＳ３３２において、メディアアクセスファンクション（MAF）５２は、その通知に基づいてメディア（3Dオブジェクトファイル（mp4））を取得する。
　ステップＳ３３３において、メディアアクセスファンクション（MAF）５２は、取得したメディア（3Dオブジェクトファイル（mp4））を2D動画像の復号方式で復号する。ステップＳ３３４において、メディアアクセスファンクション（MAF）５２は、復号して得られたビデオデータ（decoded component video data）等を、プレゼンテーションエンジン（PE）５１からの通知に基づいて、バッファ５４に格納する。
　ステップＳ３４４において、プレゼンテーションエンジン（PE）５１のレンダリング処理部６４は、そのビデオデータ等を適切なタイミングにおいてバッファ５４から読み出す（取得する）。ステップＳ３４５において、レンダリング処理部６４は、取得したビデオデータ等を用いてポイントクラウドを再構成する。ステップＳ３４６において、レンダリング処理部６４は、再構成されたポイントクラウドのデータを用いてレンダリングを行い、表示用画像を生成する。
　メディアアクセスファンクション（MAF）５２は、ステップＳ３３３およびステップＳ３３４の各処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。また、プレゼンテーションエンジン（PE）５１は、ステップＳ３４４乃至ステップＳ３４６の各処理を繰り返すことにより、各時刻（各フレーム）についてこれらの処理を実行する。全てのフレームについて処理が終了すると、メディアアクセスファンクション（MAF）５２はMAF処理を終了し、プレゼンテーションエンジン（PE）５１はPE処理を終了する。つまり、クライアント処理が終了する。
　　＜色情報以外のアトリビュートの管理＞
　図３８に示されるように、ポイントクラウドのアトリビュートには、色情報以外の情報も含まれ得る。しかしながら、glTF2.0のprimitives.attributesのプロパティにおいては、位置情報（POSITION）と色情報（COLOR）しか取り扱うことができなかった。そのため、V3Cビットストリームを復号して得られたデータに色情報以外のアトリビュートのデータ（glTF2.0のprimitives.attributesのpropertyでは表せない種類のデータ）が含まれる場合、ポイントクラウドを正しく再構成することが困難であった。これは、上述したケース１およびケース２の両方において起こり得る。
　そこで、図３９の表の最上段に示されるように、シーンディスクリプションのmesh.primitivesにおいて、ポイントクラウドの色情報以外のアトリビュート情報を格納するようにしてもよい（方法２）。
　例えば、情報処理装置において、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを有する、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部を備えてもよい。
　例えば、情報処理方法において、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを有する、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成してもよい。
　例えば、情報処理装置において、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルに規定されるオブジェクトに格納される、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報に基づいて、そのアトリビュートのデータを取得する取得部を備えてもよい。
　例えば、情報処理方法において、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルに規定されるオブジェクトに格納される、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報に基づいて、そのアトリビュートのデータを取得してもよい。
　このようにすることにより、ポイントクラウドデータが色情報以外のアトリビュートを有する場合であっても、正しく3Dオブジェクト（ポイントクラウド）を再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。この色情報以外のアトリビュートは、任意である。例えば、反射率や法線ベクトル等であってもよいし、それら以外であってもよい。
　なお、3Dオブジェクトコンテンツはポイントクラウドであり、シーン記述ファイルは、glTF2.0に準拠する方式で記述され、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトは、そのシーン記述ファイルのmesh.primitives内に規定されてもよい。ファイル生成部は、そのようなシーン記述ファイルを生成してもよい。取得部は、そのアトリビュートに関する情報に基づいてそのアトリビュートのデータを取得してもよい。このようにすることにより、glTF2.0に準拠する3Dオブジェクトコンテンツにおいて、正しく3Dオブジェクト（ポイントクラウド）を再構成することができる（色情報以外のアトリビュートに対応することができる）。
　また、ファイル生成部は、そのmesh.primitives内にextensionを規定し、そのextension内にそのオブジェクトを規定してもよい。取得部は、そのmesh.primitives内のextensionに規定されるオブジェクトに格納されるアトリビュートに関する情報に基づいてそのアトリビュートのデータを取得してもよい。extensionを適用することにより、既存のglTF2.0との互換性の低減を抑制することができる。
　　＜ケース１の適用例１＞
　上述したケース１の場合、すなわち、V3Cビットストリームが復号され、ポイントクラウドが再構成され、得られたポイントクラウドデータがバッファに格納される場合について説明する。このケース１において上述した方法１を適用する場合において、図３９の上から２番目の段に示されるように、extensionを用いて色情報以外のアトリビュート情報を格納するオブジェクトを規定してもよい（方法２－１）。
　例えば、オブジェクトは、3Dオブジェクトコンテンツのデータにおける、色以外のアトリビュートのデータの識別情報と、そのアトリビュートのデータが格納されるバッファに紐づくアクセサ（accessor）の識別情報とを格納してもよい。ファイル生成部は、mesh.primitives内のextensionにそのようなオブジェクトが規定されたシーン記述ファイルを生成してもよい。取得部は、そのようなオブジェクトの情報に基づいてバッファからそのアトリビュートのデータを取得してもよい。
　図４０は、この場合のオブジェクトの構成例を示す図である。図４０に示されるように、mesh.primitives内に、新たなextension（MPEG_vpcc）が設けられる。そのMPEG_vpcc内にアトリビュートオブジェクト（attribute）が設けられる。そのアトリビュートオブジェクト内に「glTF2.0では示すことのできないアトリビュート」の情報を格納するオブジェクトが規定される。図４０の例の場合、そのアトリビュートとして反射率が適用され、その反射率用のオブジェクト“_REFLECTANCE”が規定されている。このようなアトリビュート専用のオブジェクト内において、格納されるデータを示すプロパティと、そのデータを格納するバッファを示すプロパティとが設定される。格納されるデータの指定は、任意の情報を用いて行い得る。例えば、3Dオブジェクトコンテンツのデータにおける、そのアトリビュートのデータの識別情報（attributeId（attrId））を用いてもよい。また、そのアトリビュートのデータを格納するバッファの指定は、任意の情報を用いて行い得る。例えば、そのバッファに紐づくアクセサ（accessor）の識別情報（accessorId（acceId））を用いてもよい。
　図４１は、この場合のシーンディスクリプション（mesh）の記述例を示す図である。図４１において点線枠内に示されるように、MPEG_vpcc.attribute内において、“_REFLECTANCE”オブジェクトが規定され、accessorIdおよびattributeIdのプロパティにおいて、それぞれの値が設定されている。
　クライアント装置のメディアアクセスファンクションは、このような情報により指定されたアトリビュートのデータを、指定されたバッファに格納する。また、プレゼンテーションエンジンは、その指定されたバッファに格納されるそのアトリビュートのデータを読み出す。
　このようにすることにより、ケース１の場合であっても、色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。
　なお、図４０の例において、MPEG_vpccの"POSITION"および"COLOR"のプロパティは省略し得る。必要な場合だけ設けるようにしてもよい。
　なお、ケース１において上述した方法１を適用する場合において、図３９の上から３番目の段に示されるように、extensionを用いる代わりに、primitives.attributes内に色情報以外のアトリビュート情報を追加してもよい（方法２－２）。例えば、その色以外のアトリビュートを反射率とし、その反射率に関する情報を格納するプロパティ"_REFLECTANCE"をprimitives.attributes内に規定してもよい。この"_REFLECTANCE"プロパティは、アクセサ（accessor）の識別情報を持つ。
　すなわち、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトは、さらに、その3Dオブジェクトコンテンツの位置に関する情報、および、その3Dオブジェクトコンテンツの色に関する情報を格納してもよい。ファイル生成部は、mesh.primitives内にそのようなオブジェクトを規定してもよい。また、取得部は、mesh.primitives内に規定されたそのようなオブジェクトに基づいて、そのアトリビュートのデータを取得してもよい。
　　＜ケース２の適用例＞
　上述したケース２の場合、すなわち、V3Cビットストリームが復号され、得られたビデオデータ等がバッファに格納される場合について説明する。このケース２において上述した方法１を適用する場合において、図３９の上から４番目の段に示されるように、extensionを用いてアトラス情報、ジオメトリ情報、ポイントクラウドの色以外のアトリビュートを含むアトリビュート情報、オキュパンシー情報を格納するオブジェクトを規定してもよい（方法２－３）。
　例えば、オブジェクトは、3Dオブジェクトコンテンツのアトラス情報が格納されるバッファに紐づくアクセサ（accessor）の識別情報、その3Dオブジェクトコンテンツのジオメトリが格納されるバッファに紐づくアクセサの識別情報、その3Dオブジェクトコンテンツの全てのアトリビュートが格納されるバッファに紐づくアクセサの識別情報、および、その3Dオブジェクトコンテンツのオキュパンシー情報（例えばオキュパンシーマップ）が格納されるバッファに紐づくアクセサの識別情報を格納してもよい。ファイル生成部は、mesh.primitives内のextensionにそのようなオブジェクトが規定されたシーン記述ファイルを生成してもよい。取得部は、そのようなオブジェクトの情報に基づいて各バッファからビデオデータ等を取得してもよい。
　図４２は、この場合のオブジェクトの構成例を示す図である。図４２に示されるように、mesh.primitives内に、新たなextension（MPEG_vpcc）が設けられる。そのMPEG_vpcc内にアトリビュートオブジェクト（attribute）が設けられる。そのアトリビュートオブジェクトにおいて、各データを格納するバッファ示すプロパティとして、アトラス情報が格納されるバッファに紐づくアクセサ（accessor）を指定するプロパティ（_ATLAS）が設定される。同様に、ジオメトリが格納されるバッファに紐づくアクセサを指定するプロパティ（_GEOMETRY）が設定される。同様に、全てのアトリビュートが格納されるバッファに紐づくアクセサを指定するプロパティ（_ATTRIBUTE_0）が設定される。同様に、オキュパンシー情報が格納されるバッファに紐づくアクセサを指定するプロパティ（_OCCUPANCY）が設定される。アクセサの指定は、アクセサ（accessor）の識別情報（accessorId（acceId））を用いて行われてもよい。
　図４３は、この場合のシーンディスクリプション（mesh）の記述例を示す図である。図４１において点線枠内に示されるように、MPEG_vpcc.attribute内において、"_ATLAS", "_GEOMETRY", "_ATTRIBUTE_0". "_OCCUPANCY"のそれぞれプロパティにおいて、それぞれの値（アクセサの識別情報）が設定されている。
　なお、方法２－２と同様に、extensionを用いる代わりに、primitives.attributes内に"_ATLAS", "_GEOMETRY", "_ATTRIBUTE_0". "_OCCUPANCY"のそれぞれのプロパティを追加してもよい。
　クライアント装置のメディアアクセスファンクションは、このような情報により指定されたバッファに、ビデオデータ等を格納する。また、プレゼンテーションエンジンは、その指定されたバッファに格納されるビデオデータ等を読み出す。
　このようにすることにより、ケース２の場合であっても、色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。
　　＜ケース１の適用例２＞
　上述したケース１において上述した方法１を適用する場合において、図３９の最下段に示されるように、extensionを用いて汎用のアトリビュート情報を格納するオブジェクトを規定してもよい（方法２－４）。
　例えば、オブジェクトは、3Dオブジェクトコンテンツのデータにおける、色以外のアトリビュートのデータの識別情報と、そのアトリビュートのデータが格納されるバッファに紐づくアクセサ（accessor）の識別情報とに加え、そのアトリビュートのタイプを示す情報をさらに格納してもよい。ファイル生成部は、mesh.primitives内のextensionにそのようなオブジェクトが規定されたシーン記述ファイルを生成してもよい。取得部は、そのようなオブジェクトの情報に基づいてバッファからそのアトリビュートのデータを取得してもよい。
　図４４は、この場合のオブジェクトの構成例を示す図である。図４４に示されるように、mesh.primitives内に、新たなextension（MPEG_vpcc）が設けられる。そのMPEG_vpcc内にアトリビュートオブジェクト（attribute）が設けられる。そのアトリビュートオブジェクト内に任意のアトリビュートの情報を格納する汎用のオブジェクト（vpccattributes）が規定される。このような汎用のオブジェクト（vpccattributes）内において、格納されるデータを示すプロパティ（acceId）と、そのデータを格納するバッファを示すプロパティ（attrId）と、そのデータのタイプを示すプロパティ（attrType）とが設定される。格納されるデータの指定は、任意の情報を用いて行い得る。例えば、3Dオブジェクトコンテンツのデータにおける、そのアトリビュートのデータの識別情報（attributeId（attrId））を用いてもよい。また、そのアトリビュートのデータを格納するバッファの指定は、任意の情報を用いて行い得る。例えば、そのバッファに紐づくアクセサ（accessor）の識別情報（accessorId（acceId））を用いてもよい。また、そのアトリビュートのタイプの指定は、任意の情報を用いて行い得る。例えば、アトリビュートのタイプを識別するための識別情報（attributeType）を用いてもよい。
　図４５は、この場合のシーンディスクリプション（mesh）の記述例を示す図である。図４５において点線枠内に示されるように、MPEG_vpcc.attribute内において、汎用のオブジェクト"vpccattributes"が規定され、そのオブジェクトにおいて、"accessorId"および"attributeId"のプロパティとともに、アトリビュートのタイプを指定するためのプロパティ"attributeType"が設けられている。図４５の例の場合、この"attributeType"の値として、反射率を示す識別情報"ATTR_REFLECTANCE"が設定されている。
　クライアント装置のメディアアクセスファンクションは、このような情報により指定されたアトリビュートのデータを、指定されたバッファに格納する。また、プレゼンテーションエンジンは、その指定されたバッファに格納されるそのアトリビュートのデータを読み出す。
　このようにすることにより、シーンディスクリプションにおいて、アトリビュート専用のオブジェクトを設ける必要なしに、汎用のオブジェクトにより、色情報以外のアトリビュート情報を指定することができる。
　なお、図４４の例において、MPEG_vpccの"POSITION"および"COLOR"のプロパティは省略し得る。必要な場合だけ設けるようにしてもよい。
　　＜ファイル生成装置＞
　上述した方法２（方法２－１乃至方法２－４を含む）は、任意の装置に適用し得る。例えば、3Dオブジェクトコンテンツの配信用の情報を生成するファイル生成装置に適用してもよい。その場合、ファイル生成装置の構成は、図２８を参照して説明した場合と同様である。
　図２８に示されるファイル生成装置１００において、ファイル生成部１１４は、本技術を適用してファイル等を生成する。
　例えば、ファイル生成部１１４は、上述した方法２を適用し、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを有するシーン記述ファイルを生成してもよい。
　このようにすることにより、ファイル生成装置１００は、クライアント装置が色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができるようにすることができる。つまり、色情報以外のアトリビュートに対応することができる。
　なお、その3Dオブジェクトコンテンツはポイントクラウドであってもよい。そして、ファイル生成部１１４は、glTF2.0に準拠する方式で記述されるシーン記述ファイルを生成し、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトをそのシーン記述ファイルのmesh.primitives内に規定してもよい。
　また、ファイル生成部１１４は、mesh.primitives内にextensionを規定し、そのextension内に、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを規定してもよい。
　また、上述した方法２－１を適用し、そのオブジェクトが、3Dオブジェクトコンテンツのデータにおけるアトリビュートのデータの識別情報と、そのアトリビュートのデータが格納されるバッファに紐づくアクセサ（accessor）の識別情報とを格納してもよい。
　また、上述した方法２－４を適用し、そのオブジェクトが、アトリビュートのデータの識別情報とアクセサの識別情報に加え、アトリビュートのタイプを示す情報をさらに格納してもよい。
　また、上述した方法２－３を適用し、オブジェクトが、3Dオブジェクトコンテンツのアトラス情報が格納されるバッファに紐づくアクセサ（accessor）の識別情報、3Dオブジェクトコンテンツのジオメトリが格納されるバッファに紐づくアクセサの識別情報、3Dオブジェクトコンテンツの全てのアトリビュートが格納されるバッファに紐づくアクセサの識別情報、および、3Dオブジェクトコンテンツのオキュパンシー情報が格納されるバッファに紐づくアクセサの識別情報を格納してもよい。
　また、上述した方法２－２を適用し、ファイル生成部１１４が、mesh.primitives内に、3Dオブジェクトコンテンツの位置に関する情報、色に関する情報、およびアトリビュートに関する情報を格納するオブジェクトを規定してもよい。
　これらの本技術の内のいずれか１つ以上を適用することにより、ファイル生成装置１００は、＜３．アトリビュートの指定＞において説明したのと同様の効果を得ることができる。
　　＜ファイル生成処理の流れ＞
　このような構成のファイル生成装置１００が実行するファイル生成処理の流れの例を、図４６のフローチャートを参照して説明する。
　ファイル生成処理が開始されると、ファイル生成装置１００の入力部１１１は、ステップＳ４０１において、3Dオブジェクトのデータ（3Dデータ）を取得する。例えば、入力部１１１は、この3Dデータとして、ポイントクラウドのデータを取得する。
　ステップＳ４０２において、前処理部１１２は、ステップＳ４０１において取得された3Dオブジェクトのデータから、１つ以上の3Dオブジェクトを3D空間に配置するための空間配置情報であるシーンディスクリプションの生成に用いられる情報を取得する。そして、ファイル生成部１１４は、その情報を用いて、シーンディスクリプションファイルを生成する。
　ステップＳ４０３において、符号化部１１３は、ステップＳ４０１において取得されたポイントクラウドのデータ（3Dデータ）を符号化し、その符号化データ（V3Cビットストリーム）を生成する。
　ステップＳ４０４において、ファイル生成部１１４は、ステップＳ４０３において生成されたV3Cビットストリームを格納するファイルコンテナ（ISOBMFF）を生成する。また、ファイル生成部１１４は、例えば、MPD等の制御ファイルを生成してもよい。
　ステップＳ４０５において、ファイル生成部１１４は、ステップＳ４０４において生成されたISOBMFF（やMPD）に基づいて、シーンディスクリプションのmesh.primitivesにポイントクラウドの色情報以外のアトリビュート情報を格納する。
　ステップＳ４０６において、記録部１１５は、生成されたファイルコンテナ（ISOBMFF）や、（MPDや、）シーンディスクリプションファイル等を記録媒体に記録する。
　ステップＳ４０７において、出力部１１６は、ステップＳ４０６において記録されたファイル等を記録媒体より読み出し、所定のタイミングにおいて、その読み出したファイルをファイル生成装置１００の外部に出力する。例えば、出力部１１６は、記録媒体より読み出したファイルを、ネットワーク等の通信媒体を介して、配信サーバや再生装置等の他の装置へ送信（アップロード）してもよい。また、出力部１１６は、記録媒体より読み出したファイル等を、リムーバブルメディア等の外部記録媒体に記録してもよい。その場合、その出力されたファイルは、例えば、その外部記録媒体を介して他の装置（配信サーバや再生装置等）に供給されてもよい。
　ステップＳ４０７の処理が終了すると、ファイル生成処理が終了する。
　このようなファイル生成処理のステップＳ４０５において、ファイル生成部１１４は、＜３．アトリビュートの指定＞の＜ファイル生成装置＞において上述したように本技術の各種方法を適用して、シーンディスクリプションのmesh.primitivesにポイントクラウドの色情報以外のアトリビュート情報を格納することができる。したがって、ファイル生成装置１００は、このようにファイル生成処理を実行することにより、クライアント装置が色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができるようにすることができる。つまり、色情報以外のアトリビュートに対応することができる。また、ファイル生成装置１００は、＜３．アトリビュートの指定＞において説明したのと同様の効果を得ることができる。
　　＜クライアント装置＞
　また、本技術は、3シーン記述ファイル（シーンディスクリプション）に基づいて、3Dオブジェクトコンテンツの再生処理を行う再生装置であるクライアント装置に適用してもよい。その場合、クライアント装置の構成は、図３０を参照して説明した場合と同様である。
　図３０に示されるクライアント装置２００において、ファイル処理部２１２は、本技術を適用してシーンディスクリプションファイルや、（MPDや、）3Dオブジェクトコンテンツのデータ等を取得する。
　例えば、ファイル処理部２１２は、上述した方法２を適用し、3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルに規定されるオブジェクトに格納される、3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報に基づいて、そのアトリビュートのデータを取得してもよい。ファイル処理部２１２は、ファイル取得部２１１を制御することにより、このような処理を実現する。つまり、ファイル処理部２１２は、取得部とも言える。
　このようにすることにより、クライアント装置２００は、色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。
　なお、その3Dオブジェクトコンテンツはポイントクラウドであってもよい。また、シーン記述ファイルは、glTF2.0に準拠する方式で記述されてもよい。また、オブジェクトは、そのシーン記述ファイルのmesh.primitives内に規定されてもよい。
　また、そのオブジェクトは、mesh.primitives内に規定されたextension内に規定されてもよい。
　また、上述した方法２－１を適用し、取得部が、そのオブジェクトに格納される、3Dオブジェクトコンテンツのデータにおけるアトリビュートのデータの識別情報と、そのアトリビュートのデータが格納されるバッファに紐づくアクセサ（accessor）の識別情報とに基づいて、そのバッファからそのアトリビュートのデータを取得してもよい。
　また、上述した方法２－４を適用し、取得部が、さらに、そのオブジェクトに格納される、アトリビュートのタイプを示す情報に基づいて、そのバッファからそのアトリビュートのデータを取得してもよい。
　また、上述した方法２－３を適用し、取得部が、3Dオブジェクトコンテンツのアトラス情報が格納されるバッファに紐づくアクセサ（accessor）の識別情報、3Dオブジェクトコンテンツのジオメトリが格納されるバッファに紐づくアクセサの識別情報、および、3Dオブジェクトコンテンツのオキュパンシー情報が格納されるバッファに紐づくアクセサの識別情報とともにそのオブジェクトに格納される、3Dオブジェクトコンテンツの全てのアトリビュートが格納されるバッファに紐づくアクセサの識別情報に基づいて、そのバッファからそのアトリビュートのデータを取得してもよい。
　また、上述した方法２－２を適用し、そのオブジェクトが、さらに、3Dオブジェクトコンテンツの位置に関する情報、および、3Dオブジェクトコンテンツの色に関する情報を格納してもよい。
　これらの本技術の内のいずれか１つ以上を適用することにより、クライアント装置２００は、＜３．アトリビュートの指定＞において説明したのと同様の効果を得ることができる。
　　＜クライアント処理の流れ１＞
　このような構成のクライアント装置２００が実行するクライアント処理の流れの例を、図４７のフローチャートを参照して説明する。図４７のフローチャートは、ケース１の場合のクライアント処理の流れの例である。
　クライアント処理が開始されると、クライアント装置２００のファイル処理部２１２は、ステップＳ５０１においてファイル取得部２１１を制御し、シーンディスクリプションファイルを取得する。
　ステップＳ５０２において、ファイル処理部２１２は、ステップＳ５０１において取得したシーンディスクリプションファイルを解析する。
　ステップＳ５０３において、ファイル処理部２１２は、ステップＳ５０２の処理により得られたシーンディスクリプションファイルの解析結果に基づいてファイル取得部２１１を制御し、3Dオブジェクトコンテンツの符号化データ（V3Cビットストリーム）を取得する。
　ステップＳ５０４において、復号部２１３は、ステップＳ５０３において取得された符号化データ（V3Cビットストリーム）を復号し、ビデオデータ等を生成する。つまり、復号部２１３は、アトラス情報、ジオメトリフレーム、アトリビュートフレーム、オキュパンシーマップ等を得る。復号部２１３は、得られたこれらのデータを用いて、さらにポイントクラウドを再構成し、ポイントクラウドのデータ（ジオメトリやアトリビュート等）を生成する。そして、復号部２１３は、得られたポイントクラウドのデータを、シーン記述ファイルにより指定されるバッファに格納する。
　ステップＳ５０５において、表示情報生成部２１４は、シーンディスクリプションに基づいて、バッファからポイントクラウドのデータ（ジオメトリやアトリビュート等）を取得する。すなわち、表示情報生成部２１４は、ポイントクラウドの位置情報、色情報、およびその他のアトリビュート情報を取得する。表示情報生成部２１４は、シーンディスクリプションに従ってそのポイントクラウド（3Dオブジェクト）を３次元空間に配置し、レンダリングを行って表示画像を生成する。
　ステップＳ５０６において、表示部２１５は、ステップＳ５０５において生成された表示画像を表示する。ステップＳ５０６の処理が終了すると、クライアント処理が終了する。
　このようなクライアント処理のステップＳ５０１乃至ステップＳ５０４の各処理において、ファイル処理部２１２は、＜３．アトリビュートの指定＞の＜クライアント装置＞において上述したように本技術の各種方法を適用して、シーンディスクリプションのmesh.primitivesに格納されたポイントクラウドの色情報以外のアトリビュート情報に基づいて、そのアトリビュートのデータを取得することができる。したがって、クライアント装置２００は、このようにクライアント処理を実行することにより、色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。また、クライアント装置２００は、＜３．アトリビュートの指定＞において説明したのと同様の効果を得ることができる。
　　＜クライアント処理の流れ２＞
　次に、ケース２の場合のクライアント処理の流れの例を、図４８のフローチャートを参照して説明する。
　クライアント処理が開始されると、クライアント装置２００のファイル処理部２１２は、ステップＳ５２１においてファイル取得部２１１を制御し、シーンディスクリプションファイルを取得する。
　ステップＳ５２２において、ファイル処理部２１２は、ステップＳ５２１において取得したシーンディスクリプションファイルを解析する。
　ステップＳ５２３において、ファイル処理部２１２は、ステップＳ５２２の処理により得られたシーンディスクリプションファイルの解析結果に基づいてファイル取得部２１１を制御し、3Dオブジェクトコンテンツの符号化データ（V3Cビットストリーム）を取得する。
　ステップＳ５２４において、復号部２１３は、ステップＳ５２３において取得された符号化データ（V3Cビットストリーム）を復号し、ビデオデータ等を生成する。つまり、復号部２１３は、アトラス情報、ジオメトリフレーム、アトリビュートフレーム、オキュパンシーマップ等を得る。復号部２１３は、得られたこれらのデータをシーン記述ファイルにより指定されるバッファに格納する。
　ステップＳ５２５において、復号部２１３は、シーンディスクリプションに基づいて、バッファからビデオデータ等（アトラス情報、ジオメトリフレーム、アトリビュートフレーム、オキュパンシーマップ等）を取得する。復号部２１３は、そのビデオデータ等を用いて、ポイントクラウドを再構成し、ポイントクラウドのデータ（ジオメトリやアトリビュート等）を生成する。そして、復号部２１３は、得られたポイントクラウドのデータを、表示情報生成部２１４に供給する。
　ステップＳ５２６において、表示情報生成部２１４は、シーンディスクリプションに従ってそのポイントクラウド（3Dオブジェクト）を３次元空間に配置し、レンダリングを行って表示画像を生成する。
　ステップＳ５２７において、表示部２１５は、ステップＳ５２６において生成された表示画像を表示する。ステップＳ５２７の処理が終了すると、クライアント処理が終了する。
　このようなクライアント処理のステップＳ５２１乃至ステップＳ５２５の各処理において、ファイル処理部２１２は、＜３．アトリビュートの指定＞の＜クライアント装置＞において上述したように本技術の各種方法を適用して、シーンディスクリプションのmesh.primitivesに格納されたポイントクラウドの色情報以外のアトリビュート情報に基づいて、そのアトリビュートのデータを取得することができる。したがって、クライアント装置２００は、このようにクライアント処理を実行することにより、色情報以外のアトリビュートを有する3Dオブジェクト（ポイントクラウド）を正しく再構成することができる。つまり、色情報以外のアトリビュートに対応することができる。また、クライアント装置２００は、＜３．アトリビュートの指定＞において説明したのと同様の効果を得ることができる。
　＜４．付記＞
　　＜組み合わせ＞
　矛盾が生じない限り、上述した各種方法の任意の複数の方法を組み合わせて適用してもよい。例えば、方法１と方法２を組み合わせて適用してもよい。また、上述した各種方法を、上述していない他の任意の方法と組み合わせて適用してもよい。
　　＜コンピュータ＞
　上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
　図４９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
　図４９に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
　バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
　入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
　以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
　コンピュータが実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
　また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
　その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
　　＜本技術の適用可能な対象＞
　本技術は、任意の符号化・復号方式に適用することができる。
　また、本技術は、任意の構成に適用することができる。例えば、本技術は、様々な電子機器に応用され得る。
　また、例えば、本技術は、システムLSI（Large Scale Integration）等としてのプロセッサ（例えばビデオプロセッサ）、複数のプロセッサ等を用いるモジュール（例えばビデオモジュール）、複数のモジュール等を用いるユニット（例えばビデオユニット）、または、ユニットにさらにその他の機能を付加したセット（例えばビデオセット）等、装置の一部の構成として実施することもできる。
　また、例えば、本技術は、複数の装置により構成されるネットワークシステムにも適用することもできる。例えば、本技術を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングとして実施するようにしてもよい。例えば、コンピュータ、AV（Audio Visual）機器、携帯型情報処理端末、IoT（Internet of Things）デバイス等の任意の端末に対して、画像（動画像）に関するサービスを提供するクラウドサービスにおいて本技術を実施するようにしてもよい。
　なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、および、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　　＜本技術を適用可能な分野・用途＞
　本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。また、その用途も任意である。
　例えば、本技術は、観賞用コンテンツ等の提供の用に供されるシステムやデバイスに適用することができる。また、例えば、本技術は、交通状況の監理や自動運転制御等、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、機械等の自動制御の用に供されるシステムやデバイスに適用することができる。さらに、例えば、本技術は、農業や畜産業の用に供されるシステムやデバイスにも適用することができる。また、本技術は、例えば火山、森林、海洋等の自然の状態や野生生物等を監視するシステムやデバイスにも適用することができる。さらに、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。
　　＜その他＞
　なお、本明細書において「フラグ」とは、複数の状態を識別するための情報であり、真(1)または偽(0)の２状態を識別する際に用いる情報だけでなく、３以上の状態を識別することが可能な情報も含まれる。したがって、この「フラグ」が取り得る値は、例えば1/0の２値であってもよいし、３値以上であってもよい。すなわち、この「フラグ」を構成するbit数は任意であり、1bitでも複数bitでもよい。また、識別情報（フラグも含む）は、その識別情報をビットストリームに含める形だけでなく、ある基準となる情報に対する識別情報の差分情報をビットストリームに含める形も想定されるため、本明細書においては、「フラグ」や「識別情報」は、その情報だけではなく、基準となる情報に対する差分情報も包含する。
　また、符号化データ（ビットストリーム）に関する各種情報（メタデータ等）は、符号化データに関連づけられていれば、どのような形態で伝送または記録されるようにしてもよい。ここで、「関連付ける」という用語は、例えば、一方のデータを処理する際に他方のデータを利用し得る（リンクさせ得る）ようにすることを意味する。つまり、互いに関連付けられたデータは、１つのデータとしてまとめられてもよいし、それぞれ個別のデータとしてもよい。例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の伝送路上で伝送されるようにしてもよい。また、例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の記録媒体（または同一の記録媒体の別の記録エリア）に記録されるようにしてもよい。なお、この「関連付け」は、データ全体でなく、データの一部であってもよい。例えば、画像とその画像に対応する情報とが、複数フレーム、１フレーム、またはフレーム内の一部分などの任意の単位で互いに関連付けられるようにしてもよい。
　なお、本明細書において、「合成する」、「多重化する」、「付加する」、「一体化する」、「含める」、「格納する」、「入れ込む」、「差し込む」、「挿入する」等の用語は、例えば符号化データとメタデータとを１つのデータにまとめるといった、複数の物を１つにまとめることを意味し、上述の「関連付ける」の１つの方法を意味する。
　また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
　また、例えば、上述したプログラムは、任意の装置において実行されるようにしてもよい。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
　また、例えば、１つのフローチャートの各ステップを、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。さらに、１つのステップに複数の処理が含まれる場合、その複数の処理を、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
　また、例えば、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
　また、例えば、本技術に関する複数の技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
　なお、本技術は以下のような構成も取ることができる。
　（１）　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部
　を備える情報処理装置。
　（２）　前記トラック情報は、全ての前記他のトラックにアクセスするための情報を持つ単数のトラックを前記参照先として指定する情報である
　（１）に記載の情報処理装置。
　（３）　前記トラック情報は、前記ファイルコンテナの前記複数のトラックの内、全ての前記他のトラックにアクセスするためのトラックリファレンスを持つ前記単数のトラックを前記参照先として指定する情報である
　（２）に記載の情報処理装置。
　（４）　前記トラック情報は、前記3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、前記単数のトラックの情報を格納するアダプテーションセットを前記参照先として指定する情報である
　（２）に記載の情報処理装置。
　（５）　前記3Dオブジェクトコンテンツは、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信され、
　前記制御ファイルは、MPD（Media Presentation Description）である
　（４）に記載の情報処理装置。
　（６）　前記ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFF（International Organization for Standardization Base Media File Format）である
　（１）乃至（５）のいずれかに記載の情報処理装置。
　（７）　前記3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCC（Video-based Point Cloud Compression）に準拠する方式で符号化されたV3C（Visual Volumetric Video-based Coding）ビットストリームである
　（１）乃至（６）のいずれかに記載の情報処理装置。
　（８）　前記シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述される
　（１）乃至（７）のいずれかに記載の情報処理装置。
　（９）　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成する
　情報処理方法。
　（１１）　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する取得部
　を備える情報処理装置。
　（１２）　前記トラック情報は、全ての前記他のトラックにアクセスするための情報を持つ単数のトラックを前記参照先として指定する情報である
　（１１）に記載の情報処理装置。
　（１３）　前記トラック情報は、前記ファイルコンテナの前記複数のトラックの内、全ての前記他のトラックにアクセスするためのトラックリファレンスを持つ前記単数のトラックを前記参照先として指定する情報であり、
　前記取得部は、前記トラック情報に基づいて前記単数のトラックを参照し、前記トラックリファレンスに基づいて全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
　（１２）に記載の情報処理装置。
　（１４）　前記トラック情報は、前記3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、前記単数のトラックの情報を格納するアダプテーションセットを前記参照先として指定する情報であり、
　前記取得部は、前記制御ファイルを取得し、前記制御ファイルの、前記トラック情報により指定された前記アダプテーションセットの情報に基づいて前記単数のトラックを参照し、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
　（１２）に記載の情報処理装置。
　（１５）　前記3Dオブジェクトコンテンツは、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信され、
　前記制御ファイルは、MPD（Media Presentation Description）である
　（１４）に記載の情報処理装置。
　（１６）　前記ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFF（International Organization for Standardization Base Media File Format）である
　（１１）乃至（１５）のいずれかに記載の情報処理装置。
　（１７）　前記3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCC（Video-based Point Cloud Compression）に準拠する方式で符号化されたV3C（Visual Volumetric Video-based Coding）ビットストリームである
　（１１）乃至（１６）のいずれかに記載の情報処理装置。
　（１８）　前記シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述される
　（１１）乃至（１７）のいずれかに記載の情報処理装置。
　（１９）　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
　情報処理方法。
　（２１）　3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを有する、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部
　を備える情報処理装置。
　（２２）　前記3Dオブジェクトコンテンツはポイントクラウドであり、
　前記ファイル生成部は、
　　glTF（The GL Transmission Format）2.0に準拠する方式で記述される前記シーン記述ファイルを生成し、
　　前記オブジェクトを前記シーン記述ファイルのmesh.primitives内に規定する
　（２１）に記載の情報処理装置。
　（２３）　前記ファイル生成部は、前記mesh.primitives内にextensionを規定し、前記extension内に前記オブジェクトを規定する
　（２２）に記載の情報処理装置。
　（２４）　前記オブジェクトは、前記3Dオブジェクトコンテンツのデータにおける前記アトリビュートのデータの識別情報と、前記アトリビュートのデータが格納されるバッファに紐づくaccessorの識別情報とを格納する
　（２３）に記載の情報処理装置。
　（２５）　前記オブジェクトは、前記アトリビュートのタイプを示す情報をさらに格納する
　（２４）に記載の情報処理装置。
　（２６）　前記オブジェクトは、前記3Dオブジェクトコンテンツのアトラス情報が格納されるバッファに紐づくaccessorの識別情報、前記3Dオブジェクトコンテンツのジオメトリが格納されるバッファに紐づくaccessorの識別情報、前記3Dオブジェクトコンテンツの全てのアトリビュートが格納されるバッファに紐づくaccessorの識別情報、および、前記3Dオブジェクトコンテンツのオキュパンシー情報が格納されるバッファに紐づくaccessorの識別情報を格納する
　（２３）に記載の情報処理装置。
　（２７）　前記ファイル生成部は、前記mesh.primitives内に、前記3Dオブジェクトコンテンツの位置に関する情報、色に関する情報、および前記アトリビュートに関する情報を格納する前記オブジェクトを規定する
　（２２）に記載の情報処理装置。
　（２８）　3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報を格納するオブジェクトを有する、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成する
　情報処理方法。
　（３１）　3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルに規定されるオブジェクトに格納される、前記3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報に基づいて、前記アトリビュートのデータを取得する取得部
　を備える情報処理装置。
　（３２）　前記3Dオブジェクトコンテンツはポイントクラウドであり、
　前記シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述され、
　　前記オブジェクトは、前記シーン記述ファイルのmesh.primitives内に規定される
　（３１）に記載の情報処理装置。
　（３３）　前記オブジェクトは、前記mesh.primitives内に規定されたextension内に規定される
　（３２）に記載の情報処理装置。
　（３４）　前記取得部は、前記オブジェクトに格納される、前記3Dオブジェクトコンテンツのデータにおける前記アトリビュートのデータの識別情報と、前記アトリビュートのデータが格納されるバッファに紐づくaccessorの識別情報とに基づいて、前記バッファから前記アトリビュートのデータを取得する
　（３３）に記載の情報処理装置。
　（３５）　前記取得部は、さらに、前記オブジェクトに格納される、前記アトリビュートのタイプを示す情報に基づいて、前記バッファから前記アトリビュートのデータを取得する
　（３４）に記載の情報処理装置。
　（３６）　前記取得部は、前記3Dオブジェクトコンテンツのアトラス情報が格納されるバッファに紐づくaccessorの識別情報、前記3Dオブジェクトコンテンツのジオメトリが格納されるバッファに紐づくaccessorの識別情報、および、前記3Dオブジェクトコンテンツのオキュパンシー情報が格納されるバッファに紐づくaccessorの識別情報とともに前記オブジェクトに格納される、前記3Dオブジェクトコンテンツの全てのアトリビュートが格納されるバッファに紐づくaccessorの識別情報に基づいて、前記バッファからデータを取得する
　（３３）に記載の情報処理装置。
　（３７）　前記オブジェクトは、さらに、前記3Dオブジェクトコンテンツの位置に関する情報、および、前記3Dオブジェクトコンテンツの色に関する情報を格納する
　（３２）に記載の情報処理装置。
　（３８）　3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルに規定されるオブジェクトに格納される、前記3Dオブジェクトコンテンツの色以外のアトリビュートに関する情報に基づいて、前記アトリビュートのデータを取得する
　情報処理方法。
　１００　ファイル生成装置，　１０１　制御部，　１０２　ファイル生成処理部，　１１１　入力部，　１１２　前処理部，　１１３　符号化部，　１１４　ファイル生成部，　１１５　記録部，　１１６　出力部，　２００　クライアント装置，　２０１　制御部，　２０２　クライアント処理部，　２１１　ファイル取得部，　２１２　ファイル処理部，　２１３　復号部，　２１４　表示情報生成部，　２１５　表示部，　２１６　表示制御部

Claims (18)

  1. 　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成するファイル生成部
    　を備える情報処理装置。
  2. 　前記トラック情報は、全ての前記他のトラックにアクセスするための情報を持つ単数のトラックを前記参照先として指定する情報である
    　請求項１に記載の情報処理装置。
  3. 　前記トラック情報は、前記ファイルコンテナの前記複数のトラックの内、全ての前記他のトラックにアクセスするためのトラックリファレンスを持つ前記単数のトラックを前記参照先として指定する情報である
    　請求項２に記載の情報処理装置。
  4. 　前記トラック情報は、前記3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、前記単数のトラックの情報を格納するアダプテーションセットを前記参照先として指定する情報である
    　請求項２に記載の情報処理装置。
  5. 　前記3Dオブジェクトコンテンツは、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信され、
    　前記制御ファイルは、MPD（Media Presentation Description）である
    　請求項４に記載の情報処理装置。
  6. 　前記ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFF（International Organization for Standardization Base Media File Format）である
    　請求項１に記載の情報処理装置。
  7. 　前記3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCC（Video-based Point Cloud Compression）に準拠する方式で符号化されたV3C（Visual Volumetric Video-based Coding）ビットストリームである
    　請求項１に記載の情報処理装置。
  8. 　前記シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述される
    　請求項１に記載の情報処理装置。
  9. 　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイルを生成する
    　情報処理方法。
  10. 　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する取得部
    　を備える情報処理装置。
  11. 　前記トラック情報は、全ての前記他のトラックにアクセスするための情報を持つ単数のトラックを前記参照先として指定する情報である
    　請求項１０に記載の情報処理装置。
  12. 　前記トラック情報は、前記ファイルコンテナの前記複数のトラックの内、全ての前記他のトラックにアクセスするためのトラックリファレンスを持つ前記単数のトラックを前記参照先として指定する情報であり、
    　前記取得部は、前記トラック情報に基づいて前記単数のトラックを参照し、前記トラックリファレンスに基づいて全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
    　請求項１１に記載の情報処理装置。
  13. 　前記トラック情報は、前記3Dオブジェクトコンテンツのデータの配信を制御するための制御ファイルにおける、前記単数のトラックの情報を格納するアダプテーションセットを前記参照先として指定する情報であり、
    　前記取得部は、前記制御ファイルを取得し、前記制御ファイルの、前記トラック情報により指定された前記アダプテーションセットの情報に基づいて前記単数のトラックを参照し、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
    　請求項１１に記載の情報処理装置。
  14. 　前記3Dオブジェクトコンテンツは、MPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over Hypertext Transfer Protocol）に準拠する方式で配信され、
    　前記制御ファイルは、MPD（Media Presentation Description）である
    　請求項１３に記載の情報処理装置。
  15. 　前記ファイルコンテナは、マルチトラックストラクチャを適用するISOBMFF（International Organization for Standardization Base Media File Format）である
    　請求項１０に記載の情報処理装置。
  16. 　前記3Dオブジェクトコンテンツのデータは、ポイントクラウドがV-PCC（Video-based Point Cloud Compression）に準拠する方式で符号化されたV3C（Visual Volumetric Video-based Coding）ビットストリームである
    　請求項１０に記載の情報処理装置。
  17. 　前記シーン記述ファイルは、glTF（The GL Transmission Format）2.0に準拠する方式で記述される
    　請求項１０に記載の情報処理装置。
  18. 　3Dオブジェクトコンテンツのデータに関する情報を管理するファイルコンテナの複数のトラックの内、他のトラックにアクセスするための情報を持つ一部のトラックを参照先として指定するトラック情報を含む、前記3Dオブジェクトコンテンツのシーンを記述するシーン記述ファイル、および、前記トラック間の参照関係に基づいて、全ての前記トラックにおいて管理される前記3Dオブジェクトコンテンツのデータを取得する
    　情報処理方法。
PCT/JP2021/048117 2020-12-28 2021-12-24 情報処理装置および方法 WO2022145357A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2022573052A JPWO2022145357A1 (ja) 2020-12-28 2021-12-24
EP21915217.0A EP4270962A4 (en) 2020-12-28 2021-12-24 INFORMATION PROCESSING DEVICE AND METHOD
CN202180086825.8A CN116636225A (zh) 2020-12-28 2021-12-24 信息处理装置和方法
US18/268,620 US20240046562A1 (en) 2020-12-28 2021-12-24 Information processing device and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063131003P 2020-12-28 2020-12-28
US63/131,003 2020-12-28

Publications (1)

Publication Number Publication Date
WO2022145357A1 true WO2022145357A1 (ja) 2022-07-07

Family

ID=82259428

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/048117 WO2022145357A1 (ja) 2020-12-28 2021-12-24 情報処理装置および方法

Country Status (5)

Country Link
US (1) US20240046562A1 (ja)
EP (1) EP4270962A4 (ja)
JP (1) JPWO2022145357A1 (ja)
CN (1) CN116636225A (ja)
WO (1) WO2022145357A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024014526A1 (ja) * 2022-07-15 2024-01-18 ソニーグループ株式会社 情報処理装置および方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017145757A1 (ja) * 2016-02-22 2017-08-31 ソニー株式会社 ファイル生成装置およびファイル生成方法、並びに、再生装置および再生方法
US20200302632A1 (en) * 2019-03-21 2020-09-24 Lg Electronics Inc. Point cloud data transmission apparatus, point cloud data transmission method, point cloud data reception apparatus, and point cloud data reception method
WO2021251173A1 (ja) * 2020-06-12 2021-12-16 ソニーグループ株式会社 情報処理装置および方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7035401B2 (ja) * 2017-09-15 2022-03-15 ソニーグループ株式会社 画像処理装置およびファイル生成装置
US11218715B2 (en) * 2019-06-14 2022-01-04 Mediatek Singapore Pte. Ltd. Methods and apparatus for spatial grouping and coordinate signaling for immersive media data tracks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017145757A1 (ja) * 2016-02-22 2017-08-31 ソニー株式会社 ファイル生成装置およびファイル生成方法、並びに、再生装置および再生方法
US20200302632A1 (en) * 2019-03-21 2020-09-24 Lg Electronics Inc. Point cloud data transmission apparatus, point cloud data transmission method, point cloud data reception apparatus, and point cloud data reception method
WO2021251173A1 (ja) * 2020-06-12 2021-12-16 ソニーグループ株式会社 情報処理装置および方法

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"ISO/IEC FDIS 23090-5 Visual Volumetric Video-based Coding and Video-based Point Cloud Compression", ISO/IEC JTC 1/SC 29/ WG 11 N19579, 21 September 2020 (2020-09-21)
"Text of ISO/IEC CD 23090-14 Scene Description for MPEG Media", ISO/IEC JTC 1/SC 29/WG 3 N00026, 7 December 2020 (2020-12-07)
"Text of ISO/IEC DIS 23090-10 Carriage of Visual Volumetric Video-based Coding Data", ISO/IEC JTC 1/SC 29/WG 11 N19285, 1 June 2020 (2020-06-01)
SAURABH BHATIAPATRICK COZZIALEXEY KNYAZEVTONY PARISI, KHRONOS GLTF2.0, 9 June 2017 (2017-06-09), Retrieved from the Internet <URL:https://github.com/KhronosGroup/glTF/tree/master/specification/2.0>
See also references of EP4270962A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024014526A1 (ja) * 2022-07-15 2024-01-18 ソニーグループ株式会社 情報処理装置および方法

Also Published As

Publication number Publication date
CN116636225A (zh) 2023-08-22
EP4270962A4 (en) 2024-05-01
EP4270962A1 (en) 2023-11-01
US20240046562A1 (en) 2024-02-08
JPWO2022145357A1 (ja) 2022-07-07

Similar Documents

Publication Publication Date Title
US11532103B2 (en) Information processing apparatus and information processing method
KR102655630B1 (ko) 3차원 비디오 컨텐츠를 포함하는 미디어 파일을 생성하는 방법 및 장치 및 3차원 비디오 컨텐츠를 재생하는 방법 및 장치
WO2021251185A1 (ja) 情報処理装置および方法
WO2021251173A1 (ja) 情報処理装置および方法
US11825135B2 (en) Information processing apparatus, information processing method, reproduction processing apparatus, and reproduction processing method
EP4013042A1 (en) Information processing device, reproduction processing device, and information processing method
WO2022145357A1 (ja) 情報処理装置および方法
WO2022070903A1 (ja) 情報処理装置および方法
WO2022075342A1 (ja) 情報処理装置および方法
WO2022054744A1 (ja) 情報処理装置および方法
WO2022220291A1 (ja) 情報処理装置および方法
WO2022220255A1 (ja) 情報処理装置および方法
WO2021002142A1 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
WO2023054156A1 (ja) 情報処理装置および方法
WO2022220278A1 (ja) 情報処理装置および方法
CN114026875A (zh) 信息处理装置、信息处理方法、再现处理装置和再现处理方法
WO2023176928A1 (ja) 情報処理装置および方法
WO2023204289A1 (ja) 情報処理装置および方法
WO2022138231A1 (ja) 画像処理装置および方法
WO2022075079A1 (ja) 情報処理装置および方法
WO2023277062A1 (ja) 情報処理装置および方法
WO2021251141A1 (ja) 情報処理装置および方法
CN114598895B (zh) 音视频处理方法、装置、设备及计算机可读存储介质
JP2024503059A (ja) マルチトラックベースの没入型メディアプレイアウト
CN118118694A (zh) 点云封装与解封装方法、装置、介质及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21915217

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022573052

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 202180086825.8

Country of ref document: CN

Ref document number: 18268620

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2021915217

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021915217

Country of ref document: EP

Effective date: 20230728