framerate on variable refresh rate displays fluctuates and causes flickering

[serolod]

Important Information

Provide following Information:

• mpv 0.38.0
• Void Linux kernel version 6.6.30
• xbps-install
• sway 1.9
• AMD Polaris 22 XT [Radeon RX Vega M GH], normal kernel driver, Mesa 24.0.5

Reproduction steps

mpv --no-config --video-sync=audio --log-file=output.txt 'https://www.youtube.com/watch?v=oaCfKda82nA'

Expected behavior

The framerate should be very close to 60Hz and vary very little. The screen should not flicker.

Actual behavior

Using drm_monitor I measured the timing when the vsyncs actually occur. Sway allows to enable/disable VRR using swaymsg output * adaptive_sync on|off. In
one can see that with VRR off, the framerate is stable at 120Hz, as expected. With VRR on it fluctuates around 60Hz.

Zooming in one can see the oscillations have an amplitude of around 2.5Hz. The exact amount varies with the video, but the phenomenon can be reproduced reliably. This fluctuation does not sound like much, but can be clearly seen on screen as flickering, especially in darker areas.

Log file

output.txt

Sample files

Occurs on any video I happened to look at, but the measurement was taken on this video.

[na-na-hi]

https://github.com/mpv-player/mpv/issues/12005#issuecomment-1902597586 https://github.com/dechamps/videojitter/blob/master/EXAMPLES.md#video-clock-jitter-eg-vrr

Playing video from a PC using VRR is a very interesting and peculiar case. When using VRR, frames are sent to the display as soon as the video player presents them, as opposed to waiting for the next VSync.

The disavantage is that frame presentation timing now depends on the precise instant at which the video player decides to present a frame. Because Windows is not a real time operating system, and therefore does not make strong timing guarantees, some amount of jitter (most likely video player thread scheduling jitter) is inevitable and will manifest as random variations in frame presentation times.

Note that your result is already much better than the Windows result mentioned. I don't think there is anything mpv can do about this.

[llyyr]

I'd be curious to see if you notice any difference using the drm backend with VRR directly instead of going through sway/wlroots but what nanahi said pretty much still stands.

[serolod]

I'd be curious to see if you notice any difference using the drm backend with VRR directly instead of going through sway/wlroots but what nanahi said pretty much still stands.

To make sure: You mean running with --vo=drm outside of any X11/wayland session?

#12005 (comment) https://github.com/dechamps/videojitter/blob/master/EXAMPLES.md#video-clock-jitter-eg-vrr

Playing video from a PC using VRR is a very interesting and peculiar case. When using VRR, frames are sent to the display as soon as the video player presents them, as opposed to waiting for the next VSync.

The disavantage is that frame presentation timing now depends on the precise instant at which the video player decides to present a frame. Because Windows is not a real time operating system, and therefore does not make strong timing guarantees, some amount of jitter (most likely video player thread scheduling jitter) is inevitable and will manifest as random variations in frame presentation times.

Note that your result is already much better than the Windows result mentioned. I don't think there is anything mpv can do about this.

I don't know anything about mpv's internals, especially not how the sync to the audio works. But couldn't one calculate when the next frame needs to be presented and (busy) wait until then using a sufficiently high-precision clock? Sort of like a self-imposed vsync. Maybe wayland's presentation time protocol could help?

[Dudemanguy]

But couldn't one calculate when the next frame needs to be presented and (busy) wait until then using a sufficiently high-precision clock? Sort of like a self-imposed vsync.

That's already what happens on wayland (minus the busy wait part). And mpv already uses presentation time too.

[kasper93]

minus the busy wait part

Yeah, if we want to do something at certain time we would need to busy wait at least some part of the sleep duration. Normal sleep will never be accurate enough. It is doable, but this is precisely why display-sync exist, to avoid any timing issues and lock presentation to vsync.

This is again the topic of frame limiter basically, that we had some time ago.

[serolod]

minus the busy wait part

Yeah, if we want to do something at certain time we would need to busy wait at least some part of the sleep duration. Normal sleep will never be accurate enough. It is doable, but this is precisely why display-sync exist, to avoid any timing issues and lock presentation to vsync.

This is again the topic of frame limiter basically, that we had some time ago.

I only used --video-sync=audio because from googling around this seemed the preferred mode to use with VRR. Are the display-* modes actually better suited?

[kasper93]

Are the display-* modes actually better suited?

No, they are not compatible with VRR.

[Dudemanguy]

In theory, the polling could be removed during the wayland loop and it becomes just purely a busy wait. I doubt that would change OP's results much at all though because it would still be dependent on whenever the compositor sends a frame callback.