Summary of discussions
Action Points
Image File Format (23008-12) Topics ISO/IEC 23008-12 1st edition
Support for
-
sequences, timed or untimed, with or without audio etc.
-
single still images, the simple case, maybe based on JPX
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
|
|
|
|
|
|
|
|
|
|
|
Summary of discussions
m36825 Technical comments on IFF (RE: WG 11 via SC 29)*
Experts will discuss the possible simplifications and choose a way forward.
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.
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.
Dostları ilə paylaş: |