mirror of
https://github.com/mpv-player/mpv
synced 2024-12-28 18:12:22 +00:00
c68251a3a7
The wayland backend needs to keep track of whether or not a window is hidden for presentation time. There is no presentation feedback when a window is hidden which means we shouldn't be sending information to the vo_sync_info structure (i.e. just leave it all at -1). This seemed to work fine, but recent changes to presentation time in one notable compositor (Sway; it was probably always broken in Weston actually) changed the presentation time behavior. For reasons that aren't clear, there is a greater than 16.666ms delay between the first presentation time event and the second presentation time event (compositor latency?) when you switch back to an mpv window after it is hidden for long enough (a few seconds). When using presentation time, this causes mpv to feed in some bad values in its vsync timing mechanism thus causing the A/V desync spike as described in issue #7223. This solution is not really ideal. It would be better if the presentation time events received by the compositors did not have the aforementioned inconsistency. However since this occurs in both Sway and Weston and clients can't really fight compositors in wayland-world, here's a reasonable enough workaround. Basically, just add a slight delay before we start feeding information into the vo_sync_info again. We already do this when the window is hidden, so it's not a huge leap. The delay chosen here is arbitrary, and it basically just recycles the same parameters used to detect if a window is hidden. If vo_wayland_wait_frame times out 60 times in a row (or whatever your monitor's refresh rate is), then we assume the window is hidden. This is a pretty safe assumption; something has to be terribly wrong for you to miss 60 vblanks in a row while a window is on the screen. In this case, we basically just do the reverse of that. If mpv receives 60 frame callbacks in a row (or whatever your monitor's refresh rate is), then it assumes the window is not hidden. Previously, as soon as it received 1 frame callback it was declared not hidden. Essentially, there's just 1 second of delay after reshowing a window before the presentation time statistics are used again. This should be more than enough time to skip over the weird inconsistent behavior presentation time behavior and avoid the A/V desync spike. Fixes #7223 |
||
|---|---|---|
| .. | ||
| cocoa | ||
| cocoa-cb | ||
| d3d11 | ||
| gpu | ||
| hwdec | ||
| opengl | ||
| placebo | ||
| vulkan | ||
| win32 | ||
| android_common.c | ||
| android_common.h | ||
| aspect.c | ||
| aspect.h | ||
| bitmap_packer.c | ||
| bitmap_packer.h | ||
| cocoa_cb_common.swift | ||
| cocoa_common.h | ||
| cocoa_common.m | ||
| d3d_shader_420p.h | ||
| d3d_shader_yuv.hlsl | ||
| dither.c | ||
| dither.h | ||
| dr_helper.c | ||
| dr_helper.h | ||
| drm_atomic.c | ||
| drm_atomic.h | ||
| drm_common.c | ||
| drm_common.h | ||
| drm_prime.c | ||
| drm_prime.h | ||
| filter_kernels.c | ||
| filter_kernels.h | ||
| libmpv.h | ||
| vo_caca.c | ||
| vo_direct3d.c | ||
| vo_drm.c | ||
| vo_gpu.c | ||
| vo_image.c | ||
| vo_lavc.c | ||
| vo_libmpv.c | ||
| vo_mediacodec_embed.c | ||
| vo_null.c | ||
| vo_rpi.c | ||
| vo_sdl.c | ||
| vo_tct.c | ||
| vo_vaapi.c | ||
| vo_vdpau.c | ||
| vo_wlshm.c | ||
| vo_x11.c | ||
| vo_xv.c | ||
| vo.c | ||
| vo.h | ||
| w32_common.c | ||
| w32_common.h | ||
| wayland_common.c | ||
| wayland_common.h | ||
| win_state.c | ||
| win_state.h | ||
| x11_common.c | ||
| x11_common.h | ||