[mythtv] Proof of concept: Chromakey OSD

[Andy Poling]

On Thu, 24 Mar 2005, Bruce Markey wrote:
> 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.

OK - this is good because it helps me better understand what you're trying to
do.

Here's my understanding of what's going on here.  m_nexttrigger is designed to
(once things have stabilized) indicate the time when we would have to begin to
Show in order to complete rendering before the frame is to be retraced.  Am I
right on this so far?

Here's what I (thought I) saw happening.  When playing high-res video (think
1080i), we are ordinarily just barely able to complete PrepareFrame in time to
beat nexttrigger.  When we take a little bit longer, like when the scheduler
gave some of our precious CPU time (note, it's not the amount of CPU we need,
but that we need it with little-to-no scheduling latency) to something else
(like, say, the chromakey OSD rendering :-)), we may arrive at WaitForFrame
just at nexttrigger, or *just* after it.  Believe me, when we're desperately
trying to keep up with rendering 1080i, this is not an uncommon occurrance in
my experience.  :-)

As the code stands now, WaitForFrame would then force us to wait an entire
frame.  This caused two apparent visible problems (to my eye): 

1) the interlaced frames get inverted (are now out of order) if we wait one
   retrace interval

2) a visible and audible pause in playback, accompanied by a complaint from
   the decoding code about a "prebuffering pause".

Maybe I'm mis-understanding something fundamental, but the logic behind my
change was this: if we arrive just after m_nexttrigger, it's impossible that
we're early.  After all m_nexttrigger was calculated for _this_ frame's
timing.  m_nexttrigger would have had to be an entire frame's worth of time
mis-calculated early in order for us to be able to miss m_nexttrigger and
still be early.  If that assumption is valid, then it seems that your
less-than-half-late wait will always result in a delay even greater than we
already stumbled into.  On the other hand, my admitedly optimistic :-)
alternative basically hopes that we will still be able to complete the Show
before the frame is to be shown (or at least ahead of the retrace itself).  In
my empirical experiments, that did indeed seem to be the result.

I think perhaps what we have here is one strategy aimed at a system assumed to
be mostly loafing, and another strategy aimed at a system assumed to be
struggling to keep up.

Let me also re-iterate that it seems to not be a matter of CPU time available
that makes us late in this situation.  Rather, it seems to simply be
scheduling latency combined with GPU/XvMC latency.  When this is happening, my
cpu (Sempron 2800) is 50+% idle.

-Andy