[mythtv] Proof of concept: Chromakey OSD

[Bruce Markey]

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