After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310696 - Milkdrop Audio Visualazations
Milkdrop Audio Visualazations
Status: RESOLVED DUPLICATE of bug 310775
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-18 04:00 UTC by Lukas Sabota
Modified: 2005-08-29 15:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lukas Sabota 2005-07-18 04:00:28 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?
Comment 1 Bastien Nocera 2005-07-18 06:56:21 UTC
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.
Comment 2 Ronald Bultje 2005-07-18 07:28:13 UTC
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. :).
Comment 3 Andy Wingo 2005-07-18 12:45:28 UTC
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).
Comment 4 Andy Wingo 2005-07-18 13:31:58 UTC
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.
Comment 5 Lukas Sabota 2005-07-18 13:44:08 UTC
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.
Comment 6 Andy Wingo 2005-07-18 13:55:31 UTC
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.
Comment 7 Ronald Bultje 2005-07-18 15:30:24 UTC
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.
Comment 8 Andy Wingo 2005-07-18 15:52:23 UTC
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.
Comment 9 Andy Wingo 2005-07-18 16:10:06 UTC
Filed new bug that describes the problem better, marking this as a dup.

*** This bug has been marked as a duplicate of 310775 ***
Comment 10 David Schleef 2005-07-18 22:13:31 UTC
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.