[mythtv] Proof of concept: Chromakey OSD

[Daniel Kristjansson]

On Thu, 2005-03-24 at 00:15 -0500, Andy Poling wrote:
> The result of my experiment: an OSD for Xv and XvMC that is rendered (in full
> color) on the chromakey background instead of as an overlay.  Why Xv and XvMC?
> I use XvMC for HDTV, and I tend to transcode my normal captures to MPEG4, so
> I must use Xv to view them.  I also think those two display methods cover alot
> of people's needs...
> 
> In the process, I also decided to try removing the OSD processing from the
> timing-critical frame rendering code, and moved it instead into a low-priority
> NuppelVideoPlayer thread.  I think the results are pretty interesting.
Very cool, I'll try this out soon ;)

> I will admit that the code is a bit ugly here and there, primarily due to my
> desire to localize the impact of my changes as much as possible.  This
> prevented slicker integration here and there, but also made the changes
> relatively clean in terms of diff size and the number of files affected.  The
> one thing I found unfortunate was a namespace collision between libmyth and
> X11 with the "Visual" class.  I'm not all that proud of the re-naming hack I
> perpetrated to resolve that conflict.  :-)
I have a patch somewhere which fixes this namespace collision, basically it
just wraps MythTV's Visual in a MythTV namespace.

> Mostly it removes some sections of code that release a mutex at what
> turned out to be a bad time.  
I'll look at this.

> It also removes the second frame vertical offset fiddling since I'm convinced
> that XvMC is already doing that... and the results seemt o confirm my belief.
Actually, I found the problem when working on XvMC a couple weeks ago, the problem
is that negative offsets in XVideo aren't handled consistently, so any
Zoom mode that sends part of the video off-screen runs into problems,
specifically with the offset twiddling the bobbing gets twice as bad
instead of getting better. Unfortunately, I made the fix in a patch that
has other problems and that will conflict with your patch. I'll see if
I can get that working after I make the latest ./configure updates.

> 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.
You should have Doug look at this, he's the vsync expert.

-- Daniel