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 <sit...@kde.org> wrote: > On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo <ase...@kde.org> 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 >
