Slashdot Mirror
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."
The "pipeline" he describes is somewhat similar to what you can do with VST plugins in Windows. E.G., you could hook up a microphone, then attach some distortion filters and eventually terminate the pipeline at some output device. All in all, this is a great article in my opinion. For the technically inclined, there are much more in-depth docs here, including all the gory API details.
Buy some computer games!
In fact, there is little out there to compete with GStreamer, at least on Linux. The nearest equivalent would be DirectShow on Windows which has nowhere as nice an architecture.
You're probably thinking that GStreamer duplicates Xine and MPlayer (though mplayer isn't really a library). To a certain extent it does - they all allow you to play back files, however GStreamer allows you to do a whole lot more.
Having said that, at the moment XineLib is more robust than GStreamer is, but the competition actually is spurring them forwards.
Although the main integration isn't planned until 4.0, the upcoming 3.2 will support gstreamer in JuK, the new music player for KDE. It will replace the slow and buggy noatun. Ive tried it, and its really quite good. Its one of the reasons why KDE 3.2 will rock.
To be honest, the two don't really compete... mplayer is purely playback focussed. It has no pretensions as a multimedia framework, or anything of the sort. GStreamer is all about being a powerful multimedia framework.
It's easy to forget how much code sharing goes on between these projects. They are all liberally licensed, all import each others code all the time and swap codec implementations etc. This isn't like standard capitalist competition where people constantly reinvent the wheel in order to stay ahead - if mplayer has a codec the GStreamer guys want, licensing issues nonwithstanding they'll go and take it.
You don't know what you're talking about. GLib and GObject don't even depend on X, let alone a widget toolkit. GTK is built upon these libraries, but to say GStreamer depends on a widget toolkit is flat out wrong.
They are usually evaluated according to their adherence to software development methodologies, rather than the actual quality of the end product. To that end, students spend more time making the paperwork good rather than the code good. Whilst this is a necessary part of building really big projects, it's not an optimal method of building small projects by inexperienced part-timers who often have only a very partial understanding of the problem domain.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
That's strange. I've never had a problem grabbing the corner of an mplayer video window and resizing it as needed/desired.
Dinivin
Gstreamer needs glib to run. So what? :)
It does: Gnome System Monitor -> Kill Task
GStreamer does not depend on GTK. The only dependence is on glib. I've yet to see anyone make any rational argument against a glib dependency in KDE. glib is just an extension to the C library, and no more a GNOME technology than libxml or libpng.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Try using the 'xv' video driver ($ mplayer -vo xv). mplayer, by default, uses the 'x11' video driver and won't scale on the fly.
the 'xv' driver will, however.
Even that piece of shit known as Adobe Premiere -- which Cinelerra trys and fails to immitate -- is lightyears ahead. If you want to get into the billions of lightyears ahead, then compare to FinalCutPro or Vegas Video (which was recently bought from SoundForge by Sony Pictures).
Linux has a loooooooooooooooong way to come in this department, and that's no troll.
No you get glib seperately.2 .2.3.tar.bz2
ftp://ftp.gtk.org/pub/gtk/v2.2/glib-
It depends on glibc.
glib, gobject, gdk and gtk ARE a common package ... in most if not all distros
/usr/lib/libglib-2.0.so.0 /lib/tls/libc.so.6 (0x002f1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x004c8000)
/usr/lib/libgmcop.so.1.0.0 /usr/lib/libmcop.so.1 (0x009e9000) /usr/lib/libgobject-2.0.so.0 (0x0015b000) /usr/lib/libgmodule-2.0.so.0 (0x00111000) /lib/libdl.so.2 (0x00425000) /usr/lib/libgthread-2.0.so.0 (0x00c68000) /usr/lib/libglib-2.0.so.0 (0x00224000) /usr/lib/libstdc++.so.5 (0x0082d000) /lib/tls/libm.so.6 (0x002f2000) /lib/tls/libc.so.6 (0x0044a000) /lib/libgcc_s.so.1 (0x00fb0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00c2d000) /lib/tls/libpthread.so.0 (0x00ef0000)
Which? I've never used one. At least Debian, SuSE and Red Hat/Fedora package them separately, and those are the major dists.
GTK+ is not built on glib and gobject : they belong to GTK+.
You're just wrong there. Many projects use glib and its gobject, and have no runtime dependency on gtk+. I, myself, have developed projects in C using glib on systems that do not have gtk+ installed.
Observe that glib is not linked to gtk+ on a Fedora system:
[gordon@wanderlust:~]$ ldd
libc.so.6 =>
Further, observe that KDE's "arts" includes libgmcop which uses glib and not gtk+:
[gordon@wanderlust:~]$ ldd
libmcop.so.1 =>
libgobject-2.0.so.0 =>
libgmodule-2.0.so.0 =>
libdl.so.2 =>
libgthread-2.0.so.0 =>
libglib-2.0.so.0 =>
libstdc++.so.5 =>
libm.so.6 =>
libc.so.6 =>
libgcc_s.so.1 =>
libpthread.so.0 =>
I would like to see some kind of cross-platform framework of this kind. DirectShow is Windows only. QuickTime runs on Windows and Mac, but not anything else. Are we going to see GStreamer on other platforms? The transform filters should be relatively easy to port, as should the file readers. The only parts that should require more than a quick recompile (I would imagine) will be source and sync filters that interface directly with hardware (cameras, microphones, speakers, displays).
Oh, and one more question: DirectShow exposes an interface to graphics hardware allowing filter developers to take advantage of hardware IDCT and MC features relatively easily. Does GStreamer have an equivalent?
I am TheRaven on Soylent News
I am JACK's primary author. I hope I can explain some of the basics to you.
1. What the hell is a signal graph (re: your response above)? Of what I've read about JACK, that's the first time I've seen that expression? Or by "signal graph" do you simply mean "a graphical environment for stringing together a sequence of signal processing modules into an overall application"?
When audio programmers talk about a signal graph, they are using the term to refer to a rather abstract conceptualization of what is happening in software (sometimes in hardware). The model is of a series of "nodes" each of which processes a signal in some way. Each node is connected to one or more other nodes, for input and/or output. You can build a very simple graph, such as some kind of node that reads from a disk file and sends output to another node that delivers it to an audio interface. Or you can build incredibly complex graphs in which the signal is routed all over the place, possibly even including through feedback loops.
JACK is merely one of many systems that use the model of a signal graph internally; GStreamer is another.
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
Gstreamer is really a toolbox to be used by a SINGLE program to construct processing pathways (aka "signal graphs"). It offers no facilities (other than connections to JACK) that allow MULTIPLE processes to route data among themselves.
As to what a JACK client does with the data it receives - that is entirely up to the client. We have some clients that stream to an icecast server, other people are working on UDP and RTP-based networking, others write data to disk etc. But JACK knows nothing about this, its entirely internally to each JACK client.
3. What do you mean by "with Gstreamer the whole graph is in-process"? Are you saying that you use the graphical signal path editor to create an application out of modules, but when you're done it links (in the post-compilation sense) the modules together into a single executable which has the capability described by the network? Because otherwise -- if the modules do their work independently and pass data between each other -- that sounds like processes talking to processes, just like with JACK. What am I missing?
As I mentioned above, Gstreamer is used by a SINGLE application to build processing pathways. It is of no use whatsoever in building multiprocess pathways, other than its connection to JACK.
4. My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
For a situation involving only one process (such as rosegarden), its certainly possible for direct access to provide marginally lower latencies than with JACK. But when I say "marginal", I really mean it. On a modern CPU, and with the right kernel, you can basically JACK as low as your audio interface can handle. The reason that JACK's design matters for latency is 2-fold. First of all, it imposes the correct model of int