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."
There was one snippet of news buried in the last page that I think is pretty big:
:)
"Another interesting development is that we currently got a team of about 7 french students who are going to make a GStreamer-based non-linear video editor as the final year project."
7 students running a final year project suggests it ought to be good, so does that mean we might finally have some really high quality video editing software other than Cinelerra? If so, that's brilliant!
I like the fact that GStreamer support is now filtering even into non-GNOME apps like Juk (in KDE). Good stuff
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 and its surrounded plugins.
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!
Video playback I could resize on the fly!
Call me lazy, but I hate putting in all those switches for mplayer.
Pretty Pictures!
I'm surprised that KDE users would use something that started w/ a "G" instead of a "K"....and vice versa ;-)
KDE was cooked up in the same country that started both World Wars, embraced philosophies of destruction and hate (such as Nazism and Fascism), and spawned evil murderous maniacs such as Adolf Hitler.
By using KDE you are implicitly endorsing these hatemongering people and their genocidal dogmas.
A true patriot uses GNOME, written in the land of the free and the home of the brave. By using Gnome you are re-affirming your American ideals and supporting the open doctrine of truth, liberty, and justice for all.
So, the choice is yours: Do you use Gnome or are you a terrorist?
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.
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.
Something like "DirectSound," perhaps?
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?
Speaking as someone who works for a large corporation (and one of the world's most profitable companies) I would say student code is substantially better than corporate code.
But where are the places where GStreamer innovates over the DirectShow APIs? The basic concept seems to be the same. DirectShow even has a filter graph editor which GStreamer's stream editor is eerily reminiscent of.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
This really has come a long way from when I checked it out a while back.
.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.
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
Gstreamer is a big step in the right direction. Way to go guys.
If moderation could change anything, it would be illegal.
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?
Before everyone jumps all over me and thinks I'm being facetious, I don't mean applying tar and gzip via the command line, but rather with a GUI interface, as in the article. :-)
If moderation could change anything, it would be illegal.
You think mom and pop, or even corperate customers for that matter, know or care what DCOM, DDC, or OLE stand for or mean? Guess that means that Windows will never be taken seriously...
Frameworks are only used by developers, they can call them whatever the heck they want.
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.
Substitute audio for video when necessary.
This is not a new library, you know... And it's got the attention of the gnome and kde developpers.
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.
There, everything worked out in the end.
sic transit gloria mundi
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.
Gstreamer needs glib to run. So what? :)
Innovation for innovation's sake is a waste of time.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
flaming skull heads
you must check out LADSPA they're beautiful
so beautiful
I die
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.
As in pd.
The problem isnt core glib (which arts and some koffice filters already uses), but the extention gobject.
GObject contains the "GNOME" event-loop and object system, and is what makes integrating GNOME and KDE applications hard.
For KDE to use GStreamer, we would need to have two event-systems and two object-systems and a patch to translate between them. Or in other words an invitation to crap.
I used to work as an open-source developer with the helix engine (still do, in fact), and didn't find the licensing to be that much of a turn-off. It's kinda like the NPL, or the GPL with the special rights for the Licensor outlined in section 3.
You can read the Helix license mentioned in the article here: RPSL
Check out Helix Player
glib does not depend on anything but standard C (glibc).
Copy & Paste gives you this:
GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.
still reading?
Isn't this similar to JACK? From what I gather, GStreamer extends it to video, also.
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.
You make the mistake of thinking that "g" means "gnome" and that therefore the KDE folks must replace the g by a k. It's GUI-independent.
It's the same with gphoto2, which is the digital camera library used both by Gnome apps like gtkam and by KDE apps like Kamera.
No you get glib seperately.2 .2.3.tar.bz2
ftp://ftp.gtk.org/pub/gtk/v2.2/glib-
It depends on glibc.
Then what else is a computer, to Joe Average Windows User?
And who in the hell was saying that "Linux is a viable multimedia platform" three years ago?
--grendel drago
Laws do not persuade just because they threaten. --Seneca
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 =>
Are you completely insane?
Recommending VNC over X for LAN usage?
X was designed for remote usage. It's an excellent solution for LAN usage. I'd agree that VNC is better for slower links, but for home LAN usage X is definitely the right way to go.
Advanced users are users too!
I have glib but not GTK installed in my system right now. apt-get install libglib-2.0 does it just fine. glib and gtk are separate packages (regardless of their developers), and I have yet to run across a distro that combines them.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
You don't know what you're talking about here. It's time to give up.
My only political goal is to see to it that no political party achieves its goals.
Actually a couple of the GStreamer guys were originally scheduled to speak at the recent KDE conference in the Czech Republic (which ended up not working out) -- the title of their talk was to be KStreamer. :-)
Your friendly OSNEWS summary service.
-- Bryan
Yes
OK, I'm going to take advantage of your post to inquire about this stuff. My question is only sorta on-topic for this story, but it is inspired by it (and by this sub-thread).
I'm a Linux audio user, not a programmer. I use JACK primarily because JACK is required to use Rosegarden4 (MIDI sequencer), which I use with my soundcard's onboard synth as a composition tool, to play with tunes before trying them out with the band I'm in. And I understand that it's necessary to use Ardour effectively, which I'd like to do when I can afford a soundcard that makes it worthwhile, like the RME Hammerfall or whatever.
But I don't really know what I'm doing with JACK -- when I run it, it's by typing in a command that I know works, but which I don't really understand -- and your response here highlighted for me some of my confusion. So here I go.
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"?
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?
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?
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?
I guess another "point" to JACK is to provide a common interface . . .that way, applications and modules don't have to know how to talk to all the possible other apps/modules out there someone might wanna combine them with; rather, they just all have to know how to talk to jackd. And that makes sense, and sounds like it'd be a good thing, for inter-process communication. But why is that a good thing for output? Isn't the whole point (or, a whole point, anyway) of having sound drivers to have a unifirm output interface? How does outputting to jackd to output to the ALSA driver any better than just outputting directly to the ALSA driver?
Well, that's enough to start with. If you (or anyone else) can provide insight, much thanks. I've read online docs about JACK and ALSA, and the Gstreamer summary linked to in this article, but am obviously still quite confused.
you can buy one of those on their site :)
http://www.gstreamer.net/buystuff/
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
VNC and X do different things while remoting.
If you want access to the one, unified desktop(s) [shut up, it makes sense], you want VNC. You want to remote individual apps, then X is almost certainly what you want.
Anyways, ssh -CX user@host will take care of most of the "ineffiencies" that X serving is notorious for.
[I am not to be held responsible for my spelling, for I am perpetually sleep-deprived]
The previous sig has been removed due to
"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
--
make install -not war
aRts was supposed to be a sound server for KDE. GStreamer is far from that, it's a multimedia framework - that's one level higher. aRts failed to be a proper sound server, precisely because it was designed to be - guess what: a realtime softsynth. JACK, on the other hand, IS a soundserver.
Just a few things to add to Paul's post.
.so that the JACK server would load at runtime. I don't know if this ever materialized. These would make JACK resemble Gstreamer a bit more.
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?
I think your confusion here is that you are confusing drivers with clients. A driver is an integral part of the JACK server that is responsible for providing a time source (so that the whole JACK system can run exactly in sync with a sound card). It can also provide ports like a client, but unlike a client it runs in-process, as part of the JACK server. There can only be one driver per JACK server process. Clients, on the other hand, are separate processes that talk to the JACK server using pipes and shared memory, and there can be many of them.
There was talk at one point of making it possible to create in-process clients. They would exist as an
3. What do you mean by "with Gstreamer the whole graph is in-process"?
Imagine you are drawing a picture of sources and sinks and connections between them. With Gstreamer that whole picture, the whole network of data all lives inside one single application (one process). With JACK, each node of the network is a separate process, except the driver.
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?
If the only goal was low-latency for a single application talking to a sound card, then indeed JACK would not be necessary. But an even more fundamental goal of JACK is that applications be able to work together. JACK aims to provide the lowest possible latency, while also providing sample-accurate synchronization, for this inter-application communication.
No, I don't think it would. It would belong to the Jack and ALSA-virmidi regime, as do existing softsynths. I haven't heard of any LADSPA softsynths yet, but I hope I will soon - as LADSPA hosts increase.
Yes, it is exciting to hear that people would start working on a non-linear video editor.
I don't expect their student project to be anything useable, but if they get excited about it and continue work for a few years after their studies, who knows? Maybe a competition to Avid and Final Cut Pro could emerge?
Of course, this has only a chance if they complement their programmer team with a few professional editors and have a very serious look at the 2 current NLEs (and at Pro Tools, the sound editor).
It's called mplayer. Extremely fast, extremely light and unbloated, and Just Works(tm). No need to download DivX/QuickTime/whatever codecs - it Just Works(tm). Even WMP can't compare to that.
Fast forward? Press the Right arrow key, or the Up arrow key.
Full screen? Press F.
Pause? Press space (just like in WMP 6.4) or P.
All very simple, all very, very intuitive. Unlike WMP, where you have to get out of full screen, move your hands from the keyboard to the mouse, and then try to point a menu item to do anything.
Mplayer is far better and easier to use than WMP. I even made it my prefferred media player on Win32.
Paul, I would like to use this thread to ask your opinion on a subject : would you think jack is suitable for processing video ?
I know, they are two completely different subjects, but as I think Ardour does video, how hard/useful would you think extending LADSPA / Jack to video could be ?
What about MAS the Media Application Server for X, which is on track to be a standard part of X?
OH MY GOD!
They suspended goatse.cx!!!
Run for your tinfoil hats, the world is coming to an end..!
tried mplayer. it had skinning. so i uninstalled it.
It would be fairly easy to extend Jack to work on video. It would just require someone writing a new data type.
I don't know what the basic data type of video work is. In audio, it's unsigned long numbers. LADSPA works on those. If someone changed it to work on whatever video uses, then LADSPA could be used too. Someone would have to get the video editors to support Jack and LADSPA though.
Ardour doesn't support video yet. It does has a feature to support animatics, which is almost video, but not what you're thinking of.
Then don't enable the GUI. It's that simple.
All that's left is a window with *only* the video in it, without annoying controls -- simple, intuitive, to-the-point.