Video stutters with vulkan+winvk+interpolation

[xnoreq]

mpv version and platform

Built today from master using lachs0r's build scripts.

Reproduction steps

mpv.com --no-config --vo=gpu --gpu-api=vulkan --gpu-context=winvk --interpolation --video-sync=display-resample

either in window mode or in fullscreen mode when the window does NOT have focus on a high refresh rate display.

When the window is in fullscreen and has focus playback is fine.

Expected behavior

Smooth playback.

Actual behavior

Stuttering, dropped frames, estimated display FPS drops significantly and jumps around a much lower value than the actual display FPS, vsync jitter hovering around .8 to over .9.

Log file

https://pastebin.com/raw/VgetuKda

[haasn]

Can you upload a log with --msg-level=vo=trace?

[xnoreq]

https://xserv.hopto.org/xnor/mpv/logs/log3.txt.bz2

Windowed mode, then fullscreen with focus, then fullscreen without focus, roughly 10s each.

[aufkrawall]

Try ClockBlocker, it seems AMD's clock adjustment being flawed isn't just limited to Linux, but also Windows.
Vulkan result is a total mess here (RX 560) with dynamic clocking while it's totally fine with fixed clocks.

[Jj0YzL5nvJ]

bcdedit /set useplatformclock true and reboot.

In theory, Windows auto detect the best value for "useplatformclock", but anyone can force it.
To revert: bcdedit /deletevalue useplatformclock and reboot

https://www.tweakhound.com/2014/01/30/timer-tweaks-benchmarked/

[Hrxn]

Oh, wow. Curious if that bcdedit stuff really works..

Quite a hack. Normally something you'd only want to use for debugging etc.

[xnoreq]

The situation has improved a bit with latest git, but VSync jitter is still 10x higher than d3d11.
I've noticed that the sudden increase of the jitter when switching to/between other applications also happens with d3d11, but the effect is smaller.

I think it would help to use Multimedia Class Scheduler Service (AvSetMmThreadCharacteristics) for the relevant threads.

The wasapi ao already does this by setting the audio thread to the "Pro Audio" task, though I'm not sure that's even the right choice for a video/audio player.

I've exported my Windows 10's multimedia tasks from the registry, in case anyone wants to take a look at the properties of Windows' presets: multimedia-tasks.reg
Most consistent results are probably achieved by choosing tasks that have "Background Only" set to true, such as "Audio" or "Distribution", I guess.

[haasn]

The vulkan API currently doesn't offer an accurate way to measure the jitter.

[kevmitch]

The wasapi ao already does this by setting the audio thread to the "Pro Audio" task, though I'm not sure that's even the right choice for a video/audio player.

Frankly, this setting is a bit of voodoo that's probably only really understood by one Microsoft engineer. That being said, it is set to "Pro Audio" here for the simple reason that it is "recommended" by the example code demonstrating exclusive mode. There's also this:

In Windows Vista, if a system thread manages data transport for an exclusive-mode audio playback stream with a PCM format and a device period of less than 10 milliseconds, WASAPI assigns the MMCSS task name "Pro Audio" to the thread.

Since we use a 10 ms buffer in exclusive mode (which has been found necessary to avoid inexplicably crappy behaviour such as #1773), we use "Pro Audio".

I guess that doesn't justify setting it the same for shared mode other than keeping things simple. If someone can actually demonstrate that this is harmful, I guess we could change it. One such possibility is #3421, which I haven't gotten around to actually measuring.

Sorry to completely derail this issue. If anyone wants to take this discussion further, please open a new issue or reopen #3421 if you can demonstrate there is an issue there.

[xnoreq]

@kevmitch 10ms buffer? In a video player? That would be crazy. For non latency sensitive playback applications it's typical to use hundreds of ms or even seconds because it drastically lowers the probability of buffer underruns and increases efficiency.
I don't see how the linked issue is related to buffer length or scheduling priority. "Audio" and hundreds of ms is what I'd expect from an audio/video player. "Pro Audio" and 10ms is more like DAW territory, with low latency requirements for music production.

@haasn It's hard to believe that. Btw, I've noticed that sometimes when going fullscreen with vulkan there's a bit of extra lag that disables the vsync jitter measurement (?), at least I guess so because mpv-stats disables plotting vsync jitter after that.

[haasn]

@xnoreq If you're on nvidia drivers, try disabling “Allow Flipping” in the OpenGL settings.

[xnoreq]

After a recent update to latest master the initial problem seems to be fixed.

@haasn Regarding accurate presentation timestamps have you looked into VkPastPresentationTimingGOOGLE?

Example usage: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c

[haasn]

Only exists on android

[xnoreq]

There's an update on this:

WIP: RFC: present-timing: Enhanced presentation timing requests and events

WIP: Add the VK_EXT_present_timing extension

This is the time to look through the proposed extension/changes and comment on its (in)adequacy for media player like mpv.