Starting 1st of November Fluendo will be dedicating a resource to implementing a full featured GStreamer backend for Phonon, the multimedia API for KDE4.
The goal is to make the best backend for Phonon possible in order to demonstrate the qualities of GStreamer to the KDE community and hopefully lessen the chance of fragmentation in the free software multimedia space. This work is done in cooperation with a major industry player who shares our goal of providing the Linux and Unix communities with a unified multimedia API. I let them let announce their name themselves due to contractual reasons, but I do expect to see them talking publically about this at some point as it is quite direct follow-on to already announced efforts they are doing to bring more unity the free desktop under the auspices of the Portland project and the LSB.
As some of you know I have personally voiced reservations on Phonon in the past, and while I still think some of my concerns are valid, I hope that this effort can be a starting point for a more productive exchange of ideas. If we manage to make the GStreamer backend as good as we hope to then it would be a big step forward in resolving the worries some KDE developers have voiced about the readiness of GStreamer and maybe even encourage the development of a full set of Qt-style binding to GStreamer to suplement to the high level objects of Phonon.
I also hope is that this work will be a big step towards making users life much easier, as it will allow distributions to ship GStreamer plugins that enable proprietary codecs, and know that no matter if the user uses a GNOME/GTK or KDE/QT application the user will get access to these formats (at least as soon the licensing of applications are sorted out ;).
What is your opinion of AvKode, a phonon backend for FFmpeg that is a Qt/C++ implementation of libavformat and that uses the universal decoder libavcodec?
http://websvn.kde.org/branches/work/avkode/avkode/
AvKode’s author, Allan Sandfeld (carewolf), claims that going straight to the source (FFmpeg) will make it easier to add new features like encoding.
Whoa, this is great!
I always wondered if there would be someone stepping up for a GStreamer plugin (after all, Xine, NMM, and MPlayer through FFmpeg are already being worked on), however I didn’t expect the GStreamer people to do it themselves.
Big praises from my side!
And for the dedicated GStreamer-Qt stuff – I’m sure people will eventually use GStreamer for pro-audio or video editing stuff. It’s just that simple players don’t need GStreamer’s power, and being able to select from various engines is more important to them.
GStreamer will be the standard media framework, that way or the other. No need to lock out other frameworks to achieve that, the plain superiority of GStreamer will suffice :D
As long as it’s not distributed by default even in KDE-centric distributions, it’s just not superiour enough. But it will be, no question on that.
Bill,
I believe the GStreamer backend will cover encoding from the beginning. GStreamer is not a playback only multimedia framework. FFMpeg does not cover hardware audio output/input, video output/input well.
Also the big crunch is that ffmpeg is not legally distributable in the USA and other countries due to patent restrictions. The LGPL and GPL require you to transfer all rights on the code (including IP such as patent licences) on distribution. This would of course be crippling financially on distributors. Quote from LGPL (licence ffmpeg is under):
“For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.”
This is fantastic news. Matthias of Phonon has already blogged about it.
Thanks for the announcement, thanks to Fluendo, and thanks to the “major industry player” that isn’t known yet :).
It’s always great to hear about collaboration. Good example of people having differences (need for Phonon), but seeing the larger picture and working together.
Thanks again!
Zaheer,
Thanks for your explanation. Hate it how US patent policy is so anti-consumer.
This is the best possible outcome. Congrats and thanks to you and your sponsor.
Excellent!
Not sure about the benefits of shipping proprietary codecs though. It may be the easiest option, but every penny you pay to them goes to their pro-swpat lobbyists and their enforcement legal department. So it rather annulls any philosophical high ground you may be heading for in the long run.
Christian,
As author of one of the pro-Phonon essays when this first started I’d just like to say that I’m very excited to hear this news. I just wish I actually had the time to contribute to chip in myself. :-(
Zaheer, just curious but GStreamer is under the LGPL license as well, so what is the difference with ffmpeg?
Quintesse,
The difference is in the packaging and organisation of GStreamer. GStreamer is organized in a way that makes it very easy for distributors to use the core and a set of assumed patent free plugins and combining that with licensed codec implementations to be able to ship out of the box support for whatever codecs they want.
jonny
jonny