2010-10-18, 20:00
It adjusts the clock, video timing is referenced to that clock.
2010-10-19, 02:15
bobo1on1 Wrote:It adjusts the clock, video timing is referenced to that clock.
So I guess its the code that decides to dup/drop video I am asking about...I want to add something to debug the dup/dropped frames that are not logged. I still struggle to get consistency at present and adding debug may help avoid having to sit through hours at a time to collect enough information.
Also I can't quite workout what is expected to happen with interlaced material, when using sync to display. I tried a 59.94i m2ts file (or as mediainfo would describe it - 29.97fps interlaced) straight copy from bluray and had the refresh rate set at 59.94Hz, but I then get thousands of audio discontinuities of 10ms and video stutters all over the place.
2010-10-19, 14:38
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.
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.
2010-10-19, 16:34
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.
So it doesn't explicitly duplicate a video frame but the the current frame may get displayed for multiple cycles anyway - I think that is what you are saying. If so that is a shame - but c'est la vie. That would cover the situation where the audio clock is slower than the video built clock, and the measured audio discontinuities are negative. What about when it is the other way around and the only solution is to drop a video frame display cycle? Can that be seen anywhere?
2010-10-19, 17:56
It depends, if the render speed is limited by vsync it will show up as a framedrop, if it's not limited it won't show up at all.
2010-10-19, 21:07
But I am using vsync and I don't see anything recorded in the log when I reduce the refresh rate down enough to get 5 or 6 positive 10ms discontinuities (for 23.976p source and refresh). What you are describing should happen is what I would have expected.
EDIT: Not logged only counted for visibility in code info? m_iDroppedFrames? If so might I suggest a debug log message be added at some stage in the future, as it would make the logs so much more useful.
EDIT 2: I still remain very confused about HD interlaced material - as it seems to be treated as progressive in some respects. A 59.94 interlaced field source for example will be considered as 29.97fps, making it very unclear what XBMC thinks the ideal refresh rate should be. Of course it should be 59.94Hz (but interlaced of progressive I don't know). I don't get then how XBMC feeds the video fields to ffmpeg (DXVA/VDPAU) when using the clock built from vblank. How should this also interact with the auto refresh rate or the advancedsettings refreshrate override in trunk?
EDIT: Not logged only counted for visibility in code info? m_iDroppedFrames? If so might I suggest a debug log message be added at some stage in the future, as it would make the logs so much more useful.
EDIT 2: I still remain very confused about HD interlaced material - as it seems to be treated as progressive in some respects. A 59.94 interlaced field source for example will be considered as 29.97fps, making it very unclear what XBMC thinks the ideal refresh rate should be. Of course it should be 59.94Hz (but interlaced of progressive I don't know). I don't get then how XBMC feeds the video fields to ffmpeg (DXVA/VDPAU) when using the clock built from vblank. How should this also interact with the auto refresh rate or the advancedsettings refreshrate override in trunk?
2010-10-20, 23:55
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.
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.
2010-10-21, 00:55
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.
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?
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).
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?
2010-10-21, 12:52
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?
2010-10-21, 15:15
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.
Ok so I do understand correctly...but it would be easy to prevent too many messages with an extra counter that disables this debug logging when more than a certain number or frequency have been hit. After all, the audio discontinuities also produce "thousands" of messages when there is a problem.
Quote:Letting the tv deinterlace is currently not supported, you have to let XBMC do it.
Ok, I will go no further down this route, though I would suggest that it would be a good enhancement since display/receiver deinterlacers are probably better.
EDIT:
I just tested again...I got 20 +10ms audio discontinuity messages and not a single increase in the frame drop count on the codec info overlay screen. I guess this means that actually these are not detected either - lost in the renderer due to the display time being behind current time? Essentially there in no way currently to see that using the "vblank built" clock with the audio clock as master causes video dupes or video drops. Neither is there an easy way to see how much the audio clock and vblank rate are out of whack. I will keep studying the code to see if I can better understand (and perhaps contribute) but I am a on a steep learning curve and may lose the will at some stage and take the easy option...PCH :-(
2010-10-21, 19:25
And with which fps and refreshrate did you test? 
2010-10-21, 22:49
23.976fps source file. 23.975'ish refresh rate.
EDIT: The reason I keep testing is because I can't seem to get consistency and I don't know if XBMC is the reason or something else. I believe I change nothing at all (or more accurately I restore everything to the same state as far as I can tell), and one day I play a film and repeatedly get no audio discontinuity over 3 hours play and then next (with same film) I get discontinuities of (-)10ms every 30 mins, for example. Do the clocks on my system drift that much based on environmental conditions, or is XBMC measuring/adjusting incorrectly/inconsistently? I have conducted weeks worth of tests and each time I need to play the whole film due to the lack of debug. My target is to get a sync drift over 4 hours of play of around 10ms - I thought I was getting close but then I test a few days later and pull wha'ts left of my hair out. Hope that helps explain why I am asking all the stupid questions.
EDIT: The reason I keep testing is because I can't seem to get consistency and I don't know if XBMC is the reason or something else. I believe I change nothing at all (or more accurately I restore everything to the same state as far as I can tell), and one day I play a film and repeatedly get no audio discontinuity over 3 hours play and then next (with same film) I get discontinuities of (-)10ms every 30 mins, for example. Do the clocks on my system drift that much based on environmental conditions, or is XBMC measuring/adjusting incorrectly/inconsistently? I have conducted weeks worth of tests and each time I need to play the whole film due to the lack of debug. My target is to get a sync drift over 4 hours of play of around 10ms - I thought I was getting close but then I test a few days later and pull wha'ts left of my hair out. Hope that helps explain why I am asking all the stupid questions.
2010-10-22, 00:16
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.
It can also be the file itself.
2010-10-22, 03:02
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.
It can't be the file (in my case) since the file does not change.
2010-10-22, 12:17
Looking at the following code from VideoRenderers/RenderManager.cpp
I would say that a simple change to make (avgerror * 100) display to about 7d.p. would then make it much easier to see the real sync drift (or at least XBMC's view of it). 7d.p. I think should show how much the refresh rate needs to be adjusted to get almost perfect sync (at that time) - after correcting for what it is relative to (eg 24.00000 rather than 23.976024). Certainly with the current integer rounding it makes the "avg:" display not even close to showing the discrepancy of an assumed 24Hz refresh rate with a 23.976 real refresh rate (which I believe needs at 3-4d.p.). Note it might also make it clearer to those looking at this codec info that the "sync:" value is drifting because of this avgerror value which currently confusingly presents as zero.
Code:
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 }I would say that a simple change to make (avgerror * 100) display to about 7d.p. would then make it much easier to see the real sync drift (or at least XBMC's view of it). 7d.p. I think should show how much the refresh rate needs to be adjusted to get almost perfect sync (at that time) - after correcting for what it is relative to (eg 24.00000 rather than 23.976024). Certainly with the current integer rounding it makes the "avg:" display not even close to showing the discrepancy of an assumed 24Hz refresh rate with a 23.976 real refresh rate (which I believe needs at 3-4d.p.). Note it might also make it clearer to those looking at this codec info that the "sync:" value is drifting because of this avgerror value which currently confusingly presents as zero.
