confuse about the whole phonon gstreamer thing

[tikal26]

So I don't want to pick a figth with anyone. I just want to educate myselft a littel bit so I might actually develop an educated opinion. I don't undertand what is with this whole phonon, gstreame thing going n. At first I though that they were two different thing, but some people seem to think that it is, may I was wrong. I red the phonon and gstremer website and I am still confused. I guess I don't understand how multimedia works in linux. Anyone knows wher eI can get some info on it. I guees I don't understand what is the difference between things like gstreamer and NMM and what are the advantages and disavantages of each one over the other ones.  I also don't understand this whole front end backend thing. I thought tha tI was able to chooe that already. Isn't that what Amarok and Kaffeine does? ok so if any one can poinme towards some easy to understand information I would apreciated.

[askrieger]

Re: confuse about the whole phonon gstreamer thing

I certainly can't say I understand it, but for a start, look at this article: http://www.linux.com/article.pl?sid=06/05/05/1540250 and the references therein.

[claydoh]

Re: confuse about the whole phonon gstreamer thing

another link:
http://grammarian.homelinux.net/~mpy...-whineage.html

Don't feel like you are picking a fight, a lot of us don't quite understand
as far as I can tell, phonon is sort of like a connector between apps and multimedia bits (xine, or even gstreamer) This of course doen't really clarify anything yet for me

[Fenyx]

Re: confuse about the whole phonon gstreamer thing

Some other links that I hope will help:

Front-end/Back-ends: http://en.wikipedia.org/wiki/Frontend
Multimedia Framework: http://en.wikipedia.org/wiki/Multimedia_framework
Some thoughts about the KDE/GStreamer issue from some KDE devs:
Aaron Seigo: http://aseigo.blogspot.com/2006/05/i...ye-please.html
Ian Monroe: http://amarok.kde.org/blog/archives/...GStreamer.html
Michael Pyne: (the link that claydoh gave)

I'm no programmer or linux expert, but this is how I understand these things:
In programs, the back-end is the part that does the dirty work, hidden from the user, while the front-end it the part that gets input/data/instructions for the back-end to work on. The front-end/back-end relationship can be present in one single program or one program can act as a front-end, while another program acts as the back-end.
For example, in amaroK, the front-end is amaroK itself, which is in charge of organizing your music, displaying them, giving you the interface, etc. However, by itself, amaroK is not capable of playing the music. It uses a back-end to do this. How the back-end does this is unseen to the user. and these back-ends are GStreamer, Xine, etc.

Now multimedia frameworks, to my understanding, give a set (libaries) of APIs (programming commands) that (more or less) instruct your computer what to do with the media, like playing, stopping, pausing, etc. Different multimedia frameworks offer some different features, which I'm not really familiar with. All I know is that these frameworks (sometimes referred to as "engines") are in charge with actually playing (or telling your computer to play) the media.

Phonon, if I understand it correctly, is not an actual multimedia framework, but more of a "wrapper", providing a library of API that can be used all throughout KDE and not just one KDE app. Think of it as an added layer between front-end (amaroK) and back-end (GStreamer).

The current situation now, I think, is that for amaroK to be able to use
GStreamer, the appropriate GStreamer-amarok plugin has to be used. This plugin is developed separately from GStreamer and amaroK. But Xine uses another plugin, and so do any other back-end. and then a xine-juk plugin is another plugin that has nothing to do with the xine-amarok plugin. So what you have is that you have one plugin per engine/back-end per application. But that's only now. Who knows how many more engines/apps will be developed in the future.

What Phonon does is to simplify these things. by providing a separate layer between back-end and front-end, you don't need to have separate plugins for each engine to work for each application. The plugins just need to refer to the Phonon API and it will work for all apps.

Current situation:
GStreamer --- gstreamer-amarok plugin --- amaroK
GStreamer --- gstreamer-juk plugin --- juk
Xine --- xine-amarok plugin --- xine
Xine ---- xine-juk plugin --- juk

With Phonon:
Gstreamer --- Phonon --- amaroK/juk/all KDE
Xine --- Phonon --- amarok/juk/all KDE

That's just one part of the situation. What the KDE devs really want is for KDE 4 to be able to work with any multimedia framework that exists or will exist for as long as KDE 4 is maintained/supported, on all systems that uses KDE. They don't want to be tied down to one engine that may cease to exist in the near future.

But Phonon is really just for basic multimedia functions. Phonon is just for the basic or average user. The good thing about it is that if you need in-depth, more powerful multimedia stuff, it's still possible to go around it.

This is just from my point of view. Not really sure if it's accurate.

[askrieger]

Re: confuse about the whole phonon gstreamer thing

I don't know about the O.P., but I'm still confused. It wasn't that long age that I was still using aRts.

[Fenyx]

Re: confuse about the whole phonon gstreamer thing

Well, what I gave wasn't actually the issue regarding the GStreamer v. Phonon, but more of a reason for the existence of Phonon, which is related to the main issue...

I'm not really certain about the details regarding aRts and KDE, but what happened was that for KDE 3, the devs decided to tie down KDE's multimedia to aRts, which I think was quite popular back then. Unfortunately, after some time, aRts was slowly becoming unmaintained. This created problems for the KDE devs. And so at one point (around 2004 or 2005 I think), the KDE team made a commitment not to let something like this happen, that is, being tied down to a multimedia framework that may or may not continue to exist in the future. Ergo, the birth of Phonon. So Phonon, I think, is basically a solution (or more appropriately, a reaction) to the aRts problem.

Now enter Christian Schaller, a GStreamer dev, who basically says that the idea behind Phonon is wrong. Of course he has lots of reasons, but you can read his blog for that info (http://blogs.gnome.org/view/uraeus/2006/05/11/0). What he's saying is that KDE shouldn't do Phonon and should instead adopt a single multimedia framework, like GStreamer (no surprise there). This is, I think, what GNOME is doing. (Note: GStreamer, AFAIK, is not a GNOME based project). That's just the facts, but it has turned into almost a flame war between different camps, including but not limited to, GNOME/KDE. What I find funny, though, is that non-KDE users are the most vocal advocates of dumping Phonon in favor of GStreamer, where in fact it has no direct or immediate effect on them.

In my most humble () opinion, both sides (Chris and KDE devs) have valid reasons, but they should remain as opinions. I mean, I find it quite improper for a GStreamer dev to tell KDE devs that Phonon is wrong and that they should adopt GStreamer. It seems that he is advertising their own project. Whether it was intention or not, he shouldn't have said those things or could have said them in an unbiased way. Even judges inhibit/recluse themselves from hearing cases that are directly or indirectly related to them.

I also didn't like what Chris has said about Phonon delaying the efforts of OSDL/Portland Project. The OSDL camp has not even said anything about Phonon. It seems that his idea of "harmony" between different DE's (at least in the realm of multimedia) is to have one multimedia framework to rule them all, so to speak. It seems to me that he sees Phonon as counter-productive because it opposes their own goal of establishing GStreamer as the de facto multimedia framework. But IMHO, Phonon actually helps the OSDL/Portland Project because it ensures that any and all KDE apps can work on any and all platforms, DE's, systems where KDE is available. And that's a whole lot of systems.

Another argument against Phonon that people are saying is that KDE is overreacting to the aRts issue. That may be true, but who can blame them? When a person undergoes a traumatic experience like being in a car accident, you don't tell them they are overreacting if they decide not to ride cars anymore. Besides, I don't think KDE is overreacting. They've had almost 2 years to think about this thing.

Whew! Another long post. Ok I guess it's about time to stop here.

DISCLAIMER: The author of this post has not done any form of coding, whether in KDE, Qt, or C++ and therefore bases his opinions solely from articles written by certain authors and from certain logical/psychological deductions.

[tikal26]

Re: confuse about the whole phonon gstreamer thing

ok so I'm beign doign a little bit of reading and here are my conclutions:
Phonon is not a backend but it prevents KDE from relying on one thing too much.
KDE might have oberreacted, but phonon will make some cool things avaialbe like a mixer for each use. A mixer for your music, movies, etc (cool). In theory you could choose different backends for whaever you need to do. There is some talk of actually having multiple backends avaialble at the same time.
I must say that after some reading I agree with the phonon idea because I hope that gstreamer manges to accomplish its goals,but at the same time I have find out about other exiting backends like the NMM http://www.networkmultimedia.org/ that I would like to have a vailable. Thanks for all ofyou opinions and links