[mythtv] XVMC Change Feedback --Revision 7519

Andy Poling andy at realbig.com
Sat Oct 22 02:23:02 UTC 2005


Geoffrey Kruse <gkruse at gmail.com> said:
> I think if there was
> any way to free up that last surface, those of us on slow machines with
> xvmc would be golden. (Chroma Key OSd anyone) Just thought I would give
> some feedback on what I noticed with this change.

<cough> That would be me...

I have recently picked back up the ball I totally dropped (sorry - my bad) a
while back with the COSD.  I pulled a SVN about a week ago, and I've been
re-integrating my changes to implement the COSD.

At the moment, the COSD is mostly working, but I've gotten something wrong so
that it is crashing when we leave playback.

What my patch does is to essentially permanently neuter the Xv and XvMC
playback code of any OSD processing and handling, while establishing a
separate thread that does nothing but handle painting the COSD on the
background window.

This is not what Daniel and others wanted - they wanted a more tightly
integrated COSD that could be enabled and disabled at runtime, preferably
depending upon the content type being played.  I took a couple of runs at it,
but (not surprisingly) it really ratcheted up the complexity of the COSD
integration, and while stalled on that I got distracted by some other things.

What I can do is get the patch in working order again.  Maybe then someone
who is more familiar with the mythtv internals can take the next step and
integrate it tightly enough to be acceptable for inclusion.

Here's the fundamental problem I ran into...  

The reason the COSD works is that it is not tightly integrated with video
playback.  It avoids having to do OSD evaluation for every single frame
(that's what makes the alpha-blended OSD problematic).  The problem I never
overcame is how to integrate the COSD tightly enough to have it be as slick as
some folks want it to be while simultaneously being not integrated so that it
does not impact playback performance.

To make matters more complicated, since the OSD is built and maintained as an
yuv surface, and the COSD must be an rgb pix/image, the OSD muct be converted
from yuv to rgb.  That's an expensive operation.  That's acceptable as I've
implemented it because I only have to do the conversion when the OSD content
changes (when surface->Changed() is true).  That doesn't actually happen very
often, so the expense of the yuv-to-rgb conversion is amortized over time, and
the separate thread lets the system scheduler allocate cpu time to it
piecemeal as it's available.

Anyway, I had no intention of being this long-winded.  I'll give a shout when
I have a working patch, and then I guess we'll see if someone else can find a
clever solution to the tight/loose integration problem.  I dunno... maybe it
can't really be solved until we're using mythui?

-Andy


More information about the mythtv-dev mailing list