[bobo1on1]

You should check CXBMCRenderManager::WaitPresentTime, it takes the clock speed into account when calculating the error, so sync will only drift on a discontinuity or if the fps of the videofile is reported wrong.

[TheSwissKnife]

You should check CXBMCRenderManager::WaitPresentTime, it takes the clock speed into account when calculating the error, so sync will only drift on a discontinuity or if the fps of the videofile is reported wrong.

I already looked there - and that is what I based my suggestions on. I see that m_presentcorr is drifting when the file is perfect (direct from bluray disc m2ts decrypted copy). It seems you are suggesting I should not see the "sync:" value displayed moving at all in that case - but I do.

[bobo1on1]

If no discontinuities are happening, that means the fps for the file is reported incorrectly, and changing the refreshrate won't fix that.

[TheSwissKnife]

If no discontinuities are happening, that means the fps for the file is reported incorrectly, and changing the refreshrate won't fix that.

No discontinuities are happening in this case. Every 1min:18secs the sync: value drops by 1%. I think there must be something else going on then as I do not believe the files are a problem. They are 23.976 reported in mediainfo and I believe 24/1.001 actual.

Code:

129 int fps = g_VideoReferenceClock.GetRefreshRate();
...

139   double frametime = g_VideoReferenceClock.GetSpeed() / fps;
140
141   //the videoreferenceclock updates its clock on every vertical blank
142   //we want every frame's presenttime to end up in the middle of two vblanks
143   //if CDVDPlayerAudio is the master clock, we add a correction to the presenttime
144   if (ismaster)

139   double frametime = g_VideoReferenceClock.GetSpeed() / fps;
140
141   //the videoreferenceclock updates its clock on every vertical blank
142   //we want every frame's presenttime to end up in the middle of two vblanks
143   //if CDVDPlayerAudio is the master clock, we add a correction to the presenttime
144   if (ismaster)
145     presenttime += m_presentcorr * frametime;
146
147   double clock     = CDVDClock::WaitAbsoluteClock(presenttime * DVD_TIME_BASE) / DVD_TIME_BASE;
148   double target    = 0.5;
149   double error     = ( clock - presenttime ) / frametime - target;
150
151   m_presenterr     = error;
152
153   // correct error so it targets the closest vblank
154   error = wrap(error, 0.0 - target, 1.0 - target);

Which part can I trust as a start point? Is fps not based on the refreshrate? Which part is controlled by the source file fps? Though I thought I was, it seems I am not getting it all.

[bobo1on1]

In CDVDPlayerVideo::CalcFrameRate, check if there's a difference between framerate and m_fFrameRate, when frameduration != DVD_NOPTS_VALUE, if there is, try lowering MAXFRAMERATEDIFF.

[TheSwissKnife]

Well for that I assume I have to add some debug and re-compile. Since I have not attempted to self-compile for Windows I will have to switch to Linux for that.

[TheSwissKnife]

Just a heads up...I haven't given up but I think I made a bad choice and have been trying to dig myself out of it...I decided to build a fresh environment for this testing and I happened to go with Ubuntu 10.10 desktop + XBMC-trunk and am struggling with lots of problems (audio issues, the crap 260.xx NVidia drivers that come with it, RC buttons not working, crashing/hanging XBMC). I think I will give up on this now, and try to use Ubuntu 10.04 + XBMC-trunk instead but I will be another few days probably sorting that out. If anyone could suggest the safest platform for this testing (given that I am using Shuttle XS35GT with NG-ION GPU) before I start I will try that instead.

[jhsrennie]

Why not stick with Windows and use the free version of Visual Studio 2008?

JR

[TheSwissKnife]

I just thought I'd stick with what I knew - to avoid the set of issues I know I will hit going down a new path.

As it happens I have hit those anyway! I just tried Dharma beta3 LIVE install thinking I would perhaps build new versions inside that. Alas now I have the return of the black-flash-tear effect that I have seen before. The effect I would describe as a frame (or two) gets the bottom quarter of it look like a flash of black screen appear over it. It happens every so often (perhaps a minute or less) with files I am pretty sure are good and normally play perfectly - so I am not going to go down that path. I saw it also on Windows but after I upgrdaded the NVidia drivers the issue went. In this case I am on the 195.36.24 drivers that I remember being fine (eg with Dharma Beta 2) before. There is nothing in the log files when this occurs.

Has anyone seen this type of effect, and have any suggestions before I start again with Beta2 or go back to Windows?

EDIT: I even sometimes see the same effect when in the XBMC GUI - no movie playing at all.

EDIT2: After many tests and monitoring I think this issue is a PowerMizer one. It seems that when NVidia clock frequencies change due to the PowerMizer doing whatever it does this lower screen flicker occurs. There seems no clear pattern what makes it change in the first place. After weeks of pain with so many nvidia driver issues, all I can say is what a heap of junk these NVidia drivers are! This obviously happens in both the Windows and Linux drivers but seems more robust in the Windows ones as long as they are reasonably up-to-date. [None of the drivers do the color levels properly, Windows custom resolution management is broken in all versions I have tried to varying degrees]. The Linux ones are just pants (260.xx does not like to go to higher clock frequencies for video in the first place, 195.xx the oscillating problems I am seeing, 256.xx can't find for ubuntu). Anyone know how to force the highest clock frequencies permanently on for video? I tried the RegistryDWords config without any joy so far.

[bobo1on1]

Add this to the screen section in xorg.conf:

Code:

Option         "Coolbits" "1"

Then you can adjust the 2D and 3D clock frequencies in nvidia-settings, you probably want to set the 2D frequencies to the same values as the 3D frequencies.

[TheSwissKnife]

I had done that but I had my regdwords over multiple lines - ie not supported

Option "Coolbits" "1"
Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerLevel=0x1; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1; PowerMizerHardLevel=0x1 PowerMizerHardLevelAC=0x1;"

This works for 195.36.24 but not for 260.xx. I may try to force the frequencies themselves but when I last checked this the 2D frequency scalemax was super low. I assume VIDEO is 2D?

EDIT: 260.19.12 result attempting to force the 2D clock to 500,700 (the values that I expect the current clock to go to with VDPAU etc).

nvidia-settings -a [gpu:0]/GPU2DClockFreqs=500,700

The valid values for 'GPU2DClockFreqs' are in the ranges 33 - 270, 33 - 162
(inclusive).
'GPU2DClockFreqs' can use the following target types: X Screen, GPU.

[bobo1on1]

XBMC can be considered 3D.

[TheSwissKnife]

XBMC can be considered 3D.

Well 3D clock values are already 500,700, but current clock remains 405,405 whether XBMC is playing a video or not. Thus 260.xx linux drivers are crippled for VDPAU!

[TheSwissKnife]

In CDVDPlayerVideo::CalcFrameRate, check if there's a difference between framerate and m_fFrameRate, when frameduration != DVD_NOPTS_VALUE, if there is, try lowering MAXFRAMERATEDIFF.

This can't be the case since I never get any of the debug messages.

Code:

"framerate was:%f calculated: %f"

I am looking at the code now with Linux build (trunk) and I don't get the "sync" value drift that I get with Windows but I am happy to continue using this for understanding purposes for now. In my linux case with the refresh rate I am currently using my avgerror value converges down to -0.000003197 and stays exactly there. I know this value is small but I was wondering what it represents - is it just the unaccounted time taken to execute instructions eg in CDVDClock::WaitAbsoluteCLock?

[bobo1on1]

This can't be the case since I never get any of the debug messages.

Code:

"framerate was:%f calculated: %f"

Not necessarily, there can be a small difference between the reported fps and the calculated one, otherwise it would constantly recalculate it.

I am looking at the code now with Linux build (trunk) and I don't get the "sync" value drift that I get with Windows but I am happy to continue using this for understanding purposes for now. In my linux case with the refresh rate I am currently using my avgerror value converges down to -0.000003197 and stays exactly there. I know this value is small but I was wondering what it represents - is it just the unaccounted time taken to execute instructions eg in CDVDClock::WaitAbsoluteCLock?

It's the distance between the current video timestamp and the middle of the timestamps of the last two vertical blanks, it doesn't represent any elapsed time.