Andy Poling wrote:
It also has a small change to OpenGLVideoSync::WaitForFrame in vsync.cpp that prevents what I think is an aggravation of an already late situation. Instead of forcing us to wait an entire frame if we're late, I don't wait at all. I'm not certain the full impact of this, but it did help eliminate the prebuffer pauses.
+ + /* if we're already late, don't wait */
+ if (m_delay <= 0)
+ return;
+
With retrace info, we target the next retrace after the trigger. We're not necessarily late just because delay passed 0. Returning ASAP can result in frame updating early. In fact, a few lines later we have a subtle but important fix to handle this situation. See: http://mythtv.org/pipermail/mythtv-commits/2004-September/004234.html http://cvs.mythtv.org/cgi-bin/viewcvs.cgi/mythtv/libs/libmythtv/vsync.cpp?sortby=file&r2=1.6&r1=1.5
Normally, prepareframe has finished it's business well before delay reaches 0 and none of this is an issue. However, if there were other processes running or disk O/I to wait for or whatever, we sometimes may not reach this point until after zero.
retrace A-v delay=0-v retrace B-v retrace C-v ------------------------------------------------------------------ prepareframe--^wait-------------------^ # This would be normal =). prepareframe-------------^ASAP^ # Opps! early prepareframe-------------^wait--------^ # Good prepareframe------------------------------------^ASAP^ # Bail!
// Always sync to the next retrace except when we are very late. if (m_delay > -(m_refresh_interval/2))
"Very late" is deliberate here. If we're less than half of a refresh interval after 0, it is more probable that we are still ahead of the target retrace and should wait for it. Even if the retrace was shortly after 0 and we did miss it, we've already missed our turn anyway.
If it has been more than half of a refresh interval after 0 (more than half could be 3X), it is most probable that we've already missed and need to bail ASAP. If it is more than half a refresh and the next refresh hasn't hit yet, it can't be that much later so we can't be very early and may not cause a glitch at all in this rare circumstance.
As for prebuffer pauses, I have to assume that it would be more a matter of coincidence than this being a cause. If the system is having trouble keeping up with I/O or CPU, that could cause both prebuffering pauses while waiting for new frames to decode and would cause preparing frames for display to be late at the same time.
-- bjm _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
