[FFmpeg-trac] #11473(undetermined:new): Seeking video in mpv started to cause green and blocky glitches with FFmpeg 7.1 (using VAAPI)

[FFmpeg]

#11473: Seeking video in mpv started to cause green and blocky glitches with FFmpeg
7.1 (using VAAPI)
-------------------------------------+-------------------------------------
             Reporter:  jumperes     |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  7.1
  undetermined                       |
             Keywords:  h264_vaapi,  |               Blocked By:
  VAAPI, va-api, mpv                 |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 [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 video playback in mpv `v0.39.0` as
 well as mpv built from source at commit
 `mpv at 834f99e469b22f7abd83a3c6d476c4c7d7e26023`. VLC and Firefox do 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.

 How to reproduce:

 - play hardware-accelerated video via VA-API in mpv.
   - H.264 is 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.
   - 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.

 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
 }}}

 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.

 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.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11473>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker