[go: up one dir, main page]

WO2020008758A1 - 情報処理装置および情報処理方法、並びにプログラム - Google Patents

情報処理装置および情報処理方法、並びにプログラム Download PDF

Info

Publication number
WO2020008758A1
WO2020008758A1 PCT/JP2019/021191 JP2019021191W WO2020008758A1 WO 2020008758 A1 WO2020008758 A1 WO 2020008758A1 JP 2019021191 W JP2019021191 W JP 2019021191W WO 2020008758 A1 WO2020008758 A1 WO 2020008758A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
dimensional
information
stream
information processing
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2019/021191
Other languages
English (en)
French (fr)
Inventor
遼平 高橋
平林　光浩
央二 中神
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to CN201980044256.3A priority Critical patent/CN112369016A/zh
Priority to KR1020207037126A priority patent/KR20210025527A/ko
Priority to US15/734,559 priority patent/US11516453B2/en
Priority to JP2020528720A priority patent/JP7310816B2/ja
Priority to EP19830286.1A priority patent/EP3820147A4/en
Publication of WO2020008758A1 publication Critical patent/WO2020008758A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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/234327—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 by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/139—Format conversion, e.g. of frame-rate or size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/20—Image signal generators
    • H04N13/275—Image signal generators from 3D object models, e.g. computer-generated stereoscopic image signals
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • 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
    • 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
    • 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
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189—Recording image signals; Reproducing recorded image signals

Definitions

  • the present disclosure relates to an information processing apparatus, an information processing method, and a program, and more particularly, to an information processing apparatus, an information processing method, and a program capable of performing processing in a simple manner.
  • Non-Patent Document 1 a compression method of Point @ Cloud, which is a set of points simultaneously having position information and attribute information (particularly, color information) in a three-dimensional space, is defined.
  • Non-Patent Document 2 as one of the compression methods of Point @ Cloud, Point @ Cloud is divided into a plurality of regions (hereinafter, referred to as segmentation), and a plane image is generated for each region to generate a texture image and a geometry image. Then, a method of encoding them by a moving image codec is disclosed.
  • the geometry image is an image composed of depth information of a point cloud constituting Point @ Cloud.
  • Non-Patent Document 3 discloses the structure of a Point @ Cloud stream generated by PCC @ TMC2 (hereinafter, also referred to as PC @ stream).
  • MPEG Moving Picture Experts Group
  • Patent Document 1 discloses an image processing apparatus that records three-dimensional image data by packing it by a side-by-side method or a top-and-bottom method.
  • An information processing apparatus converts at least a first image and a second image, and a first image and a second image by converting 3D data representing a three-dimensional structure into two dimensions. And three-dimensional information metadata necessary for constructing the three-dimensional data are obtained, and one unit of the file constituting the 3D data displayed at a specific time is stored in the first image and the second image. The first image and the second image and the three-dimensional information metadata are stored and generated in accordance with a reproduction order required when reproducing and reproducing in three dimensions based on the three-dimensional information metadata.
  • a file generation unit is provided.
  • An information processing method or a program converts at least a first image and a second image, and a first image and a second image by converting 3D data representing a three-dimensional structure into two dimensions. And three-dimensional information metadata necessary for constructing the three-dimensional image are obtained.
  • One unit of the file constituting the 3D data displayed at a specific time is stored in the first image and the second image.
  • the first image, the second image, and the three-dimensional information metadata are stored in accordance with a reproduction order necessary when reproducing and reproducing an image in three dimensions based on the three-dimensional information metadata. Including generating.
  • At least a first image and a second image and a first image and a second image are three-dimensionally converted by converting 3D data representing a three-dimensional structure into two-dimensional data.
  • Three-dimensional information metadata necessary to perform the processing is obtained, and one unit of the file constituting the 3D data displayed at a specific time is used to convert the first image and the second image based on the three-dimensional information metadata.
  • the first image and the second image and the three-dimensional information metadata are stored and generated in accordance with the order of reproduction required when reproducing and reproducing three-dimensionally.
  • processing can be performed simply.
  • FIG. 4 is a diagram illustrating a compression method of Point @ Cloud. It is a figure which shows the structure of PC @ stream.
  • FIG. 3 is a diagram illustrating a structure of a GOF. It is a figure which shows the structure of a geometry video stream and a texture video stream. It is a figure which shows the structure of PC @ sample newly defined. It is a figure showing an example of PC @ sample.
  • FIG. 4 is a diagram illustrating an example of information stored in PC @ header.
  • FIG. 4 is a diagram illustrating an example of information stored in a header. It is a figure showing an example of information stored in GOF @ header.
  • FIG. 11 is a diagram showing an example when a PC stream is stored in an ISOBMFF 1 track.
  • FIG. 3 is a block diagram illustrating a first configuration example of an information processing apparatus that executes a PC file generation process. It is a block diagram showing the 1st example of composition of the information processor which performs Point @ Cloud reproduction processing.
  • FIG. 13 is a flowchart illustrating a first processing example of a PC file generation process. It is a flowchart explaining the 1st processing example of Point @ Cloud reproduction
  • FIG. 4 is a diagram illustrating an example of an ISOBMFF structure in a first storage method.
  • FIG. 10 is a diagram for explaining linking from enhancement @ track to base @ track by track @ reference. It is a figure showing the variation of packing. It is a figure which shows an example of signaling of elementary @ stream. It is a figure showing an example of SEI newly defined. It is a figure explaining the definition of packing_arrangement and frame0_is_geometry.
  • FIG. 3 is a diagram showing a definition of frame0.
  • FIG. 11 is a diagram showing an example when a PC stream is stored in an ISOBMFF 1 track. It is a figure showing an example of PCPackingInfoBox. It is a block diagram showing the 2nd example of composition of the information processor which performs packed @PC file generation processing.
  • FIG. 11 is a block diagram illustrating a second configuration example of an information processing device that executes a Point @ Cloud reproduction process. It is a flowchart explaining the 2nd processing example of packed @ PC file generation processing. It is a flowchart explaining the 2nd example of a process of Point @ Cloud reproduction
  • FIG. 29 is a diagram illustrating a modification of the PCPackingInfoBox.
  • FIG. 11 is a diagram illustrating an example of an ISOBMFF structure in a second storage method.
  • FIG. 3 is a diagram illustrating an example of ISOBMFF signaling. It is a figure showing the definition of GOFEntry (). It is a figure showing the definition of PCFrameEntry (). It is a figure showing the definition of ComponentGroupEntry (). It is a figure explaining identification of the interleave cycle of sample. It is a figure showing an example of the ISOBMFF structure in the 3rd storage method.
  • FIG. 4 is a diagram for explaining an example in which a signal is sent without using SEI.
  • FIG. 3 is a diagram illustrating an example of ISOBMFF signaling. It is a figure showing an example of the syntax of PCMultiStreamBox.
  • FIG. 3 is a diagram illustrating an example of ISOBMFF signaling. It is a figure showing an example of the syntax of PCMultiStreamBox.
  • FIG. 3 is a diagram illustrating an example of ISOBMFF signaling. It is a figure showing an example of the syntax of PCMultiStreamBox.
  • FIG. 3 is a diagram illustrating an
  • FIG. 21 is a diagram illustrating a modified example of PCMultiStreamBox. It is a figure showing an example of the syntax of PCTextureTrackGroup.
  • FIG. 21 is a diagram illustrating a modified example of PCMultiStreamBox. It is a figure which shows the example which signals geometry @ track and texture @ track linked by track @ group. It is a figure showing an example of PCStreamGroupBox newly defined. It is a figure showing an example of the ISOBMFF structure in the 4th storage method.
  • FIG. 3 is a diagram illustrating DASH signaling.
  • FIG. 3 is a diagram illustrating DASH signaling. It is a figure showing the outline of SubSampleInformationBox. It is a figure showing the outline of Sample @ Group.
  • FIG. 2 is a block diagram illustrating a configuration example of a data generation device.
  • FIG. 3 is a block diagram illustrating a configuration example of a data reproduction device.
  • FIG. 21 is a block diagram illustrating a configuration example of an embodiment of a computer to which the present technology is applied.
  • FIG. 1 is a diagram for simply explaining the Point @ Cloud compression method disclosed in Non-Patent Document 2 described above.
  • a Point @ Cloud representing a three-dimensional structure is input, and the Point @ Cloud is segmented.
  • Point @ Cloud representing a three-dimensional structure in which a hemispherical shape and a conical shape are combined is input, and segmentation is performed on three regions obtained by dividing the hemispherical shape into one region and the conical shape into two regions.
  • planar projection is performed for each region, and a texture image composed of color information representing the appearance of the surface of each region and a geometry image composed of positional information representing the depth to the surface of each region (depth) are obtained.
  • the texture image and the geometry image are encoded by a moving image codec such as AVC (Advanced Video Coding) or HEVC (High Efficiency Video Coding).
  • AVC Advanced Video Coding
  • HEVC High Efficiency Video Coding
  • FIG. 2 is a diagram showing the structure of the PC stream.
  • the PC stream is composed of 1 stream, and in the unit of Group of Frames (GOF), a plurality of Point Cloud frames that are continuously displayed at a specific time width are grouped. ing.
  • Point @ Cloud @ frame (hereinafter also referred to as PC @ frame) is Point @ Cloud displayed at the same time.
  • the GOF is composed of a texture video stream that encodes a texture image, a geometry video stream that encodes a geometry image, and three-dimensional information metadata (auxiliary patch info and occupancy map) used for 2D3D conversion.
  • the geometry video stream and the texture video stream have (frame rate of PC stream) x (GOF time width) x N (number of layers) frames.
  • the geometry video stream and the texture video stream each have N frames per 1 frame of the PC stream. This is for expressing the layer structure in the thickness direction of Point @ Cloud. That is, it means that PC frame is composed of N frames each.
  • the client decodes the geometry video stream and the texture video stream in the PC stream, and generates a geometry patch and a texture patch using the occupancy map. After that, the client first generates a colorless Point Cloud from the geometry patch using the auxiliary patch info, and then colorizes the Point Cloud with the texture patch.
  • FIG. 3 shows the structure of the GOF in the conventional PC stream, and shows an example in which the number of layers is two.
  • PC frames displayed within a specific time width have a structure in which they are not continuously arranged in a stream. That is, in the conventional PC stream, the elements necessary for the reproduction of the PC frame # 1 and the elements required for the reproduction of the PC frame # 2 are arranged so as to be located one behind the other. For this reason, for example, the elements necessary for the reproduction of the PC frame # 1, such as geometry frame # 1 layer0, geometry frame # 1 layer1, auxiliary patch information, and occupancy map # 1, texture frame # 1 layer0, and texture frame # 1 layer1 When accessing and then accessing the elements required for PC frame # 2 playback, processing that starts access from geometry frame # 2 ⁇ ⁇ layer0 located in front of texture frame # 1 layer1 occurs. would. Therefore, as described above, a large amount of random access occurs during normal reproduction.
  • the PC stream structure shown in FIG. 3 is different from the stream configuration of the existing video codec, and is not suitable for storage in ISOBMFF and distribution in over IP (Internet Protocol).
  • Non-Patent Document 4 described above discloses a method in which a geometry video stream and a texture video stream are handled independently for each stream and stored in individual tracks. However, even in this method, a large amount of random access occurs during normal reproduction.
  • Non-Patent Document 4 selects the bitrate of each stream according to the network bandwidth when acquiring the geometry video stream and the texture video stream, and Useful for reconstructing quality PCC. This is because the burden of arranging many single streams (combinations of geometry video streams and texture video streams with different bitrates) on the server is eliminated.
  • processing in the client is performed by newly defining a method of linking the geometry video stream and the texture video stream constituting the PC stream. Can be performed simply.
  • PC sample definition for storing ISOBMFF> A Point Cloud sample (hereinafter, referred to as a PC sample) newly defined for storing the ISOBMFF will be described with reference to FIG.
  • FIG. 5 is a diagram showing the structure of a newly defined PC sample.
  • the unit constituting Point Cloud displayed at the same time is called 1 PC frame, and it is defined that 1 PC frame is composed of 1 PC sample.
  • the geometry image and the texture image and the three-dimensional information metadata are combined with the ISOBMFF 1 track according to the reproduction order required when reproducing and reproducing the geometry image and the texture image in three dimensions based on the three-dimensional information metadata.
  • the client can configure a Point @ Cloud displayed at the same time by decoding 1 @ PC @ sample. Thereby, the client can avoid the occurrence of a large amount of random access during the normal reproduction as described above, and can perform the processing simply, so that, for example, processing delay and increase in processing cost Can be avoided.
  • PC stream defined in this way is composed of a series of a plurality of PC samples.
  • 1 ⁇ PC ⁇ sample is composed of a plurality of components and three-dimensional information metadata.
  • the component includes a texture image and a geometry image.
  • the three-dimensional information metadata includes auxiliary @ patch @ info and occupnacy @ map, and PC @ header.
  • One component is composed of multiple subsamples. That is, one component is composed of N (layer) geometrygesubsamples and N (layer) texture subsamples.
  • the geometry @ subsamples and the texture @ subsamples are individually encoded by the video codec.
  • the subsample is a unit that constitutes 1 picture of the geometry video stream and the texture video stream.
  • the header has information indicating the layer structure of the component.
  • the occupancy map has patch position information in the picture of the component, and the auxiliary patch information has 2D3D conversion information for attaching the patch to the 3D object.
  • the GOF information is included in the PC header, but the GOF header may be individually signaled in the PC sample. Also, three-dimensional information metadata such as PC @ header, auxiliary @ patch @ info, and occupancy @ map may be used as the subsample.
  • FIG. 6 shows an example of a PC sample (that is, a sample of ISOBMFF) when the number of layers is 2 and the video codec used for encoding is AVC or HEVC.
  • AUD Access @ Unit @ Delimiter
  • NAL Network @ Abstraction @ Layer
  • PC sample shown in FIG. 6 has a configuration in which, after PC ⁇ header, geometry0subsample of layer0, geometry subsample of layer1, texture subsample of layer0, and texture subsample of layer1 are continuously arranged.
  • FIG. 7 shows an example of information stored in the PC header of FIG.
  • information indicating the size of PC @ sample (size_of_pc_frame) and information (number_of_layer) indicating the number of layers of the texture image or geometry image forming 1PC @ frame are stored in the PC @ header.
  • information indicating the width of the geometry image or the texture image (frameWidth), information indicating the height of the geometry image or the texture image (frameHeight), and information indicating the resolution of the occupnacy map (occupancyResolution) are stored in the PC header. Is done.
  • PC header includes information indicating a radius for detecting a nearby point for smoothing (radiusToSmoothing), information indicating a maximum number of nearby points used for smoothing (neighborCountSmoothing), and a radius for detecting a boundary point.
  • RadiusToSmoothing information indicating a radius for detecting a nearby point for smoothing
  • neighborCountSmoothing information indicating a maximum number of nearby points used for smoothing
  • a radius for detecting a boundary point a radius for detecting a boundary point.
  • Radius2BoundaryDetection information indicating a smoothing threshold are stored.
  • FIG. 8 shows an example of information stored in the header of FIG.
  • the header stores information (size_of_sample) indicating the size of the subsample of the texture image or geometry image, information (type) indicating the type of the subsample, and the layer identifier (layer_id) of the subsample. . For example, if the information indicating the type of the subsample is 0, it indicates that the subsample is a geometry image, and if the information indicating the type of the subsample is 1, it indicates that the subsample is a texture image.
  • the occupancy map and auxiliary patch information are included in the geometry subsample as SEI (Supplemental Enhancement Infromation).
  • the client can identify the boundary of PC sample from PC header, and can identify the boundary of subsample of each component from header. Therefore, the client can extract the geometry video stream and the texture video stream from the PC sample according to those boundaries, and input them to the decoder to execute the decoding process.
  • the same information is signaled to the subsample of each layer. However, the information may be different for each layer. Also, the SEI may be signaled to texture @ subsample.
  • a known GOF header may be signaled at the head of the GOF of the PC stream.
  • FIG. 9 shows an example of information stored in the GOF @ header.
  • information (group0fFramesSize) indicating the number of frames in Group @ of @ Frames is stored in GOF @ header.
  • the same information as the PC @ header shown in FIG. 7 is stored in the GOF @ header.
  • the occupancy map may be encoded by a moving image codec and may be occupancy subsample as one type of component.
  • FIG. 10 shows an example when the PC stream is stored in the 1 track of ISOBMFF.
  • a newly defined PCSampleEntry (see FIG. 12) is stored in the moov of ISOBMFF, and the PCSampleEntry is composed of a PCHeaderBox shown in FIG. 13, a SubSampleEntryBox shown in FIG. 14, and a LayerCompositionBox shown in FIG.
  • subs (SubSampleInformationBox) is stored in the moof of the ISOBMFF, and as shown in FIG. 10, the boundary between the geometrysamplesubsample and the texturesamplesubsample in the PC sample can be signaled using the SubSampleInformationBox.
  • SubSampleInformation will be described with reference to the outline of SubSampleInformationBox shown in FIG. 54 described later.
  • codec_specific_parameters which is information of a subsample determined for each encoding codec
  • codec_specific_parameters when the value of codec_specific_parameters is 0, it indicates that subsample is geometry @ subsample, and when the value of codec_specific_parameters is 1, it indicates that subsample is texture @ subsample.
  • codec_specific_parameters may include the information of the layer identifier.
  • the subsample @ information may be provided in units of a continuous geometry @ subsample group and a texture @ subsample group.
  • three-dimensional information metadata such as occupancy map and auxiliary patch info are not signaled as SEI, but are signaled as subsamples as a type of component, a value indicating each subsample is added to subsample information. Good.
  • FIG. 12 shows the structure of PCSampleEntry newly defined in the present disclosure.
  • the sample entry of the track of the ISOBMFF storing the PC stream is, for example, 'pcbs'.
  • the PCHeaderBox information may be signaled as the sample group.
  • the information of the GOF @ header may be signaled to the sample @ entry, sample @ group, etc., separately from the PCHeaderBox.
  • the Sample @ Group will be described with reference to the outline of Sample @ Group shown in FIG. 55 described later.
  • the client can identify the boundary of the PC sample and the boundary of the subsample of each component without parsing the contents of the subsample. That is, the client can extract the geometry video stream and the texture video stream from the PC sample and execute the decoding process by inputting them to the respective decoders by a simplified process of referring to only the signaling of the system layer.
  • the SubSampleEntryBox signals a texture video stream, a geometry video stream codec and decoderdeconfiguration information composed of consecutive subsamples.
  • Numnum_of_component shown in FIG. 14 indicates the total number of components stored in the track, and the type field indicates the type of the component corresponding to sub sample entry. For example, if the type field is 0, it indicates that the type of the component corresponding to sub @ sample @ entry is a geometry image, and if the type field is 1, the type of the component corresponding to sub @ sample @ entry is a texture image. Indicates that SampleEntry () changes according to the encoding codec of the component. For example, HEVCSampleEntry when HEVC encoding is performed.
  • the association of each sub sample entry with the corresponding subsample is performed based on the codec_specific_parameters of the sub sample information and the type of the component signaled by the type of the sub sample entry.
  • the coding codec may be changed for each type of component.
  • the client can identify the codecs of the geometry @ video @ stream and the texture @ video @ stream and execute the decoding process correctly.
  • the LayerCompositionBox signals the number of layers having the same composition time, and the number of components constituting PC sample.
  • num_layer_composed indicates the number of decoded pictures forming 1 PC frame with output order. Also, num_of_component indicates the number of components constituting 1 ⁇ PC ⁇ frame.
  • a signal is sent to the sample @ entry.
  • the signal is not limited to this location, and may be sent to, for example, a SubSampleEntryBox.
  • a Point @ Cloud displayed at the same time can be configured, and the subsample to be rendered at the same time can be explicitly indicated. This allows the client to correctly configure and render Point @ Cloud.
  • a configuration in which the number of components is 1 and the number of layers is 2 is based on the same concept as conventional technology, for example, temporal interleaving in stereo video.
  • the present technology is different from the conventional technology that cannot cope with such a configuration in that it is possible to cope with a configuration having a plurality of components and a plurality of layers.
  • FIG. 17 shows a first configuration of an information processing apparatus that generates a PC stream from Point Cloud content on the server providing the content, and executes a PC file generation process of generating a PC file storing the PC stream in ISOBMFF. It is a block diagram showing an example.
  • the information processing device 11 includes a 3D2D conversion unit 21, an encoding unit 22, a PC stream generation unit 23, and a file generation unit 24.
  • the 3D2D conversion unit 21 generates a geometry image and a texture image and three-dimensional information metadata (auxiliary patch information and occupancy map) by converting the input Point Cloud into two dimensions, and encodes the encoded image. To supply.
  • the coding unit 22 codes a geometry video stream including the three-dimensional information metadata as SEI from the geometry image and the three-dimensional information metadata, and codes a texture video stream from the texture image.
  • the encoding unit 22 performs encoding using non-layered encoding such as AVC and HEVC, or layered encoding such as SVC or SHEVC.
  • the encoding unit 22 can perform the encoding of the geometry image and the encoding of the texture image in parallel by the two encoders 25-1 and 25-2.
  • the PC stream generating unit 23 interleaves the geometry video stream and the texture video stream encoded by the encoding unit 22 in units of a PC frame, and generates a PC sample as shown in FIG. Then, the PC stream generator 23 generates a PC stream composed of a plurality of PC samples and supplies the PC stream to the file generator 24.
  • the file generating unit 24 converts the geometry image and the texture image and the three-dimensional information metadata into three-dimensional information in accordance with a reproduction order necessary for reproducing and reproducing the geometry image and the texture image in three dimensions based on the three-dimensional information metadata. Store it in the 1BMtrack of ISOBMFF and generate a PC file.
  • the information processing apparatus 11 configured as described above can generate a PC stream from the Point Cloud content, and output a PC file in which the PC stream is stored in the 1 track of ISOBMFF.
  • FIG. 18 is a block diagram illustrating a first configuration example of an information processing apparatus that executes a Point @ Cloud reproduction process of generating a display image from a PC file and reproducing a Point @ Cloud on a client side reproducing the content.
  • the information processing device 12 includes an extraction unit 31, a decoding unit 32, a 2D3D conversion unit 33, and a display processing unit.
  • the extraction unit 31 extracts a geometry video stream and a texture video stream corresponding to the reproduction time from the PC file based on the information signaled in the ISOBMFF Box, and supplies the extracted data to the decoding unit 32.
  • the decoding unit 32 decodes the geometry video stream and the texture video stream supplied from the extraction unit 31 and supplies the decoded data to the 2D3D conversion unit 33. At this time, the decoding unit 32 can perform the decoding of the geometry image and the decoding of the texture image in parallel by the two decoders 35-1 and 35-2.
  • the 2D3D conversion unit 33 constructs a Point Cloud based on the SEI information included in the geometry video stream.
  • the display processing unit 34 renders the Point Cloud constructed by the 2D3D conversion unit 33 according to the display device of the client, generates a display image, and displays the display image on a display device (not shown).
  • the information processing apparatus 12 configured as described above can reproduce Point @ Cloud from a PC file and display a display image in which Point @ Cloud is rendered.
  • FIG. 19 is a flowchart illustrating a PC file generation process in which the information processing apparatus 11 of FIG. 17 generates a PC file from Point Cloud.
  • step S11 the 3D2D conversion unit 21 converts the geometry image, the texture image, and the three-dimensional information metadata from the input Point @ Cloud. Generate.
  • step S12 the encoding unit 22 encodes the geometry ⁇ video ⁇ stream including the three-dimensional information metadata as the SEI from the geometry image and the three-dimensional information metadata generated by the 3D2D conversion unit 21 in step S11, and Encode texture video stream.
  • step S13 the PC stream generating unit 23 interleaves in units of a PC frame (PC sample) to generate a PC stream.
  • step S14 the file generation unit 24 stores the PC stream in the ISOBMFF that has signaled the Box including the three-dimensional information metadata, and generates a PC file.
  • the sample of ISOBMFF is PC sample.
  • FIG. 20 is a flowchart illustrating a Point @ Cloud playback process in which the information processing apparatus 12 of FIG. 18 generates and plays back a display image from a PC file.
  • the extraction unit 31 outputs the reproduction time from the PC file based on the information signaled in the Box of ISOBMFF. Extract the corresponding geometry video stream and texture video stream.
  • step S22 the decoding unit 32 individually decodes the geometry video stream and the texture video stream. At this time, the geometry video stream and the texture video stream are individually decoded by two decoder instances.
  • step S23 the 2D3D conversion unit 33 constructs a Point Cloud based on the SEI information included in the geometry video stream.
  • step S24 the display processing unit 34 renders Point @ Cloud to display a display image according to the display device of the client.
  • step S25 the extraction unit 31 determines whether or not the end of PC @ stream. If not, the process returns to step S21. If the end of PC @ stream, the process ends. .
  • PC file generation processing and Point Cloud playback processing can simplify processing on the client side.
  • FIG. 21 shows an example of the ISOBMFF structure when the PC $ stream is stored in the ISOBMFF structure by the first storage method.
  • the boundary of the Group @ of @ Frames is determined using the sample @ group, as in the case of the ISOBMFF signaling in the third storage method described later.
  • Signal in encoding of the elementary stream, layered coding such as SVC (Scalable Video Coding) or SEVVC (Scalable High Efficiency Video Coding) may be used instead of non-layered coding such as AVC and HEVC.
  • the layer 0 of the geometry video stream and the texture video stream is encoded as the base layer
  • the layer 1 of the geometry video stream and the texture video stream is encoded as the enhancement layer.
  • the enhancement track contains the geometry video stream and the texture video stream of the enhancement layer
  • the base track contains the base layer Geometry video stream and texture video stream are stored.
  • the link is made from the enhancement @ track to the base @ track by the track @ reference (reference type 'sbas').
  • the sample @ entry of the base @ track is PCSampleEntry ('pcbs')
  • the sample ⁇ entry of the enhancement @ track is PCEnhancementSampleEntry ('penh').
  • enhancement @ track exists according to the number of layers.
  • the layer identifier (eg, layer_id in FIG. 8) signaled by the header in the PC # sample is used.
  • the signal may be signaled at the sample @ entry of each track.
  • the header itself in the PC @ sample may be stored in the sample @ entry of each track.
  • a description will be given of a second storage method that is a method of packing a geometry / texture video stream into 1 stream and storing the stream in ISOBMFF 1 track.
  • the first storage method described above it is possible to realize a decoding process by one decoder by interleaving the texture image and the geometry image before encoding and encoding them as one video stream.
  • compression efficiency is deteriorated due to a small correlation between the texture image and the geometry image.
  • the generated single stream can be decoded by one decoder.
  • overhead is increased because the decoder needs to be initialized at the boundary between the encoded texture image and geometry image.
  • the texture video stream and the geometry video stream are individually encoded in the PC file generation process, and the geometry video video stream and the texture video stream are individually encoded by the two decoder instances in the Point Cloud playback process. Decoding needed. For this reason, if the first storage method is applied to decoding by one decoder instance, the compression efficiency will deteriorate and the overhead will increase.
  • a plurality of images are packed into one image by the method described in Patent Literature 1 described above or the like and encoded to form a PC stream.
  • images of multiple components can be packed into one image
  • images of multiple layers can be packed into one image
  • images of multiple layers of multiple components can be packed into one image.
  • a packing method not only a method such as side by side or top & bottom but also other methods may be adopted.
  • FIG. 23A shows an example in which the same layer is packed into one image with different components by the side by side method. That is, the texture image of layer 0 and the geometry image of layer 0 are packed into one image by side by side, and the texture image of layer 1 and the geometry image of layer 1 are packed into one image by side by side.
  • FIG. 23B shows an example in which images of the same component are packed into one image by different layers by the side-by-side method. That is, the texture image of layer # 0 and the texture image of layer # 1 are packed into one image by side @ side, and the geometry image of layer # 0 and the geometry image of layer # 1 are packed into one image by side @ by @ side.
  • the decoding process can be performed by one decoder instance, the correlation between the texture image and the geometry image is small as described above. It does not become. However, when the correlation of the images between the layers is high, it is possible to improve the coding efficiency by giving a reference relationship within the packed image.
  • the packing shown in FIG. 23B is an effective packing when the geometry video stream and the texture video stream are divided and stored in the track as in a fourth storage method described later.
  • FIG. 23C two images obtained by packing images of the same component into one image with different layers by the side by side method are packed into one image by the top & bottom method.
  • An example is shown in which images of all layers in all components are packed into one image. That is, the texture image of layer 0 and the texture image of layer 1 are packed into one image by side by side, and the geometry image of layer 0 and the geometry image of layer 1 are packed into one image by side by side. . Then, the two images are packed into one image by top & bottom, and the texture image of layer 0, the texture image of layer 1, the geometry image of layer 0, and the geometry image of layer 1 are combined into one image. Packed in.
  • one image obtained by packing a plurality of images is referred to as a packed PC image.
  • a coded sequence of packed @ PC images is called packed @ PC @ stream, and a packed @ PC @ stream stored in ISOBMFF is called packed @ PC file.
  • the packing method in the second storage method described here is different from the packing method of stereoscopic viewing using parallax in that packing is performed on images that are significantly different from each other, such as a geometry image and a texture image. Is a different technology.
  • FIG. 23A an example using a packed PC image in which images of the same layer are packed into one image with different components will be described.
  • FIG. 24 shows an example of signaling of the elementary stream.
  • FIG. 24 shows an example of PC sample when the number of layers is 2 and the video codec used for encoding is AVC or HEVC.
  • the first storage method is that one packed @ PC image that forms the packed @ PC stream obtained by packing the geometry image and the texture image into one image is 1 @ subsample (see FIG. 6 described above). And different.
  • the header signals geometry + texture as the type of the subsample in addition to the information defined in the first storage method.
  • point cloud frame packing SEI can be newly defined and signaled as SEI.
  • the SEI shown in FIG. 25 has information on a packing method of a geometry image and a texture image.
  • packing_arrangement when packing_arrangement is 0, it indicates that packing is side @ by @ side, and when packing_arrangement is 1, it indicates that packing is top @ & @ bottom. If packing_arrangement is other than that, it indicates that packing is reserved.
  • frame0_is_geometry when frame0_is_geometry is 0, it indicates that frame0 is a geometry, and when frame0_is_geometry is 1, it indicates that frame0 is texture.
  • frame0 is as shown in FIG.
  • packing is performed such that frame0 is on the left and frame1 is on the right, as shown in FIG. 27A.
  • packing is performed such that frame0 is on the upper side and frame1 is on the lower side, as shown in FIG. 27B.
  • the signal of this information is not limited to SEI, and may be signaled at other places, for example, may be signaled by PC header.
  • the packing method a method other than side by side and top ⁇ ⁇ ⁇ & bottom may be used.
  • the width and height of each component to be packed are set to a multiple of 2 pixels in consideration of the chrominance signal thinning.
  • encoding processing, component extraction processing, and the like can be easily performed.
  • the affinity with the block size at the time of encoding can be increased, and encoding processing and component extraction processing can be performed. It can be done easily.
  • the boundary of PC sample can be identified from the PC header, and the boundary of subsample can be identified by the header.
  • the texture image and the geometry image can be separated from the point ⁇ cloud ⁇ frame ⁇ packing ⁇ SEI.
  • the client can correctly configure Point @ Cloud and perform rendering.
  • FIG. 28 shows an example when a packed PC stream encoded from a packed PC image is stored in an ISOBMFF 1 track.
  • the modification described in the first storage method can be similarly applied.
  • the second storage method is operated as, for example, the restricted storage scheme in the first storage method, the sample entry is 'resv', and the scheme_type of the SchemeTypeBox is 'pacp'.
  • the PCPackingInfoBox used for the post-decoding process is signaled under rinf / schi as shown in FIG.
  • FIG. 30 is a block diagram illustrating a second configuration example of an information processing apparatus that executes a PC file generation process of generating a PC file from Point Cloud content on a server providing the content. Note that, in the information processing apparatus 11A shown in FIG. 30, the same reference numerals are given to configurations common to the information processing apparatus 11 in FIG. 17, and detailed description thereof will be omitted.
  • the information processing apparatus 11A includes a 3D2D conversion unit 21, an encoding unit 22A, a PC stream generation unit 23, a file generation unit 24, and a packing processing unit 26.
  • the information processing apparatus 11A is different from the information processing apparatus 11 in FIG. 17 in that the information processing apparatus 11A includes a packing processing unit 26 and the encoding unit 22A includes one encoder 25.
  • the packing processing unit 26 packs the texture image, the geometry image, and their respective layers by the packing method described above, and supplies the packed PC image to the encoding unit 22A.
  • the encoding unit 22A can encode the packed PC image with one encoder 25.
  • FIG. 31 is a block diagram illustrating a second configuration example of an information processing apparatus that executes a Point @ Cloud playback process of generating a display image from a packed @ PC file and playing a Point @ Cloud on the client side that plays back the content.
  • the same components as those of the information processing device 12 in FIG. 18 are denoted by the same reference numerals, and detailed description thereof is omitted.
  • the information processing apparatus 12A has a configuration different from the information processing apparatus 12 in FIG. 18 in that the decoding unit 32A has one decoder 35.
  • the extraction unit 31 extracts a packed ⁇ PC ⁇ stream corresponding to the playback time from the packed @ PC file based on the information signaled in the Box of ISOBMFF, and the decoding unit 32A At 35, the packed ⁇ PC ⁇ stream can be decoded.
  • FIG. 32 is a flowchart illustrating a packed PC file generation process in which the information processing apparatus 11A in FIG. 30 generates a packed PC stream from the Point Cloud and generates a packed PC file in which the packed PC stream is stored in ISOBMFF.
  • step S31 the 3D2D conversion unit 21 converts the geometry image, the texture image, and the three-dimensional information metadata from the input Point @ Cloud. Generate.
  • step S32 the packing processing unit 26 generates a packed PC image by packing the texture image and the geometry image, and their respective layers.
  • step S33 the encoding unit 22A encodes the packed PC image generated by the 3D2D conversion unit 21 in step S32.
  • step S34 the PC stream generation unit 23 interleaves the units of the packed PC stream to generate a packed PC stream that includes three-dimensional information metadata and packing information as SEI.
  • step S35 the file generating unit 24 stores the packed PC stream in the ISOBMFF that has signaled the Box containing the three-dimensional information metadata, and generates a packed PC file.
  • the sample of ISOBMFF is PC sample.
  • FIG. 33 is a flowchart illustrating a Point @ Cloud playback process in which the information processing apparatus 12A of FIG. 31 generates and plays a display image from a packed @ PC file.
  • step S41 the extraction unit 31 determines the playback time from the packed @ PC file based on the information signaled in the Box of ISOBMFF. Extract the packed PC stream corresponding to.
  • step S42 the decoding unit 32A decodes the packed ⁇ PC ⁇ stream. At this time, packed ⁇ PC ⁇ stream is decoded by one decoder instance.
  • step S43 the 2D3D conversion unit 33 constructs a Point Cloud based on the packing information and the SEI information included in the packed PC stream.
  • step S44 the display processing unit 34 renders Point @ Cloud to display a display image according to the display device of the client.
  • step S45 the extraction unit 31 determines whether or not the end of PC @ stream. If not, the process returns to step S41. If the end of PC @ stream, the process ends. .
  • FIG. 34 shows an example of the ISOBMFF structure when the packed ⁇ PC ⁇ stream is stored in the ISOBMFF structure by the second storage method.
  • the client can identify the boundary of the PC sample and the boundary of the subsample of each component without parsing the contents of the subsample. Then, the client can acquire information necessary for separating the texture image and the geometry image from the PCPackingInfoBox. Therefore, the client extracts the packed PC stream from the PC sample and performs the decoding process by a simplified process of referring to only the signaling of the system layer. After that, the client can separate the geometry image and the texture image from the packed @ PC image, configure the Point @ Cloud, and execute the rendering.
  • the packing shown in FIG. 23B and the packing shown in FIG. 23C also have a point ⁇ cloud ⁇ frame ⁇ packing ⁇ SEI (FIG. 25) and a PCPackingInfoBox ( According to FIG. 29), the packing method can be signaled. This allows the client to separate each layer of the texture image and the geometry image.
  • the point cloud frame packing ⁇ ⁇ ⁇ SEI and PCPackingInfoBox for example, the arrangement, the position, the size, and the like of each component and each layer in the picture are signaled, so that the packing can be freely performed.
  • FIG. 35 shows a modification of the PCPackingInfoBox.
  • the PCPackingInfoBox for example, information (component_num) indicating the number of components constituting the packed @ PC image, information (layer_num) indicating the number of layers constituting the packed @ PC image, and the type of the component are indicated.
  • Information (component_type) is described. For example, when the component_type is 0, the type of the component is a geometry image, and when the component_type is 1, the type of the component is a texture image.
  • the PCPackingInfoBox includes a layer identifier (layer_id), information (left / top) indicating a position where an image indicated by component_type and layer_id is arranged in a packed @ PC image, and information (width / width) indicating their size. height) is described.
  • an occupancy map may be treated as a component.
  • the occupancy map can be packed together with the geometry image and the texture image.
  • a third storage method which is a method of storing a PC stream in one track of ISOBMFF without defining a PC sample.
  • the third storage method is different from the first storage method and the second storage method in that the texture subsample and the geometry subsample are stored as ISOBMFF samples without using the concept of the PC sample as described above. This is a modified example.
  • the signaling of elementary @ stream in the third storage method has the same structure as elementary @ stream (see FIG. 6) in the first storage method and elementary @ stream (see FIG. 24) in the second storage method.
  • samples in 1SOBMFF are defined as geometry @ subsample and texture @ subsample.
  • the geometry subsample defined as sample in 1SOBMFF is referred to as geometry subsample
  • the texture subsample defined as sample in 1SOBMFF is referred to as texture subsample.
  • FIG. 36 shows the same structure as elementary @ stream in the first storage method as an example of signaling of elementary @ stream in the third storage method.
  • FIG. 37 shows an example of ISOBMFF signaling.
  • the boundary of Group of Frames (GOFEntry), the boundary of PC frame (PCFrameEntry), the boundary of texture samples, the boundary of geometry samples, and the boundary of texture & geometry samples (ComponentGroupEntry) can be signaled.
  • the Sample @ Group will be described with reference to the outline of Sample @ Group shown in FIG. 55 described later.
  • each sample is linked to each SampleGroupEntry signaled by SampleGroupDescriptionBox ('sgpd') through SampleToGroupBox ('sbgp').
  • the sgpd may be signaled to the SampleTableBox # ('stbl') in the MovieBox # ('moov').
  • FIGS. 38 to 40 show the newly defined GroupEntry.
  • the size_of_pc_frame field in PCFrameEntry indicates the size of PC @ frame.
  • the number_of_component field indicates the number of components constituting the PC @ frame. Specifically, when the field is composed of a geometry image and a texture image, the number is 2.
  • the type field in the ComponentGroupEntry indicates the type of the component of the sample belonging to this sample ⁇ group. Specifically, if the type field is 0, it indicates that the type of the component is a geometry image, and if the type field is 1, it indicates that the type of the component is a texture image. When the type field is 2, it indicates that the type of the component is geometry & texture (second storage method).
  • a value indicating the type of each component may be added to the type field.
  • NumberThe number_of_layer field in the ComponentGroupEntry indicates the number of layers of the component.
  • GeometryGroupEntry instead of ComponentGroupEntry, GeometryGroupEntry and TextureGroupEntry may be defined.
  • the boundary of geometry @ samples can be signaled by GeometryGroupEntry, and the boundary of texture @ samples can be signaled by TextureGroupEntry.
  • 3D information metadata such as occupancy map and auxiliary patch info are not signaled as SEI, but as a type of component and signaled as samples, even if a GroupEntry that signals the boundary of each sample is defined, Good. Then, the boundary of each sample may be indicated by GroupEntry.
  • PCPackingInfoBox is signaled to sample @ entry.
  • the stream stored in ISOBMFF can conform to AVC, HEVC, SVC, SHEVC, etc., and in that case, it can be operated as a restricted scheme of these codecs. For example, sample @ entry becomes 'resv', scheme_type of SchemeTypeBox becomes 'pcbs', and data_format of OriginalFormatBox becomes avc1, hev1, etc. depending on the codec used.
  • a 120p video stream is equivalent to a 30p PC stream.
  • the client can identify 4 samples, which is the interleave cycle of samples, from the value of (num_layer_composed ⁇ num_of_component of LayerCompositionBox).
  • the client can identify the boundary of Group of frames, the boundary of PC sample, and the boundary of sample of each component through the information of sample group without parsing the contents of sample. That is, the client can acquire information necessary for separating the texture image and the geometry image from the PCPackingInfoBox.
  • the client extracts the geometry video stream and the texture video stream and executes the decoding process by a simplified process of referring only to the signaling of the system layer. Thereafter, the client can separate the geometry image and the texture image, configure Point Cloud, and execute the rendering.
  • step S14 in FIG. 19 when packing is not applied as in the first storage method, the generation processing and the reproduction processing are performed in the same manner as described above with reference to the flowcharts of FIGS. 19 and 20, respectively.
  • step S14 in FIG. 19 when PC @ stream is stored in the ISOBMFF that has signaled the Box including the three-dimensional information metadata, the sample of the ISOBMFF is a sample of each component.
  • step S22 in FIG. 20 the geometry @ video @ stream and the texture @ video @ stream are individually decoded by two decoder instances.
  • step S35 of FIG. 32 when the packed @ PC @ stream is stored in the ISOBMFF that has signaled the Box including the three-dimensional information metadata, the sample of the ISOBMFF is 1 @ picture of the packed @ PC @ stream.
  • step S42 in FIG. 33 packed ⁇ PC ⁇ stream is decoded by one decoder instance.
  • FIG. 42 shows an example of the ISOBMFF structure when PC stream is stored in the ISOBMFF structure by the third storage method.
  • three-dimensional information metadata in a PC frame is signaled using SEI.
  • three-dimensional information metadata may be signaled by using sample auxiliary information specified by ISOBMFF.
  • sampleAuxiliaryInformationOffsetBox ⁇ That is, as shown in FIG. 43, the position of sample @ auxiliary @ infromation is signaled in the offset field of SampleAuxiliaryInformationOffsetBox @ ('saio').
  • sample_info_size field of SampleAuxiliaryInformationSizeBox 'saiz'
  • SEI is an element used in an encoding codec such as AVC or HEVC, so that when SEI is used, signaling depends on the codec.
  • encoding codec such as AVC or HEVC
  • sample ⁇ auxiliary ⁇ information when sample ⁇ auxiliary ⁇ information is used, three-dimensional information metadata can be signaled without depending on the encoding codec.
  • ⁇ Fourth storage method> With reference to FIGS. 44 to 53, a fourth storage method that is a method of dividing a PC stream into a geometry video stream and a texture video stream and storing the PC stream in two tracks of ISOBMFF will be described.
  • FIG. 44 shows an example of ISOBMFF signaling in the fourth storage method.
  • the PC stream is separated into a geometry video stream and a texture video stream, and each is stored in the 1 track of ISOBMFF.
  • the track that stores the geometry video stream is referred to as the geometry track (or main track)
  • the track that stores the texture video stream is referred to as the texture track (or the secondary track).
  • auxiliary patch information and occupancy map are stored in the geometry track.
  • a signal of Group @ of @ Frames and sample @ group indicating the boundary of PC @ frame may be signaled.
  • a configuration may be adopted in which 1 layer is stored in 1 track of ISOBMFF.
  • the layer identifier eg, layer_id in FIG. 8
  • the signal may be signaled at the sample @ entry of each track.
  • the header itself in the PC @ sample may be stored in the sample @ entry of each track.
  • the stream stored in ISOBMFF can be based on AVC, HEVC, SVC, SHEVC, and the like, and in that case, it can be operated as a restricted scheme of these codecs. For example, sample @ entry becomes 'resv', scheme_type of SchemeTypeBox becomes 'pcbs', and data_format of OriginalFormatBox becomes avc1, hev1, etc. depending on the codec used.
  • these newly defined boxes are positioned to be used for post-decoding processing, and are signaled under rinf / schi shown in FIG. Further, the PCHeaderBox and the LayerCompositionBox described in the first storage method are also signaled to the rinf / schi as illustrated.
  • the three-dimensional metadata may be stored in the 1 track of ISOBMFF.
  • the same Box and information as those in the geometry @ track and the texture @ track may be signaled to the sample entry of the track storing the three-dimensional metadata.
  • each 60p video stream is equivalent to a 30p PC stream.
  • the client can identify the interleave cycle of sample from the value of (num_layer_composed ⁇ num_of_component of LayerCompositionBox).
  • the method in the fourth storage method is applicable not only to the third storage method described above but also to the packing configuration of different layers of the same component in the first storage method and the second storage method. It is possible.
  • the second storage method as described with reference to FIG. 23B, in the method of packing images of the same component into one image by different layers, the geometry video stream and the texture video stream By dividing and storing in the track, it is possible to prevent the compression efficiency from deteriorating due to a small correlation between the texture image and the geometry image.
  • a configuration may be such that a plurality of texturetexttracks having different bitrates are linked to one geometry track.
  • FIG. 45 shows an example of the syntax of PCMultiStreamBox.
  • isGeometryStream 1, it indicates that it is geometry @ track; otherwise, it indicates that it is texture @ track.
  • the track_id of the associated texture @ track is signaled.
  • the client can identify which track is the geometry track only by parsing the TrackReferenceBox of an arbitrary 1 track by indicating the track reference. Thereafter, the client can parse the PCMultiStreamBox of the geometry @ track and identify all relevant texture @ tracks. In other words, the client can identify the entire configuration only by parsing the 2 @ track at the maximum, and can simplify the processing particularly in the case where a plurality of texture @ tracks are linked.
  • texture @ tracks having different bitrates may be collectively signaled by the track @ group, and as shown in FIG. 46, may be associated with the texture @ track @ group by the texture_track_group_id.
  • track group newly defines PCTextureTrackGroupBox, and rack_group_type is 'pctg'.
  • texture_track_id may be linked to the track_group_id of the PCTextureTrackGroup.
  • an isInGeometryStream indicating whether or not the texture is stored in the same track as the geometry may be added to the PCMultiStreamBox.
  • a geometrygetrack and a texture track linked by a track group may be signaled as shown in FIG.
  • track @ group newly defines a PCStreamGroupBox, and the rack_group_type is 'pcgp'.
  • FIG. 51 shows an example of the ISOBMFF structure when PC stream is stored in the ISOBMFF structure by the fourth storage method.
  • the texture image and the geometry image and the three-dimensional information metadata are signaled by the DASH MPD.
  • the client when the client acquires the DASH distribution content, the client can refer to the PC Component Descriptor and appropriately acquire the geometry video stream and the texture video stream that constitute the PC stream. Also, appropriate switching of the texture video stream according to the network bandwidth becomes possible.
  • association from geometry representation to texture representation may be performed using Representation @ associationId.
  • associationType is “ptex”. Since geometry alone can provide a colorless point-cloud presentation, association using associationId is appropriate.
  • texture subsample and geometry subsample other than layer 0 or texturetextsample and geometry subsample other than layer 0 are all used as subsamples of layer 0 or SEI of sample. It may be stored.
  • FIG. 54 shows an outline of the SubSampleInformationBox.
  • a continuous specific byte area in the sample is defined as a sub-sample.
  • the definition of sub-sample is determined for each encoding codec. For example, in the case of HEVC, NAL @ unit is the sub-sample.
  • NAL @ unit is the sub-sample.
  • Information can be added for each sub-sample.
  • FIG. 55 shows an outline of Sample @ Group.
  • the grouping_type of the Sample To Group Box indicates the grouping_type of the associated Sample Group Description Box. For each entry, sample_count and group_description_index are signaled. Then, group_description_index indicates the index of the associated Group @ Entry, and sample_count indicates the number of samples belonging to the Group @ Entry.
  • FIG. 56 is a block diagram showing a configuration example of the data generation device.
  • the data generating device 51 includes a control unit 61 and a file generating unit 62.
  • the file generating unit 62 includes a data input unit 71, a data encoding / generating unit 72, and an MPD (Media Presentation Present Description). ) It comprises a file generation unit 73, a recording unit 74, and an upload unit 75.
  • the data encoding / generating section 72 has a preprocessing section 76, an encoding section 77, and a segment file generating section 78.
  • the preprocessing unit 76 corresponds to the above-described 3D2D conversion unit 21 (FIG. 17 or FIG. 30) and executes a process of generating a geometry image, a texture image, and three-dimensional information metadata from an input Point @ Cloud. I do.
  • ⁇ Encoding section 77 corresponds to the above-described encoding section 22 (FIG. 17), and executes a process of encoding a geometry video stream and a texture video stream.
  • the encoding unit 77 executes a process of encoding a packed @ PC image corresponding to the above-described encoding unit 22A (FIG. 30).
  • the segment file generation unit 78 generates a PC @ stream corresponding to the above-described PC @ stream generation unit 23 and the file generation unit 24 (FIG. 17 or FIG. 30), and generates a PC file in which the PC @ stream is stored in ISOBMFF. Execute the processing to be performed.
  • FIG. 57 is a block diagram showing a configuration example of a data reproducing apparatus.
  • the data playback device 52 includes a control unit 81 and a playback processing unit 82.
  • the playback processing unit 82 includes an MPD file acquisition unit 91, an MPD file processing unit 92, a segment file acquisition unit 93, It comprises a display control unit 94, a data analysis / decoding unit 95, and a display unit 96.
  • the data analysis / decryption unit 95 has a segment file processing unit 97, a decryption unit 98, and a display information generation unit 99.
  • the segment file processing unit 97 corresponds to the above-described extraction unit 31 (FIG. 18) and executes a process of extracting a geometry video stream and a texture video stream corresponding to the reproduction time.
  • the segment file processing section 97 corresponds to the above-described extraction section 31 (FIG. 31), and executes a process of extracting packed ⁇ PC ⁇ stream corresponding to the reproduction time.
  • ⁇ Decoding section 98 corresponds to the above-described decoding section 32 (FIG. 18), and executes a process of individually decoding the geometry video stream and the texture video stream.
  • the decoding unit 98 performs a process of decoding packed ⁇ PC ⁇ stream, corresponding to the above-described decoding unit 32A (FIG. 31).
  • the display information generation unit 99 corresponds to the 2D3D conversion unit 33 and the display processing unit 34 (FIG. 18 or FIG. 31), constructs Point @ Cloud, renders Point @ Cloud, and displays a display image.
  • a PC stream structure suitable for storing ISOBMFF can be defined, and the PC stream can be stored in the 1 track of ISOBMFF. This makes it possible to execute the decoding process of the PC stream by a simplified process of referring only to the signaling of the system layer at the time of reproduction by the client, and suppress occurrence of random access in the stream at the time of normal reproduction. it can.
  • the execution of the decoding process of the PC stream can be performed in a simplified manner. Can be made possible.
  • the geometry video stream and the texture video stream of the PC stream can be packed into 1 stream and stored in the 1 track of ISOBMFF. Thereby, at the time of reproduction by the client, it is possible to execute the decoding process of the PC stream in the 1 decoder instance.
  • the PC stream can be divided into a geometry video stream and a texture video stream and stored in 2 tracks of ISOBMFF. As a result, it is possible to efficiently link the track storing the geometry video stream with the track storing the texture video stream. Therefore, it is possible to easily perform the stream acquisition processing in the client for optimizing the PC stream image quality according to the network band.
  • FIG. 58 is a block diagram illustrating a configuration example of an embodiment of a computer in which a program for executing the above-described series of processes is installed.
  • the program can be recorded in advance on the hard disk 105 or the ROM 103 as a recording medium built in the computer.
  • the program can be stored (recorded) in the removable recording medium 111 driven by the drive 109.
  • a removable recording medium 111 can be provided as so-called package software.
  • examples of the removable recording medium 111 include a flexible disk, a CD-ROM (Compact Disc Only Memory), an MO (Magneto Optical) disc, a DVD (Digital Versatile Disc), a magnetic disc, and a semiconductor memory.
  • the program may be installed in the computer from the removable recording medium 111 as described above, or may be downloaded to the computer via a communication network or a broadcast network and installed in the built-in hard disk 105. That is, for example, the program is wirelessly transferred from a download site to a computer via an artificial satellite for digital satellite broadcasting, or is transmitted to a computer via a network such as a LAN (Local Area Network) or the Internet by wire. be able to.
  • LAN Local Area Network
  • the computer has a built-in CPU (Central Processing Unit) 102, and an input / output interface 110 is connected to the CPU 102 via a bus 101.
  • CPU Central Processing Unit
  • the CPU 102 executes a program stored in a ROM (Read Only Memory) 103 according to a command input by a user operating the input unit 107 via the input / output interface 110 according to the command. .
  • the CPU 102 loads a program stored in the hard disk 105 into a RAM (Random Access Memory) 104 and executes the program.
  • the CPU 102 performs the processing according to the above-described flowchart or the processing performed by the configuration of the above-described block diagram. Then, the CPU 102 causes the processing result to be output from the output unit 106 or transmitted from the communication unit 108 via the input / output interface 110 as needed, and further recorded on the hard disk 105, for example.
  • the input unit 107 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 106 includes an LCD (Liquid Crystal Display), a speaker, and the like.
  • the processing performed by the computer according to the program does not necessarily have to be performed in chronological order according to the order described in the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or individually (for example, parallel processing or processing by an object).
  • the program may be processed by a single computer (processor) or may be processed in a distributed manner by a plurality of computers. Further, the program may be transferred to a remote computer and executed.
  • a system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all components are in the same housing. Therefore, a plurality of devices housed in separate housings and connected via a network, and one device housing a plurality of modules in one housing are all systems. .
  • the configuration described as one device (or processing unit) may be divided and configured as a plurality of devices (or processing units).
  • the configuration described above as a plurality of devices (or processing units) may be configured as one device (or processing unit).
  • a configuration other than those described above may be added to the configuration of each device (or each processing unit).
  • a part of the configuration of a certain device (or processing unit) may be included in the configuration of another device (or other processing unit).
  • the present technology can adopt a configuration of cloud computing in which one function is shared by a plurality of devices via a network and processed jointly.
  • the above-described program can be executed in any device.
  • the device only has to have necessary functions (functional blocks and the like) and be able to obtain necessary information.
  • each step described in the above-described flowchart can be executed by a single device, or can be shared and executed by a plurality of devices. Further, when a plurality of processes are included in one step, the plurality of processes included in the one step can be executed by one device, or can be shared and executed by a plurality of devices. In other words, a plurality of processes included in one step may be executed as a plurality of steps. Conversely, the processing described as a plurality of steps may be collectively executed as one step.
  • the program executed by the computer may be configured so that the processing of the steps for describing the program is executed in chronological order according to the order described in the present specification, or the program may be executed in parallel or called. It may be executed individually at a necessary timing such as time. That is, as long as no inconsistency arises, the processing of each step may be performed in an order different from the order described above. Further, the processing of the steps for describing this program may be executed in parallel with the processing of another program, or may be executed in combination with the processing of another program.
  • the present technology may also have the following configurations.
  • (1) By converting the 3D data representing the three-dimensional structure into two dimensions, at least a first image and a second image, and a three-dimensional image necessary to construct the first image and the second image in three dimensions.
  • One-dimensional files constituting the 3D data, which are obtained at a specific time, are obtained based on the three-dimensional information metadata and the first image and the second image are obtained based on the three-dimensional information metadata.
  • An information processing apparatus comprising: a file generation unit configured to store and generate the first image, the second image, and the three-dimensional information metadata in accordance with a reproduction order necessary for reproduction and reproduction.
  • An encoding unit that encodes the first image and the second image to generate a first image stream and a second image stream; After the first image stream and the second image stream are respectively decoded, the file generation unit may convert the first image and the second image into a three-dimensional structure based on the three-dimensional information metadata. Generating the file by storing the first image, the second image, and the three-dimensional information metadata in accordance with a decoding order necessary to be reconstructed as the information processing according to (1). apparatus. (3) The information processing device according to (2), wherein the encoding unit encodes the first image and the second image using non-layered coding. (4) The information processing device according to any one of (1) to (3), wherein the three-dimensional information metadata includes information indicating the first image and the second image.
  • the information processing apparatus includes information indicating Group of Frames.
  • the three-dimensional information metadata includes information indicating the number of layers and the number of components to be displayed at the same time.
  • the three-dimensional information metadata includes codec information for each component of the three-dimensional structure of the 3D data.
  • the encoding unit encodes the first image and the second image by layered coding.
  • a packing processing unit for packing a plurality of images into one packing image The information processing according to any one of (1) to (8), wherein the file generation unit stores the packing image, the three-dimensional information metadata, and packing information indicating a packing method in the file. apparatus.
  • the packing processing unit packs all layers of the first image and the second image.
  • the file generation unit stores the stream including at least the first image and the second image and the three-dimensional information metadata as one sample of an ISO Base Media File Format (ISOBMFF), thereby storing the file.
  • ISOBMFF ISO Base Media File Format
  • the information processing apparatus according to any one of the above (1) to (12).
  • Either the first image or the second image includes the three-dimensional information metadata, and each of the first image and the second image is stored as the one sample.
  • the file generating unit generates the file by storing a stream including at least the first image, the second image, and the three-dimensional information metadata in different tracks.
  • the information processing apparatus according to any one of the above.
  • the information processing device wherein the three-dimensional information metadata includes information indicating a relationship between the tracks.
  • the information processing apparatus according to any one of (1) to (16), wherein the first image, the second image, and the three-dimensional information metadata are signaled by ISOBMFF.
  • the first image, the second image, and the three-dimensional information metadata are signaled by MPD (Media Presentation Description) of DASH (Dynamic Adaptive Streaming over HTTP).
  • An information processing device according to any one of the above.
  • the information processing device is By converting the 3D data representing the three-dimensional structure into two dimensions, at least a first image and a second image, and a three-dimensional image necessary to construct the first image and the second image in three dimensions.
  • One-dimensional files constituting the 3D data which are obtained at a specific time, are obtained based on the three-dimensional information metadata and the first image and the second image are obtained based on the three-dimensional information metadata. And storing and generating the first image, the second image, and the three-dimensional information metadata in accordance with a reproduction order necessary for reproduction and reproduction. (20) In the computer of the information processing device, By converting the 3D data representing the three-dimensional structure into two dimensions, at least a first image and a second image, and a three-dimensional image necessary to construct the first image and the second image in three dimensions.
  • One-dimensional files constituting the 3D data which are obtained at a specific time, are obtained based on the three-dimensional information metadata and the first image and the second image are obtained based on the three-dimensional information metadata.
  • 11 and 12 information processing device ⁇ 21 ⁇ 3D2D conversion unit, ⁇ 22 ⁇ encoding unit, ⁇ 23 ⁇ PC stream generation unit, ⁇ 24 ⁇ file generation unit, ⁇ 31 ⁇ extraction unit, ⁇ 32 ⁇ decoding unit, ⁇ 33 ⁇ 2D3D conversion unit, ⁇ 34 ⁇ display processing unit, ⁇ 51 ⁇ data generation device , ⁇ 52 ⁇ data reproduction device, ⁇ 61 ⁇ control unit, ⁇ 62 ⁇ file generation unit, ⁇ 71 ⁇ data input unit, ⁇ 72 ⁇ data encoding / generation unit, ⁇ 73 ⁇ MPD file generation unit, ⁇ 74 ⁇ recording unit, ⁇ 75 ⁇ upload unit, ⁇ 76 ⁇ preprocessing unit, ⁇ 77 ⁇ encoding Unit, ⁇ 78 ⁇ segment file generation unit, ⁇ 81 ⁇ control unit, ⁇ 82 ⁇ reproduction processing unit, ⁇ 91 ⁇ MPD file acquisition unit, ⁇ 92 ⁇ MPD file processing unit, ⁇ 93 ⁇ segment file acquisition unit, ⁇ 94 ⁇ display control unit, ⁇ 95 ⁇ data analysis / decoding unit, ⁇ 96 ⁇ display unit ,

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本開示は、処理を簡潔に行うことができるようにする情報処理装置および情報処理方法、並びにプログラムに関する。 ３次元構造を表すPoint Cloudを２次元に変換することによってgeometry画像およびtexture画像と、geometry画像およびtexture画像を３次元に構築するのに必要な３次元情報メタデータとが得られる。そして、特定時刻に表示されるPoint Cloudを構成する1 PC sampleが、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを格納して生成される。Point Cloudを配信するためのデータを生成するデータ生成装置に適用できる。

Description

情報処理装置および情報処理方法、並びにプログラム
　本開示は、情報処理装置および情報処理方法、並びにプログラムに関し、特に、処理を簡潔に行うことができるようにした情報処理装置および情報処理方法、並びにプログラムに関する。
　従来、非特許文献１で開示されているように、３次元空間上に位置情報および属性情報（特に色情報）を同時に持った点の集合であるPoint Cloudの圧縮方法が規定されている。
　また、非特許文献２には、Point Cloudの圧縮方法の一つとして、Point Cloudを複数の領域に分割（以下、セグメンテーションと称する）し、領域毎に平面投影してtexture画像およびgeometry画像を生成した後、それらを動画コーデックにより符号化する方法が開示されている。ここで、geometry画像は、Point Cloudを構成する点群のdepth情報から構成される画像である。
　このようなPoint Cloudの圧縮方法は、PCC TMC2（Point Cloud Coding Test Model Category 2）と呼ばれている。また、PCC TMC2によって生成されたPoint Cloudのstream（以下、PC streamとも称する）の構造は、非特許文献３に開示されている。
　そして、このようなPC streamを、over IP networkで配信するユースケースが期待されている。そこで、非特許文献４で開示されているように、既存の配信プラットフォームへのインパクトを抑制し、早期のサービス実現を目指すべく、MPEG（Moving Picture Experts Group）において、既存の枠組みであるISOBMFF/DASH（ISO Base Media File Format / Dynamic Adaptive St reaming over HTTP）による配信技術についての検討が開始された。
　また、特許文献１では、３次元画像データを、サイドバイサイド方式やトップアンドボトム方式などでパッキングして記録する画像処理装置が開示されている。
特開２０１１－１４２５８６号公報
MPEG-I Part5 Point Cloud Compression (ISO/IEC 23090-5) w17348, PCC Test Model Category 2 v1, January 2018, Gwangju, Korea w17374, First Working Draft for PCC Category 2, January 2018, Gwangju, Korea w17675, First idea on Systems technologies for Point Cloud Coding, April 2018, San Diego, US
　ところで、上述の非特許文献３で開示されているようなPC streamの構造では、通常再生時にランダムアクセスが多量に発生することになり、Point Cloudを再生するクライアント側における処理が複雑なものとなるため、処理が遅延したり、処理コストが増大したりすることが懸念される。
　本開示は、このような状況に鑑みてなされたものであり、処理を簡潔に行うことができるようにするものである。
　本開示の一側面の情報処理装置は、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部を備える。
　本開示の一側面の情報処理方法またはプログラムは、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成することを含む。
　本開示の一側面においては、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、第１の画像および第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される３Ｄデータを構成する１単位のファイルが、第１の画像および第２の画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、第１の画像および第２の画像と３次元情報メタデータとを格納して生成される。
　本開示の一側面によれば、処理を簡潔に行うことができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
Point Cloudの圧縮方法を説明する図である。 PC streamの構造を示す図である。 GOFの構造を示す図である。 geometry video streamおよびtexture video streamの構造を示す図である。 新たに定義するPC sampleの構造を示す図である。 PC sampleの一例を示す図である。 PC headerに格納される情報の一例を示す図である。 headerに格納される情報の一例を示す図である。 GOF headerに格納される情報の一例を示す図である。 PC streamをISOBMFFの1 trackに格納する際の一例を示す図である。 codec_specific_parametersの定義を示す図である。 PCSampleEntryの構造を示す図である。 PCHeaderBoxの一例を示す図である。 SubSampleEntryBoxの一例を示す図である。 LayerCompositionBoxの一例を示す図である。 num_layer_composed=2かつnum_of_component=2のPC sampleの一例を示す図である。 PCファイル生成処理を実行する情報処理装置の第１の構成例を示すブロック図である。 Point Cloud再生処理を実行する情報処理装置の第１の構成例を示すブロック図である。 PCファイル生成処理の第１の処理例を説明するフローチャートである。 Point Cloud再生処理の第１の処理例を説明するフローチャートである。 第１の格納方法におけるISOBMFF構造の一例を示す図である。 enhancement trackからbase trackへ、track referenceによる紐づけについて説明する図である。 パッキングのバリエーションを示す図である。 elementary streamのシグナリングの一例を示す図である。 新たに定義するSEIの一例を示す図である。 packing_arrangementおよびframe0_is_geometryの定義を説明する図である。 frame0の定義を示す図である。 PC streamをISOBMFFの1 trackに格納する際の一例を示す図である。 PCPackingInfoBoxの一例を示す図である。 packed PCファイル生成処理を実行する情報処理装置の第２の構成例を示すブロック図である。 Point Cloud再生処理を実行する情報処理装置の第２の構成例を示すブロック図である。 packed PCファイル生成処理の第２の処理例を説明するフローチャートである。 Point Cloud再生処理の第２の処理例を説明するフローチャートである。 PCPackingInfoBoxの変形例を示す図である。 第２の格納方法におけるISOBMFF構造の一例を示す図である。 elementary streamのシグナリングの一例を示す図である。 ISOBMFFのシグナリングの一例を示す図である。 GOFEntry()の定義を示す図である。 PCFrameEntry()の定義を示す図である。 ComponentGroupEntry()の定義を示す図である。 sampleのインターリーブ周期の識別について説明する図である。 第３の格納方法におけるISOBMFF構造の一例を示す図である。 SEIを用いずにシグナルする例について説明する図である。 ISOBMFFのシグナリングの一例を示す図である。 PCMultiStreamBoxのシンタックスの一例を示す図である。 PCMultiStreamBoxの変形例を示す図である。 PCTextureTrackGroupのシンタックスの一例を示す図である。 PCMultiStreamBoxの変形例を示す図である。 track groupで紐づくgeometry trackとtexture trackをシグナルする例を示す図である。 新たに定義されるPCStreamGroupBoxの一例を示す図である。 第４の格納方法におけるISOBMFF構造の一例を示す図である。 DASHのシグナリングについて説明する図である。 DASHのシグナリングについて説明する図である。 SubSampleInformationBoxの概要を示す図である。 Sample Groupの概要を示す図である。 データ生成装置の構成例を示すブロック図である。 データ再生装置の構成例を示すブロック図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
　以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
　＜従来の符号化方法＞
　本技術を適用した符号化方法について説明する前に、図１乃至図４を参照して、従来の符号化方法について説明する。
　図１は、上述した非特許文献２で開示されているPoint Cloudの圧縮方法を、簡略的に説明するための図である。
　図１に示すように、まず、３次元構造を表すPoint Cloudが入力され、そのPoint Cloudがセグメンテーションされる。図１に示す例では、半球形状と円錐形状とが組み合わされた３次元構造を表すPoint Cloudが入力され、半球形状を１領域に、円錐形状を２領域に分割した３つの領域にセグメンテーションが行われる。次に、領域ごとに平面投影が行われ、それぞれの領域の表面の見た目を表す色情報からなるtexture画像、および、それぞれの領域の表面までの奥行（depth）を表す位置情報からなるgeometry画像が生成される。そして、texture画像およびgeometry画像が、例えば、AVC（Advanced Video Coding）やHEVC（High Efficiency Video Coding）などの動画像コーデックで符号化される。
　図２は、PC streamの構造を示す図である。
　図２に示すように、PC streamは1 streamで構成されており、Group of Frames（GOF）という単位において、特定の時間幅で連続的に表示される複数のPoint Cloud frameの構成要素がまとめられている。ここで、Point Cloud frame（以下、PC frameとも称する）は、同時刻に表示されるPoint Cloudのことである。
　そして、GOFは、texture画像が符号化されたtexture video stream、geometry画像が符号化されたgeometry video stream、および、2D3D変換に用いる３次元情報メタデータ（auxiliary patch infoおよびoccupancy map）から構成される。ここで、geometry video streamおよびtexture video streamは、（PC streamのframe rate）×（GOF時間幅）×N個（layerの数）の複数のframeを持つ。そして、PC streamの1 frameにつき、geometry video streamおよびtexture video streamは、それぞれN個のframeを持つという特徴がある。これは、Point Cloudの厚み方向の層構造を表現するためである。つまり、それぞれN個のframeから、PC frameが構成されることを意味する。
　例えば、クライアントは、PC stream内のgeometry video streamおよびtexture video streamをデコードし、occupancy mapを用いてgeometryパッチとtextureパッチを生成する。その後、クライアントは、auxiliary patch infoを用いて、まずはgeometryパッチから色のないPoint Cloudを生成し、続いて、そのPoint Cloud に対してtextureパッチにより色を付ける。
　図３には、従来のPC streamにおけるGOFの構造が示されており、layer数が２である例が示されている。
　図３に示すように、従来、特定の時間幅の中で表示されるPC frameがストリーム内で連続配置されない構造となっている。つまり、従来のPC streamでは、PC frame#1の再生に必要な要素と、PC frame#2の再生に必要な要素とが、互いに前後になるように配置される構造となっている。このため、例えば、PC frame#1の再生に必要な要素であるgeometry frame#1 layer0，geometry frame#1 layer1，auxiliary patch info & occupancy map#1，texture frame#1 layer0，texture frame#1 layer1にアクセスし、その後、PC frame#2の再生に必要な要素にアクセスする場合、texture frame#1 layer1より前方の位置に配置されているgeometry frame#2 layer0からアクセスを開始するような処理が発生してしまう。従って、上述したように、通常再生時にランダムアクセスが多量に発生してしまう。
　この点で、図３に示すPC stream構造は、既存のビデオコーデックのストリーム構成とも異なっており、ISOBMFFへの格納およびover IP（Internet Protocol）での配信に適していない。
　例えば、上述した非特許文献４では、geometry video streamとtexture video streamとを、streamごとに独立したものとして取り扱い、個別のtrackに格納する手法が開示されている。しかしながら、この手法においても、通常再生時にランダムアクセスが多量に発生することになってしまう。
　また、この非特許文献４で開示されている手法は、図４に示すように、geometry video streamおよびtexture video streamを取得する際、各streamのbitrateをネットワーク帯域幅に応じて選択し、最適な品質のPCCを再構成するというユースケースに有用である。これは、サーバに多数のsingle stream（bitrateの異なるgeometry video streamとtexture video streamとの組み合わせ）を配置する負担がなくなるからである。
　そこで、以下で説明する実施の形態は、このようなユースケースを実現する上で、PC streamを構成するgeometry video streamとtexture video streamとの紐づけ方法を新たに定義することで、クライアントにおける処理を簡潔に行うことができるようにするものである。
　＜ISOBMFF格納のためのPC sample定義＞
　図５を参照して、ISOBMFF格納のために新たに定義するPoint Cloud sample（以下、PC sampleと称する）について説明する。
　図５は、新たに定義するPC sampleの構造を示す図である。
　まず、同時刻に表示されるPoint Cloudを構成する単位を1 PC frameと呼び、1 PC frameは1 PC sampleから構成されると定義する。そして、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを、ISOBMFFの1 trackに格納する。このように定義することで、クライアントは、1 PC sampleをデコードすることによって同時刻に表示されるPoint Cloudを構成可能となる。これにより、クライアントは、上述したような通常再生中に多量のランダムアクセスが発生することを回避することができ、処理を簡潔に行うことができるため、例えば、処理の遅延や処理コストの増大などを回避することができる。
　このように定義されたPC streamは、複数のPC sampleの連続で構成される。
　図５に示すように、1 PC sampleは、複数のcomponentと３次元情報メタデータとで構成される。ここで、componentには、texture画像およびgeometry画像が含まれる。また、３次元情報メタデータは、auxiliary patch infoおよびoccupnacy map、並びにPC headerからなる。
　また、１つのcomponentは、複数のsubsampleから構成される。つまり、１つのcomponentは、Ｎ個（layer）のgeometry subsample、および、Ｎ個（layer）のtexture subsampleから構成される。
　そして、geometry subsamplesおよびtexture subsamplesは、それぞれ個別に動画コーデックで符号化される。ここで、subsampleは、geometry video streamおよびtexture video streamの1 pictureを構成する単位となる。
　また、PC headerは、componentのlayer構造を示す情報を持つ。また、occupancy mapは、componentのピクチャ内のパッチ位置情報を持ち、auxiliary patch infoは、パッチを３Ｄオブジェクトに張り付けるための2D3D変換情報を持つ。
　なお、GOF情報は、PC header内に含まれるが、PC sample内に個別にGOF headerをシグナルしてもよい。また、PC headerやauxiliary patch infoおよびoccupancy mapなどのような３次元情報メタデータを、subsampleとしてもよい。
　＜第１の格納方法＞
　図６乃至図１９を参照して、ISOBMFFの1 trackにPC streamを格納する方法である第１の格納方法について説明する。
　図６乃至図９を参照して、elementary streamのシグナリングについて説明する。
　図６には、layer数が２であり、かつ、符号化に用いた動画コーデックがAVCまたはHEVCである場合におけるPC sample（即ち、ISOBMFFのsample）の一例が示されている。ここで、図６に示されているAUD（Access Unit Delimiter）は、AVCまたはHEVCのaccess unit境界にシグナルされるNAL（Network Abstraction Layer） unitである。
　図６に示すPC sampleは、PC headerに続いて、layer0のgeometry subsample、layer1のgeometry subsample、layer0のtexture subsample、およびlayer1のtexture subsampleが連続的に配置された構成となっている。
　図７には、図６のPC headerに格納される情報の一例が示されている。
　図７に示すように、PC headerには、例えば、PC sampleのサイズを示す情報（size_of_pc_frame）、および、1PC frameを構成するtexture画像またはgeometry画像のlayer数を示す情報（number_of_layer）が格納される。また、PC headerには、geometry画像またはtexture画像の幅を示す情報（frameWidth）、geometry画像またはtexture画像の高さを示す情報（frameHeight）、および、occupnacy mapの解像度を示す情報（occupancyResolution）が格納される。さらに、PC headerには、平滑化のための近傍点を検出する半径を示す情報（radiusToSmoothing）、平滑化に使用する近傍点の最大数を示す情報（neighborCountSmoothing）、境界点を検出する半径を示す情報（radius2BoundaryDetection）、および、平滑化閾値を示す情報（thresholdSmoothing）が格納される。
　図８には、図６のheaderに格納される情報の一例が示されている。
　図８に示すように、headerには、texture画像またはgeometry画像のsubsampleのサイズを示す情報（size_of_sample）、subsampleのタイプを示す情報（type）、および、subsampleのlayer識別子（layer_id）が格納される。例えば、subsampleのタイプを示す情報が０である場合、subsampleがgeometry画像であることを示し、subsampleのタイプを示す情報が１である場合、subsampleがtexture画像であることを示す。
　また、occupancy mapおよびauxiliary patch infoは、geometry subsampleにSEI (Supplemental Enhancement Infromation)として含まれる。
　これらのシグナリングによれば、クライアントは、PC headerからPC sampleの境界を識別可能であり、headerから各componentのsubsampleの境界を識別可能である。従って、クライアントは、それらの境界に従って、PC sampleからgeometry video streamおよびtexture video streamを抽出し、それぞれデコーダに入力してデコード処理を実施することができる。
　なお、occupancy mapおよびauxiliary patch infoは、layer間で同じであれば同一の情報が各layerのsubsampleにシグナルされる。但し、layerごとに、その情報が異なっていてもよい。また、SEIは、texture subsampleにシグナルされてもよい。
　また、PC streamのGOF先頭に、公知のGOF headerをシグナルしてもよい。
　図９には、GOF headerに格納される情報の一例が示されている。
　図９に示すように、GOF headerには、例えば、Group of Frames内のフレーム数を示す情報（group0fFramesSize）が格納される。その他、GOF headerには、図７に示したPC headerと同じ情報が格納される。
　なお、occupancy mapを動画コーデックで符号化し、componentの一種として、occupancy subsampleとしてもよい。
　図１０乃至図１６を参照して、ISOBMFFのシグナリングについて説明する。
　図１０には、PC streamをISOBMFFの1 trackに格納する際の一例が示されている。
　例えば、ISOBMFFのmoovには、新たに定義するPCSampleEntry（図１２参照）が格納され、PCSampleEntryは、図１３に示すPCHeaderBox、図１４に示すSubSampleEntryBox、および、図１５に示すLayerCompositionBoxからなる。
　また、ISOBMFFのmoofには、subs（SubSampleInformationBox）が格納され、図１０に示すように、SubSampleInformationBoxを利用して、PC sample内のgeometry subsampleとtexture subsampleとの境界をシグナルすることができる。なお、SubSampleInformationについては、後述の図５４に示すSubSampleInformationBoxの概要を参照して説明する。
　そして、ISOBMFFのmdatに格納されるsampleとして、図６に示したようなPC sampleが格納される。
　ここで、SubSampleInformationBoxにおいて、符号化コーデックごとに決まるsubsampleの情報であるcodec_specific_parametersが定義される。
　即ち、図１１に示すように、codec_specific_parametersの値が０であるとき、subsampleはgeometry subsampleであることを示し、codec_specific_parametersの値が１であるとき、subsampleはtexture subsampleであることを示す。
　なお、codec_specific_parametersにlayer識別子の情報を含んでもよい。また、subsample informationは、連続するgeometry subsample群、texture subsample群の単位で提供されてもよい。さらに、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種としsubsampleとしてシグナルする場合は、subsample informationに、それぞれのsubsampleを示す値を追加してもよい。
　図１２には、本開示で新たに定義するPCSampleEntryの構造が示されている。
　図１２に示す構成において、PC streamを格納するISOBMFFのtrackのsample entryは、例えば、'pcbs'となる。
　図１３に示すように、PCHeaderBoxには、図７に示したPC headerと同一の情報が記述される。
　例えば、PC stream内でPC header情報が変化する場合、PCHeaderBoxの情報をsample groupとしてシグナルしてもよい。また、GOF headerの情報は、PCHeaderBoxと個別に、sample entryやsample groupなどにシグナルしてもよい。なお、Sample Groupについては、後述の図５５に示すSample Groupの概要を参照して説明する。
　また、このとき、PC sample内のPC headerおよびheaderはシグナルされなくてもよい。
　そして、これらのシグナリングによれば、クライアントはsubsampleの中身をパースすることなく、PC sampleの境界および各componentのsubsampleの境界を識別可能である。つまり、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC sampleからgeometry video streamおよびtexture video streamを抽出し、それぞれデコーダに入力してデコード処理を実施することができる。
　図１４に示すように、SubSampleEntryBoxは、連続するsubsampleで構成されるtexture video stream、geometry video streamのコーデック、および、decoder configuration情報をシグナルする。
　図１４に示すnum_of_componentは、trackに格納されるcomponentの総数を示し、typeフィールドは、sub sample entryが対応するcomponentの種類を表す。例えば、typeフィールドが０である場合、sub sample entryが対応するcomponentの種類はgeometry画像であることを示し、typeフィールドが１である場合、sub sample entryが対応するcomponentの種類はtexture画像であることを示す。SampleEntry()は、componentの符号化コーデックに応じて変化し、例えば、HEVC符号化されている場合にはHEVCSampleEntryとなる。
　また、各sub sample entryが対応するsubsampleへの紐づけは、sub sample informationのcodec_specific_parametersおよびsub sample entryのtypeでシグナルされるcomponentの種類によって行われる。なお、componentのtypeごとに、符号化コーデックを変更してもよい。
　このシグナリングによれば、クライアントは、geometry video streamおよびtexture video streamのコーデックを識別し、正しくデコード処理を実行することができる。
　図１５に示すように、LayerCompositionBoxは、composition timeが同一となるlayer数、および、PC sampleを構成するcomponentの数をシグナルする。
　例えば、num_layer_composedは、output orderで1 PC frameを構成するdecoded picture数を示す。また、num_of_componentは、1 PC frameを構成するcomponent数を示す。
　なお、上述したようにsample entryにシグナルする例について説明したが、この場所に限らず、例えばSubSampleEntryBoxにシグナルされてもよい。このシグナリングによれば、異なるcomposition timeが割り当てられている各componentの各layerのsubsampleにおいて、同時刻に表示されるPoint Cloudを構成し、同時にレンダリングすべきsubsampleを明示的に示すことができる。これにより、クライアントは、正しくPoint Cloudを構成してレンダリングすることができる。
　図１６には、output orderで1 PC frameを構成するdecoded picture数が２（num_layer_composed=2）であって、かつ、1 PC frameを構成するcomponent数がgeometry画像とtexture画像との２（num_of_component=2）である、合計4 subsamplesから構成されるPC sampleの一例が示されている。このようなPC sampleについては、図１５に示したLayerCompositionBoxの情報により、4 subsamplesから構成されることが示される。
　なお、component数が１であって、layer数が２である構成は、従来の技術、例えば、ステレオ映像におけるtemporal interleavingと同様の考え方となる。しかしながら、本技術は、component数が複数であって、layer数が複数である構成への対応を可能としている点で、そのような構成への対応ができない従来の技術とは異なるものである。
　＜情報処理装置の第１の構成例＞
　図１７は、コンテンツを提供するサーバ側で、Point CloudコンテンツからPC streamを生成し、そのPC streamをISOBMFFに格納したPCファイルを生成するPCファイル生成処理を実行する情報処理装置の第１の構成例を示すブロック図である。
　図１７に示すように、情報処理装置１１は、3D2D変換部２１、符号化部２２、PC stream生成部２３、およびファイル生成部２４を備えて構成される。
　3D2D変換部２１は、入力されるPoint Cloudを２次元に変換することによって、geometry画像およびtexture画像と、３次元情報メタデータ（auxiliary patch infoおよびoccupancy map）とを生成して、符号化部２２に供給する。
　符号化部２２は、geometry画像と３次元情報メタデータから、３次元情報メタデータをSEIとして含むgeometry video streamを符号化し、texture画像からtexture video streamを符号化する。例えば、符号化部２２AVCおよびHEVCといったnon-layered coding、または、SVCやSHEVCなどのようなlayered codingで符号化を行う。このとき、符号化部２２は、２台のエンコーダ２５－１および２５－２によって、geometry画像の符号化とtexture画像の符号化とを並列的に行うことができる。
　PC stream生成部２３は、符号化部２２により符号化されたgeometry video streamおよびtexture video streamを、PC frameを構成する単位でインターリーブし、図５に示したようなPC sampleを生成する。そして、PC stream生成部２３は、複数のPC sampleからなるPC streamを生成して、ファイル生成部２４に供給する。
　ファイル生成部２４は、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを、ISOBMFFの1 trackに格納し、PCファイルを生成する。
　このように構成される情報処理装置１１は、Point CloudコンテンツからPC streamを生成し、そのPC streamをISOBMFFの1 trackに格納したPCファイルを出力することができる。
　図１８は、コンテンツを再生するクライアント側で、PCファイルから表示画像を生成してPoint Cloudを再生するPoint Cloud再生処理を実行する情報処理装置の第１の構成例を示すブロック図である。
　図１８に示すように、情報処理装置１２は、抽出部３１、復号部３２、2D3D変換部３３、および表示処理部３４を備えて構成される。
　抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、PCファイルから、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出して復号部３２に供給する。
　復号部３２は、抽出部３１から供給されるgeometry video streamおよびtexture video streamを復号して、2D3D変換部３３に供給する。このとき、復号部３２は、２台のデコーダ３５－１および３５－２によって、geometry画像の復号とtexture画像の復号とを並列的に行うことができる。
　2D3D変換部３３は、geometry video streamに含まれるSEI情報をもとに、Point Cloudを構築する。
　表示処理部３４は、2D3D変換部３３により構築されたPoint Cloudを、クライアントの表示デバイスに合わせてレンダリングし、表示画像を生成して、図示しない表示デバイスに表示させる。
　このように構成される情報処理装置１２は、PCファイルからPoint Cloudを再生して、Point Cloudをレンダリングした表示画像を表示させることができる。
　＜PCファイル生成処理およびPoint Cloud再生処理の第１の処理例＞
　図１９は、図１７の情報処理装置１１が、Point CloudからPCファイルを生成するPCファイル生成処理を説明するフローチャートである。
　例えば、情報処理装置１１にPoint Cloudの入力が行われると処理が開始され、ステップＳ１１において、3D2D変換部２１は、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する。
　ステップＳ１２において、符号化部２２は、ステップＳ１１で3D2D変換部２１により生成されたgeometry画像および３次元情報メタデータから、３次元情報メタデータをSEIとして含むgeometry video streamを符号化し、texture画像からtexture video streamを符号化する。
　ステップＳ１３において、PC stream生成部２３は、PC frameを構成する単位（PC sample）でインターリーブし、PC streamを生成する。
　ステップＳ１４において、ファイル生成部２４は、PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納し、PCファイルを生成する。このとき、ISOBMFFのsampleはPC sampleとなる。
　図２０は、図１８の情報処理装置１２が、PCファイルから表示画像を生成して再生するPoint Cloud再生処理を説明するフローチャートである。
　例えば、情報処理装置１２へPCファイルの先端から供給が始まると処理が開始され、ステップＳ２１において、抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、PCファイルから、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出する。
　ステップＳ２２において、復号部３２は、geometry video streamおよびtexture video streamを、それぞれ個別に復号する。このとき、geometry video streamおよびtexture video streamは２デコーダインスタンスによる個別のデコードとなる。
　ステップＳ２３において、2D3D変換部３３は、geometry video streamに含まれるSEI情報をもとに、Point Cloudを構築する。
　ステップＳ２４において、表示処理部３４は、クライアントの表示デバイスに合わせ、Point Cloudをレンダリングして表示画像を表示させる。
　ステップＳ２５において、抽出部３１は、PC streamの終端か否かを判定し、PC streamの終端でない場合には処理はステップＳ２１に戻り、PC streamの終端である場合には、処理は終了される。
　以上のようなPCファイル生成処理およびPoint Cloud再生処理によって、クライアント側における処理が簡潔に行えるようにすることができる。
　ここで、図２１には、第１の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
　なお、変形例として、第１の格納方法でPC streamをISOBMFFの構造に格納する際に、後述の第３の格納方法におけるISOBMFFのシグナリングと同様に、Group of Framesの境界を、sample groupを用いてシグナルしてもよい。また、elementary streamの符号化において、AVCおよびHEVCといったnon-layered codingではなく、SVC（Scalable Video Coding）やSHEVC（Scalable High Efficiency Video Coding）などのようなlayered codingを用いてもよい。
　例えば、geometry video streamおよびtexture video streamのlayer 0はbase layerとして符号化され、geometry video streamおよびtexture video streamのlayer 1はenhancement layerとして符号化される。
　即ち、図２２に示すように、ISOBMFFの1 trackに1 layerが格納される場合には、enhancement trackには、enhancement layerのgeometry video streamおよびtexture video streamが格納され、base trackには、base layerのgeometry video streamおよびtexture video streamが格納される。そして、enhancement trackからbase trackへ、track reference（参照タイプ'sbas'）で紐づけが行われる。このとき、base trackのsample entryはPCSampleEntry（'pcbs'）とし、enhancement trackのsample entryはPCEnhancementSampleEntry（'penh'）とする。例えば、enhancement trackは、layer数分に応じて存在する。
　ここで、例えば、各trackに格納されているlayerが、layer 0およびlayer 1のどちらであるかを示すために、PC sample内のheaderでシグナルされるlayer識別子（例えば、図８のlayer_id）を、各trackのsample entryでシグナルしてもよい。または、PC sample内のheaderそのものを、各trackのsample entryに格納してもよい。
　＜第２の格納方法＞
　図２３乃至図３５を参照して、geometry/texture video streamを1 streamにパッキングしてISOBMFFの1 trackに格納する方法である第２の格納方法について説明する。
　上述した第１の格納方法では、符号化前のtexture画像およびgeometry画像をインターリーブし、一つのvideo streamとして符号化することで、１デコーダによるデコード処理を実現することは可能である。しかしながら、そのような符号化では、texture画像とgeometry画像との間に相関が少ないことより、圧縮効率が悪化してしまう。
　また、第１の格納方法では、生成されたシングルストリームを１デコーダでデコードすることも可能である。しかしながら、符号化されたtexture画像とgeometry画像との境界でデコーダの初期化が必要となることより、オーバーヘッドが大きくなってしまう。
　つまり、第１の格納方法では、PCファイル生成処理において、texture video streamおよびgeometry video streamを個別に符号化し、Point Cloud再生処理において、geometry video streamおよびtexture video streamに対して２デコーダインスタンスによる個別のデコードが必要であった。このため、第１の格納方法を、１デコーダインスタンスによるデコードに適用すると、圧縮効率が悪化してしまい、また、オーバーヘッドが大きくなってしまう。
　そこで、第２の格納方法では、複数の画像を、上述した特許文献１に記載の方法などで１つの画像にパッキングし、符号化してPC streamを構成する。例えば、複数componentの画像を１つの画像にパッキングしたり、複数layerの画像を１つの画像にパッキングしたり、複数componentの複数layerの画像を１つの画像にパッキングすることができる。これにより、上述したような圧縮効率の悪化を回避しつつ、クライアントによる１デコーダインスタンスでのデコード処理を可能にする。なお、パッキングの方法としては、side by sideやtop & bottomなどの方法を採用するだけでなく、その他の方法を採用してもよい。
　図２３を参照して、パッキングのバリエーションについて説明する。
　図２３のＡには、side by sideの方法で、同一のlayerを異なるcomponentどうしで１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 0のgeometry画像とをside by sideで１つの画像にパッキングし、layer 1のtexture画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。
　図２３のＢには、side by sideの方法で、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 1のtexture画像とをside by sideで１つの画像にパッキングし、layer 0のgeometry画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。
　なお、図２３のＢに示すパッキングでは、１デコーダインスタンスでのデコード処理は可能であるものの、上述したようにtexture画像とgeometry画像との間に相関が少ないため、圧縮効率の悪化を改善することにはならない。しかしながら、layer間で画像の相関が高い場合においては、パッキングされた画像内で参照関係を持たせることで、符号化効率の向上を図ることができる。なお、図２３のＢに示すパッキングは、後述する第４の格納方法のように、geometry video streamおよびtexture video streamを分割してtrackに格納する場合において有効なパッキングとなる。
　図２３のＣには、side by sideの方法で、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングした２枚の画像を、top & bottomの方法で１つの画像にパッキングすることで、全てのcomponentにおける全てのlayerの画像を１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 1のtexture画像とをside by sideで１つの画像にパッキングするとともに、layer 0のgeometry画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。そして、それらの２つの画像を、top & bottomで１つの画像にパッキングすることで、layer 0のtexture画像、layer 1のtexture画像、layer 0のgeometry画像、およびlayer 1のgeometry画像が１つの画像にパッキングされる。
　ここで、以下、図２３を参照して説明したように、複数の画像をパッキングした１枚の画像をpacked PC画像と称する。そして、packed PC画像の連続を符号化したものを、packed PC streamと称し、packed PC streamをISOBMFFに格納したものをpacked PCファイルと称する。
　なお、ここで説明した第２の格納方法におけるパッキング方法は、geometry画像およびtexture画像のように、それぞれ大きく異なる画像をパッキングする点で、例えば、視差を利用した立体視に関する先行技術であるステレオパッキングとは異なる技術である。
　以下では、図２３のＡに示したように、同一のlayerの画像を異なるcomponentどうしで１つの画像にパッキングしたpacked PC画像を用いた例について説明する。
　図２４には、elementary streamのシグナリングの一例が示されている。
　図２４では、layer数が２であり、かつ、符号化に用いた動画コーデックがAVCまたはHEVCの場合におけるPC sampleの一例が示されている。
　図２４に示すように、geometry画像およびtexture画像を１つの画像にパッキングしたpacked PC streamを構成する１つのpacked PC画像を1 subsampleとしている点で、第１の格納方法（上述の図６参照）とは異なる。
　また、第２の格納方法では、headerは、第１の格納方法で定義した情報に加え、subsampleのタイプとしてgeometry+textureをシグナルする。
　例えば、図２５に示すように、SEIとして、point cloud frame packing SEIを新たに定義してシグナルすることができる。図２５に示されているSEIは、geometry画像およびtexture画像のパッキング方法についての情報を持つ。
　例えば、図２６に示すように、SEIにおいて、packing_arrangementが０である場合、パッキングがside by sideであることを示し、packing_arrangementが１である場合、パッキングがtop & bottomであることを示す。また、packing_arrangementが、その他である場合、パッキングがreservedであることを示す。同様に、SEIにおいて、frame0_is_geometryが０である場合、frame0がgeometryであることを示し、frame0_is_geometryが１である場合、frame0がtextureであることを示す。
　ここで、frame0の定義は、図２７に示すようになる。例えば、side by sideの場合には、図２７のＡに示すように、frame0が左側、かつ、frame1が右側となるようにパッキングされる。また、top & bottomの場合には、図２７のＢに示すように、frame0が上側、かつ、frame1が下側となるようにパッキングされる。
　なお、この情報のシグナルはSEIに限らず他の場所でシグナルしてもよく、例えばPC headerでシグナルしてもよい。また、パッキング方法には、side by sideおよびtop & bottom以外の方法を用いてもよい。
　また、クロマサブサンプリングが4:2:2や4:2:0などである場合、色差信号間引きを考慮し、パッキングされる各componentの幅および高さを２の倍数のピクセル数とすることで、エンコード処理やcomponent切り出し処理などを容易に行うことができる。また、パッキングされる各componentの幅および高さを、８または１６の倍数のピクセル数とすることで、エンコード時のブロックサイズとの親和性を高めることができ、エンコード処理やcomponent切り出し処理などを容易に行うことができる。
　以上のように、これらのシグナリングによれば、PC headerからPC sampleの境界を識別可能であり、headerでsubsampleの境界を識別可能である。また、point cloud frame packing SEIからtexture画像およびgeometry画像の分離が可能となる。これにより、クライアントは、subsampleをデコードした後、正しくPoint Cloudを構成してレンダリングが可能となる。
　図２８には、packed PC画像を符号化したpacked PC streamをISOBMFFの1 trackに格納する際の一例が示されている。
　図２８に示すように、SubSampleInformationBox（'subs'）のcodec_specific_parametersの値が２であるとき、subsampleはgeometry&texture subsampleであることを示す。即ち、第２の格納方法では、codec_specific_parametersの値について、図１１を参照して説明した０および１に追加して２が用いられる点で、第１の格納方法とは相違する。このように、SubSampleInformationBoxを利用して、PC sample内のgeometry&texture subsampleの境界をシグナルすることができる。なお、SubSampleInformationについては、後述の図５４に示すSubSampleInformationBoxの概要を参照して説明する。
　また、図２９に示すように、図２５に示したpoint cloud frame packing SEIと同様に、texture画像およびgeometry画像のパッキング方法についての情報を持つPCPackingInfoBoxがsample entryにシグナルされる。
　なお、第２の格納方法においても、第１の格納方法で説明した変形例を、同様に適用することができる。
　また、第２の格納方法は、例えば、第１の格納方法でのrestricted schemeとして運用され、sample entryは'resv'となり、SchemeTypeBoxのscheme_typeは'pacp'となる。このとき、ポストデコード処理に使用されるPCPackingInfoBoxは、図２８に示したように、rinf/schi下にシグナルされる。
　＜情報処理装置の第２の構成例＞
　図３０は、コンテンツを提供するサーバ側で、Point CloudコンテンツからPCファイルを生成するPCファイル生成処理を実行する情報処理装置の第２の構成例を示すブロック図である。なお、図３０に示す情報処理装置１１Ａにおいて、図１７の情報処理装置１１と共通する構成については、同一の符号を付し、その詳細な説明は省略する。
　図２０に示すように、情報処理装置１１Ａは、3D2D変換部２１、符号化部２２Ａ、PC stream生成部２３、ファイル生成部２４、およびパッキング処理部２６を備えて構成される。
　即ち、情報処理装置１１Ａは、パッキング処理部２６を備え、符号化部２２Ａが１台のエンコーダ２５を有する点で、図１７の情報処理装置１１と異なる構成となっている。
　パッキング処理部２６は、上述したようなパッキング方法で、texture画像およびgeometry画像、並びに、それらの各layerをパッキングして、packed PC画像を符号化部２２Ａに供給する。
　符号化部２２Ａは、１台のエンコーダ２５でpacked PC画像を符号化することができる。
　図３１は、コンテンツを再生するクライアント側で、packed PCファイルから表示画像を生成してPoint Cloudを再生するPoint Cloud再生処理を実行する情報処理装置の第２の構成例を示すブロック図である。なお、図３１に示す情報処理装置１２Ａにおいて、図１８の情報処理装置１２と共通する構成については、同一の符号を付し、その詳細な説明は省略する。
　即ち、情報処理装置１２Ａは、復号部３２Ａが１台のデコーダ３５を有する点で、図１８の情報処理装置１２と異なる構成となっている。
　情報処理装置１２Ａでは、抽出部３１が、ISOBMFFのBoxでシグナルされる情報をもとに、packed PCファイルから、再生時刻に対応するpacked PC streamを抽出し、復号部３２Ａが、１台のデコーダ３５でpacked PC streamを復号することができる。
　＜packed PCファイル生成処理およびPoint Cloud再生処理の処理例＞
　図３２は、図３０の情報処理装置１１Ａが、Point Cloudからpacked PC streamを生成し、そのpacked PC streamをISOBMFFに格納したpacked PCファイルを生成するpacked PCファイル生成処理を説明するフローチャートである。
　例えば、情報処理装置１１ＡにPoint Cloudの入力が行われると処理が開始され、ステップＳ３１において、3D2D変換部２１は、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する。
　ステップＳ３２において、パッキング処理部２６は、texture画像およびgeometry画像、並びに、それらの各layerをパッキングして、packed PC画像を生成する。
　ステップＳ３３において、符号化部２２Ａは、ステップＳ３２で3D2D変換部２１により生成されたpacked PC画像を符号化する。
　ステップＳ３４において、PC stream生成部２３は、packed PC streamを構成する単位でインターリーブし、３次元情報メタデータおよびパッキング情報をSEIとして含むpacked PC streamを生成する。
　ステップＳ３５において、ファイル生成部２４はpacked PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納して、packed PCファイルを生成する。このとき、ISOBMFFのsampleはPC sampleとなる。
　図３３は、図３１の情報処理装置１２Ａが、packed PCファイルから表示画像を生成して再生するPoint Cloud再生処理を説明するフローチャートである。
　例えば、情報処理装置１２ＡへPC streamの先端から供給が始まると処理が開始され、ステップＳ４１において、抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、packed PCファイルから、再生時刻に対応するpacked PC streamを抽出する。
　ステップＳ４２において、復号部３２Ａは、packed PC streamを復号する。このとき、packed PC streamは１デコーダインスタンスによるデコードとなる。
　ステップＳ４３において、2D3D変換部３３は、パッキング情報と、packed PC streamに含まれるSEI情報をもとに、Point Cloudを構築する。
　ステップＳ４４において、表示処理部３４は、クライアントの表示デバイスに合わせ、Point Cloudをレンダリングして表示画像を表示させる。
　ステップＳ４５において、抽出部３１は、PC streamの終端か否かを判定し、PC streamの終端でない場合には処理はステップＳ４１に戻り、PC streamの終端である場合には、処理は終了される。
　以上のようなpacked PCファイル生成処理およびPoint Cloud再生処理によって、クライアント側における処理が簡潔に行えるようにすることができる。
　ここで、図３４には、第２の格納方法でpacked PC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
　これらのシグナリングによれば、クライアントは、subsampleの中身をパースすることなく、PC sampleの境界および各componentのsubsampleの境界を識別可能である。そして、クライアントは、PCPackingInfoBoxからtexture画像とgeometry画像の分離に必要な情報を取得することができる。従って、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC sampleからpacked PC streamを抽出してデコード処理を実施する。その後、クライアントは、packed PC画像からgeometry画像とtexture画像とを分離し、Point Cloudを構成してレンダリングを実行することができる。
　なお、図２３のＡに示したパッキングと同様に、例えば、図２３のＢに示したパッキング、および、図２３のＣに示したパッキングについても、point cloud frame packing SEI（図２５）およびPCPackingInfoBox（図２９）によりパッキング方法をシグナルすることができる。これにより、クライアントは、texture画像およびgeometry画像の各layerを分離することが可能となる。
　また、point cloud frame packing SEIおよびPCPackingInfoBoxにより、例えば、各componentおよび各layerのピクチャ内における配置や位置、サイズなどをシグナルすることで、自由度のあるパッキングを行うことができる。
　図３５には、PCPackingInfoBoxの変形例が示されている。
　図３５に示すように、PCPackingInfoBoxには、例えば、packed PC画像を構成するcomponent数を示す情報（component_num）、packed PC画像を構成するlayer数を示す情報（layer_num）、および、componentの種類を示す情報（component_type）が記述される。例えば、component_typeが０である場合、componentの種類はgeometry画像であること示し、component_typeが１である場合、componentの種類はtexture画像であることを示す。また、PCPackingInfoBoxには、layer識別子（layer_id）、並びに、packed PC画像内においてcomponent_typeおよびlayer_idで示される画像が配置される位置を示す情報（left/top）と、それらのサイズを示す情報（width/height）とが記述される。
　なお、例えば、これまで説明したようにgeometry画像およびtexture画像をcomponentとして扱うのに加えて、occupancy mapをcomponentとして扱ってもよい。この場合、occupancy mapも、geometry画像およびtexture画像とともにパッキングすることができる。
　＜第３の格納方法＞
　図３６乃至図４３を参照して、PC sampleを定義せずPC streamをISOBMFFの1 trackに格納する方法である第３の格納方法について説明する。ここで、第３の格納方法は、上述したようなPC sampleという概念を用いずに、texture subsampleおよびgeometry subsampleをISOBMFFのsampleとして格納する点で、第１の格納方法および第２の格納方法に対する変形例となる。
　従って、第３の格納方法におけるelementary streamのシグナリングは、第１の格納方法におけるelementary stream（図６参照）および第２の格納方法におけるelementary stream（図２４参照）と同一の構造となる。但し、第３の格納方法では、1SOBMFFにおけるsampleをgeometry subsampleおよびtexture subsampleと定義する。そして、1SOBMFFにおけるsampleと定義されたgeometry subsampleをgeometry sampleと称し、1SOBMFFにおけるsampleと定義されたtexture subsampleをtexture sampleと称する。
　図３６には、第３の格納方法におけるelementary streamのシグナリングの一例として、第１の格納方法におけるelementary streamと同様の構造が示されている。
　図３７には、ISOBMFFのシグナリングの一例が示されている。
　例えば、図３７に示すように、sample groupを用いて、Group of Framesの境界(GOFEntry)、PC frameの境界(PCFrameEntry)、texture samplesの境界、geometry samplesの境界、およびtexture&geometry samplesの境界(ComponentGroupEntry)をシグナルすることができる。なお、Sample Groupについては、後述の図５５に示すSample Groupの概要を参照して説明する。
　そして、各sampleは、SampleToGroupBox ('sbgp')を通じて、SampleGroupDescriptionBox ('sgpd')でシグナルされる各SampleGroupEntryに紐づけられる。なお、sgpdは、MovieBox ('moov')内のSampleTableBox ('stbl')にシグナルされてもよい。
　ここで、図３８乃至図４０に、新たに定義したGroupEntryを示す。
　図３８に示すようにGOFEntryは定義され、grouping_type_parameter='gofg'とする。
　なお、GOFEntryの各fieldのセマンティクスは、上述の図９に示したGOF headerの各fieldと同一である。
　図３９に示すようにPCFrameEntryは定義され、grouping_type_parameter='pcfg'とする。
　例えば、PCFrameEntryにおけるsize_of_pc_frameフィールドは、PC frameのサイズを示す。また、number_of_componentフィールドは、PC frameを構成するcomponentの数を示し、具体的には、geometry画像およびtexture画像から構成される場合には、２となる。
　図４０に示すようにComponentGroupEntryは定義され、grouping_type_parameter='cmpg'とする。
　例えば、ComponentGroupEntryにおけるtypeフィールドは、このsample groupに属するsampleのcomponentの種類を示す。具体的には、typeフィールドが０である場合には、componentの種類がgeometry画像であることを示し、typeフィールドが１である場合には、componentの種類がtexture画像であることを示す。また、typeフィールドが２である場合には、componentの種類がgeometry&texture（第２の格納方法）であることを示す。
　なお、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせずにcomponentの一種として扱う場合、typeフィールドに、それぞれのcomponentの種類を示す値を追加してもよい。
　また、ComponentGroupEntryにおけるnumber_of_layerフィールドは、componentのlayer数を示す。
　さらに、ComponentGroupEntryの代わりに、GeometryGroupEntryおよびTextureGroupEntryを定義してもよい。そして、GeometryGroupEntryによりgeometry samplesの境界をシグナルし、TextureGroupEntryによりtexture samplesの境界をシグナルすることができる。
　また、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種とし、sampleとしてシグナルする場合は、それぞれのsamplesの境界をシグナルするGroupEntryを定義してもよい。そして、GroupEntryにより、それぞれのsamplesの境界を示してもよい。
　なお、第２の格納方法のように、各componentおよび各layerが１つの画像にパッキングされた場合には、sample entryにPCPackingInfoBoxがシグナルされる。
　ここで、第３の格納方法において、ISOBMFFに格納されるストリームはAVCやHEVC，SVC，SHEVCなどに準拠させることができ、その場合、これらのコーデックのrestricted schemeとして運用することができる。例えば、sample entryは'resv'になり、SchemeTypeBoxのscheme_typeは'pcbs'になり、OriginalFormatBoxのdata_formatは用いられたコーデックによって、avc1やhev1などになる。
　そして、これらの新たに定義された複数のBoxは、ポストデコード処理に使用されるという位置づけになり、図３７に示すrinf/schi下にシグナルされる。さらに、このrinf/schiには、第１の格納方法で説明したPCHeaderBoxおよびLayerCompositionBoxも、図示するようにシグナルされる。
　また、例えば、texture video streamおよびgeometry video streamが各2 layerで構成されている場合、120pのvideo streamは30pのPC streamに相当する。
　これにより、図４１に示すように、クライアントは、（LayerCompositionBoxのnum_layer_composed × num_of_component）の値から、sampleのインターリーブ周期である4 samplesを識別することができる。
　そして、これらのシグナリングによれば、クライアントはsampleの中身をパースすることなく、sample groupの情報を通じて、Group of Framesの境界、PC sampleの境界および各componentのsampleの境界を識別可能である。つまり、クライアントは、PCPackingInfoBoxからtexture画像とgeometry画像との分離に必要な情報を取得できる。
　従って、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、geometry video streamおよびtexture video streamを抽出してデコード処理を実施する。その後、クライアントは、geometry画像とtexture画像とを分離し、Point Cloudを構成してレンダリングを実行することができる。
　ここで、第１の格納方法のようにパッキングを適用しない場合、生成処理および再生処理は、それぞれ図１９および図２０のフローチャートを参照して上述したのと同様に行われる。このとき、図１９のステップＳ１４において、PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納する際、ISOBMFFのsampleは各componentのsampleとなる。また、図２０のステップＳ２２において、geometry video streamおよびtexture video streamは、２デコーダインスタンスによる個別のデコードとなる。
　また、第２の格納方法のようにパッキングを適用する場合、生成処理および再生処理は、それぞれ図３２および図３３のフローチャートを参照して上述したのと同様に行われる。このとき、図３２のステップＳ３５において、packed PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納する際、ISOBMFFのsampleはpacked PC streamの1 pictureとなる。また、図３３のステップＳ４２において、packed PC streamは１デコーダインスタンスによるデコードとなる。
　ここで、図４２には、第３の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
　なお、図４３を参照して、SEIを用いずにシグナルする例について説明する。
　ここまで、PC frame内の３次元情報メタデータについて、SEIを用いてシグナルする例について説明した。これに対し、例えば、ISOBMFFで規定されるsample auxiliary informationを利用して３次元情報メタデータをシグナルしてもよい。
　即ち、図４３に示すように、SampleAuxiliaryInformationOffsetBox ('saio')のoffsetフィールドでsample auxiliary infromationの位置をシグナルする。同様に、SampleAuxiliaryInformationSizeBox ('saiz')のsample_info_sizeフィールドで、各sampleに紐づくsample auxiliary informationのサイズをシグナルする。例えば、SampleAuxiliaryInformationOffsetBoxおよびSampleAuxiliaryInformationSizeBoxは、aux_info_type='pcmd'で関連づけられる。
　SEIは、AVCやHEVCなどのような符号化コーデックで用いられる要素であるため、SEIを用いた場合には、コーデックに依存したシグナリングとなってしまう。これに対し、sample auxiliary informationを用いた場合には、符号化コーデックに依存することなく３次元情報メタデータをシグナルすることが可能となる。
　＜第４の格納方法＞
　図４４乃至図５３を参照して、PC streamをgeometry video streamおよびtexture video streamに分け、ISOBMFFの2 tracksに格納する方法である第４の格納方法について説明する。
　図４４には、第４の格納方法におけるISOBMFFのシグナリングの一例が示されている。
　図４４に示すように、PC streamをgeometry video streamとtexture video streamとに分離し、それぞれをISOBMFFの1 trackに格納する。ここで、geometry video streamを格納するtrackをgeometry track（または主track）と称し、texture video streamを格納するtrackをtexture track（または副track）と称する。また、geometry trackには、auxiliary patch infoおよびoccupancy mapも格納される。
　そして、geometry trackおよびtexture trackの関係性を、track referenceと、新たに定義したPCMultiStreamBoxでシグナルする。
　なお、第４の格納方法においても、第３の格納方法と同様に、Group of Frames、およおび、PC frameの境界を示すsample groupをシグナルしてもよい。
　また、第１の格納方法の変形例と同様に、ISOBMFFの1 trackに、1 layerが格納される構成としてもよい。ここで、例えば、各trackに格納されているlayerが、layer 0およびlayer 1のどちらであるかを示すために、PC sample内のheaderでシグナルされるlayer識別子（例えば、図８のlayer_id）を、各trackのsample entryでシグナルしてもよい。または、PC sample内のheaderそのものを、各trackのsample entryに格納してもよい。
　ここで、第４の格納方法において、ISOBMFFに格納されるストリームはAVCやHEVC，SVC，SHEVCなどに準拠させることができ、その場合、これらのコーデックのrestricted schemeとして運用できる。例えば、sample entryは'resv'になり、SchemeTypeBoxのscheme_typeは'pcbs'になり、OriginalFormatBoxのdata_formatは用いられたコーデックによって、avc1やhev1などになる。
　そして、これらの新たに定義された複数のBoxは、ポストデコード処理に使用されるという位置づけになり、図４４に示すrinf/schi下にシグナルされる。さらに、このrinf/schiには、第１の格納方法で説明したPCHeaderBoxおよびLayerCompositionBoxも、図示するようにシグナルされる。
　なお、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種とした場合は、3次元メタデータをISOBMFFの1 trackに格納してもよい。この場合、3次元メタデータを格納するtrackのsample entryにも、geometry trackやtexture trackなどと同様のBoxおよび情報がシグナルされてもよい。
　また、例えば、texture video streamおよびgeometry video streamが各2 layerで構成され、個別trackに格納されている場合、各60pのvideo streamは30pのPC streamに相当する。これにより、クライアントは、（LayerCompositionBoxのnum_layer_composed × num_of_component）の値から、sampleのインターリーブ周期を識別することができる。
　なお、第４の格納方法における手法は、上述した第３の格納方法のみでなく、第１の格納方法および第２の格納方法において同一のcomponentの異なるlayerのパッキングの構成に対しても、適用可能である。特に、第２の格納方法において、図２３のＢを参照して説明したように、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングする手法において、geometry video streamとtexture video streamとを分割してtrackに格納することで、texture画像とgeometry画像との間に相関が少ないのに起因して、圧縮効率が悪化してしまうのを回避することができる。
　さらに、１つのgeometry trackに対して、例えば、bitrateの異なる複数のtexture trackが紐づくような構成としてもよい。
　図４５には、PCMultiStreamBoxのシンタックスの一例が示されている。
　例えば、isGeometryStream＝１である場合にはgeometry trackであることを示し、それ以外の場合にはtexture trackであることを示す。また、geometry trackであれば、紐づくtexture trackのtrack_idをシグナルする。
　このようなシグナリングによれば、クライアントはtrack referenceが示されていることで、任意の1 trackのTrackReferenceBoxをパースするだけで、どのtrackがgeometry trackか識別可能である。その後、クライアントは、geometry trackのPCMultiStreamBoxをパースし、全ての関連texture trackを識別することができる。つまり、クライアントは、最大でも2 trackをパースするだけで全体の構成を識別可能であり、特に複数のtexture trackが紐づくケースにおいて処理を簡易化することが可能となる。
　ここで、PCMultiStreamBoxのシンタックスの変形例として、bitrateの異なるtexture trackをまとめてtrack groupでシグナルし、図４６に示すように、texture_track_group_idでtexture track groupに紐づけてもよい。
　この場合、track groupは、図４７に示すように、PCTextureTrackGroupBoxを新たに定義し、rack_group_typeは'pctg'である。
　なお、texture_track_idで、PCTextureTrackGroupのtrack_group_idに紐づけてもよい。
　また、図４８に示すように、PCMultiStreamBoxに、textureがgeometryと同じtrackに格納されているか否かを示すisInGeometryStreamを追加してもよい。これにより、第１乃至第３の格納方法でも、シグナル可能なBoxとすることができる。
　さらに、PCMultiStreamBoxの代わりに、図４９に示すように、track groupで紐づくgeometry trackとtexture trackをシグナルしてもよい。
　そして、図５０に示すように、track groupは、PCStreamGroupBoxを新たに定義し、rack_group_typeは'pcgp'である。このとき、track_group_idが等しいpcgpを有するtrackは、一つのPC streamを構成する。例えば、isGeometry=0であれば、そのtrackはtexture trackであることを示し、isGeometry=1であれば、そのtrackはgeometry trackであることを示す。
　ここで、図５１には、第４の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
　＜DASHのシグナリング＞
　図５２および図５３を参照して、DASHのシグナリングについて説明する。
　例えば、texture画像およびgeometry画像と３次元情報メタデータとは、DASHのMPDでシグナルされる。そして、図５２に示すように、SupplementalProperty or EssentialProperty@schemeIdUri=="urn:mpeg:mpegI:pointcloud"をPC Component Descriptorと定義し、Representationが、texture画像およびgeometry画像のどちらであるかを示す。
　また、図５２に示すように、texture representationからgeometry representationへの紐づけをRepresentation@dependencyIdで行う。これは、presentation時に、geometry画像および３次元情報メタデータがないとtexture画像をマッピングできないという依存関係があるためである。
　これらのシグナリングによれば、クライアントがDASH配信コンテンツを取得する際、PC Component Descriptorを参照し、PC streamを構成するgeometry video streamとtexture video streamを適切に取得することができる。また、ネットワーク帯域幅に応じて、適切なtexture video streamの切り替えも可能となる。
　なお、geometry representationからtexture representationへの紐づけをRepresentation@associationIdで行ってもよい。
　この場合、図５３に示すように、associationTypeは"ptex"となる。geometryは単独で色のないpoint cloudのpresentationを可能とするため、associationIdを用いた紐づけが適切である。
　その他、上述した第１乃至第４の格納方法において、layer 0以外のtexture subsampleおよびgeometry subsample、または、layer 0以外のtexture sampleおよびgeometry subsampleを、layer 0のsubsample、または、sampleのSEIとして、全て格納してもよい。
　ここで、図５４には、SubSampleInformationBoxの概要が示されている。
　図５４に示すように、sample中の、連続した特定byte領域をsub-sampleと定義している。また、sub-sampleの定義は符号化コーデックごとに決まっており、例えばHEVCなら、NAL unitがsub-sampleとなる。また、SubSampleInformationBoxでは、sub-sampleごとに情報を付加することができる。
　また、図５５には、Sample Groupの概要が示されている。
　図５５に示すように、Sample To Group Boxのgrouping_typeは、紐づけられるSample Group Description Boxのgrouping_typeを示す。1 entryにつき、sample_countとgroup_description_indexがシグナルされる。そして、group_description_indexは、紐づくGroup Entryのindexを示し、sample_countは、そのGroup Entryに属するsample数を示す。
　＜システム構成＞
　図５６および図５７を参照して、本技術を適用したデータ生成装置およびデータ再生装置のシステム構成について説明する。
　図５６には、データ生成装置の構成例を示すブロック図が示されている。
　図５６に示すように、データ生成装置５１は、制御部６１およびファイル生成部６２を備えており、ファイル生成部６２は、データ入力部７１、データ符号化・生成部７２、MPD（Media Presentation Description）ファイル生成部７３、記録部７４、およびアップロード部７５を備えて構成される。そして、データ符号化・生成部７２は、前処理部７６、符号化部７７、およびセグメントファイル生成部７８を有している。
　例えば、前処理部７６は、上述の3D2D変換部２１（図１７または図３０）に対応し、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する処理を実行する。
　また、符号化部７７は、上述の符号化部２２（図１７）に対応し、geometry video streamおよびtexture video streamを符号化する処理を実行する。または、符号化部７７は、上述の符号化部２２Ａ（図３０）に対応し、packed PC画像を符号化する処理を実行する。
　また、セグメントファイル生成部７８は、上述のPC stream生成部２３およびファイル生成部２４（図１７または図３０）に対応し、PC streamを生成し、そのPC streamをISOBMFFに格納したPCファイルを生成する処理を実行する。
　図５７には、データ再生装置の構成例を示すブロック図が示されている。
　図５７に示すように、データ再生装置５２は、制御部８１および再生処理部８２を備えており、再生処理部８２は、MPDファイル取得部９１、MPDファイル処理部９２、セグメントファイル取得部９３、表示制御部９４、データ解析・復号部９５、および表示部９６を備えて構成さる。そして、データ解析・復号部９５は、セグメントファイル処理部９７、復号部９８、および表示情報生成部９９を有している。
　例えば、セグメントファイル処理部９７は、上述の抽出部３１（図１８）に対応し、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出する処理を実行する。または、セグメントファイル処理部９７は、上述の抽出部３１（図３１）に対応し、再生時刻に対応するpacked PC streamを抽出する処理を実行する。
　また、復号部９８は、上述の復号部３２（図１８）に対応し、geometry video streamおよびtexture video streamを、それぞれ個別に復号する処理を実行する。または、復号部９８は、上述の復号部３２Ａ（図３１）に対応し、packed PC streamを復号する処理を実行する。
　また、表示情報生成部９９は、2D3D変換部３３および表示処理部３４（図１８または図３１）に対応し、Point Cloudを構築しPoint Cloudをレンダリングして表示画像を表示させる。
　以上のように、本技術によれば、ISOBMFF格納に適したPC stream構造(PC sample)を定義し、PC streamをISOBMFFの1 trackに格納することができる。これにより、クライアントによる再生時、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC streamのデコード処理の実行を可能とし、通常再生時のstream内ランダムアクセスの発生を抑制することができる。
　また、第３の格納方法のように、PC sampleの定義を用いず、PC streamをISOBMFFの1 trackに格納することによっても、同様に、簡略化された処理で、PC streamのデコード処理の実行を可能とすることができる。
　さらに、第２の格納方法のように、PC streamのgeometry video streamおよびtexture video streamを1 streamにパッキングしてISOBMFFの1 trackに格納することができる。これにより、クライアントによる再生時、1 デコーダインスタンスでのPC streamのデコード処理の実行を可能にすることができる。
　また、第４の格納方法のように、PC streamをgeometry video streamとtexture video streamに分け、ISOBMFFの2 tracksに格納することができる。これにより、geometry video streamを格納するtrackとtexture video streamを格納するtrackの紐づけを効率的に行うことができる。従って、ネットワーク帯域に応じたPC stream画質の最適化するためのクライアントにおけるstream取得処理を容易に行うことができる。
　＜コンピュータの構成例＞
　次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
　図５８は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
　プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５や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)やスピーカ等で構成される。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
　また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
　さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
　また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
　また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
　なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
　なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
　＜構成の組み合わせ例＞
　なお、本技術は以下のような構成も取ることができる。
（１）
　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部
　を備える情報処理装置。
（２）
　前記第１の画像および前記第２の画像を符号化して、第１の画像ストリームおよび第２の画像ストリームを生成する符号化部
　をさらに備え、
　前記ファイル生成部は、前記第１の画像ストリームおよび前記第２の画像ストリームがそれぞれ復号された後に、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元構造として再構築されるのに必要な復号順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して前記ファイルを生成する
　上記（１）に記載の情報処理装置。
（３）
　前記符号化部は、前記第１の画像および前記第２の画像をnon-layered codingで符号化する
　上記（２）に記載の情報処理装置。
（４）
　前記３次元情報メタデータは、前記第１の画像および前記第２の画像を指し示す情報を含む
　上記（１）から（３）までのいずれかに記載の情報処理装置。
（５）
　前記３次元情報メタデータは、Group of Framesを示す情報を含む
　上記（１）から（４）までのいずれかに記載の情報処理装置。
（６）
　前記３次元情報メタデータは、同時刻に表示するlayer数およびcomponent数を示す情報を含む
　上記（１）から（５）までのいずれかに記載の情報処理装置。
（７）
　前記３次元情報メタデータは、前記３Ｄデータの前記３次元構造の構成要素ごとのコーデック情報を含む
　上記（１）から（６）までのいずれかに記載の情報処理装置。
（８）
　前記符号化部は、前記第１の画像および前記第２の画像をlayered codingで符号化する
　上記（２）に記載の情報処理装置。
（９）
　複数の画像を１つのパッキング画像にパッキングするパッキング処理部
　をさらに備え、
　前記ファイル生成部は、前記パッキング画像、前記３次元情報メタデータ、および、前記パッキングの方法を示すパッキング情報を前記ファイルに格納する
　上記（１）から（８）までのいずれかに記載の情報処理装置。
（１０）
　前記パッキング処理部は、同一のlayerの前記第１の画像どうし、および、同一のlayerの前記第２の画像どうしをパッキングする
　上記（９）に記載の情報処理装置。
（１１）
　前記パッキング処理部は、前記第１の画像と前記第２の画像との同一のlayerどうしをパッキングする
　上記（９）に記載の情報処理装置。
（１２）
　前記パッキング処理部は、前記第１の画像および前記第２の画像の全てのlayerをパッキングする
　上記（９）に記載の情報処理装置。
（１３）
　前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、ISOBMFF（ISO Base Media File Format）の1 sampleとして格納することで前記ファイルを生成する
　上記（１）から（１２）までのいずれかに記載の情報処理装置。
（１４）
　前記第１の画像および前記第２の画像のいずれか一方が前記３次元情報メタデータを含み、前記第１の画像および前記第２の画像で、それぞれが前記1 sampleとして格納される
　上記（１３）に記載の情報処理装置。
（１５）
　前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、異なるトラックに格納することで前記ファイルを生成する
　上記（１）から（１４）までのいずれかに記載の情報処理装置。
（１６）
　前記３次元情報メタデータは、前記トラックの間の関係性を示す情報を含む
　上記（１５）に記載の情報処理装置。
（１７）
　前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、ISOBMFFでシグナルされる
　上記（１）から（１６）までのいずれかに記載の情報処理装置。
（１８）
　前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、DASH（Dynamic Adaptive St reaming over HTTP）のMPD（Media Presentation Description）でシグナルされる
　上記（１）から（１６）までのいずれかに記載の情報処理装置。
（１９）
　情報処理装置が、
　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
　を含む情報処理方法。
（２０）
　情報処理装置のコンピュータに、
　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
　を含む情報処理を実行させるためのプログラム。
　なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　１１および１２　情報処理装置，　２１　3D2D変換部，　２２　符号化部，　２３　PC stream生成部，　２４　ファイル生成部，　３１　抽出部，　３２　復号部，　３３　2D3D変換部，　３４　表示処理部，　５１　データ生成装置，　５２　データ再生装置，　６１　制御部，　６２　ファイル生成部，　７１　データ入力部，　７２　データ符号化・生成部，　７３　MPDファイル生成部，　７４　記録部，　７５　アップロード部，　７６　前処理部，　７７　符号化部，　７８　セグメントファイル生成部，　８１　制御部，　８２　再生処理部，　９１　MPDファイル取得部，　９２　MPDファイル処理部，　９３　セグメントファイル取得部，　９４　表示制御部，　９５　データ解析・復号部，　９６　表示部，　９７　セグメントファイル処理部，　９８　復号部，　９９　表示情報生成部

Claims (20)

  1. 　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部
    　を備える情報処理装置。
  2. 　前記第１の画像および前記第２の画像を符号化して、第１の画像ストリームおよび第２の画像ストリームを生成する符号化部
    　をさらに備え、
    　前記ファイル生成部は、前記第１の画像ストリームおよび前記第２の画像ストリームがそれぞれ復号された後に、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元構造として再構築されるのに必要な復号順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して前記ファイルを生成する
    　請求項１に記載の情報処理装置。
  3. 　前記符号化部は、前記第１の画像および前記第２の画像をnon-layered codingで符号化する
    　請求項２に記載の情報処理装置。
  4. 　前記３次元情報メタデータは、前記第１の画像および前記第２の画像を指し示す情報を含む
    　請求項３に記載の情報処理装置。
  5. 　前記３次元情報メタデータは、Group of Framesを示す情報を含む
    　請求項３に記載の情報処理装置。
  6. 　前記３次元情報メタデータは、同時刻に表示するlayer数およびcomponent数を示す情報を含む
    　請求項３に記載の情報処理装置。
  7. 　前記３次元情報メタデータは、前記３Ｄデータの前記３次元構造の構成要素ごとのコーデック情報を含む
    　請求項３に記載の情報処理装置。
  8. 　前記符号化部は、前記第１の画像および前記第２の画像をlayered codingで符号化する
    　請求項２に記載の情報処理装置。
  9. 　複数の画像を１つのパッキング画像にパッキングするパッキング処理部
    　をさらに備え、
    　前記ファイル生成部は、前記パッキング画像、前記３次元情報メタデータ、および、前記パッキングの方法を示すパッキング情報を前記ファイルに格納する
    　請求項１に記載の情報処理装置。
  10. 　前記パッキング処理部は、同一のlayerの前記第１の画像どうし、および、同一のlayerの前記第２の画像どうしをパッキングする
    　請求項９に記載の情報処理装置。
  11. 　前記パッキング処理部は、前記第１の画像と前記第２の画像との同一のlayerどうしをパッキングする
    　請求項９に記載の情報処理装置。
  12. 　前記パッキング処理部は、前記第１の画像および前記第２の画像の全てのlayerをパッキングする
    　請求項９に記載の情報処理装置。
  13. 　前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、ISOBMFF（ISO Base Media File Format）の1 sampleとして格納することで前記ファイルを生成する
    　請求項１に記載の情報処理装置。
  14. 　前記第１の画像および前記第２の画像のいずれか一方が前記３次元情報メタデータを含み、前記第１の画像および前記第２の画像で、それぞれが前記1 sampleとして格納される
    　請求項１３に記載の情報処理装置。
  15. 　前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、異なるトラックに格納することで前記ファイルを生成する
    　請求項１に記載の情報処理装置。
  16. 　前記３次元情報メタデータは、前記トラックの間の関係性を示す情報を含む
    　請求項１５に記載の情報処理装置。
  17. 　前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、ISOBMFFでシグナルされる
    　請求項１５に記載の情報処理装置。
  18. 　前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、DASH（Dynamic Adaptive St reaming over HTTP）のMPD（Media Presentation Description）でシグナルされる
    　請求項１５に記載の情報処理装置。
  19. 　情報処理装置が、
    　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
    　を含む情報処理方法。
  20. 　情報処理装置のコンピュータに、
    　３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
    　を含む情報処理を実行させるためのプログラム。
PCT/JP2019/021191 2018-07-06 2019-05-29 情報処理装置および情報処理方法、並びにプログラム Ceased WO2020008758A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201980044256.3A CN112369016A (zh) 2018-07-06 2019-05-29 信息处理装置、信息处理方法和程序
KR1020207037126A KR20210025527A (ko) 2018-07-06 2019-05-29 정보 처리 장치 및 정보 처리 방법, 그리고 프로그램
US15/734,559 US11516453B2 (en) 2018-07-06 2019-05-29 Information processing apparatus, information processing method, and program for point cloud sample processing
JP2020528720A JP7310816B2 (ja) 2018-07-06 2019-05-29 情報処理装置および情報処理方法、並びにプログラム
EP19830286.1A EP3820147A4 (en) 2018-07-06 2019-05-29 Information processing device, information processing method, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-129332 2018-07-06
JP2018129332 2018-07-06

Publications (1)

Publication Number Publication Date
WO2020008758A1 true WO2020008758A1 (ja) 2020-01-09

Family

ID=69060629

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/021191 Ceased WO2020008758A1 (ja) 2018-07-06 2019-05-29 情報処理装置および情報処理方法、並びにプログラム

Country Status (7)

Country Link
US (1) US11516453B2 (ja)
EP (1) EP3820147A4 (ja)
JP (1) JP7310816B2 (ja)
KR (1) KR20210025527A (ja)
CN (1) CN112369016A (ja)
TW (1) TW202006667A (ja)
WO (1) WO2020008758A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021251173A1 (ja) * 2020-06-12 2021-12-16
JP2022500931A (ja) * 2018-09-14 2022-01-04 華為技術有限公司Huawei Technologies Co., Ltd. ポイントクラウドコーディングにおける改善された属性レイヤとシグナリング
JP2022501898A (ja) * 2018-09-18 2022-01-06 ヴィド スケール インコーポレイテッド ポイントクラウド圧縮ビットストリームフォーマットに対する方法および装置
EP3979644A1 (en) * 2020-10-02 2022-04-06 Koninklijke Philips N.V. A method and apparatus for encoding and decoding one or more views of a scene
WO2022075078A1 (ja) * 2020-10-06 2022-04-14 ソニーグループ株式会社 画像処理装置および方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX2021001377A (es) * 2018-08-08 2021-04-19 Panasonic Ip Corp America Metodo de codificacion de datos tridimensionales, metodo de decodificacion de datos tridimensionales, dispositivo de codificacion de datos tridimensionales y dispositivo de decodificacion de datos tridimensionales.
US11606576B2 (en) * 2018-10-08 2023-03-14 Samsung Electronics Co., Ltd. Method and apparatus for generating media file comprising 3-dimensional video content, and method and apparatus for replaying 3-dimensional video content
GB202001839D0 (en) * 2020-02-11 2020-03-25 V Nova Int Ltd Use of tiered hierarchical coding for point cloud compression
US12044779B2 (en) * 2020-12-08 2024-07-23 Argo AI, LLC Methods and system for analyzing dynamic lidar point cloud data
CN114298092B (zh) * 2021-12-14 2025-06-20 深圳市智慧海洋科技有限公司 声呐数据转化方法、装置、电子设备、存储介质及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011142586A (ja) 2010-01-08 2011-07-21 Sony Corp 画像処理装置、情報記録媒体、および画像処理方法、並びにプログラム
WO2017082076A1 (ja) * 2015-11-11 2017-05-18 ソニー株式会社 符号化装置および符号化方法、復号装置および復号方法
WO2017104115A1 (ja) * 2015-12-14 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置及び三次元データ復号装置
WO2018021069A1 (ja) * 2016-07-29 2018-02-01 ソニー株式会社 画像処理装置および画像処理方法
US20180268570A1 (en) * 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101258106B1 (ko) * 2008-09-07 2013-04-25 돌비 레버러토리즈 라이쎈싱 코오포레이션 크로마 정정 및/또는 체커보드 인터리브된 포맷의 ３ｄ 이미지들의 정정을 포함하는 인터리브된 데이터 세트들의 컨버젼
US10021377B2 (en) * 2009-07-27 2018-07-10 Koninklijke Philips N.V. Combining 3D video and auxiliary data that is provided when not reveived
US20110310235A1 (en) * 2009-12-28 2011-12-22 Taiji Sasaki Display device and method, recording medium, transmission device and method, and playback device and method
CN103907347B (zh) 2011-08-31 2018-01-30 诺基亚技术有限公司 多视图视频编码和解码
RU2667605C2 (ru) * 2013-05-10 2018-09-21 Конинклейке Филипс Н.В. Способ кодирования сигнала видеоданных для использования с многовидовым устройством визуализации
KR102076494B1 (ko) * 2014-01-20 2020-02-14 한국전자통신연구원 3차원 데이터 처리 장치 및 방법
US10389999B2 (en) * 2016-02-17 2019-08-20 Qualcomm Incorporated Storage of virtual reality video in media files
US10620441B2 (en) * 2016-12-14 2020-04-14 Qualcomm Incorporated Viewport-aware quality metric for 360-degree video
JP6171079B1 (ja) * 2016-12-22 2017-07-26 株式会社Cygames 不整合検出システム、複合現実システム、プログラム及び不整合検出方法
US11363248B2 (en) * 2017-03-17 2022-06-14 Lg Electronics Inc. Method and device for transmitting region information of 360-degree video
US11062738B2 (en) * 2017-03-23 2021-07-13 Qualcomm Incorporated Signalling of video content including sub-picture bitstreams for video coding
US10778993B2 (en) * 2017-06-23 2020-09-15 Mediatek Inc. Methods and apparatus for deriving composite tracks with track grouping
US10873733B2 (en) * 2017-06-23 2020-12-22 Mediatek Inc. Methods and apparatus for deriving composite tracks
WO2019008221A1 (en) * 2017-07-03 2019-01-10 Nokia Technologies Oy APPARATUS, METHOD, AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO
US20200120326A1 (en) * 2017-07-06 2020-04-16 Sharp Kabushiki Kaisha Systems and methods for signaling view information for virtual reality applications
JP7043755B2 (ja) * 2017-08-29 2022-03-30 ソニーグループ株式会社 情報処理装置、情報処理方法、プログラム、及び、移動体

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011142586A (ja) 2010-01-08 2011-07-21 Sony Corp 画像処理装置、情報記録媒体、および画像処理方法、並びにプログラム
WO2017082076A1 (ja) * 2015-11-11 2017-05-18 ソニー株式会社 符号化装置および符号化方法、復号装置および復号方法
WO2017104115A1 (ja) * 2015-12-14 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置及び三次元データ復号装置
WO2018021069A1 (ja) * 2016-07-29 2018-02-01 ソニー株式会社 画像処理装置および画像処理方法
US20180268570A1 (en) * 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
See also references of EP3820147A4
W17348, PCC TEST MODEL CATEGORY 2, vol. 1, January 2018 (2018-01-01)
W17374, FIRST WORKING DRAFT FOR PCC CATEGORY 2, January 2018 (2018-01-01)
W17675, FIRST IDEA ON SYSTEMS TECHNOLOGIES FOR POINT CLOUD CODING, April 2018 (2018-04-01)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11979605B2 (en) 2018-09-14 2024-05-07 Huawei Technologies Co., Ltd. Attribute layers and signaling in point cloud coding
JP2022500931A (ja) * 2018-09-14 2022-01-04 華為技術有限公司Huawei Technologies Co., Ltd. ポイントクラウドコーディングにおける改善された属性レイヤとシグナリング
JP2023123508A (ja) * 2018-09-14 2023-09-05 華為技術有限公司 ポイントクラウドコーディングにおける改善された属性レイヤとシグナリング
JP2022501898A (ja) * 2018-09-18 2022-01-06 ヴィド スケール インコーポレイテッド ポイントクラウド圧縮ビットストリームフォーマットに対する方法および装置
JP7460611B2 (ja) 2018-09-18 2024-04-02 ヴィド スケール インコーポレイテッド ポイントクラウド圧縮ビットストリームフォーマットに対する方法および装置
US12260597B2 (en) 2018-09-18 2025-03-25 Interdigital Vc Holdings, Inc. Methods and apparatus for point cloud compression bitstream format
EP4167573A4 (en) * 2020-06-12 2023-12-13 Sony Group Corporation DEVICE AND METHOD FOR PROCESSING INFORMATION
JPWO2021251173A1 (ja) * 2020-06-12 2021-12-16
JP7726209B2 (ja) 2020-06-12 2025-08-20 ソニーグループ株式会社 情報処理装置および方法
EP3979644A1 (en) * 2020-10-02 2022-04-06 Koninklijke Philips N.V. A method and apparatus for encoding and decoding one or more views of a scene
WO2022069388A1 (en) * 2020-10-02 2022-04-07 Koninklijke Philips N.V. A method and apparatus for encoding and decoding one or more views of a scene
WO2022075078A1 (ja) * 2020-10-06 2022-04-14 ソニーグループ株式会社 画像処理装置および方法
US12457363B2 (en) 2020-10-06 2025-10-28 Sony Group Corporation Image processing device and method

Also Published As

Publication number Publication date
US11516453B2 (en) 2022-11-29
JPWO2020008758A1 (ja) 2021-07-08
CN112369016A (zh) 2021-02-12
US20210235056A1 (en) 2021-07-29
KR20210025527A (ko) 2021-03-09
TW202006667A (zh) 2020-02-01
EP3820147A1 (en) 2021-05-12
JP7310816B2 (ja) 2023-07-19
EP3820147A4 (en) 2022-07-20

Similar Documents

Publication Publication Date Title
JP7310816B2 (ja) 情報処理装置および情報処理方法、並びにプログラム
CN114503587B (zh) 点云数据发送装置、点云数据发送方法、点云数据接收装置和点云数据接收方法
TWI679885B (zh) 用於產生媒體資料的方法及設備
KR102559862B1 (ko) 미디어 콘텐츠 전송을 위한 방법, 디바이스, 및 컴퓨터 프로그램
US20190373245A1 (en) 360 video transmission method, 360 video reception method, 360 video transmission device, and 360 video reception device
JP7439762B2 (ja) 情報処理装置および情報処理方法、並びにプログラム
US12131754B2 (en) Apparatus, a method and a computer program for video coding and decoding
KR102655630B1 (ko) 3차원 비디오 컨텐츠를 포함하는 미디어 파일을 생성하는 방법 및 장치 및 3차원 비디오 컨텐츠를 재생하는 방법 및 장치
US11638066B2 (en) Method, device and computer program for encapsulating media data into a media file
JP6037567B2 (ja) ２次元にも対応する立体映像フローのデコード方法
TWI699115B (zh) 用於視訊之改良式限制方案設計
JP7415936B2 (ja) 情報処理装置および情報処理方法
KR20200019881A (ko) 미디어 콘텐트를 전송하는 방법, 디바이스, 및 컴퓨터 프로그램
CN108605168A (zh) 在媒体文件中虚拟现实视频的存储
US11477489B2 (en) Apparatus, a method and a computer program for video coding and decoding
JP7602064B2 (ja) メディアファイル処理方法及びその装置
CN116325759A (zh) 用于处理媒体文件的方法及其设备
US11206386B2 (en) Information processing apparatus and information processing method
KR20160142626A (ko) 공통 홀로그래픽 데이터 포맷 및 부복호화 장치 및 방법
CN116406505A (zh) 媒体文件处理方法和装置
CN116210225A (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: 19830286

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2020528720

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE