International organisation for standardisation organisation internationale de normalisation
Action Points MPEG-4 ISO Base File Format (14496-12)
Download 8.47 Mb.
|
Action Points
Disposition: accepted An interesting problem; we’re not happy with defaulting to ‘all’ groups. Can it be somewhere in/near the ‘trex’ box (not in, because we don’t mix fields and boxes)? We note that the sample to group is run-length coded, but it would be nice to leave it out for e.g. map sample groups which remain constant. Using the flags at the box level would mean that samples might be mapped to more than one instance of a type, which isn’t allowed. Perhaps a new version of sample group description Let’s try a new version of the description box with a default_index field (that defaults to 0), and revise the sentence in the mapping to say that the default applies (even when the box is missing e.g. from a fragment or movie). Into amendment 3, for further comment.
Disposition: noted Interesting problem, and more study needed. Extractors are painful for constant patterns, and simple downward dependency leaves ambiguous some ordering questions. But we currently don’t have tiles in separate tracks, or tiling between coding systems (but see SHVC).
Disposition: noted This was taken in sequence with the still-picture file material. We really need a flag in the edit list itself, but there is no room. Perhaps a sample group that says merely “these are a burst”, and then the other group that says what burst-number they are, would enable an aware presenter to loop a burst if it wanted.
Disposition: n/a RA had registered the interesting content as an input, for consideration.
Disposition: accepted Amendment 3 already says ‘extend the previous sample’; we need to document what that means if there is no previous sample (it is like an empty edit). There is an issue with the explicit base-data-offset; when originally written we considered only complete movie files containing fragments, and this base offset was relative within that complete file. It doesn’t make sense for fragments in separate files; we need to make that base explicit in the file format (and note it is useless for the case of fragments in separate files, since you have no idea of the previous sizes), and also make clear that base-data-offset-present cannot be used in this case (and make that explicit in DASH). This means also that you’ll always need a data-offset, to point away from the beginning of the moof. Into amendment 3.
Disposition: not accepted We prefer to follow the meta-data track and use the techniques to link them to media tracks, but make them easily accessible. The segment index box is (a) already too complex and (b) at the structural (bytes and pointers) level. If the media track approach doesn’t work, we’ll re-explore other places (like this).
Disposition: noted (in file format) We note that the time-line alignment is all that is formally needed; don’t talk about storage level concepts (fragments etc.) at the formal level. It might help to have guidelines – align with GOPs, don’t make the quality samples too long in duration. The scale_factor seems odd; if it’s in every sample, does a default help? And if Q=quality*scale, why not make quality a 16-bit field to start with? Where do we standardize this? DASH? Part 12 doesn’t have sample formats (‘media formats’), and Part 15 is NALU video specific. Are we better off using the 4CC of the sample entry (the ‘codec name’) as the registered code-point, as otherwise we’re introducing a new registered type (the ‘quality metric’) and we need to be sure that the sample format can be uniform across all quality metrics, which isn’t clear. |