Fwd: looking for phonon gstreamer maintainer

[Weng Xuetian]

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 <sitter at kde.org> wrote:

> On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo <aseigo at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130929/5738836f/attachment.htm>