[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