Re: what to do with phonon & why aren't you using it?
[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: wy 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
Re: what to do with phonon & why aren't you using it?
Hi, like Android for which the traditional linux-based multimedia platforms like gstreamer or vlc don't work, or are very hard to get working properly. GStreamer seems the most comprehensive QML-capable framework on Android, too. At least I recall Eike having to use GStreamer for Kirogi (drone control app) as it was the only one supporting all the necessary remote streaming (RTP or whatever, I forgot) stuff on Android properly. Cheers Kai Uwe
Re: what to do with phonon & why aren't you using it?
On 14/03/2023 13:18, Neal Gompa wrote: On Tue, Mar 14, 2023 at 8:13 AM Nicolas Fella wrote: Am 14.03.23 um 13:04 schrieb Harald Sitter: Hola! Why don't you use phonon? What would it make it useful? What do you reckon we should do with it? A bit of background perhaps: wy 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. 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. With all that in mind I was prototyping a revisit of the API many years ago. Away from complicated mediagraph pipeline building abstraction to simple player abstraction (you have a player, you give it a url, it plays the url, that's it), as indeed that seems to be what most remaining users want to do these days - hassle free playback. Perhaps that is a path to take? But then the question remains, do we need the abstraction at all? Any and all thoughts welcome. HS Hi, I don't really have any first-hand experience of (not) using Phonon to give. But from my perspective the obvious question is: How does all of this compare to QtMultimedia? It's also an abstraction that kind of isn't any more, where things seem to converge on using the FFMPEG implementation for all platforms. QtMultimedia still supports other backends too, they provide the big benefit of more comprehensive hardware acceleration on each platform. But that said, if you're scrapping most of Phonon, why not just reuse QtMultimedia? +1 for aligning on a truly platform-agnostic multimedia framework. A lot of the newer (Kirigami-based) apps also target platforms like Android for which the traditional linux-based multimedia platforms like gstreamer or vlc don't work, or are very hard to get working properly. I'm pretty sure QtMultimedia will fill that gap for most use cases. Hopefully the ffmpeg backend solves some of the annoying cross-platform differences of the current implementation. Having said that, I do see a few opportunities to cover features which are not currently part of any of the existing multimedia platforms, including QtMultimedia. These are features like: - player controls (e.g. MPRIS2 and Android notification area player controls) - inhibit suspend and/or session lock - taskbar playback progress (D-Bus com.canonical.Unity.LauncherEntry) These features are must-haves for modern media applications, but are not very trivial to implement. I see several apps that have implemented these at least partially and are using code copied from elsewhere (e.g. Elisa, Kasts) and a few apps that don't have this implemented yet but would really benefit from it (e.g. PlasmaTube, AudioTube). It would be more efficient to share that code somehow rather than having nearly identical copies across several apps. Cheers, Bart
Re: what to do with phonon & why aren't you using it?
On Tue, Mar 14, 2023 at 8:13 AM Nicolas Fella wrote: > > Am 14.03.23 um 13:04 schrieb Harald Sitter: > > Hola! > > > > Why don't you use phonon? > > > > What would it make it useful? > > > > What do you reckon we should do with it? > > > > A bit of background perhaps: wy 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. > > 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. > > With all that in mind I was prototyping a revisit of the API many > > years ago. Away from complicated mediagraph pipeline building > > abstraction to simple player abstraction (you have a player, you give > > it a url, it plays the url, that's it), as indeed that seems to be > > what most remaining users want to do these days - hassle free > > playback. Perhaps that is a path to take? But then the question > > remains, do we need the abstraction at all? > > > > Any and all thoughts welcome. > > > > HS > > Hi, > > I don't really have any first-hand experience of (not) using Phonon to > give. But from my perspective the obvious question is: > > How does all of this compare to QtMultimedia? It's also an abstraction > that kind of isn't any more, where things seem to converge on using the > FFMPEG implementation for all platforms. > QtMultimedia still supports other backends too, they provide the big benefit of more comprehensive hardware acceleration on each platform. But that said, if you're scrapping most of Phonon, why not just reuse QtMultimedia? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: what to do with phonon & why aren't you using it?
Am 14.03.23 um 13:04 schrieb Harald Sitter: Hola! Why don't you use phonon? What would it make it useful? What do you reckon we should do with it? A bit of background perhaps: wy 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. 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. With all that in mind I was prototyping a revisit of the API many years ago. Away from complicated mediagraph pipeline building abstraction to simple player abstraction (you have a player, you give it a url, it plays the url, that's it), as indeed that seems to be what most remaining users want to do these days - hassle free playback. Perhaps that is a path to take? But then the question remains, do we need the abstraction at all? Any and all thoughts welcome. HS Hi, I don't really have any first-hand experience of (not) using Phonon to give. But from my perspective the obvious question is: How does all of this compare to QtMultimedia? It's also an abstraction that kind of isn't any more, where things seem to converge on using the FFMPEG implementation for all platforms. Cheers Nico
what to do with phonon & why aren't you using it?
Hola! Why don't you use phonon? What would it make it useful? What do you reckon we should do with it? A bit of background perhaps: wy 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. 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. With all that in mind I was prototyping a revisit of the API many years ago. Away from complicated mediagraph pipeline building abstraction to simple player abstraction (you have a player, you give it a url, it plays the url, that's it), as indeed that seems to be what most remaining users want to do these days - hassle free playback. Perhaps that is a path to take? But then the question remains, do we need the abstraction at all? Any and all thoughts welcome. HS
