Posts: 325
Joined: Sep 2010
Reputation:
17
2010-10-06, 16:25
(This post was last modified: 2010-10-06, 23:44 by TheSwissKnife.)
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.
Posts: 325
Joined: Sep 2010
Reputation:
17
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?
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
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.
Posts: 325
Joined: Sep 2010
Reputation:
17
2010-10-08, 21:47
(This post was last modified: 2010-10-08, 22:16 by TheSwissKnife.)
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.
Posts: 325
Joined: Sep 2010
Reputation:
17
2010-10-09, 02:42
(This post was last modified: 2010-10-09, 14:07 by TheSwissKnife.)
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?
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
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.
Posts: 325
Joined: Sep 2010
Reputation:
17
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.
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
It's in DVDPlayerAudio.cpp