On 11-07-23 08:17 AM, Dirk Meyer wrote: > Patching mplayer is bad Which is listed as a con. But I wouldn't say "it's bad" should be the final word. It's a trade-off, and has advantages over other options.
> 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! An out-of-process display engine, specifically. Incorporating MPlayer into a display engine wouldn't be "rewriting too much of MPlayer" -- at least not necessarily. It would entail modifying vo_gl2 and vo_vdpau based on our needs. It's almost tempting to try hacking up a PoC. Spawn MPlayer's mainloop in another thread, and add some thread synchronization stuff to vo_gl2 when updating textures controlled by clutter in the main thread. Anyway, I'm skeptical about gstreamer. Every time I try it I'm disappointed. >> 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? For normal fullscreen video mode, use VDPAU exclusively, and don't use GL at all. VDPAU and GL contexts are separate things. VDPAU provides a presentation queue that allows for multiple frames to be queued in the GPU and precisely timed. The alternative is more like page flipping, which is essentially like having a queue of one in the GPU, which means it's possible you could miss a retrace and delay frame delivery, resulting in stutter. (Though I suppose you could use multiple textures, and upload the next frames to the other textures while waiting for the next retrace. It's not something I tried in my earlier tinkering.) VDPAU also provides a way to do overlay, by manipulating a VdpBitmapSurface, which is mixed with the VdpVideoSurface and queued for presentation. One problem here is I'm not entirely sure how to draw the OSD bitmap with clutter. Unlike Evas, I don't know that clutter has an offscreen, raw bitmap backend. So the most integrated solution is the 3rd option in my earlier list: use GL_NV_vdpau_interop to render video frames to a GL texture, and do the frame timing manually (e.g. by using glXWaitVideoSyncSGI to wait for the right retrace). Then you're pure GL, the video is an object on the stage, and OSD is managed through clutter, like the rest of the GUI. I just need to find out if GL_NV_vdpau_interop solves the problem that texture_from_pixmap has, which is stuttering with anything higher than 1080p24, and especially when deinterlacing 1080i30. > Good idea. But how to get mplayer into this? Again: gstreamer? Described above. :) > If we use kaa.rpc, it can not. Yes, we would have to come up with a Python-C bridge for kaa.rpc, or a custom RPC protocol that would be easier to work with from C. This isn't too hard to do, conceptually. There might already be options out there. Google seems to have something that might work called Protocol Buffers. Our use-case isn't too complicated, so it might even be easier to roll our own (NIH). Jason. ------------------------------------------------------------------------------ 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
