VAAPI decoding HDR content with artifacts

[VlaDexa]

Important Information

Provide following Information:

• mpv version
  v0.37.0
• Linux Distribution and Version
  Arch Linux
• Source of the mpv binary
  both Arch Linux repository and ALHP
• If known which version of mpv introduced the problem
• Window Manager and version
  Plasma 6 Release Candidate 2
• GPU model, driver and version
  AMD 7800XT, mesa 24.0.1
• Possible screenshot or video of visual glitches
  

If you're not using git master or the latest release, update.
Releases are listed here: https://github.com/mpv-player/mpv/releases

Reproduction steps

mpv --no-config --hwdec=vaapi "https://youtu.be/ar_lpz_VQ58?si=MHAmFK-gM2_QBSRf"

The first frame will be okay, but then there will be artifacts

Expected behavior

The same picture as the software decoding

Actual behavior

See screenshot

Log file

hardware_artifact.txt

Sample files

sample.mp4

[llyyr]

No artifacts for me on vulkan but it gave me non-HDR h264 video for some reason by default

I can reproduce it on vaapi even on players that aren't mpv. So not our bug most likely

[VlaDexa]

Must be that github recompressed the sample video, sorry about that

[llyyr]

Must be that github recompressed the sample video, sorry about that

no you're good, running mpv [youtube link] gave me h264 and I failed to notice.

[nowrep]

Fixed in mesa 24.0.2 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816

[kasper93]

Workaround for ffmpeg setting segmentation_update_map to 1 with segmentation_enabled == 0.

Shouldn't it be fixed in ffmpeg in this case? The issue also happens on d3d11va

[Dudemanguy]

Sorry now that I actually read the mesa MR I suppose the problem isn't really solved. Seems like an ffmpeg issue?

[llyyr]

I asked about it in ffmpeg-devel and apparently the vaapi fix isn't a workaround at all and just how all drivers should treat values behind switches.

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 855936cdc1c7..4a628625131e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext *avctx,
                 s->s.h.segmentation.feat[i].skip_enabled = get_bits1(&s->gb);
             }
         }
+    } else {
+        s->s.h.segmentation.update_map = 0;
     }
 
     // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas

this fixes the issue from ffmpeg side because the bitstream header values aren't initialized at 0, but remain at the same value as they were for the previous frame.

[kasper93]

and just how all drivers should treat values behind switches.

Citation needed. If everyone is not handling it like ffmpeg expects, that means ffmpeg is wrong, not everyone. And it has to be workaround on ffmpeg side.

[nowrep]

In my opinion if the field isn't in bitstream it shouldn't be passed to driver as bogus value, but technically it's not wrong because from spec it shouldn't be used when segmentation is not enabled and also intel driver can handle that, so there's that. The issue isn't present in gstreamer fwiw.

It's fixed now in mesa common code, which also fixes it for the d3d vaapi driver (not sure if that one was affected).

[llyyr]

ffmpeg does it for vp8, so it probably should do it for vp9 as well. I sent a patch https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/322379.html

[nowrep]

That should probably also zero out segmentation.temporal.

[VlaDexa]

Hey, the fix landed for me, and now the video is being correctly displayed. Since your conversation seems unfinished, do you consider this still being an issue? If not, I'll close it.

[llyyr]

We don't track ffmpeg issues here so seems fine to close