mpv-player / mpv-player/mpv

dmabuf-wayland: something about frame pacing makes VRR jump to max FPS at ~1Hz

Open
#16,184 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

os:linux
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
  1. Turn on VRR on a monitor (ideally one that makes it visually clear that the refresh rate has quickly changed;)
  2. 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;
  3. Play mpv --no-config --vo=dmabuf-wayland $FILE in full screen with VRR enabled and set-up.
    • This does not happen with vo=gpu or vo=gpu-next!
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.