[PATCH] Setting A/V sync window for smoothvideo - Fix DTS in MKV stutter
#1
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.
Reply
#2
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.
Reply
#3
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.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#4
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. Nerd 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. Wink 30 sec is fine in my case, but the optimum should be obviously found by trial & error individually.
Reply
#5
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.
Reply
#6
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.
Reply
#7
I've seen that happen a lot with dts, not sure why it happens.
Reply
#8
Yes, as far as I remember affected movies contain a dts soundtrack.
Reply
#9
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.
Reply
#10
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.
Reply
#11
Wait, it is msec I guess (the value of error variable). So it is not 80 secs, but 80 msecs. Discontinuities are catched by the if (m_synctype == SYNC_DISCON && fabs(m_error) > DVD_MSEC_TO_TIME(10)) branch. However you are right, the larger window may still fail (however m_errorcount will be very large, so it will flatten out the peak quite nicely). This is an extraordinary large error, it actually causes the beat in the music to break. I am thinking about some better solution, so the 1 sec window is kept, but large (it just needs to be defined what is considered large Smile) errors are counted separately and some extra time is given for them to settle... Or maybe just ignore them completely. Will have to test it.

I will try to upload a sample if that helps. Unfortunately I don't know how to check if the encode is faulty. Sad All I know is that MPC-HC plays it fine and does not show anything odd on its graph at the problematic point.
Reply
#12
I don't know if this could be the right place/time to ask for it but I would seriously love to have something similar in XBMC to what MPC-HC offers when you press CTRL+J (the detailed playback info, synch adjustments, graph that shows those) as, especially the graph, it's perfect to catch glitches in your playback performance.
Reply
#13
get.a.life
Reply
#14
spiff Wrote:get.a.life
You really are grumpy spiff :p

But it's an helpful tool to make the perfect playback engine. After a while you really start to catch those glitches every time they manifest. It's an acquired taste. Confused
Reply
#15
printf and gnuplot Wink
Reply

Logout Mark Read Team Forum Stats Members Help
[PATCH] Setting A/V sync window for smoothvideo - Fix DTS in MKV stutter0