mpv-player
AVIF Grid images are not decoded correctly
mpv Information
mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on May 21 2025 20:53:16
libplacebo version: v7.351.0
FFmpeg version: n7.1.1
FFmpeg library versions:
libavcodec 61.19.101
libavdevice 61.3.100
libavfilter 10.4.100
libavformat 61.7.100
libavutil 59.39.100
libswresample 5.3.100
libswscale 8.3.100
Other Information
- Linux version: Arch Linux
- Kernel Version: 6.15.3-arch1-1
- GPU Model: 2d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] [1002:73bf] (rev c0)
- Mesa/GPU Driver Version: Mesa 25.1.4-arch1.1
- Window Manager and Version: KDE Plasma 6.4.1 (Wayland)
- Source of mpv: Arch Main Repository
Reproduction Steps
Open an AVIF file that is encoded using the "Grid" option (f.e. the one attached).
"Grid" option means the AVIF container contains multiple single images that need to be stitched together by the viewer to get the complete image. When exporting an AVIF from Adobe Lightroom and Adobe Photoshop, Grid mode is always used and cannot be turned off. Therefore a lot of images on the web will have the grid option encoded.
It can be achieved using the avifenc encoder command line tool with the following flag (avifenc help page):
-g, --grid MxN : Encode a single-image grid AVIF with M cols & N rows. Either supply MxN identical W/H/D images, or a single image that can be evenly split into the MxN grid and follow AVIF grid image restrictions. The grid will adopt the color profile of the first image supplied.
To check if an image is encoded as grid, one can use ffprobe: ffprobe DSC_1451_HDR.avif Output: Stream group #0:0[0x1]: Tile Grid: av1 (High)
Chromium displays "Grid" encoded AVIFs correctly, but no HDR on Linux Wayland, only HDR on Windows.
Why is it important that mpv supports AVIFs with Grid mode? Because mpv is one of the only tools that supports the display of HDR images in the AVIF format on Linux Wayland and many of these images one would want to see are encoded using Grid mode.
Expected Behavior
The whole image can be seen.
Actual Behavior
Only the first square can be seen.
Log File
Sample Files
ZIP File containing an AVIF file created with Adobe Lightroom which automatically uses the "Grid" encoding option. The image is an HDR image with BT.2020 PQ color.
I carefully read all instruction and confirm that I did the following:
- [x] I tested with the latest mpv version to validate that the issue is not already fixed.
- [x] I provided all required information including system and mpv version.
- [x] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of
--log-file=output.txt. - [x] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [x] I attached the full, untruncated log file.
- [x] I attached the backtrace in the case of a crash.
What does this mean for a potential fix? Where can I direct this issue, so it reaches the right people at the ffmpeg project? Thanks!
It also not clear if we wouldn't need to updated rendering pipeline to support this merging. This tiling is essentially required to handle those images, there are 15 tiles with size 1664x1856, even if there were a ffmpeg filter to stich them together, it would be to big to upload/process on gpu. What's needed is tile aware input in libplacebo which would downscale/crop by tile and stich it to final image of reasonable viewing size.
Long story short, whole plumbing those tiles is also on mpv/libplacebo side to support and unlikely to get support anytime soon, as image viewing is not primary target for mpv. That said, if anyone wants to help implementing that I can give guidance on that front.
EDIT: One side effect of support for tiling input in libplacebo, would be ability to display multiple streams at once, which is also sometimes wanted feature even for videos.
@aaron-rust Just for info, there is a workaround in Adobe Lightroom to avoid saving tiled AVIF. You have to save the image imposing a resizing. Even few pixels of downscaling will work. (not sure if this is still the case in the most recent version)
ffmpeg implemented this in https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20727. If that can be hooked to an auto filter, this can be closed.
It also not clear if we wouldn't need to updated rendering pipeline to support this merging. This tiling is essentially required to handle those images, there are 15 tiles with size 1664x1856, even if there were a ffmpeg filter to stich them together, it would be to big to upload/process on gpu. What's needed is tile aware input in libplacebo which would downscale/crop by tile and stich it to final image of reasonable viewing size.
Long story short, whole plumbing those tiles is also on mpv/libplacebo side to support and unlikely to get support anytime soon, as image viewing is not primary target for mpv. That said, if anyone wants to help implementing that I can give guidance on that front.
EDIT: One side effect of support for tiling input in libplacebo, would be ability to display multiple streams at once, which is also sometimes wanted feature even for videos.
This is easily fixed by switching to a VO with software rendering in a conditional profile targetting very large images, as I show in https://github.com/mpv-player/mpv/pull/15346