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

[Neal Gompa]

On Fri, Mar 24, 2023 at 2:16 PM Kevin Kofler <kevin.kofler at chello.at> wrote:
>
> 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.

With the transition to Qt 6, why not consider just using QtMultimedia itself?

The remaining gaps seem to be around UX stuff, which could be a KDE
Framework library that wraps QtMultimedia for KDE applications.

Applications already need to change for the Qt6/KF6 transition, it'd
be a good time to make that move now.



--
真実はいつも一つ！/ Always, there's only one truth!