Playback speed doubles when window is on two monitors

[christoph-heinrich]

• mpv 0.34.0-395-g9add44b11a
• Arch Linux
• compiled from source (latest master)
• KDE Plasma 5.25.4 on Wayland
• Mesa 22.1.4 using AMD R9 380

I have two 60Hz monitors and when the window overlaps both monitors, the playback speed usually (but not always) gets doubled.

In this video it doesn't happen in the beginning, but then afterwards it does two times. I only recorded the left monitor, as that's where where most of the window is, but moving it only a little bit onto the right one already triggers it. I've added --osd-msg1="fps \${estimated-display-fps}\njitter \${vsync-jitter}" for the video.

https://user-images.githubusercontent.com/8932183/182983850-8b972924-158f-46cb-8c15-09d2d50e285d.mp4

Note how the estimated-display-fps and vsync-jitter increase when this happens.

Reproduction steps

mpv --no-config --video-sync=display-resample https://github.com/haasn/interpolation-samples/raw/master/60.000.mkv Also happens with local files and files with different refresh rates. Happens with all video-sync=display-* options.

Expected behavior

Always plays video at the same speed, regardless of position

Actual behavior

Playback at 2x speed when window is on two monitors

Log file

output.txt

Sample files

haasns 60 fps test video

[Dudemanguy]

I'm guessing it's something to do with the wayland-specific poll/vblank wait stuff. Do you know if this happens on a compositor with presentation time (sway/wlroots, gnome, or weston)?

[christoph-heinrich]

Does not happen on weston.

[Dudemanguy]

On the surface, that seems to make sense. The non-presentation time code path is a lot more fragile. Basically it's just polling the display fd with a timeout, waking up, and then blocking with a wl_display_roundtrip and praying that this wait basically equals vblank.

[christoph-heinrich]

Maybe add a time measurement to make sure it actually might be vblank. I imagine something like if <time since last frame> is not roughly vblank, return would do it, but I'm not familiar with the code.

Edit: That might cause problems if the player was minimized or something, but checking for a lower bound would still make sense.

Edit2: Actually why not measure the time and then the rest can be the same as if the compositor told us the presentation time. Would this lead to more jitter then just assuming that a fixed amount of time has passed?

[Dudemanguy]

Got a chance to look at this one myself. Having overlapping monitors wakes the poll wait about one frame early; presumably because it's also rending on the other monitor. In theory if you had the window overlapping three monitors, I would expect it to be 3x as fast with display-resample. It can actually happen anywhere. It's just compositor dependent. Sway/wlroots, mutter, and plasma behave like this. Weston happens to not for whatever reason.

As for fixing this, I'm unsure of the right approach that doesn't break the intended semantics of display-resample.

Edit: We do know when mpv overlaps multiple outputs though so maybe just cook up some edge case logic for that so the behavior is more sane. If your window is overlapping multiple monitors, it's not like you really care about frame perfect presentation anyway.

[Dudemanguy]

Okay my original assessment/testing of this was wrong. This only happens on KWin not the other compositors. I mistakenly thought the messed up timing was this bug but actually my 4k screen was connected at 30hz (oops) so it was just normal crap timings (confirmed it by setting it to 1920x1080 @ 60hz).