Mpv: Slow start-up disables video-sync

[daed-alus]

mpv version and platform

mpv 0.29.1
windows 10 x64

Reproduction steps

play a file with interpolation & video sync activated.

Expected behavior

mpv plays the file without a warning and enables video sync & interpolation.

Actual behavior

mpv immediately detects A-V desynchronization and disables display sync and so interpolation

[ 1.246][w][cplayer] Audio/Video desynchronisation detected! Possible reasons include too slow
[ 1.246][w][cplayer] hardware, temporary CPU spikes, broken drivers, and broken files. Audio [ 1.246][w][cplayer] position will not match to the video (see A-V status field).
[ 1.246][w][cplayer]
[ 1.246][v][cplayer] Change display sync audio drift: 1
[ 1.270][v][cplayer] Video sync mode disabled.

running mpv with interpolation deactivated leaves display sync enabled and plays as expected

Log file

mpv.log

[haasn]

Does it happen with --no-config --no-audio --video-sync=display-desync --interpolation?

[laichiaheng]

It happens a lot in the beginning of the video. I need to adjust the progress bar to activate it.

[Akemi]

if it only happens at start up then it's somewhat related to #5882 (just ignore the hwdec part).

see a workaround and how to test it in my comment https://github.com/mpv-player/mpv/issues/5882#issuecomment-394300514, starting the player paused and manually un-pausing it a bit later.

maybe the shaderc shader compilation is at fault here (being a tad too slow)? i see it doing compilations from sec 0.132 to 1.687. the desync and deactivation happens in-between at 1.348 secs. if this causes many dropped frame at the beginning that's one reason why this happens.

[daed-alus]

here there are ~20 dropped frames when it happens
starting paused and un-pause later fixes it for now

[Akemi]

somewhat related, i've seen similar things in macOS and slow start up/backend init.

if my assumptions is right, then possible fixes are to make the desync/deactivation logic less strict on startup or somehow delay the playback after everything is properly initialised (so we don't experience any dropped frames). maybe there is a better way to fix this.

[AstralStorm]

Same issue with certain heavy glsl shader combinations that take a while for GPU to actually load and run, e.g.

gpu-api=d3d11
gpu-context=d3d11
tscale=box
tscale-window=sphinx
tscale-radius=1.05
tscale-clamp=0.0
fbo-format=rgba16hf
scale=ewa_lanczos
#dscale=ewa_lanczos
dscale=gaussian
cscale=ewa_lanczos
scaler-resizes-only=no
vf-clr
glsl-shaders-clr
glsl-shaders-append=~~/FSRCNNX_x4_16-0-4-1.glsl
glsl-shaders-append=~~/FSRCNNX_x3_16-0-4-1.glsl
glsl-shaders-append=~~/FSRCNNX_x2_8-0-4-1.glsl
glsl-shaders-append=~~/SSimDownscaler.glsl
glsl-shaders-append=~~/KrigBilateral.glsl

It really depends on how much of the shader has to be instantly initialized. Ravu and nnedi3 ns32 shaders initialize fast enough to not cause this problem.

Running with --pause then unpausing helps as long as there's about 2s pause until unpausing. Between 60 and 120 dropped frames are registered otherwise. Pause + seek + unpause actually works for some reason, probably hr-seek.

Seems like we need some sort of start preroll.

[zc62]

Probably we can have an option set the presentation queue count, then delay the start of playback until certain number of frames are decoded and rendered (and ready to present). (madVR has such an option. When I first migrated from it, I was missing the capability of changing queue sizes.)

[daed-alus]

i think i found that this only happens with _gpu-api=d3d11_
_opengl_ or _vulkan_ seem not to be affected

i have _gpu-api_ on _default/(auto)_ and _d3d11_ gets automaticlly selected

[zc62]

It is 100% sane to default to d3d11 on windows. I have been using that for quite long.

It looks like you have a lot of shaders enabled. Probably you can try to set gpu-shader-cache-dir to speed up the shader loading. Another thing you can try is to set mpv to use 'adaptive power' (instead of default energy saving option) in Nvidia control panel. d3d11 seems to be heavily affected by this option.

[daed-alus]

not using any shader at all
graphic cards powerplan is and always was on adaptive

[zc62]

mpv built-in scalers generate shaders as well. gpu-shader-cache-dir helps that too.

[Akemi]

the behaviour was changes in https://github.com/mpv-player/mpv/commit/273cc3055cb5829fe62dce88e596c21ae85ef1c2