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.
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.
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!
@ 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.
Quote Jamie McCracken:
“I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE).”
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 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.
@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).
@ 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.
@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.
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 ?
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.
@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).
@Everyone
I am really excited by the smoke-and-mirrors that is KDE4 and phonon. I enjoy the consistant duplication of effort in FOSS
If people think that phonon is anything else but another symptom of the “not-invented-here” syndrome then……..
@Heretic
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!
@Cyrille
Regarding 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.
@heretic
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.
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.
@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.
@Christian
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.
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.
(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.
@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 :)
@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).
@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.
@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.
@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.
@christian
Theres a difference between a toolkit and multimedia framework.
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 too :) )
Gstreamer isn’t the best solution for a lot of people that use kde, devs know it and instead of having warring camps they let the user’s decide in a pretty neat way. Gnome guys maybe fine with Gstreamer despite its issues but KDE offers more flexibility
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.
From the KDE side of the fence, Phonon is looking like another arts.
@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??
@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”?
@heretic
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.
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.
@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.
@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.
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.
@Hildo
agreed, and GStreamer is already ported.
@christian
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.
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.
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.
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.
@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).
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.
FYI: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
@jose
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.
For a little better explanation:
http://applications.linux.com/applications/06/05/05/1540250.shtml
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.
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!
@Jose,@rohan:
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.
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% :)
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.
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.
@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.
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.
@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.
@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.
@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. ;)
@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.”
lol like arts?
@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?
@Janne, Tim, Herectic
Crieteria to use for choosing a framework:
1) Techincal 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.
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.