Organisation internationale de normalisation

Summary of discussions

4. Action Points

28. Image File Format (23008-12)

    1. Topics

       1. ISO/IEC 23008-12 1^st edition

Support for

1. 
   sequences, timed or untimed, with or without audio etc.
   
2. 
   single still images, the simple case, maybe based on JPX
   

2. Contributions

number	Session	Title	Source
m36362	File Format	An editorial update of the High Efficiency Image File Format specification (ISO/IEC 23008-12)	M. M. Hannuksela, V. K. Malamal Vadakital, E. B. Aksu (Nokia)	Accepted N15523
m36363	File Format	Draft white paper on the High Efficiency Image File Format (ISO/IEC 23008-12)	M. M. Hannuksela, V. K. Malamal Vadakital, J. Lainema (Nokia)	Noted
m36366	File Format	Suggested corrections to 23008-12 FDIS	David Singer	Accepted N15523
m36469	File Format	Demonstration of the High Efficiency Image File Format (ISO/IEC 23008-12)	E. B. Aksu, V. K. Malamal Vadakital, A. Hallapuro, J. Lainema, M. M. Hannuksela (Nokia)	Noted
m36470	File Format	Support of multi-layer HEVC extensions in ISO/IEC 23008-12	M. M. Hannuksela, V. K. Malamal Vadakital (Nokia)	Accepted N15476
m36556	File Format	Editorial changes to the Image File Format	Cyril Concolato, Jean Le Feuvre, Franck Denoual, Frédéric Mazé, Naël Ouedraogo, Eric Nassor,	Accepted N15523
m36559	File Format	Simpler signaling in the IFF	Cyril Concolato, Jean Le Feuvre, Franck Denoual, Frédéric Mazé, Naël Ouedraogo, Eric Nassor,	Accepted N15523
M36269		Overview of the High Efficiency Image File Format		Accepted N15523

3. Summary of discussions

1. m36825 Technical comments on IFF (RE: WG 11 via SC 29)*

Experts will discuss the possible simplifications and choose a way forward.

2. m36559 Simpler signaling in the IFF

We check that the new item info entry works. We wonder if, if all readers have to handle any property being shared, perhaps the item info entry would be cleaner with only pointers.

We wonder if a similar effect can be achieved by requiring some items to be single extents in the idat box. The data is indeed in the meta box, but you still have to process ilocs and byte offsets etc.

When a decoder config is shared from a track, isn’t it easier to copy it? We’re not sure that this is an important case. We could also use an ‘item’ reference from item to track, to make the link explicit. Perhaps an amendment item?

Conceptually, this moves the division: it currently is at structure/content; now what is in the meta box is declarative, and in item bodies is content. We have fewer items and item references.

We do wonder, we're basically moving item content (rotation info.) into shared box content, and references from being item references to being property references. How different is that?

We would need rules on how to handle unknown properties (either that any property is ignorable, or that processing stops on an unknown property).

We can no longer easily have a file that has an image item and is compatible with today’s video players; the branding is hard to work out.

3. m36362 An editorial update of the High Efficiency Image File Format specification (ISO/IEC 23008-12)

Yes, we should put single image into the singular.

Drop the term ISOBMFF-derived, use Image Metadata and just say it’s identical to something from 14496-12.

Arial if it’s the name from e.g. a section title, Courier if it’s a syntax element.

Yes, ‘auxl’ is a candidate to move.

We do the binary MD5 pointing directly to the RFC saying it’s in the same order (network byte) as it would be preceding string conversion.

4.