[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Fwd: looking for phonon gstreamer maintainer
From: Weng Xuetian <wengxt () gmail ! com>
Date: 2013-09-30 1:11:21
Message-ID: CAKiDycHOgQRRsBdN3CCjmj_Sb0Tt=6e4c2B1zXDk1UWK5JtYPQ () mail ! gmail ! com
[Download RAW message or body]
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@kde.org> wrote:
> On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo <aseigo@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
>
[Attachment #3 (text/html)]
<div dir="ltr"><div><div>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.<br><br></div> 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..).<br> <br></div>Would it be easier \
to make phonon-gstreamer to use QtGstreamer and hence also make someone to maintain \
QtGstreamer?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On \
Wed, Sep 25, 2013 at 5:08 PM, Harald Sitter <span dir="ltr"><<a \
href="mailto:sitter@kde.org" target="_blank">sitter@kde.org</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. \
Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>
> thanks for the swift and excellent response! muchly appreciated ...<br>
><br>
> On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote:<br>
>> d) at some point port to phonon5<br>
><br>
> would it at all make sense to see if we can resuscitate this backend by just<br>
> going straight to (d)? does it make sense to port the existing code, or \
would<br> > a start from scratch make sense?<br>
<br>
</div>Starting from scratch is certainly a viable option. Going straight to<br>
d would not solve the problem for Phonon4, or Qt4 for that matter as<br>
Phonon5 is supposed to be exclusively Qt5. However from a backend POV<br>
there is not going to be a whole lot difference between the two<br>
versions as Phonon5's key element is getting rid of pointless API<br>
dynamics and through that simplifying the frontend API (like not<br>
having a mediagraph where in theory one could order nodes in any order<br>
and something reasonable should come out at the end). The heavy<br>
lifting code of setting a source, building a pipeline and making it<br>
create output should be largely the same.<br>
<br>
I personally would go for a rewrite but at the same time I am also<br>
very confident that starting from the existing code base would yield<br>
success. Torrie Fischer already rewrote a lot of the pipeline building<br>
and control logic a while ago, so it is most certainly not as bad as<br>
it used to be. At the very least there is stuff that can be salvaged<br>
for a possible rewrite.<br>
<div class="im"><br>
> given all the downsides to not having a *good* gstreamer 1.0 backend in your<br>
> report, this seems like a pretty important item. particularly for those of \
us<br> > looking to bring software to mobile devices where having multiple \
media<br> > middleware is not an awesome solution.<br>
<br>
</div>There definitely are solid reasons for having a GStreamer backend,<br>
otherwise it would have gotten the boot like all the other broken<br>
backends years ago. While I had not originally thought of mobile<br>
devices, it certainly has even greater importance there. Regardless of<br>
the device though it would be a shame to loose the backend, so I<br>
really hope someone who enjoys HD videos steps up and volunteers to<br>
make software to play them (better) :)<br>
<span class="HOEnZb"><font color="#888888"><br>
HS<br>
</font></span></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic