Fwd: looking for phonon gstreamer maintainer

[Todd]

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" <wengxt at gmail.com> 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 <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/20130930/ac880dc1/attachment.htm>