Why Phonon is a broken wheel
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.
May 11th, 2006 at 9:37 pm
Have to agree - I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE). I can understand their dislike of Glib’s duplication and the somewhat absurdity of the hackish GObjects but as you say this can be wrapped away in QT bindings.
In the interests of freedesktop viability, I would love to see Gnome include QT (the newer leaner cut down version) and KDE include Glib in their respective platforms. Its almost imposible to produce beneficial freedesktop software without needing either Glib/QT abstractions for things like mainloops, threads, DBUS connectivity etc. IMO, KDE has enough work to do with getting KDE4 out before Vista rather than having to waste time abstracting away things like HAL, GStreamer and other freedesktop stuff.May 11th, 2006 at 9:48 pm
So, basically we have a GStreamer-developer telling everyone that Phonon is a bad idea, and that they should just use GStreamer instead?
Well, color me surprised!May 11th, 2006 at 10:39 pm
@ Janne:
Is the point not that Gstreamer is one of the backends Phonon is designed to abstract, but abstracting is pointless when applications will no doubt require access to the low level bits and bytes. The abstraction will get messy and require hacks for each supported “pluggable” backend.May 11th, 2006 at 10:44 pm
Quote Jamie McCracken:
Wrong, the point is to have a stable API during the lifetime of KDE 4. GStreamer probably can’t provide that. 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. @ Christian Schaller Phonon is intended for the usual desktop applications. Playback of multimedia, recording and some simple effects.“I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE).”
I don’t think it’s intended to be used in professional multimedia applications as those applications do have very different needs. It’s like saying that GTK or Qt is not good enough for multimedia because they don’t contain a good enough multimedia api. That’s why you have GStreamer.
May 11th, 2006 at 10:59 pm
@Tim Beaulen: If Phonon is really just for standard playback/other simple desktop applications, then this part of Christian’s post seems all the more relevant:
“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.” I think the _possible_ benefits of sanctioning GStreamer as the multimedia backend for non-Phonon-based apps are many, but what would you think of giving a stamp of approval like that to non-Phonon apps? Any hesitation I have about it is squashed by the fact that GStreamer is really the only viable multimedia framework for things like video/audio editors at the moment (and the forseeable future).May 11th, 2006 at 11:06 pm
@ Brad Griffith
It makes no sense for KDE to define a “standard” for programs that can not use Phonon for some reason. Most, if not all programs that are included in KDE will be able to use Phonon. Special programs, that are developed outside KDE (but use KDE api’s) are the responsibility of the developers of those programs. If they want to use Xine instead of GStreamer, that’s their choice, not KDE’s choice.May 11th, 2006 at 11:12 pm
@anonymous
If that is the position that you want to take, I believe (along with Christian, if I am reading him properly) that it will be to the disadvantage of the KDE community.
Firstly, as far as the basic playback needs go, most users can’t even tell the difference between xine playing an MP3 and gstreamer playing an MP3. It should be irrelevant and the most expedient technical solution should be taken. And have a standardized framework would be more expedient than any marginal advantage one framework would have over another.
And secondly, for the apps outside of KDE base (and I suppose we’re assuming KDE won’t ever officially incorporate a video editor/audio editor/streaming server/etc.) it would benefit the community and the developers, again, to standardize on a framework (the only viable option currently being GStreamer). It’s not as if developers outside the respective GNOME and KDE cathedrals can’t choose to cooperate to better the community. It’s about time they did, so we can stop all the foolish duplication of effort and move forward as quickly as our community has the potential.
May 11th, 2006 at 11:26 pm
Anyway, what the difference between phonon and a kde/qt binding with gstreamer ? except that in the future (even in the present, after all), it would be possible to get ride of gstreamer, if it dies or something better come up ?
May 11th, 2006 at 11:39 pm
The point is not to depend on one system. Thats what happened with arts, if Gstreamer ever became unmaintained and fell the way arts did then kde would be stuck with it, much like its stuck with arts until kde4. Phonon will allow users to have a choice of using gstreamer, jack, nmm etc. The “lets all just use Gstreamer” mantra is just hilarious. Plus gstreamer .10 isn’t really a stable quality release and is missing features (dvd). I like the way kde is moving along with this, a dependency on one thing and one thing only is just riddled with failure. Kde seems to be moving along at a rapid pace with phonon, solid, plasma and tenor. I don’t see anything even remotly as cool as those projects on the gnome side. So instead of whining on how “its not gstreamer”, fix the stuff gstreamer doesn’t have and make it the one clear choice. As of now I wouldn’t use gstreamer, just too unstable and has too many quirks to deal with.
May 11th, 2006 at 11:40 pm
@Cyrille Berger
I think the primary difference would simply be that phonon can’t really encompass the full functionality of something like Gstreamer and still be capable of creating any really interesting/complicated apps.
And the odds that a new framework would fit into phonon well enough to not require major changes to phonon and still be able to create complicated apps are too miniscule to even be worth considering. I think the point is that wrapping multimedia frameworks for anything more complicated than a music/video player is futile. And the benefits of something like phonon for simple playback apps are dubious at best (seeing as the frameworks all pretty much do the exact same things and any one of them could be enhanced to do what the other can without too much effort).
May 11th, 2006 at 11:56 pm
@Everyone
If people think that phonon is anything else but another symptom of the “not-invented-here” syndrome then…….. @HereticI am really excited by the smoke-and-mirrors that is KDE4 and phonon. I enjoy the consistant duplication of effort in FOSS
Arguments like “what if Gstreamer stops being developed” are rediculous. Gstreamer is in the good position of being shipped on a number of commercial devices, and being worked on by many paid developers. It is in a VERY stable place right now. What if the Linux Kernal “became unmaintained and fell the way”………. As for “too unstable and has too many quirks to deal with”. Do you think when they release v0.0.1 of phonon it will be perfect? Ha!
May 11th, 2006 at 11:58 pm
@Cyrille
@hereticRegarding the difference between bindings and Phonon. Phonon’s official statement is that it is a limited API targeted at specific types of applications. I don’t think anyone claims its possible or even less contemplating making a full featured abstracted API that encompass everything for instance GStreamer and DirectShow does across these and other multimedia toolkits.
Your ‘what if GStreamer went unmaintained’ is about as valid a point as asking ‘what if Qt or kde-libs went unmaintained’. Can it happen? Yes. Is it likely? No. GStreamer is not missing DVD functionality either. If you want a GStreamer DVD player using 0.10 grab ‘http://seamless.sourceforge.net/‘. Being able to play DVD’s with GStreamer is not equal to being able to play DVD’s in Totem.
May 12th, 2006 at 12:08 am
What is wrong with kde4 depending on gstreamer 0.10 for its full release cycle? GStreamer 0.10 is not going to break API/ABI. Also, there is more likeliness that Phonon will become unmaintained during the kde4 cycle than GStreamer itself if that is a worry.
There are many users of GStreamer 0.10 outside of Gnome and even outside of the free software community.May 12th, 2006 at 12:21 am
@Johnson
Oh come on! “Not Invented Here”? They are basically giving the users (end-users, distributors, you name it) the means of choosing a multimedia-backend that THEY want to use (instead of being dictated by KDE). And they want to make sure that no matter which backend they use, it will work nicely with KDE. And now you march along and complain that this is NIH-syndrome at work? How come? They are not requiring you to use “created by KDE!”-framework, they are letting you choose the framework you want to use. And those frameworks are created by someone else than KDE. If anything, this is the complete opposite of NIH! KDE got bitten by Arts-situation pretty bad. They moved to Arts, and after a while, they found that they were relying on a piece of software that was basically unmaintained. Last thing they want to see is for that situation to repeat itself. How can they be sure that Gstreamer wont move in to direction they disapprove of? What is Gstreamer-hackers suddenly become interested in something else? What if Gstreamer-folks one day say “YOu know, we really do like GNOME more than KDE, so we will just focus on GNOME from now on”? It would be Arts all over again. With Phonon, that could not happen. @Everyone IIRC, KDE-developers have commented on Gstreamer, and it seemed to me that they thought that it was unsuitable for “one framework to rule them all”, as far as KDE is concerned. I believe they complained about API-instability, C++-bindings and the like (if I got those wrong, blame me, and not the KDE-devels. I might be remembering this wrong). And I for one find it really strange that we have people basically saying “everyone should just use the same stuff”. Um, no. That’s the way things are done in Windows. I for one welcome the competition, no matter if we are talking about desktops or multimedia-frameworks. If at some time in the future it becomes apparent that Gstreamer is marching all over the alternatives, then KDE could start using it as the default, maybe bypassing Phonon entirely. But as things are now, that has not happened yet, and there’s nothing wrong with keeping your options open. And why Gstreamer? Why not NMM (for example)? Gstreamer is not the “be all, end all” of multimedia-frameworks. And before anyone calls me a KDE-fanboy: As it happens, I’m currently using GNOME, and I like it.May 12th, 2006 at 12:24 am
@Christian
Then there are the features, gstreamer is not a complete solution. For instance it doesn’t have the networking multimedia capabilities of nmm. What if I wanted to setup a video wall or simultaneously play movies across several pcs which have a mix of OS’? With nmm I can do that with gstreamer I can’t (not even close), what if I want the stability of Xine or the sound quality of helix?. I hate the assumption that gstreamer is the one all end all solution. It simply isn’t. Why shouldn’t people have the choice instead of locking them in. Its just a mentality of “user’s don’t really know whats best for them so lets decide for them”. Its entertaining to watch gnome with the “lets keep cutting down features cause we don’t think anyone needs them” mentality but when they demand others do the same. As far as kde 4 being smoke and mirrors, wheres the next generation DE that is gnome? oh whats that? there is none. The roadmap and cvs commits for phonon, solid and plasma are moving along fine. The only thing that seems to have stalled is tenor.Yeah all is well now but the same thing happened to arts, it was fine when it was started then it came apart. Sure everything is roses now but like a lot of open source projects it may suffer from lack of time, money etc. What the basic stance is, don’t worry Gstreamer is great now and it will always be great. Uh sure, its not even great now.
May 12th, 2006 at 12:28 am
(Disclaimer: GStreamer developer speaking)
I came across this the other day, and I think it applies to wrappers like Phonon is going to be one as well: http://www.ozlabs.com/~rusty/ols-2003-keynote/img30.html A simple abstraction that is geared towards simple audio/video playback can be done, but it is not going to be very useful. It’s nice and all, but ‘multimedia’ apps in a few years time will need to do much much more than just play back stuff. For everything more complicated, the abstraction will suck and will limit KDE developers more than it will help them to write kick-ass applications for the desktop of the future (whatever that means). IMHO deciding on a framework - any framework, even if it is not GStreamer - and throwing the full support of the KDE developer community behind that would be much better for KDE in the long run.May 12th, 2006 at 12:37 am
@Heretic
The difference between GStreamer and Arts is that there is a big development community behind GStreamer, while arts was mostly a one or at most two person effort through its hole lifetime. Phonon is more likely to go unmaintained than GStreamer due to this. Regarding the videowall and simultaneus playback across multiple machines. Both have been done with GStreamer and can be done again. Having multiple GStreamer applications running on multiple computers inn a network sharing the clock provided by one (in order to keep in sync) was a feature added quite some months ago. And I never heard anyone claim that Helix has particular sound quality before
May 12th, 2006 at 12:51 am
@Christian
I have never seen gstreamer do networked multimedia as seamlessly as nmm does. Maybe i’m not informed on this but at linuxtag and cebit nmm really impressed me on how easily it was done. As far as Helix and Xine is concerened I know of a lot of people that swear by them. It would be thoughtless of developers just to use gstreamer despite of hundreds of other users preferring other solutions. Plus one thing I have not seen with Gstreamer is you can’t set application based volume control where with phonon it seems that sys notifactions will be medium to low even though you have a movie blasting out of speakers. Phonon’s thinking seems to be out of the box, taking advantage of an open source model (different solutions for a problem and the user can pick which solution fits him best) rather than the windows/macos way (Our way or the highway).
May 12th, 2006 at 12:53 am
@Janne
I don’t thing GStreamer *focuses* on gnome. It focuses on media processing and of course when using C and GObject it just fits. But if there would be mature QT style C++ binding available, this could be like any other KDE api. About the why GStreamer and not NMM or any other: Sometimes providing choice can be a very hard task. There is nothing wrong with projects like NMM. But personally I think its better to make a choice and if the project loses momentum, contribute to give momentum back. While most media APIs follow similar concepts, there are major differences among them as well. Designing and maintaing a unfied umbrella API is a major undertaking.May 12th, 2006 at 12:54 am
@everyone
Even though gstreamer has big community and according to some will never go the way of arts, there is the question of the direction of the project. At some point kde devs may not agree with teh direction gstreamer is heading or gstreamer devs may refuse to implement a feature that kde devs sorely need. At that point gstreamer would be a half assed solution. With phonon you can simply switch to a different backend with minimal fuss.
May 12th, 2006 at 1:07 am
@Heretic
I think you should start suggesting that KDE switches to wxWidgets and adds a Qt backend to wxWidgets. That way KDE users can choose between Qt and Gtk+ for their applications. It would be thoughtless of developers just to use Qt despite of hundreds of other users preferring other solutions.
May 12th, 2006 at 1:28 am
@christian
So by your logic there should be one mp3 player, one bittorrent client, one cd burning program etc because user’s really don’t need to have a choice? (I can go to the extreme tooTheres a difference between a toolkit and multimedia framework.
May 12th, 2006 at 1:43 am
Don’t forget the USERS.
If in the future I will be wanting to use both Gnome and KDE applications there will be “everything” doubled right? Just as it is today. Two basic widget frameworks, general support libraries, two audio frameworks, and so on.. Nice wasting of memory. Nice trying to get 2 “sound servers” working simultaneously as well. Nice wasting of hard drive space. That’s user perspective: heavy installation, heavy desktop. I couldn’t give a * about what developers like about their multimedia frameworks as long as they can produce nice working things. What I care about is interoperability. The truth is that living with 100% only KDE OR Gnome exclusively is hard. You want to be able to mix them. There aren’t tools available for everything in both of them. Both KDE and Gnome using the same framework would make also user’s life easier in the long run. It would make it more enjoyable. What I care also about is not re-inventing the wheel. NIH symptom is dangerous and I partially smell it in Phonon. It’s absolutely horrible that you hear someone developing some nice new thing, support for new stuff, applications.. But you’re on the “wrong side of the fence” as the user. Change your desktop and/or tweak a little bit.. And notice being again on the wrong side, not being able to get it all. Argh. It’s horrible tbh.May 12th, 2006 at 1:52 am
From the KDE side of the fence, Phonon is looking like another arts.
May 12th, 2006 at 1:57 am
@Anonymous
What NIH syndrome? you’re basicaly saying that the KDE devs doesn’t want to use Gstreamer because it’s a GNOME tech ?(btw isn’t Gstreamer a freedesktop project just like DBUS why is everyone assimilating them to Gnome?) Phonon allow people to use any multimedia framework (including Gstreamer) and is there so they can shut down arts, a KDE thing…. So please stop with the NIH thing… Also phonon isn’t a sound server your Gnome/KDE application will most likely use the same gstreamer/alsa/jack/nmm etc…And what do you want anyway? for KDE to use GTK??
May 12th, 2006 at 1:59 am
@anonymous
I don’t really see how Phonon forces you to use two audio frameworks. You could have a mixed KDE/GNOME desktop, where GNOME-apps use Gstreamer, while KDE-apps use Gstreamer through Phonon. There, just one audio-framework being used. What is the problem here? And I haven’t seen any any tangible explanations on how Phonon is NIH. Phonon basically empowers the end-user choose the framework he prefers, period. How on earth is that “NIH”?May 12th, 2006 at 2:06 am
@heretic
And as for one of each type of application. Well AFAIK KDE do provide only one of each type of application. Sure there are other KDE using clients available, but KDE provides only one as ‘part of KDE’, all others are optional. And if KDE chose GStreamer as its media framework wouldn’t mean that applications made using other multimedia toolkits would be impossible or cease to exist. It would just mean that with GStreamer there would be a lot of extra services built for application developers and system level integration done, just like what has and is happening with GNOME.toolkits or frameworks are created for the purpose of giving developers building blocks to create applications. GUI toolkits provide building blocks to create GUI’s and multimedia toolkits provide building blocs to do multimedia processing. They are different, but many of the logical justifications for standarizing on one are the same.
May 12th, 2006 at 2:08 am
@everybody
The situation is pretty simple, really. If Gstreamer is the best thing since sliced bread, users will use it. At some point the KDE-devels would notice that “all our users are using Gstreamer. why do we need Phonon anymore?”. At that point they could move to straight Gstreamer. Phonon basically enables the frameworks to duke it out, untill the best one is left standing. And that’s IMO alot better than making a “political” decision. And, as things are today, no framework can please everybody. Let the users decide. Let the best framework win.May 12th, 2006 at 2:08 am
@everybody
The situation is pretty simple, really. If Gstreamer is the best thing since sliced bread, users will use it. At some point the KDE-devels would notice that “all our users are using Gstreamer. why do we need Phonon anymore?”. At that point they could move to straight Gstreamer. Phonon basically enables the frameworks to duke it out, untill the best one is left standing. And that’s IMO alot better than making a “political” decision. And, as things are today, no framework can please everybody. Let the users decide. Let the best framework win.May 12th, 2006 at 2:28 am
Since KDE is being ported to Windows and MacOS X, using a framework that can plugin to the music APIs native to those platforms makes sense.
May 12th, 2006 at 2:29 am
@Hildo
agreed, and GStreamer is already ported.
May 12th, 2006 at 2:32 am
@christian
I didn’t say it was impossible for other apps that use other mm frameworks would cease to exist. Its the level of difficulty involved. Phonon would allow me to switch on the fly and integrate nicely with solid. Instead of dealing gstreamer and attempting to do something gstreamer doesn’t do particularly well I can switch to a different backend, do my stuff and switch back to gstreamer if I wanted. It simply boils down to what user’s what and saying “user’s don’t know if its xine or gstreamer or nmm playing their mp3″ is not giving credit to user’s of linux. I initially disagreed with linus when he said that gnome devs were treating their users like idiots but this is a prime example. I switched to KDE primarily for the speed but KDE gives more control over the desktop where as gnome decides for me. Now that i’m fully comfortable with KDE I can’t go back to gnome and its lack of options. Now gnome devs are telling kde to be more like gnome and cut more options. If the solution in mind was the best available solution I wouldn’t mind but its not, gstreamer is nice but its far far far from being the best choice for KDE.Umm kde actually provides a lot of different apps for the same solution (one only need to look at kde-apps to figure that out)and its not KDE that decides what apps are available, its the maintainers of the distro in question.
May 12th, 2006 at 2:36 am
Heh, you say you didnt say it sooner for fear of flame, and those are not going to be caused now ? And whats wrong with removing glib as a depends ? Developers dont want kde to depend on any gtk/gnome component, whats wrong with that ?
And, no, GStreamer is not “the best thing since sliced bread” .. just look at the gst engine for amarok. No crossfading when switching between songs, and HELL SLOW, on p3 550mhz. Yes the pc is slow, but xine engine works perfectly ! Ofcourse gst might be cleaner and have a better licence, but unless I get a faster pc, no sir. Point is, ranting about why kde phonon is good or no, wont help you or anyone else. Kde will still use phonon, users might still like it. People will still use gstreamer, and might like it. And life goes on.May 12th, 2006 at 2:39 am
Though I am not a developer I like the idea to choose
which audio system to use. Currently I run KDE on a
slow laptop, and gstreamer does simply not work as
i expect it. Thats why i use xine, which works fine.
Currently i have to configure programs like
kmplayer and juk to use xine manually, while i have
no sound in konqueror (since arts is annoying and
uses my precious memory).
I would be happy to centrally configure a sound
engine for all kde programs.
May 12th, 2006 at 2:47 am
@Heretic
“Umm kde actually provides a lot of different apps for the same solution (one only need to look at kde-apps to figure that out)” I believe the point was that KDE-project itself only gives one app for each task (text-editing is the odd man out here). Of course there are third-parties out there that provide additional apps that do the same thing, but those are not part of “base-KDE”. KDE-project gives you only one filemanager: Konqueror. But there are third-parties out there that provide additonal filemanagers (Krusader). KDE provides you with one music-jukebox: Juk. But there are third-parties that provide you with additional jukeboxes (Amarok).May 12th, 2006 at 2:47 am
I respect your opinion but I’m glad KDE have chosen that direction and that Phonon is being developed.
What they are doing is nothing new. Have you ever used Amarok? It lets you choose the multimedia framework to use. If they forced me to use GStreamer probably I will not use AmaroK since as of now, GStreamer 0.10 is buggy as hell and it does not support as many formats as Xine. But Amarok lets me choose the backend I want to use and now I find Xine better for my needs. The same goes for Totem, the first thing I do in my Ubuntu install is to apt-get install totem-xine,w32codecs,libdvdcss because I want to see restricted format videos like wmv,mov or encrypted dvds and Xine performs better and supports way more codecs than GStreamer. If some time in the future this changes, I can switch back to gstreamer, just because they support both frameworks. If they have chosen one or another and the chosen one was worsen now or in the future, it may mean the end of the application itself, because everybody will use another application with the better backend.
Phonon will extend what Totem and AmaroK are doing right now to the whole KDE platform, so applications can use Phonon+[Xine,GStreamer,Helix,…] or the multimedia backend directly, if they choose to do so.
May 12th, 2006 at 3:04 am
FYI: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
May 12th, 2006 at 3:10 am
@jose
For a little better explanation:The application has to develop specifically to that framework. The application has to support it, if the app doesn’t support it then you’re out of luck. The only reason u can pick gstreamer in amarok is because the amarok devs created a gstreamer engine. But with phonon u can just develop to one framework (phonon) and then let phonon pass that info to whatever backend you want. That way application devs don’t have to worry about supporting different framworks in kde, they can just develop for phonon and phonon will pass it on to whatever u want to use. Plus devs don’t have to use phonon it allows them to access the backend directly as well. So on a system wide basis, phonon is does is completly new.
http://applications.linux.com/applications/06/05/05/1540250.shtml
May 12th, 2006 at 3:14 am
Well, with what ac posted, this is just turning into a phonon vs. gst , and will soon turn into a kde vs. gnome flame. Hang on for the ride, guys (yet again) !
Btw, imo, jose has provided a much more unbiased view of phonon. Ofcourse the original author of this post cant, since he is a gst developer himself.May 12th, 2006 at 3:29 am
Xine has a license advantage to GStreamer: Xine is GPL and enjoys the full copyleft protections of the GPL.
http://www.gnu.org/copyleft/ The Free Software Foundation warned about the dangers of using the LGPL, but GStreamer developers didn’t listen, instead chosing to SELL OUT their users to the entertainment cartel: http://www.gnu.org/philosophy/why-not-lgpl.html Xine users can be assured that they will always be able to remove the DRM from any crippled plugin, since the GPL ensures that all plugins must be open Source. Go Xine, Go GPL, Resist draconian DRM!May 12th, 2006 at 3:39 am
@Jose,@rohan:
As for Aaron’s post I respect his opinion, but I think he might get his black eye just as easily from Phonon as from GStreamer. arts failed IMHO due to lack of developers and probably the developers involved having too little experience outside the audio field. That could very well turn out to apply to Phonon too. Aaron’s comments about platform portability are totaly off target. GStreamer already runs on those platforms and if you add to the current plugins with for instance a dll loader plugin on Windows then you have a full featured solution. Its also funny that he thinks Phonon will cover the needs of 99+% applications, when the Phonon developer thinks its around 80%Actually I think Jose comments underscores my point more than counters it. Amarok has multiple backends and the problem with amarok recently was that Markey didn’t have time to maintain the GStreamer backend anymore and it wasn’t until very recently a new maintainer came in and took over. If it was GStreamer and not the GStreamer amarok backend which was buggy as hell then also Rhythmbox and Banshee would have the same issues, which they don’t. In two months it might be the Xine backend not getting enough love and the GStreamer backend being the only one working for Jose. And I don’t see that as a verification of the multibackend strategy as the problem arise mostly due to trying to support multiple backends and developer resources to properly do so isn’t available.
May 12th, 2006 at 3:55 am
Phonon is about making things transparent and easy for the end-users. We don’t have to dictate that they have gstreamer installed; rather, we’ll fold seamlessly into whatever funky configuration they’re running.
Phonon is as much about the users as it is the developers.May 12th, 2006 at 4:07 am
It’s not a matter of numbers, Phonon is designed to support the development of the vast majority of mutimedia applications for the DESKTOP. Professional tools are not desktop applications at the moment so they must use the multimedia backend directly but most of the media players will need only Phonon.
As for the poor support of Gstreamer in AmaroK: Again for me (the user) is easier to change Xine for Gstreamer setting in Amarok than changing Amarok for a lesser featured player just because Amarok only supports one backend and that backend doesn’t work well. The same could be valid for KDE/GNOME/XFCE/whatever other DE.@Heretic
From a user point of view, Phonon it’s just the unification of efforts of what Amarok, Kaffeine, Totem and some more developers have been doing separately. From KDE4 and on, they don’t need to worry about the backend they are supporting, they support Phonon and the backends Phonon supports. Just as I can choose right now between Xine and GStreamer for Amarok, Kaffeine and so, tomorrow I will choose between them just in one place, but the effect, to me (the user) will be the same.
May 12th, 2006 at 4:10 am
@Christian
“As for Aaron’s post I respect his opinion, but I think he might get his black eye just as easily from Phonon as from GStreamer. arts failed IMHO due to lack of developers and probably the developers involved having too little experience outside the audio field. That could very well turn out to apply to Phonon too.” Well, from what I have heard, Phonon is quite easy to handle. It’s not a humungous beast like aRts is. Even if every single Phonon-developer quit, maintaining Phonon would be order of magnitude easier than maintaining aRts is. And who is to say that Phonon will fail, whereas Gstreamer will succeed? What if Gstreamer turns in to another Xfree? Remember: Xfree had lots of developers as well. Better yet: what if it turns in to another HURD ;)? What if one year from now someone releases a kick-ass audio-framework that absolutely mops the floor with Gstreamer? KDE could easily take advantage of it, whereas GNOME would be stuck with Gstreamer. Of course you will say that “Gstreamer is not going to fail!”. But that doesn’t really say much, now does it? aRts-developers propably said the very same thing back when they released aRts. “Aaron’s comments about platform portability are totaly off target. GStreamer already runs on those platforms and if you add to the current plugins with for instance a dll loader plugin on Windows then you have a full featured solution.” I can’t help it but your arguments sound like “I’m a developer of $APPLICATION, and I think that everyone should use $APPLICATION instead of $SOME_OTHER_APPLICATION!”. Like I said, if Gstreamer really is so great, then users will use it with Phonon, and sometime in KDE4.3 developers would notice that everyone uses Gstreamer, so they might as well use straigh Gstreamer, instead of going through Phonon. And if Gstreamer really is that good, then you have nothing to worry about, right? Instead of saying “KDE should just force their users to use Gstreamer!”, why not give them the choice of using a framework of their choice? Let the users vote which framework is the best. Let the users choose, instead of forcing some particular project on to them.May 12th, 2006 at 4:28 am
@Everyone
If there is a QT binding to GStreamer then you will get some degree of insulation from ABI instability (I see no eveidence that there will be any mind you!) and a nicer snugger KDE fit. So to me it seems like having a nice stable API should not even be an issue in this case. As for splintering your scarce media resources across multiple frameworks, it should be obvious that concentrating your efforts on one framework (even if its not perfect yet) is a far better long term solution. Likewise if Phonon is just a stop gap until you get the confidence to take the plunge with GStreamer then thats cool too. Afterall the argument here is more about the long term solution than a short term one.May 12th, 2006 at 4:33 am
@Jamie McCracken
“As for splintering your scarce media resources across multiple frameworks, it should be obvious that concentrating your efforts on one framework (even if its not perfect yet) is a far better long term solution.” Exactly.That’s why developers who don’t need exotic multimedia features can rely on Phonon only and don’t need to worry about any other framework.
May 12th, 2006 at 4:35 am
@Jamie
lol like arts?“As for splintering your scarce media resources across multiple frameworks, it should be obvious that concentrating your efforts on one framework (even if its not perfect yet) is a far better long term solution.”
May 12th, 2006 at 5:04 am
@Jamie
“As for splintering your scarce media resources across multiple frameworks, it should be obvious that concentrating your efforts on one framework (even if its not perfect yet) is a far better long term solution.” So we should put all our eggs in one basket? So why work on Gstreamer, why not concentrate on improving aRts (or NMM)? When are GNOME-developers going to stop working on GNOME and work on KDE instead? I mean, concentrating efforts on one thing is a good thing, right?May 12th, 2006 at 5:17 am
@Janne, Tim, Herectic
Crieteria to use for choosing a framework: 1) Techincal merit2) 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.
May 12th, 2006 at 5:28 am
The posts from people saying “what if GStreamer suddenly goes away” are ridiculous. At this point Phonon has a bigger chance of “going away” or “becoming unmaintained” than GStreamer has. Anything can go away in theory. What if QT goes away ? Basing the future of your own project on the possibility that something else goes away will make you achieve nothing in the end.
I would be surprised if Phonon can manage being both more API-stable than GStreamer while at the same time provide even the simplest of media features to applications. Getting an API-stable Phonon is definately possible if all it provides is Phonon::play_uri(). However, few applications will use such an API. I’ll be interested to see where Phonon ends up drawing the line for its API and how long applications will be satisfied with it. I wish the Phonon developers good luck, they have an ambitious plan. But the supporters of Phonon will have to come up with a lot better arguments than “What if X goes away” @ Janne: 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.May 12th, 2006 at 5:34 am
@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.May 12th, 2006 at 5:35 am
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.
May 12th, 2006 at 5:37 am
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 crazyMay 12th, 2006 at 5:41 am
@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.May 12th, 2006 at 5:43 am
“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”?May 12th, 2006 at 5:43 am
@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?May 12th, 2006 at 5:45 am
@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.
May 12th, 2006 at 5:46 am
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.May 12th, 2006 at 5:48 am
Some thoughts:
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.*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
May 12th, 2006 at 5:52 am
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.
May 12th, 2006 at 5:54 am
@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!May 12th, 2006 at 5:56 am
@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.May 12th, 2006 at 6:31 am
Meanwhile, there’s should be some reasons for people not to choose (or rely
In my case: I was subjugated by the good comments and intention aboutonly on) Gstreamer. Get off you’re self convictions of excellence and
look around.
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.
May 12th, 2006 at 6:42 am
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.May 12th, 2006 at 6:53 am
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).May 12th, 2006 at 7:03 am
I dont want to use gstreamer. Do I have to remove speakers from my computer now?
May 12th, 2006 at 7:15 am
The gst/phonon debate is basically this:
How many pairs of gloves can we wear and still be able to crack an egg?May 12th, 2006 at 7:43 am
“How many pairs of gloves can we wear and still be able to crack an egg?”
6May 12th, 2006 at 10:49 am
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 …May 12th, 2006 at 10:55 am
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.May 12th, 2006 at 11:06 am
@Heritic
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.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).
May 12th, 2006 at 12:27 pm
@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.May 12th, 2006 at 12:30 pm
@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/72May 12th, 2006 at 1:09 pm
@Heritic
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 meThats 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.
May 12th, 2006 at 3:44 pm
@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*.May 12th, 2006 at 4:25 pm
@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.
May 12th, 2006 at 5:24 pm
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.May 12th, 2006 at 5:56 pm
@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 tellingMay 12th, 2006 at 6:03 pm
@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 authorAnd 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…
May 12th, 2006 at 6:16 pm
@dude: you do know that KDE4 is going to use DBUS, do you?
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.May 12th, 2006 at 6:48 pm
@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.
May 12th, 2006 at 6:52 pm
@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 coverageMay 12th, 2006 at 8:28 pm
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.
May 12th, 2006 at 9:28 pm
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.May 12th, 2006 at 9:55 pm
@Stefan Kost
@Thomas Vander SticheleI 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.
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.
May 12th, 2006 at 11:40 pm
7 years after the start of gstreamer project, it still is slow, incomplete and crashy…
May 13th, 2006 at 12:18 am
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.
May 13th, 2006 at 12:33 am
@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.
May 13th, 2006 at 12:53 am
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 fineMay 13th, 2006 at 12:59 am
Christian:
I respectfully disagree.May 13th, 2006 at 3:39 am
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.May 13th, 2006 at 10:02 am
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.May 13th, 2006 at 5:12 pm
Quoting Tim Beaulen:
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.“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.”
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
May 13th, 2006 at 5:16 pm
Sorry for the typos and grammatical errors, it’s a tad late.
May 13th, 2006 at 6:02 pm
@Dennis
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?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.
May 13th, 2006 at 6:25 pm
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.May 13th, 2006 at 7:19 pm
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)
May 13th, 2006 at 9:10 pm
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.
May 13th, 2006 at 9:23 pm
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.May 13th, 2006 at 9:39 pm
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.May 13th, 2006 at 11:14 pm
IMHO why worry about whatever KDE selects? KDE is a dead desktop anyway
May 14th, 2006 at 2:55 am
Am I the only one who finds it hilarious that “ABI stability” is being touted as a plus for Phonon? Hello - Phonon is going to be a C++ library and the binary compatibility issues surrounding C++ are so complicated that anybody who goes anywhere near them quickly. gets their asses bitten.
From the perspective of somebody who needs a stable ABI because they are distributing software in binary form, the C/GObject based GStreamer API wins, every time, hands down. The main problem with GStreamer right now is that it can be hard to tell what elements will actually be available … the gst-plugins-good/bad/ugly is a good idea but distributors seem to routinely *change* their contents, so in practice an application that dlopens libgstreamer will actually have no clue what the framework on the users system can do! This problem affects any media framework of course. Also it’s not really clear what happens if a program wishes to redistribute the Fluendo MP3 plugin - right now people have to register to get it, so I guess you’d have to work through the licensing with Fluendo then find a way to temporarily register an element shipped privately with the app (and manage conflicts). thanks -mikeMay 14th, 2006 at 3:02 am
(that’s “the main problem with respect to binary compatibility” obviously … I don’t know what multimedia app developers would identify as the main problem
It’d be nice if GStreamer went “1.0″ at some point, the current status makes it look like a 0.12 will appear at some point.May 14th, 2006 at 9:31 am
I welcome the idea of having the choice to switch frameworks easily and this is the goal behind Phonon. Besides, consider the following situation: GStreamer supports formats A, B, and C. Xine supports B, C, and D. If Phonon allows me to choose a different back-end per format, then I can support all four without any extra effort (of learning a new API and doing Phonon’s integration work myself)!
On a broader note, there’s a reason why today we have so many application choices for some taks. KDE vs Gnome, Firefox vs Konqueror, amoong others. I’m reasonably confident that GStreamer will not go away, but it may make some major choices that I do not agree with. (I am intentinally unspecific here. If I were to mention where Gnome, or Firefox, or whatever other app went wrong for me personally, suddenly it would be a post about *that*, and not the big picture.) Let KDE go in a conceptually different way with Phonon from GNOME with GStreamer. Let’s see how each turns out. Then, we can all chose and use what we like better. Diversity is very important, as any problems one of the two communities may face will warn the other, and in the end improve both. If we stick to one philosophy, we’re autimatically ditching all those potential advantages of the other, which we would never discover. I love choice. I also love the way Amarok will let me choose Xine or GStreamer, and would love to see this idea implemented globally within KDE.May 14th, 2006 at 6:00 pm
This thread is just silly. Phonono is an API to be used by KDE applications for their multimedia needs using different MM backends. GStreamer is a MM backend. If it is wrong for writing an API to use for different bacends, then lets get rid of glibc and concentrate on the API provided by BSD or Linux.
This whole post use just useless arguments about a MM backend writer thinkin that abstracting his backend will hurt his project… For KDE would like to “use your backend” but they don’t like the API you expose, is it wrong for them to “use you backend”, but having an API wrapper? Stop being childish, no one is taking your candy yet. If at the end you backend sucks, fix it or it can easily be replaced. All you need to do is look at what developers are unhappy about, then try to work on a solution. Whining that you backend will be abstracted away (NOTE: Phonono is not even attempting to replace you) is just plain being silly.May 15th, 2006 at 8:09 pm
I prefer gnome simplicity over kde eye-candy. That said, I understand some folks prefer kde eye-candy over gnome simplicity. That’s just fine. People are diverse. That’s a good thing. But I do, personally, prefer gnome, so …
If KDE wants to shoot themselves in the foot with phonon the same way they did with arts, hey, let them. Won’t jiggle my gnome desktop. phonon will have to eventually reinvent the complexity of gstreamer. and, like arts, won’t have the developers to pull it off. So, hey, go ahead with phonom. Then, 5 years from now, we’ll have a brand shiny new kde proposal for a replacement for unmaintained phonon, the same as we have a brand shiny new kde proposal for a replacement for arts. Heaven forbid they should embrace somebody else’s extensive library.