The Full Story on GStreamer 201
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."
One big bit of news (Score:5, Insightful)
"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 [heroinewarrior.com]? 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
Re:One big bit of news (Score:5, Informative)
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.
Re:One big bit of news (Score:2)
But if the paperwork is good, that means that there will be lots of documentation for others to use to maintain and extend the work.
Re:One big bit of news (Score:2)
Cinelerra is mediocre (Score:2, Informative)
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.
Re:Cinelerra is mediocre (Score:2)
I don't know about that, I tried Avid FreeDV (ok, I do concede that it is a freeware program and in the windows world you only get what you pay for, but....) it couldn't even draw itself on the screen properly.
Re:One big bit of news (Score:5, Funny)
Sounds good, but don't you think it would be better if they were comp sci students?
Re:What? (Score:1, Insightful)
GStreamer is a very useful framework (Score:2, Interesting)
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.
Re:GStreamer is a very useful framework (Score:1)
Hmm... (Score:5, Informative)
Re:Hmm... (Score:2)
Re:Hmm... (Score:5, Interesting)
You can plug in modules, and synthesise any sound you like though plugins and modules, not unlike the pipeline editor in gstreamer.
Re:Hmm... (Score:2)
However, it's not cross-toolkit, so difficult to consider as a goal.
Re:Hmm... (Score:2)
Re:Hmm... (Score:2)
Re:Hmm... (Score:5, Insightful)
aRts is a synthesizer. KDE shouldn't have adopted it as a general-purpose sound system. Some of its problems have been partially addressed in newer versions, but it is still a bad choice. The way it SHOULD work is the kernel should provide unlimited virtual sound channels and let an unlimited number of programs open the sound device at once. It should use hardware mixing if possible and software mixing if it must, but it should keep latencies absolutely as low as possible. Then apps can choose whatever sound framework they want: aRts, gstreamer, jack, or plain old alsa, and everything would Just Work.
Re:Hmm... (Score:3, Interesting)
Re:Hmm... (Score:3, Informative)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/sound-setup.html [freebsd.org]
Re:Hmm... (Score:3, Interesting)
VST vs LADSPA, ten thousand per cent (Score:2)
you must check out LADSPA they're beautiful
so beautiful
I die
I'd settle for . . (Score:2, Interesting)
Video playback I could resize on the fly!
Call me lazy, but I hate putting in all those switches for mplayer.
Re:I'd settle for . . (Score:4, Informative)
That's strange. I've never had a problem grabbing the corner of an mplayer video window and resizing it as needed/desired.
Dinivin
Re:I'd settle for . . (Score:3, Informative)
the 'xv' driver will, however.
Re:I'd settle for . . (Score:2)
What is 'xv' and why doesn't my ATI Technologies Inc Rage XL (rev 39) and XFree86 Version 4.2.1.1 support it?
Joe
KDE usage huh? (Score:2, Funny)
Re:KDE usage huh? (Score:1)
Re:KDE usage huh? (Score:2)
KDE already uses the gphoto2 library in Kamera. There's no reason to write low-level digital camera support twice.
Should they develop a new compiler called k++ and license under the KPL?
Re:KDE usage huh? (Score:1)
Re:KDE usage huh? (Score:2)
What would be excellent would be if ARTs could return to it's roots as an Analogue RealTime Synthesiser, and use GStreamer as it's audio pipeline...and tie in with the MIDI support too (if GStreamer ever gets it).
Then there'd be really useful application that could be easily integrated into an audio production system.
GStreamer, Gnome, and KDE : WHY KDE IS WRONG (Score:1, Funny)
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 d
Re:GStreamer, Gnome, and KDE : WHY KDE IS WRONG (Score:2, Insightful)
Yeah, even if they don't ask for it, don't want it, and fight you to prevent it from happening. How "free" is so-called freedom that's shoved down your throat?
Seriously - gnome, kde, whatever.. As long as they all interoperate (which could use some work, but is improving), choice is a good thing.
Re:GStreamer, Gnome, and KDE : WHY KDE IS WRONG (Score:2)
Gnome was started by a Mexican, who still lived in Mexico at the time.
Server or Client audio? (Score:3, Interesting)
Re:Server or Client audio? (Score:1)
Re:Server or Client audio? (Score:2)
Re:Server or Client audio? (Score:2)
Re:Dear God Why? (Score:2)
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.
Breaking news (Score:2, Interesting)
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, sta
What, pray tell? (Score:2)
And who in the hell was saying that "Linux is a viable multimedia platform" three years ago?
--grendel drago
Re:Breaking news (Score:2, Informative)
No, it's definitely not just that. It's also a SoftSynth [fluidsynth.org]MIDI sequencer with audio capabilities, a DV video capture system [schirmacher.de] with editing and effects facilities, a multitrack HDR [sourceforge.net] and probably more. No, I see no multimedia this side of the mountain.
100% CPU Usage (Score:4, Interesting)
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?
Re:100% CPU Usage (Score:1, Informative)
Re:100% CPU Usage (Score:2)
Re:100% CPU Usage (Score:2)
Rhythmbox also has the ability to use xine or gstreamer. I use the xine backend as the gstreamer version causes the music to skip yet.
Re:100% CPU Usage (Score:2)
Re:100% CPU Usage (Score:2)
Explain it to me quickly, (Score:3, Insightful)
Nothing wrong with copying ideas... (Score:2)
Innovation for innovation's sake is a waste of time.
Re:Nothing wrong with copying ideas... (Score:1)
I think he was referring to this paragraph... saying that it was not implementing something done before, and then following that by saying the
Re:Explain it to me quickly, (Score:5, Informative)
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?
Nice. (Score:4, Interesting)
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.
Whoops - don't mod that funny... (Score:2)
Re:Whoops - don't mod that funny... (Score:2)
sounds like a kio slave to me. KDE at least has this support.
I've never used GNOME, but I'm surprized they don't have something like this. Surprized enough to suggest you look again because it seems more likely that they have this and you haven't seen it than they don't.
Re:Whoops - don't mod that funny... (Score:2)
For example, imagine if all Unix commands were represented graphically, so that you could arrange them like the screenshot showed in the article. Then say you could highlight multiple input files and send them through the pipe you created. It would save a lot of typing, and be easier for a beginner to understand.
Further, maybe you could save the sp
Re:Whoops - don't mod that funny... (Score:2)
Re:Nice. (Score:2)
If I had to use a graphical interface to apply a gzip filter after tar I would probably shoot myself rather soon.
Re:Nice. (Score:2)
And the point isn't to make it easier for people who already are adept at the command line, it's for people who can't be bothered with a cli. Otherwise there would be no Gnome at all.
GSteamer and MPLayer (Score:4, Interesting)
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:GSteamer and MPLayer (Score:5, Informative)
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.
Re:GSteamer and MPLayer (Score:2)
Re:GSteamer and MPLayer (Score:1)
The main goal of this project is to create a clean modular framework, with minimum cross-dependency of the modules, and at the same time solve some of the design issues/implementation limitations of MPlayer 0.90.
I know that the priorities of these two projects are different, I was just wandering if they will simply compete/coexist, or whether they will somehow combine their forces.
GStreamer summarized (Score:3, Interesting)
Substitute audio for video when necessary.
Re:GStreamer summarized (Score:5, Informative)
Re:GStreamer summarized (Score:3, Insightful)
Re:GStreamer summarized (Score:5, Insightful)
Looking over the SGI article, I seem to get the sense that it isn't really possible to have an abstract API that works on wide varieties of hardware, and you need to communicate with hardware vendors about a large number of issues. Of course, we all know how well vendors like to pay attention to open source developers, so let's not worry about being able to do that for a while. Gstreamer would have to be a force to be reckoned with before they pay any attention at all.
I don't really understand some of these objections, but I suppose it's because I'm not a graphica guru. For example, the square vs. non square pixel issue - can't a library be defined that knows what various devices do about that? AFAIK, all one can do with video shot for one pixel length when displaying on another length is add black lines to the edges to make it size correctly, or do some kind of averaging to add or subtract pixels from a dimension. I suppose if combining video from different sources the latter would have to be attempted. Even so, I can't see that this is necessarily a bad thing to have in the API - if someone has a different method for scaling between systems, just impliment it as an option for the resizing part of the API. I know if I were developing a video editor/manipulator I sure wouldn't want to deal with that myself if I could help it. Assuming there are standard ways for dealing with these issues, and maybe even default ones used most of the time, why should all the various video editors out there have to worry about it? Solve it once, define it as a standard option for the autoadapt API, and move on.
Am I missing something? I don't know much about Gstreamer, but I don't see why they can't do things in such a way that allows detailed specification of behavior if the developer is after something specific, and use the standard or accepted best solution to common video compatibility problems if not told otherwise. Maybe Gstreamer could even become a part in standardizing some of the hardware insanity SGI had to deal with, if it is successful and powerful enough. It's open source, but you never know. Ogg Vorbis is starting to get hardware support, and I would never have guessed that either.
Re:GStreamer summarized (Score:1)
Every difficulty with SGI's Video Library mentioned in this article has been overcome by GStreamer (as well as most other Linux-based media frameworks), and is used in working applications. Many of his observations seem rather quaint and outdated.
KDE 3.2 will come with partial support for it. (Score:4, Informative)
Re:KDE 3.2 will come with partial support for it. (Score:3, Informative)
GStreamer is looking more likely to be adopted by KDE. Arts is a little unmaintained and not well liked. GStreamer is good, has few new dependencies (arts depends on glib too as it happens), and supported by freedesktop.org. All things going for it. But frankly I don't know who will decide this sort of thing.
Re:KDE 3.2 will come with partial support for it. (Score:2)
how does this compete with puredata? (Score:2)
Helix licensing (Score:1)
I used to work as an open-source developer with the helix [helixcommunity.org] 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 [opensource.org]
Re:Helix licensing (Score:2)
The Helix license is GPL-incompatible, meaning that Helix can't be linked with GPL code.
Mozilla fixed that problem with dual licensing, as did Trolltech for QT. Real should fix it as well.
Am I the only person who.. (Score:1)
You Don't Know JACK? (Score:1)
Re:You Don't Know JACK? (Score:2)
JACK, Gstreamer, ALSA's mixer, etc. Very confused. (Score:2)
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
Re:JACK, Gstreamer, ALSA's mixer, etc. Very confus (Score:5, Informative)
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
Re:JACK, Gstreamer, ALSA's mixer, etc. Very confus (Score:2)
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 ?
Re:JACK, Gstreamer, ALSA's mixer, etc. Very confus (Score:2)
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
Re:JACK, Gstreamer, ALSA's mixer, etc. Very confus (Score:2)
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 URL
pipe dream? (Score:3, Interesting)
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:And then, KStreamer will follow (Score:1)
Who cares what a framework is called? (Score:3, Insightful)
Frameworks are only used by developers, they can call them whatever the heck they want.
Re:And then, KStreamer will follow (Score:2)
There, everything worked out in the end.
Re:And then, KStreamer will follow (Score:2)
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.
Re:And then, KStreamer will follow (Score:2)
Re:Wow, there's nothing more useful than . . . (Score:5, Informative)
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.
Re:Wow, there's nothing more useful than . . . (Score:2)
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 anyt
Re:Wow, there's nothing more useful than . . . (Score:2)
All that's left is a window with *only* the video in it, without annoying controls -- simple, intuitive, to-the-point.
Re:Wow, there's nothing more useful than . . . (Score:2)
This is not a new library, you know... And it's got the attention of the gnome and kde developpers.
Re:Dependencies ... (Score:4, Informative)
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.
Re:Dependencies ... (Score:1, Flamebait)
However, when exactly have you installed glib without the full gtk+ ? Sorry, but glib, gobject, gdk and gtk ARE a common package (and developed as is : same developers, same version numbers, same CVS) in most if not all distros.
Ergo, a dependency on glib is, for now and practically speaking, a dependency on GTK+. Thus, on a widget toolkit.
GTK+ is not built on glib and gobject : they belong to GTK+.
Re:Dependencies ... (Score:5, Informative)
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 =>
Re:Dependencies ... (Score:2)
Re:Dependencies ... (Score:4, Informative)
Gstreamer needs glib to run. So what? :)
Re:Dependencies ... (Score:1, Flamebait)
Glib isn't. Glib is part of GTK+.
Would you say the same with pango ?
Re:Dependencies ... (Score:5, Informative)
Re:Dependencies ... (Score:2)
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.
Re:Dependencies ... (Score:2)
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.