Hi On 26.07.2011 01:24, Jason Tackaberry wrote: > 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.
That does not require the display engine to be written in C. In fact, I started some testing code with an external app. The mplayer stuff could just be in a C thread started from within Python. Clutter and gstreamer do the same. I would like to keep the display server in python. > Anyway, I'm skeptical about gstreamer. Every time I try it I'm > disappointed. I did not try it for a long time. I guess I will give it the next chance when integrating some basic video playback code to the candy2 branch. >>> 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. Stupid question (I know, you use VDPAU): what about VA-API? It has VPDAU support and using it would give us hardware support for non-NVidia, too. Anyway, do we need a GL context? As nice as it is to have the video in the background, do we need it? It is a nice eye candy without real use. Write on top of the video is what we need. > 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. Not backend, but maybe ClutterOffscreenEffect could help as example. > 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. OK. I guess the best way is to try this option first. Are you motivated (and have time) to play with it? Dischi -- Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett) ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
