Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
Auto will choose bilinear for HD and lanczos3 optimized for SD, so that would explain it.
Posts: 325
Joined: Sep 2010
Reputation:
17
Ok thanks I think understand. So this mode plays around with the audio as best it can to match the vsync it sees from graphics card.
Without this option but with VSync enabled I assume it should therefore never adjust the audio (drop/dup audio packets or adjust audio clock)?
I am noticing that in this simple Vsync enabled mode, the a/v value in the codec info screen might give a clue to the discrepancy between the audio clock and the VSync rate (refreshrate) as it drifts. I see XBMC letting it drift up to about 10ms before correcting it somehow - the question here is then what is the somehow? The starting min and max seems dependant on the audio setup eg in Windows the DirectSound HDMI mode gives different values that the WASAPI HDMI mode.
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
When using the audio clock sync method, dvdplayer checks the difference between the clock and the audio stream, if the difference is more than 10 ms, it sets the clock to the time of the playing audio stream.
The video stream is referenced to the same clock, that's how audio and video are synchronized.
Posts: 325
Joined: Sep 2010
Reputation:
17
That is not what I observe. If I don't set the "sync to display" option I see the behaviour you just described, and DEBUG log mentions the audio discontinuity of 10000.xxxx etc, without mention that it is setting the clock back/forward. This is why I was asking as can't quite get what is the difference between the setup of:
VSync enabled, "sync to display" disabled
VSync enabled "sync to display" enabled, "Audio clock" adjustment
at least in the case where the fps is very close to the refresh rate.
They "seem" to be virtually the same. I assume both never drop audio packets? Does the former ever drop/dup video frames?
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
The difference is, with sync playback to display enabled, the vertical blank is used as the clock, instead of the system clock, but this won't help anything if you still get a lot of discontinuity errors, becaus eventually some videoframes will be shown too early or too late anyway.
The drop/drupe and resample sync methods solve that.
Posts: 325
Joined: Sep 2010
Reputation:
17
It seems you are saying that without the sync to display video frames will inevitably be dropped/duped if system clock does not match video refreshrate for the frame times (and this is independant of the audio) - did I get that right? But then for the audio without "sync playback to display" there are no options to tell xbmc how to deal with discrepancies (drop/dup audio, adjust audio clock) - what decisions does/can it make? This is not clear at all to me at least. When I see the audio discontinuity debug message - does that actually tell us what xbmc has done to workaround this (clock adjust or dup/drop etc)?
As for with the sync to display mode, it seems resample audio isn't much use because of the passthrough case, but the other two cases are possible, but I don't see how to decide when it be better to drop/dup packets instead of adjusting clock - what do you need to look for to see that the better audio clock method is not coping?
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
During playback, press 'o' and look at the sync value, you want that to remain stable.
You could also look at the interval between discontinuities in the xbmc debug log, or the interval between packet drops/dupes when using the drop/dupe sync method.