Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix avifParseItemLocationBox() itemReferenceIndex #2080

Merged
merged 2 commits into from
Mar 30, 2024

Conversation

y-guyon
Copy link
Collaborator

@y-guyon y-guyon commented Mar 29, 2024

Revert bug introduced with StreamReadBits(): https://github.com/AOMediaCodec/libavif/pull/1506/files#diff-d4b71621e3fb7422ad72c18339089f9626a0c48a95d4b71483bb18351bcd58c4
Read item_reference_index even if construction_method!=2 to be accurate with the ISOBMFF specification.

Revert bug introduced with StreamReadBits().
Read item_reference_index even if construction_method!=2 to be
accurate with the ISOBMFF specification.
@y-guyon
Copy link
Collaborator Author

y-guyon commented Mar 29, 2024

There is the same issue with v1.0.x:

libavif/src/read.c

Lines 1661 to 1665 in 8892ff4

AVIF_CHECK(avifROStreamReadBits8(&s, &baseOffsetSize, /*bitCount=*/4)); // unsigned int(4) base_offset_size;
if (((version == 1) || (version == 2)) && (baseOffsetSize != 0)) {
avifDiagnosticsPrintf(diag, "Box[iloc] has an unsupported base_offset_size [%u]", baseOffsetSize);
return AVIF_FALSE;
}

I do not think it is necessary to cherry pick the fix. It should just wrongly reject/accept some rare files.

Verbose description:
* Fix 'iloc' box parsing when offset_size, length_size or
  base_offset_size was equal to 1 or 2. Such rare files were wrongly
  accepted.
* Fix 'iloc'v1/2 box parsing when base_offset_size!=0. Such rare files
  were wrongly rejected.
* Fix 'iloc'v1/2 box parsing when index_size!=0. Such rare files were
  parsed with corrupted extent offsets and sizes instead of ignoring
  index_size.
@y-guyon y-guyon merged commit 9c6a37a into AOMediaCodec:main Mar 30, 2024
26 checks passed
@y-guyon y-guyon deleted the fix_parse_iloc branch March 30, 2024 09:38
// :: unsigned int(index_size*8) extent_index;
// :: }
uint64_t itemReferenceIndex; // unsigned int(index_size*8) item_reference_index; (ignored unless construction_method=2)
AVIF_CHECKERR(avifROStreamReadUX8(&s, &itemReferenceIndex, indexSize), AVIF_RESULT_BMFF_PARSE_FAILED);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit/optional: It would be clearer to put this call inside if (indexSize > 0). The corresponding spec is:

    if (((version == 1) || (version == 2)) && (index_size > 0)) {
         unsigned int(index_size*8) item_reference_index;
    }

But perhaps it is that spec that should omit the && (index_size > 0) check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

offset_size can be 0 so it makes as much sense as unsigned int(0) extent_offset; to me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in #2091.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. While reviewing #2091, I discovered a subtle point about item_reference_index -- its value is 1 rather than 0 when item_size is 0. Here is the excerpt from ISO/IEC 14496-12:2022 Section 8.11.3.1, page 82:

The item_reference_index is only used for the method item_offset; it indicates the 1-based index of the item reference with referenceType 'iloc' linked from this item. If index_size is 0, then the value 1 is implied; the value 0 is reserved.

Calling avifROStreamReadUX8(&s, &itemReferenceIndex, indexSize) with indexSize=0 will set itemReferenceIndex to 0. So item_reference_index needs different handling anyway.

src/read.c Show resolved Hide resolved
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.

3 participants