Tuesday, October 28, 2008

thin layers

Ade blogged recently that some of the people sharing beers around a table one evening were ponder the question "Why isn't Phonon just a thin wrapper around GStreamer?" and couldn't come up with a good answer.

The answer is pretty simple, however: Phonon is a thin layer over GStreamer when it is used with the GStreamer back-end.

What it isn't is a thin layer for only GStreamer, and the reason for that is similarly straightforward: our target platforms are your computers, where "your" is defined as "people of the world". Reality is that not all of your computers use GStreamer, and it isn't KDE's role to try and ignore that reality.

In that sense it's just like how KDE runs also on BSD or OpenSolaris: it isn't our job to make people running those OSes to switch to Linux.

In that sense it's just like how Qt is a "thin layer" over X11, but not exclusively as it supports at least four other windowing systems and a multitude of operating systems.

We wrote the GStreamer backend, bringing thousands of applications to GStreamer (which begs one to ask why people are looking gift horses in the mouth), because we believe in GStreamer as a solution. If in five year's time GStreamer has taken over the world (as defined by "our users") then everyone wins and nobody loses; if that doesn't happen KDE still doesn't lose.

So why is Phonon not a thin layer over only GStreamer? Because we cater to the whole world, today and tomorrow, even as we take care of our preferred choices and platforms through our efforts.

21 comments:

Tsuroerusu said...

You said it Aaron!
My sentiment exactly!

Socceroos said...

Very well explained Aaron. You didn't leave anything to the imagination.

Hopefully we can see an end to peoples misconception of what Phonon is - if they read this! =D

Ethan Osten said...

But is there any reasonable platform on which there's a viable Phonon backend, but on which GStreamer doesn't run? GStreamer runs relatively lightly on all of the Unix variants, OS X, and Windows; what makes it less portable to "all users" than Phonon itself?

Skye said...

Ethan, I prefer mplayer and xine to gstreamer. Should I just ditch those in favour of gstreamer? Even if you think I should, but I don't want to. So here's your answer.

Aaron J. Seigo said...

@Ethan: "is there any reasonable platform on which there's a viable Phonon backend, but on which GStreamer doesn't run"

you can run X11 on Windows and Mac, doesn't mean we should force those people to run X11 just to run KDE applications.

there is a huge % of our users who simply do not use GStreamer, even on Linux. that is simply reality.

as such, your comment is posing a question we aren't asking or answering ("does GStreamer run on those platforms?") because the question is "are people using GStreamer?"

btw, we default Phonon from KDE's svn to using libxine because it actually works for everyone. GStreamer simply doesn't; while it can work, it often doesn't and that prompted us to make the decision for defaults we did. it would be great for the GStreamer community to work on the robustness and universality of the GStreamer solution before taking up the question of Phonon. =)

"what makes it less portable to "all users" than Phonon itself?"

you're completely missing the point. it's not our job to force people to use anything. if they are using GStreamer, then great: we're ready to support that.

it doesn't matter that GStreamer can run on those platforms, the fact is that GStreamer isn't used by a significant portion of our users today.

that's without even getting into what people may or may not run tomorrow.

with Phonon, KDE users and developers are covered both today and tomorrow. that's a reality based decision.

as i said in the blog posting, if GStreamer takes over the world in the next N years, everyone can be happy as Phonon supports it just great.

in case anyone isn't sure of our commitment to GStreamer as a solution: the GStreamer people started a Phonon backend, but stopped developing it. (the wisdom of such a move is debatable..) so we stepped up and funded development of a high quality GStreamer backend for Phonon ourselves.

drfav said...

Great post, let's hope this clarifies things (and shuts some mouths)

Fabien said...

I guess this will start another 'blog flame war' between aseigo.blogspot.com and some others from planet.gnome.org (or planet fdo)

Even if I agree with your point, I'm not sure it was worth posting this (potential) flame bait.

logixoul said...

Aaron,
In that sense it's just like how Qt is a "thin layer" over X11.
You keep using that word. I don't think it means what you think it means. ;)

I agree with the rest of the article though.

Aaron J. Seigo said...

@Fabien: no, it's not. if you follow the links in my blog, it's actually to Ade's blog on planet.kde.org. and if you read Ade's blog, you'll see the context for it.

it is important information to get out there (and worth the "flamebait risk") because it helps people explain and understand the KDE approach to things, versus being pushed about by the incoherent reasoning about Phonon's role vis a vis GStreamer, et al.

@logixoul: care to elaborate? =)

maninalift said...

gstreamer doesn't work for me, xine does, this doesn't cause any problem for me, nor would it if it were the other way around, but if my apps were tied to one media framework I'd have to work out how to fix gstreamer.

mhogomchungu said...

is there anything out there that has a comprehensive and neutral discussion of linux multimedia backends? i am more interested in gstreamer, xine and mplayer

..i am one of those people who do not and dont seem to miss anything from not using gstreamer ..am i missing something from not using it? xine and mplayer seem to work well for me ..

why arent we hearing anything from xine or mplayer people when it comes to what backend kde4 should use?

randomguy3 said...

I'll elaborate for logixoul: Qt is a lot more than a thin wrapper around X11. It implements a full widget set.

The GUI module of Qt is analagous to GTK+, which is also not a thin wrapper. Instead, GTK+ is a widget toolkit that sits on top of GDK, which _is_ a thin wrapper.

behavedave said...

I can understand the desire to see GStreamer mature in to as it is a complete media framework (reads, records, transcodes, handles devices, handles metworked media etc...) so in the realms of the capabilities that Phonon supports it is no better than than any of the other media framework that are more mature (or should I say better at what they do (which is less than GStreamer)) The point that Aaron tried to put across in such a diplomatic manner is that GStreamer is still implemented poorly (A/V sync issues, green squares down the sides of the screen, decompression atrifacts, the list just carries on) and that apart it hasn't reached 1.0 (after a decade of its existence!!!!) yet which usually means the API and the ABI (whatever they are) are not stable yet so no matter what a layer is still needed.

I have to admit for my personal needs abandning GStreamer until its at 1.0 and at least at parity with the other frameworks (VLC seems to be the best for me by a nose) wouldn't be a problem.

segedunum said...

Sigh........... They still don't get this? You know, sometimes I just don't think some people on the 'G' side of things gets that it is usually a bad idea to expose all your application developers to incompatible and sometimes unforeseen future changes in direction and brain damage.

The best example I can come up with is to insulate your application developers from utter brain damage like this, because it inevitably filters to users in the form of stuff not working:

http://lwn.net/Articles/299093/

Now, in terms of layers and structuring then the Linux audio system might appear to need some serious improvement, but over the years we got better drivers and sound actually came out of our speakers believe it or not. It sounded quite good as well and we could even pass stuff to S/PDIF. PulseAudio then came along to solve an awful lot of problems end desktop users don't fundamentally care about and sound becomes a massive non-working mess again.

Phonon exists because this stuff just can't be trusted. GStreamer has been around for quite a while and shows no real sign of settling down into something reliable, and people also have to wait endlessly for PulseAudio to start working as well. Even then, the rug might well be pulled out from application developers' feet again. libsydney is yet another vapourware API to fix the problems - which developers will need to port to again. It's absolute crack. At least with Phonon, Qt and KDE developers can get together and decide what to do about insulating themselves from this stupidity.

Aaron J. Seigo said...

@randomguy3: it is a lot more than a widget set these days, but even that's not really relevant; the parts of Qt that do painting and provides access to things like QDesktopWidget, window flags, etc are all "thin wrappers" around the underlying windowing system.

in any case, i was using it as a simile, not as an exact definition. =)

Joe said...

Is phonon free software? To me it looks like QT software is selling it through commercial licensing.

Janne said...

More whining from the GNOME-camp: http://blogs.gnome.org/otte/2008/10/29/thin-layers/

Aaron J. Seigo said...

@Joe: yes, it is free software: it's LGPL licensed, as are all of KDE's libraries.

hb said...

@Joe

Phonon is LGPL licensed, but with QtCore dependancy, so your software either has to be GPL-compatible, qualify for Qt's GPL exception clause, or you have to buy a commercial Qt license.

joedoe said...

Aaron can you confirm what hb is saying?

Kevin said...

Yes, I think hb is correct, i.e. Phonon does not add any additional licence requirement if you are using Qt under GPL or respective exceptions and it only adds the usual LGPL requirements if you are using it under proprietary licence.