[mythtv] Proof of concept: Chromakey OSD

[Andy Poling]

I've been struggling for some time with HDTV viewing and XvMC.  There has been
a great deal of fundamental progress on XvMC, but I still felt we were hitting
a wall of sorts in terms of what we could do with the current approach.  So I
got myself motivated and decided to try a radical approach to solving the
problem.  I was inspired in particular by the comments and work of Daniel
Kristiansson and Ivor Hewitt.  Daniel mentioned last Fall the possibility of
taking advantage of the chromakey background, and Ivor presented the IA44 OSD
rendering late last year.

The problem, as I see it, is that rendering and blending the OSD takes too
much time during what turns out to be very time-sensitive code when viewing
high-resolution HDTV content.  The OSD processing is basically preventing us
from completing the rendering work in the time the framerate gives us.

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.

In my case (using the nvidia graphics built into my nforce2 chipset, which is
probably on the slow end of the spectrum due to it's lack of local video
memory), I can now watch 1080i HDTV content with nary a glitch.  That's huge
progress from where I was.

You can find it at:

	http://realbig.com/mythtv_hdtv/

There's a good bit of commentary there (that I won't repeat here) about the
pros and cons of the chromakey OSD as I see them.

This is intended as a proof of concept only at this point.  As I mention on
that web page, there is plenty of room for improvement - especially in terms
of CPU use.  If there are some adventuresome folks out there who are trying
and failing to watch HDTV using XvMC, feel free to try it and let me know how
well it works for you.  In particular, I'd be interested to know if it works
at all well when using viachrome graphics instead of nvidia.

Given the gnashing of teeth on this list lately, this sort of relatively
radical work may not be welcome by all.  I hope that it will be taken in the
spirit that it's given: as a stimulant to discussion, and an interesting
experiment.

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.  :-)

Anyway, if anyone tries it, I'd be interested in your feedback.  If anyone
finds this an interesting idea, I'd love to discuss it with you.

There's also a relatively small patch at the top of that page that is
technically separate from the chromakey OSD work, but was critical in my
progress from XvMC that crashed often to rock solid (but slightly slower) XvMC
support.  

Mostly it removes some sections of code that release a mutex at what
turned out to be a bad time.  

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.

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.

-Andy