GNOME Bugzilla – Bug 310696
Milkdrop Audio Visualazations
Last modified: 2005-08-29 15:42:54 UTC
Since milkdrop has been opensourced, projectM has ported it to linux. ProjectM is a milkdrop plugin for XMMS. Instead of the mediocore goom/osscope visulations or reinventing the wheel, GNOME could use a previous masterpeice in their projects. The website is: http://xmms-projectm.sourceforge.net/ What are thoughts on porting this to Totem?
It seems to be using OpenGL directly, which is a no-no for the xine-lib backend, and probably hard to integrate in GStreamer. I'll let the GStreamer people handle this, if they fancy.
GStreamer will have options for this in 0.9, but it'll be hard. Benjamin had a look at the code and didn't turn happy. :).
They claim they "support libvisual". In reality they're not very well integrated, never rendering into libvisual's buffers (instead rendering to their own glcontext). In 0.9 you could make a subclass of GstBuffer for GL contexts. Then you could have a glsink as your output, and have the buffer_alloc return GL contexts or something. Dunno. It also appears that you can dump out a GL context into pixels, meaning we could hook this thing up to output normal video frames for rendering to normal video sinks. The code does not make me happy either. Their tarball has CVS dirs and backup files. Also, it seems they don't use a public CVS. Their SF CVS is worthless, not updated. So it's a tarball-only thing. Totally agree that goom blows nuts and that we deserve better. However relying on projects that don't maintain themselves well is not a plan. Conclusion: Better to push patches upstream to get them to render into libvisual's buffers and to use the existing libvisual gstreamer plugins (and start deprecating goom).
Libvisual can tell what depth the output is; if it's GL, the plugin renders to a GL context. Proper fix is for our libvisual element to notice this, create a gl context, and grab the pixels out. Proper proper fix is to have GL buffers passing gl contexts in the pipeline. Word to your mother.
If the projectM code is unmanageable, it may be easier to use the MilkDrop source code directly: http://www.nullsoft.com/free/milkdrop/ I haven't looked at any code for either. But I'm still feeling that ProjectM would be easier, as the milkdrop code depends on DirectX.
They already support libvisual. The problem is only to get libvisual's GL output back into GStreamer, which is the real bug. No projectM-specific plugin should be made, since the libvisual one already exists.
Andy, they *cannot* render into a libvis buffer. That's the whole point of being GL'ified. I've talked to Dennis (from libvis) about this, and we need to supply a GL context in a subclass, from a glsink. This will never work with a xvimagesink, ever. How to make it integrate well? I don't know yet. That's our problem, not theirs.
Dude, problem solved: we give it a GL context and read out the pixels. We give it a GL context whenever libvisual returns DEPTH_GL. No problemo.
Filed new bug that describes the problem better, marking this as a dup. *** This bug has been marked as a duplicate of 310775 ***
Reading pixels out of OpenGL is often slower than rendering OpenGL using paper and pencil. It's basically a requirement to be able to negotiate OpenGL contexts for anything interesting. The best solution currently is probably to make a projectmsink, which would do both vis and output.