Closed leo-barnes closed 6 days ago
I see for iaug
groups that it has the following language:
When unique IDs are used, an audio-to-image entity group may associate an entity group with an audio track.
The same is present in the description for pano
.
The ster
group does not contain this language, but after reading the text on the unif
brand, it might still be allowed for a ster
group to refer to group IDs since it's not explicitly forbidden. It might be clearer to update the ster
text to allow it though.
Maybe MIAF should also add a restriction saying that an item shall not belong directly to both an altr
group and some other group. If you want an item to belong to both an altr
group and another group this should instead be accomplished by using the unif
brand and referring to group IDs within the groups.
And maybe there should be some restriction on an item belonging to two different altr
groups. It's pretty unclear how to interpret that.
EDIT: I see that this is actually already forbidden.
Any entity_id value shall be mapped to only one grouping of type 'altr'.
And I guess a follow-up question would be:
Can you mix-and-match things in an altr
group? I.e. could an altr
group point to both items and other groups? It could be a way of saying "display this stereo-pair as your first choice, but if that is not supported, display this image item instead" (although the language for stereo-pair groups already say to choose the left image for this specific case).
EntityGroups point to entity_id
's. ISOBMFF says this:
entity_id is resolved to an item, when an item with item_ID equal to entity_id is present in the hierarchy level (file, movie or track) that contains the GroupsListBox, or to a track, when a track with track_ID equal to entity_id is present and the GroupsListBox is contained in the file level.
This may however be combined with the unif
brand, which says this:
The brand 'unif' may be used to indicate unified handling of identifiers, for example across tracks, track groups, entity groups, and file-level MetaBoxes. The consequences are • that a given identifier identifies at most one of those (or nothing at all); for example, there is no identifier which is used to label both a track and an entity group; • that where an identifier is restricted, without this brand, to refer to a particular type (e.g. to a track by track_ID) that reference is no longer so restricted, and can refer to any type (e.g. to a track group), if the semantics of the reference permit it.
Given this, it should be valid to have EntityGroups in EntityGroups as long as you use the unif
brand.
This has been partially addressed. We added some basic restrictions to ISOBMFF to forbid
altr
groups of altr
groupsaltr
groups containing both entity groups and image itemsWe also added some proposed language to MIAF to document how you might sort altr
groups compared to image items. We can probably close this issue unless someone can think of more edge cases that can be easily handled.
The HEIF spec is unclear with how
altr
groups interact with other groups. Say I have a stereo pair group in a file and I want to havealtr
groups for the left and right images in the pair so I can have both low-resolution assets and high-resolution assets in the same file (or multiple codecs, or progressive rendering, or ...).How should a parser interpret that? Would I need to have one
ster
group for the high-res items and one for the low-res items? Or can we either make aster
group that refers to thealtr
group IDs rather than specific items?I think HEIF needs to clarify how this is to be interpreted, or enforce some kind of sane limitations.