Hi, splitted from Jason's post:
On 21.07.2011 03:57, Jason Tackaberry wrote: > On 11-07-17 05:47 AM, Dirk Meyer wrote: >> 8. kaa.popcorn (or video player) needs clutter support to write on >> a texture. This would enable us to draw on top of the video and put >> it on the background. Again: help needed here. we could either put >> the mplayer output on a texture or use gstreamer. Jason played with >> the first option but the code is not finished yet. Jason: do you >> think you can finish it? > > This is a big piece. It's the piece that has given me a huge amount > of grief because of the fact that we're *really* trying to have a > multi-process architecture. > > In working on this a couple years back, I hit a wall. The most > elegant design was to use GLX_EXT_texture_from_pixmap to redirect an > out-of-process pixmap rendered by MPlayer (or whatever player) to a > local GL texture that we could manipulate. Even if all you wanted > to do was slap it onto the screen unmodified, this provided the > foundation to doing nice custom OSD as well. > > This worked great for Xv, so it could be used for Xine with DVDs. > With VDPAU, we could get away with it at 24p. But higher framerates > started to tax the GPU too much, resulting in dropped frames. And > forget about deinterlacing. Too bad. > This is bad news for our goals of using stock MPlayer as a separate > process. Near as I can tell, we have something like four options: > > 1. Only redirect video to a GL texture when we need to do something > with it, like do on-screen display or play it in a thumbnail while > the user navigates the menus. * Pro: we can keep the player > out-of-process and no custom patches needed * Con: noticeable > glitching (a flicker caused by starting the redirection and raising > the Freevo window over the MPlayer VDPAU window) even when doing > something like displaying a simple OSD to show current time or > whatever. I do not like this > 2. Patch MPlayer to allow Freevo to control the contents of the > VdpBitmapSurface used for the OSD, but redirect video to GL texture > when we want to display the video in a thumbnail (or background) > during menu navigation * Pro: we can keep the player out-of-process > * Pro: smooth, glitch-free OSD * Con: requires custom patches and > custom installation of MPlayer * Con: glitch when dropping to > thumbnail mode Patching mplayer is bad > 3. Fuse the video player and the display engine (clutter) into a > single process, and use GL_NV_vdpau_interop to get the video into a > texture to be rendered by clutter * Pro: most flexible, glitch-free > solution * Con: we're basically forking MPlayer at this point * Con: > if player crashes, so does Freevo [but I have an idea about this, see > later] * Con: requires implementing frame timing logic (not using > MPlayer for that anymore) I like the idea of a display engine. A redesign of kaa.candy should take this into account. But rewriting too much of mplayer ... no, bad idea. Why not use what we have? gstreamer! > 4. Like 3, except use VdpBitmapSurface for OSD, and > GL_NV_vdpau_interop (or maybe just straight texture_from_pixmap) > when dropping to menu/thumbnail mode * I think this is what XBMC does > * Pro: still leverages nice timestamp-based display of VDPAU's > presentation queue * Con: forking MPlayer * Con: minor glitch when > dropping to menu mode; this is less than the glitch in #2 because > there's no need to remap/raise/lower and X11 windows Can you give me more details? > If we do merge the video player into the display process (like XBMC) > -- and in fact I think we should do what I'm about to describe > /anyway/ -- we should decouple the display from the main process. The > main process can talk to the display process (which runs clutter plus > the player) via RPC, and always maintain the scene graph and all > state needed so that it can replay it at any time if the display > process crashes. If the display crashes, the main process can > restart it and immediately get the GUI back to the exact state it > was in before (although if a video was playing, it may end up seeking > to a slightly different position). Good idea. But how to get mplayer into this? Again: gstreamer? > This is a new architecture for Freevo, but I like it, because one of > the things I found annoying about XBMC was when it crashed, it was > quite disruptive. Also, it means the nasty, temperamental C bits get > stuffed into the display process that's allowed to crash, all the > stable, robust Python bits are in the main process, which is expected > to be long-lived. The display process could as well be written > purely in C. If we use kaa.rpc, it can not. Dischi -- Save time... see it my way. ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
