<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>