Hi.

Is there any chance that multimedia in KDE SC will be based on Gstreamer by Qtgstreamer? http://piacentini.blog.br/2010/10/qtgstreamer-an-introduction/

Nokia will be using QtGstreamer/Gstreamer.
Libre/Openoffice is using Gstreamer.
Opera is using Gstreamer.
Psi is using Gstreamer.
Kamoso is using QtGstreamer/Gstreamer http://www.afiestas.org/kamoso-is-alive/
Telepathy-kde will be using Gstreamer.
Clementine is using Gstreamer.

Almost every new software in GNU/Linux is using Gstreamer.

Phonon is good on paper. In practice Phonon is limited. And I doubt that this state is rapidly changed.

My question is: Do we still need Phonon with his various backends?

Sorry for my english.

Edit.1

Portability of Qtgstreamer/Gstreamer will be assured - http://piacentini.blog.br/2010/10/qtgstreamer-an-introduction/#comment-245

Phonon is intended to be limited, it was designed specifically for simple tasks. It was never intended to replicate all the functionality in the various Linux multimedia backends.

For applications that need more, they can use something like qtgstreamer when it is actually finished. For applications that only want to do really simple stuff, phonon is probably easier to use and more flexible since it supports other backends (which backends support which codecs varies from distribution to distribution).

KDE has to keep phonon at least for the 4.5 series because of backwards-compatibility guarantees. Phonon could have been using gstreamer by this point if they hadn't decided to abandon development for it.

I suspect that if gstreamer really becomes the standard, then that will only push development of the phonon gstreamer backend. KDE has been bitten too many times by the abandonment of supposedly rock-solid standards (like HAL) to risk putting all their eggs in one basket again, especially not when we have a good abstraction layer available already.

Phonon is intended to be limited, it was designed specifically for simple tasks. It was never intended to replicate all the functionality in the various Linux multimedia backends.

Look at the comments underneath Kamoso. People don't understand this and demand to use Phonon, to did the job.

For applications that only want to do really simple stuff, phonon is probably easier to use and more flexible since it supports other backends (which backends support which codecs varies from distribution to distribution).

Then why allmost nobody using it, besides KDE guys? Suport other backends... xine dead, gstreamer not recommended, vlc in git. Nice choice. Seriously who will choose Phonon?

KDE has to keep phonon at least for the 4.5 series because of backwards-compatibility guarantees. Phonon could have been using gstreamer by this point if they hadn't decided to abandon development for it.

I understand backwards-compatibility and this is good thing. I hope phonon-backend-gstreamer will be develope again, this time on QtGstreamer.

I suspect that if gstreamer really becomes the standard, then that will only push development of the phonon gstreamer backend.

Gstreamer is a standard. Even Nokia understands this and pushing Qt+Gstreamer.

iria wrote:

Phonon is intended to be limited, it was designed specifically for simple tasks. It was never intended to replicate all the functionality in the various Linux multimedia backends.

Look at the comments underneath Kamoso. People don't understand this and demand to use Phonon, to did the job.

Doesn't this indicate that people like phonon? Whatever the case, this has been rehashed numerous times, the developers explained that phonon doesn't provide the API they need.

iria wrote:

For applications that only want to do really simple stuff, phonon is probably easier to use and more flexible since it supports other backends (which backends support which codecs varies from distribution to distribution).

Then why allmost nobody using it, besides KDE guys?

Because it is a KDE technology. freedesktop.org often just rubber-stamps Gnome technology. It is very, very rare to see anything from KDE make it in there. Perhaps we could talk about making gstreamer the default when the basic gstreamer plug-ins no longer depend on gtk or gnome libraries.

iria wrote:Suport other backends... xine dead, gstreamer not recommended, vlc in git. Nice choice. Seriously who will choose Phonon?

What do you mean xine is dead? It works great for me. As I said, gstreamer would be the best backend right now if the gstreamer developers hadn't stopped development of the backend.

iria wrote:

I suspect that if gstreamer really becomes the standard, then that will only push development of the phonon gstreamer backend.

Gstreamer is a standard. Even Nokia understands this and pushing Qt+Gstreamer.

You understand the decision to use was Phonon was made at least 3 or 4 years ago, right? Gstreamer was not in the state then that it is in now. You can't use the state things are in now to criticize decisions made years ago.

But I would still not say gstreamer is the standard in practice. You list only a handful of applications using it, and you can't count telepathy since it is a FDO project and thus has to use gstreamer. Even the Kamoso developers said they would prefer to use Phonon if they could.

I should add that Gstreamer still has not had a stable release yet.

Doesn't this indicate that people like phonon?

Nope. They thought that Phonon can replicate all the functionality of backends. Tell them, that Phonon is only for limited playback and you see. They want one good working solution for multimedia.

Perhaps we could talk about making gstreamer the default when the basic gstreamer plug-ins no longer depend on gtk or gnome libraries.

Why not try to talk with gstreamer-devs? Afiestas wrote about this - http://www.afiestas.org/kamoso-is-alive/#comment-3308

What do you mean xine is dead? It works great for me

viewtopic.php?p=171130#p171130
"although Xine is currently in the process of being deprecated, and GStreamer is not recommended."

http://forum.kde.org/viewtopic.php?p=171262#p171262
"Xine upstream is pretty much one single person with little time and quite some bugs, so we work on the VLC backend because we can rely on the VLC developers to give a hand for development."

Enough?

You understand the decision to use was Phonon was made at least 3 or 4 years ago, right?

Yes, I now. And now I'm asking if Phonon is _still_ needed.

You can't use the state things are in now to criticize decisions made years ago.

I don't criticize decision made years ago. I'm asking that this decision is _still_ walid, when new solution appeared.

But I would still not say gstreamer is the standard in practice. You list only a handful of applications using it, and you can't count telepathy since it is a FDO project and thus has to use gstreamer.

More apps whill using gstreamer whether we like or not. Mayby it's time for KDE with QtGstreamer

Even the Kamoso developers said they would prefer to use Phonon if they could.

They would because they want one good working solution. If you wrote Phonon was designed specifically for simple tasks, it does not mean that Phonon likely never get this function?

I should add that Gstreamer still has not had a stable release yet.

[joke]Then KDE and Phonon too.[/joke]

iria wrote:Then why allmost nobody using it, besides KDE guys? Suport other backends... xine dead, gstreamer not recommended, vlc in git. Nice choice. Seriously who will choose Phonon?

Personally, I would have loved it if Gnome would have adopted Phonon as well. I don't know if it would be feasible (for example, I don't know if it actually requires Qt and/or KDE-libs or if it could potentially be used without them so the Gnome devs would "only" have needed to create a configuration front-end) but I think it would have been great.

For example, most of the apps I use on a regular basis that require or would benefit from audio are KDE apps. Most if not all of them use Phonon, configured to use the VLC backend. I do use an app or two written for Gnome, which is the only reason gstreamer is even installed on my system. If Gnome could be configured to use VLC for its sound-system as KDE can, I wouldn't need it - and thus, one component less that could potentially head south.

Granted, as far as sounds go my system is only used for playback. And occasionally light-weight sound-editing (no video-editing whatsoever) and for that phonon with either vlc or xine is more than adequate. If you need more than that, gstreamer may be necessary.

So yeah, even with QtGsteamer I think Phonon has a role to fill - at least in the short-term. And if QtGstreamer becomes popular and/or stable enough, maybe it could even serve to rise the gstreamer phonon backend from the dead. If that happens you could essentially use just gstreamer for everything making phonon in a sense obsolote (if the backend is good enough) in the sense that it may be picked up by the distros to be the default backend.

This in turn would mean:

1. The xine and vlc backends could still be available but not installed by default but if the user thinks they're better they could be used as a substitute.
2. The idea that Gnome should have adopted phonon would be a moot point.
3. Phonon could be seen as a legacy system, just available for backwards compatibility.
4. Alternatively, Phonon could be used for playback only apps and the apps that need more than that could use QtGstreamer directly.
5. The Linux soundsystem could be seen as being slightly less confusing and/or overlapping in terms of features. Which in itself would not be a bad thing.

I guess we'll see what happens, but I don't see phonon going away any time soon.

I do use an app or two written for Gnome, which is the only reason gstreamer is even installed on my system.

With default Gstreamer in KDE less memory will be needed with one framework for all apps. And portability of apps KDE<->GNOME will be better.

iria wrote:With default Gstreamer in KDE less memory will be needed with one framework for all apps. And portability of apps KDE<->GNOME will be better.

Agreed. At least on the portability part, which is what I meant by the overlapping soundsystems in point 5. I'm not so sure about the memory consumption though. Sometimes, yes, but not necessarily all the time. It depends on what plugins are being used at a given time. And I suspect that having both xine and gstreamer (for example) loaded at any given time is only marginally affecting the memory consumption compared to the rest of KDE (or Gnome for that matter).

iria wrote:With default Gstreamer in KDE less memory will be needed with one framework for all apps. And portability of apps KDE<->GNOME will be better.

Of course it will be better. You'll have KDE depend on GNOME libs after all. Let's just ditch this KDE thingy and use GNOME /sarcasm

Perhaps we could talk about making gstreamer the default when the basic gstreamer plug-ins no longer depend on gtk or gnome libraries.[/qute]


Why not try to talk with gstreamer-devs? Afiestas wrote about this - http://www.afiestas.org/kamoso-is-alive/#comment-3308

Developers are scared to talk? If Gstreamer-devs says "NO!", then everything will be clear.

Again: More apps whill using gstreamer whether we like or not.

There's also QtMultimedia from QtMobility backed by Nokia which already has backends to all "Qt" Platforms. I don't really understand the need for somtething like QtGstreamer when there's already multimedia API which has more features than Phonon that's cross-platform too.

Hello,
actually a very nice thread indeed, thanks for bringing this subject.

May I now ask a question, as I was thinking about buying a 5.1 speaker system for my Desktop. I use Gentoo/Sabayon which by default is shipped with Phonon.

As I cannot find any web page about Phonon, does it support a 5.1 Dolby output?
This is what I found but doesn't seem to answer my doubts:
http://labs.qt.nokia.com/2010/05/10/low ... ultimedia/

The bigger questions is, will the new systems/backends/fronteneds, whatever they are, support more than stereo?

Everything comes to the point of using a control centre. Many people are using Alsa to use their 5.1 equipment. They edit config file manually. I would not like to go through a process of deinstalling and installing another frontend.

In the end, I am seriously considering another option which is buying a full home cinema system for which I don't have any money right now. On the other hand it's not very convenient unless my home cinema system will have direct access to my computer resources. At the moment my computer is my multimedia centre, I don't even have a TV set.

What's it going to be like in the near future? It's really frustrating, to me it seems like the sound systems in Linux was and will still be the Achilles heel for another couple of years to come.

Sorry if I posted a slightly "off topic" question.

Regards,
Richard

And now Nokia has decided to turn away from Phonon in QtWebkit.

What are the plans of KDE developers?

Nice question, but what happens if I don't want to use GStreamer? For example VLC serves me equally well and does not spawn gconf processes, or even MPlayer? Btw, there are equally many applications which make use of Phonon (Amarok, Kaffeine, KRunner). These applications are relatively mature and I don't think it would be easy and practical to port them to GStreamer - why break something which already works ok? What would be the benefit of these when ported to GStreamer? Will amarok play music better when it uses GStreamer directly?

On the other hand, the applications you cite are either non-KDE based, or use very specific functionality (webcam capture). Yeah, Clementine. Well I prefer amarok 2

I'd like to note, that I'm not a KDE/Qt developer, so my opinion is not "professional". But I think Phonon is a need in the dynamic world of FOSS where things change rapidly. It is also an important piece, which provides the user with flexibily - something which makes me love KDE.

Edit: I didn't know Kaffeine uses xine again

dimitar wrote:but what happens if I don't want to use GStreamer?

Well now libqtmultimediakit needs gstreamer. And if you want for example see youtube clip in qtwebkit browser (Rekonq, Konqueror/kpart-webkit) you need... gstreamer

Edit.

dimitar wrote:and does not spawn gconf processes

Chakra devs found a way to remove the dependency - http://chakra-project.org/bbs/viewtopic.php?id=4455