WO2020261690A1 - 情報処理装置、情報処理方法、再生処理装置及び再生処理方法 - Google Patents
情報処理装置、情報処理方法、再生処理装置及び再生処理方法 Download PDFInfo
- 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
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
アトラス処理部は、3次元データを所定の視点位置から複数の投影方向に投影して形成される各投影方向に対応する基準2次元画像及び所定の視点位置から限定範囲内で移動させた視点位置に基づく移動2次元画像を基準2次元画像から生成するための補完画像を形成するテクスチャ画像と、テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、テクスチャ画像における補完画像が格納される"3DoF+"領域の情報であることを示す第1ポストデコーディング情報を含む、各基準2次元画像及び各移動2次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成する。符号化部は、テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する。ファイル生成部は、テクスチャレイヤ、デプスレイヤ、アトラス識別情報及びポストデコーディング情報を含むファイルを生成する。
Description
本発明は、情報処理装置、情報処理方法、再生処理装置及び再生処理方法に関する。
HTTP(Hypertext Transfer Protocol)によるアダプティブなコンテンツ配信技術の標準化規格として、MPEG-DASH(Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP)が存在する。また、MPEG-DASHのファイルフォーマットにおける動画圧縮の国際標準技術である「MPEG-4」のファイルコンテナ仕様として、ISOBMFF(International Organization for Standardization Base Media File Format)がある。
ところで、全天球映像のように、水平方向の周囲360度および垂直方向の周囲180度の画像を立体構造に投影した画像である立体構造画像を、平面画像にマッピングした全天球画像を再生する映像がある。全天球映像は3DoF映像とも呼ばれ、全天球画像は投影平面画像や3DoF(Degrees of Freedom)画像とも呼ばれる。MPEG-I OMAF(Omnidirectional Media Format)では、全天球画像を形成する立体構造画像の配信へのMPEG-DASHの利用が検討されている。
さらに近年、3DoF映像において実行可能な3軸周りの周囲見回しに加えて、限定範囲内での視点平行移動を伴う映像視聴体験を提供することができる”3DoF+”(Degrees of Freedom Plus)映像の配信も検討されている。MPEG-I Phase 1b requirementにおいては、”3DoF+”に関連する要件として、OMAF edition.1規格に準拠するplayer(OMAF ed.1 player)への後方互換性の提供がリストアップされており、この要件を満たす技術開発が進められている。
”3DoF+”の映像視聴体験を提供するデータは、”3DoF+”ストリームと呼ばれる。”3DoF+”ストリームは、テクスチャレイヤ(texture Layer)、デプスレイヤdepth Layer及び”3DoF+”メタデータを構成要素として含む。テクスチャレイヤは、”3DoF+”映像をレンダリングするためのテクスチャのパッチの集合である。また、デプスレイヤは、”3DoF+”映像をレンダリングするためのデプスのパッチの集合である。また、”3DoF+”メタデータは、各パッチが見える視点位置情報などを含む。クライアント装置は、”3DoF+”メタデータを基に、テクスチャレイヤ及びデプスレイヤから視聴映像のレンダリングに用いるパッチを選択してレンダリングすることで”3DoF+”映像の再生を行う。
また、”3DoF+”ストリームにおけるテクスチャレイヤは、3DoF領域と呼ばれる3DoF視聴が可能な領域と、3DoF領域に追加することで”3DoF+”視聴が可能となる”3DoF+”領域とを有する。このようなテクスチャレイヤを有することで、”3DoF+”ストリームのテクスチャレイヤのうちの3DoF領域をレンダリングして3DoF画像を生成することが可能となる。すなわち、”3DoF+”映像の再生能力は有さないが3DoFレンダリング機能を備えたクライアント装置であっても、”3DoF+”ストリームから3DoF映像を生成するという利用方法が考えられる。
"ISO/IEC 14496-12:2015", Information technology. Coding of audio-visual objects. Part12:ISO base media file format, 2015-12
しかしながら、”3DoF+”ストリームにおける3DoF領域をレンダリングする場合、クライアント装置は、”3DoF+”全体のレンダリングの処理を行った上で、特定視点位置から見た3DoF映像を出力する処理を行う。そのため、実際には、”3DoF+”映像の再生能力は有さないが3DoFレンダリング機能を備えたクライアント装置では、”3DoF+”ストリームを用いて3DoF映像を再生することは困難である。そのため、利用者の視聴体験は制限を受けることになる。
そこで、本開示では、利用者の視聴体験を拡大することができる情報処理装置、情報処理方法、再生処理装置及び再生処理方法を提供する。
本開示によれば、アトラス処理部は、3次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準2次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”3DoF+”領域の情報であることを示す第1ポストデコーディング情報を含む、各前記基準2次元画像及び各前記移動2次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成する。符号化部は、テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する。ファイル生成部は、前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成する。
以下に、本開示の実施形態について図面に基づいて詳細に説明する。なお、以下の各実施形態において、同一の部位には同一の符号を付することにより重複する説明を省略する。また、本技術で開示される範囲は、実施形態の内容に限定されるものではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
非特許文献1:(上述)
非特許文献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
非特許文献3:"ISO/IEC 23090-2:2019", Information technology. Coded representation of immersive media, Part2:Omnidirecrional media format, 2019-01
非特許文献4:N17331, Requirements MPEG-I phase 1b, version 1, 2018-02-22
非特許文献5:M48024, Strawman Design for ”3DoF+”, version 2, 2019-03-28
非特許文献6:M47544, Extensions to Technicolor Intel Response to ”3DoF” CfP, version 2, 2019-03-22
非特許文献7:N18464, Working Draft 1 of Metadata for Immersive Media (Video), version 1, 2019-04-26
非特許文献8:”Matroska Media Container”, [令和2年2月27日検索], インターネット <URL : https://www.matroska.org/>
非特許文献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
非特許文献3:"ISO/IEC 23090-2:2019", Information technology. Coded representation of immersive media, Part2:Omnidirecrional media format, 2019-01
非特許文献4:N17331, Requirements MPEG-I phase 1b, version 1, 2018-02-22
非特許文献5:M48024, Strawman Design for ”3DoF+”, version 2, 2019-03-28
非特許文献6:M47544, Extensions to Technicolor Intel Response to ”3DoF” CfP, version 2, 2019-03-22
非特許文献7:N18464, Working Draft 1 of Metadata for Immersive Media (Video), version 1, 2019-04-26
非特許文献8:”Matroska Media Container”, [令和2年2月27日検索], インターネット <URL : https://www.matroska.org/>
つまり、上述の非特許文献に記載されている内容も、参照により本明細書に組み込まれる。つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、非特許文献1~3及び8に記載されているFile Structureや、非特許文献5~7に記載されている”3DoF+”ストリーム構造で用いられている用語が発明の詳細な説明において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。また、例えば、パース(Parsing)、シンタックス(Syntax)、セマンティクス(Semantics)等の技術用語についても同様に、発明の詳細な説明において直接的に定義されていない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
また、以下に示す項目順序に従って本開示を説明する。
また、以下に示す項目順序に従って本開示を説明する。
1.第1の実施形態
1.1 第1の実施形態の変形例
2.第2の実施形態
2.1 第2の実施形態の変形例
3.第3の実施形態
3.1 第3の実施形態の変形例(1)
3.2 第3の実施形態の変形例(2)
4.第4の実施形態
1.1 第1の実施形態の変形例
2.第2の実施形態
2.1 第2の実施形態の変形例
3.第3の実施形態
3.1 第3の実施形態の変形例(1)
3.2 第3の実施形態の変形例(2)
4.第4の実施形態
[1.第1の実施形態]
”3DoF+”ストリームは、テクスチャレイヤ、デプスレイヤ及び”3DoF+”メタデータを含む。”3DoF+”メタデータは、詳しくは、カメラパラメータ及びアトラスパラメータリストメタデータを有する。カメラパラメータは、各パッチが見える視点位置情報である。また、アトラスパラメータリストメタデータは、パッチ毎の表示位置とコーデックピクチャ上の位置間のマッピング情報を表す。対応するテクスチャレイヤ及びデプスレイヤの組となるレイヤペアがアトラスと呼ばれる。
”3DoF+”ストリームは、テクスチャレイヤ、デプスレイヤ及び”3DoF+”メタデータを含む。”3DoF+”メタデータは、詳しくは、カメラパラメータ及びアトラスパラメータリストメタデータを有する。カメラパラメータは、各パッチが見える視点位置情報である。また、アトラスパラメータリストメタデータは、パッチ毎の表示位置とコーデックピクチャ上の位置間のマッピング情報を表す。対応するテクスチャレイヤ及びデプスレイヤの組となるレイヤペアがアトラスと呼ばれる。
そして、”3DoF+”ストリームのテクスチャレイヤは、3DoF領域と”3DoF+”領域を含む。”3DoF+”領域には、細かいパッチが格納されており、各パッチには3DoF領域をレンダリングして形成される画像の別の角度からの映像に用いる情報が含まれる。
”3DoF+”ストリームは、マルチレイヤ(Multi-layer)HEVC(High Efficiency Video Codec)で符号化される。マルチレイヤHEVCは、1つのストリームの中に低解像度のレイヤと高解像度のレイヤとのように複数のレイヤを含む符号化方法である。”3DoF+”メタデータは、例えばSEI(Supplemental Enhancement Information)としてビットストリーム(bitstream)に格納される。ビットストリームは、”3DoF+”ストリームを形成する”3DoF+”画像のデータである。そして、HEVCのメタデータの1種であるVPS(Video Parameter Set)が拡張され、各レイヤにアトラスフラグが付与されることで、アトラスを構成するレイヤペアを識別することが可能となる。
ここで、再生処理装置が3DoFレンダリング機能を備えるが”3DoF+”映像の再生能力は有さない場合について考える。以下では、3DoFレンダリング機能を備えるが”3DoF+”映像の再生能力は有さない再生処理装置を、3DoF再生処理装置という。3DoF再生処理装置には、いくつか種類が考えられる。例えば、”3DoF+”ストリームをデコードできるが、レンダリング能力や機能の制約から3DoFレンダリングは行えるが、”3DoF+”映像のレンダリングには対応していない3DoF再生処理装置がある。また、例えば、OMAF ed.1 playerなどの”3DoF+”ストリームのデコード及びレンダリングのいずれの機能も有さない3DoF再生処理装置がある。
”3DoF+”ストリームのテクスチャレイヤは、3DoF領域及び”3DoF+”領域を含むため、3DoF再生処理装置は、”3DoF+”ストリームのテクスチャレイヤのうちの3DoF領域に限定してレンダリングを行うという場合が考えられる。このような処理を行うことが可能であれば、再生能力の異なる再生処理装置でも、同一の”3DoF+”ストリームを再生能力に合わせて適切に再生することができ、再生処理装置の再生能力毎にストリームを用意しなくてもよくなる。これにより、例えば、配信時の配信サーバが有するCDN(Content Delivery Network)ストレージを節約でき、且つ、再生処理装置が再生可能なコンテンツを増やすことができる。なおMPEG-I Phase 1bの”3DoF+”に関する技術要件においても、この場合の対応が求められている。
しかしながら、”3DoF+”ストリームに含まれる3DoF領域をレンダリングする場合、3DoF対応のクライアント装置2は、一度”3DoF+”でレンダリングを行い、その上で、特定視点位置から見た3DoF映像のみを出力する処理を行うことになる。これは、3DoF対応のクライアント装置2では、”3DoF+”ストリームの処理が困難であることを意味する。すなわち、今までの”3DoF+”コンテンツの配信システムでは、上述したメリットを享受することが困難である。そこで、以下に、3DoF再生処理装置が配信された”3DoF+”コンテンツを再生可能となる配信システムについて説明する。
[第1の実施形態に係るシステムの構成]
図1は、配信システムの一例のシステム構成図である。配信システム100は、情報処理装置であるファイル生成装置1、再生処理装置であるクライアント装置2及びWebサーバ3を含む。ファイル生成装置1、クライアント装置2及びWebサーバ3は、ネットワーク4に接続される。そして、ファイル生成装置1、クライアント装置2及びWebサーバ3は、ネットワーク4を介して相互に通信可能である。ここで、図1においては、各装置を1台ずつ示しているが、配信システム100は、ファイル生成装置1及びクライアント装置2をそれぞれ複数台含んでもよい。
図1は、配信システムの一例のシステム構成図である。配信システム100は、情報処理装置であるファイル生成装置1、再生処理装置であるクライアント装置2及びWebサーバ3を含む。ファイル生成装置1、クライアント装置2及びWebサーバ3は、ネットワーク4に接続される。そして、ファイル生成装置1、クライアント装置2及びWebサーバ3は、ネットワーク4を介して相互に通信可能である。ここで、図1においては、各装置を1台ずつ示しているが、配信システム100は、ファイル生成装置1及びクライアント装置2をそれぞれ複数台含んでもよい。
ファイル生成装置1は、”3DoF+”映像を提供するデータである”3DoF+”ストリームを生成する。ファイル生成装置1は、生成した”3DoF+”ストリームをWebサーバ3にアップロードする。ここで、本実施形態では、Webサーバ3が”3DoF+”ストリームをクライアント装置2に提供する構成について説明するが、配信システム100は他の構成を採ることも可能である。例えば、ファイル生成装置1が、Webサーバ3の機能を含み、生成した”3DoF+”ストリームを自装置内に格納し、クライアント装置2に提供する構成であってもよい。
Webサーバ3は、ファイル生成装置1からアップロードされた”3DoF+”ストリームを保持する。そして、Webサーバ3は、クライアント装置2からの要求にしたがい指定された”3DoF+”ストリームを提供する。
クライアント装置2は、”3DoF+”ストリームの送信要求をWebサーバ3へ送信する。そして、クライアント装置2は、送信要求で指定した”3DoF+”ストリームをWebサーバ3から取得する。そして、クライアント装置2は、”3DoF+”ストリームをデコードして映像を生成して、その映像をモニタなどの表示装置に表示させる。
[第1の実施形態に係るファイル生成装置の構成]
次に、ファイル生成装置1の詳細について説明する。図2は、ファイル生成装置のブロック図である。情報処理装置であるファイル生成装置1は、図2に示すように、生成処理部10及び制御部11を有する。制御部11は、生成処理部10の制御に関する処理を実行する。例えば、制御部11は、生成処理部10の各部の動作タイミングなどの統括制御を行う。生成処理部10は、データ入力部101、アトラス処理部102、符号化部103、ビットストリーム生成部104、ファイル生成部105及び送信部106を有する。
次に、ファイル生成装置1の詳細について説明する。図2は、ファイル生成装置のブロック図である。情報処理装置であるファイル生成装置1は、図2に示すように、生成処理部10及び制御部11を有する。制御部11は、生成処理部10の制御に関する処理を実行する。例えば、制御部11は、生成処理部10の各部の動作タイミングなどの統括制御を行う。生成処理部10は、データ入力部101、アトラス処理部102、符号化部103、ビットストリーム生成部104、ファイル生成部105及び送信部106を有する。
データ入力部101は、”3DoF+”映像の画像データ及び”3DoF+”メタデータなどの入力を受け付ける。”3DoF+”メタデータには、画像の時刻、位置情報及び視点位置情報などの視点に関する情報が含まれる。データ入力部101は、取得した画像データをアトラス処理部102へ出力する。また、データ入力部101は、メタ情報を符号化部103へ出力する。
アトラス処理部102は、”3DoF+”映像の画像データの入力をデータ入力部101から受ける。そして、アトラス処理部102は、画像データからテクスチャ画像のデータ及びデプス画像のデータを生成する。テクスチャ画像は、”3DoF+”映像は、3次元データを決められた視点位置から複数の投影方向に投影して形成される各投影方向に対応する画像である。デプス画像は、テクスチャ画像上の各点の3次元空間における位置を表す画像である。
図3は、テクスチャ画像及びデプス画像を表す図である。図3における画像301が、テクスチャ画像である。そして、領域311が3DoF領域であり、領域312が”3DoF+”領域である。”3DoF+”領域には、3DoF領域における視点位置から少しずれた角度から見た画像を生成するための補正画像であるパッチが含まれる。また、画像302が、デプス画像である。そして、アトラス処理部102は、対応するテクスチャ画像のデータとデプス画像のデータとを組み合わせてアトラスを生成する。また、アトラス処理部102は、アトラスを全天球映像として表示するためのアトラス配置パラメータを生成する。
さらに、アトラスを構成するテクスチャ画像及びデプス画像のペア識別子であるアトラスIDを生成して各アトラスに割り当てる。また、アトラス処理部102は、2次元のデータから全天球映像を作るためのメタデータであるポストデコーディング情報を生成する。
ここで、ポストデコーディング情報を説明するためにテクスチャ画像の詳細について、図4を参照して説明する。図4は、テクスチャ画像の詳細を説明するための図である。テクスチャ画像330は、3DoF領域331及び”3DoF+”領域332を有する。そして、テクスチャ画像330は、座標空間340における視点o、視点a、視点b及び視点cから見た全天球映像の元となる画像を含む。3DoF領域331には、基本カメラのprojected pictureである視点oの位置における画像333が格納される。この基本カメラによる視点位置が「所定の視点位置」一例にあたる。そして、画像333が、「基準2次元画像」の一例にあたる。
また、”3DoF+”領域332には、視点aの位置における画像334、視点bの位置における画像335及び視点cの位置における画像336といった限定範囲内の任意カメラ位置のprojected pictureを生成するための補完画像であるパッチが格納される。この限定範囲内の任意カメラによる視点位置が、「所定の視点位置から移動させた視点位置」の一例にあたる。そして、画像334~336が、「移動2次元画像」の一例にあたる。デプス画像についても、テクスチャ画像の各projected pictureの情報に相当するデプスマップが格納される。
アトラス処理部102は、各視点位置からの画像、すなわち視点o及びa~cからの画像333~336をテクスチャ画像330から生成するためのポストデコーディング情報を生成する。アトラス処理部102は、このポストデコーディング情報に、各画像がテクスチャ画像の3DoF領域の画像か、テクスチャ画像の”3DoF+”領域を用いて生成される画像かの情報を含ませる。その後、アトラス処理部102は、アトラスとともに、アトラス配置パラメータ、アトラスID及びポストデコーディング情報を含む”3DoF+”メタデータを符号化部103へ出力する。
符号化部103は、アトラスの入力をアトラス処理部102から受ける。また、符号化部103は、アトラス配置パラメータ、アトラスID及びポストデコーディング情報を含む”3DoF+”メタデータの入力をデータ入力部101から受ける。次に、符号化部103は、アトラス及び”3DoF+”メタデータをマルチレイヤHEVCで符号化する。符号化部103は、テクスチャ画像を符号化することで、テクスチャレイヤを生成する。また、符号化部103は、デプス画像を符号化することでデプスレイヤを生成する。すなわち、符号化されたアトラスは、テクスチャレイヤ及びデプスレイヤを含む。そして、符号化部103は、符号化したアトラス及び”3DoF+”メタデータをビットストリーム生成部104へ出力する。
ビットストリーム生成部104は、符号化されたアトラス及び”3DoF+”メタデータの入力を符号化部103から受ける。そして、ビットストリーム生成部104は、アトラスを時系列に並べ且つ対応する”3DoF+”メタデータを組み合わせてビットストリームを生成する。図5は、ビデオストリームの一例を表す図である。ビデオストリームには、テクスチャレイヤ303とデプスレイヤ304との組であるアトラスが時系列で格納される。ビデオストリームに含まれる1つのアトラスを構成するデータの単位は、アクセスユニット(AU:access unit)と呼ばれる。そして、ビットストリーム生成部104は、生成したビットストリームをファイル生成部105へ出力する。
ファイル生成部105は、ビットストリームの入力をビットストリーム生成部104から受ける。そして、ファイル生成部105は、取得したビットストリームをセグメント毎にISOBMFFファイルに格納することでファイル化して、ビットストリームのセグメントファイルを生成する。以下にISOBMFFファイルへの格納について説明する。
ファイル生成部105は、1トラックにアトラスを構成するテクスチャレイヤ及びデプスレイヤが格納されていることを示す情報をISOBMFFファイルに格納する。具体的には、ファイル生成部105は、Operating Point Information sample group(oinf)を拡張し、scalability_mask及びdimension_identifierをHEVCのVPSと同様に格納することで、アトラスを構成するテクスチャ及びデプスレイヤのペア識別子であるアトラスIDを定義する。図6は、scalability_mask及びdimension_identifierの拡張例を示す図である。ファイル生成部105は、例えば、図6に示すようにscalability_maskの5番目のビットを、アトラスIDに割り当てる。
そして、ファイル生成部105は、ビットストリームをISOBMFFファイルに格納する際にアトラスIDを各テクスチャレイヤ及び各デプスレイヤに割り当てられたレイヤIDに紐づける。図7は、アトラスIDの紐付けを説明するための図である。”3DoF+”のビットストリームをISOBMFFファイルに格納する場合、L-HEVCストレージ(ISO/IEC 14496-15参照)が利用可能であり、その場合、ビットストリームは、図6に示すようにISOBMFFファイルに格納される。ビットストリームの各アクセスユニットは、ISOBMFFファイルでは、それぞれsampleEntryとして扱われる。この場合、ファイル生成部105は、マルチメディアHEVCで符号化した際にストリームの一部として”3DoF+”メタデータを送る。
ここで、ファイル生成部105は、Sampleをグループ化し、ISOBMFFファイル内でサンプルグループを用いて、グループ毎にメタデータを紐づける。ファイル生成部105は、サンプルグループをISOBMFFファイルのMoovに格納する。図8は、サンプルグループを説明するための図である。ISOBMFFファイル内で、各サンプルグループは、図8に示すSampleTableBoxにより定義される。図8に示すように、Sample To Group Boxのgrouping_Typeは、紐づけられるSample Group Description BoxのGrouping_Typeを示す。また、Sample To Group Boxでは、1エントリにつき、sample_count及びGroup_description_indexが登録される。group_description_indexは、紐付くGroupEntryのindexを示す。また、sample_countは、そのGroupEntryに属するsample数を示す。
そして、ファイル生成部105は、サンプルグループとして、図7に示すoperating points information(oinf)サンプルグループ305及びLayer Information(linf)サンプルグループ306を生成する。
図9は、oinfサンプルグループの一例を表す図である。ファイル生成部105は、シンタックス321によりOperating Pointに含まれるレイヤと各レイヤのprofile、level及びtierをoinfサンプルグループに登録する。また、ファイル生成部105は、シンタックス322によりwidth及びheightの最大及び最小の情報、フレームレート及びビットレートの関連情報などのOperating pointに含まれる情報をoinfサンプルグループに登録する。さらに、ファイル生成部105は、シンタックス323により、非ベースレイヤの依存関係と種類の情報をoinfサンプルグループに登録する。ここで、ファイル生成部105は、図6に示したscalability_maskとdimention_identifierとを用いて種類を表す。ファイル生成部105は、この種類としてアトラスIDを格納する。すなわち、ファイル生成部105は、アトラスIDをsgpd’oinf’と表されるoinfサンプルグループに格納する。このように、oinfサンプルグループ305は、同じ属性のSampleをまとめる情報が格納される。
ファイル生成部105は、oinfサンプルグループ内でアトラスIDとレイヤIDとを対応付けることで、図7に示すように、各アトラスIDとテクスチャレイヤ及びデプスレイヤとを紐づける。図7において、「0」のアトラスIDは、レイヤIDが「0」のテクスチャレイヤ及びレイヤIDが「1」のデプスレイヤに紐づけられる。また、「1」のアトラスIDは、レイヤIDが「2」のテクスチャレイヤ及びレイヤIDが「3」のデプスレイヤに紐づけられる。
このように、テクスチャレイヤ及びデプスレイヤを有するアトラスが格納されていることを示す情報をoinfサンプルグループに格納することで、クライアント装置2は、ESのデコードをする前にテクスチャレイヤ及びデプスレイヤを把握できる。すなわち、クライアント装置2は、自装置でレンダリング可能なレイヤを選択してデコードすることができるようになり、処理オーバヘッドを削減することができる。例えば、”3DoF+”ストリームのデコードは可能、且つ、3DoFレンダリングは可能であるが、”3DoF+”レンダリングには対応してないクライアント装置2は、テクスチャレイヤを容易に選択することができる。
また、ファイル生成部105は、linfサンプルグループ306に、トラックに含まれるレイヤのレイヤID及びレイヤIDで示されるレイヤの内のどのサブレイヤが含まれるかを示す情報を格納する。図10は、linfサンプルグル―プの一例を表す図である。図10においてlayer_idがレイヤIDを表し、この値が各Sampleにおけるnuh_layer_idに対応する。
さらに、ファイル生成部105は、2次元のデータから全天球映像を作るためのメタデータであるポストデコーディング情報をISOBMFFファイルに格納する。このISOBMFFファイルに格納されたポストデコーディング情報を用いることで、クライアント装置2は”3DoF+”もしくは3DoFのレンダリングを行うことができる。
例えば、ファイル生成部105は、図11に示すように、ポストデコーディング情報を格納する。図11は、ポストデコーディング情報の格納を説明するための図である。ファイル生成部105は、図11に示すように、SchemeTypeBox341においてscheme_type=’povp’としてトラックに格納されたコンテンツが”3DoF+”ストリームであることを示す。これ以外にも、ファイル生成部105は、”3DoF+”ストリームであることを示す新規フラグを定義してSampleEntryに格納してもよい。さらに、ファイル生成部105は、例えば、SchemeInformationBoxに視点位置毎のポストデコーディング情報を持つ新規Box342としてProjectedOmniVideoForParallaxBoxを定義する。
図12は、ProjectedOmniVideoForParallaxBoxのシンタックスの一例を表す図である。図12に示すように、ファイル生成部105は、視点位置の数分のポストデコーディング情報を登録するためのProjectedOmniVideoForParallaxBoxにProjectionInfoBoxを格納する。”3DoF+”領域を用いた画像であることを表すポストデコーディング情報が、「第1ポストデコーディング情報」の一例にあたり、そのポストデコーディング情報を格納するProjectionInfoBoxが、「第1のBox」の一例にあたる。この3DoF領域の画像であることを表すポストデコーディング情報が、「第2ポストデコーディング情報」の一例にあたり、そのポストデコーディング情報を格納するProjectionInfoBoxが、「第2のBox」の一例にあたる。
図13は、ProjectionInfoBoxのシンタックスの一例を表す図である。さらに、図14は、ProjectionInfoBoxにおけるCameraPosStruct、DepthQuantizationStruct、ProjectionFormatStruct、RotationStruct及びRefionWisePackingStructのシンタックスの一例を示す図である。
ProjectionInfoBoxは、図14に示すシンタックス351~355で表される、CameraPosStruct、DepthQuantizationStruct、ProjectionFormatStruct、RotationStruct及びRegionWisePackingStructを呼び出す。ファイル生成部105は、CameraPosStruct及びDepthQuantizationStructを新しく定義する。CameraPosStructは、視点位置を格納する。CameraPosStructとしては、ViewpointPosStructを利用してもよい。DepthQuantizationStructは、デプス量子化パラメータを格納する。ファイル生成部105は、ProjectionFormatStructにおけるProjection_typeを表357に示すようにPerspective projectionを含むように拡張する。RegionWisePackingStructは、シンタックス356で表されるRectRegionPackingを呼び出す。RegionWisePackingStructは、アトラスのパッチ位置情報を格納する。すなわち、RegionWisePackingStructは、各パッチがどのテクスチャレイヤに含まれるかを示す情報である。
ProjectionInfoBoxにおけるCameraPosStruct、ProjectionFormatStruct及びRotationStructは、動的に変化しないことが想定されるため、”3DoF+”ストリーム中でなく、ISOBMFFファイルにメタデータとして格納することで、冗長な記述を回避できビット数の削減が可能となる。また、ProjectionInfoBoxにおけるRegionWisePackingStruct及びDepthQuantizationStructについては、動的に変化しない場合には、ISOBMFFファイルにメタデータとして格納することで、冗長な記述を回避できビット数の削減が可能となる。また、RegionWisePackingStruct及びDepthQuantizationStructが動的に変化する場合には、ファイル生成部105は、ISOBMFFファイルに初期値を格納する。さらに、ファイル生成部105は、ProjectionFormatStruct()及びDepthQuantizationStruct()それぞれが視点間で同一か否か示すフラグを追加して、同一で有る場合には、num_camerasのループの外に登録することで、ビット数を削減することも可能である。
ここで、ファイル生成部105は、ProjectionInfoBox及びRegionWisePackingStructを図15に示すように生成してもよい。図15は、ProjectionInfoBox及びRegionWisePackingStructのシンタックスの他の例を表す図である。図15のシンタックス361で示されるProjectionInfoBoxの場合、シンタックス362で示されるRegionWisePackingStructが呼び出される。このRegionWisePackingStructでは、unsigned_int(8) atlas_idにより、特定のテクスチャレイヤの所定の位置にアトラスIDを書き込むことができる。
さらに、ファイル生成部105は、ProjectionInfoBoxを図16のように拡張して、3DoFレンダリングが可能な視点位置を示す。図16は、3DoFレンダリングが可能な視点位置を示すように拡張したProjectionInfoBoxのシンタックスの一例を示す図である。図16に示すシンタックスでは、is_3DoF_compatibleの値が0であれば、3DoFレンダリングに対応しておらず、値が1であれば3DoFレンダリングが可能である。すなわち、クライアント装置2は、num_camerasの値を有する視点位置各視点位置のうちどの視点位置が3DoFレンダリング可能かをこのProjectionInfoBoxにより確認できる。これにより、3DoFレンダリングは可能であるが、”3DoF+”レンダリングには対応してないクライアント装置2が”3DoF+”ストリームのうち3DoF領域をレンダリングすることが可能となる。
図2に戻って説明を続ける。ファイル生成部105は、以上に説明したProjectionInfoBoxにより各視点位置におけるポストデコーディング情報及びレイヤIDに紐づけられたアトラスIDを格納したISOBMFFファイルを送信部106へ出力する。
送信部106は、ProjectionInfoBoxにより各視点位置におけるポストデコーディング情報及びレイヤIDに紐づけられたアトラスIDを格納したISOBMFFファイルの入力をファイル生成部105から受ける。そして、送信部106は、取得したISOBMFFファイルをWebサーバ3に送信してアップロードする。
[第1の実施形態に係るクライアント装置の構成]
図17は、クライアント装置のブロック図である。また、図18は、ファイル処理部、復号化処理部及び表示情報生成部の詳細を表すブロック図である。
図17は、クライアント装置のブロック図である。また、図18は、ファイル処理部、復号化処理部及び表示情報生成部の詳細を表すブロック図である。
図17に示すように、クライアント装置2は、再生処理部20及び制御部21を有する。制御部21は、再生処理部20の各部の動作を制御する。例えば、制御部21は、再生処理部20の各部の動作のタイミングを統括制御する。再生処理部20は、ファイル取得部201、ファイル処理部202、復号処理部203、表示情報生成部204及び表示部205を有する。
ファイル取得部201は、Webサーバ3にアクセスして表示する6DoFコンテンツのシーンディスクリプションが格納されたISOBMFFのファイルを取得する。そして、ファイル取得部201は、シーンディスクリプションが格納されたISOBMFFのファイルをファイル処理部202へ出力する。
ファイル取得部201は、Webサーバ3にアクセスして表示する”3DoF+”ストリームが格納されたISOBMFFファイルを取得する。そして、ファイル取得部201は、”3DoF+”ストリームが格納されたISOBMFFファイルをファイル処理部202へ出力する。
ファイル処理部202は、図18に示すように、抽出部220を有する。ファイル処理部202は、”3DoF+”ストリームが格納されたISOBMFFファイルの入力をファイル取得部201から受ける。そして、ファイル処理部202の抽出部220は、ISOBMFFファイルをパースして、ビットストリームのデータを抽出する。その後、抽出部220は、ビットストリームのデータを復号処理部203へ出力する。
ここで、ファイル処理部202は、取得したISOBMFFファイルのパースにより、トラックに格納されたコンテンツが”3DoF+”ストリームか否かを判定する。例えば、ファイル処理部202は図11におけるSchemeTyepBoxのscheme_typeを確認して”3DoF+”ストリームか否かを判定する。そして、復号処理部203が”3DoF+”ストリームのデコードに対応していない場合、ファイル処理部202は、トラックに格納されたコンテンツが”3DoF+”ストリームであればエラーを通知して処理を中止する。
また、復号処理部203が”3DoF+”ストリームのデコードに対応しているが、表示情報生成部204が”3DoF+”のレンダリングに対応していない場合、ファイル処理部202は、3DoFレンダリングが可能な視点位置を取得する。そして、ファイル処理部202は、テクスチャレイヤのデコードを復号処理部203に指示するとともに、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を送信する。
復号処理部203は、図18に示すように、複数のデコーダ230を有する。復号処理部203は、ビットストリームデータの入力をファイル処理部202から受ける。そして、復号処理部203は、デコーダ230を用いて取得したビットストリームのデータに対して復号処理を施す。その後、復号処理部203は、復号化したビットストリームのデータを表示情報生成部204へ出力する。
また、復号処理部203は、表示情報生成部204が”3DoF+”レンダリングに対応していない場合、テクスチャレイヤのデコードの指示を復号処理部203から受ける。また、復号処理部203は、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を受信する。そして、復号処理部203は、”3DoF+”ストリームのテクスチャレイヤのデコードを行う。その後、復号処理部203は、デコードしたテクスチャレイヤ、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を表示情報生成部204へ出力する。
表示情報生成部204は、図18に示すように、アトラス分解部241及び表示処理部242を有する。表示情報生成部204は、復号化されたビットストリームの入力を復号処理部203から受ける。そして、表示情報生成部204のアトラス分解部241は、復号化された各アトラスのテクスチャレイヤとデプスレイヤとを分解する。そして、アトラス分解部241は、分解したアトラスを表示処理部242へ出力する。
また、”3DoF+”レンダリングに対応していない場合、表示情報生成部204は、デコードされたたテクスチャレイヤ、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報の入力を復号処理部203から受ける。そして、アトラス分解部241は、デコードされたテクスチャレイヤ、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報を表示処理部242へ出力する。
表示処理部242は、分解されたアトラスの入力をアトラス分解部241から受ける。さらに、表示処理部242は、視点位置及び視線方向の入力を図示しない入力装置から受ける。そして、表示処理部242は、入力された視点位置及び視線方向にしたがって、”3DoF+”レンダリングを行い表示用の”3DoF+”画像を生成する。その後、表示処理部242は、生成した表示用の”3DoF+”画像を表示部207に供給する。
また、”3DoF+”レンダリングに対応していない場合、表示処理部242は、コードされたテクスチャレイヤ、3DoFレンダリングが可能な視点位置及びその視点位置のポストデコーディング情報の入力をアトラス分解部241から受ける。さらに、表示処理部242は、視点位置及び視線方向の入力を図示しない入力装置から受ける。そして、表示処理部242は、入力された視点位置に対応するテクスチャレイヤの3DoF領域からデータを取得し、視線方向にしたがって3DoFレンダリングを行い表示用の3DoF画像を生成する。その後、表示処理部242は、生成した表示用の3DoF画像を表示部207に供給する。
表示部205は、モニタなどの表示装置を有する。表示部205は、表示情報生成部204により生成された表示用の画像の入力を受ける。そして、表示部205は、取得した表示用の画像を表示装置に表示させる。
[第1の実施形態に係るファイル生成手順]
次に、図19を参照して、第1の実施形態に係るファイル生成装置1によるファイル生成処理の流れについて詳細に説明する。図19は、第1の実施形態に係るファイル生成装置によるファイル生成処理のフローチャートである。
次に、図19を参照して、第1の実施形態に係るファイル生成装置1によるファイル生成処理の流れについて詳細に説明する。図19は、第1の実施形態に係るファイル生成装置によるファイル生成処理のフローチャートである。
アトラス処理部102は、”3DoF+”映像の画像データ及び”3DoF+”メタデータの入力をデータ入力部101から受ける。そして、アトラス処理部102は、”3DoF+”映像の画像データ及び”3DoF+”メタデータからアトラス及びアトラス配置パラメータを生成する(ステップS101)。また、アトラス処理部102は、アトラスID及びポストデコーディング情報を生成する。そして、アトラス処理部102は、アトラス、並びに、アトラスID、ポストデコーディング情報及びアトラス配置パラメータを含む”3DoF+”メタデータを符号化部103へ出力する。
符号化部103は、アトラス、並びに、アトラスID、ポストデコーディング情報及びアトラス配置パラメータを含む”3DoF+”メタデータをエンコードしてビットストリーム生成部104へ出力する。ビットストリーム生成部104は、エンコードされたアトラス及び”3DoF+”メタデータを用いて”3DoF+”のビットストリームを生成する(ステップS102)。その後、符号化部103は、生成したビットストリームをファイル生成部105へ出力する。
次に、ファイル生成部105は、アトラスIDとレイヤIDとを紐づける情報、視点位置毎のポストデコーディング情報及びビットストリームをISOBMFFファイルに格納する(ステップS103)。その後、ファイル生成部105は、ISOBMFFファイルを送信部106へ出力する。送信部106は、ファイル生成部105により生成されたISOBMFFファイルをWebサーバ3へ出力する。
[第1の実施形態に係る再生処理手順]
次に、図20を参照して、本実施形態に係るクライアント装置2により実行される再生処理の流れを説明する。図20は、第1の実施形態に係るクライアント装置により実行される再生処理のフローチャートである。ここでは、復号処理部203が”3DoF+”ストリームのデコードが可能である場合で説明する。
次に、図20を参照して、本実施形態に係るクライアント装置2により実行される再生処理の流れを説明する。図20は、第1の実施形態に係るクライアント装置により実行される再生処理のフローチャートである。ここでは、復号処理部203が”3DoF+”ストリームのデコードが可能である場合で説明する。
ファイル処理部202は、ファイル取得部201を介して再生する”3DoF+”ストリームに対応するISOBMFFファイルをWebサーバ3から取得する。次に、ファイル処理部202は、自装置の表示情報生成部204が”3DoF+”レンダリングに対応しているか否かを判定する(ステップS201)。
自装置の表示情報生成部204が”3DoF+”レンダリングに対応している場合(ステップS201:肯定)、ファイル処理部202は、ISOBMFFファイルをパースして、3DoF及び”3DoF+”のポストデコーディング情報を取得する(ステップS202)。さらに、ファイル処理部202は、”3DoF+”のビットストリームをISOBMFFファイルから抽出する。そして、ファイル処理部202は、抽出した”3DoF+”のビットストリーム、並びに、3DoF及び”3DoF+”のポストデコーディング情報を復号処理部203へ出力する。
復号処理部203は、”3DoF+”のビットストリーム、並びに、3DoF及び”3DoF+”のポストデコーディング情報の入力をファイル処理部202から受ける。そして、復号処理部203は、”3DoF+”のビットストリームをデコードする(ステップS203)。その後、復号処理部203は、デコードしたビットストリームのデータ及びポストデコーディング情報を表示情報生成部204へ出力する。
表示情報生成部204は、ビットストリームのデータ、並びに、3DoF及び”3DoF+”のポストデコーディング情報の入力を復号処理部203から受ける。さらに、表示情報生成部204は、視点位置及び視線方向の入力を入力装置から受ける。そして。表示情報生成部204は、ポストデコーディング情報、視点位置及び視線方向の情報を用いて”3DoF+”レンダリングを実行して表示用の”3DoF+”画像を生成する(ステップS204)。その後、表示情報生成部204は、”3DoF+”画像を送信して表示部205に表示させる視聴処理を実行する。
これに対して、自装置の表示情報生成部204が”3DoF+”レンダリングに対応していない場合(ステップS201:否定)、ファイル処理部202は、ISOBMFFファイルをパースして、3DoFのポストデコーディング情報を取得する(ステップS205)。さらに、ファイル処理部202は、”3DoF+”のビットストリームをISOBMFFファイルから抽出する。そして、ファイル処理部202は、抽出した”3DoF+”のビットストリーム及び3DoFのポストデコーディング情報を復号処理部203へ出力し、テクスチャレイヤのエンコードを指示する。
復号処理部203は、”3DoF+”のビットストリーム及び3DoFのポストデコーディング情報の入力をファイル処理部202から受ける。そして、復号処理部203は、”3DoF+”のビットストリームの3DoFレンダリングに用いる部分をデコードする(ステップS206)。すなわち、復号処理部203は、”3DoF+”のビットストリームのテクスチャレイヤをデコードする。その後、復号処理部203は、デコードしたビットストリームのデータ及び3DoFのポストデコーディング情報を表示情報生成部204へ出力する。
表示情報生成部204は、ビットストリームのデータ及び3DoFのポストデコーディング情報の入力を復号処理部203から受ける。さらに、表示情報生成部204は、視点位置及び視線方向の入力を入力装置から受ける。そして。表示情報生成部204は、ポストデコーディング情報、視点位置及び視線方向の情報を用いて3DoFレンダリングを実行して表示用の3DoF画像を生成する(ステップS207)。その後、表示情報生成部204は、3DoF画像を送信して表示部205に表示させる視聴処理を実行する。
以上に説明したように、本実施形態に係るファイル生成装置は、テクスチャレイヤ及びデプスレイヤを有するアトラスが格納されていることを表す情報をISOBMFFファイルに格納する。また、ファイル生成装置は、格納されたコンテンツが”3DoF+”ストリームか否かの情報及び視点位置毎のポストデコーディング情報をISOBMFFファイルに格納する。ポストデコーディング情報には、3DoFレンダリングが可能な視点位置を表す情報が格納される。これにより、クライアント装置は、”3DoF+”ストリームか否かを判定して、自装置の能力に対応したレイヤのデータを容易に取得できる。さらに、”3DoF+”レンダリングに対応していない場合、クライアント装置は、3DoFレンダリングにより表示用画像を生成することができる。したがって、クライアント装置の表示処理能力に応じた画像を提供して表示させることができ、利用者の視聴体験を拡大することができる。
[1.1 第1の実施形態の変形例]
本変形例に係るファイル生成装置は、3DoF領域と”3DoF+”領域とのそれぞれに関するポストデコーディング情報を個別のボックスに格納することが第1の実施形態と異なる。図21は、第1の実施形態の変形例に係るISOBMFFファイルの一例を表す図である。
本変形例に係るファイル生成装置は、3DoF領域と”3DoF+”領域とのそれぞれに関するポストデコーディング情報を個別のボックスに格納することが第1の実施形態と異なる。図21は、第1の実施形態の変形例に係るISOBMFFファイルの一例を表す図である。
ファイル生成部105は、図21においてボックス371に示すようにSchemeTypeBoxにscheme_type=’podv’を格納する。これにより、OMAF ed.1の構造に近づけることができる。そして、ファイル生成部105は、podvに3DoF領域のポストデコーディング情報を格納する。このように構成することで、scheme_type=’podv’により、3DoF領域のポストデコーディング情報が格納されていることが示される。さらに、ファイル生成部105は、podvにおけるrwpkを用いて3DoF領域のレンダリングを可能とするための情報を格納する。
また、ファイル生成部105は、ボックス372に示すようにCompatibleSchemeTypeBoxにscheme_type=’ecpp’を格納する。そして、ファイル生成部105は、ecppに”3DoF+”領域のポストデコーディング情報を格納する。さらに、ファイル生成部105は、povpにおけるpinfを用いて”3DoF+”領域のレンダリングを可能とする情報を格納する。ただし、ファイル生成部105は、povpにおけるpinfには、3DoF領域及び”3DoF+”領域の両方のポストデコーディング情報を格納してもよい。
以上に説明したように、本実施例に係るファイル生成装置は、3DoF領域のポストコーディング情報と”3DoF+”領域のポストコーディング情報を異なるボックスに格納する。これにより、テクスチャレイヤが再生可能で”3DoF+”ストリームのデコードに対応しない場合にも、デプスレイヤを無視できるファイル生成装置であれば、3DoF領域に制限してデコード及びレンダリングを行うことが可能となる。
[2.第2の実施形態]
本実施形態に係るファイル生成装置は、テクスチャレイヤとデプスレイヤとを個別のトラックに格納することが第1の実施形態と異なる。本実施形態に係るファイル生成装置も、図2のブロック図で表される。以下の説明では、第1の実施形態と同様の各部の動作については説明を省略する場合がある。
本実施形態に係るファイル生成装置は、テクスチャレイヤとデプスレイヤとを個別のトラックに格納することが第1の実施形態と異なる。本実施形態に係るファイル生成装置も、図2のブロック図で表される。以下の説明では、第1の実施形態と同様の各部の動作については説明を省略する場合がある。
ファイル生成部105は、L-HEVC storageの技術を利用して、テクスチャレイヤとデプスレイヤとを個別のトラックに格納する。図22は、第2の実施形態に係るISOBMFFFファイルの一例を表す図である。
具体期には、ファイル生成部105は、ボックス401で示されるid=1のtrack boxにテクスチャレイヤを格納する。また、ファイル生成部105は、ボックス402で示されるid=2のtrack boxにデプスチャレイヤを格納する。そして、ファイル生成部105は、Track referenceを用いて、ボックス402のデプスレイヤトラックから、ボックス401のテクスチャトラックが参照できるようにする。
そして、ファイル生成部105は、ボックス401のテクスチャレイヤトラックにおいて、SchemeTyeBoxにscheme type=’podv’を格納する。さらに、ファイル生成部105は、povdに3DoF領域のポストデコーディング情報を格納する。この3DoF領域のポストデコーディング情報が、「第1識別情報」の一例にあたる。このように構成することで、scheme_type=’podv’により、3DoF領域のポストデコーディング情報が格納されていることが示される。さらに、ファイル生成部105は、rwpkを用いて3DoF領域のレンダリングを可能とする情報を格納する。
また、ファイル生成部105は、ボックス401のテクスチャレイヤトラックにおいて、CompatibleSchemeTyeBoxにscheme type=’ecpp’を格納する。さらに、ファイル生成部105は、ボックス402のデプスレイヤトラックにscheme type=’povp’を格納する。そして、ファイル生成部105は、povpに”3DoF+”領域のポストデコーディング情報を格納する。この”3DoF+”のポストデコーディング情報が、「第2識別情報」の一例にあたる。例えば、ファイル生成部105は、ボックス401のテクスチャレイヤトラックのpovpにおけるpinfに”3DoF+”領域のポストデコーディング情報を格納する。また、ファイル生成部105は、ボックス402のデプスレイヤトラックのpovpにおけるpinfに3DoF領域及び”3DoF+”領域のポストデコーディング情報を格納する。
クライアント装置2のファイル処理部202は、”3DoF+”ストリームのデコード及びレンダリングが可能な場合、テクスチャレイヤトラック及びデプスレイヤトラックの双方を用いて”3DoF+”映像の再生を行う。この場合、ファイル処理部202は、ボックス401のテクスチャレイヤトラックにおけるschiに格納されたpovpを参照して、”3DoF+””領域のポストデコーディング情報を取得する。
一方、”3DoF+”ストリームのデコードに対応していない場合、ファイル処理部202は、テクスチャレイヤトラックに格納された3DoF領域及び3DoF領域のポストデコーディング情報を用いて3DoF映像の再生を行う。
以上に説明したように、本実施例に係るファイル生成装置は、テクスチャレイヤとデプスレイヤとを個別のトラックに格納する。これにより、”3DoF+”ストリームのデコードには対応していないクライアント装置であっても、テクスチャレイヤのトラックを使用して3DoFの全天球映像を再生することが可能となる。
[2.1 第2の実施形態の変形例]
本変形例に係る配信システムでは、クライアント装置2が”3DoF+”レンダリングの際にデプスレイヤトラックにおけるschiに格納されたpropを参照することが第2の実施形態と異なる。以下に、本変形例に係るファイル生成装置1について説明する。
本変形例に係る配信システムでは、クライアント装置2が”3DoF+”レンダリングの際にデプスレイヤトラックにおけるschiに格納されたpropを参照することが第2の実施形態と異なる。以下に、本変形例に係るファイル生成装置1について説明する。
ファイル生成装置1のファイル生成部105は、”3DoF+”レンダリングを行う場合にデプスレイヤトラックにおけるschiに格納されたpovpの参照を示すscheme_typeを新しく定義する。そして、ファイル生成部105は、テクスチャレイヤトラックにおけるCompatibleSchemeTypeBoxのscheme_typeとして新しく定義したscheme_typeを格納する。
クライアント装置2のファイル処理部202は、”3DoF+”ストリームのデコード及びレンダリングが可能な場合、テクスチャレイヤトラック及びデプスレイヤトラックの双方を用いて”3DoF+”映像の再生を行う。この場合、ファイル処理部202は、テクスチャレイヤトラックにおけるCompatibleSchemeTypeBoxのsheme_typeを参照してデプスレイヤトラックにおけるschiに格納されたpovpの参照の指示を確認する。そして、ファイル処理部202は、デプスレイヤトラックにおけるschiに格納されたpovpを参照して、”3DoF+”領域のポストデコーディング情報を取得する。
以上に説明したように、本実施例に係る配信システムでは、クライアント装置は、デプスレイヤトラックにおけるschiに格納されたpropを参照して”3DoF+”領域のポストデコーディング情報を取得し、”3DoF+”レンダリングを行う。これにより、OMAF ed.1で規定されるprofileを満たすことが可能となる。
[3.第3の実施形態]
本実施形態に係るファイル生成装置は、テクスチャレイヤの”3DoF+”領域と3DoF領域とを分割してそれぞれ個別に1トラックに格納することが第2の実施形態と異なる。本実施形態に係るファイル生成装置も、図2のブロック図で表される。以下の説明では、第1及び第2の実施形態と同様の各部の動作については説明を省略する場合がある。
本実施形態に係るファイル生成装置は、テクスチャレイヤの”3DoF+”領域と3DoF領域とを分割してそれぞれ個別に1トラックに格納することが第2の実施形態と異なる。本実施形態に係るファイル生成装置も、図2のブロック図で表される。以下の説明では、第1及び第2の実施形態と同様の各部の動作については説明を省略する場合がある。
ファイル生成部105は、テクスチャレイヤの”3DoF+”領域と3DoF領域とを分割する。さらに、ファイル生成部105は、デプスレイヤにおけるテクスチャレイヤの”3DoF+”領域に対応する領域と3DoF領域に対応する領域とを分割する。以下では、デプスレイヤにおけるテクスチャレイヤの”3DoF+”領域に対応する領域と3DoF領域に対応する領域とを、それぞれ「デプスレイヤの”3DoF+”領域」及び「デプスレイヤの3DoF領域」と呼ぶ。ファイル生成部105は、Track referenceを用いて、テクスチャレイヤの”3DoF+”領域と3DoF領域とを紐づける。また、ファイル生成部105は、Track referenceを用いて、デプスレイヤの”3DoF+”領域と3DoF領域とを紐づける。
そして、ファイル生成部105は、図23に示すように、テクスチャレイヤの”3DoF+”領域と3DoF領域とをそれぞれの個別のトラック501及び503のMoovBoxに格納する。さらに、ファイル生成部105は、デプスレイヤの”3DoF+”領域と3DoF領域とをそれぞれ個別のトラック502及び504のMoovBoxに格納する。図23は、第3の実施形態に係るISOBMFFFファイルの一例を表す図である。
次に、ファイル生成部105は、各レイヤの分割情報を、他のトラックグループ510であるsub-picture track groupingに格納する。この場合、ファイル生成部105は、tile base track/tile trackの仕組みにより、各レイヤの分割情報を格納してもよい。また、ファイル生成部105は、sub-picture track groupingには、元となるトラックであるベーストラックの一覧を登録する。例えば、トラック501及び503のテクスチャレイヤトラックをベーストラックとする場合、ファイル生成部105は、sub-picture track groupingにトラック501及び503のテクスチャレイヤトラックの情報を登録する。この場合、トラック501のテクスチャトラックにおけるSchemeTypeBoxのScheme_type=’podv’により、トラック501がテクスチャレイヤの3DoF領域を格納したトラックであることが識別可能である。このScheme_type=’podv’によって表される3DoF領域の情報であることを示す情報が「第1識別情報」の一例にあたる。また、このScheme_type=’povp’によって表される”3DoF+”領域の情報であることを示す情報が「第2識別情報」の一例にあたる。Scheme_type=’povp’は、アトラス処理部102により例えば、ポストデコーディング情報に含まれるようにアトラス処理部102により生成される。
クライアント装置2のファイル処理部202は、”3DoF+”ストリームのデコード及びレンダリングが可能な場合、sub-picture track groupingを参照して、各レイヤの分割情報を取得し対応するトラックを特定する。そして、ファイル処理部202は、”3DoF+”領域及び3DoF領域のテクスチャレイヤトラック及びデプスレイヤトラックを用いて”3DoF+”映像の再生を行う。
一方、”3DoF+”ストリームのデコードに対応していない場合、ファイル処理部202は、トラック501のテクスチャトラックにおけるSchemeTypeBoxのScheme_type=’podv’を確認して、トラック501がテクスチャレイヤの3DoF領域を格納したトラックと確認する。そして、ファイル処理部202は、トラック501の3DoF領域のテクスチャレイヤトラックに格納された3DoF領域及び3DoF領域のポストデコーディング情報を用いて3DoF映像の再生を行う。
ここで、本実施例ではデプスレイヤも”3DoF+”領域及び3DoF領域に分けたが、ファイル生成部105は、デプスレイヤを領域毎に分割せずに1トラックにまとめてもよい。
他にも、ファイル生成部105は、デプスレイヤの”3DoF+”領域及び3DoF領域とテクスチャレイヤの”3DoF+”領域とを1つのトラックにまとめてもよい。この場合、ファイル生成部105は、デプスレイヤの”3DoF+”領域及び3DoF領域とテクスチャレイヤの”3DoF+”領域とをまとめたトラックに、テクスチャレイヤ用とデプスレイヤ用との2つのProjectionInfoBoxを格納する。
さらに、ファイル生成部105は、”3DoF+”領域を、各視点位置を構成するパッチ群毎に分割して、個別にトラックに格納することもできる。この場合、ファイル生成部105は、各トラックにViewingSpaceBoxを格納し、トラックが格納するストリーム視聴時の視点の移動可能範囲を登録することも可能である。
以上に説明したように、本実施例に係るファイル生成装置は、テクスチャレイヤの”3DoF+”領域と3DoF領域とを分割してそれぞれ個別に1トラックに格納する。これにより、”3DoF+”ストリームのデコードには対応していないクライアント装置であっても、テクスチャレイヤの3DoF領域を格納したトラックを使用して3DoFの全天球映像を再生することが可能となる。また、OMAF ed.1で規定されるprofileを満たすことが可能となる。
[3.1 第3の実施形態の変形例(1)]
本変形例に係る配信システムでは、sub-picture track groupingに各トラックに格納されたストリームがテクスチャレイヤの3DoF領域か否かを表す情報することが第2の実施形態と異なる。以下に、本変形例に係るファイル生成装置1について説明する。
本変形例に係る配信システムでは、sub-picture track groupingに各トラックに格納されたストリームがテクスチャレイヤの3DoF領域か否かを表す情報することが第2の実施形態と異なる。以下に、本変形例に係るファイル生成装置1について説明する。
図24は、第3の実施形態の変形例(1)に係るsub-picture track groupingのシンタックスの一例を示す図である。ファイル生成部105は、図24に示すように、sub-picture track groupingにおいて、格納されたストリームがテクスチャレイヤの3DoF領域であることを表すThreeDoFCompatibleBox()を格納する。ThreeDoFCompatibleBox()は空であり、このThreeDoFCompatibleBox()が存在するトラックが格納するストリームがテクスチャレイヤの3DoF領域であることを表す。
ここで、本変形例では、ThreeDoFCompatibleBox()を用いてトラックが格納するストリームがテクスチャレイヤの3DoF領域であることを表したが、ファイル生成部105は、新規フィールドを定義して、そのフィールドに同様の情報を格納してもよい。
[3.2 第3の実施形態の変形例(2)]
さらに、第3の実施形態及びその変形例(1)では、符号化部103は、マルチレイヤHEVCを用いて符号化を行ったが、HEVC/AVC(Advanced Video Coding)を用いてテクスチャレイヤ及びデプスレイヤを符号化することも可能である。これは、第2の実施形態及びその変形例についても同様である。この場合、各ストリームに対する”3DoF+”メタデータをtimed metadataとして表し、個別のtrackに格納し、テクスチャレイヤ及びデプスレイヤを格納するトラックにtrack referenceによって紐づける。
さらに、第3の実施形態及びその変形例(1)では、符号化部103は、マルチレイヤHEVCを用いて符号化を行ったが、HEVC/AVC(Advanced Video Coding)を用いてテクスチャレイヤ及びデプスレイヤを符号化することも可能である。これは、第2の実施形態及びその変形例についても同様である。この場合、各ストリームに対する”3DoF+”メタデータをtimed metadataとして表し、個別のtrackに格納し、テクスチャレイヤ及びデプスレイヤを格納するトラックにtrack referenceによって紐づける。
ファイル生成部105は、テクスチャレイヤ及びデプスレイヤの識別情報、アトラスを構成するレイヤペアの関連付け情報を、ISOBMFF/Elementary Stream(SEI)を拡張して格納する。これにより、L-HEVC storageにおいてoinf/oref/sbasにより格納されていた情報が、HEVC/AVCに適用可能となる。ファイル生成部105は、その他の情報については、HEVC/AVCにおいてもL-HEVC storageと同様に格納可能である。
以上に説明したように、HEVC/AVCを用いることで、一般的に市場で流通するデコーダを利用することが可能となる。また、”3DoF+”ストリームのデコードに対応していないクライアント装置であっても、テクスチャレイヤトラックのデコード及びレンダリングを行うことができる。
[4.第4の実施形態]
以上に説明した各実施形態及びそれらの各変形例では、ビットストリームを格納するフォーマットとしてISOBMFFを用いたが、これ以外のフォーマットを用いることも可能である。
以上に説明した各実施形態及びそれらの各変形例では、ビットストリームを格納するフォーマットとしてISOBMFFを用いたが、これ以外のフォーマットを用いることも可能である。
例えば、ファイル生成部105は、図25に示すフォーマットを有するMatroska Media Containerを用いることも可能である。図25は、Matroska Media Containerのフォーマットを表す図である。この場合、ファイル生成部105は、テクスチャレイヤ及びデプスレイヤの識別情報及びアトラスIDとレイヤペアとを紐づける情報を、Trak Entry elementの下の新たに定義したelementとして格納する。さらに、ファイル生成部105は、ISOBMFFファイルにおいてProjectionInfoBox()に格納されるポストデコーディング情報も、Trak Entry elementの下の新たに定義したelementとして格納する。
このように、ISOBMFF以外のフォーマットを用いてもセグメントファイルを生成することが可能であり、その場合でも、各実施形態及びそれらの各変形例と同様の効果を得ることが可能である。
以上、本開示の実施形態について説明したが、本開示の技術的範囲は、上述の実施形態そのままに限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また他の効果があってもよい。
なお、本技術は以下のような構成を取ることもできる。
(1)3次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準2次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”3DoF+”領域の情報であることを示す第1ポストデコーディング情報を含む、各前記基準2次元画像及び各前記移動2次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成するアトラス処理部と、
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する符号化部と、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成するファイル生成部と
を備えた情報処理装置。
(2)前記ファイル生成部は、前記アトラス識別情報を、ISOBMFFファイルにおけるMoovのsgpd’oinf’に格納する付記(1)に記載の情報処理装置。
(3)前記ファイル生成部は、前記テクスチャレイヤ及び前記デプスレイヤにISOBMFFファイルのトラックを割り当て、前記テクスチャレイヤ及び前記デプスレイヤに割り当てた前記トラックにおける第1のBoxに前記第1ポストデコーディング情報を格納する付記(1)又は(2)に記載の情報処理装置。
(4)前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報を含む第2ポストデコーディング情報を前記ポストデコーディング情報に含ませる付記(3)に記載の情報処理装置。
(5)前記アトラス処理部は、前記第2ポストデコーディング情報に前記3DoF領域の情報であることを示す情報を含ませる付記(4)に記載の情報処理装置。
(6)前記ファイル生成部は、前記第2ポストデコーディング情報を、前記ISOBMFFファイルにおける前記第1のBoxが割り当てられた前記トラックにおける前記第1のBoxとは異なる第2のBoxに格納する付記(3)に記載の情報処理装置。
(7)前記ファイル生成部は、前記テクスチャレイヤと前記デプスレイヤとをそれぞれISOBMFFファイルの異なるトラックに割り当て、且つ、各前記トラックはTrack referenceで紐づけられる付記(1)又は(2)に記載の情報処理装置。
(8)前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報が前記レンダリングの対象に含まれるか否かを示す第1識別情報を前記ポストデコーディング情報に含ませる付記(7)に記載の情報処理装置。
(9)前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるScheme Type Boxに格納する付記(8)に記載の情報処理装置。
(10)前記アトラス処理部は、前記”3DoF+”領域の情報が前記レンダリングの対象に含まれるか否かを示す第2識別情報を前記ポストデコーディング情報に含ませる付記(7)に記載の情報処理装置。
(11)前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるCompatible Scheme Type Boxに格納する付記(10)に記載の情報処理装置。
(12)前記ファイル生成部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域と、前記”3DoF+”領域と、前記3DoF領域に対応する前記デプス画像の第1領域と、前記”3DoF+”領域に対応する前記デプス画像の第2領域とのそれぞれに、ISOBMFFファイルにおける異なるトラックを割り当て、前記3DoF領域と前記”3DoF+”領域とが割り当てられた各前記トラックそれぞれ、及び、前記第1領域と前記第2領域とが割り当てられた各前記トラックそれぞれに、”3DoF+”メタデータを格納するトラックをTrack referenceで紐付ける付記(1)又は(2)に記載の情報処理装置。
(13)前記アトラス処理部は、前記レンダリングの対象が前記3DoF領域の情報であることを表す第1識別情報を前記ポストデコーディング情報に含ませる付記(12)に記載の情報処理装置。
(14)前記ファイル生成部は、前記アトラス識別情報のうちの前記3DoF領域に関する情報を前記テクスチャレイヤの前記3DoF領域に割り当てられたトラックにおけるMoov Boxに格納する付記(13)に記載の情報処理装置。
(15)前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記(13)に記載の情報処理装置。
(16)前記アトラス処理部は、前記レンダリングの対象が前記”3DoF+”領域の情報であることを表す第2識別情報を前記ポストデコーディング情報に含ませる付記(12)に記載の情報処理装置。
(17)前記ファイル生成部は、前記アトラス識別情報のうちの前記”3DoF+”領域に関する情報を前記テクスチャレイヤの前記”3DoF+”領域に割り当てられたトラックにおけるMoov Boxに格納する付記(16)に記載の情報処理装置。
(18)前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記(16)に記載の情報処理装置。
(19)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報を生成し、
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成し、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記テクスチャ画像における前記ポストデコーディング情報を含むファイルを生成する
処理をコンピュータに実行させる情報処理方法。
(20)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得するファイル取得部と、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定するファイル処理部と、
前記ファイル処理部により決定された前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成する復号処理部と、
前記復号処理部により生成された画像を基に、前記画像生成方法にしたがって表示画像を生成する表示情報生成部と
を備えた再生処理装置。
(21)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得し、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定し、
決定した前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成し、
生成した画像を基に、前記画像生成方法にしたがって表示画像を生成する
処理をコンピュータに実行させる再生処理方法。
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する符号化部と、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成するファイル生成部と
を備えた情報処理装置。
(2)前記ファイル生成部は、前記アトラス識別情報を、ISOBMFFファイルにおけるMoovのsgpd’oinf’に格納する付記(1)に記載の情報処理装置。
(3)前記ファイル生成部は、前記テクスチャレイヤ及び前記デプスレイヤにISOBMFFファイルのトラックを割り当て、前記テクスチャレイヤ及び前記デプスレイヤに割り当てた前記トラックにおける第1のBoxに前記第1ポストデコーディング情報を格納する付記(1)又は(2)に記載の情報処理装置。
(4)前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報を含む第2ポストデコーディング情報を前記ポストデコーディング情報に含ませる付記(3)に記載の情報処理装置。
(5)前記アトラス処理部は、前記第2ポストデコーディング情報に前記3DoF領域の情報であることを示す情報を含ませる付記(4)に記載の情報処理装置。
(6)前記ファイル生成部は、前記第2ポストデコーディング情報を、前記ISOBMFFファイルにおける前記第1のBoxが割り当てられた前記トラックにおける前記第1のBoxとは異なる第2のBoxに格納する付記(3)に記載の情報処理装置。
(7)前記ファイル生成部は、前記テクスチャレイヤと前記デプスレイヤとをそれぞれISOBMFFファイルの異なるトラックに割り当て、且つ、各前記トラックはTrack referenceで紐づけられる付記(1)又は(2)に記載の情報処理装置。
(8)前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報が前記レンダリングの対象に含まれるか否かを示す第1識別情報を前記ポストデコーディング情報に含ませる付記(7)に記載の情報処理装置。
(9)前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるScheme Type Boxに格納する付記(8)に記載の情報処理装置。
(10)前記アトラス処理部は、前記”3DoF+”領域の情報が前記レンダリングの対象に含まれるか否かを示す第2識別情報を前記ポストデコーディング情報に含ませる付記(7)に記載の情報処理装置。
(11)前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるCompatible Scheme Type Boxに格納する付記(10)に記載の情報処理装置。
(12)前記ファイル生成部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域と、前記”3DoF+”領域と、前記3DoF領域に対応する前記デプス画像の第1領域と、前記”3DoF+”領域に対応する前記デプス画像の第2領域とのそれぞれに、ISOBMFFファイルにおける異なるトラックを割り当て、前記3DoF領域と前記”3DoF+”領域とが割り当てられた各前記トラックそれぞれ、及び、前記第1領域と前記第2領域とが割り当てられた各前記トラックそれぞれに、”3DoF+”メタデータを格納するトラックをTrack referenceで紐付ける付記(1)又は(2)に記載の情報処理装置。
(13)前記アトラス処理部は、前記レンダリングの対象が前記3DoF領域の情報であることを表す第1識別情報を前記ポストデコーディング情報に含ませる付記(12)に記載の情報処理装置。
(14)前記ファイル生成部は、前記アトラス識別情報のうちの前記3DoF領域に関する情報を前記テクスチャレイヤの前記3DoF領域に割り当てられたトラックにおけるMoov Boxに格納する付記(13)に記載の情報処理装置。
(15)前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記(13)に記載の情報処理装置。
(16)前記アトラス処理部は、前記レンダリングの対象が前記”3DoF+”領域の情報であることを表す第2識別情報を前記ポストデコーディング情報に含ませる付記(12)に記載の情報処理装置。
(17)前記ファイル生成部は、前記アトラス識別情報のうちの前記”3DoF+”領域に関する情報を前記テクスチャレイヤの前記”3DoF+”領域に割り当てられたトラックにおけるMoov Boxに格納する付記(16)に記載の情報処理装置。
(18)前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する付記(16)に記載の情報処理装置。
(19)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報を生成し、
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成し、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記テクスチャ画像における前記ポストデコーディング情報を含むファイルを生成する
処理をコンピュータに実行させる情報処理方法。
(20)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得するファイル取得部と、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定するファイル処理部と、
前記ファイル処理部により決定された前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成する復号処理部と、
前記復号処理部により生成された画像を基に、前記画像生成方法にしたがって表示画像を生成する表示情報生成部と
を備えた再生処理装置。
(21)3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得し、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定し、
決定した前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成し、
生成した画像を基に、前記画像生成方法にしたがって表示画像を生成する
処理をコンピュータに実行させる再生処理方法。
1 ファイル生成装置
2 クライアント装置
3 Webサーバ
4 ネットワーク
10 生成処理部
11 制御部
20 再生処理部
21 制御部
101 データ入力部
102 アトラス処理部
103 符号化部
104 ビットストリーム生成部
105 ファイル生成部
106 送信部
201 ファイル取得部
202 ファイル処理部
203 復号処理部
204 表示情報生成部
205 表示部
220 抽出部
230 デコーダ
241 アトラス分解部
242 表示処理部
2 クライアント装置
3 Webサーバ
4 ネットワーク
10 生成処理部
11 制御部
20 再生処理部
21 制御部
101 データ入力部
102 アトラス処理部
103 符号化部
104 ビットストリーム生成部
105 ファイル生成部
106 送信部
201 ファイル取得部
202 ファイル処理部
203 復号処理部
204 表示情報生成部
205 表示部
220 抽出部
230 デコーダ
241 アトラス分解部
242 表示処理部
Claims (21)
- 3次元データを所定の視点位置から複数の投影方向に投影して形成される各前記投影方向に対応する基準2次元画像及び前記所定の視点位置から限定範囲内で移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補完画像を形成するテクスチャ画像と、前記テクスチャ画像に対応するデプス画像とを対応付けるアトラス識別情報、並びに、前記テクスチャ画像における前記補完画像が格納される”3DoF+”領域の情報であることを示す第1ポストデコーディング情報を含む、各前記基準2次元画像及び各前記移動2次元画像をレンダリングするためのそれぞれのポストデコーディング情報を生成するアトラス処理部と、
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成する符号化部と、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記ポストデコーディング情報を含むファイルを生成するファイル生成部と
を備えた情報処理装置。 - 前記ファイル生成部は、前記アトラス識別情報を、ISOBMFFファイルにおけるMoovのsgpd’oinf’に格納する請求項1に記載の情報処理装置。
- 前記ファイル生成部は、前記テクスチャレイヤ及び前記デプスレイヤにISOBMFFファイルのトラックを割り当て、前記テクスチャレイヤ及び前記デプスレイヤに割り当てた前記トラックにおける第1のBoxに前記第1ポストデコーディング情報を格納する請求項1に記載の情報処理装置。
- 前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報を含む第2ポストデコーディング情報を前記ポストデコーディング情報に含ませる請求項3に記載の情報処理装置。
- 前記アトラス処理部は、前記第2ポストデコーディング情報に前記3DoF領域の情報であることを示す情報を含ませる請求項4に記載の情報処理装置。
- 前記ファイル生成部は、前記第2ポストデコーディング情報を、前記ISOBMFFファイルにおける前記第1のBoxが割り当てられた前記トラックにおける前記第1のBoxとは異なる第2のBoxに格納する請求項3に記載の情報処理装置。
- 前記ファイル生成部は、前記テクスチャレイヤと前記デプスレイヤとをそれぞれISOBMFFファイルの異なるトラックに割り当て、且つ、各前記トラックはTrack referenceで紐づけられる請求項1に記載の情報処理装置。
- 前記アトラス処理部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域の情報が前記レンダリングの対象に含まれるか否かを示す第1識別情報を前記ポストデコーディング情報に含ませる請求項7に記載の情報処理装置。
- 前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるScheme Type Boxに格納する請求項8に記載の情報処理装置。
- 前記アトラス処理部は、前記”3DoF+”領域の情報が前記レンダリングの対象に含まれるか否かを示す第2識別情報を前記ポストデコーディング情報に含ませる請求項7に記載の情報処理装置。
- 前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられた前記トラックにおけるCompatible Scheme Type Boxに格納する請求項10に記載の情報処理装置。
- 前記ファイル生成部は、前記テクスチャ画像における前記基準2次元画像が格納される3DoF領域と、前記”3DoF+”領域と、前記3DoF領域に対応する前記デプス画像の第1領域と、前記”3DoF+”領域に対応する前記デプス画像の第2領域とのそれぞれに、ISOBMFFファイルにおける異なるトラックを割り当て、前記3DoF領域と前記”3DoF+”領域とが割り当てられた各前記トラックそれぞれ、及び、前記第1領域と前記第2領域とが割り当てられた各前記トラックそれぞれに、”3DoF+”メタデータを格納するトラックをTrack referenceで紐付ける請求項1に記載の情報処理装置。
- 前記アトラス処理部は、前記レンダリングの対象が前記3DoF領域の情報であることを表す第1識別情報を前記ポストデコーディング情報に含ませる請求項12に記載の情報処理装置。
- 前記ファイル生成部は、前記アトラス識別情報のうちの前記3DoF領域に関する情報を前記テクスチャレイヤの前記3DoF領域に割り当てられたトラックにおけるMoov Boxに格納する請求項13に記載の情報処理装置。
- 前記ファイル生成部は、前記第1識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する請求項13に記載の情報処理装置。
- 前記アトラス処理部は、前記レンダリングの対象が前記”3DoF+”領域の情報であることを表す第2識別情報を前記ポストデコーディング情報に含ませる請求項12に記載の情報処理装置。
- 前記ファイル生成部は、前記アトラス識別情報のうちの前記”3DoF+”領域に関する情報を前記テクスチャレイヤの前記”3DoF+”領域に割り当てられたトラックにおけるMoov Boxに格納する請求項16に記載の情報処理装置。
- 前記ファイル生成部は、前記第2識別情報を前記テクスチャレイヤが割り当てられたトラックにおけるSchemeTypeBoxに格納する請求項16に記載の情報処理装置。
- 3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報を生成し、
テクスチャ画像及びデプス画像を符号化してテクスチャレイヤ及びデプスレイヤを生成し、
前記テクスチャレイヤ、前記デプスレイヤ、前記アトラス識別情報及び前記テクスチャ画像における前記ポストデコーディング情報を含むファイルを生成する
処理をコンピュータに実行させる情報処理方法。 - 3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得するファイル取得部と、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定するファイル処理部と、
前記ファイル処理部により決定された前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成する復号処理部と、
前記復号処理部により生成された画像を基に、前記画像生成方法にしたがって表示画像を生成する表示情報生成部と
を備えた再生処理装置。 - 3次元データを所定の視点位置から複数の投影方向に投影した場合の前記投影方向に対応する基準2次元画像及び前記所定の視点位置から移動させた視点位置に基づく移動2次元画像を前記基準2次元画像から生成するための補正画像におけるテクスチャ画像とデプス画像との対応付けを表すアトラス識別情報、及び、前記テクスチャ画像における前記補正画像が格納される”3DoF+”領域の情報である第1ポストデコーディング情報を含む前記基準2次元画像及び前記移動2次元画像をレンダリングするためのポストデコーディング情報、前記テクスチャ画像が符号化されたテクスチャレイヤ、並びに、前記デプス画像が符号化されたデプスレイヤを含むファイルを取得し、
前記ファイルから前記アトラス識別情報及び前記ポストデコーディング情報を取得し、取得した前記アトラス識別情報及び前記ポストデコーディング情報を基に、自装置の処理能力に応じた画像生成方法を決定し、
決定した前記画像生成方法に応じて前記テクスチャレイヤ及び前記デプスレイヤの双方又は前記テクスチャレイヤを復号化して前記テクスチャ画像及び前記デプス画像の双方又は前記テクスチャ画像を生成し、
生成した画像を基に、前記画像生成方法にしたがって表示画像を生成する
処理をコンピュータに実行させる再生処理方法。
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113792150A (zh) * | 2021-11-15 | 2021-12-14 | 湖南科德信息咨询集团有限公司 | 一种人机协同的智能需求识别方法和*** |
Families Citing this family (2)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012510102A (ja) * | 2008-11-24 | 2012-04-26 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 三次元guiにおける二次元グラフィックスの拡張 |
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)
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) |
-
2020
- 2020-03-31 WO PCT/JP2020/014888 patent/WO2020261690A1/ja active Application Filing
- 2020-03-31 US US17/615,586 patent/US20220247991A1/en active Pending
- 2020-03-31 CN CN202080045603.7A patent/CN114009054A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012510102A (ja) * | 2008-11-24 | 2012-04-26 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 三次元guiにおける二次元グラフィックスの拡張 |
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)
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 |