• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 20
Jerky playback Dharma B2 and SVN /Ion
#46
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.
Reply
#47
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?
Reply
#48
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.
Reply
#49
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.
Reply
#50
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.
Reply
#51
So "audio Clock" will be more accurate, BUT it will allow the audio to drift out-of-sync until a whole frame of video can be "drop/duped" to bring back in sync?

Have I got this right at last?
Reply
#52
That's correct, except the offset will be one refreshrate period, so on 24 hertz it will be 1/24 second, on 60 hertz it will be 1/60 second.
Reply
#53
Big Grin At last I think I understand. FYI I have now tried 180min film with no discontinuity (gone back to audio clock) - it seems normal DTS and DD are good! Alas this is not the case when audio stream type is "TrueHD down conversion to PCM 5.1/7.1" nor it seems DTS-ES-Matrix passthrough - both of which have discontinuities (often larger than a video frame length) back and forward throughout. I will try to get some other samples of this to confirm for sure, and to try other formats such as DTS-MA->DTS-CORE.

Side note not for further discussion in this thread I also saw that TrueHD to PCM 7.1 seems to have the rear and side surround channels swapped with each other (using trunk).

EDIT: I think the DTS-ES is actually ok as I now suspect a bad encode for this result as I has success with DTS-ES-Discrete...
Reply
#54
bobo1on1 Wrote:That's correct, except the offset will be one refreshrate period, so on 24 hertz it will be 1/24 second, on 60 hertz it will be 1/60 second.

How is it I don't see anything in the log for these video frame dup/drop events? I would expect on 23.976 movie with a refreshrate rate of around the same, that after the audio clock has made >41.7ish ms adjustments to see a message like the the "didn't consume" (or whatever it is) one that I have seen from time to time.

Are these not recorded?

BTW, further tests using Linux XBMC live etc Dharma beta2 show that I need to use a different refreshrate to get the same level of sync as I have been getting in Windows (eg for no "audio clock" discontinuity in 180mins, 23.976260 in Windows 23.976003 in XBMC live). If this sync issue is down to clock discrepancies (audio vs. video) then what might be the explanation of this relatively large difference between OS.

Also it seems that the same TrueHD files work ok in XBMC Live -ie they don't get the cycles of positive/negative discontinuity messages for the resulting PCM that I see in Windows.
Reply
#55
TheSwissKnife Wrote:How is it I don't see anything in the log for these video frame dup/drop events? I would expect on 23.976 movie with a refreshrate rate of around the same, that after the audio clock has made >41.7ish ms adjustments to see a message like the the "didn't consume" (or whatever it is) one that I have seen from time to time.

Are these not recorded?

Correct, recording those would make the logfile enormous.
Also there's no way of knowing if it was supposed to do that or not.
Reply
#56
bobo1on1 Wrote:Correct, recording those would make the logfile enormous.
Also there's no way of knowing if it was supposed to do that or not.

Why enormous? I would hope that drop/dup video due to audio resync would be very few. At least in the cases I have there would only be one or two. Perhaps a new debug level? This would be very useful to see for home debugging and also for reporting problems too.

Any comments on the other points?
Reply
#57
bobo1on1, can you please point me to the file/location in DVDPlayer source where the total audio discontiniuty correction is being tracked, so that after reaching a whole vblank cycle of discrepancy the video can be adjusted. I can't see it with my cursory glance through DVDPlayer.cpp, DVDPlayerVideo.cpp, DVDPlayerAudio.cpp it is not jumping out at me.
Reply
#58
Any clues anyone?
Reply
#59
It's in DVDPlayerAudio.cpp
Reply
#60
Thanks but I can't see where...I think I see the 10ms audio clock correction code but not anything that adjusts the video:

In CDVDPlayerAudio::HandleSyncError:

Code:
if (m_synctype == SYNC_DISCON && fabs(m_error) > DVD_MSEC_TO_TIME(10))
{
        m_pClock->Discontinuity(CLOCK_DISC_NORMAL, clock+m_error, 0);
        if(m_speed == DVD_PLAYSPEED_NORMAL)
          CLog::Log(LOGDEBUG, "CDVDPlayerAudio:: Discontinuity - was:%f, should be:%f, error:%f", clock, clock+m_error, m_error);
}
Reply
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 20

Logout Mark Read Team Forum Stats Members Help
Jerky playback Dharma B2 and SVN /Ion0