thanks for your fast answer. Just for clarification why I’m asking this: I’m currently using gstreamer/pulse in kde4 as well and I actually like this combination. I’m using ubuntu as base distribution which come with gstreamer/pulse as default and use my own vanilla compiled kde on top of it. Since I would like to keep just one multimedia backend I’m a little bit worried that everyone in kde land jumps onto the vlc wagon and GST as phonon backend will be forgotten completely.

(On a side note, yesterday I gave kde45 trunk a try and the pulse integration into kmix is just perfectly, though took me some time to find out how to move a stream , really cool work!)

So the answer, as it invariably is, is somewhat inconclusive! I’m currently using GST (tho’ you have to turn off crossfade in Amarok), but will try and use VLC more and more as I find time to hack on the PA layer inside it.

What is actually the shape of the gstreamer phonon backend (thus I mean the code that is part of phonon, not gstreamer itself), afaik not much development went into it last years/months? Do you expect the vlc and the gstreamer backends soon to be on the same quality/featureset or is the vlc backend already in a much better state and is this fact alone a reason to switch to vlc?

.. sepecially if one (me) uses pulseaudio…

Xine is a dead project. It’s no longer developed upstream and it has so many bugs that applications have to work around them, even with a phonon wrapper. While it may work great for you, this is in part testament to the fact that the developers have added all these various workarounds to deal with it. This is not practical longer term. Work on Phonon VLC has been going on for a long time now and it’s progressing very well. When VLC 1.1 is released (soon) it will become more mainstream.

With regards to VLC vs. GStreamer, I have to say that I really rather like the concepts on both of them. Both of them are really rather similar as far as I can gather. The real trick is getting the right “graph” for any given job. If you want to play back video the graph will include the input, demux, decode and output stages (possible others too, like OSD, subtitles etc.). Both systems offer some kind of automatic graph generation (in GST this is the playbin and decodebin components I believe). In the past I was rather ignorant as to how VLC worked, but after speaking with JB I see that they two have a pretty flexible graph generation system that can wire up all the modular component automatically for any given job.

Now I wont begin to talk about the internals. I really only have a high level understanding of both GST and VLC really, but from what I can see, they are not all that different. I guess I was just previously assuming that VLC was a media player rather than a media framework, and that prejudice is what formed my general opinion (and it wasn’t a bad opinion, I just didn’t realise that it was much more than a media player).

While I would love to say, yes this is the “final API and it will last for ever”, it’s not really 100% our (the KDE media developers) to make these decisions. We are at the behest of Qt in many regards and while we can do our best to keep things stable, if change is genuinely merited (for either technical “pureness” or maintainability reasons) then this should certainly be considered and in many cases encouraged.

But as I said, I do not see Phonon API going anywhere (incompatible) for quite some time.

we need to do better than that with our API commitments. the only reason to toss out Phonon that quickly is if it is really broken. sometimes we toss things out because “we can do it better if we start again” and not because what we are tossing is really broken.

sometimes, things are really broken (i can name a number of things we tossed from KDE3, including aRts), but we need to keep ourselves from feeling too cavalier about such decisions.

Phonon actually works very well, has a nice API and, as we can see here (and as Chani already pointed out), shields app devs from the utter insanity of multimedia framework development (from an app developer POV). that’s invaluable.

please, as media developers inside of KDE, produce some commitment and resolve to the framework. let’s move from “ok, for the next year or two” towards something more concrete and confident ….. even if that means we’ll need to do some work on the framework to keep it viable. which will be true of _any_ solution that comes along.

At present, the Qt Mobility system is a far worse option for app developers as it is simply not available anywhere on any distro etc. etc. As I said in the summary at the end, Phonon + VLC backend is very much the solution to continue focusing on for the short and medium term. With regards to long term, if/when Qt Mobility matures and there is reliable support on a wide variety of platforms, then it will potentially be possible to port things across to it. The API is actually quite similar to Phonon and such a porting effort wont be that difficult if/when that happens. As a stopgap I’m sure a phonon compatibility wrapper will be possible, but I did mention that this would cause two layers of abstraction where one would suffice; which is not ideal (and especially so for mobile systems).

Nothing lasts forever and while the Phonon API may be around for quite some time, there may be a better, more appropriate route that is a realistic option in a year or two. Ultimately, this is not really news to anyway if you break it down to the fundamental principles