Kodi Community Forum

Full Version: Periodical judder, because "sync playback to display" does not adjust to vsynch?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am in the process of switching to XBMC from Mediaportal, as Mediaportal has a few problems with freezing and crashes. I used the original xbmc on the xbox several years ago, and was very happy with that. One of the things that impressed me the most was its absolutely smooth playback (even of 24fps material on a 50Hz TV) due to audio resampling. This has over the years made me an addict to smooth playback, to the point where even a single frame drop every 40 seconds (like when playing 23.976 material on 24Hz) is like a periodical blow to the face.

My mediaportal configuration has included Reclock, which was a b*itch to configure properly, but did guarantee absolutely smooth playback.
This is also what I expected with xbmc´s "sync playback to display"-feature. When enabling this feature, the frame-drop every 40 seconds disappears, but instead I get periods of heavy judder every hour or so.
Unless I am mistaken, this is because xbmc tries to play the movie at 24fps to match the 24Hz refresh rate, but due to small differences in the involved clocks, the match is not perfect. This means that after some time xbmc will deliver the frames around the time of the vsync, and it will be somewhat random whether the frame comes before or after. When enabling the monitoring, I can see that the "sync"-percentage very slowly decreases until it reaches -50%, at which point the juddering starts and goes on for 30 seconds or so. When it stops, it will again play perfectly for an hour.

I believe the only way to avoid this is to monitor the sync-percentage-setting, and adjust the audio resampling to keep the sync-setting steady. This is what reclock does, but it seems that xbmc does not? Or am I the only one experiencing this?
Might be important to include some details about which xbmc you are running ? There are three platforms ( osx, linux, and windows) with that breaking into sub-platforms for example for osx -> osx, atv1, ios and atv2. Then we have which version, so you see the matrix gets quite large and it becomes impossible to guess which one you might be running.
Good point, davilla. I´m running official Dharma official release on windows 7, with a nVidia 9300 motherboard. My guess was that the "synch playback to display"-feature is implemented reasonably similar on all platforms, but that may of course not be the case.

EDIT: BTW, the problem with playing material at a specific framerate matching the display refresh rate is explained here: http://software.intel.com/en-us/articles...onization/. See especially the discussion just below figure 5.
Yes I have same problem. Thats why I stop using "synch playback to display" option Sad

Linux 10.10, Dharma 10
queeup Wrote:Yes I have same problem. Thats why I stop using "synch playback to display" option Sad

Then I guess you get a frame drop every 30-40 seconds instead? I actually prefer having heavy stuttering only every hour.

I´ve worked around the problem for now by using MPC-HC as external player, which allows me configure in Reclock in the graph. Not the most elegant solution. Can one of the developers confirm that "synch playback to display" does NOT monitor the vsynch continuously?
I know what's going on here, the clock referenced from the vertical blank wasn't synchronized to the videoframe timestamps, so if you're unlucky you could end up displaying 25 fps video at 50 hertz with a 1:3 cadence.
This is already fixed in git master.

A pause and unpause could possibly work around it.
bobo1on1: and this problem would arise only when the frame delivery and vsynch have come close to each other (i.e. when enough drift has occurred)? Note that the problem only occurs every hour or so for me.

Maybe I should give it a go with a newer version...
Correct.
bobo1on1 Wrote:Correct.

Bobo1on1, you brilliant man! Downloaded a nightly build, and the sync-percentage now stabilizes at 0% and has stopped the slow drifting. Playback seems completely smooth. Thanks a lot!

Too bad the current official release contains this bug...