From kde-multimedia Wed Sep 25 13:00:43 2013 From: Harald Sitter Date: Wed, 25 Sep 2013 13:00:43 +0000 To: kde-multimedia Subject: Re: Fwd: looking for phonon gstreamer maintainer Message-Id: X-MARC-Message: https://marc.info/?l=kde-multimedia&m=138011411412670 On Wed, Sep 25, 2013 at 1:24 PM, Aaron J. Seigo 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 _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia