International organisation for standardisation organisation internationale de normalisation
Action Points MPEG-4 AVC File Format (14496-15)
Download 8.47 Mb.
|
- Navigate this page:
- Summary of discussions
Action PointsMPEG-4 AVC File Format (14496-15)
Disposition: noted Questions about losing the timing; how would the sequence be ‘normally’ presented? Would meta-data items work better? There is clearly a desire here to leverage the very rich support we have in tracks (e.g. shared sample entries, sample groups, sub-samples, and so on). Is a ‘default’ timing table harmful (e.g. constant frame duration), and is there any benefit in losing it? There is a problem that we use the decoding offset to establish presentation order. To what extent can we expect coding parameters to stay constant (and thus share a sample description)? A new track type certainly makes clear that this is not ‘normal’ video, but we worry that the distinction between ‘video’ and ‘image sequence’ and ‘sequence of image bursts’ may not be so cut and dried.
Disposition: noted We wonder if these two flags could be handled as sample groups (it’s cheap to map all samples to a sample group). But certainly it’s possible to add to the sample entry, if needed.
Disposition: noted Uses groups; don’t we also need a way to group the pictures in a single burst? Maybe sample groups also work here as though each burst would need a new description, those descriptions could be of zero length and hence cost nothing – a ‘burst index’ sample group? We could have sample groups that describe each type of burst, as well. (E.g. a “focal burst” sample group, and so on). How deep does the grouping need to go (e.g. trees)? We also reviewed 30315 (above) and the requirements on still pictures (coming out of the requirements group). The use of meta-boxes is tempting but might lead to having two ways to do some things (e.g. a single picture in a track or in a meta-box). It might be worth exploring whether meta-box improvement is worthwhile, but by the time we’re into timed bursts it looks like tracks structures may be better. We’d like to work up the needs, the trade-offs, and so on, in further contributions. Are we aiming for storage only, or presentation information as well? Are there other tools (e.g. ZIP+manifest, JPEG 2000 formats) that apply, and how well do we ‘compete’? Do we have a direction that simple things would be, well, simple (e.g. a single image in a file)? We also note that though inspired by HEVC, most of this discussion is coding independent.
Disposition: noted This extends sub-track usage (currently defined only for SVC and MVC) to HEVC tiles, enabling switching/alternates in HEVC to be in one track. We note that ‘independent’ means not only within this picture, but also over time. This was inspired by m29231 (Incheon). Note that finding the tiles is necessarily coding-system specific. Can this be applied to AVC as well (motion-constrained tile sets, SEI)?
Disposition: noted This leverages the ‘mapping’ group idea that was used in SVC. Rather than the above, it indirects through sample groups to get the sub-tracks (which is a permitted mode of sub-tracks).
Disposition: noted This is a similar approach to the above, using maps and sample groups. This seems purely sample groups – sub-tracks could leverage these, but is not specified here. Sub-tracks would be additional, and may be useful. These three contributions are heading in similar directions, and a union of them (sample groups, and sub-tracks based on that) would be beneficial. To the extent that we can follow the approach of the previous and not be HEVC-specific where it’s not needed, that would be good. The authors of these three will try to make a harmonized working draft at this meeting, as an output. (Note we also have MVC+D working draft, which has no contributions at this meeting and we’ll carry forward. If the two decide to progress to amendment at the same meeting, we’ll merge). |