Fwd: looking for phonon gstreamer maintainer
-- Forwarded message -- From: Harald Sitter Date: Mon, Sep 23, 2013 at 4:55 PM Subject: looking for phonon gstreamer maintainer To: "For discussion of multimedia (sound/video) issues under KDE" Ahoy, 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. If anyone wishes to step up and move the backend forward now is the time to do it. I'd like to note that this is not a one-man job though and I am going to continue to be supporting developer. In the unfortunate case that no one is willing enough we will have to look at the possibility of moving the backend out of the support scope, leaving Phonon VLC as the only actively supported backend on all platforms. As immediate result I will likely have to demote the backend's initial preference for the upcoming 4.7.0 release below Phonon VLC's. HS
Re: Fwd: looking for phonon gstreamer maintainer
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? * 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? * 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? -- Aaron J. Seigo
Re: Fwd: looking for phonon gstreamer maintainer
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
Re: Fwd: looking for phonon gstreamer maintainer
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 : > 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
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 3:38 PM, Daniel Nicoletti wrote: > 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... It has the most ludicrous API in all of multimedia. More to the point though Phonon was part of kdelibs4 as such it is needed to retain compatibility. Less so with frameworks5 though. Phonon was created because we did not want to bind kdelibs and core applications to one library we have no control over that then ends up breaking API (as gstreamer did shortly before that 0.9 -> 0.10), or falls apart (as arts did), or dies off (as xine did after it had been the default phonon backend for a while). At the same time there was need for a general purpose multimedia solution for KDE software, so Phonon came to be. Whether qtmultimedia should take that place for qt5 based kde software I do not know. API-wise I certainly wouldn't want to use it. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Wednesday, September 25, 2013 13:38:57 Daniel Nicoletti wrote: > 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. my experience with QtMultimedia can best be summed up by “holding my nose, i used it because i had to”. it’s really not a good framework. for simplistic things, ok... > 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? because it’s remarkably better than QtMultimedia, which itself was an exercise in NIH by certain people who worked on Qt for Nokia at the time. -- Aaron J. Seigo
Re: Fwd: looking for phonon gstreamer maintainer
thanks for the swift and excellent response! muchly appreciated ... On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: > d) at some point port to phonon5 would it at all make sense to see if we can resuscitate this backend by just going straight to (d)? does it make sense to port the existing code, or would a start from scratch make sense? given all the downsides to not having a *good* gstreamer 1.0 backend in your report, this seems like a pretty important item. particularly for those of us looking to bring software to mobile devices where having multiple media middleware is not an awesome solution. -- Aaron J. Seigo
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo wrote: > thanks for the swift and excellent response! muchly appreciated ... > > On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: >> d) at some point port to phonon5 > > would it at all make sense to see if we can resuscitate this backend by just > going straight to (d)? does it make sense to port the existing code, or would > a start from scratch make sense? Starting from scratch is certainly a viable option. Going straight to d would not solve the problem for Phonon4, or Qt4 for that matter as Phonon5 is supposed to be exclusively Qt5. However from a backend POV there is not going to be a whole lot difference between the two versions as Phonon5's key element is getting rid of pointless API dynamics and through that simplifying the frontend API (like not having a mediagraph where in theory one could order nodes in any order and something reasonable should come out at the end). The heavy lifting code of setting a source, building a pipeline and making it create output should be largely the same. I personally would go for a rewrite but at the same time I am also very confident that starting from the existing code base would yield success. Torrie Fischer already rewrote a lot of the pipeline building and control logic a while ago, so it is most certainly not as bad as it used to be. At the very least there is stuff that can be salvaged for a possible rewrite. > given all the downsides to not having a *good* gstreamer 1.0 backend in your > report, this seems like a pretty important item. particularly for those of us > looking to bring software to mobile devices where having multiple media > middleware is not an awesome solution. There definitely are solid reasons for having a GStreamer backend, otherwise it would have gotten the boot like all the other broken backends years ago. While I had not originally thought of mobile devices, it certainly has even greater importance there. Regardless of the device though it would be a shame to loose the backend, so I really hope someone who enjoys HD videos steps up and volunteers to make software to play them (better) :) HS
Re: Fwd: looking for phonon gstreamer maintainer
25.09.2013 15:25 пользователь "Aaron J. Seigo" написал: > > 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? > > * 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? > > * 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? * One more serious question: how well does this backend copes with (recent versions of) GStreamer 1.x?
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 2:54 PM, Vadim Zhukov wrote: > * One more serious question: how well does this backend copes with (recent > versions of) GStreamer 1.x? It doesn't seeing as there is an unfinished porting branch. HS
Re: Fwd: looking for phonon gstreamer maintainer
Only phonon-gstreamer support replaygain for mp3/ogg/flac files... So removing phonon-gstreamer will break applications like Amarok. I think phonon-vlc needs some more love before being Phonon default backend. regards, Le mercredi 25 septembre 2013 12:35:25 Harald Sitter a écrit : > In the unfortunate case that no one is willing enough we will have to > look at the possibility of moving the backend out of the support > scope, leaving Phonon VLC as the only actively supported backend on > all platforms. -- Cédric
Re: Fwd: looking for phonon gstreamer maintainer
Another question, gstreamer is not parallel linkable, and ktp-call-ui is currently using QtGstreamer (which also seems unmaintained for quite some time) and it's using gstreamer 0.10. So if phonon-gstreamer is ported to gstreamer then QtGstreamer also must be ported to 1.0 (Though phonon-gstreamer and QtGstreamer doesn't use each other but they could end up in same application which will cause some problem..). Would it be easier to make phonon-gstreamer to use QtGstreamer and hence also make someone to maintain QtGstreamer? On Wed, Sep 25, 2013 at 5:08 PM, Harald Sitter wrote: > On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo wrote: > > thanks for the swift and excellent response! muchly appreciated ... > > > > On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: > >> d) at some point port to phonon5 > > > > would it at all make sense to see if we can resuscitate this backend by > just > > going straight to (d)? does it make sense to port the existing code, or > would > > a start from scratch make sense? > > Starting from scratch is certainly a viable option. Going straight to > d would not solve the problem for Phonon4, or Qt4 for that matter as > Phonon5 is supposed to be exclusively Qt5. However from a backend POV > there is not going to be a whole lot difference between the two > versions as Phonon5's key element is getting rid of pointless API > dynamics and through that simplifying the frontend API (like not > having a mediagraph where in theory one could order nodes in any order > and something reasonable should come out at the end). The heavy > lifting code of setting a source, building a pipeline and making it > create output should be largely the same. > > I personally would go for a rewrite but at the same time I am also > very confident that starting from the existing code base would yield > success. Torrie Fischer already rewrote a lot of the pipeline building > and control logic a while ago, so it is most certainly not as bad as > it used to be. At the very least there is stuff that can be salvaged > for a possible rewrite. > > > given all the downsides to not having a *good* gstreamer 1.0 backend in > your > > report, this seems like a pretty important item. particularly for those > of us > > looking to bring software to mobile devices where having multiple media > > middleware is not an awesome solution. > > There definitely are solid reasons for having a GStreamer backend, > otherwise it would have gotten the boot like all the other broken > backends years ago. While I had not originally thought of mobile > devices, it certainly has even greater importance there. Regardless of > the device though it would be a shame to loose the backend, so I > really hope someone who enjoys HD videos steps up and volunteers to > make software to play them (better) :) > > HS >
Re: Fwd: looking for phonon gstreamer maintainer
On Mon, Sep 30, 2013 at 3:11 AM, Weng Xuetian wrote: > Would it be easier to make phonon-gstreamer to use QtGstreamer and hence > also make someone to maintain QtGstreamer? No. Maintaining two things is more work than maintaining one ;) On top of that there are no real synergies between the two softwares. Yes they both abstract GStreamer, however QtGStreamer really just abstracts the glib/c wiring and replaces it with Qt/cpp wiring whereas Phonon GStreamer entirely abstracts the API. So, Phonon GStreamer could utilize QtGstreamer but all we would get from that is (as a Phonon GStreamer developer) a more convenient API to work with. Other than that it doesn't bring anything to the table as Phonon GStreamer still needed to do what it does now, which is abstracting the API. ^ This is actually why we did not pick up QtGstreamer when it was first released, it would be abstraction stacking without gain. HS P.S. I am a fan of abstracting abstractions regardless :P
Re: Fwd: looking for phonon gstreamer maintainer
I looked at the QtGstreamer git recently and there is still work going on, but the focus seemed to be on splitting out QtGlib and the Qt5 port. It looks like that should be a release with those changes ready soon. I assume the gstreamer 1 port well be next, although I think some work in that area is already done. On Sep 30, 2013 10:17 AM, "Weng Xuetian" wrote: > > Another question, gstreamer is not parallel linkable, and ktp-call-ui is currently using QtGstreamer (which also seems unmaintained for quite some time) and it's using gstreamer 0.10. > > So if phonon-gstreamer is ported to gstreamer then QtGstreamer also must be ported to 1.0 (Though phonon-gstreamer and QtGstreamer doesn't use each other but they could end up in same application which will cause some problem..). > > Would it be easier to make phonon-gstreamer to use QtGstreamer and hence also make someone to maintain QtGstreamer? > > > On Wed, Sep 25, 2013 at 5:08 PM, Harald Sitter wrote: >> >> On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo wrote: >> > thanks for the swift and excellent response! muchly appreciated ... >> > >> > On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: >> >> d) at some point port to phonon5 >> > >> > would it at all make sense to see if we can resuscitate this backend by just >> > going straight to (d)? does it make sense to port the existing code, or would >> > a start from scratch make sense? >> >> Starting from scratch is certainly a viable option. Going straight to >> d would not solve the problem for Phonon4, or Qt4 for that matter as >> Phonon5 is supposed to be exclusively Qt5. However from a backend POV >> there is not going to be a whole lot difference between the two >> versions as Phonon5's key element is getting rid of pointless API >> dynamics and through that simplifying the frontend API (like not >> having a mediagraph where in theory one could order nodes in any order >> and something reasonable should come out at the end). The heavy >> lifting code of setting a source, building a pipeline and making it >> create output should be largely the same. >> >> I personally would go for a rewrite but at the same time I am also >> very confident that starting from the existing code base would yield >> success. Torrie Fischer already rewrote a lot of the pipeline building >> and control logic a while ago, so it is most certainly not as bad as >> it used to be. At the very least there is stuff that can be salvaged >> for a possible rewrite. >> >> > given all the downsides to not having a *good* gstreamer 1.0 backend in your >> > report, this seems like a pretty important item. particularly for those of us >> > looking to bring software to mobile devices where having multiple media >> > middleware is not an awesome solution. >> >> There definitely are solid reasons for having a GStreamer backend, >> otherwise it would have gotten the boot like all the other broken >> backends years ago. While I had not originally thought of mobile >> devices, it certainly has even greater importance there. Regardless of >> the device though it would be a shame to loose the backend, so I >> really hope someone who enjoys HD videos steps up and volunteers to >> make software to play them (better) :) >> >> HS > >
Re: Fwd: looking for phonon gstreamer maintainer
On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote: > -- Forwarded message -- > From: Harald Sitter > Date: Mon, Sep 23, 2013 at 4:55 PM > Subject: looking for phonon gstreamer maintainer > To: "For discussion of multimedia (sound/video) issues under KDE" > > > > Ahoy, > > 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. > > If anyone wishes to step up and move the backend forward now is the > time to do it. I'd like to note that this is not a one-man job though > and I am going to continue to be supporting developer. > > In the unfortunate case that no one is willing enough we will have to > look at the possibility of moving the backend out of the support > scope, leaving Phonon VLC as the only actively supported backend on > all platforms. > > As immediate result I will likely have to demote the backend's initial > preference for the upcoming 4.7.0 release below Phonon VLC's. Hi, in Fedora we have a big interest in keeping phonon-gstreamer alive, namely because we can't ship phonon-vlc due to legal issues (you know, US company, software patents and what not...) and our users would not probably be very happy if we had no phonon working backend in Fedora KDE. So far we are happy with gstreamer-0.10, but we realize that sooner or later we will have to start looking into supporting gstreamer-1.0. Even if we are able to keep phonon with gstreamer-0.10 alive by patching the hell out of it in downstream, at some point we will be forced to drop it, and then we would have nothing to switch to. So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 port. I'm not able to fully maintain yet another project (I already have more than enough :-)), but as said above, I can contribute to keep it alive and push it over the hill to gstreamer-1.0 (come on, how hard can it be? ;-)) Luckily for me, we have a GStreamer guy in the office, so I can get some help from him if necessary :) Cheers, Dan > > HS -- Daniel Vrátil KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Fwd: looking for phonon gstreamer maintainer
On 04 Oct, Daniel Vrátil wrote : > in Fedora we have a big interest in keeping phonon-gstreamer alive, namely > because we can't ship phonon-vlc due to legal issues (you know, US company, > software patents and what not...) and our users would not probably be very This is a bit untrue, tbh and at the limit of FUD. libVLC and libVLCcore are not more patent-encumbered than gstreamer-core. VLC, phonon-VLC and libVLC are based on modules loaded at runtime, like gstreamer, QT, DShow and other multimedia frameworks (a contrario from all-included players like mplayer) Shipping a version without problematic modules is very doable and has already been done. Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
Re: Fwd: looking for phonon gstreamer maintainer
On Fri, Oct 4, 2013 at 5:50 PM, Daniel Vrátil wrote: > On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote: >> -- Forwarded message -- >> From: Harald Sitter >> Date: Mon, Sep 23, 2013 at 4:55 PM >> Subject: looking for phonon gstreamer maintainer >> To: "For discussion of multimedia (sound/video) issues under KDE" >> >> >> >> Ahoy, >> >> 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. >> >> If anyone wishes to step up and move the backend forward now is the >> time to do it. I'd like to note that this is not a one-man job though >> and I am going to continue to be supporting developer. >> >> In the unfortunate case that no one is willing enough we will have to >> look at the possibility of moving the backend out of the support >> scope, leaving Phonon VLC as the only actively supported backend on >> all platforms. >> >> As immediate result I will likely have to demote the backend's initial >> preference for the upcoming 4.7.0 release below Phonon VLC's. > > Hi, > > in Fedora we have a big interest in keeping phonon-gstreamer alive, namely > because we can't ship phonon-vlc due to legal issues (you know, US company, > software patents and what not...) and our users would not probably be very > happy if we had no phonon working backend in Fedora KDE. > > So far we are happy with gstreamer-0.10, but we realize that sooner or later > we will have to start looking into supporting gstreamer-1.0. Even if we are > able to keep phonon with gstreamer-0.10 alive by patching the hell out of it > in downstream, at some point we will be forced to drop it, and then we would > have nothing to switch to. > > So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not > saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 > port. > I'm not able to fully maintain yet another project (I already have more than > enough :-)), but as said above, I can contribute to keep it alive and push it > over the hill to gstreamer-1.0 (come on, how hard can it be? ;-)) That's great! Some progress is certainly better than no progress :D If you could hop on #kde-multimedia we can coordinate development etc. > Luckily for me, we have a GStreamer guy in the office, so I can get some help > from him if necessary :) Sebastian Dröge from GStreamer also offered to help, so we definitely have some GStreamer backing. Yay. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Mon, Oct 7, 2013 at 2:36 PM, Jean-Baptiste Kempf wrote: > On 04 Oct, Daniel Vrátil wrote : >> in Fedora we have a big interest in keeping phonon-gstreamer alive, namely >> because we can't ship phonon-vlc due to legal issues (you know, US company, >> software patents and what not...) and our users would not probably be very > > This is a bit untrue, tbh and at the limit of FUD. > > libVLC and libVLCcore are not more patent-encumbered than > gstreamer-core. > > VLC, phonon-VLC and libVLC are based on modules loaded at runtime, like > gstreamer, QT, DShow and other multimedia frameworks (a contrario from > all-included players like mplayer) > Shipping a version without problematic modules is very doable and has > already been done. FWIW rdieter and j-b were able to clear up the confusion on IRC and apparently there now are plans to get vlc-without-patent-plugins into Fedora \o/ For anyone who is interested... libvlc* use $LIB/vlc/plugins/*/*.so to actually get demuxers/decoders/etc. a reasonable amount of containers and codecs (certainly some of the most important ones from a free software distribution's POV) are supported by vlc native implementations without usage of libav/ffmpeg/whatever. Any of the plugins can be dropped, which will naturally reduce feature or format support, but not impair libvlc's functionality at large. So a simple ldd check will tell you which plugins to exclude to get an ffmpeg-free package. ^ This is also how one can get smaller monolithic phonon-vlc binary packages BTW. Tomahawk for example strips a lot of the unused vlc plugins from their windows and osx binaries to reduce the size. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Tuesday 08 October 2013 10:52:26 Harald Sitter wrote: > > libVLC and libVLCcore are not more patent-encumbered than > > gstreamer-core. > > > FWIW rdieter and j-b were able to clear up the confusion on IRC and > apparently there now are plans to get vlc-without-patent-plugins into > Fedora \o/ Since already quite some time openSUSE has a VLC package in Factory and this package will be appearing in the upcoming 13.1 version. We solved it quite easily, but utilizing the videolan OBS system (maintained by Dominique/DimStar) to build the patented-plugins there. We have the full VLC tarball, but as that certain packages (e.g. ffmpeg, etc) are not available, VLC is only build with a small number of codecs, but as you indicated enough to build a working VLC backend for phonon. On the videolan buildservice, we are building the same package, but now with the full functionality. However we have set the package up that the patented codecs are put in a separate package, that can then easily be added by the user to get the full functionality. Regards Raymond
