[gstreamer-bugs] [Bug 310775] libvisual element needs to support opengl

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=310775
 GStreamer | gst-plugins-base | Ver: HEAD CVS


Jonathan Matthew changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathan at kaolin.wh9.net




------- Comment #4 from Jonathan Matthew  2006-05-08 14:08 UTC -------
I've implemented support for opengl libvisual visualisations using the
following hackery:

- added a 'glcontext' interface that gl-based sinks can implement to allow
other elements (and maybe applications) to request that they make their gl
context current in the calling thread.  I thought this was better than passing
the context back from the sink to the rendering element and (eventually) having
#ifdefs everywhere for calls to glXMakeCurrent, wglMakeCurrent, etc.

- added a new content type, video/x-opengl-texture-id to glimagesink's caps.
Buffers with this content type contain only an opengl texture id that the sink
is to use to draw the frame.  Hypothetical intermediate elements
(gltextoverlay?) could also draw on the pbuffer.

- created a variant of the libvisual plugin (I intend to merge the code back in
at some point, but haven't gotten around to it yet) that creates a framebuffer
(using GL_EXT_framebuffer_object) and convinces libvisual to render into it. 
For each frame, it then pushes a video/x-opengl-texture-id buffer containing
the framebuffer's texture id.

This all seems to work fairly well, but it's a bit ugly in places, particularly
how video/x-opengl-texture-id buffers are handled.  I've tested all the
gl-based visualisations that come with libvisual (but not projectM, as far as I
recall).  

I haven't looked in to getting playbin to handle it properly (not trying to run
the vis plugin output through ffmpegcolorspace, for a start).  It'd be nice to
get it to automatically construct a gl-capable video sink if the vis plugin has
video/x-opengl-texture-id caps, but I'd be happy enough if it required the
application to do that for itself.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.