Geoffrey Kruse <[EMAIL PROTECTED]> 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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
