--ao=dsound without --autosync=4 causing video to stutter

[Cyberbeing]

I've been doing some testing on couple Windows 7 x64 computers (nvidia & ati gpu), and notice that the opengl and direct3d_shaders output drivers stutter frequently with autosync=0, the default value. In both cases using a low value of autosync=4 along with --mc=0 resolved the issue.

Has anybody else noticed this?

Would there be any merit for mpv to enable ---autosync=4 and --mc=0 by default?

[ghost]

What audio output? Does it happen with --ao=null? Does it happen with --no-audio?

Setting that value as default for autosync might not be a bad idea, but I'll have to see whether it can have bad effects on perfectly working audio outputs, or what's the cause in your case.

[Cyberbeing]

mpv 64-bit git-0e07189

Issue occurs:
--ao=dsound
--ao=openal
--ao=dsound --autosync=N
--ao=openal --autosync=N
--ao=dsound --mc=N
--ao=openal --mc=N

Issue does not occur:
--ao=null
--no-audio
--ao=dsound --autosync=4 --mc=0
--ao=openal --autosync=4 --mc=0

There is also a separate issue, where vsync can be way off and stutter constantly no matter what the setting depending on when exactly during a screen refresh process mpv presents its first video frame after playback start or seek. If you re-seek once or twice, it will often resolve it. This secondary issue isn't unique to mpv, other dumb renderers on Windows (i.e. Haali renderer) which don't have special vsync correction logic also have this issue.

[ghost]

Did this problem exist on mplayer2 too, or is it a regression? Basically, it would mean that either the ao_dsound and ao_openal outputs are broken, or that audio on windows doesn't provide a viable time source for some reason.

where vsync can be way off and stutter constantly no matter what the setting depending on when exactly during a screen refresh process mpv presents its first video frame after playback start or seek.

How exactly does this happen? The playloop should take vsync timing into account, as long as vsync actually blocks. So, if there is an offset between intended presentation time and actual presentation time, it should be compensated quickly. On the other hand, it appears modern video drivers don't like blocking on buffer swapping anymore, so this mechanism breaks often. (Actual vsync aware timing is available on vo_vdpau only.)

[Cyberbeing]

Did this problem exist on mplayer2 too, or is it a regression?

The need to use --autosync=4 also exists with mplayer2.

There is also a separate issue, where vsync can be way off and stutter constantly no matter what...

How exactly does this happen?

Possibilities include:

1. vsync presentation is not performed at the optimal time

2. playback rate (fps) doesn't match monitor refresh rate, and frame presentation isn't optimized for smoothest display

3. playback rate (fps) mostly matches the monitor refresh rate, but over time a very slightly faster or slower playback rate results in frame drops

4. the audio clock has high amounts of jitter

5. the system timer may have low jitter but be inaccurate

6. the highest accuracy multimedia timer is not being used (i.e. HPET w/ 0.5ms resolution) if available

7. the various timers used for playback are not in perfect agreement with each other

8. thread priorities for critical code are not set correctly, causing processing delays because of thread scheduling.

9. etc.

The accepted solutions on Windows are usually a combination of, Reclock (replaces jittery audio clock, syncs system clock, speeds up or slows down playback rate exactly match vsync if possible, resamples audio to keep sync with playback rate changes), a video renderer which performs managed vsync presentation, and fullscreen exclusive mode which is often more reliable than windowed mode. madVR also has its vsync adaptive blending (smooth motion frame rate conversion) to display frames on an optimal timeline, and eliminate judder. Though before you can worry about judder, you first need to eliminate potential causes of arbitrary stuttering.

Maybe you could do something to delay playback a few millisecond and make a best effort to ensure at least the first frame is aligned with monitor refresh. Otherwise you'd need some way to actually detect this occasional constant stutter problem, and automatically correct it during playback. From my testing, setting --mc to a value greater than 0 (disabled) just makes the stuttering problems worse.

Yet another oddity I've noticed is that mpv seem to have a higher tendency to stutter on Windows when using the --quite or --really-quite switches to silence console output. Does disabling console output make mpv "sleep" more often and/or query multimedia timers less often between workloads?

[ghost]

From my testing, setting --mc to a value greater than 0 (disabled) just makes the stuttering problems worse.

By the way, the default value for --mc can't be set from command line (using --mc simply overwrites it). By default it's 0.1 * duration of the video frame.

Yet another oddity I've noticed is that mpv seem to have a higher tendency to stutter on Windows when using the --quite or --really-quite switches to silence console output. Does disabling console output make mpv "sleep" more often and/or query multimedia timers less often between workloads?

No. All what should happen is that mpv writes less often to the terminal.

[Cyberbeing]

By the way, the default value for --mc can't be set from command line (using --mc simply overwrites it). By default it's 0.1 * duration of the video frame.

I'll go back and edit my posts then. I've been using both --autosync=4 & --mc=0 all along in my config file to fix the stuttering. I didn't realize that 0 wasn't the default value for --mc.

[ghost]

The --autosync option is not completely sane, so I'll wait for the outcome of your tests.

I'll go back and edit my posts then.

Editing is bad. It's hard to see what changed, or that somebody changed something at all. Those who mainly use e-mail to communicate on the issue tracker won't see the edited replies. Better make new posts.

[Cyberbeing]

I'll wait for the outcome of your tests.

What did you need me to test?

As far as my edits, I essentially just changed every post with --autosync=4 only to --autosync=4 --mc=0 because using both together are what fixed the stuttering and initially prompted me to create this issue report. Used alone, neither completely resolve the issue.

[Cyberbeing]

Sorry about that, accidentally hit Close instead of Comment.

Editing is bad

I do have the somewhat bad habit of posting too quickly and then going back to re-edit, adding anything I forgot. I'll try to get into the habit of creating more new posts, if you don't check the issue tracker directly very often.

[ghost]

OK.

Did you try with --softsleep too? This should help if the sleep function. (mpv just uses the Sleep() function, with --softsleep it will do active waiting for up to 11 ms to avoid timer resolution issues with Sleep. Although we do request 1 ms resolution with timeBeginPeriod.)

[Cyberbeing]

Did you try with --softsleep too?

Yes, --softsleep was one of the switches I initially tested, but it didn't help at all.

[ghost]

Well, I find it rather strange that this helps. --mc=0 actually disables the logic to time against vsync. Together with --autosync=4, it assumes that the decoded audio and video are perfectly in sync, but corrects the timing by 1/4 of the difference between video time and actually played audio time, or something like this. I think in theory higher values of --mc might help you. How is it with --no-audio, by the way? In that mode there's no synchronization at all, and it should strictly time according to video PTS (with no consideration for vsync).

Anyway, I think it's better for now not to enable these options by default (even if they help sometimes), and wait until we get something like syncing audio to video instead.

[Cyberbeing]

As mentioned in above, the issue does not occur with --no-audio, and using values of --mc >0 continue to make the stuttering an order of magnitude worse with audio enabled.

Anyway, I think it's better for now not to enable these options by default (even if they help sometimes), and wait until we get something like syncing audio to video instead.

Okay. Were you ever able to personally confirm if this strange behavior was Windows OS specific?

All I know is that mpv was unbearable to use from all the stuttering until I changed these options, but if it doesn't work for everyone, I would agree that it wouldn't make sense to make this the default setting. It's just unfortunate that mpv is essentially broken out-of-box on my Windows 7 computers.

wait until we get something like syncing audio to video instead.

LAV Audio may have something like this in its Auto A/V Sync correction.

[ghost]

Okay. Were you ever able to personally confirm if this strange behavior was Windows OS specific?

Currently I don't have access to a real windows where I could actually test this (it would require getting some test media there too...)

LAV Audio may have something like this in its Auto A/V Sync correction.

From what I know about the mpc-hc world, this is what reclock is doing.

[Cyberbeing]

From what I know about the mpc-hc world, this is what reclock is doing.

Reclock is a combination of audio resampling + replacing the reference clock & actively reducing clock jitter + speed-up/slow-down playback to match refresh rate. The thing about Reclock, is that its designed for refresh rates which are a multiple of the movie framerate, as well as things like PAL->NTSC. If the refresh rate isn't a near multiple of the movie frame rate, all the corrections it performs are disabled.

That LAV Audio thing is something completely different, more about fixing decoded audio jitter and ensuring sync is maintained with the video timestamps. Not vsync related at all.

[ghost]

You mean that jitter stuff in CLAVAudio::Deliver? Looks pretty simple, not sure if not something similar is hidden somewhere in the mplayer code. Possible that it isn't, though. On the other hand, sync is never adjusted abruptly, so some jittering shouldn't have such a big impact IMO. But it also depends how big the jitter is. Have you tested with a raw audio source?

[Cyberbeing]

You mean that jitter stuff in CLAVAudio::Deliver?

Yes, its the code which makes use of the following functions to adaptively correct jitter and re-sync when needed:

m_bUpdateTimeCache
m_rtStartInputCache
m_rtStopInputCache
m_rtBitstreamCache
m_faJitter
m_JitterLimit

In some ways I doubt that lacking something like this could in any way be related to the stuttering problem in mpv, but who knows.

Have you tested with a raw audio source?

If you are talking about LAV Audio "Auto A/V Sync", it is automatically disabled for audio-only sources I believe.

[ghost]

Does it happen with --ao=null? What does the status line say, does it say something about ct:?

[ghost]

Try how large you can make the value passed to --mc until the stutter happens (values between 0 and 0.1 would make sense).

With --mc=0 you'll eventually get desync. I tried with some mkv, and after about 7 mins, the desync was already 20ms (the player still thinks A-V sync is 0.0 aka ok, because --mc compensates for the difference between timestamps that builds up for whatever reason).

The change applied without --mc option is very small (e.g. about 0.000036 per frame in my case), so I'm wondering how the hell it would cause stutter. Try the following patch and paste what it outputs (try with null, dsound, and wasapi AOs): http://sprunge.us/EAMA (it won't change behavior, just adds debug output)

Also, try the following patch: http://sprunge.us/MANS (it also doesn't change behavior). Play a few seconds of video with --dump-stats=out.txt, and paste the resulting out.txt file somewhere. Run it once with default options, and once with options that appear to remove the stutter.

[Cyberbeing]

As mentioned in #98 (comment) the issue does not occur with --ao=null . I've not seen ct: in the status line, but I was unsure of exactly what settings and playback duration what you wanted me to test when looking for it.

After further testing (lachs0r's 2015-01-29 Win32 build), I'm unsure how much --mc is involved with the stuttering.

Occasionally I'll see stuttering with --ao=dsound or --ao=wasapi depending on the exact moment I begin playback or enter fullscreen, no matter what --mc value is set. So at least with current builds, I'm now unconvinced if --mc=0 makes any difference, since my results have been inconsistent over multiple runs.

--ao=dsound I'll always see constant stuttering unless I set --autosync=4

--ao=wasapi seems decent using defaults, with only an occasional glitch.

--ao=null always feels slightly smoother than both.

wasapi wasn't implemented when I originally opened this issue, so it's possible that this Issue may primarily be caused by audio clock variation in --ao=dsound. I'll need to do more testing, as I've always had --ao=dsound set in my config file.

I'm also noticing that overriding display-fps with my refresh rate value causes --ao=dsound to stutter more, which is not immediately apparent with --ao=wasapi. Use of wasapi over dsound doesn't resolve the stuttering with smoothmotion though, which once again seems to confirm that the stuttering seen in Issue #1505 is an OpenGL issue.

I'll see if I can try your patches this weekend, assuming I don't have any trouble updating my cross-compile VM to mpv's new waf build system. Last time I built mpv myself was over 6 months ago.

[mia-0]

I'll see if I can try your patches this weekend, assuming I don't have any
trouble updating my cross-compile VM to mpv's new waf build system. Last
time I built mpv myself was over 6 months ago.

You can use this: https://github.com/lachs0r/mingw-w64-cmake

Notice the prebuilt VM image that has all the build dependencies preinstalled.

With that, you can get binaries with the same configuration as those on my
site. If you want to apply patches, either add a patch step to mpv.cmake
(see the other files for examples) or cd into
/packages/mpv-prefix/src/mpv and do it there after you’ve successfully
built mpv using the environment (do that if you need many rebuilds as the
CMake build system updates all dependencies every time). You can just run
./waf there as usual; mpv.exe will be in the build/ subdirectory. Just take
care not to reconfigure waf without passing the right flags.

[Cyberbeing]

You can use this: https://github.com/lachs0r/mingw-w64-cmake

Thanks, I'll look into that later. A little bit eariler, I already ended up using rossy's MSYS2 guide from https://github.com/mpv-player/mpv/blob/master/DOCS/compile-windows.md#native-compilation-with-msys2 which seemed to go smoothly for compiling a quick dynamic mpv build on Windows.

[Cyberbeing]

patch1 console logs:
dsound (stuttering) | dsound --autosync=4 (smooth) | wasapi (smooth) | null (very smooth)

[Cyberbeing]

patch2 dump-stats logs:
https://www.mediafire.com/?2r64ara13o5d7q8

[ghost]

patch1 console logs:

Looks to me like --mc=0 really shouldn't have any effect. The deviation added by this code is not larger than 1ms in any case.

patch2 dump-stats logs:

Maybe the coarse playback position reporting of dsound is really a problem, wasapi on the other hand looks pretty much perfect.

Can you try running with: --ao=null:outburst=512:broken-delay. Just to see whether you experience stuttering with it or not. (I don't want any logs.) Maybe increase the outburst parameter a bit.

[Cyberbeing]

--ao=null:outburst=512:broken-delay stutters badly

[ghost]

So, is ao_null or --no-audio in any way smoother than ao_wasapi? (With no additional options.)

[Cyberbeing]

Occasionally I'll see stuttering with --ao=dsound or --ao=wasapi depending on the exact moment I begin playback or enter fullscreen

Only this, which I've now been able to confirm also occurs occasionally with --ao=null or --no-audio as well, suggesting it's a completely unrelated OpenGL renderer problem. I've now opened Issue #1543 for that problem.

The apparent 'broken-delay' stuttering (the problem I originally opened this issue for) I believe only affects --ao=dsound, which --autosync=4 functions as a partial-workaround.

[ghost]

I don't think we'll ever bother to fix ao_dsound. It's more likely that we'll just remove it.