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
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.
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.
Do you really need reason for beer? Wingman Brewers
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!
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.
Obviously you didn't read the SGI article. His point is that such encapsulating APIs make the details inaccessible, thereby frustrating attempts to make any decent video applications.
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.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
There are two ways to read that - a) It's impossible to abstract the details in any useful way or b) all APIs to date have made bad choices in how to abstract things.
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.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
What about MAS the Media Application Server for X, which is on track to be a standard part of X?
tried mplayer. it had skinning. so i uninstalled it.