dmabuf-wayland: something about frame pacing makes VRR jump to max FPS at ~1Hz
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 37k
- Forks
- 3.5k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 22
Description
mpv Information
mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on Jan 1 1980 00:00:00
libplacebo version: v7.349.0
FFmpeg version: 7.1.1
FFmpeg library versions:
libavcodec 61.19.101
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: NixOS
- Kernel Version: 6.12.21
- GPU Model: 7800XT
- Mesa/GPU Driver Version: 25.0.2
- Window Manager and Version: niri 25.02
- Source of mpv: NixOS package
- Latest known working version: N/A (also an issue in previous release)
- Issue started after the following happened: dmabuf-wayland VO chosen.
Reproduction Steps
- Turn on VRR on a monitor (ideally one that makes it visually clear that the refresh rate has quickly changed;)
- Pick a video file that has a refresh rate multiple of which would trigger a low variable refresh rate on your monitor;
- e.g. 23.976Hz video usually plays at 71~72Hz on my monitor, as the next lowest multiple is < 48Hz that's the minimum my monitor supports; this is still pretty far down its supported refresh range of 48~165Hz;
- Play
mpv --no-config --vo=dmabuf-wayland $FILEin full screen with VRR enabled and set-up.- This does not happen with
vo=gpuorvo=gpu-next!
- This does not happen with
Expected Behavior
The frame rate would consistently remain at around 71.928Hz for a 23.976Hz file throughout the playback.
Actual Behavior
Every second or so the frame pacing triggers the monitor refresh rate to jump to the maximum refresh rate in the supported VRR range (165Hz.) On my monitor the VRR implementation isn't perfect and results in slight change in brightness of dark surfaces that resembles a flicker. Subjectively this seems to happen at a similar time when OSD (ctrl+O) readings update, regardless of whether any OSD is visible or not, but not sure if this is in any way related.
Log File
Log file for BigBuckBunny at 30FPS flicker.txt
Sample Files
http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the dmabuf-wayland VO and compare its frame-pacing behavior with vo=gpu and vo=gpu-next, using the attached flicker.txt and the exact reproduction command. Reproduce with the Big Buck Bunny 30 FPS sample on a VRR monitor, then verify that refresh remains near the expected multiple instead of jumping to the maximum.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- desktop, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100