jurplel
[Feature request] IVF file format support
Installed for macOS 13 with brew (using Apple M2) https://formulae.brew.sh/cask/qview
This is possibly a malformed image. I could not load it in any application that loads avif (several photo viewers that support it and a current version of Chrome), and GIMP returned:
Opening '/home/evan/animation-woods.avif'
failed: Loading HEIF image
failed: Invalid input: No 'ftyp' box
System: Linux, Kubuntu 22.04 with backports.
@EvanEdwards VLCand mplayer can play it. The ftyp issue is because proper support has not been added yet.
- https://github.com/d2phap/ImageGlass/issues/1465
- https://gitlab.gnome.org/GNOME/gimp/-/issues/2209
- https://github.com/carsales/pyheif/issues/5
The issue has been reported to GIMP: https://gitlab.gnome.org/GNOME/gimp/-/issues/9356 The animation should cycle through indefinitely like a gif.
I can confirm it works in VLC and mpv (my copy of mplayer is ancient). However:
- It fails in Chrome 112.0.5615.49 (AVIF image format is fully supported on Google Chrome 105)
- It fails in Firefox 112.0 (AVIF full compliance was claimed in version 93)
- It fails in image-lint on npm (output below)
- It fails on this validator from the Alliance for Open Media who created the AVIF spec (output below)
image-lint output:
animation-woods.avif
INFO: This file is not what it seems, attempting brute force discovery of file type.
WARN: There is a mismatch between the file extension (.avif) and the file contents (unknown)
ERROR: Unknown file type
1 warnings. 1 errors.
Total Warnings: 1, Errors: 1
Validator for AOM AV1 image files (AVIF)
Result:
Compliance Warden, version v31-master-rev0-gb1ce523.
Tool errors:
ISOBMFF probing: first box size too big (1145784646 bytes when file size is 406941 bytes). Aborting.
Again, these are observations, and I am not familiar enough with the spec to go in with an editor and look at the actual frames and data. I can not positively state that it is a broken image file, but it does fail the validator created by the organization that created and maintains the format specification. It also fails on many highly visible projects that implement AVIF support using different libraries. I thus tend to suspect it is a non-compliant file that libavformat currently happens to be able to parse, which mplayer, mpv, and VLC all use (pretty much anything that uses FFmpeg).
[Edit: Right after I posted this I also checked with a quick conversion to a video file using ffmpeg itself and it does parse the file as well, which fits my theory.]
As a followup, using ffmpeg 6.0 I can convert the animation-woods.avif to test1.avif, essentially reencoding it. Many errors are noted, but it does result in an image file that successfully loads and animates properly in Chrome, PhotoQt, gwenview, qview 4, and several other viewers. It loads in GIMP, although as a static image. It also passes the AOMedia validator with no errors and only two warnings.
The converted file does not, however, load in qview 5.0 or 2023-01-11 nightly (the version I happen to have on my system). So the bug itself is probably valid, even if the example file may have encoding issues.
You can create a sample avif from a gif with the command provided in this page: https://github.com/xiph/rav1e/issues/356
And use this provided gif:
ffmpeg -i animation-woods.gif -pix_fmt yuv420p -r 12 -vf scale=640x480 -f yuv4mpegpipe - | rav1e - -o - --quantizer 20 --speed=10 > animation-woods.avif
rav1e outputs in IVF format, changing extension to .avif doesn't make it AVIF.
You can pipe output of ffmpeg into avifenc (from libavif package):
ffmpeg -i 232261428-7ce3f0d3-4eca-4e40-8a36-f2e925444ac9.gif -pix_fmt yuv420p -r 12 -f yuv4mpegpipe - | avifenc --stdin -o output.avif
Testfile: http://188.121.162.14/avif/woods-animation.avif
Closing since it seems to be explained/not a qview issue
It depends if you want qview to be able to view it or not.
My bad, I thought it was related to AVIF, I didn't notice the scope of the issue changed
If there exists a Qt IVF plugin, I can try to deploy it with qView. In the meantime, there is nothing I can do about the issue short of a complete move to a Magick++ backend (which is honestly pretty tempting, after dealing with the plugin builds).