There ended up being quite a lot of comments posted to my blog post yesterday where I pointed out a logical fallacy in a blog post by Aaron Segio. I wasn’t online in the evening so I didn’t reply to the comments posted, but let put down my arguments here instead.
Benoit Jacobs posted a reply making the point about Phonon being smaller than a multimedia framework and that on Windows and Mac installing another multimedia framework would be redundant. This argument rests on some assumptions I think are false. First of all it assumes that GStreamer is huge while Phonon is small. The core idea behind GStreamer since day one was to keep the core small and media agnostic while all functionality was put into plugins. This means that what you install on Windows or Mac, if all you want is access to the codecs provided on those platforms is actually very small. And while I haven’t looked at Phonon’s disk usage I would be suprised if Phonon plus dependencies really had much of an advantage in that area.
The second assumption is that using three different media frameworks is in some way work saving. Having talked with people who tried going the multi framework route before deciding to just use GStreamer on all three major platforms I can tell you that this simply isn’t true. First of all is the problem that you have three major sources for bugs instead of one. So what people trying this experienced was that instead of hitting one bug in GStreamer and having to fix that, they instead hit one bug in GStreamer, one bug in Quicktime and one bug in DirectShow. And since they didn’t have the source code to Quicktime and DirectShow they often had to introduce ugly work arounds in the application layer. The other cost people experience is that everytime a new feature is needed they would have to implement it once for each of their backends. And Phonon do not insulate people against these kind of problems. They will still hit bugs in the underlaying frameworks and whenever they try to do something Phonon do not support, they either have to try to extend Phonon, hoping that the media frameworks are similar enough in terms of that specific functionality to make this viable, or access the underlaying frameworks directly. And if they want to add a new codec for instance they would still have to implement that codec for three media frameworks instead of one.
bluescarni commented that I had a comprehension problem since Aaron was clearly talking about Qt apps. I am not sure what to reply to that considering you in your own comment posted the quote from Aaron starting with the words ‘Phonon is also more than just an option for Qt apps’. True enough, English is a second language for me, but I do feel I am somewhat in firm ground here…
There was quite a few comments about how Phonon was a better choice for Qt developers. First of all my original blog post was in direct response to a claim by Aaron that Phonon was a good choice also for non-Qt developers doing cross platform applications. So I do not feel a strong need to engage in that debate. But my paragraph above on the second assumption made by Benoit sums up why I do think there might not even be true for even for Qt developers in a lot of cases.
Aaron commented that Phonon is not in the same space as GStreamer. Sure, Phonon does not do most of what GStreamer does, but GStreamer does provide a key feature of Phonon, providing an easy to use API across Windows, Mac and Linux/Unix. Sure you ‘don’t get a hard dependency on any one multimedia system’ with Phonon, but you do get a dependency on Phonon and its dependencies instead. So the argument that ‘and like it or not most aren’t using GStreamer on those platforms’ doesn’t compute, because most applications on those platforms are not using Phonon either. The argument is not about what applications use today, cause if that is the argument then people should just use DirectShow or Quicktime. But instead the argument is about what is the best way to write a cross platform multimedia application today. And here I think GStreamer is a better option in most cases, especially the cases when your application is not using Qt.
Aaron also repeated the oft heard argument that Phonon is for KDE about not repeating the mistakes of Arts. And I guess this is one of the big differences in perception. Because for Aaron for KDE to have used GStreamer would have been repeating Arts, but for me Phonon is repeating the Arts story. Back in the day if one dared to take issue about any of the wonderous claims made about Arts one got tons of comments about just being partisan and ‘hating Arts or hating KDE’. Kinda like how it is today when one tries to point out that Phonon is not the universal wonder solution that Aaron likes to paint it as.
So to make it clear, I am not arguing that using Phonon is the biggest mistake you can ever make in any possible situation. I am taking issue with the promotion of Phonon as a better solution than just using GStreamer for a lot of specific use cases including cross-platform development. The strength of Phonon lies in providing a familiar API to existing Qt developers, giving them access to some limited multimedia functionality, but in terms of promoting itself as a generic cross platform multimedia development API it falls down, Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either.
“bluescarni commented that I had a comprehension problem since Aaron was clearly talking about Qt apps. I am not sure what to reply to that considering you in your own comment posted the quote from Aaron starting with the words ‘Phonon is also more than just an option for Qt apps’. True enough, English is a second language for me, but I do feel I am somewhat in firm ground here…”
See my comment on your last blog :) (the one just before the pingback from this blog). As an addendum to my comment: my addition of quotes merely emphasises my initial parsing of the Aaron’s comment, and is not required for my parsing to make sense, or even to be the more obvious one. That’s just in case anyone was thinking “Sure, if you *add punctuation where there was none before*, you can spin it that way, but you can do this for most sentences!”
Christian, can you explain this comments a little bit more in detail?
“Phonon is not the universal wonder solution that Aaron likes to paint it as”
” but in terms of promoting itself as a generic cross platform multimedia development API it falls down”
Why do you think that? Please be specific.
Aaron meant: “For Qt apps, Phonon is more than just an option”, nothing else.
Your completely twisting the truth with this post. You claim that Aaron paints Phonon as the universal wonder solution while actually you are doing just that with GStreamer, not the other way around.
in practice, phonon is simply a qt binding for gstreamer (based on the assumption that most distros will ship gstreamer alongside phonon)
the fact that it can make use of other backends is of little relevance and will be rarely done
I dont consider it a competitor to gstreamer frankly so this entire flamewar is a little off base :)
“Phonon is also more than just an option for Qt apps”
At first, my reading was : “Phonon is not only for Qt apps, it’s an option for all application”
Then, I read it again and I understood : “For Qt apps, and only Qt apps, Phonon is more than an option, it’s THE solution.”
Bot understanding of the sentence are very different and can explain some misunderstanding.
First, let’s get one thing straight: I belong to the Gnome camp.
The same thing happened to me as to Ploum, I first misunderstood the meaning of that exact sentence from Aaron pointed out by Ploum, and that made the comment feel quite aggressive. And now understanding the sentence the other way around, I feel that maybe us Gnome people have been the aggressive ones and not the other way around…
@tbscope: The paragraph in my blog entry about ‘the second assumption’ goes into some of the reasons why I think that and it is quite specific :)
Christian,
Talking about bugs in the underlaying media frameworks:
“And Phonon do not insulate people against these kind of problems. They will still hit bugs in the underlaying frameworks and whenever they try to do something Phonon do not support, they either have to try to extend Phonon, hoping that the media frameworks are similar enough in terms of that specific functionality to make this viable, or access the underlaying frameworks directly. ”
How does GStreamer protect against this?
How does GStreamer extent functionality which comes available in the underlaying framework?
I have a feeling that GStreamer would hit bugs in the underlaying frameworks too :-)
tbscope: well as I tried to explain in my post. It doesn’t, but using GStreamer means you have one underlaying framework to worry about and not three. So it does not protect you against it, but it significantly reduce the exposure.
GStreamer do not use DirectShow or Quicktime, instead it just uses the encoder and decoders for those frameworks directly.
Don’t be so naive, is not the first time Aaron’s mouth get him into troble, some how every time I hear from this guy is because a rant or controversy, So till he doesn’t explain what did he want to say then I’ll take it like he was refering to phonon beyond Qt. And this is because his bad reputation.
Don’t be so naive, is not the first time Aaron’s mouth get him into trouble, some how every time I hear from this guy is because a rant or a controversy, So till he doesn’t explain what did he want to say then I’ll take it like he was refering to phonon beyond Qt. And this is because his bad reputation.
Christian,
I understand.
Instead of using QuickTime directly, you have decoders for the QuickTime format.
Thus not making use of existing decoders and encoders. You write your own introducing your own bugs. That might be good as then you have full control. But it means a tremendous work for GStreamer to include everything and the kitchen sink.
The idea behind Phonon is the exact oposite: use what is available.
Does Xine not have a Windows Media decoder? Well, use GStreamer, or something else which does have such a decoder. For the programmer this means 0 seconds of work. If GStreamer wouldn’t have a specific plugin, the programmer needs to first create it which costs him slightly more than 0 seconds of work.
It makes no sense to not use what is available.
mmm
sorry for double post.
All this talk about who’s pissing further makes me wonder, what happened to the evidence? I’m wondering about video editors (I heard Diva died), audio editors (I haven’t heard of Jono’s project in ages, don’t even know its name anymore) or DVD players (last time I checked, Ubuntu’s commercial offering was non-Gst-based). How about a new blog post covering progress on these more relevant areas?
I’ve made a similar argument in the LWN article:
see here: http://lwn.net/Articles/300599/
I just feel like the Phonon developers made life hard on themselves – creating it takes alot of work, only a simplified API is available, and if they need more, they’ll have to link to f.e. gstreamer anyway.
So Phonon makes the simple things easy indeed, but the hard things are still impossible (without using other frameworks directly). Extending Phonon’s API is of course always possible, but the mismatching APIs will always introduce implementation difficulties and bugs.
@Ronald: ok, I felt it wasn’t that long ago I blogged about those. But I will post an update on Jokosher, Pitivi and resindvd on Monday then.
tbscope: GStreamer doesn’t have implementations of codecs, it uses the original ones (such as libvorbis, libtheora) directly.
For us, one of the big benefits of GStreamer was being able to use the already licensed codecs on Windows and MacOS. I’m not sure if Phonon wraps them or not, but that’s a really important feature if you want to be able to ship mp3 playback to users without paying licensing fees. For example, VLC does not let us do this.
@tbscope: You misunderstood me. GStreamer do use the existing codecs on windows and Mac, we just do not use the DirectShow and Quicktime frameworks through their ‘high’ level API’s.
Christian, what I meant is this. Aaron’s phrase is:
“Phonon is also more than just an option for Qt apps.”
My first thought when parsing this (as a non-native speaker myself) is:
“Phonon is also more than just an option as far as Qt apps are concerned.”
I think you parsed it this way instead:
“Phonon is also more than an option not just for Qt apps.”
I still think that the first interpretation is correct, and I think that it also makes much more sense in the context of Aaron’s post.
You all can go to hell! You are discussing stupid things, and I still don’t see any decent linear video editor for Linux, neither using phonon nor gstreamer. Let’s work in getting things done not in making flame wars. As I see it, this is a democracy and developers will choose the framework that is better for their needs.
Nice, level-headed, well-written response. Thanks for staying classy.
@dree and others:
Aaron has a new article on his blog explaining what he meant.
One suggestion for comprehension: if something you hear sounds blatantly untrue, chances are you’ve misread it. Give people more credit in the future.
Nice, level-headed, well-written response. Thanks for staying classy.
and completely wrong! See http://aseigo.blogspot.com/2008/09/strawmen-and-learning-from-history.html
@nona:
I think you’re fundamentally misunderstanding the reason for Phonon, and the way Qt and KDE does APIs. Part of the KDE/Qt philosophy is that doing simple tasks should be simple. Phonon is designed for that.
It’s powerful enough for a media player or simple recorder, but no more. It’s not supposed to be and never will be. If you’re doing serious audio editing, you probably want to plug directly into GStreamer or even Jack to leverage their full power. But to shove a video component or a sound player into an application, there’s no reason it should take more than 5 or 6 lines.
Even if you take something as complex as Amarok, the full interaction with Phonon is fewer than 200 lines according to my quick grepping. And that’s including all the uses of Phonon::State across the application in decision logic. The actual media object that forms the core of Phonon interactions is only used on 60 lines, including making signal/slot connections.
And as Michael Pyne has pointed out, the binary compatibility guarantees without preventing us upgrading KDE wholesale to, say, gstreamer-0.12 in the future (with very little work compared to porting each application individually) is worth the effort put into Phonon on its own.
On top of that, we get an API in a familiar style and multiple backends. The latter I have already made use of – on my system, GStreamer won’t play WMA files, and Xine won’t play anything with a non-ascii character in the filename. But I can switch backends and play either type of file. I might even manage to get a KDE video player to play a DVD on my tempramental DVD drive by using the forthcoming VLC backend (since VLC is the only thing that will ever manage to play a DVD).
I would like to know why only gnome people (which hates kde btw) are indexed in the freedesktop planet?
KDE adds glib as dependency
KDE moves to dbus from dcop
KDE moves from arts to phonon using gstreamer
KDE KDE KDE…
what thing is doing gnome for the “free”desktop ? (except spreading FUD against KDE)
Since most everything else has been said, I will make my argument in the form of code. I like a radio station called Radio Paradise. In fact, I like it so much that I decided to write a dedicated player for it (since I think none of the existing media players are up to snuff for playing internet radio).
I used Qt+phonon. Why? Well I have a fully functional internet radio player which fetches playlists at different bitrates automatically from the server, keeps track of metadata for past songs, fetches album covers, fetches lyrics, has nice animated transitions and runs on Linux, Windows, and Mac with only Qt as a dependency. The whole thing is currently just 965 lines of code, with about 15 of those dealing with phonon to handle the actual playback of music.
Plain and simple, there is no way in hell I could have done that with any other toolkit (if you feel differently, feel free to prove it by trying to write that app with anything else and see how much harder it is). It would have been way more complicated, and in my free time I only code things if they’re fun. I can’t be bothered to put up with unnecessary hassle.
Oops, that would be this one http://code.google.com/p/urpp/
GStreamer never really worked. How long does it exist now? Since 1999 that makes nearly 9 years now and it’s still a mess – for the normal user – I don’t want to judge for the code but for normal usage. Looking inside GNOME there is no real use for it since the only 3 tools that use it seem to be using xine–lib as well or there are random dependencies for different other frameworks. Some tools rely to xine-lib, others to gstreamer, others call the desired libraries directly. I am no KDE user but I believe that the KDE people sorted the problem out correctly. While GNOME is still suffering from “including” the things by using some sort of brains, the KDE people otoh solved the solution by simply ending up with phonon.
What I like to explain here. If you look inside GNOME there is a cross dependency to all kind of libs – coders seem to avoid using gstreamer, or the apps simply don’t clearly work using gstreamer.. to whatever reasons.. there is no clear roadmap inside GNOME to say that gstreamer should be default and that everything should use it… the abstraction layer in KDE solves it.. they say “people please use the abstraction layer.. so every distro or user can chose his backend.. be it gstreamer or xine or whatever”
but in GNOME everything refers on this and that which makes it a pita to use. so many years have passed and gnome still can’t handle these things – in a clear correct way – not that no one wants to.. maybe developers like to do so.. but there is more politics and high opinions rather than someone sitting down and actually doing the work.. maybe thats the bigger problem.. due to the language chosen (C) that may make it hard to actually code the requirements. again the phonon layer is the right choice… object oriented code simply make things work…. you code more efficiently and the results speak for it.
As a KDE user and developer, and also a fan of Aaron’s work, I have to say, I agree completely that gstreamer should have been the API used in KDE 4. Re-inventing that, whether you call it an abstraction layer or whatever, was just ridiculous. Admittedly, GStreamer has flaws. It also has potential to be THE linux multimedia framework, if everyone would just get behind it and fix issues rather than throwing the baby out with the bathwater as they seem to do.
However, one thing that might help this a lot, and KDE vs. GNOME issues in general, would be to get rid of the stupid core-level incompatibility between glib event loops and Qt event loops. How about abstracting THAT layer, so both KDE and GNOME users can swap code in and out much more easily? With an XDG spec for *that*, and we might not be having this debate right now.
Hmm.. I should also lend my voice to Ignacious’s comment, even if I think it’s a *little* harshly worded. It’s time to stop the in-fighting, and produce useful tools. Windows XP came *with* a NLV editor. On free desktops, they barely exist yet. Notably, the one that’s most usable to me seems to be based on neither solution, but on mlt/ffmpeg instead.
There’s a saying in the far east about getting things done: “If your strength isn’t enough, lower your pride.”
@Lee: Just on a side note, I’m pretty sure that Qt added support for the glib event loop ages ago. I’ve had gobject stuff operating in a Qt program (and all that in Python).
@Lee , what did phonon invent? It just gives devs more functionality in less code like you say. Whoever needs more than they can get with phonon should just use gstreamer then.
Not having to recode the entire app because gstreamer, xine, mplayer or vlc stop being developed is reason enough to use Phonon in my opinion.
If gstreamer plugs dshow codecs into it’s framework, I’d expect it to trigger all kind of weird bugs and issues with those libraries, as they were not meant to be used in different framework (and that means, not tested). So I’d not expect gstreamer on Windows to even pop up with same bugs as gstreamer on Linux (ffmpeg etc.). If you guys can emulate dshow perfectly, fine, but I don’t expect miracles. And the impedance matching code might have it’s own share of bugs as well (and some bugs you will see regardless of whether yo uuse gstreamer or dshow directly in your phonon or gstreamer app).
Same applies also to Phonon, as it will trigger different kind of bugs with dshow/quicktime, so I am curious to see which approach will turn out to actually be worse.
And as they said, Phonon is a simple mm API, meant to simplify coding effort, which can ultimately lead to better players (especiall if a person doing it isn’t siklled enough to make it work well with a complex API). And I completely understand why they want to have option of using something else. (btw. my experience with gstreamer based players in Gnome is a bit of mixed bag).
Christian,
ideally you’d not just post an update of “this code changed”. I barely eer read that since it has no functional relevance for me. could you post walkthroughs on Youtube (like Diva used to do) so we can see with our own eyes how it works and what it can do? I know, tough assignment, but that’s what PR is for. Good luck!
Jamie McCracken: “the fact that it can make use of other backends is of little relevance and will be rarely done”
As it happens, I installed Kubuntu on this laptop just yesterday. And at least on this machine, Phonon uses Xine by default. So much for the “Phonon always uses Gstreamer”-argument…. And what about KDE that is running on Windows or OS X?
Lee: “As a KDE user and developer….”. Aren’t you the “KDE-developer” who has submitted a total of 20 or so commits to KDE?
I developed a rather complicated program for recording and playing sound using Gstreamer.
After being introduced to Phonon’s API, I realzed it is Gstreamers API that made it complicated! :-(
As Phonon seems a lot easier to get to work on different platforms as well,
im switching to Phonon.
Hallo everybody,
no I am not someone who calls himself a developer and I don’t think that I am more clever than the rest of you either. Still I want to make some comments on this discusssion, but not in order to make the heat in it grow ever further…
I am using Windows at work and home, I have been using different kinds of DOS, MacOS, OS/2, HP-UX, SunOS, OpenSolaris, Linux, BeOS and others. I have tried Gnome, KDE, Xfce, CDE and others. I like to try new things and I like to have choices, though I like to have standards, too, in order to have a choice.
Why this long introduction? Cause I want to make clear that I am not a “fanboy” of anything, who can just see the view of “his” side.
What is the point of the whole discussion, I wonder? Discussions are good, and can be productive and lead to new insights. People should discuss things. But what I see here, is so often so emotional, that it is not productive anymore.
Well, there has been made a decision to use Phonon in KDE4 as an abstraction layer. Has that been a stupid decision? One have arguments for that is has been, others have arguments for that it hasn’t been. Only time will tell.
But, the people who made that decision have given reasons for why they made that decision and with what intention, namely (and please correct me, if I am wrong) in order to simplify the “simple use of sound” when programming in Qt/KDE and in order not to be dependent on a certain backend (GStreamer, Xine, QT, Direct*,…). And this decision, one has to respect.
What I do not understand is, why “KDE” gets so much attacked for this decision? I thought, KDE, Gnome, GStreamer, Linux, and so on, all that was so called free software projects? And I thought, free software is to a big part about choices. So, as a user, because of KDE’s decision to have Phonon: are you kept away from using GStreamer? No. And as a developer? No. But you have the choice to use Phonon, when it’s suitable for you, or GStreamer, or something else, otherwise.
I am glad, GStreamer exists. I am glad, KDE exists. So am I glad for Gnome, Xine and a lot of other free software. Remember that it’s always good to have competition in order to go further. But sometimes there is no need for competing. And even in a competition, one should always respect one’s competitor!
Thank you both Christian and Aaron for your good work and your commitment!
Reards,
D
Ps: No, English is not my native language, so I ask for your tolerance and hope you understand the meaning behind my words anyway. Correcctions are welcomed anyway. :-)
hold on a minute, you’re barking up the wrong tree!
Christian, I have no idea what there is to fail to get here:
1. It is not a multimedia stack Christian, so relax. It doesn’t compete with GStreamer.
2. Abstracting audio and multimedia away for Qt and KDE applications is entirely sensible, and is probably what other non-Qt applications should do as well:
a) The Linux and open source multimedia landscape is littered with train wrecks, and GStreamer is shaping up to be another one. Tying all KDE applications to it is not a fantastic idea, and I don’t believe it is what Gnome should be doing either. KDE went through the whole Arts thing, and then Gnome went through their whole esound fiasco as well as they painted right over Arts. So what?
b) Phonon can be used by Qt and KDE applications on different platforms and use the frameworks on those respective platforms. GStreamer is not cross-platform.
c) Accessing multimedia functionality for Qt applications can be done through some nice looking and universally usable Qt classes that act like any others. A KDE or Qt application developer does not have to know about GStreamer’s API or the API of any other multimedia framework. They just need to know about Qt and they can do multimedia.
Sorry Christian, but unless GStreamer becomes a saner and more stable multimedia platform then you merely prove the case for Phonon. KDE and Qt applications will be insulated from the insanity and get something that is actually usable to program.
“First of all is the problem that you have three major sources for bugs instead of one.”
Yer. The bugs are identified and handled within Qt and Phonon and worked around there. You’re still going to have exactly the same trouble getting GStreamer running itself on different platforms, and then getting application developers to use that.
“Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either.”
Yes I know Christian. wxWidgets was awful to program for, repeated an awful lot of cross-platform GUI mistakes and just wasn’t very good, quite frankly. There is another cross-platform toolkit in the world that has managed to do a pretty good and much better cross-platform job than anything else – Qt.
@Segedunum:
1. I agree
2. a) aRts and Esound are not at all comparable with gstreamer or even Phonon. Different layer altogether. As for gstreamer shaping up to be another trainwreck – I think a lot of people would disagree, and it would be a shame because it’s the best we got.
2. b) Last I checked, gstreamer did work on win32 and MacOS X (and Solaris, etc) didn’t it? How is Phonon more “cross-platform” than gstreamer?
2. c) sounds like NIH to me, but OK, fine, matter of taste I guess. A thinner layer probably could have done the trick.
@nona
There is a misunderstanding regarding the reference to aRts.
While aRts has been used as KDE3’s audio framework, the reference in the context of Phonon, i.e. not wanting to repeat the aRts mistake, means not to repeat the mistake of tying our API to one specific implementation.
Remember that at the time of the decision GStreamer hadn’t API or ABI stability commitment yet, at least not for the expected lifespan of KDE4.
So since there was a need for an API which can accomodate different incompatible versions of GStreamer, adding the capability to accomodate different frameworks was basically a logical next step.
“. b) Last I checked, gstreamer did work on win32 and MacOS X (and Solaris, etc) didn’t it? How is Phonon more “cross-platform” than gstreamer?”
What about the various BSD’s?
And why are you still comparing Phonon to Gstreamer, when they are in no shape or form alternatives to each other? But to answer your question: Phonon runs on all platform that Qt supports. It might not work on platforms that Qt is not ported to, but since Phonon is used with Qt, that’s totally irrelevant.
If KDE/Qt used Gstreamer instead, they would have to make sure that the platform the software is running on has Gstreamer installed. If not, it would not work. With Phonon, they would not have to worry about that, since Phonon would work with what’s already present on the system.
the more I read these comments, the more obvious ot becomes that Gstreamer-folks totally misunderstood what was being said, and then proceeded to complain and whine. It would be nice for them to admit that they are totally, 100% wrong on this issue, but I’m not holding my breath.
This whole thing seems to be about Gstreamer-folks insisting that everyone should use their software, and nothing but their software. And if someone uses something else, or uses Gstreamer indirectly (like, through Phonon), they start to whine.