what to do with phonon & why aren't you using it?

[Kevin Kofler]

[Resending per e-mail. I keep forgetting about the issue and sending through 
Gmane NNTP, and then the mail sits stuck in moderation (or mail server 
"quarantine") for days. So do not be surprised when the original copy ends 
up making it through days, weeks, or even months later, when somebody 
happens to look at the moderation/quarantine queue.]

Harald Sitter wrote:
> A bit of background perhaps: waaaay back when phonon was conceived as
> multimedia abstraction library to serve as multimedia pillar. While it
> is certainly abstract and a library I'm not so sure about the pillar
> aspect ;) In fact, phonon is barely even an abstraction since I only
> maintain the vlc backend and nobody else maintains any other backend.

Well, that might be one (though not the only) answer to your first 
question ("Why don't you use phonon?"). The preferred backend in 
distributions has been GStreamer for years. (At some point, it was even the 
one preferred by upstream.) It is also what QtMultimedia uses by default. 
Why was VLC chosen as the one maintained backend for Phonon?

These days, the Phonon GStreamer backend can have obvious defects 
(visible in less than 5 minutes of testing, e.g., Dragon Player crashing on 
exit), and nobody is here to care. This in turn will lead developers to stop 
using the "buggy" Phonon.

> So, one has to wonder if it'd not make more sense to put the bit of
> energy that flows into phonon to instead go into qtvlc and not have to
> deal with the abstraction element at all. Indeed all these
> abstractions seem a bit silly because the multimedia libraries
> gstreamer and vlc are already abstractions... it's nesting dolls all
> the way down.

Ah, the famous "KDE Abstracted My Abstraction Layer" quote (which I see 
you even used as a presentation title in 2011). ;-)

This is a bit of a mess indeed. One issue is of course that some 
people prefer GStreamer and some VLC (and then there may in principle be: 
native Windows or MacOS backends, a backend using FFmpeg directly, etc.), so 
then you end up with another layer to pick one of those. Kinda an instance 
of:
https://xkcd.com/927/

The whole history of multimedia on Qt is a mess. Phonon was started 
when something like QtMultimedia simply did not exist. That had made it 
so interesting to the Qt project that they started to ship Phonon with 
Qt. Unfortunately, that cooperation never worked as well as intended (I 
remember subtle incompatibilities between "Qt Phonon" and "KDE Phonon", 
different default backends or even different backends altogether, issues 
initially getting the GStreamer backend from "Qt Phonon" to fully work with 
"KDE Phonon", and bootstrapping / build order issues) and abruptly ended 
when Qt decided to reinvent the wheel with QtMultimedia (first as a part 
of QtMobility, then standalone).

As a result, we now have two competing Qt multimedia frameworks that 
both suffer or suffered from a lack of maintainers. QtMultimedia was in 
a horrible state a few months ago (so much that I ended up suggesting on 
the Qt developer mailing list to just use Phonon, which, I was later told, 
made some powerful people at Qt really hate me ;-) ). It seems to be better 
now. But now we have Phonon falling into pieces, with only one backend 
being maintained at all.

I wish Qt and KDE could work together on *one* multimedia framework, with 
at least a working GStreamer backend. Though I am worried about the 
porting effort, since it would mean at least one of the two APIs will go 
away, maybe even both (in favor of a completely new one). But if you are 
going to revisit the Phonon API anyway, it may be worth considering to work 
with QtMultimedia instead.

I would rather have one working multimedia framework for Qt than two 
half-unmaintained ones.

        Kevin Kofler