2010-10-18, 20:00
It adjusts the clock, video timing is referenced to that clock.
bobo1on1 Wrote:It adjusts the clock, video timing is referenced to that clock.
bobo1on1 Wrote:You can check CDVDPlayerVideo::OutputPicture in DVDPlayerVideo.cpp, at the bottom of that function, g_renderManager.FlipPage is called, the second argument is the time that the frame should be displayed.
In RenderManager.cpp in the function CXBMCRenderManager::WaitPresentTime, the render thread waits for the presenttime for the current frame.
The problem here is, it doesn't explicitly decide to drop/dupe a frame, it just waits for the presenttime to pass.
bobo1on1 Wrote:It will take at least 40 ms worth of discontinuities before you get a framedrop, and the discontinuities have to be positive.
Logging framedrops would fill the log to a ridiculously large size, and make it completely unreadable.
Deinterlacing with opengl isn't handled correctly at the moment, dvdplayer outputs a frame, the renderer will deinterlace that and show it as two fields, so currently you can't use 30 hertz for 30 fps material and 60 hertz for 60 fields per second interlaced material.
Deinterlacing with vdpau is fine, since vdpau will make a frame for each field.
TheSwissKnife Wrote:I wait for much more than 40ms of discontinuity, and yes I agree positive discontinuities. But I don't see why the logging would generate so many - in my case one or two after initial stream start. If so many frames are dropped during normal play mode then surely it must be unwatchable?If there's a problem, it's possible that it drops hundreds of frames per minute, and then it is unwatchable, if you log every framedrop the logfile will be unreadable, and figuring out the problem will be difficult.
Quote:I tried setting up interlaced 59.94 refresh rate with DXVA for 1080i59.94 source - it was much better but not quite right still (in line with your comments). Now I am not sure whether to continue with the Windows incarnation ~(which seems to have slightly better audio support and DXVA handles much higher FPS than VDPAU).Letting the tv deinterlace is currently not supported, you have to let XBMC do it.
You say VDPAU will make a frame for each field - do you mean it will deinterlace it - if so is there any way to NOT do that and let display deinterlace it? Or are you saying that to all intensive purposes there is (currently) no point in interlaced refresh rates for XBMC?
bobo1on1 Wrote:If there's a problem, it's possible that it drops hundreds of frames per minute, and then it is unwatchable, if you log every framedrop the logfile will be unreadable, and figuring out the problem will be difficult.
Quote:Letting the tv deinterlace is currently not supported, you have to let XBMC do it.
bobo1on1 Wrote:10 ms over 30 minutes is a drift of 1/180000, I guess that could be clock drift due to temperature changes, cosmic rays etc.
It can also be the file itself.
194 CStdString CXBMCRenderManager::GetVSyncState()
195 {
196 double avgerror = 0.0;
197 for (int i = 0; i < ERRORBUFFSIZE; i++)
198 avgerror += m_errorbuff[i];
199 avgerror /= ERRORBUFFSIZE;
200
201 CStdString state;
202 state.Format("sync:%+3d%% avg:%3d%% error:%2d%%"
203 , MathUtils::round_int(m_presentcorr * 100)
204 , MathUtils::round_int(avgerror * 100)
205 , abs(MathUtils::round_int(m_presenterr * 100)));
206 return state;
207 }