So I attended the OSDL Desktop Summit in Mainz, Germany from Sunday to Tuesday evening this week. The goal of the meeting was to follow up on the tasks done at the earlier meeting in Portland and to look for new areas that could do with some work, multimedia being the one pulling me in.
The goal of myself and the GStreamer community in such a scenario is of course to advocate the use of GStreamer as the response free software can offer to advanced media frameworks on other platforms. We do believe we have the best and most extensive framework available and that with the work currently being done in the community this is not likely to change anytime soon.
In the discussion the approach taken by the Phonon abstraction layer which the Phonon project is advocating for inclusion in KDE4 also came up. I have held back blogging about Phonon for some time to avoid flamewars, but I don’t want to have efforts like OSDL delayed due to setups like Phonon being promoted or thought of as a workable solution for the issues faced. Let me start of with a brief introduction to the area of multimedia frameworks.
First of all multimedia frameworks are very complex systems, handling very hard technical problems in order to cater for issues ranging from problems from dealing with the analog past (for some technical information in this field I recommend fourcc.org), a forest of media formats with different traits, a host of features/deficiencies in hardware and a wide range of other software solutions to interact with like sound servers and legacy systems. On top of this you add performance and latency requirements, network protocols and multiplatform issues. In the end you have a problem space where even those who have worked on the issues for many years need to keep their head clear when designing the framework.
Multimedia frameworks are also by their nature abstraction layers themselves, trying to abstract away all the demuxers, muxers, decoders, encoders, cameras, soundcards, sound systems, network protocols and various types of filters into a coherent and userfriendly API.
With all this complexity the frameworks are struggling to not only bring you a coherent API, but also try to offer developers using them some high-level API’s that are useful for application developers. What we discovered in GStreamer is that while application developers initially ask for a ‘play this file’ API, which is what we offer through our ‘playbin’ component, they often end up pushing playbin to its limits and sometimes not use it at all in the end as they want to do fancy stuff which demands manipulating the pipelines more directly.
In many cases application authors want to do something which demands that a special plugin or filter to be written.
Now to get back to why I think Phonon is conceptually broken. First of all it is destined to fall into one of two traps. Either its API become so high level and limited that application developers will shun it due to a lack of features, meaning that you have an API useful for doing ‘ding’ sounds in standard applications, but anyone wanting more powerful operations will feel its a bigger hindrance than a help. On the other hand if they actually try to implement a feature set that is big enough to at least satisfy a subset, of for instance music player writers, then they will be forced into accessing things so deep in the frameworks that the operations become so framework specific that generalizing them away into a common API will at best be a kludge and at worst produce various broken behaviour changing depending on framework chosen.
Phonon also falls short in many other areas. For instance the stated goal is to let application writers write their applications against one API and have them work with a host of media frameworks. The reasoning is that no framework ‘does it all’ so having this flexibility is a good thing. This logic falls down quickly when you start thinking about it. While the general statement that no framework supports all formats or all features is true, the opposite, that a combination of multiple frameworks ‘do it all’, is equally untrue. An application developer who wants to add support for a new or rare audio format for instance would very often need to write the plugin or library to support it him/herself anyway, targeting an API with for instance 5 backends doesn’t make that job easier, it actually means that if you as an application developer want to ensure all your users can play this format he/she need to repeat the job five times.
So if you choose to standardize on one framework like GNOME has done with GStreamer then there is a chance that the application developer wants to support a format that GStreamer doesn’t currently support. But at least the developer have a clear idea where to add support for this format.
Also in a usability context telling the users to do hit and miss framework changes based on which media file they are trying to play is simply broken and I have a hard time believing that this is the user experience anyone wants to present users with for KDE4.
The counter argument to this is that Phonon do allow application developers to force or at least strongly suggest a specific backend for the user to use. This do solve the problem of the application developer knowing where to add support for something, but it also means that another stated goal of Phonon, to avoid enforcing such a ‘heavy’ dependency as GStreamer, might very well be replaced by enforcing 5 different mediaframeworks to be bundled with KDE4 as a whole. And if you think one framework is a heavy dependency then I promise you than five is not less. It also reduces the synergy effect of the KDE community a lot as it means that the work done by one music player author to add support for a new format will not be automatically available to the other KDE music players.
What we have been advocating for a long time from the GStreamer corner is that if both GNOME and KDE share a multimedia framework the synergy effect for both desktops will be huge.
My final objection to Phonon is that even if they manage to prove me wrong on their ability to provide a truly useful limited cross framework API and demonstrates that having a menu option offering your grandma to play her music using framework X,Y or Z actually solves more problems that it creates, I still think that it falls short. Because it wouldn’t provide an API to do applications like Pitivi, Diva, Jokosker, Buzztard, Flumotion and so on which I think is where we want to be at today in order to provide a competitive desktop. MacOS X and Windows Vista are showing us that this is the role that the desktop is heading towards.
One scenario I know have been contemplated is using Phonon, but at the same time saying that GStreamer is the recommended framework if you want to do something outside of the scope of Phonon. But my opinion is that in this use case focusing on Qt-style bindings for GStreamer is a better solution and a much easier thing to do and would result in something more useful for developers and users alike.
So I hope that interested people in the KDE community agrees with my analysis and starts working on Qt-style bindings for GStreamer, and as a result Phonon falls by the wayside. If not, well hopefully we will be able to cooperate on some of the lower level issues in the desktop, like improved driver handling through HAL for instance as the minimum.
All this said, people from the GStreamer community will of course try to help out people developing the GStreamer phonon backend for instance. We do try our best to try to help anyone using GStreamer, even when they do something we don’t believe in the viability or direction of. Zaheer Merali for instance has already volunteered to mentor or co-mentor anyone interested in working on Phonon-GStreamer integration as part of the Google Summer of code and as far as I know there where multiple proposals submitted for that.
@jamie
Good Support + guarantees of future support
Gstreamer does not have that because mm frameworks can change drastically. Putting all your eggs in an unproven basket is a gamble that kde does not need take.
Disclaimer: honest GNOME user for 8 years. Have loathed and loved GNOME and Gstreamer.
First of all, I would claim that all speach about gstreamer quality are on very shaky foundation, as far as it goes about last stable version, because 0.10 is very high quality stuff. And believe me, as someone as who have cursed 0.8 version of it’s lack of quality, I know what I say. Media files simply gets played, period. Trough Totem, Rhythmbox, everything. And please guys, no other framework as Gstreamer does true multichannel quality sound from ALSA bindings for my sound card.
to not sound like yes man – there is lot of areas where 0.10 still needs improvements, but we can see light in the end of tunnel here. Media playback is rocking.
Now about subject. Lot of these comments here and in another blogs feels like old flame war – please stop that. Chris has some reasons to lay out his opinions about Phonon here, and in fact it is done quite honestly and peacefully. What I don’t like is quite arrogant answers from KDE guys. It is not like I would care (hey, I am honest :)), but multimedia layer projects have been far too much already for free desktop – it is time to land on one. I know, it is hard to make political decision for KDE guys, because they want to keep their “truly geek desktop” slogan, but… I don’t know.
Honestly, Gstreamer _already_ provides sinks for different backends – like arts, ALSA, oss sound, etc. And at this point I just have to ask – why KDE don’t want to work on this in Gstreamer? Let’s improve Gstreamer backends! ALSA is just rocking, OSS never had problems, Esd is shaky with multiple channel cards, I don’t know about arts.
Many KDE devels here got jumpy and started to troll with comparing same situation “why not abadon GNOME and work only on KDE thing?”. Please, don’t mix it. it is NOT the same. Multimedia format doesn’t change because of GUI. And user DON’T CARE WICH FRAMEWORK plays it’s file. As 95% of users – KDE or GNOME – WON’T change backend. Because it is plainly stupid. I want things to work out of box. And I am geek.
Please, KDE guys, get over your self-importance and “impossible-to-prove-but-still-we-own-Linux-desktop” attitude. Before it is too late. Gstreamer IS the way to go. Chris have proven his point half a year ago with 0.10 release. From that point, it have got only better.
Heretic: hmmm, you can claim what you want, but Chris and others have worked hard not to break things in 0.10. And if KDE will support Gstreamer and will give some weight behind it with bug reports and testing, well, everyone benifits, I guess.
Gst has very good support for now. They fix bugs like crazy :)
@Thomas Vander Stichele
Gstreamer has a chance of being a no longer valid solution in a couple of years. The devs may decide to go in a direction that may not be be good for kde. Then what? KDE is stuck with gstreamer and its arts all over again. On the other hand gstreamer may be awesome and phonon is no longer needed and it can be phased out. Better to hedge your bets when it comes to this specially since kde has been in this situation before and went with the wrong choice. I understand that the devs may be confident in what they have now and say stuff like “gstreamer won’t go away, thats ridiculous” is retarded. The simple fact is they don’t know. They don’t know if a much better solution will crop up or if Gstreamer will end up in the toilet and they’re asking kde to trust that everything will come up aces. uhh riiiiight.
“I don’t think the right approach is to downright spread FUD about GStreamer. “buggy as hell” is clearly a personal opinion and not backed by facts. Everyone out there actually using GStreamer is agreeing that this is the most stable series yet, and it’s improving with leaps and bounds. Arguing from a clearly bigoted standpoint will not convince anyone here.”
Ummmm, where have I claimed that Gstreamer is “buggy as hell”?
@Peteris, others
I don’t think anyone from KDE is being noticeably arrogant about this situation. This is a discussion about the merits of a KDE media framework, so if KDE developers want to respond with reasons they think it’s a good idea, what’s the problem?
Furthermore, why is it the intense concern of GNOME users and the GNOME project whether or not KDE has a media framework? I’ve heard some among your ranks criticize KDE for “wasting time” on KHTML when there’s Gecko… too bad KHTML is cleaner, more standards compliant, eats less memory and runs faster. (Ok, small jab.)
The bottom line, I think, is that there are two major desktop players (KDE and GNOME) because there are two schools of thought. We can shout at each other all we want for disagreeing about things, but demanding that we all see the same light is a little bit silly. Some people call this split a duplication of effort; rather, I see it as simple evolution – survival of the fittest. If we all banded together to work on *one* desktop environment, we’d probably end up killing eachother and never get a single stable release done.
Moral of the story is to let KDE developers be KDE developers, and let them decide how to best represent the interests of KDE users. Ya’ll do the same — okay?
@Peteris Krisjanis
No one is saying Gstreamer sucks and lets all work on kde stuff. Most likely gstreamer will be the default backend for phonon. But saying Gstreamer will rule all and should replace phonon, its too early to tell. Specially since gstreamer is lacking a lot of features and isn’t really a good backend to use if you have older hardware.
Heretic: do I feel “We afraid of things we don’t control?” all over again here? What about Linux kernel? What about HAL, DBUS? Gosh, get grown up. AFAIK, KDE 3 is younger than DBUS and HAL, and they are still here. Or they went away too?
What is premise of free software? That anyone can take over Gstreamer team’s work. And as GNOME is depending on it, and some companies (hint, hint, Novell, Cannonical) too, then maybe situation maybe won’t be so bad.
And about direction – well, you should learn to work together. If you won’t then KDE as common user desktop is truely lost. Sorry to say that, without irony.
Some thoughts:
*GStreamer already covers all of the basic uses that Phonon is meant to cover, so the fact that other frameworks provide other features seems to be irrelevant. Does it matter that NMM can do network stuff if Phonon won’t provide an API for it? What advantage is then gained by using Phonon? It seems like a bit of a heavy solution for the problem of app. developers having to integrate three or more different backends.
*GStreamer seems to be yielding some innovative apps right now. However, it’s easy to see future innovation happening in the network space, so the features of NMM shouldn’t be neglected. Can GStreamer be adapted to incorporate the network functionality of NMM?
*GStreamer needs to get rid of the issues that cause people to switch over to Xine or other frameworks. For me the problem is that even when I install every possible plugin and codec for gstreamer, it never seems to be able to play my MP3’s, while Xine always seems able to.
*Larger developer mass working on a single framework would guarantee that GStreamer will not suffer an arts-like fate. In fact, because it discourages direct involvement with GStreamer, Phonon probably makes it more likely that GStreamer will lack critical developer mass, thus becoming a bit of a self-fulfilling prophecy
My verdict is that Phonon is fine, it won’t hurt anything in the end. It might direct a good deal of developer resources away from GStreamer in the short run, but if GStreamer continues to progress rapidly and also to integrate the attractive features of other frameworks, then Phonon will just be bypassed and will eventually die or be relegated to a limited role.
Heretic: sorry about last post, got over top here (and trollish). All I wanted to say that I just don’t like split efforts in multimedia field, because they are too much diversed. But let’s see how will everything land in the end.
@Peteris
“What I don’t like is quite arrogant answers from KDE guys.”
What “arrogant answers”? We basically have Gstreamer-developer telling how Phonon is crap. You are fine by that, and then you complain about “arrogant answers from KDE guys” when they mention in their blogs that “Christian misses the point”. Huh? Did I just enter the Bizarro-world?
“Many KDE devels here got jumpy and started to troll with comparing same situation “why not abadon GNOME and work only on KDE thing?”
Huh? Are you referring to my post (where I jokingly mentioned droppng work on GNOME and working on KDE instead)? FYI: I’m not a KDE-developer. At this moment I’m not even KDE-user! I use GNOME currently! ONLY KDE developer (to my knowledge) who has commented on this is Aaron Seigo!
“Please, KDE guys, get over your self-importance and “impossible-to-prove-but-still-we-own-Linux-desktop” attitude.”
Please: take a chill-pill. They are designing a multimedia-system for their desktop. Why do you care about it?
“Gstreamer IS the way to go.”
Maybe, maybe not. Maybe some uber-framework that is yet to be released is the way to go instead? And if Gstreamer truly is gods gift to Linux-users, then people will use it, with Phonon, or without it. And in the future KDE might move to just Gstreamer. But as things are right now, there is no “one framework to rule them all”. Of course Gstreamer-developers think that their project is the best. I bet that few NMM-developers would disagree with them though ;).
“From that point, it have got only better.”
New version of the software are better than the previous versions! Well, I would sure hope that is the case!
@Peteris Krisjanis
Thats ok. The primary issue is that kde has been bitten by the whole multimedia framework thing and its logical that instead of standing behind a single solution. They will allow the user to pick until the available frameworks mature, then and only then can we see a clear leader and can phase out phonon.
Meanwhile, there’s should be some reasons for people not to choose (or rely
only on) Gstreamer. Get off you’re self convictions of excellence and
look around.
In my case: I was subjugated by the good comments and intention about
Gstreamer .10. I really thought that it will be the one kick ass fd.o
multimedia solution eventually done rightly (and that’d avoid the
fragmentation like we have with all those half backed frameworks or
implems, xine, mplayer, vlc lib, etc.).
The Cairo, the Xlib, even, the POSIX of the multimedia ! All so good.
So much that I decided to code with gst .10.
First in C, but given the global opacity of the lib (apart for an ultra
basic proof-of-concept usage through playbin), I tried the python binding.
Same problem. No docs for the incomer (gave me the feeling that all this
was written by a sect with special dialect), no true tutorial, outdated
formal docs, manpage covering 1% of the cli functions etc…
Then I struggled with other weakness (so hard, given all the hope I’ve
putted on Gstreamer .10 !).
Oh, the universal multimedia lib doesn’t even work on *BSD ? Too bad.
I believed (really, I did) that those uber hackers were intensively
testing everywhere for portability, but not, gst won’t even compile
on FreeBSD, NetBSD or OpenBSD. Wooff, thanks that the major
multimedia players and DE don’t rely on gst-0.10, else we’d loose multimedia
functionalities for our desktops.
Oh, the “too be stable and long term maintained” lib is so hard to
use that even gst devs failed to port a large part of their own
plugins from 0.8 to 0.10 (hey, where is dvd navigation now ? etc).
Nice demonstration of an API that will be well supported on the long run.
So before giving lessons to everyone, please, work to make your options
attractive. It’s not time yet to start whispering against other
developers for not relying on an API not well documented, not
so portable, that proved unstable in the long run, that has no bindings
for KDE language of choice, that is not easy to code for, doesn’t provide
good high level shortcuts or abstraction for the common needs, no
easy path to start coding with (remember, that’s what Phonon mandate for)…
At least for me, the inappropriately relayed self esteem of Gstreamer
devs about their work, the unavowed gap between intentions and reality
conduced to a loss of time, and disappointment. Glad to see that KDE
devs won’t all in this hype & momentum trap.
Well, think from the KDE perspective.
All apps which ship with KDE will use Phonon which uses Gstreamer (and other engines). KDE does not have to depend on gstreamer and advocates of other solutions are satisfied as well.
On the long run competition will solve the problems.
Further if a KDE non-core application is not satisfied with Phonon it will support gstreamer directly, no problem.
People who need multimedia backends other than gstreamer because of certain features will be satisfied as well.
Think of the approach that was done with KDE printing which lead to real success. They somehow copy the method.
I’ve jus read the Aaron Seigo blog post about Gstreamer and thought that he said better what I (as a basic, simple dev that tried Gst) wanted to explain about Gstreamer experience:
> a believable API/ABI stability guarantee that covers kde4’s lifespan
Transition from Gstreamer 0.8 to 0.10 has proved that there are still much work to do for Gst in this area.
> an API that is easy enough to use for casual development (bonus points for fitting in nicely with KDE’s API)
For this one, I’ve already spoke. Gstreamer is not easy to use (neither well documented, and neither giving most wanted high level functionality, and please, playbin is not that …).
> availbility on every platform that KDE supports (that’s more than linux; it’s even more than open source platforms for that matter)
Not a priority for gstreamer, appart for commercialy backed one (Linux, Windows, MacOSX and some bits of Solaris: not so much).
> a solid user experience
As a end user, I’ve nothing against Gstreamer so far (appart for the gst-launch cli not being ergonomic nor documented and dvd navigation, and some subtitles itches).
I dont want to use gstreamer. Do I have to remove speakers from my computer now?
The gst/phonon debate is basically this:
How many pairs of gloves can we wear and still be able to crack an egg?
“How many pairs of gloves can we wear and still be able to crack an egg?”
6
As I understand it, KDE 4 will need components to provide multimedia services very smoothly integrated with the desktop, like multimedia players embedded in koffice documents, or in kmail, konqueror, …
AFAIK, gstreamer’s first goal is to provide a single multimedia framework, not to fit into kde desktop at all cost.
It would be very weird i think if in this century a desktop like kde would provide consistent look, feel and integration through all its components except multimedia ones …
I for one do not want to use stupid gnome sh*t. Last time I installed gstreamer, it pulled bazillion of gnome dependencies which is totaly gay.
Thats the whole problem with projects like gstreamer and freedesktop (yes, that too). They keep whining and complaining about how other projects do not want to use these so called “standards” yet if you look at gstreamer or freedesktop projects, they use bunch of glib/gtk/gnome libraries.
Good example is freedesktop’s dbus. KDE had DCOP for a long time now, yet freedesktop did not want to make it a standard, but instead they made their own version and called it dbus. Of course, dbus heavilly depends on gnome sh*t.
Why didn’t they just make DCOP standard? Because only way that an app can be standard is if it uses bunch of gnome crap.
Now that KDE has decided not to use any of this stupid crap and actually allow the user to pick what they want, all the gnome people have their panties up in a bunch.
Gnome, gstreamer, freedesktop = communism = ass raping prison.
KDE = freedom.
Hurray for freedom.
@Heritic
Dont you have better things to do than troll on other peoples blogs? I think Christian gave up arguing with you because you “just dont get it”. Stop being the KDE fanatic and take a look at the big picture. For one thing, users should _not_ be able to tell what mm framework is running in the background when doing something. Can you really tell the difference between XINE and GStreamer playing an MP3? The point is you shouldn’t be able to, they’re both playing the same MP3, their output should be the same (unless you have different audio filters for each, in which case it _should_ sound different, but shouldn’t be distinguished from another which has the same audio filter). I am no expert in the audio/visual field, but what is the point of creating a uniformed API for a non-uniform set of multimedia frameworks? Unless you are going to create a uniform set of flexible features which apply to all underlying multimedia frameworks, this is a bad idea. As stated above many people, the issue of extending the backends is huge (writing 5 extensions to a mm framework is more work than writing one).
It seems to me Phonon contradicts itself — it wants to be an abstraction to provide a uniform API to provide multimedia capabilities, except in the process it is making everything but the most simple of tasks more complex. In my oppinion, if Phonon is to succeed, they need to provide support for only a single mm framework OR they should somehow find a way to abstract a uniformed API which interfaces with all the underlying backends and allows you to write a single extension which works with all of the underlying mm frameworks.
That is my view of the topic, and I think many people would agree on this.
@Anonymouse
You shouldn’t be able to tell the difference between xine and gstreamer huh? Unfortunatly you can. Gstreamer is slow on older hardware.
I don’t think u get the point of phonon, Its to relieve dependency on a single framework so that the mistake of arts will not be repeated. If Gstreamer was mature and had most of its issues/missing features resolved then christian’s stance would be stronger. Unfortunatly it isn’t. Even amarok is temporarily turned off their gstreamer engine.
A lot of gnome fan boys and devs may agree with you but most kde devs don’t (aaron siego, scott wheeler, Ian monroe etc)even scott wheeler who is a big fan of gstreamer admits its simply not ready to be adopted by kde 4 as the only mm framework.
If you think that disagreeing the Gstreamer should be integrated into kde 4 is trolling so be it. You strike me as a gnome user. If so why do you even care what kde uses? I am a kde user and plan on using kde 4 and feel that phonon is a step in the right directions. Whine and hold your breath all you want when it comes down to it gstreamer 0.10 isn’t complete and probably won’t be for some time. Phonon is going in kde 4, Gstreamer will only be used as a backend. Get over it. Gnome maybe fine with using a single mm framework that they believe is good enough, kde prefers its users to decide. I started using linux because it gave me choice, if I wanted something shoved down my throat i’ll go back to using windows.
@everyone
One more thing that all the pro “Gstreamer should be the only mm framework in kde 4” close their eyes to is that gstreamer isn’t portable to all the platforms kde runs on. I think scott wheeler said it best:
http://www.kdedevelopers.org/blog/72
@Heritic
Thats not my point. Im not Pro-GStreamer, and im not a GNOME user (although when showing GNU/Linux to friends/colleagues i will show them GNOME). I’m just agreeing to many of the points Christian said above. Although GStreamer might _not_ be the best MM framework to use practically (as i said above, i am not experienced in audio/visual field so i am not qualified to make any judgements), but the issues Christian has pointed out are true. While Phonon may be excellent for purposes such as general use for KDE4 (ie. simple audio/video playback/recording), it is conceptually flawed if it aims to provide a true general purpose library for multimedia access.
As [many other people and] I pointed out above, Phonon will suffer in various areas. The main issue is in regards to the features that the underlying frameworks provide (or dont provide). Many of these underlying frameworks have different goals, and each will provide their own feature set. It is when these underlying multimedia frameworks _dont_ provide the feature you want that it becomes a problem. Say for instance you wanted to have some real-time audio effect which none of the underlying backends provide. Therefore you will have to implement this feature yourself. In the case of Phonon, you will have to write 5 different versions of this feature, one for each backend that Phonon provides support for. Or you will face issues in regards to the availibility of your feature, as only people who use the same underlying multimedia framework as you will be able to access it. This is an issue which Phonon will have to resolve in order to reach its goals.
Also, my criticisms are meant to be taken constructively. If you were really interested in what i use as a WM/DE, i use Ratpoison on the GNU Emacs operating system, using the Linux kernel and GNU tools. I think that KDE fanatic’s would be more ‘GNOME fanboy’ than me ;)
@everyone
After reading comments it seems that KDE developers just want to use whatever framework is popular at the moment while GNOME developers are actually *working on the framework*.
@Heretic: gst isn’t slow on old or limmited devices. why do you think nokia uses is on its 770 or access has chosen it for the palm os?
@Anonymous (who complained about portability & docs):
1: Gst-developers welcome everyone who is willing to help about portabillity. Whe don’t intend to limmit gstreamer portabillity.
2: Gstreamer docs are quite complete. The API docs coverage is constantly >95% in the 0.10 series. I admit the application writer manual and the plugin writers guide still suffer from the .8->0.10 transition. Beside I belive the gst irc channel is one of the most-helpful I’ve ever seen.
The reason why this discussion can go on and on, ad infinitum, is that there is no right or wrong point-of-view. Everyone is talking about opinions and speculations. When you try to attack an opinion, unless you’ve covered ALL possible bases, you’ll just get more rebuttals.
The KDE wants control of their destiny. They don’t want to be stuck with one solution. So they create a wrapper for multimedia APIs much the same way wxWindows is a wrapper for various graphical toolkits.
There is no right or wrong. Unfortunately, what is incontestible is that we’re getting a glut of choices and there are certain circumstances where having many choices is just divisive. The win32 MFC classes may have been an imposed standard and may not be the best, but one can’t argue with how successful it’s been at getting mindshare as well as applications.
So people, if you’re going to be making arguments, please try to consider possible rebuttals and answer those as well. Make your arguments bullet-proof or go back to the drawing board and think some more.
Personally, I think a wiki is a better medium for cooperative discussions since corrections, rebuttals and counter-arguments can help improve the original argument.
@Janne: sorry, I mistyped, it was directed at Jose.
@Heretic: the point is not that we claim GStreamer will not go away. The point is that *anything* can go away, and basing your strategy on the possibility of something goin away is stupid. I’m not claiming GStreamer is here to stay. I’m claiming GStreamer 0.10 will always be available.
The problem with arts is that KDE people have let it die a slow death, because nobody hacked on it. It’s that simple.
Can this happen again ? Sure. Should you be worried about this happening to Phonon itself ? Maybe, but if you do, then it’s a bigger worry than GStreamer going away.
@Anonymous: the fact that you are the only one to post anonymously is telling :) Where are your bug reports ? Did you read documentation ? Your comments about them make me think you didn’t – half of the elements these days now come with a simple sample, and our documentation contains multiple simple sample applications. Did you ask us for help ? We’re friendly guys and we help anyone that bothers to send us a mail or drop into IRC with questions. Sure, there could be more docs, but it’s not like any other framework has perfect docs. Your comment about DVD support is completely off the mark – it didn’t get ported because the person who wrote it in the first place is not hacking ATM, he’s busy getting a PhD.
About BSD: as far as I know it works on BSD, there are people that report bugs on it. I don’t use BSD myself, and you’re blaming the wrong people if for some reason it doesn’t work for you on BSD. You should have filed a bug report. You can’t expect a single project on its own to guarantee 0% bug freeness without a little help from platform people. It’s very easy to make such a silly claim and not back it up with facts (where’s the bug report ?) As it stands, GStreamer works on i386, ppc, x86_64, linuxes, BSD’s, Windows, Mac OSX, ARM, …
@Heretic: didn’t find the bit you seem to quote from Scott’s log about GStreamer’s portability to other platforms.
@dude: funny post, thanks for the comic relief. I do hope you didn’t have an actual point though because it probably got last in all the *ss-r*ping.
@everyone :)
Having been at the presentation of Phonon@LinuxTag I think it is meant as a backend of KDE applications for easily accessing audio and video playback and maybe recording. I don’t think it is meant as a backend for special case applications.
@the author
And as you said yourself, you didn’t say anything to not start a flamewar. Well, I wonder why then now you did. You should have emailed the Phonon project leader, telling him what you think and then talk to _him_ about it. Making this a public discussion make no sence. I think if you have different ideas about what Phonon should be and how it should do that, then so be it! How can you seriously come and suggest that Phonon should be scrapped and instead GStreamer’s qt-bindings developed?
@everyone
What I do think would make sence is to make Phonon available to any Qt-application. (But I don’t know if that’ll anyway be the case…
@dude: you do know that KDE4 is going to use DBUS, do you? :-D
And as a KDE user I can assure you I would raise hell if they decided to force GStreamer down out throats. Because I _want_ the choice that an app like Amarok is offering. Basically Phonon will just make that choice system-wide and standard.
Do I hate GStreamer? Of course not, it’s what I use for 80-90% of my apps but there are times that it just isn’t enough.
@Jamie McCracken:
>Criteria to use for choosing a framework:
>1) Technical merit
>2) Good Support + guarantees of future support
>3) Widespread use in apps
>4) ABI/API stability
>only (4) would work against GStreamer ATM but I would >expect them to produce a Roadmap to an ABI stable 1.0 >version soonish if they have serious aspirations.
Yes, ATM. but before GStreamer was started, none of these counted. so development on GStreamer would never have started in the first place. second, these things counted for aRts, too – and aRts depended on glibc (!!! yes, KDE accepted that) – it was NOT meant for KDE, KDE was merely the first DE to accept it. Then Gnome didn’t want to accept it because, what? KDE used it? It’s not like esound was better…
I think NMM has better cards: better design, mostly. It took GStreamer years and years to get to a moderately usable state – still xinelib kicks its ass, and aRts isn’t that bad for a years old, unmaintained framework.
@Stefan Kost
> 1: Gst-developers welcome everyone who is willing to help about portability. We don’t intend to limit Gstreamer portability.
Off course. I just wanted to point that as of now, Gstreamer is not the universal solution it’s intended to be (and will certainly be).
Or to put it differently, given the facts (not the intention), it’s relevant for KDE to give a fall back option (and to Gstreamer devs, to be more self honest when evaluating and talking to others about the shines and lacks of the current gst code).
> 2: Gstreamer docs are quite complete. The API docs coverage is constantly >95% in the 0.10 series.
Right. I just got back to the online doc and must admit a large progress since I tried to use Gstreamer, several month ago (at that time, I remember a very low coverage of .10 plugins, for instance). Sorry for my fud about coverage :(
Anyway, I remember being eaten by cases that such a formal doc don’t cover (that’s, again, where more “honest” or “go real” doc is really wanted), things like “oh, but don’t do this, this plugin can’t seek as of now”.
Second, about the docs, my other point is still relevant: the gst API is hard and relatively low level, and newcomers somehow lack friendly “get in” docs/tutorials. This could be a respectable choice (or just not the priority) for the Gstreamer project ; but then you can’t deny that it leave room for higher level wrappers like Phonon, that, to quote Aaron, intend to be “an API that is easy enough to use for casual development”.
See, wouldn’t an “easily write a video player with gst-python” article on newsforge or onlamp.com be more efficient to show the pertinence of Gstreamer than the Christian’s blog post ?
I think you are all forgetting that KDE’s decision not to support a unique multimedia framework was made in 2004. And at that time gstreamer wasn’t a viable solution.
I see a lot of posts what if GStreamer goes the way of the Dodo and what if it takes a direction we (the KDE people in this case) don’t like?
My take is that if you can put resources into Phonon, you can instead put your resources into GStreamer and ensure yourself that it doesn’t go that way. As for what if it takes of in a direction we don’t like? If you take that approach KDE basically just disqualified all f.d.o. projects. So lets just not share any tech anymore and live on our own island! Again get your KDE developers involved in GStreamer and you should be able to have some influence over that.
Something that’s standardized is bound to have some people complaining about missing features, but for the majority it is very convenient to not have to target multiple frameworks. And it saves a lot of duplicate effort.
@Stefan Kost
I have a test machine thats 333mhz and has 198 megs of ram, it does not matter what player I use Gstreamer is always slower than xine and a lot of times will pause in the middle of a somg and then move on. So in my experience it is slower and just by performance I can tell if i’m using xine or gstreamer.
@Thomas Vander Stichele
I wasn’t quoting scott wheeler, I just think what he said about the whole phonon/gstreamer bit was more detailed than I can put it. One thing he did mention is maturity and portability to other platforms is one of the signs of maturity. The quote from him that seems to hit a bullseye ont he whole thing is:
“All other arguments aside, GStreamer doesn’t offer a stable API. I can understand why that’s the case, but as such, because of the (sane) library policies within the KDE project on binary compatibility we cannot simply use a GStreamer binding as our multimedia solution”
But gstreamer should used anyway?
@Elroy
“My take is that if you can put resources into Phonon, you can instead put your resources into GStreamer and ensure yourself that it doesn’t go that way. As for what if it takes of in a direction we don’t like? If you take that approach KDE basically just disqualified all f.d.o. projects. So lets just not share any tech anymore and live on our own island! Again get your KDE developers involved in GStreamer and you should be able to have some influence over that.,”
But thats like saying why don’t gnome devs put their efforts into arts and make it a suitable framework? If Gstreamer goes the wrong direction and disagreements break out between gnome and kde as to the direction of the project devs then what? It becomes another arts, not for gnome but for kde because their mm framework is not syncing up with the direction their desktop is going.
What I don’t get is that the gstreamer devs pretty much are saying “don’t worry, that won’t happen. We’ll be here for years to come, gstreamer will be awesome and everyone will hold hands and sing we are the world”. Until the time comes when gstreamer proves that why not be cautious and allow kde to allow any mm framework to be used. It doesn’t affect gnome in anyway and kde user’s can pick the mm framework that best suits their needs. When the time comes and if gstreamer or nmm or helix or jack become the obvious choice then phonon will be put to pasture and the best solution will be used.
7 years after the start of gstreamer project, it still is slow, incomplete and crashy…
For me the key issue is that Xine will do 7.1 audio output. So far the best I have gotten from Gstreamer is stereo and when I have looked online it seems that greater then stereo output is something planned for in the future.
@kosh
Current GStreamer do have multichannel sound. I have only tested Dolby AC3 5.1 so I can’t say for sure that 7.1 works, but any testing and feedback you can provide would be appreciated.
For me it feels that many comment authors here have tried Gst 0.8 version, even very old ones. Yes, 0.8 was extremely buggy and unsuable. 0.10 is very different story. But I say it only as side note :)
Kosh: Gstreamer certainly do multichannel (5.1, 7.1, etc.) sound, as I can watch AC3 movies with my multichannel (eight, actually) card just fine :)
Christian:
I respectfully disagree. ;)
I’ve posted my (lengthy) objections in blog form at http://grammarian.homelinux.net/~mpyne/weblog/kde/phonon-whineage.html
The short story is that this is the only way we will be able to maintain binary compatibility. In other words, we’d like to be able to track gstreamer as you guys develop it instead of being stuck with 0.10. (Would you guys like to develop 0.10 for 5 years? Didn’t think so. ;)
Once we have a layer such that we can maintain binary compatibility, then there’s other stuff we can do which makes sense. But Phonon isn’t a MM framework like gstreamer or NMM, it’s the way we at KDE get out of trying to maintain a MM framework.
And just another reason why desktop Linux is a failure. Total fragmentation, NIVH, no ad-hoc standards, fanboy wars that look like hormone-induced teenage girl gossip-fests.
The question is when will someone come along and put a real desktop on Linux and kick all this Gnome and KDE shit to the curb once and for all, because neither of them is going anywhere.
KDE folks have the right to feel the way they do after getting “burned” by arts and the recent gstreamer change.
But, deciding on doing something like Phonon, it’s an overreaction to the facts.
When 2 people have problems, either they sit and talk about it and solve it together, or they leave and do it their own way. The first option is and always will be the best option.
So there is an issue with binary compatibility. Let’s talk about it. It’s not like the people developing GStreamer don’t know or don’t care about binary compatibility. Gnome has hounoured a binary compatibility claim (and also KDE) for such a long time, there’s no reason to think Freedeskop devs couldn’t do it too — there’s people doing it in other projects, it is possible.
Please, fragmentation only hurts everybody.
Quoting Tim Beaulen:
“It also lets the user choose whatever he or she wants. If a user likes Xine more than GStreamer, he or she can choose to use it.”
This is something you do NOT want to offer to the user. There is a certain mind twist involved in understadning this, sort of getting out of the wirechamber and up to the desk you are actually sitting at and “just using” an app. You don NOT want a user to choose between audio _BACKENDS_. He can set his audio output card/device, volume, etc, but the backend shouldn’t be relevant at all. I never got why a lot of players support multiple (or some even tons, see Amarok) backends, or even keep the support even though an equally well working one is now supported as well (see Totem).
We believe in GStreamer 0.10 and use and support GST 0.10 _ONLY_ because of 2 major reasons:
1) While it might be not “there” yet, the framework in 0.10 is certainly excellent, it’s just that everything’s still suffering from the 0.8 to 0.10 transition. I very much hope and believe that this will be straightened out in 0.12 at the very least
2) The othe reason is sort of, call it recursive: We believe in it and support only GST 0.10, because that’s what will make it the most successfuly multimedia backend. You can call this “belief in propagation”. IF we use only 1 backend, then we (AND our users) inevitably have to deal with it, and errors will be exposed much earlier and more clearly, and we can propagate them or possibly fix them ourselves and then send in patched code.
Having multiple backends will lead _users_ to switch to another one if one can’t play a file, and will lead _us developers_ to neglect that backend because some other one might play some files better (but we’d never entirely remove it, of course, as it plays some other files again very well)
Something like Phonon seems to me like a futile attempt because of very different reasons than Christian pointed out; unifying backends AND making it possible for the user to choose is a HORRIBLE idea. Bundling them and internally soting out which one to use for playing a particular file is an almost equally horrible idea, but at least somewhat less horrible as you don’t give the user a choice (sic), and can internally evaluate which backend works best and focus on that one, and eventually it will come out as the most usable one (in technical terms).
Cmon guys, this isn’t the time for monkeying. Reptile brain-stream aside, we just have to find what is viable for the future, without personal animosity. We (from BMP) think that this is GStreamer 0.10, and maybe simply because we do believe this and support GST 0.10 only in our player, it will be.
— Milosz
Sorry for the typos and grammatical errors, it’s a tad late.
@Dennis
It is not the author that started a flame war, it is the fanatics/fanboys. All Christian did was state his oppinion (which has many solid points) about Phonon. This article should have been taken as constructive criticism by Phonon developers and the rest of the KDE crew, while they might not take any action in regards to what Christian has state, they should still think about what has been said and take it into consideration.
I myself have misinterpreted the goal of Phonon, as from what is stated on the Phonon website it sounds as if Phonon is a global solution to multimedia access. When in fact it is only meant to be a simple generalised abstraction (providing simple access to basic features). If you have ever programmed before, abstractions are a godo thing. But it still has some issues (regarding underlying MM backends), but generally it is a good idea. Christian (and many others) may have misinterpreted the goal of Phonon like me, who knows? :P
And some people (Heritic ;)) have also misinterpreted my argument in regards to this issue.
quote janne: “The situation is pretty simple, really. If Gstreamer is the best thing since sliced bread, users will use it.”
Sorry if i’m repeating myself: why is everyone stating again and again that it’s the user’s choice to use a particular backend? IT’S NOT! No, really, it isn’t.
We (now speaking as a user, and not audio app developer myself) simply got used to it because in the past, there were a lot of different “backends” that one or the other worked more or less half assed, there was no corporate support and everything was on the verge of getting unmaintained.
So it made only sense for application/frontend developers to give the user the choice to choose between multiple backends and support then but THOSE WERE MISERABLE TIMES and they are f’ing over, cmon people (?)
We have several VERY viable backends at the moment, NMM looks ok at a first glance, i very much prefer GStreamer (see above)..
Janne: There is NO point in making the user choose the backend. “The users” will not choose a particular backend if it’s good simply because this isn’t something they should do.
Also what i see coming is that the feedback from Phonon to the respective frameworks will be horrid at best and non-existant at all. THIS is what it is about.
Think for a second: What makes (except their aggressive, anti-competetive, etc, stuff) Microsoft successful? Because their software (is a buggy POS but also) consistent.
How do they achieve this? They develop everything in house. It’s all one tight package where everything is (in theory) meant to work with each other, and each group inside M$ gives feedback to another, at least in theory. Apple might be a better example of this, or take companies like Nokia.
_SO FOR TO NOT SUFFER FROM NIH ON A GLOBAL LEVEL_ (speaking of “the free software community” as a whole here) we have to work trough propagation. People have to focus on something and propagate feedback whenever something’s not allright. This feedback must be sustained and it must have a certain traffic. Spread the feedback traffic across 5 backends instead of one, and you can almost speak of scattering it.
Posted by Milosz Derezynski at Sat May 13 2006 08:12
“Quoting Tim Beaulen:
“It also lets the user choose whatever he or she wants. If a user likes Xine more than GStreamer, he or she can choose to use it.”
This is something you do NOT want to offer to the user. “
You have to understand WHO the user is.
Who actually downloads KDE, installs it and does the heavy configuration? The desktop user? Of course not, it’s the company that creates a “distribution”, a complete working set of applications, customised like the company wants it to.
All this means is that Suse for example can use Xine as the default multimedia engine and Kubuntu can use GStreamer as the default engine.
Any regular desktop user will not change those.
And by the way:
If the developers of GStreamer want KDE to fully support GStreamer without using Phonon, that would be awesome. But, that means that the developers of GStreamer themselves need to put all the effort into doing this. Don’t expect KDE to keep up to date with GStreamer. That’s the world upside down. At the moment, I can imagine that fully supporting GStreamer would take a lot more time, time that can be used for other more important things, like actually getting KDE4 to work.
What I want to say is, if the GStreamer developers realy want excellent support of GStreamer in KDE, they should ask for a KDE SVN account (if they don’t already have it) and start commiting patches, keep GStreamer up to date and binary compatible for maybe the next 6 or 7 years (untill work has started on KDE 5)
I just wish all major desktop environments used the same multimedia framework.
KDE has its own, Gnome has its own, so when it comes to write an app that works fine on both, it gets messy.
The ARTS situation and others like it, where a piece of software becomes “unmaintained” and so support for it is dropped, I find both surprising and amusing.
I thought one of the supposed advantages of open source software was that one would not be held to ransom by the original supplier – if they were to lose interest, someone else can take the code and resume development. Odd that this often does not happen. ARTS and DevFS spring to mind, but there are others. It seems that besides the NIH syndrome, there is also the DWWOPC syndrome (don’t want to work on other peoples code!).
Witness also the duplication of effort going on with Linux distros. There definately seems to be a reluctance on the part of many developers to use any code other than that they have written themselves. I imagine lack of documentation and may be a significant factor, making learning how the code works and subsequent development very difficult.
This is a real shame. All this code lying around and going to waste – tens of thousands of man hours of work going to waste.
Im with the original author on this one – instead of writing yet another framework, why not work together on one that is already very close to be fully useable and has a bright future, namely GStreamer. We dont really need yet another API.
I think the problem is that free desktop users are just plain tired of so many incompatible multimedia frameworks. I mean, AmigaOS had a better framework than Free Desktops had, way back in ’92 or so. Important VIDEO apps like blender still don’t support generating video in a large range of formats on free desktops, even though it can do it on windows and OS, just because there is no standard way to do it on Linux.
I know GStreamer isn’t perfect, but the point is, NO framework will ever be perfect. It seems to be pretty good though, and when everyone gets behind it, it’ll get better, as people implement the features they need.
On the ABI compatibility thing… well, if you want a simple interface to play a sound, then by all means go ahead and write the method/function. But a whole framework (even a simple one), that hedges bets and supports a lot of backends is just bloat and fear of commitment. Choose something, and go with it, I say.