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.
on Pitivi related improvements in GStreamer and Gnonlin.
