Another question, gstreamer is not parallel link= able, and ktp-call-ui is currently using QtGstreamer (which also seems unma= intained 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 eac= h other but they could end up in same application which will cause some pro= blem..).

Would it be easier to make phonon-gstreamer to use QtGstreamer an= d 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<= /a>> 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 b= y just
> going straight to (d)? does it make sense to port the existing code, o= r 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 i= n your
> report, this seems like a pretty important item. particularly for thos= e of us
> looking to bring software to mobile devices where having multiple medi= a
> 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

--001a11c30a849fb80404e78f831a--