WO2020261690A1 - 情報処理装置、情報処理方法、再生処理装置及び再生処理方法 - Google Patents

情報処理装置、情報処理方法、再生処理装置及び再生処理方法 Download PDF

Info

Publication number
WO2020261690A1
WO2020261690A1 PCT/JP2020/014888 JP2020014888W WO2020261690A1 WO 2020261690 A1 WO2020261690 A1 WO 2020261690A1 JP 2020014888 W JP2020014888 W JP 2020014888W WO 2020261690 A1 WO2020261690 A1 WO 2020261690A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
information
3dof
texture
file
Prior art date
Application number
PCT/JP2020/014888
Other languages
English (en)
French (fr)
Inventor
遼平 高橋
平林　光浩
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to US17/615,586 priority Critical patent/US20220247991A1/en
Priority to CN202080045603.7A priority patent/CN114009054A/zh
Publication of WO2020261690A1 publication Critical patent/WO2020261690A1/ja

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/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
    • 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/128—Adjusting depth or disparity
    • 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/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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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
    • H04N2013/0074—Stereoscopic image analysis
    • H04N2013/0085—Motion estimation from stereoscopic image signals

Definitions

  • the present invention relates to an information processing device, an information processing method, a reproduction processing device, and a reproduction processing method.
  • MPEG-DASH Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP
  • HTTP Hypertext Transfer Protocol
  • ISOBMFF International Organization for Standardization Base Media File Format
  • the spherical image which is an image obtained by projecting an image of 360 degrees in the horizontal direction and 180 degrees in the vertical direction onto the stereostructure, is reproduced by mapping the spherical image to the planar image. There is a video to do.
  • the spherical image is also called a 3DoF image
  • the spherical image is also called a projective plane image or a 3DoF (Degrees of Freedom) image.
  • MPEG-I OMAF Omnidirectional Media Format
  • the data that provides the "3DoF +" video viewing experience is called the "3DoF +" stream.
  • the "3DoF +" stream contains a texture layer, a depth layer depth layer, and "3DoF +" metadata as components.
  • a texture layer is a collection of texture patches for rendering a "3DoF +" video.
  • a depth layer is a set of depth patches for rendering a "3DoF +" image.
  • the "3DoF +" metadata includes viewpoint position information in which each patch can be seen.
  • the client device reproduces the "3DoF +" video by selecting and rendering the patch used for rendering the viewing video from the texture layer and the depth layer based on the "3DoF +" metadata.
  • the texture layer in the "3DoF +" stream has an area called a 3DoF area where 3DoF viewing is possible, and a "3DoF +" area where "3DoF +” viewing is possible by adding to the 3DoF area. Having such a texture layer makes it possible to render a 3DoF region in the texture layer of the "3DoF +" stream to generate a 3DoF image. That is, even a client device that does not have the ability to reproduce "3DoF +" video but has a 3DoF rendering function can be used to generate 3DoF video from the "3DoF +" stream.
  • the client device when rendering the 3DoF area in the "3DoF +" stream, the client device performs a process of rendering the entire "3DoF +" and then a process of outputting a 3DoF image viewed from a specific viewpoint position. Therefore, in reality, it is difficult for a client device having a 3DoF rendering function to reproduce a 3DoF video using a "3DoF +" stream, although it does not have the ability to reproduce the "3DoF +" video. Therefore, the viewing experience of the user is restricted.
  • the present disclosure provides an information processing device, an information processing method, a reproduction processing device, and a reproduction processing method capable of expanding the viewing experience of the user.
  • the atlas processing unit is limited to a reference two-dimensional image corresponding to each projection direction formed by projecting three-dimensional data from a predetermined viewpoint position in a plurality of projection directions and the predetermined viewpoint position.
  • Atlas identification information that associates a texture image that forms a complementary image for generating a moving 2D image based on a viewpoint position moved within a range from the reference 2D image with a depth image corresponding to the texture image, and
  • first post-decoding information indicating that the complementary image in the texture image is information in a "3DoF +" region.
  • the coding unit encodes the texture image and the depth image to generate the texture layer and the depth layer.
  • the file generation unit generates a file including the texture layer, the depth layer, the atlas identification information, and the post-decoding information.
  • Non-Patent Document 1 (above)
  • Non-Patent Document 2 “ISO / IEC 14496-15: 2017", Information technology. Coding of audio-visual objects.
  • Part15 Carriage of network abstraction layer (NAL) unit structure video in the ISO base media file format 2017-02
  • Non-Patent Document 3 "ISO / IEC 23090-2: 2019", Information technology.
  • Non-Patent Documents 1 to 3 and 8 the terms used in the File Structure described in Non-Patent Documents 1 to 3 and 8 and the "3DoF +" stream structure described in Non-Patent Documents 5 to 7 are directly described in the detailed description of the invention. Even if there is no description, it is within the scope of disclosure of this technology and shall meet the support requirements of the scope of claims. Similarly, technical terms such as Parsing, Syntax, and Semantics are also within the scope of the present technology even if they are not directly defined in the detailed description of the invention. And shall meet the support requirements of the claims. In addition, the present disclosure will be described according to the order of items shown below.
  • the "3DoF +" stream contains a texture layer, a depth layer and "3DoF +" metadata.
  • the "3DoF +” metadata specifically has camera parameter and atlas parameter list metadata.
  • the camera parameter is the viewpoint position information in which each patch can be seen.
  • the atlas parameter list metadata represents mapping information between the display position for each patch and the position on the codec picture.
  • a layer pair that is a pair of a corresponding texture layer and a depth layer is called an atlas.
  • the texture layer of the "3DoF +" stream includes the 3DoF area and the "3DoF +" area. Fine patches are stored in the "3DoF +" area, and each patch contains information used for an image from another angle of an image formed by rendering the 3DoF area.
  • the "3DoF +" stream is encoded by Multi-layer HEVC (High Efficiency Video Codec).
  • Multilayer HEVC is a coding method that includes a plurality of layers such as a low resolution layer and a high resolution layer in one stream.
  • the "3DoF +" metadata is stored in a bitstream as, for example, SEI (Supplemental Enhancement Information).
  • SEI Supplemental Enhancement Information
  • the bitstream is the data of the "3DoF +" image forming the "3DoF +” stream.
  • VPS Video Parameter Set
  • an atlas flag is added to each layer, so that the layer pairs constituting the atlas can be identified.
  • a reproduction processing device having a 3DoF rendering function but not having a reproduction ability of "3DoF +" video is referred to as a 3DoF reproduction processing device.
  • 3DoF regeneration processing devices There are several types of 3DoF regeneration processing devices. For example, there is a 3DoF playback processing device that can decode a "3DoF +" stream, but can perform 3DoF rendering due to restrictions on rendering ability and functions, but does not support rendering of "3DoF +" video. Further, for example, there is a 3DoF playback processing device such as OMAF ed.1 player that does not have any function of decoding and rendering a "3DoF +" stream.
  • the texture layer of the "3DoF +" stream includes the 3DoF area and the "3DoF +" area, it is conceivable that the 3DoF reproduction processing device performs rendering only in the 3DoF area of the texture layer of the "3DoF +" stream. .. If it is possible to perform such processing, the same "3DoF +" stream can be appropriately reproduced according to the reproduction ability even in the reproduction processing devices having different reproduction abilities, and each reproduction processing device has a reproduction ability. You don't have to prepare a stream. As a result, for example, the CDN (Content Delivery Network) storage of the distribution server at the time of distribution can be saved, and the content that can be played by the playback processing device can be increased.
  • the technical requirements for "3DoF +" in MPEG-I Phase 1b also require measures in this case.
  • the 3DoF compatible client device 2 when rendering the 3DoF area included in the "3DoF +" stream, the 3DoF compatible client device 2 renders once with "3DoF +", and then outputs only the 3DoF image viewed from a specific viewpoint position. Will be done. This means that it is difficult for the 3DoF-compatible client device 2 to process the "3DoF +" stream. That is, it is difficult to enjoy the above-mentioned merits in the conventional "3DoF +" content distribution system. Therefore, a distribution system capable of reproducing the "3DoF +" content distributed by the 3DoF reproduction processing device will be described below.
  • FIG. 1 is a system configuration diagram of an example of a distribution system.
  • the distribution system 100 includes a file generation device 1 which is an information processing device, a client device 2 which is a reproduction processing device, and a Web server 3.
  • the file generation device 1, the client device 2, and the Web server 3 are connected to the network 4. Then, the file generation device 1, the client device 2, and the Web server 3 can communicate with each other via the network 4.
  • the distribution system 100 may include a plurality of file generation devices 1 and a plurality of client devices 2, respectively.
  • the file generation device 1 generates a "3DoF +" stream, which is data that provides "3DoF +” video.
  • the file generation device 1 uploads the generated "3DoF +" stream to the Web server 3.
  • the configuration in which the Web server 3 provides the "3DoF +" stream to the client device 2 will be described, but the distribution system 100 can adopt another configuration.
  • the file generation device 1 may include the function of the Web server 3, store the generated "3DoF +" stream in its own device, and provide it to the client device 2.
  • the Web server 3 holds the "3DoF +" stream uploaded from the file generation device 1. Then, the Web server 3 provides a designated "3DoF +" stream according to the request from the client device 2.
  • the client device 2 transmits a transmission request for the "3DoF +" stream to the Web server 3. Then, the client device 2 acquires the "3DoF +" stream specified in the transmission request from the Web server 3. Then, the client device 2 decodes the "3DoF +" stream to generate an image, and displays the image on a display device such as a monitor.
  • FIG. 2 is a block diagram of the file generator.
  • the file generation device 1 which is an information processing device has a generation processing unit 10 and a control unit 11.
  • the control unit 11 executes a process related to the control of the generation processing unit 10.
  • the control unit 11 performs integrated control such as the operation timing of each unit of the generation processing unit 10.
  • the generation processing unit 10 includes a data input unit 101, an atlas processing unit 102, an encoding unit 103, a bitstream generation unit 104, a file generation unit 105, and a transmission unit 106.
  • the data input unit 101 accepts inputs such as "3DoF +" video image data and "3DoF +” metadata.
  • the "3DoF +" metadata includes information about the viewpoint such as the time, position information and viewpoint position information of the image.
  • the data input unit 101 outputs the acquired image data to the atlas processing unit 102. Further, the data input unit 101 outputs meta information to the coding unit 103.
  • the atlas processing unit 102 receives the input of the image data of the "3DoF +" video from the data input unit 101. Then, the atlas processing unit 102 generates texture image data and depth image data from the image data.
  • the texture image is an image corresponding to each projection direction formed by projecting three-dimensional data from a predetermined viewpoint position in a plurality of projection directions in the "3DoF +" image.
  • the depth image is an image showing the position of each point on the texture image in the three-dimensional space.
  • FIG. 3 is a diagram showing a texture image and a depth image.
  • Image 301 in FIG. 3 is a texture image.
  • the region 311 is a 3DoF region
  • the region 312 is a "3DoF +" region.
  • the "3DoF +" region includes a patch that is a correction image for generating an image viewed from an angle slightly deviated from the viewpoint position in the 3DoF region.
  • the image 302 is a depth image.
  • the atlas processing unit 102 generates an atlas by combining the corresponding texture image data and the depth image data.
  • the atlas processing unit 102 generates an atlas arrangement parameter for displaying the atlas as a spherical image.
  • an atlas ID which is a pair identifier of the texture image and the depth image constituting the atlas, is generated and assigned to each atlas. Further, the atlas processing unit 102 generates post-decoding information which is metadata for creating a spherical image from two-dimensional data.
  • FIG. 4 is a diagram for explaining the details of the texture image.
  • the texture image 330 has a 3DoF region 331 and a "3DoF +" region 332.
  • the texture image 330 includes an image that is the source of the spherical image viewed from the viewpoint o, the viewpoint a, the viewpoint b, and the viewpoint c in the coordinate space 340.
  • the 3DoF area 331 the image 333 at the position of the viewpoint o, which is the projected picture of the basic camera, is stored.
  • the viewpoint position by this basic camera corresponds to an example of "predetermined viewpoint position”.
  • the image 333 corresponds to an example of the "reference two-dimensional image".
  • a complement for generating a projected picture of an arbitrary camera position within a limited range such as an image 334 at the position of the viewpoint a, an image 335 at the position of the viewpoint b, and an image 336 at the position of the viewpoint c.
  • the patch that is an image is stored.
  • the viewpoint position by an arbitrary camera within this limited range corresponds to an example of "viewpoint position moved from a predetermined viewpoint position”.
  • Images 334 to 336 correspond to an example of a "moving two-dimensional image”.
  • the depth image the depth map corresponding to the information of each projected picture of the texture image is stored.
  • the atlas processing unit 102 generates post-decoding information for generating images from each viewpoint position, that is, images 333 to 336 from viewpoints o and a to c from the texture image 330.
  • the atlas processing unit 102 includes information on whether each image is an image in the 3DoF region of the texture image or an image generated using the “3DoF +” region of the texture image in the post-decoding information. After that, the atlas processing unit 102 outputs "3DoF +" metadata including the atlas arrangement parameter, the atlas ID, and post-decoding information to the coding unit 103 together with the atlas.
  • the coding unit 103 receives the atlas input from the atlas processing unit 102. Further, the coding unit 103 receives the input of "3DoF +" metadata including the atlas arrangement parameter, the atlas ID, and the post-decoding information from the data input unit 101. Next, the coding unit 103 encodes the atlas and the "3DoF +" metadata with multilayer HEVC. The coding unit 103 generates a texture layer by encoding the texture image. Further, the coding unit 103 generates a depth layer by encoding the depth image. That is, the encoded atlas includes a texture layer and a depth layer. Then, the coding unit 103 outputs the coded atlas and "3DoF +" metadata to the bitstream generation unit 104.
  • the bitstream generation unit 104 receives the input of the encoded atlas and the "3DoF +" metadata from the encoding unit 103. Then, the bitstream generation unit 104 generates a bitstream by arranging the atlases in chronological order and combining the corresponding "3DoF +" metadata.
  • FIG. 5 is a diagram showing an example of a video stream.
  • the atlas which is a set of the texture layer 303 and the depth layer 304, is stored in the video stream in chronological order.
  • the unit of data that constitutes one atlas included in the video stream is called an access unit (AU). Then, the bitstream generation unit 104 outputs the generated bitstream to the file generation unit 105.
  • AU access unit
  • the file generation unit 105 receives the bitstream input from the bitstream generation unit 104. Then, the file generation unit 105 creates a file by storing the acquired bit stream in the ISOBMFF file for each segment, and generates a segment file of the bit stream.
  • the storage in the ISOBMFF file will be described below.
  • the file generation unit 105 stores information indicating that the texture layer and depth layer constituting the atlas are stored in one track in the ISOBMFF file. Specifically, the file generation unit 105 is a pair identifier of the texture and depth layer constituting the atlas by extending the Operating Point Information sample group (oinf) and storing the scalability_mask and dimension_identifier in the same manner as the VPS of HEVC. Define the atlas ID.
  • FIG. 6 is a diagram showing an extended example of scalability_mask and dimension_identifier. For example, the file generation unit 105 assigns the fifth bit of the scalability_mask to the atlas ID as shown in FIG.
  • the file generation unit 105 associates the atlas ID with the layer ID assigned to each texture layer and each depth layer when storing the bit stream in the ISOBMFF file.
  • FIG. 7 is a diagram for explaining the association of the atlas ID.
  • L-HEVC storage see ISO / IEC 14496-15
  • Each bitstream access unit is treated as a sampleEntry in the ISOBMFF file.
  • the file generator 105 sends "3DoF +" metadata as part of the stream when encoded in multimedia HEVC.
  • the file generation unit 105 groups the Samples and uses the sample groups in the ISOBMFF file to associate the metadata for each group.
  • the file generation unit 105 stores the sample group in Moov of the ISOBMFF file.
  • FIG. 8 is a diagram for explaining a sample group.
  • each sample group is defined by the SampleTableBox shown in FIG.
  • the grouping_Type of the Sample To Group Box indicates the Grouping_Type of the associated Sample Group Description Box.
  • sample_count and Group_description_index are registered for each entry.
  • group_description_index indicates the index of the associated GroupEntry.
  • sample_count indicates the number of samples belonging to the GroupEntry.
  • the file generation unit 105 generates the operating points information (oinf) sample group 305 and the layer information (linf) sample group 306 shown in FIG. 7 as sample groups.
  • FIG. 9 is a diagram showing an example of an inf sample group.
  • the file generation unit 105 registers the layers included in the operating point and the profile, level, and tier of each layer in the oinf sample group by the syntax 321. Further, the file generation unit 105 registers the information included in the operating point such as the maximum and minimum information of width and height, the related information of frame rate and bit rate, etc. in the oinf sample group by the syntax 322. Further, the file generation unit 105 registers the dependency and type information of the non-base layer in the oinf sample group by the syntax 323.
  • the file generation unit 105 uses the scalability_mask and the dimention_identifier shown in FIG. 6 to represent the types.
  • the file generation unit 105 stores the atlas ID as this type. That is, the file generation unit 105 stores the atlas ID in the oinf sample group represented by sgpd'oinf'. In this way, the inf sample group 305 stores information that collects Samples with the same attributes.
  • the file generation unit 105 associates the atlas ID with the layer ID in the inf sample group, and associates each atlas ID with the texture layer and the depth layer as shown in FIG. 7.
  • the atlas ID of “0” is associated with the texture layer having the layer ID “0” and the depth layer having the layer ID “1”.
  • the atlas ID of "1” is associated with the texture layer having the layer ID of "2" and the depth layer having the layer ID of "3".
  • the client device 2 can grasp the texture layer and the depth layer before decoding the ES. That is, the client device 2 can select and decode a layer that can be rendered by its own device, and can reduce the processing overhead. For example, the client device 2 which can decode the "3DoF +" stream and can perform 3DoF rendering but does not support "3DoF +" rendering can easily select the texture layer.
  • the file generation unit 105 stores the layer ID of the layer included in the track and the information indicating which sublayer among the layers indicated by the layer ID is included in the linf sample group 306.
  • FIG. 10 is a diagram showing an example of the linf sample group.
  • layer_id represents a layer ID, and this value corresponds to nuh_layer_id in each Sample.
  • the file generation unit 105 stores the post-decoding information, which is metadata for creating a spherical image from the two-dimensional data, in the ISOBMFF file.
  • the client device 2 can perform "3DoF +" or 3DoF rendering.
  • the file generation unit 105 stores post-decoding information as shown in FIG.
  • FIG. 11 is a diagram for explaining the storage of post-decoding information.
  • the file generation unit 105 may define a new flag indicating that the stream is a "3DoF +" stream and store it in the SampleEntry.
  • the file generation unit 105 defines the ProjectedOmniVideoForParallaxBox as a new Box 342 having post-decoding information for each viewpoint position in the Scheme Information Box, for example.
  • FIG. 12 is a diagram showing an example of the syntax of ProjectedOmniVideoForParallaxBox.
  • the file generation unit 105 stores the ProjectionInfoBox in the ProjectedOmniVideoForParallaxBox for registering the post-decoding information for the number of viewpoint positions.
  • the post-decoding information indicating that the image uses the "3DoF +" area corresponds to an example of "first post-decoding information”
  • the ProjectionInfoBox that stores the post-decoding information is an example of "first Box”. It hits.
  • the post-decoding information indicating that the image is in the 3DoF region corresponds to an example of "second post-decoding information”
  • the ProjectionInfoBox that stores the post-decoding information corresponds to an example of "second box”.
  • FIG. 13 is a diagram showing an example of the syntax of Projection InfoBox.
  • FIG. 14 is a diagram showing an example of the syntax of CameraPosStruct, DepthQuantizationStruct, ProjectionFormatStruct, RotationStruct and RefionWisePackingStruct in ProjectionInfoBox.
  • ProjectionInfoBox calls CameraPosStruct, DepthQuantizationStruct, ProjectionFormatStruct, RotationStruct and RegionWisePackingStruct represented by the syntaxes 351 to 355 shown in FIG.
  • the file generation unit 105 newly defines CameraPosStruct and DepthQuantizationStruct. CameraPosStruct stores the viewpoint position. ViewpointPosStruct may be used as CameraPosStruct. DepthQuantizationStruct stores depth quantization parameters.
  • the file generation unit 105 extends the Projection_type in the ProjectionFormatStruct so as to include the Perspective projection as shown in Table 357.
  • RegionWisePackingStruct calls RectRegionPacking, which is represented by syntax 356.
  • RegionWisePackingStruct stores atlas patch location information. That is, RegionWisePackingStruct is information indicating which texture layer each patch is contained in.
  • the file generation unit 105 adds a flag indicating whether ProjectionFormatStruct () and DepthQuantizationStruct () are the same between viewpoints, and if they are the same, registers them outside the loop of num_cameras to bit them. It is also possible to reduce the number.
  • the file generation unit 105 may generate the ProjectionInfoBox and the RegionWisePackingStruct as shown in FIG.
  • FIG. 15 is a diagram showing another example of the syntax of ProjectionInfoBox and RegionWisePackingStruct.
  • RegionWisePackingStruct shown by syntax 362 is called.
  • the atlas ID can be written at a predetermined position on a specific texture layer by using unsigned_int (8) atlas_id.
  • FIG. 16 is a diagram showing an example of the syntax of the Projection InfoBox extended so as to indicate the viewpoint position where 3DoF rendering is possible.
  • the client device 2 can confirm which viewpoint position among the viewpoint positions having the value of num_cameras can be rendered by 3DoF by this ProjectionInfoBox. As a result, 3DoF rendering is possible, but the client device 2 that does not support "3DoF +" rendering can render the 3DoF region of the "3DoF +" stream.
  • the file generation unit 105 outputs an ISOBMFF file storing the post-decoding information at each viewpoint position and the atlas ID associated with the layer ID by the Projection InfoBox described above to the transmission unit 106.
  • the transmission unit 106 receives the input of the ISOBMFF file storing the post-decoding information at each viewpoint position and the atlas ID associated with the layer ID from the file generation unit 105 by the ProjectionInfoBox. Then, the transmission unit 106 transmits the acquired ISOBMFF file to the Web server 3 and uploads it.
  • FIG. 17 is a block diagram of the client device. Further, FIG. 18 is a block diagram showing details of a file processing unit, a decoding processing unit, and a display information generation unit.
  • the client device 2 has a reproduction processing unit 20 and a control unit 21.
  • the control unit 21 controls the operation of each unit of the reproduction processing unit 20.
  • the control unit 21 comprehensively controls the operation timing of each unit of the reproduction processing unit 20.
  • the reproduction processing unit 20 includes a file acquisition unit 201, a file processing unit 202, a decoding processing unit 203, a display information generation unit 204, and a display unit 205.
  • the file acquisition unit 201 acquires an ISOBMFF file in which a scene description of 6DoF content to be displayed by accessing the Web server 3 is stored. Then, the file acquisition unit 201 outputs the ISOBMFF file in which the scene description is stored to the file processing unit 202.
  • the file acquisition unit 201 acquires the ISOBMFF file in which the "3DoF +" stream to be displayed by accessing the Web server 3 is stored. Then, the file acquisition unit 201 outputs the ISOBMFF file in which the "3DoF +" stream is stored to the file processing unit 202.
  • the file processing unit 202 has an extraction unit 220.
  • the file processing unit 202 receives the input of the ISOBMFF file in which the "3DoF +" stream is stored from the file acquisition unit 201. Then, the extraction unit 220 of the file processing unit 202 parses the ISOBMFF file and extracts the bitstream data. After that, the extraction unit 220 outputs the bitstream data to the decoding processing unit 203.
  • the file processing unit 202 determines whether or not the content stored in the track is a "3DoF +" stream by parsing the acquired ISOBMFF file. For example, the file processing unit 202 confirms the scheme_type of the SchemeTyepBox in FIG. 11 and determines whether or not it is a “3DoF +” stream. Then, when the decoding processing unit 203 does not support decoding of the "3DoF +" stream, the file processing unit 202 notifies an error if the content stored in the track is a "3DoF +" stream and cancels the processing.
  • the file processing unit 202 can perform 3DoF rendering. Get the position. Then, the file processing unit 202 instructs the decoding processing unit 203 to decode the texture layer, and transmits the viewpoint position capable of 3DoF rendering and the post-decoding information of the viewpoint position.
  • the decoding processing unit 203 has a plurality of decoders 230.
  • the decoding processing unit 203 receives the input of the bitstream data from the file processing unit 202. Then, the decoding processing unit 203 performs decoding processing on the bitstream data acquired by using the decoder 230. After that, the decoding processing unit 203 outputs the decoded bit stream data to the display information generation unit 204.
  • the decoding processing unit 203 receives an instruction for decoding the texture layer from the decoding processing unit 203. Further, the decoding processing unit 203 receives the viewpoint position capable of 3DoF rendering and the post-decoding information of the viewpoint position. Then, the decoding processing unit 203 decodes the texture layer of the “3DoF +” stream. After that, the decoding processing unit 203 outputs the decoded texture layer, the viewpoint position capable of 3DoF rendering, and the post-decoding information of the viewpoint position to the display information generation unit 204.
  • the display information generation unit 204 has an atlas disassembly unit 241 and a display processing unit 242.
  • the display information generation unit 204 receives the input of the decoded bit stream from the decoding processing unit 203. Then, the atlas decomposition unit 241 of the display information generation unit 204 decomposes the texture layer and the depth layer of each decoded atlas. Then, the atlas disassembly unit 241 outputs the disassembled atlas to the display processing unit 242.
  • the display information generation unit 204 inputs the decoded texture layer, the viewpoint position capable of 3DoF rendering, and the post-decoding information of the viewpoint position to the decoding processing unit 203. Receive from. Then, the atlas decomposition unit 241 outputs the decoded texture layer, the viewpoint position capable of 3DoF rendering, and the post-decoding information of the viewpoint position to the display processing unit 242.
  • the display processing unit 242 receives the input of the disassembled atlas from the atlas disassembly unit 241. Further, the display processing unit 242 receives inputs of the viewpoint position and the line-of-sight direction from an input device (not shown). Then, the display processing unit 242 renders "3DoF +" according to the input viewpoint position and line-of-sight direction, and generates a "3DoF +" image for display. After that, the display processing unit 242 supplies the generated "3DoF +" image for display to the display unit 207.
  • the display processing unit 242 receives the input of the coded texture layer, the viewpoint position capable of 3DoF rendering, and the post-decoding information of the viewpoint position from the atlas decomposition unit 241. .. Further, the display processing unit 242 receives inputs of the viewpoint position and the line-of-sight direction from an input device (not shown). Then, the display processing unit 242 acquires data from the 3DoF region of the texture layer corresponding to the input viewpoint position, performs 3DoF rendering according to the line-of-sight direction, and generates a 3DoF image for display. After that, the display processing unit 242 supplies the generated 3DoF image for display to the display unit 207.
  • the display unit 205 has a display device such as a monitor.
  • the display unit 205 receives the input of the display image generated by the display information generation unit 204. Then, the display unit 205 causes the display device to display the acquired image for display.
  • FIG. 19 is a flowchart of a file generation process by the file generation device according to the first embodiment.
  • the atlas processing unit 102 receives input of "3DoF +" video image data and "3DoF +" metadata from the data input unit 101. Then, the atlas processing unit 102 generates an atlas and an atlas arrangement parameter from the image data of the “3DoF +” video and the “3DoF +” metadata (step S101). In addition, the atlas processing unit 102 generates atlas ID and post-decoding information. Then, the atlas processing unit 102 outputs the atlas, and "3DoF +" metadata including the atlas ID, the post-decoding information, and the atlas arrangement parameter to the coding unit 103.
  • the coding unit 103 encodes the atlas and "3DoF +" metadata including the atlas ID, post-decoding information, and atlas placement parameters, and outputs the metadata to the bitstream generation unit 104.
  • the bitstream generation unit 104 generates a "3DoF +" bitstream using the encoded atlas and "3DoF +” metadata (step S102). After that, the encoding unit 103 outputs the generated bit stream to the file generation unit 105.
  • the file generation unit 105 stores the information for associating the atlas ID and the layer ID, the post-decoding information for each viewpoint position, and the bit stream in the ISOBMFF file (step S103). After that, the file generation unit 105 outputs the ISOBMFF file to the transmission unit 106. The transmission unit 106 outputs the ISOBMFF file generated by the file generation unit 105 to the Web server 3.
  • FIG. 20 is a flowchart of the reproduction process executed by the client device according to the first embodiment.
  • the decoding processing unit 203 can decode the "3DoF +" stream.
  • the file processing unit 202 acquires the ISOBMFF file corresponding to the "3DoF +" stream to be played back via the file acquisition unit 201 from the Web server 3. Next, the file processing unit 202 determines whether or not the display information generation unit 204 of the own device supports "3DoF +" rendering (step S201).
  • the file processing unit 202 parses the ISOBMFF file and displays the post-decoding information of 3DoF and "3DoF +". Acquire (step S202). Further, the file processing unit 202 extracts the bit stream of "3DoF +" from the ISOBMFF file. Then, the file processing unit 202 outputs the extracted "3DoF +" bit stream and the post-decoding information of 3DoF and "3DoF +" to the decoding processing unit 203.
  • the decoding processing unit 203 receives the input of the bit stream of "3DoF +" and the post-decoding information of 3DoF and "3DoF +" from the file processing unit 202. Then, the decoding processing unit 203 decodes the bit stream of "3DoF +" (step S203). After that, the decoding processing unit 203 outputs the decoded bitstream data and the post-decoding information to the display information generation unit 204.
  • the display information generation unit 204 receives input of bitstream data and post-decoding information of 3DoF and "3DoF +" from the decoding processing unit 203. Further, the display information generation unit 204 receives inputs of the viewpoint position and the line-of-sight direction from the input device. And. The display information generation unit 204 executes "3DoF +" rendering using the post-decoding information, the viewpoint position, and the information in the line-of-sight direction to generate a "3DoF +" image for display (step S204). After that, the display information generation unit 204 executes a viewing process of transmitting a "3DoF +" image and displaying it on the display unit 205.
  • the file processing unit 202 parses the ISOBMFF file and post-decoding information of 3DoF. (Step S205). Further, the file processing unit 202 extracts the bit stream of "3DoF +" from the ISOBMFF file. Then, the file processing unit 202 outputs the extracted “3DoF +” bit stream and the post-decoding information of 3DoF to the decoding processing unit 203, and instructs the encoding of the texture layer.
  • the decoding processing unit 203 receives the input of the "3DoF +" bit stream and the 3DoF post-decoding information from the file processing unit 202. Then, the decoding processing unit 203 decodes the portion of the bit stream of “3DoF +” used for 3DoF rendering (step S206). That is, the decoding processing unit 203 decodes the texture layer of the “3DoF +” bitstream. After that, the decoding processing unit 203 outputs the decoded bitstream data and the 3DoF post-decoding information to the display information generation unit 204.
  • the display information generation unit 204 receives input of bitstream data and 3DoF post-decoding information from the decoding processing unit 203. Further, the display information generation unit 204 receives inputs of the viewpoint position and the line-of-sight direction from the input device. And. The display information generation unit 204 executes 3DoF rendering using the post-decoding information, the viewpoint position, and the information in the line-of-sight direction to generate a 3DoF image for display (step S207). After that, the display information generation unit 204 executes a viewing process of transmitting a 3DoF image and displaying it on the display unit 205.
  • the file generation device stores information indicating that the atlas having the texture layer and the depth layer is stored in the ISOBMFF file. Further, the file generation device stores information on whether or not the stored content is a "3DoF +" stream and post-decoding information for each viewpoint position in the ISOBMFF file. The post-decoding information stores information representing a viewpoint position capable of 3DoF rendering.
  • the client device can determine whether or not it is a "3DoF +" stream, and can easily acquire layer data corresponding to the capability of the own device. Further, if it does not support "3DoF +" rendering, the client device can generate a display image by 3DoF rendering. Therefore, it is possible to provide and display an image according to the display processing capacity of the client device, and it is possible to expand the viewing experience of the user.
  • FIG. 21 is a diagram showing an example of an ISOBMFF file according to a modified example of the first embodiment.
  • the file generation device stores the post-coding information in the 3DoF area and the post-coding information in the "3DoF +" area in different boxes. As a result, even when the texture layer is reproducible and does not support decoding of the "3DoF +" stream, if the file generation device can ignore the depth layer, decoding and rendering can be performed by limiting to the 3DoF area.
  • the file generation device is different from the first embodiment in that the texture layer and the depth layer are stored in separate tracks.
  • the file generation device is also represented by the block diagram of FIG. In the following description, the description of the operation of each part similar to that of the first embodiment may be omitted.
  • the file generation unit 105 stores the texture layer and the depth layer in separate tracks by using the technology of L-HEVC storage.
  • FIG. 22 is a diagram showing an example of the ISOBMFFF file according to the second embodiment.
  • the file processing unit 202 of the client device 2 reproduces the "3DoF +" video using both the texture layer track and the depth layer track when the "3DoF +" stream can be decoded and rendered.
  • the file processing unit 202 refers to the povp stored in the schi in the texture layer track of the box 401 to acquire the post-decoding information in the “3DoF +” “region.
  • the file processing unit 202 reproduces the 3DoF video by using the post-decoding information of the 3DoF area and the 3DoF area stored in the texture layer track.
  • the file generation device stores the texture layer and the depth layer in separate tracks. As a result, even a client device that does not support decoding of the "3DoF +" stream can reproduce the 3DoF spherical image using the track of the texture layer.
  • the file generation unit 105 of the file generation device 1 newly defines a schema_type indicating a reference of povp stored in schi in the depth layer track when performing "3DoF +" rendering. Then, the file generation unit 105 stores the newly defined schema_type as the schema_type of the CompatibleSchemeTypeBox in the texture layer track.
  • the file processing unit 202 of the client device 2 reproduces the "3DoF +" video using both the texture layer track and the depth layer track when the "3DoF +" stream can be decoded and rendered.
  • the file processing unit 202 refers to the sheme_type of the CompatibleSchemeTypeBox in the texture layer track and confirms the instruction to refer to the povp stored in the schi in the depth layer track. Then, the file processing unit 202 refers to the povp stored in the schi in the depth layer track, and acquires the post-decoding information in the "3DoF +" area.
  • the client device refers to the prop stored in schi in the depth layer track to acquire the post-decoding information in the "3DoF +" area, and obtains "3DoF +". Render. This makes it possible to satisfy the profile specified in OMAF ed.1.
  • the file generation device is different from the second embodiment in that the “3DoF +” area and the 3DoF area of the texture layer are divided and individually stored in one track.
  • the file generation device is also represented by the block diagram of FIG. In the following description, the description of the operation of each part similar to that of the first and second embodiments may be omitted.
  • the file generation unit 105 divides the "3DoF +" area and the 3DoF area of the texture layer. Further, the file generation unit 105 divides the area corresponding to the "3DoF +" area of the texture layer in the depth layer and the area corresponding to the 3DoF area.
  • the region corresponding to the "3DoF +" region of the texture layer and the region corresponding to the 3DoF region in the depth layer are referred to as "the" 3DoF + "region of the depth layer” and "the 3DoF region of the depth layer", respectively.
  • the file generation unit 105 associates the "3DoF +" area and the 3DoF area of the texture layer with the Track reference. In addition, the file generation unit 105 associates the "3DoF +" area and the 3DoF area of the depth layer with the Track reference.
  • FIG. 23 is a diagram showing an example of the ISOBMFFF file according to the third embodiment.
  • the file generation unit 105 stores the division information of each layer in the sub-picture track grouping, which is another track group 510.
  • the file generation unit 105 may store the division information of each layer by the mechanism of tile base track / tile track.
  • the file generation unit 105 registers a list of base tracks, which are the original tracks, in the sub-picture track grouping. For example, when the texture layer tracks of tracks 501 and 503 are used as base tracks, the file generation unit 105 registers the information of the texture layer tracks of tracks 501 and 503 in the sub-picture track grouping.
  • the file processing unit 202 of the client device 2 can decode and render the "3DoF +" stream, it refers to the sub-picture track grouping to acquire the division information of each layer and specify the corresponding track. Then, the file processing unit 202 reproduces the "3DoF +" video by using the texture layer track and the depth layer track in the "3DoF +" area and the 3DoF area.
  • the depth layer is also divided into a "3DoF +" area and a 3DoF area, but the file generation unit 105 may combine the depth layers into one track without dividing each area.
  • the file generation unit 105 may combine the "3DoF +" area and the 3DoF area of the depth layer and the "3DoF +” area of the texture layer into one track.
  • the file generation unit 105 stores two ProjectionInfoBoxes, one for the texture layer and the other for the depth layer, in the track that combines the “3DoF +” area and the 3DoF area of the depth layer and the “3DoF +” area of the texture layer.
  • the file generation unit 105 can also divide the "3DoF +" area into each patch group constituting each viewpoint position and store them individually in the track. In this case, the file generation unit 105 can store the ViewingSpaceBox in each track and register the movable range of the viewpoint at the time of stream viewing stored in the track.
  • the file generation device divides the "3DoF +" area and the 3DoF area of the texture layer and stores them individually in one track. As a result, even a client device that does not support decoding of the "3DoF +" stream can reproduce the 3DoF spherical image using the track that stores the 3DoF area of the texture layer. In addition, it is possible to satisfy the profile specified in OMAF ed.1.
  • FIG. 24 is a diagram showing an example of the syntax of sub-picture track grouping according to the modified example (1) of the third embodiment.
  • the file generation unit 105 stores the ThreeDoFCompatibleBox () indicating that the stored stream is the 3DoF area of the texture layer in the sub-picture track grouping.
  • ThreeDoFCompatibleBox () is empty, indicating that the stream stored in the track in which this ThreeDoFCompatibleBox () exists is the 3DoF region of the texture layer.
  • the stream stored by the track is the 3DoF area of the texture layer by using ThreeDoFCompatibleBox (), but the file generation unit 105 defines a new field and the same applies to the field. Information may be stored.
  • the coding unit 103 encodes using the multilayer HEVC, but uses HEVC / AVC (Advanced Video Coding) to perform the texture layer and the depth layer. It is also possible to encode. This also applies to the second embodiment and its modifications.
  • the "3DoF +" metadata for each stream is represented as timed metadata, stored in a separate track, and linked to the track storing the texture layer and depth layer by track reference.
  • the file generation unit 105 stores the identification information of the texture layer and the depth layer, and the association information of the layer pairs constituting the atlas by expanding the ISOBMFF / Elementary Stream (SEI). As a result, the information stored by oinf / oref / sbas in L-HEVC storage can be applied to HEVC / AVC.
  • the file generation unit 105 can store other information in HEVC / AVC as well as in L-HEVC storage.
  • the file generation unit 105 can also use a Matroska Media Container having the format shown in FIG. 25.
  • FIG. 25 is a diagram showing the format of Matroska Media Container.
  • the file generation unit 105 stores the identification information of the texture layer and the depth layer and the information for associating the atlas ID with the layer pair as a newly defined element under the Trak Entry element. Further, the file generation unit 105 also stores the post-decoding information stored in ProjectionInfoBox () in the ISOBMFF file as a newly defined element under Trak Entry element.
  • ProjectionInfoBox ProjectionInfoBox
  • a reference two-dimensional image formed by projecting three-dimensional data from a predetermined viewpoint position in a plurality of projection directions and a viewpoint position moved within a limited range from the predetermined viewpoint position.
  • Atlas identification information that associates a texture image that forms a complementary image for generating a moving two-dimensional image based on the reference two-dimensional image with a depth image corresponding to the texture image, and the complementary image in the texture image.
  • Atlas processing unit and A coding unit that encodes a texture image and a depth image to generate a texture layer and a depth layer
  • An information processing device including the texture layer, the depth layer, the atlas identification information, and a file generation unit that generates a file containing the post-decoding information.
  • the information processing device according to the appendix (1) wherein the file generation unit stores the atlas identification information in sgpd'oinf'of Moov in an ISOBMFF file.
  • the file generation unit allocates a track of the ISOBMFF file to the texture layer and the depth layer, and stores the first post-decoding information in the first Box of the track assigned to the texture layer and the depth layer.
  • the information processing device according to the appendix (1) or (2).
  • the file generation unit stores the second post-decoding information in a second Box different from the first Box in the track to which the first Box in the ISOBMFF file is assigned.
  • the information processing device according to (3).
  • the file generation unit allocates the texture layer and the depth layer to different tracks of the ISOBMFF file, and each track is associated with the Track reference.
  • the atlas processing unit uses the first identification information indicating whether or not the information in the 3DoF region in which the reference two-dimensional image in the texture image is stored is included in the rendering target as the post-decoding information.
  • the information processing device wherein the file generation unit stores the second identification information in the Compatible Scheme Type Box in the track to which the texture layer is assigned.
  • the file generation unit includes a 3DoF region in which the reference two-dimensional image in the texture image is stored, the "3DoF +" region, a first region of the depth image corresponding to the 3DoF region, and the "".
  • Different tracks in the ISOBMFF file are assigned to each of the second region of the depth image corresponding to the 3DoF + "region, and each of the tracks to which the 3DoF region and the" 3DoF + "region are assigned, and the first The information processing device according to Appendix (1) or (2), wherein a track for storing "3DoF +" metadata is associated with a Track reference to each of the tracks to which the area and the second area are assigned.
  • the atlas processing unit includes first identification information indicating that the rendering target is information in the 3DoF region in the post-decoding information.
  • the information processing device (14) The information processing device according to the appendix (13), wherein the file generation unit stores information about the 3DoF region of the atlas identification information in a Moov Box in a track assigned to the 3DoF region of the texture layer. .. (15) The information processing device according to Appendix (13), wherein the file generation unit stores the first identification information in a Scheme TypeBox in a track to which the texture layer is assigned. (16) The information processing apparatus according to the appendix (12), wherein the atlas processing unit includes second identification information indicating that the rendering target is information in the "3DoF +" region in the post-decoding information.
  • the file generation unit describes in the appendix (16) that the information regarding the "3DoF +" region of the atlas identification information is stored in the Moov Box in the track assigned to the "3DoF +" region of the texture layer. Information processing equipment. (18) The information processing device according to the appendix (16), wherein the file generation unit stores the second identification information in the Scheme TypeBox in the track to which the texture layer is assigned. (19) A reference two-dimensional image corresponding to the projection direction when the three-dimensional data is projected from a predetermined viewpoint position in a plurality of projection directions and a moving two-dimensional image based on the viewpoint position moved from the predetermined viewpoint position.
  • Atlas identification information representing the correspondence between the texture image and the depth image in the correction image to be generated from the reference two-dimensional image, and information in the "3DoF +" region in which the correction image in the texture image is stored.
  • 1 Generates post-decoding information for rendering the reference 2D image and the moving 2D image including post-decoding information. Encode the texture image and depth image to generate the texture layer and depth layer, An information processing method for causing a computer to execute a process of generating a file including the texture layer, the depth layer, the atlas identification information, and the post-decoding information in the texture image.
  • Atlas identification information representing the correspondence between the texture image and the depth image in the correction image to be generated from the reference two-dimensional image, and information in the "3DoF +" region in which the correction image in the texture image is stored.
  • Post-decoding information for rendering the reference 2D image including 1 post-decoding information and the moving 2D image, a texture layer in which the texture image is encoded, and a depth layer in which the depth image is encoded.
  • a file acquisition unit that acquires files containing A file processing unit that acquires the atlas identification information and the post-decoding information from the file, and determines an image generation method according to the processing capacity of the own device based on the acquired atlas identification information and the post-decoding information.
  • a decoding processing unit that decodes both the texture layer and the depth layer or the texture layer to generate both the texture image and the depth image or the texture image according to the image generation method determined by the file processing unit.
  • a reproduction processing apparatus including a display information generation unit that generates a display image according to the image generation method based on the image generated by the decoding processing unit.
  • Atlas identification information representing the correspondence between the texture image and the depth image in the correction image to be generated from the reference two-dimensional image, and information in the "3DoF +" region in which the correction image in the texture image is stored.
  • Post-decoding information for rendering the reference 2D image including 1 post-decoding information and the moving 2D image, a texture layer in which the texture image is encoded, and a depth layer in which the depth image is encoded.
  • Get the file that contains The atlas identification information and the post-decoding information are acquired from the file, and based on the acquired atlas identification information and the post-decoding information, an image generation method according to the processing capacity of the own device is determined. Both the texture layer and the depth layer or the texture layer are decoded according to the determined image generation method to generate both the texture image and the depth image or the texture image.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

アトラス処理部は、３次元データを所定の視点位置から複数の投影方向に投影して形成される各投影方向に対応する基準２次元画像及び所定の視点位置から限定範囲内で移動させた視点位置に基づく移動２次元画像を基準２次元画像から生成するための補完画像を形成するテクスチャ画像と、テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、テクスチャ画像における補完画像が格納される"３ＤｏＦ＋"領域の情報であることを示す第１ポストデコーディング情報を含む、各基準２次元画像及び各移動２次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成する。符号化部は、テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する。ファイル生成部は、テクスチャレイヤ、デプスレイヤ、アトラス識別情報及びポストデコーディング情報を含むファイルを生成する。

Description

情報処理装置、情報処理方法、再生処理装置及び再生処理方法
　本発明は、情報処理装置、情報処理方法、再生処理装置及び再生処理方法に関する。
　ＨＴＴＰ（Hypertext　Transfer　Protocol）によるアダプティブなコンテンツ配信技術の標準化規格として、ＭＰＥＧ－ＤＡＳＨ（Moving　Picture　Experts　Group-Dynamic　Adaptive　Streaming　over　HTTP）が存在する。また、ＭＰＥＧ－ＤＡＳＨのファイルフォーマットにおける動画圧縮の国際標準技術である「ＭＰＥＧ－４」のファイルコンテナ仕様として、ＩＳＯＢＭＦＦ（International　Organization　for　Standardization　Base　Media　File　Format）がある。
　ところで、全天球映像のように、水平方向の周囲３６０度および垂直方向の周囲１８０度の画像を立体構造に投影した画像である立体構造画像を、平面画像にマッピングした全天球画像を再生する映像がある。全天球映像は３ＤｏＦ映像とも呼ばれ、全天球画像は投影平面画像や３ＤｏＦ（Degrees　of　Freedom）画像とも呼ばれる。ＭＰＥＧ－Ｉ　ＯＭＡＦ（Omnidirectional　Media　Format）では、全天球画像を形成する立体構造画像の配信へのＭＰＥＧ－ＤＡＳＨの利用が検討されている。
　さらに近年、３ＤｏＦ映像において実行可能な３軸周りの周囲見回しに加えて、限定範囲内での視点平行移動を伴う映像視聴体験を提供することができる”３ＤｏＦ＋”（Degrees　of　Freedom　Plus）映像の配信も検討されている。ＭＰＥＧ－Ｉ　Phase　1b　requirementにおいては、”３ＤｏＦ＋”に関連する要件として、ＯＭＡＦ　edition.1規格に準拠するplayer（ＯＭＡＦ　ed.1　player）への後方互換性の提供がリストアップされており、この要件を満たす技術開発が進められている。
　”３ＤｏＦ＋”の映像視聴体験を提供するデータは、”３ＤｏＦ＋”ストリームと呼ばれる。”３ＤｏＦ＋”ストリームは、テクスチャレイヤ（texture　Layer）、デプスレイヤdepth　Layer及び”３ＤｏＦ＋”メタデータを構成要素として含む。テクスチャレイヤは、”３ＤｏＦ＋”映像をレンダリングするためのテクスチャのパッチの集合である。また、デプスレイヤは、”３ＤｏＦ＋”映像をレンダリングするためのデプスのパッチの集合である。また、”３ＤｏＦ＋”メタデータは、各パッチが見える視点位置情報などを含む。クライアント装置は、”３ＤｏＦ＋”メタデータを基に、テクスチャレイヤ及びデプスレイヤから視聴映像のレンダリングに用いるパッチを選択してレンダリングすることで”３ＤｏＦ＋”映像の再生を行う。
　また、”３ＤｏＦ＋”ストリームにおけるテクスチャレイヤは、３ＤｏＦ領域と呼ばれる３ＤｏＦ視聴が可能な領域と、３ＤｏＦ領域に追加することで”３ＤｏＦ＋”視聴が可能となる”３ＤｏＦ＋”領域とを有する。このようなテクスチャレイヤを有することで、”３ＤｏＦ＋”ストリームのテクスチャレイヤのうちの３ＤｏＦ領域をレンダリングして３ＤｏＦ画像を生成することが可能となる。すなわち、”３ＤｏＦ＋”映像の再生能力は有さないが３ＤｏＦレンダリング機能を備えたクライアント装置であっても、”３ＤｏＦ＋”ストリームから３ＤｏＦ映像を生成するという利用方法が考えられる。
"ISO/IEC　14496-12:2015",　Information　technology.　Coding　of　audio-visual　objects.　Part12:ISO　base　media　file　format,　2015-12
　しかしながら、”３ＤｏＦ＋”ストリームにおける３ＤｏＦ領域をレンダリングする場合、クライアント装置は、”３ＤｏＦ＋”全体のレンダリングの処理を行った上で、特定視点位置から見た３ＤｏＦ映像を出力する処理を行う。そのため、実際には、”３ＤｏＦ＋”映像の再生能力は有さないが３ＤｏＦレンダリング機能を備えたクライアント装置では、”３ＤｏＦ＋”ストリームを用いて３ＤｏＦ映像を再生することは困難である。そのため、利用者の視聴体験は制限を受けることになる。
　そこで、本開示では、利用者の視聴体験を拡大することができる情報処理装置、情報処理方法、再生処理装置及び再生処理方法を提供する。
　本開示によれば、アトラス処理部は、３次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準２次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”３ＤｏＦ＋”領域の情報であることを示す第１ポストデコーディング情報を含む、各前記基準２次元画像及び各前記移動２次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成する。符号化部は、テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する。ファイル生成部は、前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成する。
配信システムの一例のシステム構成図である。 ファイル生成装置のブロック図である。 テクスチャ画像及びデプス画像を表す図である。 テクスチャ画像の詳細を説明するための図である。 ビデオストリームの一例を表す図である。 scalability_mask及びdimension_identifierの拡張例を示す図である。 アトラスＩＤの紐付けを説明するための図である。 サンプルグループを説明するための図である。 oinfサンプルグループの一例を表す図である。 linfサンプルグル―プの一例を表す図である。 ポストデコーディング情報の格納を説明するための図である。 ProjectedOmniVideoForParallaxBoxのシンタックスの一例を表す図である。 ProjectionInfoBoxのシンタックスの一例を表す図である。 ProjectionInfoBoxにおけるCameraPosStruct、DepthQuantizationStruct、ProjectionFormatStruct、RotationStruct及びRefionWisePackingStructのシンタックスの一例を示す図である。 ProjectionInfoBox及びRegionWisePackingStructのシンタックスの他の例を表す図である。 ３ＤｏＦレンダリングが可能な視点位置を示すように拡張したProjectionInfoBoxのシンタックスの一例を示す図である。 クライアント装置のブロック図である。 ファイル処理部、復号化処理部及び表示情報生成部の詳細を表すブロック図である。 第１の実施形態に係るファイル生成装置によるファイル生成処理のフローチャートである。 第１の実施形態に係るクライアント装置により実行される再生処理のフローチャートである。 第１の実施形態の変形例に係るＩＳＯＢＭＦＦファイルの一例を表す図である。 第２の実施形態に係るＩＳＯＢＭＦＦＦファイルの一例を表す図である。 第３の実施形態に係るＩＳＯＢＭＦＦＦファイルの一例を表す図である。 第３の実施形態の変形例（１）に係るsub-picture　track　groupingのシンタックスの一例を示す図である。 Matroska　Media　Containerのフォーマットを表す図である。
　以下に、本開示の実施形態について図面に基づいて詳細に説明する。なお、以下の各実施形態において、同一の部位には同一の符号を付することにより重複する説明を省略する。また、本技術で開示される範囲は、実施形態の内容に限定されるものではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
　非特許文献１：（上述）
　非特許文献２："ISO/IEC　14496-15:2017",　Information　technology.　Coding　of　audio-visual　objects.　Part15:Carriage　of　network　abstraction　layer(NAL)　unit　structure　video　in　the　ISO　base　media　file　format　2017-02
　非特許文献３："ISO/IEC　23090-2:2019",　Information　technology.　Coded　representation　of　immersive　media,　Part2:Omnidirecrional　media　format,　2019-01
　非特許文献４：N17331,　Requirements　MPEG-I　phase　1b,　version　1,　2018-02-22
　非特許文献５：M48024,　Strawman　Design　for　”3DoF+”,　version　2,　2019-03-28
　非特許文献６：M47544,　Extensions　to　Technicolor　Intel　Response　to　”3DoF”　CfP,　version　2,　2019-03-22
　非特許文献７：N18464,　Working　Draft　1　of　Metadata　for　Immersive　Media　(Video),　version　1,　2019-04-26
　非特許文献８：”Matroska　Media　Container”,　[令和2年2月27日検索],　インターネット　<URL　:　https://www.matroska.org/>
　つまり、上述の非特許文献に記載されている内容も、参照により本明細書に組み込まれる。つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、非特許文献１～３及び８に記載されているFile　Structureや、非特許文献５～７に記載されている”３ＤｏＦ＋”ストリーム構造で用いられている用語が発明の詳細な説明において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。また、例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、発明の詳細な説明において直接的に定義されていない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
　また、以下に示す項目順序に従って本開示を説明する。
　　１．第１の実施形態
　　　１．１　第１の実施形態の変形例
　　２．第２の実施形態
　　　２．１　第２の実施形態の変形例
　　３．第３の実施形態
　　　３．１　第３の実施形態の変形例（１）
　　　３．２　第３の実施形態の変形例（２）
　　４．第４の実施形態
［１．第１の実施形態］
　”３ＤｏＦ＋”ストリームは、テクスチャレイヤ、デプスレイヤ及び”３ＤｏＦ＋”メタデータを含む。”３ＤｏＦ＋”メタデータは、詳しくは、カメラパラメータ及びアトラスパラメータリストメタデータを有する。カメラパラメータは、各パッチが見える視点位置情報である。また、アトラスパラメータリストメタデータは、パッチ毎の表示位置とコーデックピクチャ上の位置間のマッピング情報を表す。対応するテクスチャレイヤ及びデプスレイヤの組となるレイヤペアがアトラスと呼ばれる。
　そして、”３ＤｏＦ＋”ストリームのテクスチャレイヤは、３ＤｏＦ領域と”３ＤｏＦ＋”領域を含む。”３ＤｏＦ＋”領域には、細かいパッチが格納されており、各パッチには３ＤｏＦ領域をレンダリングして形成される画像の別の角度からの映像に用いる情報が含まれる。
　”３ＤｏＦ＋”ストリームは、マルチレイヤ（Multi-layer）ＨＥＶＣ（High　Efficiency　Video　Codec）で符号化される。マルチレイヤＨＥＶＣは、１つのストリームの中に低解像度のレイヤと高解像度のレイヤとのように複数のレイヤを含む符号化方法である。”３ＤｏＦ＋”メタデータは、例えばＳＥＩ（Supplemental　Enhancement　Information）としてビットストリーム（bitstream）に格納される。ビットストリームは、”３ＤｏＦ＋”ストリームを形成する”３ＤｏＦ＋”画像のデータである。そして、ＨＥＶＣのメタデータの１種であるＶＰＳ（Video　Parameter　Set）が拡張され、各レイヤにアトラスフラグが付与されることで、アトラスを構成するレイヤペアを識別することが可能となる。
　ここで、再生処理装置が３ＤｏＦレンダリング機能を備えるが”３ＤｏＦ＋”映像の再生能力は有さない場合について考える。以下では、３ＤｏＦレンダリング機能を備えるが”３ＤｏＦ＋”映像の再生能力は有さない再生処理装置を、３ＤｏＦ再生処理装置という。３ＤｏＦ再生処理装置には、いくつか種類が考えられる。例えば、”３ＤｏＦ＋”ストリームをデコードできるが、レンダリング能力や機能の制約から３ＤｏＦレンダリングは行えるが、”３ＤｏＦ＋”映像のレンダリングには対応していない３ＤｏＦ再生処理装置がある。また、例えば、ＯＭＡＦ　ed.1　playerなどの”３ＤｏＦ＋”ストリームのデコード及びレンダリングのいずれの機能も有さない３ＤｏＦ再生処理装置がある。
　”３ＤｏＦ＋”ストリームのテクスチャレイヤは、３ＤｏＦ領域及び”３ＤｏＦ＋”領域を含むため、３ＤｏＦ再生処理装置は、”３ＤｏＦ＋”ストリームのテクスチャレイヤのうちの３ＤｏＦ領域に限定してレンダリングを行うという場合が考えられる。このような処理を行うことが可能であれば、再生能力の異なる再生処理装置でも、同一の”３ＤｏＦ＋”ストリームを再生能力に合わせて適切に再生することができ、再生処理装置の再生能力毎にストリームを用意しなくてもよくなる。これにより、例えば、配信時の配信サーバが有するＣＤＮ（Content　Delivery　Network）ストレージを節約でき、且つ、再生処理装置が再生可能なコンテンツを増やすことができる。なおＭＰＥＧ－Ｉ　Phase　1bの”３ＤｏＦ＋”に関する技術要件においても、この場合の対応が求められている。
　しかしながら、”３ＤｏＦ＋”ストリームに含まれる３ＤｏＦ領域をレンダリングする場合、３ＤｏＦ対応のクライアント装置２は、一度”３ＤｏＦ＋”でレンダリングを行い、その上で、特定視点位置から見た３ＤｏＦ映像のみを出力する処理を行うことになる。これは、３ＤｏＦ対応のクライアント装置２では、”３ＤｏＦ＋”ストリームの処理が困難であることを意味する。すなわち、今までの”３ＤｏＦ＋”コンテンツの配信システムでは、上述したメリットを享受することが困難である。そこで、以下に、３ＤｏＦ再生処理装置が配信された”３ＤｏＦ＋”コンテンツを再生可能となる配信システムについて説明する。
[第１の実施形態に係るシステムの構成]
　図１は、配信システムの一例のシステム構成図である。配信システム１００は、情報処理装置であるファイル生成装置１、再生処理装置であるクライアント装置２及びＷｅｂサーバ３を含む。ファイル生成装置１、クライアント装置２及びＷｅｂサーバ３は、ネットワーク４に接続される。そして、ファイル生成装置１、クライアント装置２及びＷｅｂサーバ３は、ネットワーク４を介して相互に通信可能である。ここで、図１においては、各装置を１台ずつ示しているが、配信システム１００は、ファイル生成装置１及びクライアント装置２をそれぞれ複数台含んでもよい。
　ファイル生成装置１は、”３ＤｏＦ＋”映像を提供するデータである”３ＤｏＦ＋”ストリームを生成する。ファイル生成装置１は、生成した”３ＤｏＦ＋”ストリームをＷｅｂサーバ３にアップロードする。ここで、本実施形態では、Ｗｅｂサーバ３が”３ＤｏＦ＋”ストリームをクライアント装置２に提供する構成について説明するが、配信システム１００は他の構成を採ることも可能である。例えば、ファイル生成装置１が、Ｗｅｂサーバ３の機能を含み、生成した”３ＤｏＦ＋”ストリームを自装置内に格納し、クライアント装置２に提供する構成であってもよい。
　Ｗｅｂサーバ３は、ファイル生成装置１からアップロードされた”３ＤｏＦ＋”ストリームを保持する。そして、Ｗｅｂサーバ３は、クライアント装置２からの要求にしたがい指定された”３ＤｏＦ＋”ストリームを提供する。
　クライアント装置２は、”３ＤｏＦ＋”ストリームの送信要求をＷｅｂサーバ３へ送信する。そして、クライアント装置２は、送信要求で指定した”３ＤｏＦ＋”ストリームをＷｅｂサーバ３から取得する。そして、クライアント装置２は、”３ＤｏＦ＋”ストリームをデコードして映像を生成して、その映像をモニタなどの表示装置に表示させる。
［第１の実施形態に係るファイル生成装置の構成］
　次に、ファイル生成装置１の詳細について説明する。図２は、ファイル生成装置のブロック図である。情報処理装置であるファイル生成装置１は、図２に示すように、生成処理部１０及び制御部１１を有する。制御部１１は、生成処理部１０の制御に関する処理を実行する。例えば、制御部１１は、生成処理部１０の各部の動作タイミングなどの統括制御を行う。生成処理部１０は、データ入力部１０１、アトラス処理部１０２、符号化部１０３、ビットストリーム生成部１０４、ファイル生成部１０５及び送信部１０６を有する。
　データ入力部１０１は、”３ＤｏＦ＋”映像の画像データ及び”３ＤｏＦ＋”メタデータなどの入力を受け付ける。”３ＤｏＦ＋”メタデータには、画像の時刻、位置情報及び視点位置情報などの視点に関する情報が含まれる。データ入力部１０１は、取得した画像データをアトラス処理部１０２へ出力する。また、データ入力部１０１は、メタ情報を符号化部１０３へ出力する。
　アトラス処理部１０２は、”３ＤｏＦ＋”映像の画像データの入力をデータ入力部１０１から受ける。そして、アトラス処理部１０２は、画像データからテクスチャ画像のデータ及びデプス画像のデータを生成する。テクスチャ画像は、”３ＤｏＦ＋”映像は、３次元データを決められた視点位置から複数の投影方向に投影して形成される各投影方向に対応する画像である。デプス画像は、テクスチャ画像上の各点の３次元空間における位置を表す画像である。
　図３は、テクスチャ画像及びデプス画像を表す図である。図３における画像３０１が、テクスチャ画像である。そして、領域３１１が３ＤｏＦ領域であり、領域３１２が”３ＤｏＦ＋”領域である。”３ＤｏＦ＋”領域には、３ＤｏＦ領域における視点位置から少しずれた角度から見た画像を生成するための補正画像であるパッチが含まれる。また、画像３０２が、デプス画像である。そして、アトラス処理部１０２は、対応するテクスチャ画像のデータとデプス画像のデータとを組み合わせてアトラスを生成する。また、アトラス処理部１０２は、アトラスを全天球映像として表示するためのアトラス配置パラメータを生成する。
　さらに、アトラスを構成するテクスチャ画像及びデプス画像のペア識別子であるアトラスＩＤを生成して各アトラスに割り当てる。また、アトラス処理部１０２は、２次元のデータから全天球映像を作るためのメタデータであるポストデコーディング情報を生成する。
　ここで、ポストデコーディング情報を説明するためにテクスチャ画像の詳細について、図４を参照して説明する。図４は、テクスチャ画像の詳細を説明するための図である。テクスチャ画像３３０は、３ＤｏＦ領域３３１及び”３ＤｏＦ＋”領域３３２を有する。そして、テクスチャ画像３３０は、座標空間３４０における視点ｏ、視点ａ、視点ｂ及び視点ｃから見た全天球映像の元となる画像を含む。３ＤｏＦ領域３３１には、基本カメラのprojected　pictureである視点ｏの位置における画像３３３が格納される。この基本カメラによる視点位置が「所定の視点位置」一例にあたる。そして、画像３３３が、「基準２次元画像」の一例にあたる。
　また、”３ＤｏＦ＋”領域３３２には、視点ａの位置における画像３３４、視点ｂの位置における画像３３５及び視点ｃの位置における画像３３６といった限定範囲内の任意カメラ位置のprojected　pictureを生成するための補完画像であるパッチが格納される。この限定範囲内の任意カメラによる視点位置が、「所定の視点位置から移動させた視点位置」の一例にあたる。そして、画像３３４～３３６が、「移動２次元画像」の一例にあたる。デプス画像についても、テクスチャ画像の各projected　pictureの情報に相当するデプスマップが格納される。
　アトラス処理部１０２は、各視点位置からの画像、すなわち視点ｏ及びａ～ｃからの画像３３３～３３６をテクスチャ画像３３０から生成するためのポストデコーディング情報を生成する。アトラス処理部１０２は、このポストデコーディング情報に、各画像がテクスチャ画像の３ＤｏＦ領域の画像か、テクスチャ画像の”３ＤｏＦ＋”領域を用いて生成される画像かの情報を含ませる。その後、アトラス処理部１０２は、アトラスとともに、アトラス配置パラメータ、アトラスＩＤ及びポストデコーディング情報を含む”３ＤｏＦ＋”メタデータを符号化部１０３へ出力する。
　符号化部１０３は、アトラスの入力をアトラス処理部１０２から受ける。また、符号化部１０３は、アトラス配置パラメータ、アトラスＩＤ及びポストデコーディング情報を含む”３ＤｏＦ＋”メタデータの入力をデータ入力部１０１から受ける。次に、符号化部１０３は、アトラス及び”３ＤｏＦ＋”メタデータをマルチレイヤＨＥＶＣで符号化する。符号化部１０３は、テクスチャ画像を符号化することで、テクスチャレイヤを生成する。また、符号化部１０３は、デプス画像を符号化することでデプスレイヤを生成する。すなわち、符号化されたアトラスは、テクスチャレイヤ及びデプスレイヤを含む。そして、符号化部１０３は、符号化したアトラス及び”３ＤｏＦ＋”メタデータをビットストリーム生成部１０４へ出力する。
　ビットストリーム生成部１０４は、符号化されたアトラス及び”３ＤｏＦ＋”メタデータの入力を符号化部１０３から受ける。そして、ビットストリーム生成部１０４は、アトラスを時系列に並べ且つ対応する”３ＤｏＦ＋”メタデータを組み合わせてビットストリームを生成する。図５は、ビデオストリームの一例を表す図である。ビデオストリームには、テクスチャレイヤ３０３とデプスレイヤ３０４との組であるアトラスが時系列で格納される。ビデオストリームに含まれる１つのアトラスを構成するデータの単位は、アクセスユニット（ＡＵ：access　unit）と呼ばれる。そして、ビットストリーム生成部１０４は、生成したビットストリームをファイル生成部１０５へ出力する。
　ファイル生成部１０５は、ビットストリームの入力をビットストリーム生成部１０４から受ける。そして、ファイル生成部１０５は、取得したビットストリームをセグメント毎にＩＳＯＢＭＦＦファイルに格納することでファイル化して、ビットストリームのセグメントファイルを生成する。以下にＩＳＯＢＭＦＦファイルへの格納について説明する。
　ファイル生成部１０５は、１トラックにアトラスを構成するテクスチャレイヤ及びデプスレイヤが格納されていることを示す情報をＩＳＯＢＭＦＦファイルに格納する。具体的には、ファイル生成部１０５は、Operating　Point　Information　sample　group（oinf）を拡張し、scalability_mask及びdimension_identifierをＨＥＶＣのＶＰＳと同様に格納することで、アトラスを構成するテクスチャ及びデプスレイヤのペア識別子であるアトラスＩＤを定義する。図６は、scalability_mask及びdimension_identifierの拡張例を示す図である。ファイル生成部１０５は、例えば、図６に示すようにscalability_maskの５番目のビットを、アトラスＩＤに割り当てる。
　そして、ファイル生成部１０５は、ビットストリームをＩＳＯＢＭＦＦファイルに格納する際にアトラスＩＤを各テクスチャレイヤ及び各デプスレイヤに割り当てられたレイヤＩＤに紐づける。図７は、アトラスＩＤの紐付けを説明するための図である。”３ＤｏＦ＋”のビットストリームをＩＳＯＢＭＦＦファイルに格納する場合、Ｌ－ＨＥＶＣストレージ（ISO/IEC　14496-15参照）が利用可能であり、その場合、ビットストリームは、図６に示すようにＩＳＯＢＭＦＦファイルに格納される。ビットストリームの各アクセスユニットは、ＩＳＯＢＭＦＦファイルでは、それぞれsampleEntryとして扱われる。この場合、ファイル生成部１０５は、マルチメディアＨＥＶＣで符号化した際にストリームの一部として”３ＤｏＦ＋”メタデータを送る。
　ここで、ファイル生成部１０５は、Sampleをグループ化し、ＩＳＯＢＭＦＦファイル内でサンプルグループを用いて、グループ毎にメタデータを紐づける。ファイル生成部１０５は、サンプルグループをＩＳＯＢＭＦＦファイルのMoovに格納する。図８は、サンプルグループを説明するための図である。ＩＳＯＢＭＦＦファイル内で、各サンプルグループは、図８に示すSampleTableBoxにより定義される。図８に示すように、Sample　To　Group　Boxのgrouping_Typeは、紐づけられるSample　Group　Description　BoxのGrouping_Typeを示す。また、Sample　To　Group　Boxでは、１エントリにつき、sample_count及びGroup_description_indexが登録される。group_description_indexは、紐付くGroupEntryのindexを示す。また、sample_countは、そのGroupEntryに属するsample数を示す。
　そして、ファイル生成部１０５は、サンプルグループとして、図７に示すoperating　points　information（oinf）サンプルグループ３０５及びLayer　Information(linf)サンプルグループ３０６を生成する。
　図９は、oinfサンプルグループの一例を表す図である。ファイル生成部１０５は、シンタックス３２１によりOperating　Pointに含まれるレイヤと各レイヤのprofile、level及びtierをoinfサンプルグループに登録する。また、ファイル生成部１０５は、シンタックス３２２によりwidth及びheightの最大及び最小の情報、フレームレート及びビットレートの関連情報などのOperating　pointに含まれる情報をoinfサンプルグループに登録する。さらに、ファイル生成部１０５は、シンタックス３２３により、非ベースレイヤの依存関係と種類の情報をoinfサンプルグループに登録する。ここで、ファイル生成部１０５は、図６に示したscalability_maskとdimention_identifierとを用いて種類を表す。ファイル生成部１０５は、この種類としてアトラスＩＤを格納する。すなわち、ファイル生成部１０５は、アトラスＩＤをsgpd’oinf’と表されるoinfサンプルグループに格納する。このように、oinfサンプルグループ３０５は、同じ属性のSampleをまとめる情報が格納される。
　ファイル生成部１０５は、oinfサンプルグループ内でアトラスＩＤとレイヤＩＤとを対応付けることで、図７に示すように、各アトラスＩＤとテクスチャレイヤ及びデプスレイヤとを紐づける。図７において、「０」のアトラスＩＤは、レイヤＩＤが「０」のテクスチャレイヤ及びレイヤＩＤが「１」のデプスレイヤに紐づけられる。また、「１」のアトラスＩＤは、レイヤＩＤが「２」のテクスチャレイヤ及びレイヤＩＤが「３」のデプスレイヤに紐づけられる。
　このように、テクスチャレイヤ及びデプスレイヤを有するアトラスが格納されていることを示す情報をoinfサンプルグループに格納することで、クライアント装置２は、ＥＳのデコードをする前にテクスチャレイヤ及びデプスレイヤを把握できる。すなわち、クライアント装置２は、自装置でレンダリング可能なレイヤを選択してデコードすることができるようになり、処理オーバヘッドを削減することができる。例えば、”３ＤｏＦ＋”ストリームのデコードは可能、且つ、３ＤｏＦレンダリングは可能であるが、”３ＤｏＦ＋”レンダリングには対応してないクライアント装置２は、テクスチャレイヤを容易に選択することができる。
　また、ファイル生成部１０５は、linfサンプルグループ３０６に、トラックに含まれるレイヤのレイヤＩＤ及びレイヤＩＤで示されるレイヤの内のどのサブレイヤが含まれるかを示す情報を格納する。図１０は、linfサンプルグル―プの一例を表す図である。図１０においてlayer_idがレイヤＩＤを表し、この値が各Sampleにおけるnuh_layer_idに対応する。
　さらに、ファイル生成部１０５は、２次元のデータから全天球映像を作るためのメタデータであるポストデコーディング情報をＩＳＯＢＭＦＦファイルに格納する。このＩＳＯＢＭＦＦファイルに格納されたポストデコーディング情報を用いることで、クライアント装置２は”３ＤｏＦ＋”もしくは３ＤｏＦのレンダリングを行うことができる。
　例えば、ファイル生成部１０５は、図１１に示すように、ポストデコーディング情報を格納する。図１１は、ポストデコーディング情報の格納を説明するための図である。ファイル生成部１０５は、図１１に示すように、SchemeTypeBox３４１においてscheme_type=’povp’としてトラックに格納されたコンテンツが”３ＤｏＦ＋”ストリームであることを示す。これ以外にも、ファイル生成部１０５は、”３ＤｏＦ＋”ストリームであることを示す新規フラグを定義してSampleEntryに格納してもよい。さらに、ファイル生成部１０５は、例えば、SchemeInformationBoxに視点位置毎のポストデコーディング情報を持つ新規Box３４２としてProjectedOmniVideoForParallaxBoxを定義する。
　図１２は、ProjectedOmniVideoForParallaxBoxのシンタックスの一例を表す図である。図１２に示すように、ファイル生成部１０５は、視点位置の数分のポストデコーディング情報を登録するためのProjectedOmniVideoForParallaxBoxにProjectionInfoBoxを格納する。”３ＤｏＦ＋”領域を用いた画像であることを表すポストデコーディング情報が、「第１ポストデコーディング情報」の一例にあたり、そのポストデコーディング情報を格納するProjectionInfoBoxが、「第１のBox」の一例にあたる。この３ＤｏＦ領域の画像であることを表すポストデコーディング情報が、「第２ポストデコーディング情報」の一例にあたり、そのポストデコーディング情報を格納するProjectionInfoBoxが、「第２のBox」の一例にあたる。
　図１３は、ProjectionInfoBoxのシンタックスの一例を表す図である。さらに、図１４は、ProjectionInfoBoxにおけるCameraPosStruct、DepthQuantizationStruct、ProjectionFormatStruct、RotationStruct及びRefionWisePackingStructのシンタックスの一例を示す図である。
　ProjectionInfoBoxは、図１４に示すシンタックス３５１～３５５で表される、CameraPosStruct、DepthQuantizationStruct、ProjectionFormatStruct、RotationStruct及びRegionWisePackingStructを呼び出す。ファイル生成部１０５は、CameraPosStruct及びDepthQuantizationStructを新しく定義する。CameraPosStructは、視点位置を格納する。CameraPosStructとしては、ViewpointPosStructを利用してもよい。DepthQuantizationStructは、デプス量子化パラメータを格納する。ファイル生成部１０５は、ProjectionFormatStructにおけるProjection_typeを表３５７に示すようにPerspective　projectionを含むように拡張する。RegionWisePackingStructは、シンタックス３５６で表されるRectRegionPackingを呼び出す。RegionWisePackingStructは、アトラスのパッチ位置情報を格納する。すなわち、RegionWisePackingStructは、各パッチがどのテクスチャレイヤに含まれるかを示す情報である。
　ProjectionInfoBoxにおけるCameraPosStruct、ProjectionFormatStruct及びRotationStructは、動的に変化しないことが想定されるため、”３ＤｏＦ＋”ストリーム中でなく、ＩＳＯＢＭＦＦファイルにメタデータとして格納することで、冗長な記述を回避できビット数の削減が可能となる。また、ProjectionInfoBoxにおけるRegionWisePackingStruct及びDepthQuantizationStructについては、動的に変化しない場合には、ＩＳＯＢＭＦＦファイルにメタデータとして格納することで、冗長な記述を回避できビット数の削減が可能となる。また、RegionWisePackingStruct及びDepthQuantizationStructが動的に変化する場合には、ファイル生成部１０５は、ＩＳＯＢＭＦＦファイルに初期値を格納する。さらに、ファイル生成部１０５は、ProjectionFormatStruct()及びDepthQuantizationStruct()それぞれが視点間で同一か否か示すフラグを追加して、同一で有る場合には、num_camerasのループの外に登録することで、ビット数を削減することも可能である。
　ここで、ファイル生成部１０５は、ProjectionInfoBox及びRegionWisePackingStructを図１５に示すように生成してもよい。図１５は、ProjectionInfoBox及びRegionWisePackingStructのシンタックスの他の例を表す図である。図１５のシンタックス３６１で示されるProjectionInfoBoxの場合、シンタックス３６２で示されるRegionWisePackingStructが呼び出される。このRegionWisePackingStructでは、unsigned_int(8)　atlas_idにより、特定のテクスチャレイヤの所定の位置にアトラスＩＤを書き込むことができる。
　さらに、ファイル生成部１０５は、ProjectionInfoBoxを図１６のように拡張して、３ＤｏＦレンダリングが可能な視点位置を示す。図１６は、３ＤｏＦレンダリングが可能な視点位置を示すように拡張したProjectionInfoBoxのシンタックスの一例を示す図である。図１６に示すシンタックスでは、is_3DoF_compatibleの値が０であれば、３ＤｏＦレンダリングに対応しておらず、値が１であれば３ＤｏＦレンダリングが可能である。すなわち、クライアント装置２は、num_camerasの値を有する視点位置各視点位置のうちどの視点位置が３ＤｏＦレンダリング可能かをこのProjectionInfoBoxにより確認できる。これにより、３ＤｏＦレンダリングは可能であるが、”３ＤｏＦ＋”レンダリングには対応してないクライアント装置２が”３ＤｏＦ＋”ストリームのうち３ＤｏＦ領域をレンダリングすることが可能となる。
　図２に戻って説明を続ける。ファイル生成部１０５は、以上に説明したProjectionInfoBoxにより各視点位置におけるポストデコーディング情報及びレイヤＩＤに紐づけられたアトラスＩＤを格納したＩＳＯＢＭＦＦファイルを送信部１０６へ出力する。
　送信部１０６は、ProjectionInfoBoxにより各視点位置におけるポストデコーディング情報及びレイヤＩＤに紐づけられたアトラスＩＤを格納したＩＳＯＢＭＦＦファイルの入力をファイル生成部１０５から受ける。そして、送信部１０６は、取得したＩＳＯＢＭＦＦファイルをＷｅｂサーバ３に送信してアップロードする。
［第１の実施形態に係るクライアント装置の構成］
　図１７は、クライアント装置のブロック図である。また、図１８は、ファイル処理部、復号化処理部及び表示情報生成部の詳細を表すブロック図である。
　図１７に示すように、クライアント装置２は、再生処理部２０及び制御部２１を有する。制御部２１は、再生処理部２０の各部の動作を制御する。例えば、制御部２１は、再生処理部２０の各部の動作のタイミングを統括制御する。再生処理部２０は、ファイル取得部２０１、ファイル処理部２０２、復号処理部２０３、表示情報生成部２０４及び表示部２０５を有する。
　ファイル取得部２０１は、Ｗｅｂサーバ３にアクセスして表示する６ＤｏＦコンテンツのシーンディスクリプションが格納されたＩＳＯＢＭＦＦのファイルを取得する。そして、ファイル取得部２０１は、シーンディスクリプションが格納されたＩＳＯＢＭＦＦのファイルをファイル処理部２０２へ出力する。
　ファイル取得部２０１は、Ｗｅｂサーバ３にアクセスして表示する”３ＤｏＦ＋”ストリームが格納されたＩＳＯＢＭＦＦファイルを取得する。そして、ファイル取得部２０１は、”３ＤｏＦ＋”ストリームが格納されたＩＳＯＢＭＦＦファイルをファイル処理部２０２へ出力する。
　ファイル処理部２０２は、図１８に示すように、抽出部２２０を有する。ファイル処理部２０２は、”３ＤｏＦ＋”ストリームが格納されたＩＳＯＢＭＦＦファイルの入力をファイル取得部２０１から受ける。そして、ファイル処理部２０２の抽出部２２０は、ＩＳＯＢＭＦＦファイルをパースして、ビットストリームのデータを抽出する。その後、抽出部２２０は、ビットストリームのデータを復号処理部２０３へ出力する。
　ここで、ファイル処理部２０２は、取得したＩＳＯＢＭＦＦファイルのパースにより、トラックに格納されたコンテンツが”３ＤｏＦ＋”ストリームか否かを判定する。例えば、ファイル処理部２０２は図１１におけるSchemeTyepBoxのscheme_typeを確認して”３ＤｏＦ＋”ストリームか否かを判定する。そして、復号処理部２０３が”３ＤｏＦ＋”ストリームのデコードに対応していない場合、ファイル処理部２０２は、トラックに格納されたコンテンツが”３ＤｏＦ＋”ストリームであればエラーを通知して処理を中止する。
　また、復号処理部２０３が”３ＤｏＦ＋”ストリームのデコードに対応しているが、表示情報生成部２０４が”３ＤｏＦ＋”のレンダリングに対応していない場合、ファイル処理部２０２は、３ＤｏＦレンダリングが可能な視点位置を取得する。そして、ファイル処理部２０２は、テクスチャレイヤのデコードを復号処理部２０３に指示するとともに、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を送信する。
　復号処理部２０３は、図１８に示すように、複数のデコーダ２３０を有する。復号処理部２０３は、ビットストリームデータの入力をファイル処理部２０２から受ける。そして、復号処理部２０３は、デコーダ２３０を用いて取得したビットストリームのデータに対して復号処理を施す。その後、復号処理部２０３は、復号化したビットストリームのデータを表示情報生成部２０４へ出力する。
　また、復号処理部２０３は、表示情報生成部２０４が”３ＤｏＦ＋”レンダリングに対応していない場合、テクスチャレイヤのデコードの指示を復号処理部２０３から受ける。また、復号処理部２０３は、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を受信する。そして、復号処理部２０３は、”３ＤｏＦ＋”ストリームのテクスチャレイヤのデコードを行う。その後、復号処理部２０３は、デコードしたテクスチャレイヤ、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を表示情報生成部２０４へ出力する。
　表示情報生成部２０４は、図１８に示すように、アトラス分解部２４１及び表示処理部２４２を有する。表示情報生成部２０４は、復号化されたビットストリームの入力を復号処理部２０３から受ける。そして、表示情報生成部２０４のアトラス分解部２４１は、復号化された各アトラスのテクスチャレイヤとデプスレイヤとを分解する。そして、アトラス分解部２４１は、分解したアトラスを表示処理部２４２へ出力する。
　また、”３ＤｏＦ＋”レンダリングに対応していない場合、表示情報生成部２０４は、デコードされたたテクスチャレイヤ、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報の入力を復号処理部２０３から受ける。そして、アトラス分解部２４１は、デコードされたテクスチャレイヤ、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を表示処理部２４２へ出力する。
　表示処理部２４２は、分解されたアトラスの入力をアトラス分解部２４１から受ける。さらに、表示処理部２４２は、視点位置及び視線方向の入力を図示しない入力装置から受ける。そして、表示処理部２４２は、入力された視点位置及び視線方向にしたがって、”３ＤｏＦ＋”レンダリングを行い表示用の”３ＤｏＦ＋”画像を生成する。その後、表示処理部２４２は、生成した表示用の”３ＤｏＦ＋”画像を表示部２０７に供給する。
　また、”３ＤｏＦ＋”レンダリングに対応していない場合、表示処理部２４２は、コードされたテクスチャレイヤ、３ＤｏＦレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報の入力をアトラス分解部２４１から受ける。さらに、表示処理部２４２は、視点位置及び視線方向の入力を図示しない入力装置から受ける。そして、表示処理部２４２は、入力された視点位置に対応するテクスチャレイヤの３ＤｏＦ領域からデータを取得し、視線方向にしたがって３ＤｏＦレンダリングを行い表示用の３ＤｏＦ画像を生成する。その後、表示処理部２４２は、生成した表示用の３ＤｏＦ画像を表示部２０７に供給する。
　表示部２０５は、モニタなどの表示装置を有する。表示部２０５は、表示情報生成部２０４により生成された表示用の画像の入力を受ける。そして、表示部２０５は、取得した表示用の画像を表示装置に表示させる。
［第１の実施形態に係るファイル生成手順］
　次に、図１９を参照して、第１の実施形態に係るファイル生成装置１によるファイル生成処理の流れについて詳細に説明する。図１９は、第１の実施形態に係るファイル生成装置によるファイル生成処理のフローチャートである。
　アトラス処理部１０２は、”３ＤｏＦ＋”映像の画像データ及び”３ＤｏＦ＋”メタデータの入力をデータ入力部１０１から受ける。そして、アトラス処理部１０２は、”３ＤｏＦ＋”映像の画像データ及び”３ＤｏＦ＋”メタデータからアトラス及びアトラス配置パラメータを生成する（ステップＳ１０１）。また、アトラス処理部１０２は、アトラスＩＤ及びポストデコーディング情報を生成する。そして、アトラス処理部１０２は、アトラス、並びに、アトラスＩＤ、ポストデコーディング情報及びアトラス配置パラメータを含む”３ＤｏＦ＋”メタデータを符号化部１０３へ出力する。
　符号化部１０３は、アトラス、並びに、アトラスＩＤ、ポストデコーディング情報及びアトラス配置パラメータを含む”３ＤｏＦ＋”メタデータをエンコードしてビットストリーム生成部１０４へ出力する。ビットストリーム生成部１０４は、エンコードされたアトラス及び”３ＤｏＦ＋”メタデータを用いて”３ＤｏＦ＋”のビットストリームを生成する（ステップＳ１０２）。その後、符号化部１０３は、生成したビットストリームをファイル生成部１０５へ出力する。
　次に、ファイル生成部１０５は、アトラスＩＤとレイヤＩＤとを紐づける情報、視点位置毎のポストデコーディング情報及びビットストリームをＩＳＯＢＭＦＦファイルに格納する（ステップＳ１０３）。その後、ファイル生成部１０５は、ＩＳＯＢＭＦＦファイルを送信部１０６へ出力する。送信部１０６は、ファイル生成部１０５により生成されたＩＳＯＢＭＦＦファイルをＷｅｂサーバ３へ出力する。
［第１の実施形態に係る再生処理手順］
　次に、図２０を参照して、本実施形態に係るクライアント装置２により実行される再生処理の流れを説明する。図２０は、第１の実施形態に係るクライアント装置により実行される再生処理のフローチャートである。ここでは、復号処理部２０３が”３ＤｏＦ＋”ストリームのデコードが可能である場合で説明する。
　ファイル処理部２０２は、ファイル取得部２０１を介して再生する”３ＤｏＦ＋”ストリームに対応するＩＳＯＢＭＦＦファイルをＷｅｂサーバ３から取得する。次に、ファイル処理部２０２は、自装置の表示情報生成部２０４が”３ＤｏＦ＋”レンダリングに対応しているか否かを判定する（ステップＳ２０１）。
　自装置の表示情報生成部２０４が”３ＤｏＦ＋”レンダリングに対応している場合（ステップＳ２０１：肯定）、ファイル処理部２０２は、ＩＳＯＢＭＦＦファイルをパースして、３ＤｏＦ及び”３ＤｏＦ＋”のポストデコーディング情報を取得する（ステップＳ２０２）。さらに、ファイル処理部２０２は、”３ＤｏＦ＋”のビットストリームをＩＳＯＢＭＦＦファイルから抽出する。そして、ファイル処理部２０２は、抽出した”３ＤｏＦ＋”のビットストリーム、並びに、３ＤｏＦ及び”３ＤｏＦ＋”のポストデコーディング情報を復号処理部２０３へ出力する。
　復号処理部２０３は、”３ＤｏＦ＋”のビットストリーム、並びに、３ＤｏＦ及び”３ＤｏＦ＋”のポストデコーディング情報の入力をファイル処理部２０２から受ける。そして、復号処理部２０３は、”３ＤｏＦ＋”のビットストリームをデコードする（ステップＳ２０３）。その後、復号処理部２０３は、デコードしたビットストリームのデータ及びポストデコーディング情報を表示情報生成部２０４へ出力する。
　表示情報生成部２０４は、ビットストリームのデータ、並びに、３ＤｏＦ及び”３ＤｏＦ＋”のポストデコーディング情報の入力を復号処理部２０３から受ける。さらに、表示情報生成部２０４は、視点位置及び視線方向の入力を入力装置から受ける。そして。表示情報生成部２０４は、ポストデコーディング情報、視点位置及び視線方向の情報を用いて”３ＤｏＦ＋”レンダリングを実行して表示用の”３ＤｏＦ＋”画像を生成する（ステップＳ２０４）。その後、表示情報生成部２０４は、”３ＤｏＦ＋”画像を送信して表示部２０５に表示させる視聴処理を実行する。
　これに対して、自装置の表示情報生成部２０４が”３ＤｏＦ＋”レンダリングに対応していない場合（ステップＳ２０１：否定）、ファイル処理部２０２は、ＩＳＯＢＭＦＦファイルをパースして、３ＤｏＦのポストデコーディング情報を取得する（ステップＳ２０５）。さらに、ファイル処理部２０２は、”３ＤｏＦ＋”のビットストリームをＩＳＯＢＭＦＦファイルから抽出する。そして、ファイル処理部２０２は、抽出した”３ＤｏＦ＋”のビットストリーム及び３ＤｏＦのポストデコーディング情報を復号処理部２０３へ出力し、テクスチャレイヤのエンコードを指示する。
　復号処理部２０３は、”３ＤｏＦ＋”のビットストリーム及び３ＤｏＦのポストデコーディング情報の入力をファイル処理部２０２から受ける。そして、復号処理部２０３は、”３ＤｏＦ＋”のビットストリームの３ＤｏＦレンダリングに用いる部分をデコードする（ステップＳ２０６）。すなわち、復号処理部２０３は、”３ＤｏＦ＋”のビットストリームのテクスチャレイヤをデコードする。その後、復号処理部２０３は、デコードしたビットストリームのデータ及び３ＤｏＦのポストデコーディング情報を表示情報生成部２０４へ出力する。
　表示情報生成部２０４は、ビットストリームのデータ及び３ＤｏＦのポストデコーディング情報の入力を復号処理部２０３から受ける。さらに、表示情報生成部２０４は、視点位置及び視線方向の入力を入力装置から受ける。そして。表示情報生成部２０４は、ポストデコーディング情報、視点位置及び視線方向の情報を用いて３ＤｏＦレンダリングを実行して表示用の３ＤｏＦ画像を生成する（ステップＳ２０７）。その後、表示情報生成部２０４は、３ＤｏＦ画像を送信して表示部２０５に表示させる視聴処理を実行する。
　以上に説明したように、本実施形態に係るファイル生成装置は、テクスチャレイヤ及びデプスレイヤを有するアトラスが格納されていることを表す情報をＩＳＯＢＭＦＦファイルに格納する。また、ファイル生成装置は、格納されたコンテンツが”３ＤｏＦ＋”ストリームか否かの情報及び視点位置毎のポストデコーディング情報をＩＳＯＢＭＦＦファイルに格納する。ポストデコーディング情報には、３ＤｏＦレンダリングが可能な視点位置を表す情報が格納される。これにより、クライアント装置は、”３ＤｏＦ＋”ストリームか否かを判定して、自装置の能力に対応したレイヤのデータを容易に取得できる。さらに、”３ＤｏＦ＋”レンダリングに対応していない場合、クライアント装置は、３ＤｏＦレンダリングにより表示用画像を生成することができる。したがって、クライアント装置の表示処理能力に応じた画像を提供して表示させることができ、利用者の視聴体験を拡大することができる。
［１．１　第１の実施形態の変形例］
　本変形例に係るファイル生成装置は、３ＤｏＦ領域と”３ＤｏＦ＋”領域とのそれぞれに関するポストデコーディング情報を個別のボックスに格納することが第１の実施形態と異なる。図２１は、第１の実施形態の変形例に係るＩＳＯＢＭＦＦファイルの一例を表す図である。
　ファイル生成部１０５は、図２１においてボックス３７１に示すようにSchemeTypeBoxにscheme_type=’podv’を格納する。これにより、ＯＭＡＦ　ed.1の構造に近づけることができる。そして、ファイル生成部１０５は、podvに３ＤｏＦ領域のポストデコーディング情報を格納する。このように構成することで、scheme_type=’podv’により、３ＤｏＦ領域のポストデコーディング情報が格納されていることが示される。さらに、ファイル生成部１０５は、podvにおけるrwpkを用いて３ＤｏＦ領域のレンダリングを可能とするための情報を格納する。
　また、ファイル生成部１０５は、ボックス３７２に示すようにCompatibleSchemeTypeBoxにscheme_type=’ecpp’を格納する。そして、ファイル生成部１０５は、ecppに”３ＤｏＦ＋”領域のポストデコーディング情報を格納する。さらに、ファイル生成部１０５は、povpにおけるpinfを用いて”３ＤｏＦ＋”領域のレンダリングを可能とする情報を格納する。ただし、ファイル生成部１０５は、povpにおけるpinfには、３ＤｏＦ領域及び”３ＤｏＦ＋”領域の両方のポストデコーディング情報を格納してもよい。
　以上に説明したように、本実施例に係るファイル生成装置は、３ＤｏＦ領域のポストコーディング情報と”３ＤｏＦ＋”領域のポストコーディング情報を異なるボックスに格納する。これにより、テクスチャレイヤが再生可能で”３ＤｏＦ＋”ストリームのデコードに対応しない場合にも、デプスレイヤを無視できるファイル生成装置であれば、３ＤｏＦ領域に制限してデコード及びレンダリングを行うことが可能となる。
［２．第２の実施形態］
　本実施形態に係るファイル生成装置は、テクスチャレイヤとデプスレイヤとを個別のトラックに格納することが第１の実施形態と異なる。本実施形態に係るファイル生成装置も、図２のブロック図で表される。以下の説明では、第１の実施形態と同様の各部の動作については説明を省略する場合がある。
　ファイル生成部１０５は、Ｌ－ＨＥＶＣ　storageの技術を利用して、テクスチャレイヤとデプスレイヤとを個別のトラックに格納する。図２２は、第２の実施形態に係るＩＳＯＢＭＦＦＦファイルの一例を表す図である。
　具体期には、ファイル生成部１０５は、ボックス４０１で示されるid=1のtrack　boxにテクスチャレイヤを格納する。また、ファイル生成部１０５は、ボックス４０２で示されるid=2のtrack　boxにデプスチャレイヤを格納する。そして、ファイル生成部１０５は、Track　referenceを用いて、ボックス４０２のデプスレイヤトラックから、ボックス４０１のテクスチャトラックが参照できるようにする。
　そして、ファイル生成部１０５は、ボックス４０１のテクスチャレイヤトラックにおいて、SchemeTyeBoxにscheme　type=’podv’を格納する。さらに、ファイル生成部１０５は、povdに３ＤｏＦ領域のポストデコーディング情報を格納する。この３ＤｏＦ領域のポストデコーディング情報が、「第１識別情報」の一例にあたる。このように構成することで、scheme_type=’podv’により、３ＤｏＦ領域のポストデコーディング情報が格納されていることが示される。さらに、ファイル生成部１０５は、rwpkを用いて３ＤｏＦ領域のレンダリングを可能とする情報を格納する。
　また、ファイル生成部１０５は、ボックス４０１のテクスチャレイヤトラックにおいて、CompatibleSchemeTyeBoxにscheme　type=’ecpp’を格納する。さらに、ファイル生成部１０５は、ボックス４０２のデプスレイヤトラックにscheme　type=’povp’を格納する。そして、ファイル生成部１０５は、povpに”３ＤｏＦ＋”領域のポストデコーディング情報を格納する。この”３ＤｏＦ＋”のポストデコーディング情報が、「第２識別情報」の一例にあたる。例えば、ファイル生成部１０５は、ボックス４０１のテクスチャレイヤトラックのpovpにおけるpinfに”３ＤｏＦ＋”領域のポストデコーディング情報を格納する。また、ファイル生成部１０５は、ボックス４０２のデプスレイヤトラックのpovpにおけるpinfに３ＤｏＦ領域及び”３ＤｏＦ＋”領域のポストデコーディング情報を格納する。
　クライアント装置２のファイル処理部２０２は、”３ＤｏＦ＋”ストリームのデコード及びレンダリングが可能な場合、テクスチャレイヤトラック及びデプスレイヤトラックの双方を用いて”３ＤｏＦ＋”映像の再生を行う。この場合、ファイル処理部２０２は、ボックス４０１のテクスチャレイヤトラックにおけるschiに格納されたpovpを参照して、”３ＤｏＦ＋””領域のポストデコーディング情報を取得する。
　一方、”３ＤｏＦ＋”ストリームのデコードに対応していない場合、ファイル処理部２０２は、テクスチャレイヤトラックに格納された３ＤｏＦ領域及び３ＤｏＦ領域のポストデコーディング情報を用いて３ＤｏＦ映像の再生を行う。
　以上に説明したように、本実施例に係るファイル生成装置は、テクスチャレイヤとデプスレイヤとを個別のトラックに格納する。これにより、”３ＤｏＦ＋”ストリームのデコードには対応していないクライアント装置であっても、テクスチャレイヤのトラックを使用して３ＤｏＦの全天球映像を再生することが可能となる。
［２．１　第２の実施形態の変形例］
　本変形例に係る配信システムでは、クライアント装置２が”３ＤｏＦ＋”レンダリングの際にデプスレイヤトラックにおけるschiに格納されたpropを参照することが第２の実施形態と異なる。以下に、本変形例に係るファイル生成装置１について説明する。
　ファイル生成装置１のファイル生成部１０５は、”３ＤｏＦ＋”レンダリングを行う場合にデプスレイヤトラックにおけるschiに格納されたpovpの参照を示すscheme_typeを新しく定義する。そして、ファイル生成部１０５は、テクスチャレイヤトラックにおけるCompatibleSchemeTypeBoxのscheme_typeとして新しく定義したscheme_typeを格納する。
　クライアント装置２のファイル処理部２０２は、”３ＤｏＦ＋”ストリームのデコード及びレンダリングが可能な場合、テクスチャレイヤトラック及びデプスレイヤトラックの双方を用いて”３ＤｏＦ＋”映像の再生を行う。この場合、ファイル処理部２０２は、テクスチャレイヤトラックにおけるCompatibleSchemeTypeBoxのsheme_typeを参照してデプスレイヤトラックにおけるschiに格納されたpovpの参照の指示を確認する。そして、ファイル処理部２０２は、デプスレイヤトラックにおけるschiに格納されたpovpを参照して、”３ＤｏＦ＋”領域のポストデコーディング情報を取得する。
　以上に説明したように、本実施例に係る配信システムでは、クライアント装置は、デプスレイヤトラックにおけるschiに格納されたpropを参照して”３ＤｏＦ＋”領域のポストデコーディング情報を取得し、”３ＤｏＦ＋”レンダリングを行う。これにより、ＯＭＡＦ　ed.1で規定されるprofileを満たすことが可能となる。
［３．第３の実施形態］
　本実施形態に係るファイル生成装置は、テクスチャレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とを分割してそれぞれ個別に１トラックに格納することが第２の実施形態と異なる。本実施形態に係るファイル生成装置も、図２のブロック図で表される。以下の説明では、第１及び第２の実施形態と同様の各部の動作については説明を省略する場合がある。
　ファイル生成部１０５は、テクスチャレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とを分割する。さらに、ファイル生成部１０５は、デプスレイヤにおけるテクスチャレイヤの”３ＤｏＦ＋”領域に対応する領域と３ＤｏＦ領域に対応する領域とを分割する。以下では、デプスレイヤにおけるテクスチャレイヤの”３ＤｏＦ＋”領域に対応する領域と３ＤｏＦ領域に対応する領域とを、それぞれ「デプスレイヤの”３ＤｏＦ＋”領域」及び「デプスレイヤの３ＤｏＦ領域」と呼ぶ。ファイル生成部１０５は、Track　referenceを用いて、テクスチャレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とを紐づける。また、ファイル生成部１０５は、Track　referenceを用いて、デプスレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とを紐づける。
　そして、ファイル生成部１０５は、図２３に示すように、テクスチャレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とをそれぞれの個別のトラック５０１及び５０３のMoovBoxに格納する。さらに、ファイル生成部１０５は、デプスレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とをそれぞれ個別のトラック５０２及び５０４のMoovBoxに格納する。図２３は、第３の実施形態に係るＩＳＯＢＭＦＦＦファイルの一例を表す図である。
　次に、ファイル生成部１０５は、各レイヤの分割情報を、他のトラックグループ５１０であるsub-picture　track　groupingに格納する。この場合、ファイル生成部１０５は、tile　base　track/tile　trackの仕組みにより、各レイヤの分割情報を格納してもよい。また、ファイル生成部１０５は、sub-picture　track　groupingには、元となるトラックであるベーストラックの一覧を登録する。例えば、トラック５０１及び５０３のテクスチャレイヤトラックをベーストラックとする場合、ファイル生成部１０５は、sub-picture　track　groupingにトラック５０１及び５０３のテクスチャレイヤトラックの情報を登録する。この場合、トラック５０１のテクスチャトラックにおけるSchemeTypeBoxのScheme_type=’podv’により、トラック５０１がテクスチャレイヤの３ＤｏＦ領域を格納したトラックであることが識別可能である。このScheme_type=’podv’によって表される３ＤｏＦ領域の情報であることを示す情報が「第１識別情報」の一例にあたる。また、このScheme_type=’povp’によって表される”３ＤｏＦ＋”領域の情報であることを示す情報が「第２識別情報」の一例にあたる。Scheme_type=’povp’は、アトラス処理部１０２により例えば、ポストデコーディング情報に含まれるようにアトラス処理部１０２により生成される。
　クライアント装置２のファイル処理部２０２は、”３ＤｏＦ＋”ストリームのデコード及びレンダリングが可能な場合、sub-picture　track　groupingを参照して、各レイヤの分割情報を取得し対応するトラックを特定する。そして、ファイル処理部２０２は、”３ＤｏＦ＋”領域及び３ＤｏＦ領域のテクスチャレイヤトラック及びデプスレイヤトラックを用いて”３ＤｏＦ＋”映像の再生を行う。
　一方、”３ＤｏＦ＋”ストリームのデコードに対応していない場合、ファイル処理部２０２は、トラック５０１のテクスチャトラックにおけるSchemeTypeBoxのScheme_type=’podv’を確認して、トラック５０１がテクスチャレイヤの３ＤｏＦ領域を格納したトラックと確認する。そして、ファイル処理部２０２は、トラック５０１の３ＤｏＦ領域のテクスチャレイヤトラックに格納された３ＤｏＦ領域及び３ＤｏＦ領域のポストデコーディング情報を用いて３ＤｏＦ映像の再生を行う。
　ここで、本実施例ではデプスレイヤも”３ＤｏＦ＋”領域及び３ＤｏＦ領域に分けたが、ファイル生成部１０５は、デプスレイヤを領域毎に分割せずに１トラックにまとめてもよい。
　他にも、ファイル生成部１０５は、デプスレイヤの”３ＤｏＦ＋”領域及び３ＤｏＦ領域とテクスチャレイヤの”３ＤｏＦ＋”領域とを１つのトラックにまとめてもよい。この場合、ファイル生成部１０５は、デプスレイヤの”３ＤｏＦ＋”領域及び３ＤｏＦ領域とテクスチャレイヤの”３ＤｏＦ＋”領域とをまとめたトラックに、テクスチャレイヤ用とデプスレイヤ用との２つのProjectionInfoBoxを格納する。
　さらに、ファイル生成部１０５は、”３ＤｏＦ＋”領域を、各視点位置を構成するパッチ群毎に分割して、個別にトラックに格納することもできる。この場合、ファイル生成部１０５は、各トラックにViewingSpaceBoxを格納し、トラックが格納するストリーム視聴時の視点の移動可能範囲を登録することも可能である。
　以上に説明したように、本実施例に係るファイル生成装置は、テクスチャレイヤの”３ＤｏＦ＋”領域と３ＤｏＦ領域とを分割してそれぞれ個別に１トラックに格納する。これにより、”３ＤｏＦ＋”ストリームのデコードには対応していないクライアント装置であっても、テクスチャレイヤの３ＤｏＦ領域を格納したトラックを使用して３ＤｏＦの全天球映像を再生することが可能となる。また、ＯＭＡＦ　ed.1で規定されるprofileを満たすことが可能となる。
［３．１　第３の実施形態の変形例（１）］
　本変形例に係る配信システムでは、sub-picture　track　groupingに各トラックに格納されたストリームがテクスチャレイヤの３ＤｏＦ領域か否かを表す情報することが第２の実施形態と異なる。以下に、本変形例に係るファイル生成装置１について説明する。
　図２４は、第３の実施形態の変形例（１）に係るsub-picture　track　groupingのシンタックスの一例を示す図である。ファイル生成部１０５は、図２４に示すように、sub-picture　track　groupingにおいて、格納されたストリームがテクスチャレイヤの３ＤｏＦ領域であることを表すThreeDoFCompatibleBox()を格納する。ThreeDoFCompatibleBox()は空であり、このThreeDoFCompatibleBox()が存在するトラックが格納するストリームがテクスチャレイヤの３ＤｏＦ領域であることを表す。
　ここで、本変形例では、ThreeDoFCompatibleBox()を用いてトラックが格納するストリームがテクスチャレイヤの３ＤｏＦ領域であることを表したが、ファイル生成部１０５は、新規フィールドを定義して、そのフィールドに同様の情報を格納してもよい。
［３．２　第３の実施形態の変形例（２）］
　さらに、第３の実施形態及びその変形例（１）では、符号化部１０３は、マルチレイヤＨＥＶＣを用いて符号化を行ったが、ＨＥＶＣ／ＡＶＣ（Advanced　Video　Coding）を用いてテクスチャレイヤ及びデプスレイヤを符号化することも可能である。これは、第２の実施形態及びその変形例についても同様である。この場合、各ストリームに対する”３ＤｏＦ＋”メタデータをtimed　metadataとして表し、個別のtrackに格納し、テクスチャレイヤ及びデプスレイヤを格納するトラックにtrack　referenceによって紐づける。
　ファイル生成部１０５は、テクスチャレイヤ及びデプスレイヤの識別情報、アトラスを構成するレイヤペアの関連付け情報を、ＩＳＯＢＭＦＦ／Elementary　Stream（ＳＥＩ）を拡張して格納する。これにより、Ｌ－ＨＥＶＣ　storageにおいてoinf/oref/sbasにより格納されていた情報が、ＨＥＶＣ／ＡＶＣに適用可能となる。ファイル生成部１０５は、その他の情報については、ＨＥＶＣ／ＡＶＣにおいてもＬ－ＨＥＶＣ　storageと同様に格納可能である。
　以上に説明したように、ＨＥＶＣ／ＡＶＣを用いることで、一般的に市場で流通するデコーダを利用することが可能となる。また、”３ＤｏＦ＋”ストリームのデコードに対応していないクライアント装置であっても、テクスチャレイヤトラックのデコード及びレンダリングを行うことができる。
［４．第４の実施形態］
　以上に説明した各実施形態及びそれらの各変形例では、ビットストリームを格納するフォーマットとしてＩＳＯＢＭＦＦを用いたが、これ以外のフォーマットを用いることも可能である。
　例えば、ファイル生成部１０５は、図２５に示すフォーマットを有するMatroska　Media　Containerを用いることも可能である。図２５は、Matroska　Media　Containerのフォーマットを表す図である。この場合、ファイル生成部１０５は、テクスチャレイヤ及びデプスレイヤの識別情報及びアトラスＩＤとレイヤペアとを紐づける情報を、Trak　Entry　elementの下の新たに定義したelementとして格納する。さらに、ファイル生成部１０５は、ＩＳＯＢＭＦＦファイルにおいてProjectionInfoBox()に格納されるポストデコーディング情報も、Trak　Entry　elementの下の新たに定義したelementとして格納する。
　このように、ＩＳＯＢＭＦＦ以外のフォーマットを用いてもセグメントファイルを生成することが可能であり、その場合でも、各実施形態及びそれらの各変形例と同様の効果を得ることが可能である。
　以上、本開示の実施形態について説明したが、本開示の技術的範囲は、上述の実施形態そのままに限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また他の効果があってもよい。
　なお、本技術は以下のような構成を取ることもできる。
（１）３次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準２次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”３ＤｏＦ＋”領域の情報であることを示す第１ポストデコーディング情報を含む、各前記基準２次元画像及び各前記移動２次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成するアトラス処理部と、
　テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する符号化部と、
　前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成するファイル生成部と
　を備えた情報処理装置。
（２）前記ファイル生成部は、前記アトラス識別情報を、ＩＳＯＢＭＦＦファイルにおけるMoovのsgpd’oinf’に格納する付記（１）に記載の情報処理装置。
（３）前記ファイル生成部は、前記テクスチャレイヤ及び前記デプスレイヤにＩＳＯＢＭＦＦファイルのトラックを割り当て、前記テクスチャレイヤ及び前記デプスレイヤに割り当てた前記トラックにおける第１のBoxに前記第１ポストデコーディング情報を格納する付記（１）又は（２）に記載の情報処理装置。
（４）前記アトラス処理部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域の情報を含む第２ポストデコーディング情報を前記ポストデコーディング情報に含ませる付記（３）に記載の情報処理装置。
（５）前記アトラス処理部は、前記第２ポストデコーディング情報に前記３ＤｏＦ領域の情報であることを示す情報を含ませる付記（４）に記載の情報処理装置。
（６）前記ファイル生成部は、前記第２ポストデコーディング情報を、前記ＩＳＯＢＭＦＦファイルにおける前記第１のBoxが割り当てられた前記トラックにおける前記第１のBoxとは異なる第２のBoxに格納する付記（３）に記載の情報処理装置。
（７）前記ファイル生成部は、前記テクスチャレイヤと前記デプスレイヤとをそれぞれＩＳＯＢＭＦＦファイルの異なるトラックに割り当て、且つ、各前記トラックはTrack　referenceで紐づけられる付記（１）又は（２）に記載の情報処理装置。
（８）前記アトラス処理部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域の情報が前記レンダリングの対象に含まれるか否かを示す第１識別情報を前記ポストデコーディング情報に含ませる付記（７）に記載の情報処理装置。
（９）前記ファイル生成部は、前記第１識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるScheme　Type　Boxに格納する付記（８）に記載の情報処理装置。
（１０）前記アトラス処理部は、前記”３ＤｏＦ＋”領域の情報が前記レンダリングの対象に含まれるか否かを示す第２識別情報を前記ポストデコーディング情報に含ませる付記（７）に記載の情報処理装置。
（１１）前記ファイル生成部は、前記第２識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるCompatible　Scheme　Type　Boxに格納する付記（１０）に記載の情報処理装置。
（１２）前記ファイル生成部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域と、前記”３ＤｏＦ＋”領域と、前記３ＤｏＦ領域に対応する前記デプス画像の第１領域と、前記”３ＤｏＦ＋”領域に対応する前記デプス画像の第２領域とのそれぞれに、ＩＳＯＢＭＦＦファイルにおける異なるトラックを割り当て、前記３ＤｏＦ領域と前記”３ＤｏＦ＋”領域とが割り当てられた各前記トラックそれぞれ、及び、前記第１領域と前記第２領域とが割り当てられた各前記トラックそれぞれに、”３ＤｏＦ＋”メタデータを格納するトラックをTrack　referenceで紐付ける付記（１）又は（２）に記載の情報処理装置。
（１３）前記アトラス処理部は、前記レンダリングの対象が前記３ＤｏＦ領域の情報であることを表す第１識別情報を前記ポストデコーディング情報に含ませる付記（１２）に記載の情報処理装置。
（１４）前記ファイル生成部は、前記アトラス識別情報のうちの前記３ＤｏＦ領域に関する情報を前記テクスチャレイヤの前記３ＤｏＦ領域に割り当てられたトラックにおけるMoov　Boxに格納する付記（１３）に記載の情報処理装置。
（１５）前記ファイル生成部は、前記第１識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記（１３）に記載の情報処理装置。
（１６）前記アトラス処理部は、前記レンダリングの対象が前記”３ＤｏＦ＋”領域の情報であることを表す第２識別情報を前記ポストデコーディング情報に含ませる付記（１２）に記載の情報処理装置。
（１７）前記ファイル生成部は、前記アトラス識別情報のうちの前記”３ＤｏＦ＋”領域に関する情報を前記テクスチャレイヤの前記”３ＤｏＦ＋”領域に割り当てられたトラックにおけるMoov　Boxに格納する付記（１６）に記載の情報処理装置。
（１８）前記ファイル生成部は、前記第２識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記（１６）に記載の情報処理装置。
（１９）３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報を生成し、
　テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成し、
　前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記テクスチャ画像における前記ポストデコーディング情報を含むファイルを生成する
　処理をコンピュータに実行させる情報処理方法。
（２０）３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得するファイル取得部と、
　前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定するファイル処理部と、
　前記ファイル処理部により決定された前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成する復号処理部と、
　前記復号処理部により生成された画像を基に、前記画像生成方法にしたがって表示画像を生成する表示情報生成部と
　を備えた再生処理装置。
（２１）３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得し、
　前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定し、
　決定した前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成し、
　生成した画像を基に、前記画像生成方法にしたがって表示画像を生成する
　処理をコンピュータに実行させる再生処理方法。
　１　ファイル生成装置
　２　クライアント装置
　３　Ｗｅｂサーバ
　４　ネットワーク
　１０　生成処理部
　１１　制御部
　２０　再生処理部
　２１　制御部
　１０１　データ入力部
　１０２　アトラス処理部
　１０３　符号化部
　１０４　ビットストリーム生成部
　１０５　ファイル生成部
　１０６　送信部
　２０１　ファイル取得部
　２０２　ファイル処理部
　２０３　復号処理部
　２０４　表示情報生成部
　２０５　表示部
　２２０　抽出部
　２３０　デコーダ
　２４１　アトラス分解部
　２４２　表示処理部

Claims (21)

  1. 　３次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準２次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”３ＤｏＦ＋”領域の情報であることを示す第１ポストデコーディング情報を含む、各前記基準２次元画像及び各前記移動２次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成するアトラス処理部と、
    　テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する符号化部と、
    　前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成するファイル生成部と
    　を備えた情報処理装置。
  2. 　前記ファイル生成部は、前記アトラス識別情報を、ＩＳＯＢＭＦＦファイルにおけるMoovのsgpd’oinf’に格納する請求項１に記載の情報処理装置。
  3. 　前記ファイル生成部は、前記テクスチャレイヤ及び前記デプスレイヤにＩＳＯＢＭＦＦファイルのトラックを割り当て、前記テクスチャレイヤ及び前記デプスレイヤに割り当てた前記トラックにおける第１のBoxに前記第１ポストデコーディング情報を格納する請求項１に記載の情報処理装置。
  4. 　前記アトラス処理部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域の情報を含む第２ポストデコーディング情報を前記ポストデコーディング情報に含ませる請求項３に記載の情報処理装置。
  5. 　前記アトラス処理部は、前記第２ポストデコーディング情報に前記３ＤｏＦ領域の情報であることを示す情報を含ませる請求項４に記載の情報処理装置。
  6. 　前記ファイル生成部は、前記第２ポストデコーディング情報を、前記ＩＳＯＢＭＦＦファイルにおける前記第１のBoxが割り当てられた前記トラックにおける前記第１のBoxとは異なる第２のBoxに格納する請求項３に記載の情報処理装置。
  7. 　前記ファイル生成部は、前記テクスチャレイヤと前記デプスレイヤとをそれぞれＩＳＯＢＭＦＦファイルの異なるトラックに割り当て、且つ、各前記トラックはTrack　referenceで紐づけられる請求項１に記載の情報処理装置。
  8. 　前記アトラス処理部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域の情報が前記レンダリングの対象に含まれるか否かを示す第１識別情報を前記ポストデコーディング情報に含ませる請求項７に記載の情報処理装置。
  9. 　前記ファイル生成部は、前記第１識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるScheme　Type　Boxに格納する請求項８に記載の情報処理装置。
  10. 　前記アトラス処理部は、前記”３ＤｏＦ＋”領域の情報が前記レンダリングの対象に含まれるか否かを示す第２識別情報を前記ポストデコーディング情報に含ませる請求項７に記載の情報処理装置。
  11. 　前記ファイル生成部は、前記第２識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるCompatible　Scheme　Type　Boxに格納する請求項１０に記載の情報処理装置。
  12. 　前記ファイル生成部は、前記テクスチャ画像における前記基準２次元画像が格納される３ＤｏＦ領域と、前記”３ＤｏＦ＋”領域と、前記３ＤｏＦ領域に対応する前記デプス画像の第１領域と、前記”３ＤｏＦ＋”領域に対応する前記デプス画像の第２領域とのそれぞれに、ＩＳＯＢＭＦＦファイルにおける異なるトラックを割り当て、前記３ＤｏＦ領域と前記”３ＤｏＦ＋”領域とが割り当てられた各前記トラックそれぞれ、及び、前記第１領域と前記第２領域とが割り当てられた各前記トラックそれぞれに、”３ＤｏＦ＋”メタデータを格納するトラックをTrack　referenceで紐付ける請求項１に記載の情報処理装置。
  13. 　前記アトラス処理部は、前記レンダリングの対象が前記３ＤｏＦ領域の情報であることを表す第１識別情報を前記ポストデコーディング情報に含ませる請求項１２に記載の情報処理装置。
  14. 　前記ファイル生成部は、前記アトラス識別情報のうちの前記３ＤｏＦ領域に関する情報を前記テクスチャレイヤの前記３ＤｏＦ領域に割り当てられたトラックにおけるMoov　Boxに格納する請求項１３に記載の情報処理装置。
  15. 　前記ファイル生成部は、前記第１識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する請求項１３に記載の情報処理装置。
  16. 　前記アトラス処理部は、前記レンダリングの対象が前記”３ＤｏＦ＋”領域の情報であることを表す第２識別情報を前記ポストデコーディング情報に含ませる請求項１２に記載の情報処理装置。
  17. 　前記ファイル生成部は、前記アトラス識別情報のうちの前記”３ＤｏＦ＋”領域に関する情報を前記テクスチャレイヤの前記”３ＤｏＦ＋”領域に割り当てられたトラックにおけるMoov　Boxに格納する請求項１６に記載の情報処理装置。
  18. 　前記ファイル生成部は、前記第２識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する請求項１６に記載の情報処理装置。
  19. 　３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報を生成し、
    　テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成し、
    　前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記テクスチャ画像における前記ポストデコーディング情報を含むファイルを生成する
    　処理をコンピュータに実行させる情報処理方法。
  20. 　３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得するファイル取得部と、
    　前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定するファイル処理部と、
    　前記ファイル処理部により決定された前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成する復号処理部と、
    　前記復号処理部により生成された画像を基に、前記画像生成方法にしたがって表示画像を生成する表示情報生成部と
    　を備えた再生処理装置。
  21. 　３次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準２次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動２次元画像を前記基準２次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”３ＤｏＦ＋”領域の情報である第１ポストデコーディング情報を含む前記基準２次元画像及び前記移動２次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得し、
    　前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定し、
    　決定した前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成し、
    　生成した画像を基に、前記画像生成方法にしたがって表示画像を生成する
    　処理をコンピュータに実行させる再生処理方法。
PCT/JP2020/014888 2019-06-28 2020-03-31 情報処理装置、情報処理方法、再生処理装置及び再生処理方法 WO2020261690A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/615,586 US20220247991A1 (en) 2019-06-28 2020-03-31 Information processing apparatus, information processing method, reproduction processing device, and reproduction processing method
CN202080045603.7A CN114009054A (zh) 2019-06-28 2020-03-31 信息处理装置、信息处理方法、再现处理装置和再现处理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962868497P 2019-06-28 2019-06-28
US62/868,497 2019-06-28

Publications (1)

Publication Number Publication Date
WO2020261690A1 true WO2020261690A1 (ja) 2020-12-30

Family

ID=74061358

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/014888 WO2020261690A1 (ja) 2019-06-28 2020-03-31 情報処理装置、情報処理方法、再生処理装置及び再生処理方法

Country Status (3)

Country Link
US (1) US20220247991A1 (ja)
CN (1) CN114009054A (ja)
WO (1) WO2020261690A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113792150A (zh) * 2021-11-15 2021-12-14 湖南科德信息咨询集团有限公司 一种人机协同的智能需求识别方法和***

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4327561A1 (en) * 2021-04-19 2024-02-28 Nokia Technologies Oy Method, apparatus and computer program product for signaling information of a media track
CN116800987A (zh) * 2022-03-14 2023-09-22 中兴通讯股份有限公司 数据处理方法、装置、设备、存储介质及程序产品

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012510102A (ja) * 2008-11-24 2012-04-26 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 三次元ｇｕｉにおける二次元グラフィックスの拡張
WO2018215502A1 (en) * 2017-05-23 2018-11-29 Koninklijke Kpn N.V. Coordinate mapping for rendering panoramic scene
US20190068946A1 (en) * 2017-08-29 2019-02-28 Qualcomm Incorporated Processing omnidirectional media with dynamic region-wise packing
EP3474562A1 (en) * 2017-10-20 2019-04-24 Thomson Licensing Method, apparatus and stream for volumetric video format

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110090305A1 (en) * 2009-02-19 2011-04-21 Wataru Ikeda Recording medium, playback device, and integrated circuit
US9357199B2 (en) * 2013-01-04 2016-05-31 Qualcomm Incorporated Separate track storage of texture and depth views for multiview coding plus depth
US10306273B2 (en) * 2013-07-19 2019-05-28 Sony Corporation Information processing device and method for generating partial image information including group identification information
US10034010B2 (en) * 2015-10-14 2018-07-24 Qualcomm Incorporated Alignment of operation point sample group in multi-layer bitstreams file format
EP3376761B1 (en) * 2015-11-11 2021-10-13 Sony Group Corporation Image processing device and image processing method
CN108476346B (zh) * 2016-01-13 2021-03-12 索尼公司 信息处理装置和信息处理方法
US10290119B2 (en) * 2016-09-15 2019-05-14 Sportsmedia Technology Corporation Multi view camera registration
US11514613B2 (en) * 2017-03-16 2022-11-29 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs
WO2019002662A1 (en) * 2017-06-26 2019-01-03 Nokia Technologies Oy APPARATUS, METHOD AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO
EP3682632B1 (en) * 2017-09-15 2023-05-03 InterDigital VC Holdings, Inc. Methods and devices for encoding and decoding 3d video stream
EP3457688A1 (en) * 2017-09-15 2019-03-20 Thomson Licensing Methods and devices for encoding and decoding three degrees of freedom and volumetric compatible video stream
EP3481067A1 (en) * 2017-11-07 2019-05-08 Thomson Licensing Method, apparatus and stream for encoding/decoding volumetric video
EP3489900A1 (en) * 2017-11-23 2019-05-29 Thomson Licensing Method, apparatus and stream for encoding/decoding volumetric video
EP3496388A1 (en) * 2017-12-05 2019-06-12 Thomson Licensing A method and apparatus for encoding a point cloud representing three-dimensional objects
EP3595319A1 (en) * 2018-07-12 2020-01-15 InterDigital VC Holdings, Inc. Methods and apparatus for volumetric video transport
KR20200111643A (ko) * 2019-03-19 2020-09-29 한국전자통신연구원 이머시브 영상 처리 방법 및 이머시브 영상 합성 방법
EP3716628A1 (en) * 2019-03-29 2020-09-30 InterDigital CE Patent Holdings A method and apparatus for encoding and decoding volumetric video
WO2020232281A1 (en) * 2019-05-14 2020-11-19 Intel Corporation IMMERSIVE VIDEO CODING TECHNIQUES FOR THREE DEGREE OF FREEDOM PLUS/METADATA FOR IMMERSIVE VIDEO (3DoF+/MIV) AND VIDEO-POINT CLOUD CODING (V-PCC)

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012510102A (ja) * 2008-11-24 2012-04-26 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 三次元ｇｕｉにおける二次元グラフィックスの拡張
WO2018215502A1 (en) * 2017-05-23 2018-11-29 Koninklijke Kpn N.V. Coordinate mapping for rendering panoramic scene
US20190068946A1 (en) * 2017-08-29 2019-02-28 Qualcomm Incorporated Processing omnidirectional media with dynamic region-wise packing
EP3474562A1 (en) * 2017-10-20 2019-04-24 Thomson Licensing Method, apparatus and stream for volumetric video format

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113792150A (zh) * 2021-11-15 2021-12-14 湖南科德信息咨询集团有限公司 一种人机协同的智能需求识别方法和***
CN113792150B (zh) * 2021-11-15 2022-02-11 湖南科德信息咨询集团有限公司 一种人机协同的智能需求识别方法和***

Also Published As

Publication number Publication date
US20220247991A1 (en) 2022-08-04
CN114009054A (zh) 2022-02-01

Similar Documents

Publication Publication Date Title
US11805304B2 (en) Method, device, and computer program for generating timed media data
JP6960528B2 (ja) メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム
US20240040170A1 (en) Method, device, and computer program for transmitting media content
WO2020261690A1 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
CN110800311B (zh) 用于传输媒体内容的方法、装置和计算机程序
JP7133038B2 (ja) メディアコンテンツを送信する方法、装置及びコンピュータプログラム
BR112019010875A2 (pt) sistemas e métodos de sinalização de regiões de interesse
GB2561026A (en) Method and apparatus for generating media data
GB2509953A (en) Displaying a Region of Interest in a Video Stream by Providing Links Between Encapsulated Video Streams
KR20210019017A (ko) 컨텐츠의 처리 방법 및 장치
US12015756B2 (en) Multi-view video processing method and apparatus
WO2022054744A1 (ja) 情報処理装置および方法
US11974028B2 (en) Information processing device, information processing method, reproduction processing device, and reproduction processing method

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: 20830566

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20830566

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP