Seeking started to cause green and blocky gpu glitches with FFmpeg 7.1 (using VAAPI)

mpv Information

mpv v0.39.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Nov 27 2024 18:31:26
libplacebo version: v7.349.0
FFmpeg version: n7.1
FFmpeg library versions:
   libavcodec      61.19.100
   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 (all packages installed from official repo)
- Kernel Version: `Linux arch-m 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux`
- GPU Model: `VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)`
- Mesa/GPU Driver Version: OpenGL version string: 3.3 (Compatibility Profile) Mesa 24.3.4-arch1.1
- Window Manager and Version: Xfce's `xfwm4 4.20.0-2`
- Source of mpv: Official Arch Linux repo
- Latest known working version: `mpv 1:0.39.0-1` together with `ffmpeg 2:7.0.2-3`, `rubberband 3.3.0-2` and `x265 3.6-1` from Arch Linux repo
- Issue started after the following happened: Arch Linux updated to ffmpeg 7.1 a few months ago.

mpv built from 834f99e469b22f7abd83a3c6d476c4c7d7e26023 did reproduce the issue as well.

Since the issue appeared with the update from ffmpeg 7.0 to 7.1 I bisected ffmpeg using git bisect start $(git merge-base release/7.{0,1}) n7.1 and it identified https://github.com/FFmpeg/FFmpeg/commit/510494760cde847e4417231f10c9759d0da6cb07 as the culprit:
[510494760cde847e4417231f10c9759d0da6cb07] lavc/vaapi_h264: Fix merging fields in DPB with missing references
I compiled ffmpeg from git checkout n7.1 && git revert 51049476 and ran mpv against it by pointing LD_LIBRARY_PATH to the shared library build artifacts.
 Doing this did not reproduce the issue. Playback had no issues during my testing so far. I can't tell if this definitely means that the problem is on ffmpeg; I chose to report this here first since I did not observe this specific issue with VLC or Firefox running in the same environment (I used intel_gpu_top from intel-gpu-tools to verify that both of these do in fact utilize video acceleration). Please tell me if this belongs on the ffmpeg bugtracker instead.

Reproduction Steps

• play hardware-accelerated video via VA-API.
  • H.264 is the most recent supported codec on this hardware and the only one that I use hardware acceleration with so I did not test the others (mpeg2 and VC-1 according to vainfo).
• do exact seeks using Shift+Up/Down
  • (video must be playing, not paused.)
  • seeking backwards might be more likely to trigger the issue
  • multiple relatively frequent exact seeks seem to trigger the issue most reliably. (keeping the arrow key pressed for a moment to dispatch multiple keypresses can also help to reproduce.)
  • enough video needs to be bufferd to do the seeks, so a local file is preferred.
• when using a local file, the container format seems to matter.
  • forcing --cache often allows reproducing regardless.
  • if --cache is not enough, remuxing to mpegts should reproduce
  • with mpegts files or when using --cache inexact seeks may also trigger the issue

Expected Behavior

video seeks cause no glitches even with hardware acceleration

Actual Behavior

The video output gets corrupted with mostly green and blocky glitches. Other screen content may appear in these glitches; the example screenshots feature the heavily distorted icon of the Xfce Terminal that was used to execute mpv.

With an mkv container, the glitches usually disappear after doing an inexact seek.
With mpegts, the glitches are more persistent. At worst, cycling the video track removes them at the cost of dropping the demuxer cache, meaning data loss when viewing any live broadcast.

Three images showing the glitches (taken with mpv's internal screenshot feature using the `s` hotkey.")

Log File

output.txt

Sample Files

I was able to reproduce this with H.264 video from multiple sources like YouTube and Twitch. For this issue report I used this example from YouTube:

mpv --no-config --hwdec=vaapi --ytdl-format=137 ytdl://dQw4w9WgXcQ --cache-secs=999 --demuxer-max-bytes=256M

youtube-dl dQw4w9WgXcQ -f137 -o'%(id)s.%(format_id)s.%(ext)s'
mpv --no-config --hwdec=vaapi dQw4w9WgXcQ.137.mp4 --cache
ffmpeg -i dQw4w9WgXcQ.137.mp4 -c copy dQw4w9WgXcQ.137.ts
mpv --no-config --hwdec=vaapi dQw4w9WgXcQ.137.ts
ffmpeg -i dQw4w9WgXcQ.137.mp4 -c copy dQw4w9WgXcQ.137.mkv
mpv --no-config --hwdec=vaapi dQw4w9WgXcQ.137.mkv

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• 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.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

Start by reproducing the issue with mpv --no-config --hwdec=vaapi and the exact-seek steps, then inspect output.txt alongside the FFmpeg vaapi_h264 change in commit 510494760cde847e4417231f10c9759d0da6cb07. Compare behavior with FFmpeg 7.1 and that commit reverted; done means VA-API H.264 playback remains free of green or blocky glitches after repeated seeks, or the issue is confirmed for FFmpeg.