Fwd: looking for phonon gstreamer maintainer

[Harald Sitter]

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