Skip to content

Conversation

@wantehchang
Copy link
Collaborator

ISO/IEC 14496-12:2022 Clause 8.11.6.2 says:

aligned(8) class ItemInfoBox
extends FullBox('iinf', version, 0) {
if (version == 0) {
unsigned int(16) entry_count;
} else {
unsigned int(32) entry_count;
}
ItemInfoEntry[ entry_count ] item_infos;
}

Do not reject version > 1 in iinf as an error. This will allow version 2 to be added in the future.

ISO/IEC 14496-12:2022 Clause 8.11.6.2 says:

  aligned(8) class ItemInfoBox
        extends FullBox('iinf', version, 0) {
     if (version == 0) {
        unsigned int(16) entry_count;
     } else {
        unsigned int(32) entry_count;
     }
     ItemInfoEntry[ entry_count ] item_infos;
  }

Do not reject version > 1 in iinf as an error. This will allow version 2
to be added in the future.
@wantehchang wantehchang requested review from vigneshvg and y-guyon May 14, 2025 23:56
@wantehchang wantehchang marked this pull request as draft May 21, 2025 17:05
@wantehchang
Copy link
Collaborator Author

I converted this pull request to a draft. Perhaps the proper way to handle an iinf box of version > 1 is to ignore it.

@maryla-uc
Copy link
Contributor

I was looking at the spec for something else, and indeed I saw that ISOBMFF (14496-12:2024) section 4.2.2 says "FullBoxes with an unrecognized version shall be ignored and skipped."

But note that it's not always clear (in my opinion) what an "unrecognized version" is. The pseudo code you posted doesn't make it clear that only versions 0 and 1 are defined.

Another misleading example I came across is SampleGroupDescriptionBox ('sgpd') where the box definition only has if (version>=1) and if (version>=2) but if you read the spec carefully, a version 3 is also mentioned ("An essential sample group description is a sample group description for which the version field is equal to 3").

@wantehchang
Copy link
Collaborator Author

wantehchang commented May 23, 2025

Maryla: Thanks for your comment.

Searching for "} else {" in ISO BMFF, I found two common patterns.

(1). The syntax says:

   if (version==1) {
      ...
   } else { // version==0
      ...
   }

and the semantics says the version is "0 or 1 in this document" or "0 or 1".

Examples: mvhd, tkhd, mdhd, elst.

(2) The syntax says:

    if (version==0) {
      ...
   } else {
      ...
   }

and the semantics does not enumerate the versions. The condition under which version 1 should be used is described, and no other versions are mentioned.

Examples: cslg, pitm, iinf, fpar.

In this pattern, although the versions are not explicitly enumerated, it is reasonable to interprete that only version 0 and version 1 are defined, for otherwise the description should state the condition under which version 1 or higher should be used.

Another piece of information could help us resolve this issue. Is there a FullBox with a version n that is backward compatible with version n-1? If there is no such a FullBox in ISO BMFF or HEIF, then when version 2 of the iinf box is defined, it is unlikely to be backward compatible with version 1, and it is better to ignore and skip an iinf box of version > 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants