Fwd: looking for phonon gstreamer maintainer

[Daniel Nicoletti]

I have a question:

I had to write a Qt5 app for playing music/video some
time ago, and I have used QtMultimedia5, so far so good
QtMultimedia seems to provide everything I needed tho
it still uses gstreamer 0.10. AFAIK Phonon was created
due the lack of QtMultimedia, so now that it's there and
it's maintained shouldn't we drop Phonon, or even better
why is Phonon still important?
I googled trying to find their differences but I still have
this questioning...

Thanks


2013/9/25 Harald Sitter <sitter at kde.org>:
> On Wed, Sep 25, 2013 at 1:24 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> On Wednesday, September 25, 2013 12:35:25 Harald Sitter wrote:
>>> since everyone who ever was/is/wanted to be Phonon GStreamer
>>> maintainer is either busy or has no interest in it, the backend has as
>>> of right now no actual maintenance.
>>
>> you may not get much a reply without some more information:
>>
>> * is there some underlying reason why there is no interest in maintaining
>> Phonon GStreamer? e.g. is there a GStreamer annoyance that needs to be known
>> about / taken into consideration?
>
> I think it's just that one needs to be comfortable working with glib
> and have the time. Although I guess one could try to start using QtGst
> which should help with the glib thing a bit ;)
> Or perhaps everyone got headhunted after putting Linux multimedia on
> their public CV :O
>
>> * what are the real-world ramifications of not having GStreamer support? which
>> platforms might suffer due to a lack of integration / codec support / etc as a
>> result?
>
> GStreamer only ever was supported on *nix platforms meaning for the
> better part only Linux distributions would be affected by dropping
> GStreamer.
> We do however have VLC support and VLC runs on all platforms, so codec
> support would not suffer. Integration into the overall Linux based
> workspace on the other hand could become somewhat less optimal.
> GStreamer is directly used in various advanced use cases that cannot
> successfully be covered by abstractions (e.g. QtWebkit, Kamoso,
> Telepathy) so it is already a hard requirement for most workspace
> distributions, dropping GStreamer support would essentially mean that
> everyone will have to have GStreamer and VLC installed to get a
> complete Plasma workspace experience.
> Additionally there is a bunch of feature discrepencies between the two
> backends [1] that for example would make Amarok loose the newly
> introduced analyzer.
>
> At the same time incoming and resolved bug metrics suggest that the
> current GStreamer backend offers subpar quality (at least compared to
> the VLC backend) and thus degrades the workspace experience as a whole
> (it's not terribly entertaining if knotify explodes at login for
> example). So if it need be we'll have to make the not-optimal
> situation of VLC (for Phonon) and GStreamer (for other stuff) being
> both required work as best we can. It certainly beats offering an ever
> so random crash experience.
>
>> * what effort is currently required to support Phonon GStreamer? Is it stable
>> and needing continued testing and bug fixing maintenance; is it need of more
>> major surgery; is the big work ahead a port to Qt5 or a change in Phonon?
>
> Major surgery: yes. So, right now the backend supports GStreamer 0.10
> which is deprected upstream in favor of 1.0, for which there is a
> branch that is mostly ported but apparently not working with
> complicated applications such as Amarok. That is probably what needs
> to be moved forward the most urgently as most distributions are
> looking to adopt 1.0 sometime soon, and right now Phonon GStreamer
> essentially forces distributions to also ship an upstream unsupported
> GStreamer version.
>
> Stable: not the word I would use. There are currently 37 bugs that are
> open/needsinfo of which a rather big chunk seems to be actual crashes
> (perhaps in GStreamer itself though). Since no one actively triaged
> them in quite a while it's hard to say how many of those are legit
> issues caused by Phonon GStreamer.
>
> All that being said. I am working on a Phonon5 version of libphonon
> featuring simplified API which will eventually need porting too, but
> not any time soon and if anything it also allows simplification of the
> backend code.
>
> So here is what I would do if I had the time and motivation to poke
> Phonon Gstreamer:
> a) finish the 1.0 port -> release
>     this is actually a very good way to get used to the code and glib
> and gstreamer and learn about how phonon backends work
> b) rewrite the entire thing -> over the course of a couple of releases
>     which greatly helps with getting rid of cruft accumulated over time.
> c) sip Margaritas while shooting the odd bug that appears once a month
> with a sniper rifle
> d) at some point port to phonon5
> e) more of c
>
> Phonon backends are incredibly low maintenance if written well, except
> that Phonon GStreamer is not written well (at least in my opinion, and
> I am very opinionated about what good code looks like, so I may be
> wrong). Above steps are by the way what I did with Phonon VLC so I'll
> call it the 'apachelogger method'(tm) and assert it as the only way to
> make a phonon backend not suck donkey balls.
>
> [1] http://community.kde.org/Phonon/FeatureMatrix
>
> HS



-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com