WO2018180511A1 - 画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法 - Google Patents

画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法 Download PDF

Info

Publication number
WO2018180511A1
WO2018180511A1 PCT/JP2018/010081 JP2018010081W WO2018180511A1 WO 2018180511 A1 WO2018180511 A1 WO 2018180511A1 JP 2018010081 W JP2018010081 W JP 2018010081W WO 2018180511 A1 WO2018180511 A1 WO 2018180511A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
rinf
tile
region
image
Prior art date
Application number
PCT/JP2018/010081
Other languages
English (en)
French (fr)
Inventor
遼平 高橋
平林　光浩
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Publication of WO2018180511A1 publication Critical patent/WO2018180511A1/ja

Links

Images

Classifications

    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/167—Position within a video image, e.g. region of interest [ROI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback

Definitions

  • the present technology relates to an image generation apparatus and an image generation method, and an image reproduction apparatus and an image reproduction method, and in particular, an image generation apparatus and an image generation that make it easy to use rinf information and easily reproduce an image.
  • the present invention relates to a method, an image reproducing apparatus, and an image reproducing method.
  • Non-Patent Document 1 a Restricted Scheme Information Box (rinf) is defined.
  • information stereo packing information etc.
  • post-processing such as rendering of the entire picture is stored.
  • FIG. 1 is a diagram showing the configuration of MP4.
  • the MP4 is composed of a nested box.
  • the box arranged at the lower right is arranged in the box arranged at the upper left. Boxes arranged in the same column are arranged in parallel.
  • each box of ftyp (File Type Box), moov (Movie Box), moof (Movie Fragment Box), and mdat (Media Data) is arranged in parallel in MP4.
  • trak Trace Box
  • mdia Media Box
  • minf Media Information Box
  • stbl Sample Table Box
  • stsd Sample Discription Box
  • sbgp SampleToGroupBox
  • sgpd SampleGroupDescriptionBox
  • Resv (Sample Entry) is placed in stsd, and hvcC (HEVC configuration Box) and rinf (Restricted Scheme Information Box) are placed in resv.
  • rinf information used in post-processing (rendering etc.) after decoding, that is, information that does not need to be known before decoding is stored.
  • schm Scheme Type Box
  • schi Scheme Information Box
  • the traf (Track Fragment Box) is placed in moof, and sbgp and sgpd are placed in traf.
  • FIG. 2 is a diagram showing an example of information existing in rinf. As described with reference to FIG. 1, schm and schi are arranged in rinf. As shown in FIG. 2, povd (Projected Omnidirectional Video Box), fovd (Fisheye Omnidirectional Video Box), rwpk (Region Wise Packing Box), and stvi (Stereo Video Box) are arranged in schi.
  • povd Projected Omnidirectional Video Box
  • fovd Fisheye Omnidirectional Video Box
  • rwpk Registered Wise Packing Box
  • stvi Stepo Video Box
  • schm scheme_type When schm scheme_type is odvd, either povd or fovd is required.
  • feye stores metadata for Fisheye.
  • rwpk a conversion table of a projected frame and a packed frame region for region-wise packing is stored.
  • stvi indicates a stereo video and a stereo arrangement type (top-bottom, side-to-side, etc.). rwpk and stvi are optional when povd is present.
  • prfr ProjectionFormatBox
  • pror ProjectionOrientationBox
  • covi CrossageInformationBox
  • prfr indicates projection format and geometry type. prfr is mandatory.
  • pror indicates the direction of projection. pror is optional.
  • covi indicates content coverage information. The absence of covi means that the area covers the entire 360 degrees. covi is optional.
  • FIG. 3 is a diagram illustrating a configuration example of prfr
  • FIG. 4 is a diagram illustrating prfr fields.
  • geometry_type and projection_type are described in prfr.
  • geometry_type indicates a coordinate system to be used, and a value of 1 means a spherical coordinate system.
  • the projection_type indicates a projection format, and a value of 1 means an equirectangular projection.
  • FIG. 5 is a diagram illustrating a configuration example of covi
  • FIG. 6 is a diagram illustrating the fields of covi.
  • center_yaw, center_pitch.hor_range, and ver_range are described as coverage information.
  • center_yaw represents the yaw angle at the center of the area
  • center_pitch represents the pitch angle at the center of the area
  • hor_range represents the horizontal angle range of the area
  • ver_range represents the vertical angle of the area. Represents a range.
  • a sample group is defined as a general-purpose mechanism that links information other than basic information such as codec information and access information of the sample table (sample table) of ISOBMFF to sample. .
  • a tile region group (TileRegionGroup). This is a sample group indicating a tile region where one or more HEVC (High Efficiency Video Coding) tiles are defined in ISO / IEC (International Organization for standardization / International electrotechnical Commission) 14496-15.
  • the entry of TileRegionGroup is TileRegionGroupEntry (trif).
  • TileRegionGroup a part of a picture (tile) can be decoded independently.
  • FIG. 7 is a diagram showing an example of Sample Group.
  • sgpd and sbgp are arranged in stbl (or traf).
  • grouping_type is described as 'XXXX'
  • entry_count the number of entries
  • GroupEntry () [1] to GroupEntry () [4] are described as GroupEntry.
  • Sbgp describes that grouping_type is ‘XXXX’, grouping_type_parameter is ‘YYYY’, and entry_count (number of entries) is 6.
  • sample_count [1] indicating the number of sample IV
  • group_description_index [1] indicating GroupEntry IV is described as 1.
  • sample_count [1] corresponds to the first Sample [1] of the mdat samples.
  • sample_count [4] 1 corresponds to sample [5] which is one sample after sample [4] of mdat.
  • Sbgp sample_count [5] 1.
  • sample_count [6] 2 corresponds to sample [7] and sample [8] which are the next two samples after mdat sample [6].
  • ISO / IEC 96 14496-12 Information technology-Coding of audio-visual objects-P art12 ISO base media file
  • the information under rinf is necessary information for rendering, but for example, when decoding only a part of a tile of a picture, it may be used as a criterion for determining which tile should be decoded. .
  • the present technology has been made in view of such a situation, and makes it possible to easily reproduce an image.
  • One aspect of the present technology is an image generation apparatus including a generation unit that generates related information for associating information to be referred to by rinf with a Sample Group, and an addition unit that adds the related information to the Sample Group.
  • the related information may be information indicating the presence / absence of information to be referred to by the rinf.
  • the related information can be described in TileRegionGroupEntry, SampleGroupDescriptionEntry or SampleGroupDescriptionBox.
  • information to be referred to by the rinf can be added to a box other than the rinf.
  • the boxes other than the rinf can be a plurality of boxes identified by different grouping_types.
  • the generation unit generates dependency information representing a dependency relationship when processing a plurality of pieces of information necessary for rendering under the rinf, and the addition unit adds the dependency information to the box under the rinf. Can do.
  • the dependency information may be a processing order.
  • the plurality of information can be information of different boxes under schi.
  • the dependency information can be described in a box under the rinf that is different from the plurality of information.
  • the dependency information can be described in the schi or schm.
  • the dependency information can be described as a box in scheme specific data.
  • One aspect of the present technology is an image generation method including a generation step of generating related information for associating information to be referred to by rinf with a Sample Group, and an adding step of adding the related information to the Sample Group.
  • One aspect of the present technology is an image reproduction device including a selection unit that selects related information for associating information to be referred to by rinf with Sample Group, and a processing unit that performs processing based on the selected related information. .
  • One aspect of the present technology is an image reproduction method including a selection step of selecting related information for associating information to be referred to by rinf with Sample Group, and a processing step of performing processing based on the selected related information. .
  • related information for associating information to be referenced by rinf with Sample Group is generated, and related information is added to Sample Group.
  • related information for associating information to be referred to by rinf with Sample Group is selected, and processing based on the selected related information is performed.
  • the information of rinf can be easily used and an image can be easily reproduced.
  • the effects described in this specification are merely examples, and are not limited, and may have additional effects.
  • First Embodiment Association with Sample Group (FIGS. 10 to 51) (1-1) First example (FIGS. 10 to 24) (1-2) Second example (FIGS. 25 and 26) (1-3) Third example (FIGS. 27 and 28) (1-4) Fourth example (FIGS. 29 to 31) (1-5) Fifth example (FIGS. 32 to 42) (1-6) Sixth example (FIGS. 43 to 51) 2.
  • FIG. 61 and 62 Generation processing and reproduction processing (FIGS. 63 to 70) (3-1) Image processing system (FIGS. 63 to 66) (3-2) Generating process of the first embodiment (FIG. 67) (3-3) Reproduction process of the first embodiment (FIG. 68) (3-4) Generation processing of the second embodiment (FIG. 69) (3-5) Reproduction process of the second embodiment (FIG. 70) 4).
  • Computer Fig. 71) 5).
  • FIG. 10 is a diagram illustrating a configuration example of the TileRegionGroupEntry
  • FIG. 11 is a diagram illustrating fields of the TileRegionGroupEntry.
  • GroupID and tile_region_flag are described in this TileRegionGroupEntry.
  • GroupID is a unique identifier of tile region group.
  • tile_region_flag is a flag indicating whether the NAL unit associated with tile region is a tile region. The value 0 indicates that the NAL unit associated with the tile region region is not a tile region. The value 1 indicates that the NAL unit associated with the tile region is a tile region.
  • tile_region_flag is 1 (not! Tile_region_flag), independent_idc, full_picture, filtering_disabled, and has_dependency_list are described.
  • Independent_idc indicates the dependency of the tile region with respect to another tile region or picture.
  • the value 0 indicates that tile region belonging to this tile region group has coding dependency with respect to tile region of the same picture or reference picture of the same layer.
  • the value 1 indicates that tile region belonging to tile region group does not have temporal dependency for tile region having a different group ID.
  • the value 2 indicates that tile region belonging to this tile region group has no coding dependency for the reference picture in the same layer.
  • “Full_picture” represents the relationship between the tile region and the entire picture, and the value 1 indicates that the tile region belonging to the tile region group is the entire picture.
  • filtering_disabled represents whether or not the pixel acquisition of the neighboring tile region is necessary when performing in-loop filtering.
  • a value of 1 indicates that a tile region belonging to the tile region region does not need to acquire a pixel of the neighboring tile region when performing in-loop filtering.
  • has_dependency_list represents the presence of dpendency_tile_count, and its value 0 indicates that dpendency_tile_count does not exist. The value 1 indicates that dpendency_tile_count exists.
  • regionwidth indicates the width of the rectangular region covered by this tile region group.
  • region_height indicates the height of the rectangular region covered by this tile region region.
  • horizontal_offset indicates the horizontal position of the rectangular area covered by this tile
  • vertical_offset indicates the vertical position of the rectangular area covered by this tile
  • dependency_tile_count indicates the number of tile regions in which this tile region group has dependency.
  • dependencyTileGroupID indicates the GroupID of the tile region where the tile region region has dependency.
  • FIG. 12 is a diagram for explaining restricted_scheme_info_dependent_flag.
  • restricted_scheme_info_dependent_flag is a flag relating to the presence of information to be referred to by rinf. The value 0 indicates that there is no information to be referenced in rinf when decoding this SampleGroupEntry, and the value 1 indicates that there is information to be referenced in rinf when decoding this SampleGroupEntry. Show.
  • TileRegionGroupEntry instead of TileRegionGroupEntry, other SampleGroupEntry can be extended and the flag restricted_scheme_info_dependent_flag can be described there.
  • FIG. 13 is a diagram illustrating the configuration of video stored in ISOBMFF
  • FIG. 14 is a diagram illustrating the description of povd and rwpk.
  • FIG. 13 shows a region frame wise packed frame 11 of a video stored in ISOBMFF.
  • the packed frame 11 is divided into six tile regions, but it is unclear what each tile region indicates unless the information of rinf is referred to.
  • packedpackframe 22 is generated by region wise packaging of projected frame 21 as shown in Fig. 14. .
  • the projected frame 21 is generated by cube mapping projection of the omnidirectional image.
  • left, front, right, and back tiles are arranged in order from the left in the center row, a top tile is arranged on the front, and a bottom tile is arranged below.
  • a front tile is arranged at the lower left
  • a right tile is arranged at the left side above it
  • a back tile is arranged at the right side above it.
  • a top tile is placed on the right side of the front tile
  • a bottom tile is placed below.
  • a left tile is arranged on the right side of the back tile and above the top tile.
  • the tiles of right, back, left, top, and bottom are reduced in length in the horizontal and vertical directions to 1 ⁇ 2 of the front.
  • FIG. 15 is a diagram illustrating a configuration example of povd. As shown in FIG. 15, ProjectionFormatBox (), ProjectionOrientationBox (), and CoverageInformationBox () are stored in povd. ProjectionFormatBox () is essential, and ProjectionOrientationBox () and CoverageInformationBox () are optional.
  • FIG. 16 is a diagram illustrating a configuration example of rwpk
  • FIG. 17 is a diagram illustrating rwpk fields.
  • num_regions indicates the number of regions.
  • proj_frame_width indicates the width of the projected frame (projected frame)
  • proj_frame_height indicates the height of the projected frame.
  • packing_type [i] represents information regarding region-wise packing, and a value of 0 indicates region-wise packing of a rectangular area.
  • RectRegionPacking (i) is described. Details thereof are shown in FIG. 46 described later.
  • proj_reg_width [i], proj_reg_height [i], proj_reg_top [i], proj_reg_left [i], transform_type [i], packed_reg_width [i], packed_reg_height [i], packed_reg_top [i], packed_reg_left [i] are described .
  • Proj_reg_width [i] indicates the area width of the projected frame
  • proj_reg_height [i] indicates the area height of the projected frame
  • proj_reg_top [i] indicates the vertical position (upper left of the projected frame is 0) of the upper left corner pixel of the region in the projected frame
  • proj_reg_left [i] indicates the horizontal position of the pixel in the upper left corner of the region in the projected frame (the upper left of the projected frame is 0).
  • Transform_type [i] specifies the rotation and mirroring of the area.
  • the value 1 indicates no conversion
  • the value 2 is horizontal mirroring
  • the value 3 is rotated 180 ° counterclockwise
  • the value 4 is rotated 180 ° counterclockwise after horizontal mirroring.
  • Its value 5 is 90 ° counterclockwise after horizontal mirroring
  • its value 6 is 90 ° counterclockwise
  • its value 7 is 270 ° counterclockwise after horizontal mirroring
  • its value 8 Indicates 270 ° counterclockwise.
  • Packed_reg_width [i] indicates the area width of the packed frame
  • packed_reg_height [i] indicates the area height of the packed frame.
  • packed_reg_top [i] indicates the vertical position (the upper left corner of the packed frame is 0) of the upper left corner pixel of the region in the packed frame.
  • packed_reg_left [i] indicates the horizontal position (the upper left corner of the packed frame is 0) of the upper left corner pixel of the region in the packed frame.
  • the flag restricted_scheme_info_dependent_flag is described in TileRegionGroupEntry. Therefore, based on this flag, it becomes possible to know whether or not there is information to be referred to when decoding SampleGroupEntry in rinf. As a result, the information of rinf can be easily used, and an effect of easily and efficiently reproducing an image can be realized.
  • FIG. 18 is a diagram illustrating the configuration of a video stored in ISOBMFF
  • FIG. 19 is a diagram illustrating the description of povd, rwpk, and stvi.
  • FIG. 18 shows a packed frame 41 of a region wise packed in a video stored in ISOBMFF.
  • the packed frame 41 is divided into 12 tile ⁇ regions, but it is unclear what each tile region indicates without referring to rinf.
  • a packed frame 52 is generated by region-wise packing of a projected frame 51 in which left-view and right-view stereo images are arranged side-to-side.
  • the projected frame 51 is generated by cube mapping projection of the omnidirectional image.
  • a left view image is arranged on the left side, and a right view image is arranged side-to-side on the right side.
  • the left, front, right, and back tiles are arranged in order from the left in the center row, the top tile is arranged above the front, and the bottom tile is arranged below.
  • the left, front, right, and back tiles are arranged in order from the left in the center row, with the top tile above the front and the bottom tile below.
  • the horizontal length is 1 ⁇ 2 of the vertical length.
  • the left ⁇ view image is arranged on the left side
  • the right view image is arranged side-to-side on the right side.
  • a front tile is arranged at the lower left
  • a right tile is arranged on the left side above it
  • a back tile is arranged on the right side above it.
  • a top tile is placed on the right side of the front tile
  • a bottom tile is placed below.
  • a left tile is arranged on the right side of the back tile and above the top tile.
  • the front tile is arranged at the lower left
  • the right tile is arranged at the upper left side
  • the back tile is arranged at the upper right side.
  • a top tile is placed on the right side of the front tile
  • a bottom tile is placed below.
  • a left tile is arranged on the right side of the back tile and above the top tile.
  • the horizontal and vertical lengths of tiles other than the front are 1 ⁇ 2 of the front tile.
  • FIG. 20 is a diagram illustrating a configuration example of stvi
  • FIG. 21 is a diagram illustrating the stvi field.
  • single_view_allowed represents information regarding display permission.
  • a value of 0 means that the content is intended to be displayed only on a stereoscopic display.
  • Stereo_scheme represents information related to the frame packing method.
  • the value 1 indicates that the frame packing method conforms to Frame / packing / arrangement / SEI of ISO / IEC 14496-10, and the value 2 indicates that the frame packing method conforms to Annex.L of ISO / IEC / 13818-2. .
  • the value 3 indicates that the frame packing method follows the ISO / IEC 23000-11 frame / sevice compatible and 2D / 3D mixed mixed sevice.
  • Length indicates the byte length of stereo_indication_type
  • stereo_indication_type indicates a frame packing method according to stereo_shceme.
  • the flag restricted_scheme_info_dependent_flag is described in TileRegionGroupEntry. Therefore, based on this flag, it becomes possible to know whether or not there is information to be referred to when decoding SampleGroupEntry in rinf. As a result, the information of rinf can be easily used, and an effect of easily and efficiently reproducing an image can be realized.
  • FIG. 22 is a diagram for explaining the descriptions of povd, rwpk, and stvi.
  • a packed frame 62 is generated by region-wise packing of a projected frame 61 in which left-view and right-view stereo images are arranged side-to-side.
  • the projected frame 61 is generated by performing cube mapping projection on the omnidirectional image.
  • a left view image is arranged on the left side
  • a right view image is arranged on the right side.
  • the left, front, right, and back tiles are arranged in order from the left in the center row
  • the top tile is arranged above the front
  • the bottom tile is arranged below.
  • the left, front, right, and back tiles are arranged in order from the left in the center row, with the top tile above the front and the bottom tile below.
  • the horizontal length is 1 ⁇ 2 of the vertical length.
  • the front tile is arranged at the lower left, the right tile is arranged on the left side above it, and the back tile is arranged on the right side above it.
  • a top tile is placed on the right side of the front tile, and a bottom tile is placed below.
  • a left tile is arranged on the right side of the back tile and above the top tile. That is, each of the tiles of right, back, left, top, and bottom is reduced in length in the horizontal and vertical directions to 1/2 of the front.
  • a left-view image is arranged on the left side and a right-view image is arranged on the right side.
  • the Tile region group when decoding the Tile region group, it is possible to determine which Tile region group in the packed frame 62 is the original region in the projected frame 61 by referring to povd, rwpk, stvi. That is, it can be seen which tile in the packed frame 62 is front, right, back, left, top, bottom. Therefore, for example, when it is desired to decode the front tiles in stereo as a pair, it can be seen that the lower left Tile Region 62A of the packed frame 62 is composed of the front left view and the right view. As a result, the stereo front tile can be decoded independently.
  • the flag restricted_scheme_info_dependent_flag is described in TileRegionGroupEntry. Therefore, based on this flag, it becomes possible to know whether or not there is information to be referred to when decoding SampleGroupEntry in rinf. As a result, the information of rinf can be easily used, and an effect of easily and efficiently reproducing an image can be realized.
  • FIG. 23 is a diagram illustrating the configuration of a video stored in ISOBMFF
  • FIG. 24 is a diagram illustrating the description of stvi.
  • a packed region 81 of video stored in ISOBMFF is divided into two tile regions 81A and tile regions 81B.
  • each tile region indicates without referring to the information of rinf.
  • stvi Fig. 2 below schi below rinf
  • FIG. 24 it can be seen that left view and right view stereo images are arranged side-to-side and a packed frame 91 is generated.
  • a left tile view 91A is arranged on the left side
  • a right tile tile 91B is arranged on the right side.
  • Tile Region Group when Tile Region Group is decoded, it is possible to determine whether each Tile Region is left view or right view by referring to stvi. Therefore, for example, when it is desired to decode left view, it is understood that Tile Region 91A is left view, and it can be decoded independently.
  • the flag restricted_scheme_info_dependent_flag is described in TileRegionGroupEntry. Therefore, based on this flag, it becomes possible to know whether or not there is information to be referred to when decoding SampleGroupEntry in rinf. As a result, the information of rinf can be easily used, and an effect of easily and efficiently reproducing an image can be realized.
  • FIG. 25 is a diagram illustrating a configuration example of SampleGroupDescriptionEntry.
  • this SampleGroupDescriptionEntry is an abstract class, in which restricted_scheme_info_dependent_flag is described.
  • restricted_scheme_info_dependent_flag The meaning of restricted_scheme_info_dependent_flag is as described with reference to FIG.
  • All SampleGroupEntry inherits this abstract class. That is, all SampleGroupEntry has the function that the abstract class has. Therefore, all SampleGroupEntry have restricted_scheme_info_dependent_flag.
  • FIG. 26 is a diagram illustrating a configuration example of VisualSampleGroupEntry. As shown in FIG. 26, this VisualSampleGroupEntry is abstract class, in which restricted_scheme_info_dependent_flag is described. VisualSampleGroupEntry related to all videos is defined by inheriting this abstract class.
  • VisualSampleGroupEntry extensions to AudioSampleGroupEntry, Hint SampleGroupEntry, SubtitleSampleGroupEntry, and TextSampleGroupEntry can be performed.
  • FIG. 27 is a diagram illustrating a configuration example of the SampleGroupDescriptionBox
  • FIG. 28 is a diagram illustrating fields of the SampleGroupDescriptionBox.
  • grouping_type is an identifier for identifying SampleToGroupBox associated with this sample group description.
  • entry_count indicates the number of entries in the for loop table following this field.
  • SampleGroupEntry indicates an entry of SampleGroup.
  • sampleGroupDescriptionBox version When sampleGroupDescriptionBox version is 1, default_length is described. version indicates the version of SampleGroupDescriptionBox IV. default_length indicates the size of all sample group entries. A value of 0 indicates that the size of the group entry changes. When version is 2 or more, default_sample_description_index is described. default_sample_description_index indicates the id of sample group entry to which all samples not linked to sample group entry are linked by SampleToGroupBox. If version is 1 and default_length is 0, description_length is described. description_length indicates the size of each sample group entry.
  • restricted_scheme_info_dependent_flag represents information related to information to be referred to by rinf.
  • the value 0 indicates that there is no information to be referred to in rinf when decoding the GroupGroup_type SampleGroupEntry.
  • the value 1 indicates that there is information to be referred to in rinf when decoding this Grouping_type SampleGroupEntry.
  • the flag restricted_scheme_info_dependent_flag clearly indicates that information to be referred to exists in rinf when referring to SamplesampleGroup and decoding a part of sample. . This clearly indicates that at least a part of the information stored in rinf is information to be referred to.
  • the image reproducing apparatus can determine whether or not to refer to rinf at the time of decoding, and it becomes easy to perform an appropriate decoding process. However, the process is not completed only by referring to Sample Group, and it is necessary to refer to rinf.
  • Sample Group is a general-purpose mechanism that groups ISOBMFF samples together and links information to the group.
  • VisualRollRecoveryEntry, AudioRollRecoveryEntry, VisualRandomAccessEntry, etc. are also available.
  • VisualRollRecoveryEntry is a SampleGroup for signaling samples necessary to correctly decode the video sample to which it belongs.
  • AudioRollRecoveryEntry is a SampleGroup for signaling samples necessary for correctly decoding the audio samples to which the AudioRollRecoveryEntry belongs.
  • VisualRandomAccessEntry is a SampleGroup for signaling information necessary for decoding at the time of random access to the video sample to which it belongs.
  • FIG. 29 is a diagram illustrating a configuration example of TileRegionGroupEntry ()
  • FIG. 30 is a diagram illustrating fields of TileRegionGroupEntry ().
  • tile_region_flag As shown in FIG. 29, in this TileRegionGroupEntry (), groupID and tile_region_flag are described.
  • tile_region_flag is 1, independent_idc, full_picture, filtering_disabled, has_dependency_list, region_width, region_height are described.
  • full_picture is not 1 (when (! full_picture))
  • horizontal_offset and vertical_offset are described.
  • has_dependency_list is 1, dependency_tile_count and dependencyTileGroupID are described.
  • stereo_packed represents information regarding the stereoscopic of the Tile region.
  • a value of 0 means that Tile region is not stereoscopic, and a value of 1 indicates that Tile region is stereoscopic.
  • full_sphere represents information related to the 360 ° celestial sphere cover of Tile Region.
  • a value of 0 indicates that the Tile ⁇ ⁇ ⁇ Region does not cover the 360 ° celestial sphere region, and a value of 1 indicates that the Tile Region covers the 360 ° celestial sphere region.
  • stereo_packed 1, stereo_indication_type is described. Otherwise, view_idc is described. These indicate whether or not the Tile region is stereoscopic.
  • Stereo_indication_type represents information about the type of stereo pack.
  • a value of 3 indicates that the Tile region is side-to-side stereo packed, and a value of 4 indicates that the Tile region is top-bottom stereo packed.
  • view_idc represents the type of view. The value 0 indicates center view (when the picture to which Tile region belongs is mono), the value 1 indicates left view (when the picture to which Tile region belongs is stereo), and the value 2 indicates right view ( The picture to which Tile region belongs is stereo).
  • Shape_type represents information related to the region shape.
  • the value 0 means a region shape surrounded by four great circles, and the value 1 means a region shape surrounded by two small and two grate circles.
  • FIG. 31 is a diagram for explaining the region shape.
  • great circle means a circle C1 whose center coincides with the center of the sphere, and corresponds to, for example, a longitude line of the globe. Therefore, the region shape surrounded by four great circles is a region surrounded by four circles C1 (great circles).
  • small circle means a circle C2 other than the great circle, and corresponds to the latitude line of the globe. Therefore, the region shape surrounded by two small and two grate circles is an area surrounded by two circles C1 (grate circles) and two circles C2 (small circles) as shown in FIG.
  • Center_yaw indicates the yaw angle at the center of the region
  • center_pitch indicates the pitch angle at the center of the region
  • hor_range indicates the horizontal angle range of the region
  • ver_range indicates the vertical angle range of the region.
  • TileRegionGroupEntry determines whether Tile Region is stereoscopic or not, and detailed information such as region information is described in TileRegionGroupEntry (), so it is not necessary to refer to rinf during decoding.
  • the information to be referred to is stored outside rinf, so that it is not necessary to refer to rinf twice more. That is, rinf information is easy to use. As a result, efficient processing is possible, and images can be easily reproduced.
  • the area on the projected frame may be expressed in a two-dimensional coordinate system.
  • the projection format may be signaled.
  • Tile Region is stereoscopic or not
  • detailed information such as region information is information to be referred to as part of the information stored in rinf. These pieces of detailed information may be described in their positions instead of the restricted_scheme_info_dependent_flag in FIGS.
  • RegionOnSphereGroupEntry () and StereoPackedGroupEntry () are defined as new SampleGroupEntry. And, to associate RegionOnSphereGroupEntry () and StereoPackedGroupEntry () with TileRegionGroupEntry, SampleToGroupBox is extended.
  • FIG. 32 is a diagram illustrating a configuration example of RegionOnSphereGroupEntry ()
  • FIG. 33 is a diagram illustrating a configuration example of StereoPackedGroupEntry ()
  • FIG. 34 is a diagram illustrating a configuration example of SampleToGroupBox.
  • groupID full_sphere is described in RegionOnSphereGroupEntry (). Furthermore, if full_sphere is not 1 (if (! Full_sphere)), shape_type, center_yaw, center_pitch, hor_range, and ver_range are described. That is, information on the spherical area is described.
  • stereoPackedGroupEntry groupID and stereo_packed are described. If stereo_packed is 1, stereo_indication_type is described. Otherwise (if stereo_packed is 0), view_idc is described. The That is, a stereo pack method is described.
  • the information on the spherical area and the stereo pack method are information to be referred to as part of the information stored in rinf.
  • RegionOnSphereGroupEntry () and StereoPackedGroupEntry () shown in FIG. 32 and FIG. 33 may be extended with respect to SampleGroupDescriptionEntry, AudioSampleGroupEntry, HintSampleGroupEntry, SubtitleSampleGroupEntry, and TextSampleGroupEntry instead of VisualSampleGroupEntry.
  • FIG. 35 is a diagram for explaining the operation of the TileRegionGroup.
  • sample_count [1] 4 corresponds to mdat samples [1] to sample [4].
  • the image 101 is composed of tile region 1 and tile region 2.
  • the group ID determines which TileRegionGroupEntry belongs to.
  • FIG. 36 is a diagram for explaining the operation of TileRegionGroup when SampleToGroupBox IV is extended.
  • grouping_type “nalm”
  • entry_count 1
  • SampleGroupDescriptionBox whose grouping_type is “trif”.
  • SampleGroupDescriptionBox shown on the left side of the figure has three SampleGroupDescriptionBox (sgpd) whose grouping_types are “trif”, “rosp”, and “spak”.
  • Group A groupID is assigned to each sample's NAL unit, and it is determined by the groupID which TileRegionGroupEntry () belongs. Which RegionOnSphereGroupEntry () belongs to is determined by the groupID. Which StereoPackedGroupEntry () belongs to is determined by the groupID.
  • SampleGroup in the fifth example can be stored in, for example, a file and a track as shown in FIG.
  • FIG. 37 is a diagram illustrating a configuration example of a file and a track.
  • FIG. 37A shows an example in which a plurality of tiles (two in the example of FIG. 37A) are stored in one track of one file.
  • tile region 1 and tile region 2 are stored as Sample Entry (hvc1) in one track of one MP4 file.
  • B in FIG. 37 represents an example in which a plurality of tiles (two in the example of B in FIG. 37) are stored in 2 tracks of 1 file.
  • tile region 1 is stored as Sample Entry (hvt1) in one track of one MP4 file
  • tile region 2 is stored as Sample Entry (hvt1) in another track of the same MP4 file. Stored.
  • FIG. 37C shows an example in which a plurality of tiles (two in the example of FIG. 37C) are stored in one file in one file.
  • tile region 1 is stored as Sample Entry (hvt1) in one track of one MP4 file
  • tile region 2 is stored as Sample Entry (hvt1) in that one track of another MP4 file. Stored.
  • the MP4 file shown in FIGS. 38 to 40 is configured as an MPEG-DASH MPD (Media Presentation Description) file.
  • MPEG-DASH MPD Media Presentation Description
  • FIG. 38 is a diagram showing a configuration example of the MPD file, and corresponds to the case A in FIG.
  • the AdaptationSet is included in the Period
  • the Representation is included in the AdaptationSet
  • the Segment boxes are included in the Representation.
  • Codecs hvc1 is described in AdaptationSet.
  • Value 1,0,0,360,180,0,0,360,180,1 is described in SupplementalProperty.
  • This value is a specific value of coverage information, and means source_id, center_yaw, center_pitch, hor_range, ver_range, total_center_yaw, total_center_pitch, total_hor_range, total_ver_range, and spatial_set_id, respectively. Details thereof will be described later with reference to FIGS. 41 and 42.
  • One MP4file having one track is stored in Segment.
  • FIG. 39 is a diagram showing a configuration example of the MPD file, and corresponds to the case B in FIG.
  • the value of ver_range is different, 120 on the one hand and 240 on the other hand, but the other values are the same.
  • FIG. 40 is a diagram showing a configuration example of an MPD file, and corresponds to the case C in FIG.
  • two AdaptationSets are arranged in Period, and Representation and Segment are sequentially arranged in each.
  • codecs hvt1
  • SupplementalProperty value 1,0,0,240,180,0,0,360,180,1.
  • one of two MP4MP files having one track in one MP4 file is stored.
  • FIG. 41 is a diagram for explaining value
  • FIG. 42 is a diagram for explaining elements of value. 41, source_id, center_yaw, center_pitch, hor_range, ver_range, total_center_yaw, total_center_pitch, total_hor_range, total_ver_range, and spatial_set_id are described in the value of SupplementalPropertyvalue.
  • source_id indicates an identifier of the original content.
  • center_yaw indicates the yaw angle at the center of the region.
  • center_pitch indicates the pitch angle at the center of the region.
  • hor_range represents the horizontal angle range of the region.
  • ver_range indicates the vertical angle range of the region.
  • Total_center_yaw indicates the yaw angle of the center of the entire area grouped by spatial_set_id.
  • total_center_pitch indicates the pitch angle of the center of the entire area grouped by spatial_set_id.
  • Total_hor_range indicates the horizontal angle range of the entire area grouped by spatial_set_id.
  • total_ver_range indicates the vertical angle range of the entire area grouped by spatial_set_id.
  • spatial_set_id indicates id indicating grouping of the same resolution or the like. When spatial_set_id is present, total_ * is essential (* means center_yaw, center_pitch, hor_range, or ver_range).
  • the information to be referred to is stored outside rinf, so it is necessary to refer to rinf twice more. Disappear. That is, rinf information is easy to use. Therefore, an image can be easily reproduced.
  • a flag is used as related information for associating information to be referred to by rinf, which is added to Sample Group, and the fourth and fifth examples are used. Detailed information is used in the examples. As a result, it becomes easy to use the information of rinf, and the image can be easily reproduced.
  • the region information of region wise has a reference to TileRegionGroup.
  • RegionWisePackingBox is extended.
  • a first extension method of the RegionWisePackingBox will be described with reference to FIGS. 43 to 46.
  • FIG. 43 is a diagram illustrating a configuration example of the RegionWisePackingBox
  • FIG. 44 is a diagram illustrating a configuration example of the RegionWisePackingStruct.
  • FIG. 45 is a diagram for explaining the fields of RegionWisePackingStruct.
  • FIG. 46 is a diagram illustrating a configuration example of RectRegionPacking.
  • RegionWisePackingBox inherits RegionWisePackingStruct.
  • RegionWisePackingStruct As shown in FIG. 44, in RegionWisePackingStruct, num_regions, proj_frame_width, and proj_frame_height are described, and packing_type [i] is described according to the number of num_regions. When packing_type [i] is 0, RectRegionPacking (i) and tile_region_entry_count are described according to the number of num_regions. Further, tile_region_group_id is described according to the number of tile_region_entry_count.
  • tile_region_entry_count indicates the number of Tile regions where packed regions match or are included
  • tile_region_group_id is a group ID of Tile Region group.
  • RectRegionPacking (i) IV As shown in FIG. 46, the following fields are described in RectRegionPacking (i) IV. That is, proj_reg_width [i], proj_reg_height [i], proj_reg_top [i], proj_reg_left [i], transform_type [i], packed_reg_width [i], packed_reg_height [i], packed_reg_top [i], packed_reg_left [i] are described .
  • FIGS. 47 is a diagram illustrating a configuration example of RegionWisePackingStruct
  • FIG. 48 is a diagram illustrating packing_type
  • FIG. 49 is a diagram illustrating a configuration example of TileRegionPacking (i) i.
  • TileRegionPacking describes proj_reg_width [i], proj_reg_height [i], proj_reg_top [i], proj_reg_left [i], transform_type [i], and tile_region_group_id [i] Is done.
  • TileRegionPacking can be configured as shown in FIG. 50 instead of the example of FIG.
  • FIG. 50 is a diagram illustrating a configuration example of TileRegionPacking ()
  • FIG. 51 is a diagram illustrating stereo_packed_region.
  • stereo_packed_region represents information about a pair of left view and right view.
  • the value 0 indicates that the region is not composed of a pair of left view and right view
  • the value 1 indicates that the region is composed of a pair of left view and right view.
  • stereo_packed_region 1
  • proj_reg_width 1
  • proj_reg_height 1
  • proj_reg_top 1
  • proj_reg_top 1
  • proj_reg_left 1
  • transform_type 2
  • the signaled left view region and the corresponding right view region are stereo packed according to stvi.
  • stereo_packed_region 1, stereo_indication_type may be further signaled.
  • the region information of region wise packing has a reference to TileRegionGroup
  • the tile region corresponding to the region wise packing region can be easily recognized.
  • TileRegionGroupEntry a process of finding a tile region corresponding to a desired region wise packing region can be omitted. As a result, an image can be easily reproduced.
  • FIG. 52 is a diagram illustrating an example of information existing in rinf.
  • the configuration of FIG. 52 is basically the same as that shown in FIG. 2, but in this example, under the schi, in the same column as povd, fovd, rwpk, stvi, a Schp (Scheme Information Priority Box) Is newly defined.
  • schi is an arbitrary box having information on the application order of scheme specific information under a plurality of Scheme Information Boxes.
  • FIG. 53 is a diagram illustrating a configuration example of the SchemeInformationPriorityBox
  • FIG. 54 is a diagram illustrating fields of the SchemeInformationPriorityBox.
  • number_of_scheme_specific_data and the number of boxtype [i] corresponding to number_of_scheme_specific_data are described.
  • number_of_scheme_specific_data indicates the number of boxes of schemesspecific data (except for scp) stored under schi
  • boxtype indicates the box type (4 character code) of scheme specific data, Indicates that processing priority is higher in order of for loop.
  • the 4 character code is, for example, povd, fovd, rwpk, stvi and the like.
  • FIG. 55 is a diagram illustrating a configuration example of the schp
  • FIG. 56 is a diagram illustrating a processing procedure.
  • number_of_scheme_specific_data is set to 3 in the scp
  • boxtype [0] of rwpk, boxtype [1] of stvi, and boxtype [2] of povd as a 4-character code of boxtype. are described in that order.
  • processing at the time of rendering is performed in the order as shown in FIG.
  • a process referring to rwpk is performed on a packed frame 201 composed of 12 tiles.
  • a projected frame 211 in which a left view including six tiles of the packed frame 201 and a right view including other six tiles of the packed frame 201 are arranged side-to-side is generated.
  • a process of referring to stvi is performed on the projected frame 211 to generate a left frame view 221A and a right frame projected 221B.
  • the process of rendering the cube 231A and the cube 231B is performed with reference to the povd with respect to the left-view projected-frame 221A and the right-view projected-frame 221B.
  • the image reproducing apparatus can perform the post process in the correct processing order in accordance with the information of the schp.
  • FIG. 57 is a diagram illustrating a configuration example of a SchemeInformationBox.
  • this SchemeInformationBox as in the case of SchemeInformationPriorityBox in FIG. 53, number_of_scheme_specific_data and the number of boxtype [i] corresponding to number_of_scheme_specific_data are described. Also, Box scheme_specific_data [] is described.
  • Boxtype [i] is described as shown in FIG. 55, for example. In that case, processing similar to that described with reference to FIG. 56 is performed.
  • FIG. 58 is a diagram illustrating a configuration example of the SchemeInformationPriorityBox
  • FIG. 59 is a diagram illustrating priority.
  • priority is described in the SchemeInformationPriorityBox.
  • priority indicates the processing priority of schemesspecific data. Value 1 has the highest priority, and the priority decreases as the value increases. A value of 0 indicates no priority.
  • FIG. 60 is a diagram illustrating a configuration example of StereoVideoBox.
  • StereoVideoBox in addition to single_view_allowed, stereo_scheme, length, stereo_indication_type, SchemeInformationPriorityBox scheme_info_priority is described. That is, SchemeInformationPriorityBox is stored in stvi. As a result, processing is performed according to the order of priorities described in priority.
  • FIG. 61 is a diagram illustrating a configuration example of SchemeTypeBox
  • FIG. 62 is a diagram illustrating priority_flag.
  • scheme_type In this SchemeTypeBox (schm), scheme_type, scheme_type, scheme_version (scheme version) is described.
  • version 1
  • priority_flag represents information related to the processing procedure of scheme_specific_data.
  • the value 0 indicates that the processing order of scheme_specific_data under the scheme is indefinite
  • the value 1 indicates that the scheme_specific_data under the scheme is processed from the top in the defined order.
  • flags is 1 (when (flags & 0x000001)
  • scheme_uri [] (browser uri) is described. As a result, processing according to the order described in priority_flag is performed.
  • the image reproducing apparatus can know the processing order and can perform an appropriate rendering process. As a result, it becomes easy to use the information of rinf, and the image can be easily reproduced.
  • information representing dependency is used as related information for associating information to be referred to by rinf.
  • FIG. 63 is a block diagram illustrating the configuration of the image processing system
  • FIG. 64 is a block diagram illustrating the configuration of the file generation unit
  • FIG. 65 is a block diagram illustrating the configuration of the file analysis unit
  • FIG. 3 is a block diagram illustrating a configuration of a display unit.
  • the image processing system 301 includes an image generation device 311 that generates and outputs an image, and an image reproduction device 312 that reproduces an image supplied from the image generation device 311.
  • the image generation apparatus 311 includes a data input unit 321 that inputs data, an encoder 322 that encodes data supplied from the data input unit 321, and a file generation unit 323 that generates a file from the encoded data.
  • the file generated by the file generation unit 323 is supplied to the image playback device 312.
  • the image playback device 312 includes a file analysis unit 331 that analyzes the file generated by the file generation unit 323, a decoder 332 that decodes the output of the file analysis unit 331, and a display unit 333 that displays the decoded image. Yes.
  • the file generation unit 323 includes a determination unit 351 that performs various determination processes, a storage unit 352 that stores data, an addition unit 353 that performs information addition processing, and a file A generation unit 354 that performs generation processing is configured.
  • the file analysis unit 331 includes a determination unit 371 that performs various determination processes, a selection unit 372 that performs various selection processes, and an analysis unit 373 that performs analysis processes.
  • the display unit 333 performs a selection unit 391 that performs various selection processes, a determination unit 392 that performs various determination processes, a post process unit 393 that performs various post process processes, and a rendering process.
  • the rendering unit 394 is configured.
  • FIG. 67 is a flowchart for describing generation processing according to the first embodiment.
  • the processing of the first example will be mainly described, but the same applies to the processing of the second to fifth examples.
  • step S11 the data input unit 321 inputs image data and audio data.
  • step S12 the encoder 322 encodes image data and audio data. In the following, image data processing will be mainly described.
  • step S13 the determination unit 351 of the file generation unit 323 determines whether post-decoding after decoding is necessary. If post-decoding after decoding is necessary, in step S14, the storage unit 352 of the file generation unit 323 generates rinf and stores necessary information therein.
  • step S15 the determination unit 351 determines whether to signal TileRegionGroupEntry.
  • step S16 the generation unit 354 of the file generation unit 323 generates TileRegionGroupEntry.
  • step S17 the determination unit 351 determines whether it is necessary to refer to the information of rinf at the time of decoding with TileRegionGroupEntry.
  • the generation unit 354 generates related information for associating the information of rinf.
  • the adding unit 353 adds related information to the TileRegionGroupEntry.
  • the generation unit 354 After the addition processing in step S19 is performed, the generation unit 354 performs processing for generating ISOBMFF in step S20. That is, MP4 file is generated.
  • step S13 If it is determined in step S13 that post-decoding after decoding is not necessary, and if it is determined in step S15 that TileRegionGroupEntry is not signaled, the process of step S20 is performed. Also, if it is determined in step S17 that TileRegionGroupEntry does not need to refer to rinf information during decoding, the process of step S20 is performed.
  • the restricted_scheme_info_dependent_flag described with reference to FIGS. 25 to 28 in the second and third examples is also included.
  • information on whether or not the Tile region described with reference to FIGS. 29 and 30 is stereoscopic and region information in the spherical coordinate system of the Tile region are added.
  • information on the spherical area, stereo pack method, grouping_type_parameter, and the like described with reference to FIGS. 32 to 34 in the fifth example are added.
  • FIG. 68 is a flowchart for describing the reproduction processing according to the first embodiment.
  • the processing of the first example will be mainly described in correspondence with the processing of FIG. 67, but the same applies to the processing of the second to fifth examples.
  • step S31 the analysis unit 373 of the file analysis unit 331 analyzes ISOBMFF (MP4 file).
  • the determination unit 371 determines whether TileRegionGroupEntry exists. If TileRegionGroupEntry exists, in step S32, the determination unit 371 determines whether to decode a part of the picture.
  • the selection unit 372 refers to TileRegionGroupEntry and selects related information.
  • step S34 the selection unit 372 selects an appropriate tile region as a decoding target based on the related information. That is, the selection unit 372 functions as a processing unit that performs processing based on the selected related information. If there is associated rinf information, the selection unit 372 executes processing for selecting an appropriate tile region as a decoding target. Thereby, based on the information added in step S19 of FIG. 67, an appropriate tile region is selected as a decoding target.
  • step S31 If it is determined in step S31 that the TileRegionGroupEntry does not exist, or if it is determined in step S32 that a part of the picture is not to be decoded, the selection unit 372 selects the entire picture as a decoding target in step S35.
  • step S36 the decoder 332 decodes and outputs the data.
  • step S37 the display unit 333 displays a picture corresponding to the data.
  • FIG. 69 is a flowchart for describing generation processing according to the second embodiment.
  • the processing of the first example will be mainly described, but the same applies to the processing of the second to fourth examples.
  • step S51 the data input unit 321 inputs image data and audio data.
  • step S52 the encoder 322 encodes image data and audio data. In the following, image data processing will be mainly described.
  • step S53 the determination unit 351 of the file generation unit 323 determines whether post-process information after decoding is necessary. If post-decoding information after decoding is necessary, the determination unit 351 determines in step S54 whether a plurality of post-processing information is necessary.
  • step S55 the storage unit 352 stores a plurality of Boxes having post process information in rinf / schi.
  • the storage unit 352 functions as a generation unit that generates dependency information representing dependency relationships when processing a plurality of pieces of information necessary for rendering under rinf, and in the next step S56, processing to be added to a plurality of Boxes Generate order information.
  • step S56 the adding unit 353 adds processing order information to a plurality of Boxes.
  • step S54 If it is determined in step S54 that a plurality of post process information is not necessary, the storage unit 352 stores a box having post process information in rinf / schi in step S57.
  • step S58 After the addition process in step S56 or the storage process in step S57, the generation unit 354 generates ISOBMFF in step S58. That is, MP4 file is generated. Even when it is determined in step S53 that post-decoding information after decoding is not necessary, the process of step S58 is executed.
  • FIG. 70 is a flowchart for explaining the reproduction processing according to the second embodiment.
  • the processing of the first example will be mainly described, but the same applies to the processing of the second to fourth examples.
  • step S81 the analysis unit 373 of the file analysis unit 331 analyzes the file supplied from the image generation device 311. That is, ISOBMFF (MP4 file) is analyzed.
  • step S82 the decoder 332 decodes the data obtained by the analysis.
  • step S83 the determination unit 392 of the display unit 333 determines whether post-process information after decoding exists. If post-decoding information after decoding exists, the determination unit 392 determines in step S84 whether a plurality of post-processing information exists. When there are a plurality of post process information, as described above, a plurality of Boxes having post process information are stored in rinf / schi in the process of step S55 of FIG. 69, and processing order information is added. Therefore, in this case, in step S85, the post processing unit 393 performs the post process on the decoded picture in accordance with the processing order information of the post process information.
  • step S84 When post-decoding information after decoding exists but there are not a plurality of post-processing information, as described above, a box having post-processing information is stored in rinf / schi in the process of step S57 of FIG. Therefore, when it is determined in step S84 that a plurality of post-process information does not exist, the post-processing unit 393 performs post-processing on the decoded picture in step S86.
  • step S85 or step S86 the rendering unit 394 executes a process for rendering a picture in step S87. If it is determined in step S83 that post-decoding information after decoding does not exist, post-processing processing is not necessary. Therefore, the processing in step S87 is executed without executing the processing in steps S85 and S86.
  • step S83 and step S84 is executed after decoding of the data. However, it may be executed before decoding.
  • the image playback device can know the processing order and Rendering can be done. In this way, the information of rinf can be easily used and the image can be easily reproduced.
  • FIG. 71 is a block diagram illustrating a configuration example of computer hardware.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 905 is further connected to the bus 904.
  • An input unit 906, an output unit 907, a storage unit 908, a communication unit 909, and a drive 910 are connected to the input / output interface 905.
  • the input unit 906 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 907 includes a display, a speaker, and the like.
  • the storage unit 908 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 909 includes a network interface or the like.
  • the drive 910 drives a removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 901 loads the program stored in the storage unit 908 to the RAM 903 via the input / output interface 905 and the bus 904 and executes the program. A series of processing is performed.
  • the program executed by the computer 900 can be provided by being recorded on a removable medium 911 as a package medium, for example.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 908 via the input / output interface 905 by attaching the removable medium 911 to the drive 910.
  • the program can be received by the communication unit 909 via a wired or wireless transmission medium and installed in the storage unit 908.
  • the program can be installed in the ROM 902 or the storage unit 908 in advance.
  • the program executed by the computer 900 may be a program that is processed in time series in the order described in this specification, or a necessary timing such as when a call is made in parallel. It may be a program in which processing is performed.
  • the system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all the components are in the same housing. Accordingly, a plurality of devices housed in separate housings and connected via a network and a single device housing a plurality of modules in one housing are all systems. .
  • the present technology can be configured as follows. (1) a generation unit for generating related information for associating information to be referred to in rinf with Sample Group; An image generating apparatus comprising: an adding unit that adds the related information to the Sample Group. (2) The image generation apparatus according to (1), wherein the related information is information indicating presence / absence of information to be referred to by the rinf. (3) The image generation apparatus according to (1) or (2), wherein the related information is described in TileRegionGroupEntry, SampleGroupDescriptionEntry, or SampleGroupDescriptionBox. (4) The image generation device according to any one of (1) to (3), wherein information to be referred to by the rinf is added to the box other than the rinf as the related information.
  • the image generation apparatus according to any one of (1) to (4), wherein the boxes other than the rinf are a plurality of boxes identified by different grouping_types.
  • the generation unit generates dependency information representing a dependency relationship when processing a plurality of pieces of information necessary for rendering under the rinf,
  • the image generation apparatus according to any one of (1) to (5), wherein the adding unit adds the dependency information to a box under the rinf.
  • the image generation apparatus according to any one of (1) to (6), wherein the dependency information is a processing order.
  • the image generation device according to any one of (1) to (7), wherein the plurality of pieces of information are information of different boxes under schi.
  • the image generation apparatus according to any one of (1) to (8), wherein the dependency information is described in a box under the rinf that is different from the plurality of pieces of information.
  • the dependence information is described in the schi or schm.
  • the image generation device according to any one of (1) to (9).
  • the dependency information is described as a box in scheme specific data.
  • the image generation device according to any one of (1) to (10).
  • (14) a selection step for selecting related information for associating information to be referenced in rinf with Sample Group; And a processing step of performing processing based on the selected related information.
  • Image processing system 311 image generation device, 312 image playback device, 321 data input unit, 322 encoder, 323 file generation unit, 331 file analysis unit, 332 decoder, 333 display unit, 351 determination unit, 352 storage unit, 353 addition Part, 354 generation part, 371 determination part, 372 selection part, 373 analysis part, 391 selection part, 392 determination part, 393 post-process part, 394 rendering part

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本技術は、容易に画像を再生することができるようにする画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法に関する。 画像生成装置は生成部と付加部とで構成される。生成部により、rinfの参照すべき情報をSample Groupに関連づけるための関連情報が生成される。付加部により、関連情報がSample Groupに付加される。関連情報により、rinfの参照すべき情報がSample Groupに関連づけられるため、rinfの参照すべき情報の参照が容易となる。本技術は、画像を生成し、再生する画像処理システムに適用することができる。

Description

画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法
　本技術は、画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法に関し、特にrinfの情報を利用し易くし、容易に画像を再生することができるようにした画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法に関する。
　ISOBMFF (ISO14496-12) （International Organization for standardization/ Base Media File Format）（非特許文献１）には、リストゥリクテッドスキームインフォメーションボックス（Restricted Scheme Information Box ）(rinf)が規定されている。ここに、サンプル（sample）をデコードした後、ピクチャ全体のレンダリング等のポストプロセスに必要な情報 (ステレオパッキング情報など) が格納される。
　図１は、MP4の構成を示す図である。図１に示されるように、MP4は、入れ子状のボックス(box)により構成されている。図１において右下に配置されているboxは、左上に配置されているbox内に配置される。同じ列に配置されているboxは、並列に配置される。
　図１に示されるように、MP4には、ftyp(File Type Box),moov(Movie Box),moof(Movie Fragment Box),mdat(Media Data)の各boxが並列に配置される。
　moovにはtrak(Track Box)が、trakにはmdia(Media Box)が、mdiaにはminf(Media Information Box)が、minfにはstbl(Sample Table Box)が、それぞれ配置される。stblにはstsd(Sample Discription Box)、sbgp(SampleToGroupBox)、およびsgpd(SampleGroupDescriptionBox)が、配置される。sbgpでは、SampleとGroupの紐づけが行われる。sgpdは、各Group情報のエントリを持つ。
　stsdにはresv(Sample Entry) が配置され、resvにはhvcC(HEVC configuration Box)とrinf(Restricted Scheme Information Box)が配置される。rinfには、デコード後のポストプロセス（レンダリング等）で用いられる情報、すなわちデコード前には知らなくてもよい情報が格納される。
　rinfには、schm(Scheme Type Box)とschi(Scheme Information Box)が配置される。schiには、Scheme Type Boxで指定されたタイプに応じた情報が格納される。
　moofには、traf(Track Fragment Box)が配置され、trafには、sbgpとsgpdが配置される。
　図２は、rinfに存在する情報の例を示す図である。図１を参照して説明したように、rinfには、schmとschiが配置される。そしてschiには、図２に示されるように、povd(ProjectedOmnidirectionalVideoBox),fovd(FisheyeOmnidirectionalVideoBox),rwpk(RegionWisePackingBox),stvi(StereoVideoBox)が配置される。
　schmのscheme_typeがodvdのとき、povdとfovdのどちらか一方が必須である。fovdにはFisheye用メタデータが格納される。rwpkには、region-wise packingのための、projected frameとpacked frame領域の変換テーブルが格納される。stviは、ステレオビデオであること、およびそのステレオアレンジタイプ（top-bottom,side-to-side等）を示す。rwpk,stviは、povdがあるとき任意である。
　povdにはprfr(ProjectionFormatBox),pror(ProjectionOrientationBox),covi(CoverageInformationBox)が配置される。prfrはprojection formatとgeometry typeを示す。prfrは必須である。prorは、projectionの方向を示す。prorは任意である。coviはコンテンツのカバレッジ情報を示す。coviが存在しないことは、その領域が360度全体をカバーすることを意味する。coviは任意である。
　図３は、prfrの構成例を示す図であり、図４は、prfrのフィールドを説明する図である。図３に示されるように、prfrには、geometry_typeとprojection_typeが記述される。図４に示されるように、geometry_typeは、用いる座標系を示し、その値１は、球座標系であることを意味する。projection_typeは、プロジェクションフォーマットを示し、その値１は、正距円筒プロジェクションであることを意味する。
　図５は、coviの構成例を示す図であり、図６は、coviのフィールドを説明する図である。図５に示されるように、coviには、カバレッジ情報として、center_yaw,center_pitch.hor_range,ver_rangeが記述される。図６に示されるように、center_yawは、領域中心のyaw角を表し、center_pitchは、領域中心のpitch角を表し、hor_rangeは、領域の水平方向角度レンジを表し、ver_rangeは、領域の垂直方向角度レンジを表す。
　また、ISOBMFFのサンプルテーブル（sample table）のコ－デック（codec）情報、アクセス情報等の基本的な情報以外の情報をsampleに紐づける汎用的な仕組みとしてサンプルグループ（SampleGroup）が規定されている。その中の一つとして、タイルリージョングループ（TileRegionGroup）がある。これは、ISO/IEC（International Organization for standardization/ International electrotechnical Commission） 14496-15で規定されている、1つもしくは複数のHEVC(High Efficiency Video Coding) tileをまとめたtile regionを示すSample Groupである。TileRegionGroupのエントリがTileRegionGroupEntry(trif)である。
　TileRegionGroupを用いることで、ピクチャの一部(タイル)を単独でデコードすることができる。
　図７は、Sample Groupの例を示す図である。図７に示される例においては、stbl（またはtraf）に、sgpdとsbgpが配置されている。sgpdには、grouping_typeが‘XXXX’、entry_count(entryの数)が４と記述され、GroupEntryとして、GroupEntry()[1]乃至GroupEntry()[4]が記述されている。
　sbgpには、grouping_typeが‘XXXX’、grouping_type_parameterが‘YYYY’、entry_count(entryの数)が6と記述されている。sbgpのgrouping_type=‘XXXX’は、sgpdのgrouping_type=‘XXXX’に対応している。
　さらにsample の数を表すsample_count[1]が1で、GroupEntry を指すgroup_description_index[1]が1と記述されている。sample_count[1]がmdatのSampleのうちの最初の１つのSample[1]に対応している。そして、sample_count[1]=1とgroup_description_index[1]=1の記述が、sgpdのGroupEntry()[1]に対応している。
　以下同様に、sbgpのsample_count[2]=2，group_description_index[2]=3が、sgpdのGroupEntry()[3]に対応している。sample_count[2]=2は、mdatのsample[1]の次の２つのsampleであるsample[2]とsample[3]に対応している。sbgpのsample_count[3]=１、group_description_index[3]=2が、sgpdのGroupEntry()[2]に対応している。sample_count[3]=１は、mdatのsample[3]の次の１つのsampleであるsample[4]に対応している。
　sbgpのsample_count[4]=1,group_description_index[4]=0は、‘XXXX’ GroupのどのGroupにも対応していない。sample_count[4]=１は、mdatのsample[4]の次の１つのsampleであるsample[5]に対応している。
　sbgpのsample_count[5]=1．group_description_index[5]=4が、sgpdのGroupEntry()[4]に対応している。sample_count[5]=１は、mdatのsample[5]の次の１つのsampleであるsample[6]に対応している。sbgpのsample_count[6]=2，group_description_index[6]=1が、sgpdのGroupEntry()[1]に対応している。sample_count[6]=2は、mdatのsample[6]の次の２つのsampleであるsample[7],sample[8]に対応している。
　図８は、TileRegionGroupEntryの構成例を示す図であり、grouping_type=‘trif’ のSampleGroupDescriptionBoxにおける、GroupEntry()を表す。図９は、１つのピクチャのtile regionの配置の例を表す図である。図９の例では、ピクチャが、tile region 1, tile region 1の左下のtile region 2、およびtile region 1の右下のtile region 3の３つのtileに区分されている。tile region 1乃至tile region 3には、それぞれgroupID=1乃至groupID=3が対応付けられている。従って、図８のTileRegionGroupEntryにおいて、そのgroupIDとして例えばgroupID=1と記述することで、tile region 1のhorizonntal_offset,vertical_offset,region_width,region_height等の配置情報を記述することができる。同様にgroupIDを変更することで、tile region 2やtile region 3の配置情報を記述することができる。
　MPEGでは、rinfとSampleGroupの技術を組み合わせ、全天球映像の視点適応再生処理（viewport dependent processing）を行う方法が議論されている。
ISO/IEC 14496-12 Information technology - Coding of audio-visual objects － P art12: ISO base media file format
　ところで、rinf下の情報は、レンダリングする際に必要な情報ではあるが、例えばピクチャの一部のタイルを単独でデコードする場合において、どのタイルをデコードすべきかの判定基準としても使用できる場合がある。
　しかしながら、タイルデコード時に参照してほしい情報がrinfに存在しているか否かを明示する方法がなく、rinf下の情報をデコード時に使用するか否かはクライアント（画像再生装置）に依存する。
　すなわち、デコード時にrinfを常に参照しない画像再生装置においては、参照すべき情報があっても参照しないため、適切なデコード処理が行われない。また、デコード時にrinfを常に参照する画像再生装置においては、参照すべき情報が無い場合でも、常にrinfを参照しにいくため、処理が非効率的になる。
　またrinf下に、レンダリングする際に必要な情報が複数存在する場合に、それぞれの情報の依存関係を示す方法がない。そのため、画像再生装置は処理順を知ることができず、適切なレンダリング処理ができない。
　このように、rinfに格納されている情報を利用するに当たっては、不便な点があった。そこで、rinfに格納されている情報を容易に利用できるようにし、画像を容易に再生できるようにすることが望まれている。
　本技術はこのような状況に鑑みてなされたものであり、容易に画像を再生することができるようにするものである。
　本技術の一側面は、rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成部と、前記関連情報を前記Sample Groupに付加する付加部とを備える画像生成装置である。
　前記関連情報は、前記rinfの参照すべき情報の有無を表す情報であることができる。
　前記関連情報は、TileRegionGroupEntry, SampleGroupDescriptionEntryまたはSampleGroupDescriptionBoxに記述されることができる。
　前記関連情報として、前記rinfの参照すべき情報が、前記rinf以外のboxに付加されることができる。
　前記rinf以外のboxは、異なるgrouping_typeで識別される複数のboxであることができる。
　前記生成部は、前記rinf下のレンダリングする際に必要な複数の情報の処理時の依存関係を表す依存情報を生成し、前記付加部は、前記依存情報を前記rinf下のboxに付加することができる。
　前記依存情報は、処理の順番であることができる。
　前記複数の情報は、schi下の異なるboxの情報であることができる。
　前記依存情報は、前記rinf下の、前記複数の情報とは異なるboxに記述されることができる。
　前記依存情報は、前記schiまたはschmに記述されることができる。
　前記依存情報は、scheme specific dataにboxとして記述されることができる。
　本技術の一側面は、rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成ステップと、前記関連情報を前記Sample Groupに付加する付加ステップとを含む画像生成方法である。
　本技術の一側面は、rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択部と、選択された前記関連情報に基づく処理を行う処理部とを備える画像再生装置である。
　本技術の一側面は、rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択ステップと、選択された前記関連情報に基づく処理を行う処理ステップとを含む画像再生方法である。
　本技術の一側面においては、rinfの参照すべき情報をSample Groupに関連づけるための関連情報が生成され、関連情報がSample Groupに付加される。
　また、本技術の一側面においては、rinfの参照すべき情報をSample Groupに関連づけるための関連情報が選択され、選択された関連情報に基づく処理が行なわれる。
　以上のように、本技術の一側面によれば、rinfの情報を利用し易くし、容易に画像を再生することができる。
　なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また付加的な効果があってもよい。
MP4の構成を示す図である。 rinfに存在する情報の例を示す図である。 prfrの構成例を示す図である。 prfrのフィールドを説明する図である。 coviの構成例を示す図である。 coviのフィールドを説明する図である。 Sample Groupの例を示す図である。 TileRegionGroupEntryの構成例を示す図である。 １つのピクチャのtile regionの配置の例を表す図である。 TileRegionGroupEntryの構成例を示す図である。 TileRegionGroupEntryのフィールドを説明する図である。 restricted_scheme_info_dependent_flagを説明する図である。 ISOBMFFに格納されるビデオの構成を表す図である。 povd,rwpkの記述を説明する図である。 povdの構成例を示す図である。 rwpkの構成例を示す図である。 rwpkのフィールドを説明する図である。 ISOBMFFに格納されるビデオの構成を表す図である。 povd,rwpk,stviの記述を説明する図である。 stviの構成例を示す図である。 stviのフィールドを説明する図である。 povd,rwpk,stviの記述を説明する図である。 ISOBMFFに格納されるビデオの構成を表す図である。 povd,rwpk,stviの記述を説明する図である。 SampleGroupDescriptionEntryの構成例を示す図である。 VisualSampleGroupEntryの構成例を示す図である。 SampleGroupDescriptionBoxの構成例を示す図である。 SampleGroupDescriptionBoxのフィールドを説明する図である。 TileRegionGroupEntry()の構成例を示す図である。 TileRegionGroupEntry()のフィールドを説明する図である。 領域形状を説明する図である。 RegionOnSphereGroupEntry()の構成例を示す図である。 StereoPackedGroupEntry()の構成例を示す図である。 SampleToGroupBoxの構成例を示す図である。 TileRegionGroupの運用を説明する図である。 SampleToGroupBox を拡張した場合のTileRegionGroupの運用を説明する図である。 ファイルとトラックの構成例を示す図である。 MPDファイルの構成例を示す図である。 MPDファイルの構成例を示す図である。 MPDファイルの構成例を示す図である。 valueを説明する図である。 valueの要素を説明する図である。 RegionWisePackingBoxの構成例を示す図である。 RegionWisePackingStructの構成例を示す図である。 RegionWisePackingStructのフィールドを説明する図である。 RectRegionPackingの構成例を示す図である。 RegionWisePackingStructの構成例を示す図である。 packing_typeを説明する図である。 TileRegionPacking(i)の構成例を示す図である。 TileRegionPacking()の構成例を示す図である。 stereo_packed_regionを説明する図である。 rinfに存在する情報の例を示す図である。 SchemeInformationPriorityBoxの構成例を示す図である。 SchemeInformationPriorityBoxのフィールドを説明する図である。 schpの構成例を示す図である。 処理手順を示す図である。 SchemeInformationBoxの構成例を示す図である。 SchemeInformationPriorityBoxの構成例を示す図である。 priorityを説明する図である。 StereoVideoBoxの構成例を示す図である。 SchemeTypeBoxの構成例を示す図である。 priority_flagを説明する図である。 画像処理システムの構成を示すブロック図である。 ファイル生成部の構成を示すブロック図である。 ファイル解析部の構成を示すブロック図である。 表示部の構成を示すブロック図である。 第１の実施の形態の生成処理を説明するフローチャートである。 第１の実施の形態の再生処理を説明するフローチャートである。 第２の実施の形態の生成処理を説明するフローチャートである。 第２の実施の形態の再生処理を説明するフローチャートである。 コンピュータのハードウエアの構成例を示すブロック図である。
　以下、本技術を実施するための実施の形態について説明する。なお、説明は以下の順序で行う。
　１．第１の実施の形態：Sample Groupに対する紐付け（図１０乃至図５１）
　　（１－１）第１の例（図１０乃至図２４）
　　（１－２）第２の例（図２５、図２６）
　　（１－３）第３の例（図２７、図２８）
　　（１－４）第４の例（図２９乃至図３１）
　　（１－５）第５の例（図３２乃至図４２）
　　（１－６）第６の例（図４３乃至図５１）
　２．第２の実施の形態：依存関係情報の付加（図５２乃至図６２）
　　（２－１）第１の例（図５２乃至図５６）
　　（２－２）第２の例（図５７）
　　（２－３）第３の例（図５８乃至図６０）
　　（２－４）第４の例（図６１、図６２）
　３．生成処理と再生処理（図６３乃至図７０）
　　（３－１）画像処理システム（図６３乃至図６６）
　　（３－２）第１の実施の形態の生成処理（図６７）
　　（３－３）第１の実施の形態の再生処理（図６８）
　　（３－４）第２の実施の形態の生成処理（図６９）
　　（３－５）第２の実施の形態の再生処理（図７０）
　４．コンピュータ（図７１）
　５．その他
　＜第１の実施の形態＞
　　（Sample Groupに対する紐付け（図１０乃至図５１））
（１－１）第１の例（図１０乃至図２４）
　第１の例においては、図１０に示されるように、TileRegionGroupEntryが拡張される。図１０は、TileRegionGroupEntryの構成例を示す図であり、図１１は、TileRegionGroupEntryのフィールドを説明する図である。
　図１０に示されるように、このTileRegionGroupEntryには、GroupID,tile_region_flagが記述される。GroupIDは、tile region groupのユニークな識別子である。tile_region_flagは、tile region groupに紐づけられているNAL unitsがtile regionであるかを表すフラグである。その値０は、このtile region groupに紐づけられているNAL unitsはtile regionではないことを示す。その値１は、このtile region groupに紐づけられているNAL unitsはtile regionであることを示す。
　tile_region_flagが１である場合（!tile_region_flagではない場合）、independent_idc,full_picture,filtering_disabled,has_dependency_listが記述される。
　independent_idcは、tile regionの、他のtile regionまたはピクチャに対するdependency（依存性）を示す。その値０は、このtile region groupに属するtile regionが、同じピクチャ、もしくは同じレイヤの参照ピクチャのtile regionに対してcoding dependencyがあることを示す。その値１は、tile region groupに属するtile regionが、異なるgroupIDのtile regionに対し、temporal dependencyがないことを示す。その値２は、このtile region groupに属するtile regionが、同じレイヤの参照ピクチャに対してcoding dependencyがないことを示す。
　full_pictureは、tile regionとピクチャ全体との関係を表し、その値１は、このtile region groupに属するtile regionは、ピクチャ全体であることを示す。filtering_disabledは、in-loopフィルタリングを行う際に、となりのtile regionのピクセル取得が必要であるかを表す。その値１は、このtile region groupに属するtile regionは、in-loopフィルタリングを行う際に、となりのtile regionのピクセル取得が必要ないことを示す。has_dependency_listは、dpendency_tile_countの存在を表し、その値０は、dpendency_tile_countが存在しないことを示す。その値１は、dpendency_tile_countが存在することを示す。
　さらに、regionwidth,region_heightが記述される。regionwidthは、このtile region groupでカバーする矩形領域の幅を示す。region_heightは、このtile region groupでカバーする矩形領域の高さを示す。
　full_pictureが１ではない場合（!full_pictureである場合）、horizontal_offset,vertical_offsetが記述される。horizontal_offsetは、このtile region groupでカバーする矩形領域の水平方向の位置を、矩形領域の左上ピクセルの水平方向オフセットで示す。vertical_offsetは、このtile region groupでカバーする矩形領域の垂直方向の位置を、矩形領域の左上ピクセルの垂直方向オフセットで示す。
　さらに、has_dependency_listの値が１である場合、dependency_tile_count,dependencyTileGroupIDが記述される。dependency_tile_countは、このtile region groupがdependencyを持つtile regionの数を示す。dependencyTileGroupIDは、このtile region groupがdependencyを持つtile regionのGroupIDを示す。
　以上のフィールドは、図８における場合と同様であるが、本技術においては、以上の他に、restricted_scheme_info_dependent_flagが記述される。図１２は、restricted_scheme_info_dependent_flagを説明する図である。restricted_scheme_info_dependent_flagは、rinfの参照すべき情報の存在に関するフラグである。その値０は、このSampleGroupEntryをデコードする上で、rinfに参照すべき情報が存在しないことを示し、その値１は、このSampleGroupEntryをデコードする上で、rinfに参照すべき情報が存在することを示す。
　なお、TileRegionGroupEntryに替えて、他のSampleGroupEntryを拡張し、そこにフラグrestricted_scheme_info_dependent_flagを記述するようにすることもできる。
　次に、図１３と図１４を参照して、第１の例の第１の効果について説明する。図１３は、ISOBMFFに格納されるビデオの構成を表す図であり、図１４は、povd,rwpkの記述を説明する図である。
　図１３には、ISOBMFFに格納されるビデオのregion wise packingされたpacked frame１１が示されている。このpacked frame１１は、６個のtile regionに区分されているが、rinfの情報を参照しないと、各tile regionが何を示すのかが不明である。しかしながら、rinfの下のschiのさらに下のpovd,rwpk（図２）を参照することで、図１４に示されるように、projected frame２１をregion wise packingしてpacked frame２２が生成されていることが判る。projected frame２１は、全天球画像をキューブマッピングプロジェクションすることで生成されたものである。
　projected frame２１においては、中央の行に左から順番に、left,front,right,backの各tileが配置され、frontの上にtopのtileが、下にbottomのtileが、それぞれ配置されている。packed frame２２においては、左下に、frontのtileが配置され、その上の左側にrightのtileが配置され、その上の右側にbackのtileが配置されている。frontのtileの右側の上にtopのtileが配置され、下にbottomのtileが配置されている。そして、backのtileの右側で、topのtileの上側に、leftのtileが配置されている。right,back,left,top,bottomの各tileは、その水平と垂直方向の長さが、frontの１／２に縮小されている。
　従って、Tile Region Groupのデコード時、povd,rwpkを参照することで、元のprojected frame２１における領域が、packed frame２２におけるどのTile Region Groupであるのかを判別することができる。すなわち、packed frame２２のどの位置のtileがfront,right,back,left,top,bottomのtileであるのかが判る。そこで、例えばfrontのtileをデコードしたい場合、packed frame２２の対応するTile Region２２Ａを判別し、それを単独でデコードすることができる。
　図１５は、povdの構成例を示す図である。図１５に示されるように、povdには、ProjectionFormatBox()、ProjectionOrientationBox()、CoverageInformationBox()が格納される。ProjectionFormatBox()は必須であり、ProjectionOrientationBox()とCoverageInformationBox()は任意である。
　図１６は、rwpkの構成例を示す図であり、図１７は、rwpkのフィールドを説明する図である。rwpkには、num_regions,proj_frame_width,proj_frame_height, packing_type[i]が記述される。num_regionsは、領域数を示す。proj_frame_widthは、プロジェクテッドフレーム(projected frame)の幅を示し、proj_frame_heightは、プロジェクテッドフレームの高さを示す。packing_type[i]は、リージョンワイズパッキングに関する情報を表し、その値０は、矩形領域のリージョンワイズパッキングを示す。
　また、packing_type が値０である場合、RectRegionPacking(i)が記述される。その詳細は、後述する図４６に示されている。
　さらに、proj_reg_width[i],proj_reg_height[i],proj_reg_top[i],proj_reg_left[i],transform_type[i],packed_reg_width[i],packed_reg_height[i], packed_reg_top[i],packed_reg_left[i]が記述される。
　proj_reg_width[i]は、プロジェクテッドフレームの領域幅を示し、proj_reg_height[i]は、プロジェクテッドフレームの領域高さを示す。proj_reg_top[i]は、領域の左上隅ピクセルの、プロジェクテッドフレーム内での垂直方向の位置 (プロジェクテッドフレームの左上を0とする)を示す。proj_reg_left[i]は、領域の左上隅ピクセルの、プロジェクテッドフレーム内での水平方向の位置 (プロジェクテッドフレームの左上を0とする)を示す。
　transform_type[i]は、領域の回転やミラーリングを指定する。その値１は、変換無しを示し、その値２は、水平ミラーリング、その値３は、反時計回りに180°回転、その値４は、水平ミラーリング後、反時計回りに180°回転、をそれぞれ示す。その値５は、水平ミラーリング後、反時計回りに90°回転、その値６は、反時計回りに90°回転、その値７は、水平ミラーリング後、反時計回りに270°回転、その値８は、反時計回りに270°回転、をそれぞれ示す。
　packed_reg_width[i]は、パックドフレームの領域幅を示し、packed_reg_height[i]は、パックドフレームの領域高さを示す。packed_reg_top[i]は、領域の左上隅ピクセルの、パックドフレーム内での垂直方向の位置 (パックドフレームの左上を0とする)を示す。packed_reg_left[i]は、領域の左上隅ピクセルの、パックドフレーム内での水平方向の位置 (パックドフレームの左上を0とする)を示す。
　本技術においては、フラグrestricted_scheme_info_dependent_flagがTileRegionGroupEntryに記述されている。そこで、このフラグに基づいて、rinfにSampleGroupEntryをデコードする上で参照すべき情報が存在するか否かを知ることが可能になる。その結果、rinfの情報が利用し易くなり、画像を容易に効率的に再生する効果を実現することができる。
　次に、図１８乃至図２１を参照して、第１の例の第２の効果について説明する。図１８は、ISOBMFFに格納されるビデオの構成を表す図であり、図１９は、povd,rwpk,stviの記述を説明する図である。
　図１８には、ISOBMFFに格納されるビデオのregion wise packingされたpacked frame４１が示されている。このpacked frame４１は、１２個のtile regionに区分されているが、rinfを参照しないと、各tile regionが何を示すのかが不明である。しかしながら、rinfの下のschiのさらに下のpovd,rwpk,stvi（図２）を参照することで、次のことが判る。すなわち、図１９に示されるように、left viewとright viewのステレオの画像がside-to-sideに配置されたprojected frame５１をregion wise packingすることでpacked frame５２が生成されている。projected frame５１は、全天球画像をキューブマッピングプロジェクションすることで生成されたものである。
　projected frame５１においては、左側にleft viewの画像が、そして、右側にright viewの画像がside-to-sideに配置されている。left viewの画像において、中央の行に左から順番に、left,front,right,backの各tileが配置され、frontの上にtopのtileが、下にbottomのtileが、それぞれ配置されている。同様に、right viewの画像においても、中央の行に左から順番に、left,front,right,backの各tileが配置され、frontの上にtopのtileが、下にbottomのtileが、それぞれ配置されている。各tileにおいては、その水平方向の長さが、垂直方向の長さの１／２とされている。
　packed frame５２においては、左側にleft viewの画像が、そして、右側にright viewの画像がside-to-sideに配置されている。left viewの画像において、左下に、frontのtileが配置され、その上の左側にrightのtileが配置され、その上の右側にbackのtileが配置されている。frontのtileの右側の上にtopのtileが配置され、下にbottomのtileが配置されている。そして、backのtileの右側で、topのtileの上側に、leftのtileが配置されている。
　right viewの画像においても、左下に、frontのtileが配置され、その上の左側にrightのtileが配置され、その上の右側にbackのtileが配置されている。frontのtileの右側の上にtopのtileが配置され、下にbottomのtileが配置されている。そして、backのtileの右側で、topのtileの上側に、leftのtileが配置されている。front以外のtileの水平方向と垂直方向の長さは、frontのtileの１／２とされている。
　従って、Tile Region Groupのデコード時、povd,rwpk,stviを参照することで、元のprojected frame５１における領域が、packed frame５２におけるどのTile Region Groupであるのかを判別することができる。すなわち、packed frame５２のどの位置のtileがleft view またはright viewのfront,right,back,left,top,bottomであるのかが判る。そこで、例えばステレオでfrontのtileをペアでデコードしたい場合、packed frame５２の対応するleft view のTile Region５２Ａと、right viewのTile Region５２Ｂを判別することができる。つまり、ステレオのfrontのtileをペアで単独でデコードすることができる。
　povdとrwpkの構成については、図１５乃至図１７を参照して説明した。そこで、stviの構成について、図２０と図２１を参照して説明する。図２０は、stviの構成例を示す図であり、図２１はstviのフィールドを説明する図である。
　図２０に示されるように、stviには、single_view_allowed,stereo_scheme, length,stereo_indication_typeが記述される。single_view_allowedは、表示の許容に関する情報を表す。その値０は、コンテンツがステレオスコピック対応のディスプレイでのみ表示されることを意図していることを意味する。その値１（(single_view_allowed&1)=1）は、コンテンツはモノスコピックディスプレイでright viewの表示が許されていることを示し、その値２（(single_view_allowed&2)=2）は、コンテンツはモノスコピックディスプレイでleft viewの表示が許されていることを意味する。
　stereo_schemeは、フレームパッキング方法に関する情報を表す。その値１は、フレームパッキング方法は、ISO/IEC 14496-10のFrame packing arrangement SEIに従うことを示し、その値２は、フレームパッキング方法は、ISO/IEC 13818-2のAnnex.Lに従うことを示す。その値３は、フレームパッキング方法は、ISO/IEC 23000-11のframe/sevice compatible および2D/3D Mixed seviceに従うことを示す。
　lengthは、stereo_indication_typeのバイト長を示し、stereo_indication_typeは、stereo_shcemeに従った、フレームパッキング方法を示す。
　本技術においては、フラグrestricted_scheme_info_dependent_flagがTileRegionGroupEntryに記述されている。そこで、このフラグに基づいて、rinfにSampleGroupEntryをデコードする上で参照すべき情報が存在するか否かを知ることが可能になる。その結果、rinfの情報が利用し易くなり、画像を容易に効率的に再生する効果を実現することができる。
　次に、図２２を参照して、第１の例の第３の効果について説明する。図２２は、povd,rwpk,stviの記述を説明する図である。
　図１３に示されるように、ISOBMFFに格納されるビデオのregion wise packingされたpacked frame１１が、６個のtile regionに区分されている場合、rinfを参照しないと、各tile regionが何を示すのかが不明である。しかしながら、rinfの下のschiのさらに下のpovd,rwpk,stvi（図２）を参照することで、次のことが判る。すなわち、図２２に示されるように、left viewとright viewのステレオの画像がside-to-sideに配置されたprojected frame６１をregion wise packingすることでpacked frame６２が生成されている。projected frame６１は、全天球画像をキューブマッピングプロジェクションすることで生成されたものである。
　projected frame６１においては、左側にleft viewの画像が、そして、右側にright viewの画像が配置されている。left viewの画像において、中央の行に左から順番に、left,front,right,backの各tileが配置され、frontの上にtopのtileが、下にbottomのtileが、それぞれ配置されている。同様に、right viewの画像においても、中央の行に左から順番に、left,front,right,backの各tileが配置され、frontの上にtopのtileが、下にbottomのtileが、それぞれ配置されている。各tileにおいては、その水平方向の長さが、垂直方向の長さの１／２とされている。
　packed frame６２においては、左下に、frontのtileが配置され、その上の左側にrightのtileが配置され、その上の右側にbackのtileが配置されている。frontのtileの右側の上にtopのtileが配置され、下にbottomのtileが配置されている。そして、backのtileの右側で、topのtileの上側に、leftのtileが配置されている。すなわち、right,back,left,top,bottomの各tileは、その水平と垂直方向の長さが、frontの１／２に縮小されている。また各tileの内部においては、その左側にleft viewの画像が、右側にright viewの画像が配置されている。
　従って、Tile Region Groupのデコード時、povd,rwpk,stviを参照することで、もとのprojected frame６１における領域が、packed frame６２におけるどのTile Region Groupであるのかを判別することができる。すなわち、packed frame６２のどの位置のtileがfront,right,back,left,top,bottomであるのかが判る。そこで、例えばステレオでfrontのtileをペアでデコードしたい場合、packed frame６２の左下のTile Region６２Ａがfrontのleft viewとright viewで構成されていることが判る。これによりステレオのfrontのtileを単独でデコードすることができる。
　本技術においては、フラグrestricted_scheme_info_dependent_flagがTileRegionGroupEntryに記述されている。そこで、このフラグに基づいて、rinfにSampleGroupEntryをデコードする上で参照すべき情報が存在するか否かを知ることが可能になる。その結果、rinfの情報が利用し易くなり、画像を容易に効率的に再生する効果を実現することができる。
　次に、図２３と図２４を参照して、第１の例の第４の効果について説明する。図２３は、ISOBMFFに格納されるビデオの構成を表す図であり、図２４は、stviの記述を説明する図である。
　図２３に示されるように、ISOBMFFに格納されるビデオのregion wise packingされたpacked frame８１が、２個のtile region８１Ａとtile region８１Ｂに区分されている。この場合、rinfの情報を参照しないと、各tile regionが何を示すのかが不明である。しかしながら、rinfの下のschiのさらに下のstvi（図２）を参照することで、次のことが判る。すなわち、図２４に示されるように、left viewとright viewのステレオの画像がside-to-sideに配置されて、packed frame９１が生成されていることが判る。
　packed frame９１においては、左側にleft viewのtile９１Ａが、右側にright viewのtile９１Ｂが配置されている。
　従って、Tile Region Groupのデコード時、stviを参照することで、各Tile Regionが、left viewとright viewのいずれであるのかを判別することができる。そこで、例えばleft viewをデコードしたい場合、Tile Region ９１Ａがleft viewであることがわかり、それを単独でデコードすることができる。
　本技術においては、フラグrestricted_scheme_info_dependent_flagがTileRegionGroupEntryに記述されている。そこで、このフラグに基づいて、rinfにSampleGroupEntryをデコードする上で参照すべき情報が存在するか否かを知ることが可能になる。その結果、rinfの情報が利用し易くなり、画像を容易に効率的に再生する効果を実現することができる。
（１－２）第２の例（図２５、図２６）
　次に第２の例について説明する。第２の例においては、SampleGroupDescriptionEntryが拡張される。図２５は、SampleGroupDescriptionEntryの構成例を示す図である。図２５に示されるように、このSampleGroupDescriptionEntryはabstract classとされ、そこには、restricted_scheme_info_dependent_flagが記述されている。restricted_scheme_info_dependent_flagの意味は、図１２を参照して説明した通りである。全てのSampleGroupEntryは、このabstract classを承継する。すなわち、全てのSampleGroupEntryは、abstract classが有する機能を有する。従って、全てのSampleGroupEntryは、restricted_scheme_info_dependent_flagを有することになる。
　また、図２６に示されるように、VisualSampleGroupEntryが拡張される。図２６は、VisualSampleGroupEntryの構成例を示す図である。図２６に示されるように、このVisualSampleGroupEntryはabstract classとされ、そこには、restricted_scheme_info_dependent_flagが記述されている。全てのビデオに関わるVisualSampleGroupEntryは、このabstract classを承継して定義される。
　なお、VisualSampleGroupEntryではなく、AudioSampleGroupEntry,Hint SampleGroupEntry,SubtitleSampleGroupEntry,TextSampleGroupEntryに対する拡張を行うこともできる。
（１－３）第３の例（図２７、図２８）
　次に第３の例について説明する。第３の例においては、SampleGroupDescriptionBoxが拡張される。図２７は、SampleGroupDescriptionBoxの構成例を示す図であり、図２８は、SampleGroupDescriptionBoxのフィールドを説明する図である。このSampleGroupDescriptionBoxには、grouping_type, entry_count, SampleGroupEntry (grouping_type)が記述される。grouping_typeは、このsample group descriptionに紐づくSampleToGroupBoxを識別するための識別子である。entry_countは、このフィールドに続くfor ループテーブルのエントリ数を示す。SampleGroupEntry は、SampleGroupのエントリを示す。
　SampleGroupDescriptionBoxのversionが１である場合、default_lengthが記述される。versionは、SampleGroupDescriptionBox のバージョンを示す。default_length は、全てのsample group entryのサイズを示す。その値0はgroup entryのサイズは変化することを示す。versionが２以上である場合、default_sample_description_indexが記述される。default_sample_description_index は、SampleToGroupBoxにより、sample group entryに紐づけられていない全てのsampleが紐づくsample group entryのidを示す。versionが１であり、default_length が０である場合、description_lengthが記述される。description_lengthは、個々のsample group entryのサイズを示す。
　さらに、versionが３以上である場合、restricted_scheme_info_dependent_flagが記述される。図２８に示されるように、restricted_scheme_info_dependent_flagは、rinfの参照すべき情報に関する情報を表す。その値０は、このgrouping_typeのSampleGroupEntryをデコードする上で、rinfに参照すべき情報が存在しないことを示す。その値１は、このgrouping_typeのSampleGroupEntryをデコードする上で、rinfに参照すべき情報が存在することを示す。
　以上のように、第１の例乃至第３の例においては、フラグrestricted_scheme_info_dependent_flagにより、Sample Groupを参照して、sampleの一部分をデコードする際、参照すべき情報がrinfに存在することが明示される。これにより、rinfに格納されている情報のうちの少なくとも一部は、参照すべき情報であることが明示される。その結果、画像再生装置はデコード時にrinfを参照すべきか否かを判別することができ、適切なデコード処理を行うことが容易になる。ただし、Sample Groupの参照のみで処理は完結せず、rinfを参照する必要がある。
　なおSample Groupは、ISOBMFFのsampleをまとめてグループ化し、そのグループに情報を紐づける汎用的な仕組みであり、VisualRollRecoveryEntry, AudioRollRecoveryEntry, VisualRandomAccessEntry等もある。VisualRollRecoveryEntryは、属するビデオサンプルを正しくデコードするために必要なサンプルをシグナルするためのSampleGroupである。AudioRollRecoveryEntryは、属するオーディオサンプルを正しくデコードするために必要なサンプルをシグナルするためのSampleGroupである。VisualRandomAccessEntryは、属するビデオサンプルへのランダムアクセス時に、デコードする上で必要な情報をシグナルするためのSampleGroupである。
（１－４）第４の例（図２９乃至図３１）
　次に第４の例について説明する。この第４の例においては、図２９に示されるように、TileRegionGroupEntryが拡張され、詳細情報が追加される。図２９は、TileRegionGroupEntry()の構成例を示す図であり、図３０は、TileRegionGroupEntry()のフィールドを説明する図である。
　図２９に示されるように、このTileRegionGroupEntry()においては、groupID, tile_region_flagが記述される。またtile_region_flagが１である場合、independent_idc,full_picture,filtering_disabled,has_dependency_list, region_width,region_heightが記述される。full_pictureが１ではない場合（(!full_picture)である場合）、horizontal_offset,vertical_offsetが記述される。has_dependency_listが１である場合、 dependency_tile_count,dependencyTileGroupIDが記述される。
　さらにこのTileRegionGroupEntry()においては、stereo_packed,full_sphereが記述される。stereo_packedは、Tile regionのステレオスコピックに関する情報を表す。その値０は、Tile regionはステレオスコピックではないことを意味し、その値１は、Tile regionはステレオスコピックであることを示す。full_sphereは、Tile Regionの360°全天球領域のカバーに関する情報を表す。その値０は、Tile Regionが360°全天球領域をカバーしないことを示し、その値１は、Tile Regionが360°全天球領域をカバーすることを示す。
　また、stereo_packedが１である場合、stereo_indication_typeが記述され、そうでない場合、view_idcが記述される。これらにより、Tile Regionが、ステレオスコピックであるか否かが表される。
　stereo_indication_typeは、ステレオパックのタイプに関する情報を表す。その値３は、Tile regionはside-to-sideでステレオパックされていることを示し、その値４は、Tile regionはtop-bottomでステレオパックされていること示す。view_idcは、viewの種類を表す。その値０は、center view (Tile regionが属するピクチャがモノの場合)を示し、その値１は、left view (Tile regionが属するピクチャがステレオの場合)を示し、その値２は、right view (Tile regionが属するピクチャがステレオの場合)を示す。
　さらにfull_sphereが１ではない場合(（!full_sphere）である場合)、shape_type, center_yaw,center_pitch,hor_range,ver_rangeが記述される。これらは、Tile Regionの球座標系における領域情報である。
　shape_typeは、領域形状に関する情報を表す。その値０は、four great circlesで囲まれる領域形状を意味し、その値１は、two small, two grate circlesで囲まれる領域形状を意味する。
　図３１は、領域形状を説明する図である。great circle は、図３１のＡに示されるように、その中心が球の中心と一致する円Ｃ１を意味し、例えば地球儀の経度線に相当する。従って、four great circlesで囲まれる領域形状とは、４つの円Ｃ１（great circles）により囲まれる領域である。
　small circleは、図３１のＢに示されるように、great circle以外の円Ｃ２を意味し、地球儀の緯度線に相当する。従って、two small, two grate circlesで囲まれる領域形状とは、図３１のＢに示されるように、２つの円Ｃ１（grate circles）と２つの円Ｃ２（small circles）により囲まれる領域である。
　center_yawは、領域中心のyaw角を示し、center_pitchは領域中心のpitch角を示し、hor_rangeは、領域の水平方向角度レンジを示し、ver_rangeは、領域の垂直方向角度レンジを示す。
　この例では、Tile Regionがステレオスコピックであるか否か、領域情報等の詳細情報が、TileRegionGroupEntry()に記述されるため、デコード時にrinfを参照する必要がなくなる。つまり、rinfに格納されている情報のうち、参照すべき情報がrinfの外に格納されているため、さらに二重にrinfを参照する必要がなくなる。すなわち、rinfの情報が利用し易くなっている。その結果、効率的な処理が可能となり、容易に画像を再生することができる。
　なお、球面上領域シグナルの代わりに、projected frame上の領域を、二次元座標系で表現してもよい。また、プロジェクションフォーマットをシグナルしてもよい。
　Tile Regionがステレオスコピックであるか否か、領域情報等の詳細情報は、rinfに格納されている情報のうちの一部の参照すべき情報である。これらの詳細情報は、図２５乃至図２７のrestricted_scheme_info_dependent_flagに替え、その位置に記述するようにしてもよい。
（１－５）第５の例（図３２乃至図４２）
　次に第５の例について説明する。第４の例においては、詳細情報が１つのGroupEntryに追加されたが、第５の例においては、詳細情報が複数のGroupEntryに追加される。
　第５の例においては、新たなSampleGroupEntryとして、RegionOnSphereGroupEntry()とStereoPackedGroupEntry()が定義される。そして、RegionOnSphereGroupEntry()とStereoPackedGroupEntry()をTileRegionGroupEntryに関連づけるため、SampleToGroupBoxが拡張される。
　図３２は、RegionOnSphereGroupEntry()の構成例を示す図であり、図３３は、StereoPackedGroupEntry()の構成例を示す図であり、図３４は、SampleToGroupBoxの構成例を示す図である。
　図３２に示されるように、RegionOnSphereGroupEntry()には、groupID, full_sphereが記述される。さらに、full_sphereが１でなければ（(!full_sphere)であれば）、shape_type, center_yaw, center_pitch, hor_range, ver_rangeが記述される。すなわち球面上領域の情報が記述される。
　図３３に示されるように、StereoPackedGroupEntry()には、groupID, stereo_packedが記述され、stereo_packedが１であれば、stereo_indication_typeが記述され、そうでなければ（stereo_packedが０であれば）、view_idcが記述される。すなわちステレオパック方法が記述される。
　これらの球面上領域の情報やステレオパック方法は、rinfに格納されている情報のうちの一部の参照すべき情報である。
　なお、図３２と図３３に示されるRegionOnSphereGroupEntry()とStereoPackedGroupEntry()は、VisualSampleGroupEntryではなく、SampleGroupDescriptionEntry, AudioSampleGroupEntry, HintSampleGroupEntry, SubtitleSampleGroupEntry, TextSampleGroupEntryに対して拡張してもよい。
　図３４に示されるように、SampleToGroupBoxには、grouping_type, entry_count, sample_count,group_description_indexが記述される他、SampleToGroupBox のversionが１である場合、grouping_type_parameterが記述される。さらに第５の例においては、SampleToGroupBox のversionが２以上である場合、number_of_parameterが記述され、その数だけgrouping_type_parameterが記述される。
　ここで比較のため、既に知られているTileRegionGroupの運用について、図３５を参照して説明する。図３５は、TileRegionGroupの運用を説明する図である。図中右上に示されるSampleGroupDescriptionBox (sgpd)においては、grouping_type=“nalm”(NALUMapEntry)とされ、entry_count=1とされている。NALUMapEntry()[1]においては、NALU[0]にgroupID=1が、NALU[1]にgroupID=2が、それぞれ割り当てられている。
　SampleToGroupBox (sbgp)においては、grouping_type=“nalm”、grouping_type_parameter=“trif”、entry_count=1、sample_count[1]=4、group_description_index[1]=1と記述されている。sample_count[1]=4は、mdatのsample[1]乃至sample[4]に対応している。sample_count[1]=4とgroup_description_index[1]=1は、上述したSampleGroupDescriptionBox (sgpd)のNALUMapEntry()[1]に対応している。
　画像１０１は、tile region 1とtile region 2で構成されている。図中左側に示されるSampleGroupDescriptionBox (sgpd)においては、grouping_type=“trif”,entry_count=2とされている。TileRegionGroupEntry()[1]ではgroupID＝１とされ、TileRegionGroupEntry()[2]ではgroupID＝ 2とされている。groupID＝ 1のTileRegionGroupEntry()[1]がtile region 1に対応し、groupID＝ 2のTileRegionGroupEntry()[2]がtile region 2に対応している。
　groupIDにより、どのTileRegionGroupEntryに属するかが決定される。この例では、groupID=1のNALUはtile region 1を構成し、groupID=2のNALUはtile region 2を構成する。
　次に第５の例における運用について、図３６を参照して説明する。図３６は、SampleToGroupBox を拡張した場合のTileRegionGroupの運用を説明する図である。図中右上に示されるSampleGroupDescriptionBox (sgpd)においては、grouping_type=“nalm”,entry_count=1とされ、NALUMapEntry()[1]では、NALU[0]にgroupID=1が、NALU[1]にgroupID=2が、それぞれ割り当てられている。
　SampleToGroupBox (sbgp)においては、grouping_type=“nalm”,number_of_parameter=3,grouping_type_parameter=“trif”,grouping_type_parameter=“rosp”,grouping_type_parameter=“spak”,entry_count=1とされている。さらにsample_count[1]=4,group_description_index[1]=1とされている。sample_count[1]=4とgroup_description_index[1]=1は、上述したSampleGroupDescriptionBox (sgpd)の、groupID=1のNALU[0]とgroupID=2 のNALU[1]を有するNALUMapEntry()[1]に対応する。
　図３５の既存の例では、grouping_typeが“trif”であるSampleGroupDescriptionBox (sgpd)が１つだけある。しかし第５の例（図３６）では、図中左側に示されるSampleGroupDescriptionBox (sgpd)には、grouping_typeが“trif　　”,“rosp”,“spak”である３つのSampleGroupDescriptionBox (sgpd)がある。
　grouping_type=“trif”のSampleGroupDescriptionBox (sgpd)では、entry_count=2とされ、groupID＝１のTileRegionGroupEntry()[1]と、groupID＝ 2のTileRegionGroupEntry()[2]とが記述されている。
　grouping_type=“rosp”のSampleGroupDescriptionBox (sgpd)では、entry_count=2とされ、groupID＝１のRegionOnSphereGroupEntry()[1]とgroupID＝ 2のRegionOnSphereGroupEntry()[2]とが記述されている。
　grouping_type=“spak”のSampleGroupDescriptionBox (sgpd)では、entry_count=2とされ、groupID＝１のStereoPackedGroupEntry()[1]とgroupID＝ 2のStereoPackedGroupEntry()[2]とが記述されている。
　tile region 1は、groupID＝１のTileRegionGroupEntry()[1]、groupID＝１のRegionOnSphereGroupEntry()[1]、groupID＝１のStereoPackedGroupEntry()[1]に対応する。また、tile region 2は、groupID＝2のTileRegionGroupEntry()[2]、groupID＝2のRegionOnSphereGroupEntry()[2]、groupID＝2のStereoPackedGroupEntry()[2]に対応する。
　各sampleのNAL UnitにgroupIDが割り当てられ、groupIDにより、いずれのTileRegionGroupEntry()に属するかが決定される。groupIDにより、いずれのRegionOnSphereGroupEntry()に属するかが決定される。groupIDにより、いずれのStereoPackedGroupEntry()に属するかが決定される。
　この例では、groupID=1のNALUは、tile region 1を構成し、groupID=2のNALUはtile region 2を構成し、それぞれのtile regionに、groupIDに従ってRegionOnSphereGroupEntry, StereoPackedGroupEntryの情報が紐づけられる。
　第５の例におけるSampleGroupは、例えば図３７に示されるようなファイル（file）とトラック(track)に格納することができる。図３７は、ファイルとトラックの構成例を示す図である。図３７のＡは、複数（図３７のＡの例では２個）のタイル（tiles）が１fileの１trackに格納される例を表している。この例では、tile region 1とtile region 2が、１つのMP4 fileの１つのtrackにSample Entry(hvc1)として格納されている。
　図３７のＢは、複数（図３７のＢの例では２個）のtilesが１fileの２trackに格納される例を表している。この例では、tile region 1が、１つのMP4 fileの１つのtrackにSample Entry(hvt1)として格納されるとともに、tile region 2が、同じMP4 fileの他の１つのtrackにSample Entry(hvt1)として格納されている。
　図３７のＣは、複数（図３７のＣの例では２個）のtilesが、１fileで１trackの複数のfileに格納される例を表している。この例では、tile region 1が、１つのMP4 fileの１つのtrackにSample Entry(hvt1)として格納されるとともに、tile region 2が、他のMP4 fileのその１つのtrackにSample Entry(hvt1)として格納されている。
　図３７のＡ乃至図３７のＣに示されるMP4 fileは、MPEG-DASHのMPD(Media Presentation Description) fileとして、図３８乃至図４０に示されるように構成される。
　図３８は、MPDファイルの構成例を示す図であり、図３７のＡのケースに対応する。このMPD fileでは、図３８に示されるように、PeriodにAdaptationSet、AdaptationSetにRepresentation,RepresentationにSegmentの各boxが、それぞれ含まれる。AdaptationSetには@codecs=hvc1が記述される。またそのSupplementalProperty にvalue=1,0,0,360,180,0,0,360,180,1が記述されている。このvalueは、カバレッジ情報の具体的な値であり、それぞれsource_id,center_yaw,center_pitch,hor_range,ver_range,total_center_yaw,total_center_pitch,total_hor_range,total_ver_range, spatial_set_idを意味する。その詳細は、図４１と図４２を参照して後述する。１つのtrackを有する１つのMP4fileは、Segmentに格納される。
　図３９は、MPDファイルの構成例を示す図であり、図３７のＢのケースに対応する。この例のMPD fileにおいては、Representationに２つのSubRepresentationが配置され、その一方に、SupplementalProperty のvalue=1,0,0,240,180,0,0,360,180,1が記述され、他方にvalue=1,0,0,120,180,0,0,360,180,1が記述されている。それぞれにおいては、ver_rangeの値が、一方では120、他方では240と、異なっているが、他の値は同じである。
　AdaptationSetには@codecs=hvt1が記述されている。２つのtrackを有する１つのMP4 fileは、Segmentに格納される。
　図４０は、MPDファイルの構成例を示す図であり、図３７のＣのケースに対応する。この例のMPD fileにおいては、Periodに２つのAdaptationSetが配置され、それぞれにRepresentationとSegmentが順次配置されている。一方のAdaptationSetに、@codecs=hvt1が記述されるとともに、SupplementalPropertyのvalue=1,0,0,240,180,0,0,360,180,1が記述されている。そしてその下のSegmentに、１つのMP4 fileに１つのtrackを有する２つのMP4 fileのうちの一方が格納されている。
　他方のAdaptationSetに、@codecs=hvt1が記述されるとともに、SupplementalProperty のvalue=1,0,0,120,180,0,0,360,180,1が記述されている。この場合も、一方のver_rangeの値が240、他方の値が120と、異なっているが、他の値は同じである。その下のSegmentに、１つのMP4 fileに１つのtrackを有する他方のMP4 fileが格納されている。
　図４１は、valueを説明する図であり、図４２は、valueの要素を説明する図である。図４１に示されるように、SupplementalProperty のvalueには、source_id,center_yaw,center_pitch,hor_range,ver_range,total_center_yaw,total_center_pitch,total_hor_range,total_ver_range, spatial_set_idが記述される。source_idは、元コンテンツの識別子を示す。center_yawは、領域中心のyaw角を示す。center_pitchは、領域中心のpitch角を示す。hor_rangeは、領域の水平方向角度レンジを示す。ver_rangeは、領域の垂直方向角度レンジを示す。
　total_center_yawは、spatial_set_idでグルーピングされた領域全体の中心のyaw角を示す。total_center_pitchは、spatial_set_idでグルーピングされた領域全体の中心のpitch角を示す。
　total_hor_rangeは、spatial_set_idでグルーピングされた領域全体の水平方向角度レンジを示す。total_ver_rangeは、spatial_set_idでグルーピングされた領域全体の垂直方向角度レンジを示す。spatial_set_idは、同じ解像度等のグルーピングを示すidを示す。spatial_set_idがあった場合は、total_＊が必須である（＊は、center_yaw,center_pitch,hor_rangeまたはver_rangeを意味する）。
　第５の例においても、第４の例と同様に、rinfに格納されている情報のうち、参照すべき情報がrinfの外に格納されているため、さらに二重にrinfを参照する必要がなくなる。すなわち、rinfの情報が利用し易くなっている。従って、容易に画像を再生することができる。
　第４の例と第５の例では、Tile regionがステレオスコピックか否か、Tile regionの球座標系における領域情報、球面上領域、ステレオパック方法等の詳細情報を記述するようにした。schi下に格納されている情報のうち、記述した方がよい一部の情報（rinfの参照すべき情報）は、少なくともcovi,stviの情報である。pror,rwpkの情報は必ずしも記述しなくてもよい。
　以上のように、Sample Groupに付加される、rinfの参照すべき情報を関連づけるための関連情報として、第１の例乃至第３の例においてはフラグが用いられ、第４の例および第５の例においては詳細情報が用いられる。その結果、rinfの情報を利用し易くなり、容易に画像を再生することが可能になる。
（１－６）第６の例（図４３乃至図５１）
　次に第６の例について説明する。
　次のようなことが考えられる。例えば、TileRegionGroupEntryを参照し、一部の領域をデコードした後、レンダリング時にrinfを参照した際、デコードを完了している領域以外の領域を追加でレンダリングすることである。このような場合、もう一度TileRegionGroupEntryを参照し、所望のregion wise packing領域に相当するtile regionを見つけ、デコード処理を行う必要がある。しかしながら、region wise packing領域に相当するtile regionを見つける処理は困難である。
　そこで第６の例においては、region wise packingの領域情報にTileRegionGroupへの参照を持つように構成される。
　第６の例においては、RegionWisePackingBoxが拡張される。このRegionWisePackingBoxの第１の拡張方法について、図４３乃至図４６を参照して説明する。図４３は、RegionWisePackingBoxの構成例を示す図であり、図４４は、RegionWisePackingStructの構成例を示す図である。図４５は、RegionWisePackingStructのフィールドを説明する図である。図４６は、RectRegionPackingの構成例を示す図である。
　図４３に示されるように、RegionWisePackingBoxはRegionWisePackingStructを承継する。図４４に示されるように、RegionWisePackingStructには、num_regions, proj_frame_width,proj_frame_heightが記述されるとともに、num_regions の数に応じてpacking_type[i]が記述される。またpacking_type[i]が０である場合、RectRegionPacking(i)とtile_region_entry_countが、num_regionsの数に応じて記述される。さらにtile_region_entry_countの数に応じて、tile_region_group_idが記述される。
　図４５に示されるように、tile_region_entry_countは、packed frameのregionが一致する、もしくは含まれるTile regionの数を示し、tile_region_group_idは、Tile Region GroupのgroupIDである。
　このように、Region wise packing boxが拡張され、Tile Region Groupへの参照情報が追加される。同様の拡張を、RectRegionPacking()で実施してもよい。
　なお、図４６に示されるように、RectRegionPacking(i) には、次のようなフィールドが記述される。すなわち、proj_reg_width[i], proj_reg_height[i],proj_reg_top[i],proj_reg_left[i],transform_type[i],packed_reg_width[i],packed_reg_height[i],packed_reg_top[i],packed_reg_left[i]が記述される。
　次にRegionWisePackingBoxの第２の拡張方法について、図４７乃至図４９を参照して説明する。図４７は、RegionWisePackingStructの構成例を示す図であり、図４８は、packing_typeを説明する図であり、図４９は、TileRegionPacking(i) の構成例を示す図である。
　図４７に示されるように、RegionWisePackingStructには、num_regions, proj_frame_width,proj_frame_heightが記述される。また、 num_regions の数に応じてpacking_type[i]が記述され、packing_type[i]が０である場合、RectRegionPacking(i)が、num_regionsの数に応じて記述される。packing_type[i]が１である場合、TileRegionPacking()が、num_regionsの数に応じて記述される。図４８に示されるように、packing_type[i]は、リージョンワイズパッキングに関する情報を表す。その値０は、矩形領域のリージョンワイズパッキングを示し、その値１は、TileRegionによるリージョンワイズパッキングを使うことを示す。
　図４９に示されるように、TileRegionPacking()には、proj_reg_width[i],proj_reg_height[i],proj_reg_top[i],proj_reg_left[i],transform_type[i]が記述される他、tile_region_group_id[i]が記述される。
　このように、この例の場合、TileRegionPacking()が新規に定義され、packed frameのregion情報がtile region groupのgroupIDでシグナルされる。そしてpacked frameのregionがtile regionとアラインしている場合に使用するpacking type (=1)が追加される。
　次にRegionWisePackingBoxの第３の拡張方法について、図５０と図５１を参照して説明する。TileRegionPacking()は、図４９の例に替えて、図５０に示されるように構成することもできる。図５０は、TileRegionPacking()の構成例を示す図であり、図５１は、stereo_packed_regionを説明する図である。
　図５０の構成例においては、図４９の構成例の場合と同様に、proj_reg_width[i],proj_reg_height[i],proj_reg_top[i],proj_reg_left[i],transform_type[i],tile_region_group_id[i]が記述される。図５０の構成例においては、さらにstereo_packed_regionが記述される。図５１に示されるように、stereo_packed_regionは、left viewとright viewのペアに関する情報を表す。その値０は、regionがleft viewとright viewのペアで構成されていないことを示し、その値１は、regionがleft viewとright viewのペアで構成されていることを示す。
　stereo_packed_region=1の場合、proj_reg_width, proj_reg_height, proj_reg_top, proj_reg_left, transform_typeはleft viewのもののみがシグナルされる（記述される）。tile regionには、シグナルされたleft viewのregionと、対応するright viewのregionが、stviに従ってstereo packingされる。
　なお、stereo_packed_region=1の場合、さらにstereo_indication_typeをシグナルしてもよい。
　以上のように、第６の例においては、region wise packingの領域情報にTileRegionGroupへの参照を持つようにするので、region wise packing領域に相当するtile regionを容易に認識できるようになる。また、TileRegionGroupEntryを参照し、所望のregion wise packing領域に相当するtile regionを見つける処理を省略することができる。その結果、容易に画像を再生することができる。
　＜第２の実施の形態＞
　　（依存関係情報の付加（図５２乃至図６２））
　次に、rinf下の複数の情報に対して、処理時の順番、優先度等の依存関係情報を付加し、画像再生装置による適切な処理を可能とする例について説明する。
（２－１）第１の例（図５２乃至図５６）
　第１の例においては、rinfとschiの下に新たなboxが定義される。図５２は、rinfに存在する情報の例を示す図である。図５２の構成は、基本的に図２に示される場合と同様であるが、この例においては、schiの下に、povd,fovd,rwpk,stviと同じ列に、schp(Scheme Information Priority Box)が新たに定義される。schiは、複数のScheme Information Box下のscheme specificな情報の適用順序の情報を持つ、任意のboxである。
　図５３は、SchemeInformationPriorityBoxの構成例を示す図であり、図５４は、SchemeInformationPriorityBoxのフィールドを説明する図である。SchemeInformationPriorityBoxには、number_of_scheme_specific_dataと、number_of_scheme_specific_dataに対応する数のboxtype[i]が記述される。図５４に示されるように、number_of_scheme_specific_dataは、schi下に格納されている、scheme specific dataのBox数 (schpは除く)を示し、boxtypeは、scheme specific dataのbox type (4キャラクターコード)を示し、forループの順に処理優先度が高いことを示す。4キャラクターコードとは、例えばpovd,fovd,rwpk,stvi等である。
　図５５は、schpの構成例を示す図であり、図５６は、処理手順を示す図である。例えば図５５に示されるように、schpにおいて、number_of_scheme_specific_dataが３とされ、boxtypeの4キャラクターコードとして、forループ内に、rwpkのboxtype[0]、stviのboxtype[1]、povdのboxtype[2]が、その順番に記述されていたとする。この場合、レンダリング時の処理は、図５６に示されるような順番で行われる。
　すなわち、最初に１２個のtileよりなるpacked frame２０１に対してrwpkを参照した処理が行われる。これにより、packed frame２０１の６個のtileを含むleft viewと、packed frame２０１の他の６個のtileを含むright viewがside-to-sideに配置されたprojected frame２１１が生成される。次にprojected frame２１１に対してstviを参照した処理が行われてleft viewのprojected frame２２１Ａとright viewのprojected frame２２１Ｂが生成される。そしてさらにその次に、left viewのprojected frame２２１Ａとright viewのprojected frame２２１Ｂに対してpovdを参照して、キューブ２３１Ａとキューブ２３１Ｂにレンダリングする処理が行われる。このように、schpの情報に従って、画像再生装置は正しい処理順序でポストプロセスを行うことが可能となる。
（２－２）第２の例（図５７）
　次に第２の例について、図５７を参照して説明する。第２の例においては、SchemeInformationBox(schi)が拡張される。図５７は、SchemeInformationBoxの構成例を示す図である。このSchemeInformationBoxにおいては、図５３のSchemeInformationPriorityBoxにおける場合と同様に、number_of_scheme_specific_dataと、number_of_scheme_specific_dataに対応する数のboxtype[i]が記述される。また、Box scheme_specific_data[]が記述される。
　boxtype[i]は、例えば図５５に示されるように記述される。その場合、図５６を参照して説明した場合と同様の処理が行われる。
　なお、シンタックス的には拡張せずに、scheme_specific_dataの並び順に先頭から優先度が高いことを示すように規定してもよい。
（２－３）第３の例（図５８乃至図６０）
　第３の例においては、scheme specific dataが拡張され、scheme specific data中に、優先度を記載するboxが定義される。図５８は、SchemeInformationPriorityBoxの構成例を示す図であり、図５９は、priorityを説明する図である。
　図５８に示されるように、SchemeInformationPriorityBoxには、priorityが記述される。priorityは、図５９に示されるように、scheme specific dataの処理優先度を示し、値１が最も優先度が高く、値が大きくなるにつれて優先度は下がる。値０は優先度がないことを示す。
　stviに適用した場合においては、図６０に示されるようになる。図６０は、StereoVideoBoxの構成例を示す図である。このStereoVideoBoxには、single_view_allowed,stereo_scheme,length,stereo_indication_typeの他、SchemeInformationPriorityBox scheme_info_priorityが記述される。すなわち、stvi内にSchemeInformationPriorityBoxが格納されている。その結果、priorityに記述された優先度の順番に従って処理が行われる。
　その他のscheme specific data(rwpk,povd等)にも同様に適用することができる。
（２－４）第４の例（図６１、図６２）
　第４の例においては、SchemeTypeBoxが拡張される。図６１は、SchemeTypeBoxの構成例を示す図であり、図６２は、priority_flagを説明する図である。
　このSchemeTypeBox(schm)には、scheme_type,scheme_type,scheme_version（scheme version）が記述される。またversionが１である場合、priority_flagが記述される。図６２に示されるように、priority_flagは、scheme_specific_dataの処理手順に関する情報を表す。その値０は、schi下のscheme_specific_dataの処理順は不定であることを示し、その値１は、schi下のscheme_specific_dataは、定義された順に先頭から処理することを示す。さらにflagsが１である場合（(flags & 0x000001)である場合）、scheme_uri[]（browser uri）が記述される。その結果、priority_flagに記述された順序に従った処理が行われる。
　なお、flagsでpriority_flagと同様の情報をシグナルしてもよい。
　以上のように、第２の実施の形態によれば、rinfに格納されている情報中に、レンダリングする際に必要な情報が複数存在する場合、それぞれの情報の依存関係が記述されるので、画像再生装置は処理順序を知ることができ、適切なレンダリング処理を行うことができる。その結果、rinfの情報を利用し易くなり、容易に画像を再生することが可能になる。
　このように、rinfの参照すべき情報を関連づけるための関連情報として、第２の実施の形態においては、依存関係を表す情報が用いられる。
　＜生成処理と再生処理（図６３乃至図７０）＞
（３－１）画像処理システム
　次に、画像を取得し、それを再生する処理について説明する。図６３は、画像処理システムの構成を示すブロック図であり、図６４は、ファイル生成部の構成を示すブロック図であり、図６５は、ファイル解析部の構成を示すブロック図であり、図６６は、表示部の構成を示すブロック図である。
　図６３に示されるように、画像処理システム３０１は、画像を生成し、出力する画像生成装置３１１と、画像生成装置３１１から供給される画像を再生する画像再生装置３１２とにより構成されている。
　画像生成装置３１１は、データを入力するデータ入力部３２１、データ入力部３２１から供給されるデータをエンコードするエンコーダ３２２、およびエンコードされたデータからファイルを生成するファイル生成部３２３により構成されている。ファイル生成部３２３により生成されたファイルは、画像再生装置３１２に供給される。
　画像再生装置３１２は、ファイル生成部３２３により生成されたファイルを解析するファイル解析部３３１、ファイル解析部３３１の出力をデコードするデコーダ３３２、およびデコードされた画像を表示する表示部３３３により構成されている。
　図６４に示されるように、ファイル生成部３２３は、各種の判定処理を行う判定部３５１、データを格納する格納処理を行う格納部３５２、情報を付加する処理を行う付加部３５３、およびファイルの生成処理を行う生成部３５４により構成されている。
　図６５に示されるように、ファイル解析部３３１は、各種の判定処理を行う判定部３７１、各種の選択処理を行う選択部３７２、および解析処理を行う解析部３７３により構成されている。
　図６６に示されるように、表示部３３３は、各種の選択処理を行う選択部３９１、各種の判定処理を行う判定部３９２、各種のポストプロセス処理を行うポストプロセス部３９３、およびレンダリング処理を行うレンダリング部３９４により構成されている。
（３－２）第１の実施の形態の生成処理
　次に、図６７を参照して、第１の実施の形態の生成処理について説明する。図６７は、第１の実施の形態の生成処理を説明するフローチャートである。以下においては、主に第１の例の処理について説明するが、第２の例乃至第５の例の処理においても同様に適用される。
　ステップＳ１１においてデータ入力部３２１は、画像データと音声データを入力する。ステップＳ１２においてエンコーダ３２２は、画像データと音声データをエンコードする。以下においては、主に画像データの処理について説明する。
　ステップＳ１３においてファイル生成部３２３の判定部３５１は、デコード後のポストプロセスが必要であるかを判定する。デコード後のポストプロセスが必要である場合、ステップＳ１４において、ファイル生成部３２３の格納部３５２は、rinfを生成し、必要な情報をそこに格納する。
　ステップＳ１５において判定部３５１は、TileRegionGroupEntryをシグナルするかを判定する。TileRegionGroupEntryをシグナルする場合、ステップＳ１６においてファイル生成部３２３の生成部３５４は、TileRegionGroupEntryを生成する。
　ステップＳ１７において判定部３５１は、TileRegionGroupEntryでデコード時にrinfの情報を参照する必要があるかを判定する。TileRegionGroupEntryでデコード時にrinfの情報を参照する必要がある場合、ステップＳ１８において生成部３５４は、rinfの情報を関連付けるための関連情報を生成する。ステップＳ１９において付加部３５３は、関連情報をTileRegionGroupEntryに付加する。
　これにより、上述した、例えば第１の実施の形態の第１の例におけるrestricted_scheme_info_dependent_flag等が付加される。
　ステップＳ１９の付加処理が行われた後、ステップＳ２０において生成部３５４は、ISOBMFFを生成する処理を行う。すなわちMP4 fileが生成される。
　ステップＳ１３においてデコード後のポストプロセスが必要ではないと判定された場合、およびステップＳ１５においてTileRegionGroupEntryをシグナルしないと判定された場合にも、ステップＳ２０の処理が行われる。また、ステップＳ１７においてTileRegionGroupEntryでデコード時にrinfの情報を参照する必要がないと判定された場合にも、ステップＳ２０の処理が行われる。
　第１の実施の形態の第２の例乃至第５の例における処理の説明は省略するが、第２の例および第３の例においても図２５乃至図２８を参照して説明したrestricted_scheme_info_dependent_flag等が付加される。第４の例において図２９と図３０を参照して説明したTile regionがステレオスコピックか否かの情報や、Tile regionの球座標系における領域情報が付加される。また第５の例において図３２乃至図３４を参照して説明した球面上領域の情報、ステレオパック方法、grouping_type_parameter等が付加される。
（３－３）第１の実施の形態の再生処理
　次に、図６８を参照して、第１の実施の形態の再生処理について説明する。図６７を参照して説明した生成処理により生成されたデータが画像再生装置３１２に供給されると、図６８に示されるような再生処理が行われる。図６８は、第１の実施の形態の再生処理を説明するフローチャートである。以下においては、図６７の処理に対応して、主に第１の例の処理について説明するが、第２の例乃至第５の例の処理においても同様に適用される。
　ステップＳ３１においてファイル解析部３３１の解析部３７３は、ISOBMFF(MP4 file)を解析する。判定部３７１は、TileRegionGroupEntryは存在するかを判定する。TileRegionGroupEntryが存在する場合、ステップＳ３２において判定部３７１は、ピクチャの一部分のデコードを行うかを判定する。ピクチャの一部分のデコードを行う場合、ステップＳ３３において選択部３７２は、TileRegionGroupEntryを参照し、関連情報を選択する。ステップＳ３４において選択部３７２は、関連情報に基づいて、適切なtile regionをデコード対象に選択する。すなわち選択部３７２は、選択された関連情報に基づく処理を行う処理部として機能し、関連づけられたrinf情報があれば、それを用いて適切なtile regionをデコード対象に選択する処理を実行する。これにより、図６７のステップＳ１９において付加された情報に基づいて、適切なtile regionがデコード対象に選択される。
　ステップＳ３１においてTileRegionGroupEntryが存在しないと判定された場合、およびステップＳ３２においてピクチャの一部分のデコードを行わないと判定された場合、ステップＳ３５において選択部３７２は、ピクチャ全体をデコード対象として選択する。
　ステップＳ３４およびステップＳ３５の選択処理が行われた後、ステップＳ３６においてデコーダ３３２はデータをデコードし、出力する。ステップＳ３７において表示部３３３はデータに対応するピクチャを表示する。
（３－４）第２の実施の形態の生成処理
　次に、図６９を参照して、第２の実施の形態の生成処理について説明する。図６９は、第２の実施の形態の生成処理を説明するフローチャートである。主に第１の例の処理について説明するが、第２の例乃至第４の例の処理においても同様に適用される。
　ステップＳ５１においてデータ入力部３２１は、画像データと音声データを入力する。ステップＳ５２においてエンコーダ３２２は、画像データと音声データをエンコードする。以下においては、主に画像データの処理について説明する。
　ステップＳ５３においてファイル生成部３２３の判定部３５１は、デコード後のポストプロセス情報が必要であるかを判定する。デコード後のポストプロセス情報が必要である場合、ステップＳ５４において判定部３５１は、ポストプロセス情報は複数必要であるかを判定する。ポストプロセス情報が複数必要である場合、ステップＳ５５において格納部３５２は、rinf/schiにポストプロセス情報を持つ複数Boxを格納する。ここで格納部３５２は、rinf下のレンダリングする際に必要な複数の情報の処理時の依存関係を表す依存情報を生成する生成部として機能し、次のステップＳ５６において、複数Boxに付加する処理順情報を生成する。ステップＳ５６において付加部３５３は、複数Boxに処理順情報を付加する。
　ステップＳ５４においてポストプロセス情報は複数必要ではないと判定された場合、ステップＳ５７において格納部３５２は、rinf/schiにポストプロセス情報を持つBoxを格納する。
　すなわちステップＳ５５またはステップＳ５７の処理により、第２の実施の形態の第１の例において図５２乃至図５４を参照して、また第２の例において図５７を参照して、それぞれ説明したように、schpにboxtypeが付加される。さらに第３の例において図５８乃至図６０を参照して説明したように、priority, SchemeInformationPriorityBox scheme_info_priority等が付加される。また、第４の例において図６１と図６２を参照して説明したように、priority_flagが付加される。
　ステップＳ５６の付加処理またはステップＳ５７の格納処理の後、ステップＳ５８において生成部３５４は、ISOBMFFを生成する。すなわちMP4 fileが生成される。ステップＳ５３においてデコード後のポストプロセス情報が必要ではないと判定された場合にも、ステップＳ５８の処理が実行される。
（３－５）第２の実施の形態の再生処理
　次に、図７０を参照して、第２の実施の形態の再生処理について説明する。図６９を参照して説明した生成処理により生成されたデータが画像再生装置３１２に供給されると、図７０に示されるような再生処理が行われる。図７０は、第２の実施の形態の再生処理を説明するフローチャートである。主に第１の例の処理について説明するが、第２の例乃至第４の例の処理においても同様に適用される。
　ステップＳ８１においてファイル解析部３３１の解析部３７３は、画像生成装置３１１から供給されたファイルを解析する。すなわち、ISOBMFF(MP4 file)が解析される。ステップＳ８２においてデコーダ３３２は、解析して得られたデータをデコードする。
　ステップＳ８３において表示部３３３の判定部３９２は、デコード後のポストプロセス情報が存在するかを判定する。デコード後のポストプロセス情報が存在する場合、ステップＳ８４において判定部３９２は、ポストプロセス情報が複数存在するかを判定する。ポストプロセス情報が複数存在する場合、上述したように、図６９のステップＳ５５の処理で、rinf/schiにポストプロセス情報を持つ複数Boxが格納され、処理順情報が付加されている。そこでこの場合、ステップＳ８５においてポストプロセス部３９３は、ポストプロセス情報の処理順情報に従い、デコードされたピクチャに対しポストプロセスを行う。
　デコード後のポストプロセス情報が存在するが、ポストプロセス情報が複数存在しない場合、上述したように、図６９のステップＳ５７の処理で、rinf/schiにポストプロセス情報を持つBoxが格納されている。そこでステップＳ８４でポストプロセス情報が複数存在しないと判定された場合、ステップＳ８６においてポストプロセス部３９３は、デコードされたピクチャに対しポストプロセスを行う。
　ステップＳ８５またはステップＳ８６におけるポストプロセス処理の後、ステップＳ８７においてレンダリング部３９４は、ピクチャをレンダリングする処理を実行する。ステップＳ８３においてデコード後のポストプロセス情報が存在しないと判定された場合、ポストプロセス処理は不要となる。そこでステップＳ８５およびステップＳ８６の処理は実行されずに、ステップＳ８７の処理が実行される。
　なお、以上においてはステップＳ８３およびステップＳ８４の処理をデータのデコード後に実行するようにしたが、デコード前に実行するようにすることもできる。
　以上のようにしてrinf下に、レンダリングする際に必要な情報が複数存在する場合に、それぞれの情報の依存関係が示されているので、画像再生装置は処理順を知ることができ、適切なレンダリング処理ができる。このように、rinfの情報を利用し易くし、容易に画像を再生することができる。
　なお本技術は、その本質を逸脱しない範囲において、種々の変形例が存在しうる。
　＜コンピュータ（図７１）＞
　上述した一連の処理は、プログラムにより実行することができる。図７１は、コンピュータのハードウエアの構成例を示すブロック図である。
　コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。
　バス９０４には、さらに、入出力インタフェース９０５が接続されている。入出力インタフェース９０５には、入力部９０６、出力部９０７、記憶部９０８、通信部９０９、及びドライブ９１０が接続されている。
　入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記憶部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインタフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
　以上のように構成されるコンピュータ９００では、CPU９０１が、例えば、記憶部９０８に記憶されているプログラムを、入出力インタフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インタフェース９０５を介して、記憶部９０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部９０９で受信し、記憶部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記憶部９０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ９００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　さらに、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　＜その他＞
　本技術は、以下のような構成もとることができる。
（１）
　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成部と、
　前記関連情報を前記Sample Groupに付加する付加部と
　を備える画像生成装置。
（２）
　前記関連情報は、前記rinfの参照すべき情報の有無を表す情報である
　前記（１）に記載の画像生成装置。
（３）
　前記関連情報は、TileRegionGroupEntry, SampleGroupDescriptionEntryまたはSampleGroupDescriptionBoxに記述される
　前記（１）または（２）に記載の画像生成装置。
（４）
　前記関連情報として、前記rinfの参照すべき情報が、前記rinf以外のboxに付加される
　前記（１）乃至（３）のいずれかに記載の画像生成装置。
（５）
　前記rinf以外のboxは、異なるgrouping_typeで識別される複数のboxである
　前記（１）乃至（４）のいずれかに記載の画像生成装置。
（６）
　前記生成部は、前記rinf下のレンダリングする際に必要な複数の情報の処理時の依存関係を表す依存情報を生成し、
　前記付加部は、前記依存情報を前記rinf下のboxに付加する
　前記（１）乃至（５）のいずれかに記載の画像生成装置。
（７）
　前記依存情報は、処理の順番である
　前記（１）乃至（６）のいずれかに記載の画像生成装置。
（８）
　前記複数の情報は、schi下の異なるboxの情報である
　前記（１）乃至（７）のいずれかに記載の画像生成装置。
（９）
　前記依存情報は、前記rinf下の、前記複数の情報とは異なるboxに記述される
　前記（１）乃至（８）のいずれかに記載の画像生成装置。
（１０）
　前記依存情報は、前記schiまたはschmに記述される
　前記（１）乃至（９）のいずれかに記載の画像生成装置。
（１１）
　前記依存情報は、scheme specific dataにboxとして記述される
　前記（１）乃至（１０）のいずれかに記載の画像生成装置。
（１２）
　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成ステップと、
　前記関連情報を前記Sample Groupに付加する付加ステップと
　を含む画像生成方法。
（１３）
　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択部と、
　選択された前記関連情報に基づく処理を行う処理部と
　を備える画像再生装置。
（１４）
　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択ステップと、
　選択された前記関連情報に基づく処理を行う処理ステップと
　を含む画像再生方法。
　３０１　画像処理システム，　３１１　画像生成装置，　３１２　画像再生装置，　３２１　データ入力部，　３２２　エンコーダ，　３２３　ファイル生成部，　３３１　ファイル解析部，　３３２　デコーダ，　３３３　表示部，　３５１　判定部，　３５２　格納部，　３５３　付加部，　３５４　生成部，　３７１　判定部，　３７２　選択部，　３７３　解析部，　３９１　選択部，　３９２　判定部，　３９３　ポストプロセス部，　３９４　レンダリング部

Claims (14)

  1. 　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成部と、
    　前記関連情報を前記Sample Groupに付加する付加部と
    　を備える画像生成装置。
  2. 　前記関連情報は、前記rinfの参照すべき情報の有無を表す情報である
    　請求項１に記載の画像生成装置。
  3. 　前記関連情報は、TileRegionGroupEntry, SampleGroupDescriptionEntryまたはSampleGroupDescriptionBoxに記述される
    　請求項２に記載の画像生成装置。
  4. 　前記関連情報として、前記rinfの参照すべき情報が、前記rinf以外のboxに付加される
    　請求項２に記載の画像生成装置。
  5. 　前記rinf以外のboxは、異なるgrouping_typeで識別される複数のboxである
    　請求項４に記載の画像生成装置。
  6. 　前記生成部は、前記rinf下のレンダリングする際に必要な複数の情報の処理時の依存関係を表す依存情報を生成し、
    　前記付加部は、前記依存情報を前記rinf下のboxに付加する
    　請求項１に記載の画像生成装置。
  7. 　前記依存情報は、処理の順番である
    　請求項６に記載の画像生成装置。
  8. 　前記複数の情報は、schi下の異なるboxの情報である
    　請求項７に記載の画像生成装置。
  9. 　前記依存情報は、前記rinf下の、前記複数の情報とは異なるboxに記述される
    　請求項８に記載の画像生成装置。
  10. 　前記依存情報は、前記schiまたはschmに記述される
    　請求項８に記載の画像生成装置。
  11. 　前記依存情報は、scheme specific dataにboxとして記述される
    　請求項７に記載の画像生成装置。
  12. 　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を生成する生成ステップと、
    　前記関連情報を前記Sample Groupに付加する付加ステップと
    　を含む画像生成方法。
  13. 　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択部と、
    　選択された前記関連情報に基づく処理を行う処理部と
    　を備える画像再生装置。
  14. 　rinfの参照すべき情報をSample Groupに関連づけるための関連情報を選択する選択ステップと、
    　選択された前記関連情報に基づく処理を行う処理ステップと
    　を含む画像再生方法。
PCT/JP2018/010081 2017-03-27 2018-03-14 画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法 WO2018180511A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-061546 2017-03-27
JP2017061546 2017-03-27

Publications (1)

Publication Number Publication Date
WO2018180511A1 true WO2018180511A1 (ja) 2018-10-04

Family

ID=63675564

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/010081 WO2018180511A1 (ja) 2017-03-27 2018-03-14 画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法

Country Status (1)

Country Link
WO (1) WO2018180511A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022133439A (ja) * 2017-06-27 2022-09-13 キヤノン株式会社 メディアコンテンツを送信するための方法、装置及びコンピュータプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013110540A (ja) * 2011-11-18 2013-06-06 Sony Corp 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
WO2015008775A1 (ja) * 2013-07-19 2015-01-22 ソニー株式会社 情報処理装置および方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013110540A (ja) * 2011-11-18 2013-06-06 Sony Corp 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
WO2015008775A1 (ja) * 2013-07-19 2015-01-22 ソニー株式会社 情報処理装置および方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
OHJI NAKAGAMI: "Frame packing arrangement SEI extension for HEVC", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG 16 WP3 AND ISO/IEC JTC1/SC29/WG11 JCTVC-I0057, ITU-T, 27 April 2012 (2012-04-27) - 7 May 2012 (2012-05-07), pages 1 - 4, XP055613109 *
QUALCOMM INCORPORATED: "VR: Video System for 360 Video", 3GPP TSG SA WG4 #91 S4- 161172, vol. SA WG4, 24 October 2016 (2016-10-24) - 28 October 2016 (2016-10-28), pages 22, XP051171316 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022133439A (ja) * 2017-06-27 2022-09-13 キヤノン株式会社 メディアコンテンツを送信するための方法、装置及びコンピュータプログラム
JP7399224B2 (ja) 2017-06-27 2023-12-15 キヤノン株式会社 メディアコンテンツを送信するための方法、装置及びコンピュータプログラム

Similar Documents

Publication Publication Date Title
US10582221B2 (en) Image data encapsulation with referenced description information
JP6960528B2 (ja) メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム
US10567784B2 (en) Description of image composition with HEVC still image file format
JP7399224B2 (ja) メディアコンテンツを送信するための方法、装置及びコンピュータプログラム
JP7133038B2 (ja) メディアコンテンツを送信する方法、装置及びコンピュータプログラム
KR20210144912A (ko) 미디어 데이터를 생성하기 위한 방법
JP6088968B2 (ja) フラグメント基盤のマルチメディアストリーミングサービス提供方法とその装置、並びにフラグメント基盤のマルチメディアストリーミングサービス受信方法とその装置
US20160029091A1 (en) Method of displaying a region of interest in a video stream
US20120288257A1 (en) Image processing device, information recording medium, image processing method, and program
WO2014111423A1 (en) Method of displaying a region of interest in a video stream
WO2011083625A1 (ja) 画像処理装置、情報記録媒体、および画像処理方法、並びにプログラム
CN111095937B (zh) 图像处理设备和文件生成设备
US11729366B2 (en) Information processing apparatus and method
WO2018180511A1 (ja) 画像生成装置および画像生成方法、並びに画像再生装置および画像再生方法
US20210092374A1 (en) Information processing apparatus and method
KR101382618B1 (ko) 콘텐츠 정보 생성 방법 및 콘텐츠 정보를 이용한 콘텐츠처리 장치
JP7239029B2 (ja) 画像処理装置およびファイル生成装置
US20220076485A1 (en) Information processing apparatus and information 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: 18775418

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP