Reading animated AVIF fails with error: Unsupported file-type: Unspecified: File does not include any supported brands.
When trying to read animated AVIF file Chimera-AV1-10bit-480x270.avif from https://github.com/AOMediaCodec/av1-avif repository with heif-info, it fails with error:
$ heif-info Chimera-AV1-10bit-480x270.avif
MIME type: image/avif-sequence
Could not read HEIF/AVIF file: Unsupported file-type: Unspecified: File does not include any supported brands.
This file opens fine in gwenview (with qt-avif-image-plugin installed) and also chromium.
Also note that image/avif-sequence was removed from spec, see https://github.com/AOMediaCodec/av1-avif/issues/59 and https://github.com/AOMediaCodec/av1-avif/pull/86.
To reproduce:
git clone https://github.com/AOMediaCodec/av1-avif
cd av1-avif/testFiles/Netflix/avis
heif-info Chimera-AV1-10bit-480x270.avif
OS: ArchLinux x86_64 libheif version: 1.9.1 aom version: 2.0.0 dav1d version: 0.7.1 ImageMagick issue which led to me making this issue: https://github.com/ImageMagick/ImageMagick/issues/2788 Relevant tree at the time of writing this issue: https://github.com/AOMediaCodec/av1-avif/tree/3fb01d066368fc09d86651c1034bcb7a84ca0715/testFiles/Netflix/avis
I tried this image with the proposed change in PR #419, which does help with some "avis" branded AVIF images, but it is missing a pitm (primary item) box.
$ heif-convert Chimera-AV1-10bit-480x270.avif out.png
Could not read HEIF/AVIF file: Invalid input: No 'pitm' box
Proper support for AVIS will require much more work and we also have to extend the API for that. I never understood the need for another container for video formats. Maybe someone can enlighten me why this makes sense?
One compelling use case for AVIF image sequences is on-the-fly image transformation services that convert animated GIFs to AVIF depending on the requester's Accept header.
Many downstream image transformation services rely on libheif via libvips, so a feature like this could potentially save a lot of bandwidth globally.
We could kind-of support files that have a heic or hevc compatible brand.
For example, with the test file that is linked over at #949
$ heif-info ~/starfield_animation.heic
MIME type: image/heif-sequence
main brand: msf1
compatible brands: msf1, hevc, heic, mif1, iso8
image: 256x144 (id=1003), primary
colorspace: YCbCr, 4:2:0
bit depth: 8
color profile: no
alpha channel: no
depth channel: no
metadata:
none
transformations:
none
region annotations:
none
properties:
That file is both an image (top level meta) and a movie (top level moof).
Compatible brand is essentially "if you can handle this, you'll be able to get something from the file", so possibly our checks would be more accurate if we parsed all of the compatible brands and not just the major brand. Its a little slower though.