Add animated AVIF (or AVIS) support

[ramonbouckaert]

Overview

While trying to use this library for a hobby project, I noticed that animated AVIF files were not being parsed by this library.
There are a few problems that prevented this:

• Although AVIF and animated AVIF are both part of the same spec, and are both ISO BMFF files, they have different magic numbers: non animated AVIFs are ftypavif while animated AVIFs are ftypavis (which stands for AV1 Image Sequence)
• While normal AVIFs always seems to have exactly two sub-boxes in their TRAK boxes, animated AVIFs have >=2.
• Animated AVIFs contain META boxes that are sub-boxes of other boxes. While nested META boxes are rarely seen in the wild for non-animated AVIF images, they are commonplace for animated AVIFs, and they are supported in the ISO BMFF: https://b.goeswhere.com/ISO_IEC_14496-12_2015.pdf In the best case, these nested META boxes lead to misleading exceptions being thrown by Kim, but in the worst case they completely confuse Kim's metadata extraction.
• There appear to actually be two standards for embedding XMP data into ISO BMFF files. The more modern approach (already used by Kim, and adopted by HEIF) is to embed XMP within the top-level META box with an item type of mime.
  There is an older approach, described briefly in Adobe's XMP specification (https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart3.pdf) on page 16. Files that use this approach instead embed XMP data in UUID boxes - sometimes at the top level, and sometimes nested inside MOOV boxes. Unfortunately I found lots of animated AVIFs in the wild that store XMP data in this way, probably because that's what exiftool appears to do.

This pull request enhances the BMFF image parser to support animated AVIFs, and allows Kim to identify and parse such files.

Changes

• Added ftypavis magic number for identifying animated AVIF files (also known as AV1 Image Sequence)
• In the Base Image File Format parser:
  • Improved the handling of TRAK boxes, allowing for >=2 boxes and introducing a new class for the the Track Header Box
  • When boxes contain other boxes, their type is passed into BoxReader.readBoxes(...) as parentBoxType, to give the BoxReader visibility of whether a box is top-level or not.
  • MetaBox is split into two classes: MetaBox and MetaBoxTopLevel, the latter of which represents a META box that is not a sub box of some other box. The top-level META box is where our EXIF and XMP data actually live.
  • BoxReader parses META boxes differently depending on whether they appear at the top level of the file, or if they're a sub-box of some other box.
  • BoxReader.readBoxes(...) has smarter logic for stopAfterMetadataRead = true - it will continue reading until it has found XMP data in either a META box or a UUID box.
  • BaseMediaFileFormatImageParser will try to find XMP data in UUID boxes if it cannot be found in the META box.
• Three new animated AVIF test files have been added called photo_84.avif, photo_85.avif, photo_86.avif, which is used by existing tests to ensure accurate metadata extraction. Each one embeds its XMP data differently to test three cases I observer in real-life animated AVIFS: XMP data in the META box, XMP data in a top-level UUID box, and XMP data in a nested UUID box.
• The BMFF BoxReaderTest has been fleshed out so that it tests reading boxes from HEIC, AVIF and animated AVIF test images, rather than just HEIC.

[StefanOltmann]

@ramonbouckaert That's an awesome contribution! :)

Unfortunately I don't think that someone at Ashampoo will ever pull this. :/
I'm no longer with them and I was the only developer on this project.

I continue the work on my fork https://github.com/stefanOltmann/kim

If you could make your PR there, I would love to pull it. :)

[ramonbouckaert]

@ramonbouckaert That's an awesome contribution! :)

Unfortunately I don't think that someone at Ashampoo will ever pull this. :/ I'm no longer with them and I was the only developer on this project.

I continue the work on my fork https://github.com/stefanOltmann/kim

If you could make your PR there, I would love to pull it. :)

No worries! I'll leave this PR open just in case, but make a PR on your fork now.

[ramonbouckaert]

On second thoughts, closing this PR to focus on the fork at https://github.com/stefanOltmann/kim as the codebase has diverged too much