Submitted by Gstreamer developer Christian Schaller explains why he thinks Phonon (announced a few days ago by the KDE project) is a broken wheel. “I have held back blogging about Phonon for some time to avoid flamewars, but I don’t want to have efforts like OSDL delayed due to setups like Phonon being promoted or thought of as a workable solution for the issues faced. Let me start of with a brief introduction to the area of multimedia frameworks.”
It’s nice “Gstreamer developer Christian Schaller” thinks that Phonon isn’t an optimal solution, but as a KDE user who has lived with an undermaintained arts for years… Yes the ‘abstraction of the abstraction’ is useful. KDE should be focused on building an easy to use DE that is easy to code for.
KDE developers should not be:
-Getting into the nitty gritty of ‘media framework’ development (As with Arts).
-Terribly concerned with GStreamer visibility.
This is one thing that amaroK and Kaffiene got very right. The choice between arts or raw oss/alsa was sub optimal. The choice of Gstreamer or raw oss/alsa wold only be slightly less worse. It’s not like there haven’t been plenty of people to suffer some version of gstreamer suckage at some point in time.
Phonon will allow the media apps to not have to re-invent the ‘pluggable media framework’ again and again (as is now the case), and will offer a choice of back ends, and platform independence. The choice between Gstreamer or raw oss/alsa isn’t much of an improvement over the current situation… You’re only one borken upgrade away from being stuck.
I’ll have that extra abstraction with some fries please. Being able to choose from Gstreamer, Xine, Arts, MAS, or whatever else is a good thing. Not having a half dozen re-implementations of this in KDE apps is good. Not being bound to any given project is good. CHOICE IS GOOD, IT PROTECTS OUR FREEDOM.
Edited 2006-05-11 16:22
CHOICE IS GOOD, IT PROTECTS OUR FREEDOM.
Freedom is useless if 4 of the 5 options will be mediocre or half baked, at the end 95% of the users will use the same backend and the rest %5 will be unmantained.
“Freedom is useless if 4 of the 5 options. . .”
Freedom is NEVER useless. The programs may be, but not freedom. Freedom is priceless. Unfortunately, most people don’t realize that until they lose it.
Freedom is useless if 4 of the 5 options will be mediocre or half baked, at the end 95% of the users will use the same backend and the rest %5 will be unmantained.
There’s a tiny flaw there. It hasn’t stopped Xine or MPlayer being used, as well as arts and GStreamer for different purposes. GStreamer also doesn’t do what NMM does. If 95% of people do end up choosing GStreamer, it will be used because it has been proven to satisfy most peoples’ needs in the real world and not because you or Christian Schaller wants it to be some sort of enforced standard.
It’s pretty simple: (a) GStreamer isn’t a stable platform yet (as KDE intents to be). (b) GStreamer isn’t universally liked. (c) GStreamer doesn’t acceptably cover all platforms KDE intents to deploy on. Hence the need for an abstraction mechanism.
The goal of Phonon is not to reimplement an API with the sophistication of GStreamer’s – applications with such requirements may bypass Phonon and use, for example, GStreamer. Phonon won’t make that any harder, by the way.
Phonon is designed to facilitate the majority of the use cases of a multimedia framework (basic playback and recording) as easy and lightweight as possible – for users as well as developers – independent of the platform KDE is run on. Because we don’t have that yet. And neither does GStreamer.
For those who say GStremer is unstable, check your config or distro because thay are wrong, the same was said about Cairo when it was implemented and now Rocks!!, if all desktop enviroment work on a common sound server then there are more chances to make it stable.
> For those who say GStremer is unstable, check your config or distro
Stability here does not so much refer to application crashes as whether an application that works with the current GStreamer version can be reasonably expected to work with future versions without breakage. Recently, the GStreamer 0.8->0.10 transition was more painful than it perhaps should have been.
> if all desktop enviroment work on a common sound server then there are more chances to make it stable.
Perhaps, but KDE 4 can’t afford to rely on an unstable one and hope things are just going to work out. Phonon is a contingency as well as a comfort layer. The idea is to protect users from backend problems by not taking the risk of limiting KDE 4 to one.
> the same was said about Cairo when it was implemented and now Rocks!!
While my knowledge on cairo is lacking, I believe the Mozilla guys still aren’t entirely happy with its performance (hazily remembering Planet Mozilla blog posts here). It may eventually get there, and when it does the synergy effect will definitely have helped, but I’d be cautious about suggesting it as a magic bullet.
For those who say GStremer is unstable, check your config or distro because thay are wrong
Are they? Not from my perspective they’re not, because something like Xine still works far better in most cases. Also, future versions of GStreamer need to work in exactly the same way. That hasn’t happened.
the same was said about Cairo when it was implemented and now Rocks!!
I get the impression you’re way too enthusiastic. It’s performance still needs work, it needs to get way more programmre friendly and some of the Mozilla people haven’t been too impressed with the performance.
I think that GStreamer just had a big update with API changes, so it isn’t stable.
With phonon you can do far less than with <insert favorite audio lib> but if the API of the audio lib change, only the corresponding plugin needs to be modified not all KDE’s application.
And phonon’s own API will hopefuly be more stable as it does less.
The fact that Christian is annoyed about Phonon shoes that he completely doesn’t get what KDE is all about.
If you look at the parts that make KDE shine, they ARE the simple, high-level API that bring application creation to the very surface of the programming ocean.
KDE is a platform that makes even an average Joe creative – just look at the multitude of little apps on kde-apps.org, and kde-look.org. We have an enormous load of “average Joes”, me being one of them.
Because of High-level API like (DCOP, SuperKaramba, Kommander, PyQT) I can easily scratch my own itches, like building a control for my ivtv-based TV card, tweaking a-foto to my liking (soon out on kde-look), implementing XVideo screen assignment applet.
GStreamer’s playbin “failed” because there’s just no one on Gnome planet to play with it. Instead of average Joes, Gnome collects deeply-involved coding priests, working on their towers of apps.
KDE has its priests who manage the core, but majority of KDE’s user base is happy when next “Visual Basic” shows up on the horizon. We can make the desktop more complete this way with less effort. I hate this comparison, but the situation IS like that between Mac and Windows.
Coming out of Soviet Union, I was for a while dismissive of “stupid Americans” for making everything in life easy, with Swifer Wet Jets and all. Yet, at the end, sorta wized up to the situation.
Christian is not talking about the “Average Joe”, read again, the “average” programmer can understand any sound server abstraction be it GStreamer or what ever.
Christian is not talking about the “Average Joe”, read again, the “average” programmer can understand any sound server abstraction be it GStreamer or what ever.
That is exactly what I am talking about. He completely forgets that the world is mostly made of “average Joes” His major complaint is “Phonon is NOT for uber-geeks”
And the post was not ABOUT “programmers”. It was about uselessness of Phonon. Christian argues that Phonon will be useless because it is hard to write something like an advanced multi-track recorder. You can only have so many multi-track recorders. The rest of the media functionality is “stupid” in comparison.
See the (already mentioned) aarons, post about this.
There are MORE simple uses of multimedia that don’t require heavy-duty lifting. He gives examples of voice recorder in note-taking app, and video clips in presentation soft.
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please…
Christian is not talking about the “Average Joe”, read again, the “average” programmer can understand any sound server abstraction be it GStreamer or what ever.
Nope, but there will be many people who do understand that Xine works and GStreamer doesn’t, or NMM does what they want and GStreamer doesn’t, and ulimately it will be those people and not you or Christian Schaller who will determine the direction things go in and what the ‘Average Joe’ mostly uses.
Christian doesn’t like Phonon because his company Fluendo is trying to become the “multimedia center” for Linux. In typical Microsoft fashion, spread FUD about competition and then deliver something suboptimal
I think the truth of the matter is that KDE doesn’t need gstreamer and rather is being “pushed” very much like the move to spatial gnome (which sucked sooo much it was amazing). Other than that I can say that as media frameworks go, gstreamer is pretty crummy – it’s more like an overbearing state than a “liberating” experience.
“Freedom is useless if 4 of the 5 options will be mediocre or half baked, at the end 95% of the users will use the same backend and the rest %5 will be unmaintained.”
The problem is that not everybody has experienced same rock solid and stable experience with gstreamer as you have. I wouldn’t go as far as calling gstreamer “mediocre or half baked”, and I’m sure that the gsteamer devs are very skilled and very nice people. I’d just rather not be wed to them for the next half decade… (FWIW, I’ve always has the best luck with the Xine backends for the apps I actually use. I like having the choice.)
Please read how Aaron (well me too:) sees it.
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please…
– none of them can include any proprietary codecs.
– none of them have any money to purchase licenses for distribution
– none of them have any “corporate” aliances with codec and hardware developers
– none of them really understand that frameworks are all bogus if you don’t have the apps to go over them.
– none of them will be able to implement MS/Apple/RIAA/MPAA compatible DRM solutions.
Will ardor port to gstreamer? will realplayer support Phonon? will Skype support anything beside Open Sound?
Edited 2006-05-11 17:38
> none of them can include any proprietary codecs.
Phonon is an abstraction layer on top of pluggable backends. Such a backend can be proprietary (let’s say DirectShow on Windows); Phonon doesn’t impose any restrictions there.
Huh?
Well, perhaps they cannot _include_ proprietary codecs in a solution, but that doesn’t mean one cannot _use_ proprietary codecs with GStreamer.
I’m doing the latter one, and it works fine.
You don’t know what you are talking about. (and you are plainly trolling)
* GStreamer *can* use proprietary codecs (yum install gst-plugins-ugly )
* Fluendo has actually bought a license to permit inclusion of mp3 decoding and release it to the public.
* Alliances. Irrelevant.
* Apps are coming. And with the stabilization of the APIs they are improving. See Dina, Pitivi, and so on.
* GStreamer specifically support DRM solutions.
Don’t take badly implemented apps like Skype as examples. Skype should use ALSA and be done with it. GStreamer has nothing to do with it.
Real has a proprietary audio framework that works far *worse* than GStreamer, so I doubt they’ll admit it and switch to the competition.
> * GStreamer *can* use proprietary codecs (yum install gst-plugins-ugly )
They are ILLEGAL to use!. They have NOT obtained permissions from Apple or Microsoft to use the codecs on Linux.
> * Fluendo has actually bought a license to permit inclusion of mp3 decoding and release it to the public.
NO!. You have to use a binary plugin that only is licensed for Fluendo’s MP3 player. It’s not available for FreeBSD or Solaris.
> * Alliances. Irrelevant.
That’s how industry works – you make aliances between content providers and and content distributors – if you don’t have aliances forget about Blu-Ray DVD, HD DVD, HD Audio and all future multimedia technonologies (unless you want to hack and run “illegal” software).
> * Apps are coming. And with the stabilization of the APIs they are improving. See Dina, Pitivi, and so on.
Wow, real block buster open source apps – arent’ they?
Where’s ardour or audacity?
> * GStreamer specifically support DRM solutions.
STOP LYING!
Illegality of the codecs: first, they are illegal *in the USA*. As much as this may come as a surprise to you, the world does not end at your border. Second, any company is free to develop a *licensed* and thus perfectly legal plugin for whatever codec and it will work with Gstreamer.
Oh? You wanted them *legal* and for free?
As for alliances: bull. Content providers and codec builders will become more and more entangled, till everything will fall apart. Think for the future. Refuse such pacts with the devil.
As for DRM…
http://blogs.gnome.org/view/uraeus/2005/12/03/0
It’s in the works.
And obviously companies are prefectly welcome to develop their proprietary plugin for GStreamer.
I’d probably add to your comment that even in the USA, many codec patents are on fairly shaky ground, and the legality of DRM — despite its widespread use — is still sort of questionable.
In the US, DRM that interferes with otherwise legal or sanctioned use of a work enters into a pretty murky area of law. If you had a good lawyer, I rather suspect that you could force a copyright-holder to not distribute DRM’d works — there’s some precedent.
They are ILLEGAL to use
so?
– none of them can include any proprietary codecs.
It depends on your definition of “included”; sure gstreamer.tar.gz doesn’t have proprietary codecs, but a distro is welcome to include GStreamer and some proprietary GStreamer plugins if they want to.
– none of them have any money to purchase licenses for distribution
Fluendo is doing exactly this.
– none of them really understand that frameworks are all bogus if you don’t have the apps to go over them.
I think there are plenty of KDE and GStreamer multimedia apps — not as many as there could be, but it seems like new open source multimedia apps are being started all the time.
– none of them have any “corporate” aliances with codec and hardware developers
– none of them will be able to implement MS/Apple/RIAA/MPAA compatible DRM solutions.
These two points are sad but true. Multimedia is political, not just technical. If open source multimedia communities have no political clout, they’re probably doomed no matter what frameworks they build or don’t build.
– you have no idea what you are talking about…
Do you know what Phonon is, or aims to be?
Please check http://phonon.kde.org/
Edited 2006-05-11 17:41
It would be sad that all this end up with yet-again-an-not-so-finished-framework, or having two understaffed then unstable frameworks. This curse had always beaten the linux multimedia experience (remember vlc, esd, aRts etc. ?).
Sad also that KDE developpers found that gstreamer isn’t the graal of the long awaited common unix/fd.o universal standard and compatibility layer for multimedia (as X11 is for graphic access etc.).
But they should better know than us what is the right choice for KDE.
As a begginer developer and BSD user, I can tell you my disappointment when I first tried to code with gstreamer (0.10), which I hoped would be the end of the linux multimedia curse:
– No *BSD port. (that is, gst 0.10 don’t work on FreeBSD nor OpenBSD nor NetBSD. It’s not tested there: it don’t even compile). Not nice for an “universal” API. And it wouldn’t be nice if every free multimedia appz from gnome and kde rely on gstreamer only (that would imply: no multimedia for the *BSD !).
– Quite frankly, the gstreamer has great ideas and competences, but they totaly fail to write and maintain up to date documentation. There’s no single tuto for the python binding. There no doc that teach you how to begin with the very formal (and outdated) API doc, and I’m sure that everybody did like me: guess how to use gst by looking at some actual implementation source code (not a good way to learn right !). So they’re not on a good position to whisper against other developers for not using your API.
– Also, gstreamer is 100% modeled around glib’s gobject model. Not easy to begin with (for a beginer perspective) and not clever for their KDE/Qt friends (should glib become a mandatory dependency of KDE ?).
– The basic needed work on gstreamer isn’t finished yet, we still lack DVD support (navigation etc), streaming (eg. mpeg-ts over udp, or multicast helpers), and many other small things like that.
– The evolution from gstreamer 0.8 to 0.10 left many important plugins/codecs behind, now unsupported, even many that were part of the standard gst-plugins (so even the maintainers of gstreamer failed to port those on the new release !). Maybe not a sign of good, pacified, long term API stability and engagment.
In many other aspects, Gstreamer is incredibly good, excellent, the best, even. But don’t do like I did, don’t have too much hopes, or at least, don’t judge other’s choices only with your hope of what gstreamer should be (and actualy, is not). Look at the code, try it.
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please…
I thought this might be coming. Christian just seems to be sore that KDE will not be joining itself at the hip with GStreamer. I wonder why.
I also find it amusing that he talks about the OSDL being held up by efforts like Phonon. Presumably he would like GStreamer to be some sort of OSDL standard. Sorry Christian, but GStreamer has to prove itself in the real world. The big mistake Unix made in the 80s and 90s was the promotion of certain software as standards that just couldn’t prove themselves in the real world. It also needs to work on more than just Linux. What happens to Gnome on BSD, Solaris or other? Fortunately, KDE will not be making that mistake.
If GStreamer is it then it will be it. If not, KDE will continue unaffected. Phonon will have absolutely no effect, unless Christian had something else in mind. There are also many reasons Mr. A. Seigo has come up with I won’t repeat.
Edited 2006-05-11 19:07
You are right not only does he look sore, it’s even more amusing when you look at the straw man arguments and other logical fallacy in this discussion.
Like the one about Phonmon making it impossible for developers wanting to write for the more professional use cases, rather nicly glossing over the fact that Gsttreamer are not suitable for those taske either. Those developers most likely would choose JACK for those demanding tasks, which by the way Phonon would intergrate nicely and work alongside with it’s JACK backend plugin.
Even more funny are those who claim it’s some kind of NIH syndrome at play, comming in defense of Gstremer it’s hillarius. Afteral Gstreamer is nothing more than a NIH itself. Had the initial developers bothered to help aRts along rather than starting from scratch, multimedia on the *nix desktop would have been farther along. Afteral the major reason for aRts lack of development was caused by Stefans Westerfeldt’s choice of switching to glibs event loop and the C usage that decission forced. The only reason that choice was to make it less problematic for the Gnome developers to switch to aRts and share framework with KDE. In hindsight it’s easy to see that it was a bad move and a Qt event loop/C++ solution would have been better. And last I checked(in 2006 btw) the Gnome desktop still had no comon multimedia infrastucture like KDE has enjoied for the last 6 years or so. It still needed ESD, Gstreamer was just used by the mediaplayers.
Edited 2006-05-11 19:45
Hi Morty,
Did you actually read what I wrote in that article?
I didn’t use any generic term like ‘profesional use cases’. What I did was point to five GStreamer applications in development and saying that I doubt Phonon would be able to cater for such apps. The straw man argument here is starting to discuss wether pro-audio apps like Ardour should/could be ported to GStreamer. Also the talk about a Jack backend for Phonon sounds strange to me considering that Jack is a advanced sound server, not a media framework. Afaik so is there no such thing as a decoders for instance in Jack.
Christian
Did you actually read what I wrote in that article?
Have you read what’s been written since?
What I did was point to five GStreamer applications in development and saying that I doubt Phonon would be able to cater for such apps.
Well, those apps are at extremely varying degress of development (and currently mean nothing to anyone in the OSS world) and the functionality those apps use means nothing to the vast majority of desktop applications out there, and in KDE. I would imagine Phonon would be designed around giving current KDE applications what they need, and what can be done in differing frameworks, quickly and easily for KDE developers and on different platforms other than Linux.
No doubt Phonon will not give everyone all of what they need so they will inevitably pick a framework like GStreamer, NMM or Xine and go with that. Indeed, they may discuss trying to add functionality to Phonon, if practical and supportable. Neither KDE, nor you I might add, has any right to dictate GStreamer to them as a pre-requisite. They have to use what they need.
Segedunum I have read some, but not all of what has been written since. But it isn’t my responsibility to defend other people’s claims, I only defend my own. So I do feel entitled to correct people when they put words in my mouth.
Regarding the functionlity of those apps meaning nothing to the vast majority of desktop applications out there, that might be so. I don’t agree that iMovie style NLE’s are non-important as we move forward, but I have no problem accepting someone feeling that way. But I have seen very few people make that argument, that Phonon is good enough because my usecase examples are not important to Joe user. Only arguments along those lines are a few comments here and there like the one I originally replied to trying to claim I was talking about pro-audio applications like Ardour.
Hi Christian
“Did you actually read what I wrote in that article?”
Well I actually did, may come as a surprise on a site like this, but that’s what I usually do.
And from looking at those apps you mention they don’t seem to be designed with too heavy requrements, making them all possible Phonon users. The two audio applications(jokosher and buzztard) may perhaps be best served if you use Phonon with one of the lover latency backends. But all in all well inside the realm of which Phonon are aimed, the exception are still considered to be pro-audio apps and heavy duty video editing. None of those apps seem to require that, so it’s more a question of what the Phonon developers bother to include not limitations in the way it’s designed. And looking at the phonon website and quick glance at the mailinglist shows the features needed by the video applications are all considered.
And the talking avbout using JACK as a backend is not so strange, there are users who will consider the low latency for sound achived by JACK more important than any other media needs and tailor their system accordingly.
Edited 2006-05-11 23:16
Even more funny are those who claim it’s some kind of NIH syndrome at play, comming in defense of Gstremer it’s hillarius.
Well this NIH syndrome thing always comes up, and it has to be said, it always goes in one direction.
KDE started using arts many years ago, and it may not have fallen into disrepair as it has done if it was adopted by Gnome. Indeed, many things were done to make it attractive in that direction and Gnome went off to use the unmitigated disaster that is ESD. What was that about?
KPDF uses Popplar, KDE in so many areas uses libxml2, it uses HAL and DBUS where the functionality is useful, KDE people came up with GTK-Qt, which I might add, Gnome and GTK people seem to be totally disinterested in etc. etc. What the hell’s the problem?
Just because something gets used by Gnome, or appears to, and then gets lobbed on to Freedesktop does not mean KDE then needs to adopt it in a direct fashion to avoid ‘letting the side down’. The stuff on Freedesktop needs to prove itself first, including GStreamer, in a practical manner. Maybe the NMM people should get space on Freedesktop and start blogging about how Gnome should be using NMM and how the GStreamer route that Gnome is going down is totally broken? Do you see any posts or comments like that? No, you dont.
Indeed, many things were done to make it attractive in that direction and Gnome went off to use the unmitigated disaster that is ESD. What was that about?
That’s not relevant; Gnome standardized on ESD before KDE standardized on aRts.
KDE people came up with GTK-Qt, which I might add, Gnome and GTK people seem to be totally disinterested in etc. etc. What the hell’s the problem?
eh… GTK-Qt is a Gtk theme engine which uses Qt to draw the widgets. Why would Gnome and GTK people be interested in that? What the hell’s your problem?
Maybe the NMM people should get space on Freedesktop and start blogging about how Gnome should be using NMM and how the GStreamer route that Gnome is going down is totally broken?
Sure, they could do that; but they’d be wrong.
That’s not relevant; Gnome standardized on ESD before KDE standardized on aRts.
Well, you can make that an answer to everything.
eh… GTK-Qt is a Gtk theme engine which uses Qt to draw the widgets. Why would Gnome and GTK people be interested in that? What the hell’s your problem?
Because it would go in the other direction and enable good KDE applications like Task Juggler to be run under Gnome, that have no real equal, so people could enjoy them (like I enjoy VMware console fitting into my desktop)? It might also pave the way for better GTK and KDE integration.
Sure, they could do that; but they’d be wrong.
Brilliant. Well, on an equally opinionated basis I think people who push GStreamer as the answer to the free desktop’s multimedia woes are wrong. So there.
Edited 2006-05-12 12:11
Well this NIH syndrome thing always comes up, and it has to be said, it always goes in one direction
I’m wondering where this paranoia came from.
KDE started using arts many years ago, and it may not have fallen into disrepair as it has done if it was adopted by Gnome
What are you doing there ? Putting the fault for the brokenness of ARTS on Gnome ? Why do you have to take one to beat the other ?
I could as well say that Gnome did well to not adopt arts, given what it has become.
many things were done to make it attractive in that direction and Gnome went off to use the unmitigated disaster that is ESD
ESD still works well despite the words “disaster” you love to use, as well (or as bad) as ARTS at least. Noone uses their features anyway, I think that’s where the disaster really is. ESD and ARTS were sound servers though, not multimedia frameworks.
KPDF uses Popplar
Which derives from XPdf, which is old unmaintained known code with some problems. Why reinvent the wheel ? Poppler is a right thing to do.
No real link to Gnome, except that Gnome devs decided to make a library from Xpdf.
KDE in so many areas uses libxml2
Proven through the years, and still actively maintained. One (if not the) best XML library. Again, because Gnome adopted it does not imply anything about KDE adopting it too, except that it is very good.
it uses HAL and DBUS where the functionality is useful
Which are in the same state more or less as gstreamer, in terms of stability for example.
That’s one of the main reason why I don’t understand the Phonon move.
KDE people came up with GTK-Qt, which I might add, Gnome and GTK people seem to be totally disinterested in etc. etc. What the hell’s the problem?
The problem is your paranoia. The interest in GTK-Qt is naturally from Qt people. Why would GTK devs be interested in it ?
They said it’s a good thing, what do you want more ? That they start developing with Qt instead of GTK ?
Just because something gets used by Gnome, or appears to, and then gets lobbed on to Freedesktop does not mean KDE then needs to adopt it in a direct fashion to avoid ‘letting the side down’
That’s not the case at all. Did it occur to you that perhaps, Gnome adopted these things because they were good ?
Is it the fault of Gnome, that most of these API and libraries are developed in C ?
I think that’s the main reason why Gnome adopts them first, because they are done in C, that’s all.
The stuff on Freedesktop needs to prove itself first, including GStreamer, in a practical manner. Maybe the NMM people should get space on Freedesktop and start blogging about how Gnome should be using NMM and how the GStreamer route that Gnome is going down is totally broken? Do you see any posts or comments like that? No, you dont.
For the simple reason that GStreamer is already far advanced. If NMM were to do anything, it’s too late, it should have been made at least 2 years ago.
We already discussed Phonon here on OSNews, and my views were nearly the same as those of the GStreamer dev here. A. Seigo made the same answers then.
I still disagree with him that 99% of multimedia apps do not need the advanced API the GStreamer dev talks about.
And I don’t understand why A. Seigo talks about him having problems with GStreamer in Amarok. This can have a LOT of reasons, all having to do with the fact that there is one more level of abstraction in Amarok, the very same that will be added by Phonon and its backends.
Like I said last time, just we wait and see. I see Phonon as a mistake, but I understand that KDE devs don’t want to be burned twice. I think that’s what will happen anyway if they go the Phonon way.
At least, GStreamer devs said they will support the Phonon/GStreamer backend, which they’d better do. A GStreamer/NMM backend would be good too IMHO.
There is already a GStreamer/JACK backend after all. I have nothing against Phonon, and KDE devs know their resources better than me, so I think they know they can do it right. Phonon is even an enjoyable thing to do. What I fear most in fact, is that if it ends up being useless, it will be more ammo to loads of FOSS bashers that say OSS is full of duplicate efforts, and will divert some resources from KDE for nothing.
But all of this is speculation.
Just wait and see what happens.
Maybe we are so used to rants that we didn’t see that Christian actually volunteered to resolve all issued KDE might currently have with GStreamer.
Maybe he intended to say that he will personally work on an API/ABI compatability issue during the whole KDE4 lifecycle and make sure GStreamer is available on all platforms KDE4 supports and all KDE developers would have to do is a Qt-style API on top of that.
However this sounds a bit unrealistic for one developer, maybe he has already assembled a task-force that will work on meeting KDE’s requirements.
On the other hand, maybe it was really just a rant, who knows
versus each other 🙂
” KDE people came up with GTK-Qt, which I might add, Gnome and GTK people seem to be totally disinterested in etc. etc. What the hell’s the problem?
eh… GTK-Qt is a Gtk theme engine which uses Qt to draw the widgets. Why would Gnome and GTK people be interested in that? What the hell’s your problem?”
Err… right, the GNOME ppl shouldn’t be interested in doing that but they can surely make a QT-GTK engine that does exactly the opposite.
“Maybe the NMM people should get space on Freedesktop and start blogging about how Gnome should be using NMM and how the GStreamer route that Gnome is going down is totally broken?
Sure, they could do that; but they’d be wrong.”
Why would they be wrong? Because it’s not GStreamer doesn’t mean it’s not good. NMM is better than Gstreamer at certain task, PERIOD. And so is Xine, Mplayer, Helix etc. I am a KDE user and I want choice, PERIOD. If the KDE developer wants to give me that choice why should a gstreamer developer have a problem with that?
Let’s analyse why Gstreamer may not be the perfect solution:
1. The user prefers Xine instead of gstreamer (You can’t force him to use Gstreamer, if you do I call you a gstreamer fanboy and troll.)
2. The user may prefer MPlayer.
3. The user may prefer NMM for synchronising audio and video playback between two computers.
4. The user may prefer well, XYZ (such as Helix, Real Audio (I know it sucks but…….. ).
Phonon is there to give them that choice. Phonon will not harm Gstreamer in any way. If gstreamer is good, people will use it. However there is no need to standardize on gstreamer now.
And I agree with A. Seigo that a majority of multimedia apps dont require advanced functionality of any media abstraction layer.
Lets see what these apps are: Amarok, Kaffeine, Juk, Totem etc.
Do you think they need advanced functionality? I say NO.
On the other hand, Audacity does require advanced functionality: so Audacity can use Gstreamer/ALSA/xyz layer to achieve that.
SIMPLE as PIE.
I could as well say that Gnome did well to not adopt arts, given what it has become
AFAIK this decision is part of the current problem. At the beginning some GNOME developers were quite positive about using aRts so Stefan Westerfeld tried hard to not introduce any Qt dependency, which in turn lead to very few KDE developers wanting to work on it.
Which are in the same state more or less as gstreamer, in terms of stability for example.
That’s one of the main reason why I don’t understand the Phonon move
HAL is not exposed as an API and will be abstracted in KDE4 by Solid, just like Phonon intends to do for mediaframeworks.
D-Bus on the other hand is committing itself to long term stability for their 1.x series.
A. Seigo made the same answers then.
I still disagree with him that 99% of multimedia apps do not need the advanced API the GStreamer dev talks about
Aaron said desktop applications. Only a small portion of desktop applications are multimedia applications.
For example applikations like educational tools or presentation apps only need very basic multimedia capabilities.
What I fear most in fact, is that if it ends up being useless, it will be more ammo to loads of FOSS bashers that say OSS is full of duplicate efforts, and will divert some resources from KDE for nothing
Well, since there is no duplication on part of KDE, it will be just bashing based on false “facts”.
There would be duplication diverting resources from KDE if someone else were about to create long term stable KDE bindings for GStreamer, but I don’t see anybody outside of KDE doing that.