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 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.
Video playback I could resize on the fly!
Call me lazy, but I hate putting in all those switches for mplayer.
Pretty Pictures!
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.
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?
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?
You can plug in modules, and synthesise any sound you like though plugins and modules, not unlike the pipeline editor in gstreamer.
Substitute audio for video when necessary.
"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
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.
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.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}