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