[PATCH] Setting A/V sync window for smoothvideo - Fix DTS in MKV stutter

There is now a more streamlined solution. Jump straight to page 4 for details.

-----------------------------------------------------

Hi Devs,

First of all, thanks to all of you for this wonderful piece of software. I just submitted a patch http://trac.xbmc.org/ticket/10469 which uses the "syncwindowsize" parameter from advancedsettings.xml to change the window size for sync error correction in smoothvideo (if the parameter is not present, window is set to 1 sec, preserving current behavior).

The background: for me, fluid video is #1 priority for movies and I do passthrough via S/PDIF, so my only option is to use drop/dupe audio. However, I encountered lots of unnecessary packet skips and duplications with some (actually many) movies (mkvs) in both Dharma Beta 2 on Windows 7 and also previously on Ubuntu minimal with XBMC 9.11. Most of them produce lots of stream wrapback warnings for the audio stream which might be an explanation. Simple mkv remuxing did not help, so the problem must be somewhere else. As usual, MPC-HC played these files well, but I prefer XBMC's internal player over everything else on my HTPC.

I took a closer look at the sources and found, that by default, sync is adjusted after 1 second. Clocks in my setup are relatively accurate (need >10 mins for A/V to go async) and my display supports all refresh rates (23.976, 24, 50, 60 Hz), so I tried to increase this to a higher value and found, that adjusting it to 30 seconds eliminates the problem completely on my setup, packets are skipped/duplicated now like I expect it.

I have only tested the patch on Windows, but it does not touch platform specific code, so it should be safe... I tested all sync modes (sync to audio, drop/dupe and resample) and did not encountered any ill side effects. Actually those modes also benefit from a larger window size, most notably sync to audio where video was very juddery.

Please have a look at it and if you find it useful, add it to the mainline.

The problem here is the audio timestamps have some judder, so if you average them over 30 seconds they'll match, but over 1 second they won't.

Having a window of 30 seconds will probably break the resample sync, so I wonder if there's a better solution, maybe we can ignore a big offset if it's only around for one timestamp.

If you have wrapbacks the file is either broken or we read it wrong, so to start with we should validate why you get wrapbacks, that should not happen.

Please disregard what I wrote about wrapback. There are no wrapbacks actually, I just played with dsplayer and unofficial nightlies before and forgot to clean up my HTPC before live testing the patch. Obviously some leftover was causing those wrapback entries in the log. After cleaning up, they are gone.

Still, the original problem is not affected. bobo1on1, you are right, the root cause is that there is some audio jitter and these errors average to 0 over a large sync period, but in 1 sec they do not. Unfortunately I am very sensitive to these frequent skips and duplicates in audio (they are especially annoying when using headphones).

I made some small tests with resampler and it looks like it doesn't break with larger sync windows (but probably resampler does not need this at all), but I must admit it wasn't a through test (just played some 24p movies @ 25 Hz for a while and they sounded/looked OK).

However, I created the patch especially for audio sensitive people using skipdup sync. This is why I have put this option into advancedsettings.xml so there is an opportunity to play around with this for advanced users. 30 sec is fine in my case, but the optimum should be obviously found by trial & error individually.

Same thing applies, we should find out why this is happening.
Can you check if you get a lot of discontinuity errors if you turn off sync playback to display.

Yes, there are discontinuity errors right where the audio packets are duplicated/skipped. Here is the log: http://pastebin.com/TGDiKbQH.

As you see, the discontinuities actually (almost) cancel each other.

I've seen that happen a lot with dts, not sure why it happens.

Yes, as far as I remember affected movies contain a dts soundtrack.

If you can view xlsx... I logged error values of a problematic part in CDVDPlayerAudio::HandleSyncError. The log is here: http://web.t-online.hu/svce/data/ts_error_log.xlsx.

Wow, that's almost 80 seconds, something is really screwed there.
A larger window still doesn't work if the window happens to end up on a boundary of messed up timestamps.