Jerky playback Dharma B2 and SVN /Ion

Well the a/v sync in the codec info isn't entirely correct, dvdplayer does a good job of keeping things in sync, you don't have to look at that value every time and manually adjust the sync.

Well I have been trying to use this method now for a few hours and I am not getting anywhere. If I adjust the refresh rate of the card across 23.974->23.986Hz over many small iterations I always see the sync value drift downwards (ie -1 every period). At the 23.974 end I see the audio discontinuity appear as +10ms and at the 23.986 end I see this as -10ms. It seems though that adjusting the refresh rate also adjusts the audio clock (because they are the same card - hdmi), and thus does not really get me anywhere in this "sync to display mode". In this way all I am really doing I guess is trying to get source file frame rate to match the refresh rate - though it is not clear how to see this from anything xbmc presents in "o" code info panel. I am not sure that the measurerefreshrate settting in advancedsettings.xml is doing much to help though I can see it parses successfully.

I have not given up yet but I can see now why some people return to their settop boxes (PCH etc).

I assume this is used to get an accurate value to build the clock's scale? Any idea how I know this "measurerefreshrate" setting is working eg what message in the log file?

Currently no matter what refresh rate I tweak to, I seem to see in the log file that it thinks it is 23.976023 Hz.

Measurerefreshrate is only useful if windows doesn't report the refreshrate correctly, and it will always round the measurement to the nearest integer, the adjustment of the clock speed based on video fps will cancel that out, so if your refreshrate is 23.976 hertz, xbmc will round that to 24, then on 23.976 fps video it will speed up the clock by 0.1%, so on every vblank interval the clock is updated by 1/24 * 1.001 second, which happens to be equal to 1/23.976 second.

Also, measuring the refreshrate is not very accurate because it doesn't measure for very long.

Oh so the measurerefreshrate is not going to help me. I have now gathered that the "sync" value is now based on the 24Hz mode as it likes to drift by 1ms every 40'ish seconds - and after a complete cycle of 100% it does not necessarily update the clock. This makes the value not at all useful in trying to fine tune the refresh rate. In addition it is not very intuitive (just like seeing the .1% adjust value), given that we are dealing here with 23.976 material. This should really be documented somewhere as it would save people the pain I have been through.

I am now close to getting a refreshrate that completely eliminates the audio correction debug lines (at least for my test case file [m2ts h.264 dd5.1, duration 105mins - copy from bluray]). Will post my results if there is interest.

I am still struggling to get my head around what is going on under bonnet.

I am now using the "sync to display", with "audio clock" method as mentioned. As I adjust the graphics card refresh rate I can see the number of audio discontinuity messages reduce (so less often the clock is adjusted by 10ms).

How is the clock being built from just a vsync/vblank pulse trail that XBMC/dvdplayer assumes to be at a rounded 24.00000Hz?

Where does it get its scale, so that it can compare with the audio stream? Does it assume the duration of a pulse from the source file fps/timestamps or does it still reference the system clock?

Does the audio and video slowly drift out of sync visibly, with the 10ms clock adjust not actually changing anything, until the total discrepancy has reached some threshold?

At what stage would the video from the 23.976 skip over a vsync or duplicate - is this the threshold above?

If there were no audio stream at all I assume I would still see the "sync" value (in codec info) drifting to fix the artificial clock?

I am not sure what I am achieving beyond getting rid of the discontinuity messages, which "feels" like the right thing to do.

I have conducted many further tests. Here is one result : over 140mins with "audio clock" method I see no "10ms discontinuity" debug messages occur - lovely and clean, THEN just changing to "dup/drop audio" method I see for the same film and duration, 7 "drop 10.67ms sample" debug messages.

bobo1on1 can you explain why choosing "dup/drop audio" gives different results than "audio clock"? I mean which one should I trust to try to get perfect sync?

I also confirmed that the only way the "a/v" value does not have a value is when there is no audio stream. It still appears and fluctuates if the audio device is not available. Does this suggests this value is only related to comparison of stream timestamps and nothing to do with clocks?

If you're running trunk, then with drop/dupe there is some extra sync code running to adjust the clock speed slightly to make the video timestamps end up exactly in between two vblanks, that helps if the reported fps for a video is not reported correctly, for example if a 23.976 fps video is reported as 24 fps you'll see sync stabilize at -10%.

If you're using audio clock an offset is calculated instead to make the timestamps end up between two vblanks, because if you start changing the clock speed the two sync methods will fight each other.

If you're using Dharma, there should be no difference between audio clock and drop/dupe.

Ah maybe that's it - I had temporarily switched to trunk to get rid of the pullupcorrection messages I was seeing.

The question is then which is more accurate. I am trying to get the video "clock" to match the audio perfectly. Assuming I use trunk and I see that to reduce all xbmc adjustments to nil I need two very different refreshrates for drop/dup to audio-clock. So which one is really the more correct one?

EDIT: by the way, may I suggest the debug messages have a changing id or timestamp attached because otherwise the log file just gets a cumulative "last message repeated x times" message and then it is not possible to know when the individual events occurred.

TheSwissKnife Wrote:The question is then which is more accurate. I am trying to get the video "clock" to match the audio perfectly. Assuming I use trunk and I see that to reduce all xbmc adjustments to nil I need two very different refreshrates for drop/dup to audio-clock. So which one is really the more correct one?

I'd use audio clock, because currently drop/dupe also depends on video timestamps, maybe I should change that.