Guys I found this in one of the comments to Asiego’s blog: http://lwn.net/Articles/183462/
It is from someone named Michael Pyne. And it is the first piece I have read about the Gstreamer vs. Photon issue which is not FUD and appears not to be based on misinformation. According to this text the *real* issue is binary compatibility-ie. that Gstreamer cannot and will not provide the ABI stability that KDE4 needs for the length of KDE4 lifespan, and not through any fault of their own.
According to this text the binary compatibility is the key issue here: in his own words:
“This isn’t to blame the gstreamer developers: Both gstreamer upgrades were a definite change for the better. But the problem is that they were still a definite change. We won’t be able to keep the Qt/KDE gstreamer bindings up to date, not to mention binary compatible, without limiting the scope of the API that we wrap. In fact, Phonon is about the extent of the amount of wrapping we’d be able to do.”
It seems to me that phonon is an extremely thin layer which wraps an abosolute minimum which is equally supported by all backends (directshow, quicktime, gstreamer, xine). It is a convenience API for QT/KDE app developers who do not need to do any real heavy lifting-ie. more demanding audio/video work.
You guys can go on and on about QT vs. Glib dependencies, or LGPL vs GPL, or about how good gstreamer compatibility is acrosss various OS’s-but if KDE needs binary compatibility for the life of KDE4 and phono fills this bill then it is the best tool for the job.
Of course what would be really cool is if Nokia/trolltech would simply wrap the entirety of gstreamer and place it directly into QT. Then QT/KDE devs would have this amazingly simple abstract API which is pure magic for those devs and they would embrace the media framework developed by and for the FOSS community. Then work could be done to soldify the OS X and Windows gstreamer ports so that really shine.
And of course what would also be really cool is if QT/KDE would wake up and smell the roses and actually address the issues which Pulseaudio is addressing. I want to see support for XDG sound themes in KNOTIFY and I want KNOTIFY not to wreak havoc with other applications vying for access to my sound card. Hey maybe if the KDE community would embrace Pulseaudio there might even end being good ports of Pulseaudio to other OS’s 😉 And I want that when I use a KDE multimedia app that it registers itself with Pulseaudio and lets me redirect my audio to my PC connected to my home surround sound system.
Put another way it simply would not hurt QT/KDE to embrace gstreamer and pulseaudio and to do so publicly. Many act as if these two projects were GNOME projects-the reality is it is the distros which have made their interests clear-gstreamer is *the* FOSS media framework and pulseaudio is *the* FOSS sound server. This is not a GNOME vs. KDE thing-it is a KDE-runs-on-every-platform-under-the-sun-aspiration vs. Linux distributions. The linux community via gstreamer and pulseaudio is finally beginning to really address some its real shortcommings and
KDE is off touting Windows compatibility…major disconnect here…
And in the meantime we will just ignore the fact that most users don’t care about the legal obligations of the commercial corporations involved in gstreamer development and the commercial corporations involved in Linux distribution-us users will simply install xine and mplayer to deal with those things which gstreamer cannot deal with or only deal with by demanding outrageous sums of cash. At least KDE devs give us the choice to use xine-something the GNOME devs don’t do(ok I lied: totem-xine is still around ;)).
I use Gstreamer and I am quite impressed with it’s capabilities and the apps which utilize these to their fullest. But I must add that I find it sad that Gstreamer is *still* not capable of dealing with as many, and dealing as well with the formats supported by xine. Gstreamer has improved by leaps and bounds, and it has a tremendous community built up around including a number of commerical companies-a community much larger and more diverse than xine. Yet xine is still the only media lib I have found that religously works with any damn thing I throw at it. Of course on most distros xine is so crippled that it is basically useless-but here I am using xine on 64bit(which means no wincodecs) and the only thing that I find that it could still do better is navigate menus on DVD’s(I am just waiting for libdvdnav to be cleaned up and integrated in xine-the newest version with mplayer allows for flawless DVD playback). Gstreamer still fails to support a number of formats- and of those which it does support it often fails to do things like fast forward/rewind. That phonon can use both gstreamer and xine means that I can playback virtually any kind of media in existance. And it needs to be said that it is the commercial companies and their legal requirements which are the biggest limiting factors in Gstreamer capabilities-and it is this squeaky-clean image of Gstreamer which is driving it’s commerical adoption(3 years ago I could playback DVD’s far better with Totem-gstreamer than I can today, before the commercial interests basically took over gstreamer). Now Ubuntu can offer me gstreamer codecs to playback the contentious formats-$90 or I can simply use xine-which irks me greatly because the DVD drive which I purchased already included a license for DVD playback-just not for Linux-which to me is utterly absurd.