[FFmpeg-trac] #11473(undetermined:new): Seeking video in mpv started to cause green and blocky glitches with FFmpeg 7.1 (using VAAPI)
FFmpeg
trac at avcodec.org
Sun Feb 16 06:28:39 EET 2025
#11473: Seeking video in mpv started to cause green and blocky glitches with FFmpeg
7.1 (using VAAPI)
-------------------------------------+-------------------------------------
Reporter: jumperes | Owner: (none)
Type: defect | Status: new
Priority: normal | Component:
| undetermined
Version: 7.1 | Resolution:
Keywords: h264_vaapi, | Blocked By:
VAAPI, va-api, mpv |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Description changed by jumperes:
Old description:
> [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.
New description:
[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 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 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.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11473#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list