feat: Support ISO/IEC 23008-12 AMD2 boxes

[y-guyon]

Description

Add support for the boxes specified in ISO/IEC 23008-12:2025/DAmd 2 "Information technology — High efficiency coding and media delivery in heterogeneous environments — Part 12: Image File Format — Amendment 2: Low-overhead image file format":

• MinimizedImageBox (new box)
• PixelInformationProperty (existing box, new syntax introduced when flags=1)
• ContentColourVolumeBox (existing box, its syntax is reused in MinimizedImageBox)
• AmbientViewingEnvironmentBox (existing box, its syntax is reused in MinimizedImageBox)
• NominalDiffuseWhite (existing box, its syntax is reused in MinimizedImageBox)
• ReferenceViewingEnvironment (existing box, its syntax is reused in MinimizedImageBox)
• FileTypeBox (existing box, minor_version field semantics extended in ISO/IEC FDIS 14496-12/DAmd 1 "Information technology — Coding of audio-visual objects — Part 12: ISO base media file format — Amendment 1: Tools for enhanced CMAF and DASH integration" and relied upon by MinimizedImageBox)

The BitStream class is introduced as a MultiBufferStream wrapper for easier bit parsing.

[y-guyon]

This PR can wait till more final specification stages if syntax conformance is more important than early support.

[y-guyon]

Fell free to suggest changes. The implementation somewhat differs from the existing boxes.

[DenizUgur]

Hi, thank you for the PR. There is an ongoing effort for a bit reader class at the PR linked below. We may wait for that before merging this.

• Add AVS3 audio and video #474

[y-guyon]

Hi, thank you for the PR. There is an ongoing effort for a bit reader class at the PR linked below. We may wait for that before merging this.

That is fine. Alternatively this PR can be merged with BitStream renamed to BitStreamTemporary. Then BitStreamTemporary can be removed in another PR as soon as possible.

It would be much more convenient if MultiBufferStream offered a read_unaligned_bits() API instead of having a separate class, but it does not seem to be the path taken by the PR you mentioned.
However MultiBufferStream::read_unaligned_bits() would not help for the clliBox::parse() argument type matter, unless MultiBufferStream::read_u16() accepts reading u16 without byte alignment (or unless you accept changing read_u16() calls into read_unaligned_bits(16) in clliBox::parse()).

[paulhiggs]

I am happy to use the BitStream wrapper from this PR for my work, although I don't see an easy way in DataStream or MultiBufferStream to reserve some byte aligned bits (8 or 16) for a length, then write out the bitbased values then finally write out the number of bytes back in that reserved bits.

The PSIBuffer in TSduck has the best implementation with pushWriteSequenceWithLeadingLength(n) to allocate the length bits, followed by popState() to write in the number of bytes representing the bits and go back to an aligned writing model.

I use this when reading and writing the DVB service_prominence_descriptor in TSduck.

[y-guyon]

I am happy to use the BitStream wrapper from this PR for my work, although I don't see an easy way in DataStream or MultiBufferStream to reserve some byte aligned bits (8 or 16) for a length, then write out the bitbased values then finally write out the number of bytes back in that reserved bits.

The current implementation of BitStream in this PR is only for reading, which does not have this issue (you can read the size S first and then read the bits B, with a BitStream limited to S bytes for examples).

If BitStream was implemented for writing too, I see three options:

• Keep the existing pattern of writing a size and then bytes (used for all ISOBMFF boxes already), but use a BitStream wrapper to write bits instead of bytes. That should work the same.
• Write a temporary chunk of bits B using a BitStream, pad it, get its length in bytes L, and write to the main output stream L then B. There is an unnecessary copy of the bytes B from the temporary stream to the main output stream, but if you are outputting bits I would imagine the overhead to be acceptable.
• Add two functions to BitStream as you mentioned: one for "reserving" a few bytes at some offset, and one for writing the current offset minus the remembered offset at those remembered few bytes.

I am happy with any approach, as long as I do not have to read bytes and handle bit fiddling manually (especially across bytes).