[mythtv] Proof of concept: Chromakey OSD
Bruce Markey
bjm at lvcm.com
Thu Mar 24 22:42:54 UTC 2005
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
More information about the mythtv-dev
mailing list