[Regression] H.264 VAAPI hardware decoding unusual artifacts

[jumperes]

[This issue was also filed in mpv's bugtracker as ​https://github.com/mpv-player/mpv/issues/15874]

Summary of the bug:
As of ffmpeg 7.1 green blocky glitches/curruption started to appear when seeking during hardware accelerated h264 video playback in mpv v0.39.0 as well as mpv built from source at commit mpv@834f99e469b22f7abd83a3c6d476c4c7d7e26023. VLC is also affected if it is built against ffmpeg 7.1 and above. Firefox does not display any similar issues in the same reproduction environment. I could not figure out how to test FFplay seeking in combination with VAAPI decoding.

Git bisect led to commit "[510494760cde847e4417231f10c9759d0da6cb07] lavc/vaapi_h264: Fix merging fields in DPB with missing references". Running mpv against ffmpeg libraries built from git checkout n7.1 && git revert 51049476 does not reproduce the issue and hardware accelerated video playback and seeking appears to work perfectly fine again.

Software and Hardware involved:

• 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.

VLC reproduction environment:

• Debian 13 (tested shortly after the stable release from 2025-08-09)

How to reproduce:

• play hardware-accelerated video via VA-API in mpv.
  • H.264 is the only accelerated codec on this gpu that I use. I did not test any of 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.
  • mp4 seems mostly unaffected.
  • forcing mpv to demux the file to memory with --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.

I am 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

Attached are:

• three images showing the glitches (taken with mpv's internal screenshot feature using the s hotkey).
• mpv-output.txt contains a log captured from mpv while the issue was observed.

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](​https://gitlab.xfce.org/apps/xfce4-terminal/-/blob/3fe9c8b3a5a74cd1a38bbfde614b46792a0cff2a/icons/16x16/org.xfce.terminal.svg) that was used to execute mpv, meaning the terminal window was open at that moment.

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

[Balling]

SVG icons are rasterised on a GPU using a quite complex code... It is not done by ffmpeg, only previews.

264 is the only accelerated codec on this gpu that I use

Your GPU is too ancient... This would be like 770, right

[jumperes]

I was assuming anyway that SVG rendering is entirely unrelated to this issue - the terminal window icon might be rendered from the corresponding png asset under /usr/share/icons for all I know. I only linked the asset for illustrative purposes, in order to contextualize the glitches shown on the attached images. In any case, the icon is visible on screen so it already has to be decoded and rendered somewhere in memory before mpv and therefore ffmpeg are launched in the first place, right?

In case the GPU Model I specified using output from lspci isn't enough: I am using an Intel HD 3000 (Sandy Bridge), so it's not quite as old as a an AMD 770 but I am aware that it is on the more ancient side. However, I believe that just that on its own shouldn't mean that regressions like this are unfixable? (Especially since it appears to hinge on one specific commit isolated to the vaapi code in FFmpeg.)
I might be wrong here; in that case I'd very much appreciate at least some explanation (or pointers to appropriate reading material if it exists) as to why this issue is rooted in flawed hardware design limited to very old GPUs and why it would be infeasible to fix regressions like this.

[MasterQuestionable]

͏    Regressor:
͏    ​https://github.com/FFmpeg/FFmpeg/commit/510494760cde847e4417231f10c9759d0da6cb07

[jumperes]

I have updated the issue body to reflect that I was able to reproduce the issue with VLC on Debian 13, both last year on testing (a few months before the release of trixie) and right now using up to date packages.

Initially I could not reproduce it in VLC because I simply overrode LD_LIBRARY_PATH to point to the files I built. VLC on Arch Linux is compiled against ffmpeg 4.4 ​due to a VAAPI issue. I didn't realize this, and because the build uses a different major version of libavcodec it still used the system libraries and not the newer ones I compiled.

​Since 2025-01-14 Debian was backporting a fix from vlc's upstream trunk while compiling vlc against libavcodec61 from ffmpeg 7.1. ​The patch was dropped on 2025-09-28 after vlc 3.0.22 got released.

[jumperes]

Another update: I can't reproduce the issue with ffmpeg 8.1 + mpv (Edit: it might still be present, more on that below).

Git bisect between 8.0 and 8.1 points to "[d3953237d127f82889d27d1a5094cc32fc09d328] avcodec/h264_slice: don't force ff_get_format unconditionally after flush"
I am unable to find the issue referenced in the commit message as "Fix #20760."

I can't reproduce after compiling ffmpeg from
git checkout n7.1.3 && git cherry-pick d3953237d127f82889d27d1a5094cc32fc09d328
Unfortunately, I have no clue if cherry-picking like this might have any side-effects.

Edit: After 10 days of using ffmpeg 8.1 without reverting the initial regressor I have seen identical looking artifacts in firefox 150 while seeking on youtube. This happened only a few times and I have no idea how to consistently reproduce these so I can't say for certain if these are related at all.
N.B.: I did not test VLC with any of this, or any other video player.