so it is that christian, a gstreamer developer, thinks that kde should bet on a single media engine again as we did with aRts. this would require that we first forget the lessons we've learned and ignore the real-world test cases of amaroK, juk, kaffeine and others.
specifically, the day that gstreamer or any other media engine provides:
- a believable API/ABI stability guarantee that covers kde4's lifespan
- an API that is easy enough to use for casual development (bonus points for fitting in nicely with KDE's API)
- availbility on every platform that KDE supports (that's more than linux; it's even more than open source platforms for that matter)
- a solid user experience
then we can think about ditching somethign like phonon.
we learned with aRts that one size does not fit all and that over time media engine trends change. the ltsp people right now are struggling to find a media engine that does really solid network media, particularly video. i've discovered that gstreamer isn't able to give me a good sound experience for amarok (to state it kindly). and i wonder what the people on macos or windows think?
reality is that different people will pick different things. it's not our job, as a desktop environment and not a systems integrator, to try and dictate the usage of a media engine particularly when it comes at the expense of user experience. we can and should certainly push for standardization by supporting and even spearheading those efforts (ever notice who the main developers in the portland project are?), but reality meets wishful thinking when it comes to multimedia right now.
christian is probably right that the high end of media apps such as studio-quality media creation apps will need more power than what phonon can offer. but for 99%+ of desktop applications out there, that power is meaningless. they don't need something that powerful when it's also sporting a complex, foreign API and only works or is available on 1/N support platforms. this is why most open source desktop apps that could or should have media support tend not to (think: video clips in presentation apps; or audio recordings in note takers).
phonon is providing things like access to basic recording, effects and visualizations; it is more than "just playback" and should cover the overwhelming majority of needs quite well. so let the <1% of applications written that need ultrahorsepower multimedia framework access surf the tumultuous seas of multimedia uncertainty; the rest of the desktop deserves better and we can deliver that to them today.
but something christian obviously doesn't "get" is the benefit of writing an app that works with a "host of media frameworks". christian erected the following strawman: "The reasoning is that no framework 'does it all' so having this flexibility is a good thing." good thing that isn't what we're thinking because that would be stupid. no, the benefit to working with a "host of media frameworks" is that you gain portability both between different operating systems today as well as between the same operating system today and tomorrow. been there done that with aRts and gstreamer isn't any better on that front; then again, no media system currently is.
now ... i can understand how this might be frustrating from a media framework developer's perspective, but perhaps they could step back for a moment and try and understand how frustrating the multimedia world is for a desktop project right now.
honestly, people writing media engines should write media engines instead of trying to politic the desktop environments for their support (gstreamer isn't the only or even worst project in this category, btw). instead how about writing something so good, so solid, so portable and so easy to write applications with it that it becomes the obvious answer and then we can stop having this conversation. and when that is achieved, we'll be right there in a very good adoption position due to phonon not having wedded us to some other media framework. until then, we'll continue to make sure our users, system integration partners and 99% of our application developers are looked after thank you very much.
34 comments:
Well said.
BTW: that would make a perfect podcast.
My experience has been than is much more reliable than GStreamer, and I want to be able to continue using Xine. Other KDE users may want NMM or GStreamer, and it's important that they be given a choice without burdening individual application developers to write interfaces for multiple backends.
Xine has a license advantage to GStreamer: Xine is GPL and enjoys the full of the GPL.
The Free Software Foundation warned against the use of the LGPL, but GStreamer developers didn't listen -- they instead choose to sell out their users to the .
users can be assured that they will always be able to remove the from any crippled multimedia plugin, since the GPL ensures that all plugins must be Open Source.
I encourage all Freedom-conscious developers to stop working on GStreamer, NMM, Helix or any other backend that allows the Media Mafia to ram DRM down consumers’ throats. Work for Freedom, help out !
Go Xine, Go GPL, Resist draconian DRM!
Nice response Aaron.
Amen.
Well,
The way I see it is it's absolutely pointless to sling snow back-and-forth on the blogs. He thinks it's not going to work, so someone needs to sling some code to prove him wrong.
Gnome just doesn't seem to value platform availability as much as KDE does. Just look at that HAL-Linux-mess which isn't working on for example *BSD. At least KDE tries to solve these kind of problems with projects like Solid and Phonon while Gnome has nothing to fall back onto if a platform doesn't work with their backend.
> someone needs to sling some code
> to prove him wrong
agreed. and that's what mkretz is doing with phonon =) i actually wrote my first bit of phonon-using code the other day. it was only like 6 lines and was a port of some old aRts code in kdebase, but it was a start. the nicest thing was that it took me about 5 minutes of looking at the API docu in phonon to figure out how to do that. it'll be even nicer once there is high-level documentation to compliment that.
The thing I still don't get about the reason for chosing Phonon is how on earth a library *that does not yet exist* will be able to provide API/ABI stability for all of KDE4.
You expect a new library to be better at this than an already existing library ? GStreamer 0.10 will be API/ABI stable for as long as it exists.
I think the thing KDE should have learned from the arts thing is that one should make sure that whatever is chosen ends up being actively maintained.
Will Phonon be actively maintained ? Let's hope so, but what guarantees better maintenance than arts ?
Phonon is a KDE project. It's api stability will be the same as the rest of KDE's.
How can KDE hope to guarantee API/ABI stability for a project (like GStreamer or NMM or any other MM backend) that they don't control?
How do you make sure any project is maintained? How could KDE guarantee that GStreamer would be maintained into the future?
> Will Phonon be actively
> maintained ? Let's hope so, but
> what guarantees better
> maintenance than arts ?
there are no gauarantees in life, of course, but you can certainly improve the odds.
phonon is not a full media stack like aRts or gstreamer. it's a very small, simple API lib. it's also in the style of other KDE APIs.
right now we have multiple apps (amaroK, juk and kaffeine to name three) all doing this work on their own already!
so if mkretz were to fall over and die the day after 4.0 was released, we'd have a small bit of code in a familiar style to take over. most likely, the developers working on the apps that used to maintain their -own- backend media framework libs would step up and maintain it.
and since it's so small and relatively simple, maintenance shouldn't be a huge issue.
contrast this with aRts, gstreamer or any other full-on media system. christian is right that those systems -are- resource intensive to get right.
Nice post - I think the Phonon people need a little backup now because unfortunately Christian started kind of a flame war :/
Btw.: there are no clear information about the connection of Multimedia and Portland - is there any material available you know about?
liquidat
The issue I- as a fairly typical end-user- see is the possibility of Phonon backends becoming unmaintained.
Fundamentally, there is no guarantee that either Phonon or GStreamer will continue to be maintained. The only thing that could assure this would be developers working on them. Phonon right now is not established- it has neither had a stable release nor any final commitment. GStreamer has large companies and fd.o behind it. While both have the possibility of becoming unmaintained, the latter seems more unlikely simply because it already has momentum.
Having significant developer manpower working on maintaining stable backends instead of working on good multimedia frameworks seems a relatively poor idea. Instead of being able to say "GStreamer is the way to go, implement crossfading using GStreamer", you have to tell an application developer "there is no real way to go beyond our abstraction; if something doesn't work you have to implement it in every one of our backends or face some of your user base not having the ability". amaroK exemplifies this; GStreamer in amaroK is near broken not because GStreamer sucks, but because no one is spending time on it.
If a single multimedia framework- be it GStreamer or Xine or anything else- can be decided upon, it will make my time using a multimedia application easier, because I won't have to constantly switch backends (I've experienced this firsthand). Phonon has no greater chance of long-term survival than GStreamer, but GStreamer has more flesh on its bones.
Well said Aaron.
I think Phonon is a fantasticly simple idea.
PROBLEM: What media-framework should KDE4 use?
ANSWER: [insert 745 different responses plus 3 months of arguing back and forth and the end-selection of a backend that we pray will be around/stable for the next few years]
The only real solution is Phonon. Provide a link to ANY backend. Fantastic Stuff guys.
Everything is really starting to come together.. keep up the good work!
Better clap your palms together- Linux might die next week. No surety that Trolltech's going to continue working on Qt. No way to be sure that dependency foo will be around for bar.
You can't judge if /any/ framework, be it Phonon or GStreamer or Xine, will be around in a year. What you can judge is which framework will give the best experience to the users and developers. Having ten partially maintained backends which half-implement their frameworks functions in Phonon won't provide this.
ok: so call me confused.
Christian is arguing that KDE should only be writing qt/kde bindings to gstreamer, rather than working on phonon.
Now isn't phonon basically a qt/kde binding to gstreamer, that also happens to be plugin based to allow bindings to other multimedia systems to be added?
So what, exactly is the complaint? That a plugin system is 'too hard'?
Or that KDE is not working to kill off other multimedia backends besides gstreamer?
Or is it something else?
I'm clearly missing the point....
The point is, by creating a system that allows for the use of multiple multimedia frameworks as Phonon does, it creates a situation where work must be duplicated across multimedia frameworks for there to be any consistency or guarantee of work. In essence, that anyone who wanted to add a new feature to Phonon and the KDE multimedia framework would have to add it to GStreamer, Helix, Xine, and whatever else if they wanted all of their users to benefit from it.
No offense, but have you heard of capital letters? :)
Anonymous said:
>The point is, by creating a system that allows for the use of multiple multimedia frameworks as Phonon does, it creates a situation where work must be duplicated across multimedia frameworks for there to be any consistency or guarantee of work. In essence, that anyone who wanted to add a new feature to Phonon and the KDE multimedia framework would have to add it to GStreamer, Helix, Xine, and whatever else if they wanted all of their users to benefit from it.
Yes, this is true. but - how to choose a MM framework that is the best? aRts WAS the best choice. It was meant to be used in Gnome, too, even depended on Glibc. But in the end, it proved a wrong decision. How can we EVER know what will happen in 5 years?
>>Better clap your palms together- Linux might die next week. No surety that Trolltech's going to continue working on Qt. No way to be sure that dependency foo will be around for bar.
...<<
You have got the point! =))
thats why kde doesn't want to depend to much on code thats just much to different.
what i linux dies? no problem, kde is no linux desktop. its a *nix desktop, and the next version will be even more portable.
what if trolltech will drop qt? than kde gets a nice kde-like api that every kde developer is familiar with under the bsd-license. so it will be easy to maintain it themself.
same for phonon. its a kdelibs api. itsmost likely that it will be maintained by the kde team till they wan't to switch or kde itself is unmaintained...
i don't know why thats so hard to understand. why should it be easier to just help gstreamer, and therefore code in another language, with other libs and other codeing style if it could just write something own, in their language, with their libs and their codingstyle?
gstreamer doesn't do everything kde wants their media backend to do. and gstreamer is ruled by forces that don't have the same interests.
the gnome folks should be the last to say anthing about that. they don't use others work either if it doesn't fit. every seen something depend on qt in gnome? would they accept something build upon qt4core(thats qt without gui stuff) into their core libs!?
so reading all that stuff about kde not playing well with others on christians blog(mostly the comments...) is just ridiculous....
> it creates a situation where work
> must be duplicated across
> multimedia frameworks for there
> to be any consistency or
> guarantee of work
phonon is not a commitment to -all- media frameworks, it's actually a commitment to whichever one(s) work best at the time.
so your statement is incorrect on two counts: first, there isn't that much of a difference between the various (quality) frameworks today when it comes to basic playback, recording, etc. however, were one engine to become more capable, guess which one people would use?
just because we have phonon does -not- mean we'd suddenly have to husband every project, nor do we recommend the community do that.
i know this may be hard to understand as it requires "common sense"
> No offense, but have you heard of
> capital letters?
heh... you're new here, aren't you? ;)
it's something i do to simultaneously be nice to my wrists and piss off people who are more anal than they ought to be ;)
you will be happy to know that in formal communication i do use capital letters, and that i haven't regressed so far the other way in casual communication to use texter contractions like: "how u 2day?"
ok ... that was more on the topic than probably anybody needed ;)
@aseigo: I don't think amaroK wanted to use every multimedia framework out there, but it has the option to... and that has caused the GStreamer backend to become unmaintained (and now apparently removed).
You know what: replace gstreamer with Corba and phonon with DCOP and you can travel back in time.
Will phonon be maintained ? Was DCOP maintained ? Yes because:
- it was a small piece of code
- it was very useful
- it is simple and well architectured
Why was artsd not maintained in the end:
- it was a very big piece of code
- it did a lot of things, not all of them directly useful for KDE
- it was not simple to use
So yes, I am very confident that phonon will be maintained.
"replace gstreamer with Corba and phonon with DCOP and you can travel back in time."
you got the point!
Not to mention arts' architectural problems, small developer community in the first place, and lack of use outside KDE.
@Thomas
Please, do not repeat againt that crap about "GStreamer 0.10 begin API/ABI stable". Just a few days ago you yourself made a proposal to break API/ABI compatibility in 0.10!
That's exactly why Phonon is the right choice for KDE4. It may be right for Gnome developers to change their software everytime GStreamer changes API/ABI (which is too often, sadly), but it's not for KDE.
If KDE used GStreamer, either KDE app developers stick with GStreamer 0.10.5 for the whole KDE4 lifetime, or KDE app developers change their apps for GStreamer 0.10.6, 0.12, 0.14, etc.
GStreamer releases so many versions with so many changes so often that it's a very fast-moving target, and that's definitely BAD.
Saying that xine is more reliable than gstreamer shows a misunderstanding. Gstreamer is a younger API and applications' plugins for it simply aren't as developed yet. That isn't a fault of gstreamer.
Amarok and gstreamer work flawlessly for me on Ubuntu Dapper. Aaron, you should explain the problems you are having -- it could be a problem specific to your setup. Also see the point I just made above.
The important argument for gstreamer is that Gnome is standardizing on it. Having all these audio backends is a wasteful duplication of resources. It'd be one thing if the argument was for ripping out some well established KDE API and replacing it with gstreamer, but that's not the case -- arts is going to be ripped out anyway.
The 'lesson' that should be learned from arts is that when you make your own sound server that nobody else uses because it's low quality and riddled with bugs, you shoot yourself in the foot. The 'lesson' that should be learned is 'don't remake the wheel yourself if it's unnecessary and you are probably just going to make a buggier one anyway.' The more widely gstreamer is used, the better tested and the higher the quality of an API it will be. Juk, Kaffeine, etc. are why gstreamer should be used.
Gstreamer is being developed to be crossplatform. It already runs on windows, running on the other *nix's will be comparitively trivial, and I'm sure that if somebody hasn't started porting on a Mac version already it won't be too long, especially now that Gtk+ is getting good Mac support.
Making a nice C++'ified wrapper around gstreamer would be something productive for KDE developers to do I think. The only advantage I can think of to Phonon is that it will probably be easier to use when doing OOP, and this would nicely give gstreamer that benefit. My hope is that the gstreamer backend for Phonon ends up being the most popular so that this ends up being what Phonon essentially is anyway.
As for maintainership -- the more people who use a library, the more likely there will be maintainers. If both desktop environments used gstreamer someone, somewhere, would end up being motivated enough to fix annoying bugs.
Phonon has no inertia behind it yet. If I had another internship with an ISV, and they wanted to make an app that used multimedia, I'd love to be able to tell them to use kdelibs+Phonon and not have my boss smack me down, because in most respects IMHO, KDE is leaps and bounds ahead of Gnome. But I can point to commercial backing on the future of Gstreamer, and I can't do that for Phonon.
Money makes a big difference. I speculate this is why GTK+ apps are aesthetically just now emerging from the dark ages while Qt looks slick. We don't need a GTK+ of sound servers.
P.S. I just reread my comment and realized it could be misinterpreted -- when I imply that Phonon will probably be buggier than gstreamer, I am not making a statement about the KDE developers coding skills. I'm saying that because using gstreamer will result in a library that already has a lot of users having even more users, there will be a lot more testing going on. Gstreamer would be constantly grinded by both Gnome and KDE application developers until it's very stable.
@Jengu: guy, you are seriously confused on this matter. it's hard to know where to start. instead of refuting point by point the various oddly wrong things in your commnet, i'll just say that phonon doesn't mean we don't choose gstreamer it means we don't choose a media framework for the lifespan of kde4. gstreamer may indeed become the most common backend for phonon; it could become the -only- backend for phonon and still phonon would be the right choice for all the other reasons mentioned.
@Jengu: I am not interested in CEO-blabla in the mainline. I want solutions that just work for me.
And a solution that just works for me is libxine, whilst GStreamer does not. I don't care whom to blame for that broken experience with GStreamer. I am just not interested in finding it out.
And if perfect working solution X has zero money behind, whilst average working solution Y has millions behind: Why should I throw further money on the inefficient one that needs so much money in order to work?
Just economics. I am sure that a resonable CEO that actually has knowledge of economy would make the right decission. :p
It has already happened:
Remember back in history there was a little operating system originally called FreaX, a student from Finnland just coded for the fun. Then there was some well known professor that obviously had much of knowlegde but said that this OS is just stone age and a waste of time because it is monolithic.
You now see that Linux just works, whilst micro kernel desktop OS are still not that widespread. Linus doesn't care if Linux it is perfect he just want things that work *now* (and work as fast as possible).
So better you switch your OS to a *perfect* modeled one (for example Plan 9 or Hurd) or use Linux and live with solutions that are not aimed at purity (whatever this is).
Aaron, if I'm totally confused, then maybe Phonon is misadvertised. I consider myself a pretty saavy linux user and a fairly competent (although young) coder. My understanding of the issue may not be perfect, and I totally admit I don't hack on phonon or gstreamer or arts. My understanding of Phonon is that it's going to provide an API for the multimedia actions apps may like to perform, playing sound and movies, recording, etc. It's also my understanding that it's going to be designed so that it can work with multiple backends. And your post says to me that KDE is not committed to using gstreamer as its primary backend.
If I've said anything wrong so far, please specifically correct me. I foresee different distros using different backends as their default, users still not being able to download codecs that add multimedia support to both their gnome and kde applications, and continued duplication of effort. Not anything an ISV will feel like trying to support.
Jumping Jesus.
It seems like people are INTENTIONALLY misunderstanding each other here.
I am a GNOME user, I like GNOME. I think Gstreamer is a great idea. I think Phonon is a great idea.
If Gstreamer presented a stable, standardised API that fit in with both GNOME and KDE API standards that would be great, there would be LESS need for Phonon.
If Gstreamer supported EVERY format and codec that Xine and other alternatives support NOW, there would be LESS need for Phonon.
If Gstreamer was GPL not LGPL, there would be LESS need for Phonon.
What Phonon provides to KDE devs and users is:
1. The ability to access NOW whichever decoder/framework does the job best NOW. Yes, the future may be different and Phonon will allow easier changes.
2. A single piece of code exposing High-Level KDE standard API to people who just want to write simple apps KDE-style (GNOME could learn from this philosophy!). When Gstreamer changes, as it does and will continue to do, only this one piece of code needs changing and the apps will continue to function without change. How is that not a good idea?
3. The choice to use whichever backend / framework / decoder you prefer, for whatever reason, including GPL compatability, DRM availability / exclusion, WHATEVER your reason.
So:
Phonon is a VERY GOOD IDEA.
Phonon very much supports Gstreamer, it just happens to support alternatives (Well boo-hoo get over it).
If anything, Phonon allows LESS dupliction of effort and code, not more. How is this difficult to see?
GNOME should have its own Phonon. Unfortunately, I can't see THAT happening.
Heh, I didn't really expect to start such an uproar when I posted that article.
Anyway, I hope everyone knows that Phonon is just a high-level wrapper, and not a new sound implementation that competes with gstreamer, etc. We're not reinventing the wheel (we learned from arts) - we're just making it easier to add quick sound support to your applications without having to worry about all the juicy gstreamer/xine/nmm/xmms/dshow/qtime/etc. implementation specifics :P
Cheers
Heh, I didn't really expect to start such an uproar when I posted that article.
Anyway, I hope everyone knows that Phonon is just a high-level wrapper, and not a new sound implementation that competes with gstreamer, etc. We're not reinventing the wheel (we learned from arts) - we're just making it easier to add quick sound support to your applications without having to worry about all the juicy gstreamer/xine/nmm/xmms/dshow/qtime/etc. implementation specifics :P
Cheers
Post a Comment