The Full Story on GStreamer

JigSaw writes "Gnome's Christian Schaller has written an intro/status document on GStreamer, the next generation multimedia development framework for Unix. Christian explains what it is, why it is important, its use in both the desktop and server side, its use on embedded Linux, Gnome and even KDE. He also discusses its current competition and the plans for the future."

GStreamer is a very useful framework

[Anonymous Coward]

That was a good reading. I hope Rhythmbox and Totem will be included on Gnome 2.8 at least when GStreamer 0.8 is out and more mature.

The BeOS had the Media Kit and it was great, allowed for cool stuff easily done on apps. Check Cortex for example: http://www.bebits.com/search?search=cortex [bebits.com] and its surrounded plugins.

I'd settle for . .

[Leroy_Brown242]

Video playback I could resize on the fly!
Call me lazy, but I hate putting in all those switches for mplayer.

Server or Client audio?

[vanyel]

The article wasn't clear if Gstream addresses this problem, but one of the things I've been looking for is X-server based audio. I have a variety of types of systems and try to run or two desktops. Since Windows and Mac won't remote natively, they're the ones I'm currently stuck with, and my unix systems, being capable of it, are off in another room somewhere and I get to them using a local X-server or ssh. But that means no Unix multimedia, because no audio.

Breaking news

[Anonymous Coward]

Multimedia on Linux, Film At 11.

And here I believed the rabid zealots that told me in no uncertain terms that Linux was a viable multimedia platform... 3 years ago. 3 years ago Linux wouldn't detect most soundcards.

OT really, but you guys should think more before blathering it up in the trenches. Coming back with a zany "we have that, fucker" and pointing people to a page for a project maintained by a kid in Romania barely out of alpha that's been abandoned for 2 years as an alternative to a mature, stable commercial application is not my idea of "we have that". The computer is not just a browser, office suite and MP3 player.

100% CPU Usage

[Anonymous Coward]

My experience with GStreamer on RedHat v9 with Gnome has got me annoyed. Nautilus uses GStreamer to make the thumbnails and when browsing directories I'll often see GKrellM screaming about 100% CPU usage. A quick 'top' almost always reveals the culprit as gst-thumbnail.

One of my terminal windows looks this:
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail
killall gst-thumbnail

KDE has a runaway process killer. Why doesnt gnome?

Nice.

[Bluesman]

This really has come a long way from when I checked it out a while back.

It's a fantastic idea, although it's been around for a while. But being able to apply different filters to an audio stream is really cool. It's unix pipes for audio.

What would be great is if gnome standardized a bunch of filters like this for everything. Imagine being able to apply a tar and then a gzip filter in this manner. Or perhaps a .doc decode filter and a grep, then to a .csv. All file conversion could be handled by the environment, rather than individual programs, which is messy and inconsistent.

Gstreamer is a big step in the right direction. Way to go guys.

GSteamer and MPLayer

[JarekC]

Recently I read a short but interesting discussion [gnome.org] of GStreamer in context of MPlayer, triggered by an announcement of a bonobo component wrapping MPlayer.

I wonder what will happen when MPlayerG2 comes out from an incubator. Will the two projects simply compete, or will they work out some way to integrate/support each other?

Re:Hmm...

[CoolVibe]

Ever saw artsbuilder? Arts (despised and misunderstood by many) also is more than meets the eye.

You can plug in modules, and synthesise any sound you like though plugins and modules, not unlike the pipeline editor in gstreamer.

GStreamer summarized

[Jeffrey Baker]

I think gstreamer is a cute hack, but it is also *exactly* what Chris Pirazzi warned against in his "Video I/O on Linux: Lessons Learned from SGI" [lurkertech.com].

One can build fancy mechanisms which have network transparency, compression/decompression, format conversion, graph-based dataflow management, etc. on top of a well-designed video I/O API, and such mechanisms might be useful for some applications. But SGI's big mistake--one which hampered development of useful audio/video applications for years--was to try to build and offer those fancier mechanisms to developers instead of offering a simple API that worked on multiple video devices.

Substitute audio for video when necessary.

pipe dream?

[Doc Ruby]

"GStreamer is that of a pipeline system which your media streams through"

Linux programs are filters in pipelines with data streaming through them. GStreamer is a special case for media. "Programming" GStreamer is executed through a pipeline viewer, a flowchart for GStreamer components. How about a general purpose flowchart programing tool for Linux?

Perl, for example, is internally compiled into a graph of primitives. How about a program that parses Perl into graphs, enforces Perl graph grammar in a GUI, and reconstitutes Perl code for saving? The three tier form has Perl code for data, Perl graphs in the "business", and flowcharts as presentation. Is there such a thing? For Python? Ruby (hint ;)?

Re:Hmm...

[egreB]

Since I don't know a whole lot about kernels, that sounded like a good idea to me. But isn't OSS and ALSA at least partly kernel-driven? Sound drivers are in the kernel, and I would think /dev/mixer is a kernel-thingy. Is the mixing done in userland? Is this supported by hardware mixers? Are there any arguments against doing it in kernel? Could it be done in a nasty hack? How is other OSes doing this (like BeOS, Good'ol-MacOS, Darwin, Windows or HURD (if they at all think about sound))? Would this be different in microkernels? Why hasn't anybody done this yet?

To stay remotely on subject, I your points about aRts is quite my experiences, especially on some hardware (like my laptop). I just turn it off.

Re:Hmm...

[Spy Hunter]

Right now the only mixing done in the ALSA/OSS drivers is done by the sound card hardware itself. All cards can mix together at least one channel of sound output from programs plus MIDI, CD Audio, Mic input, and sometimes other things. Some cards can mix together two or three channels of sound output from programs. But many can't, so the result is that only one program can output sound at a time (which is mixed together with the MIDI/CD/MIC channels on the card, not by the kernel). It is part of the kernel's job to virtualize hardware for access by multiple programs, so IMHO the kernel should provide an infinite number of virtual chanels and use software mixing to mix them together. There is an ALSA plugin that allows software mixing in the kernel, but last time I tried it it didn't work, and I don't think there's a way to add more channels on the fly when requested by programs. If ALSA provided only this one benefit over OSS, people would switch to it in droves. I can't understand why it hasn't been added yet.