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

Bart De Vries bart at mogwai.be
Tue Mar 14 13:54:58 GMT 2023


On 14/03/2023 13:18, Neal Gompa wrote:
> On Tue, Mar 14, 2023 at 8:13 AM Nicolas Fella <nicolas.fella at gmx.de> 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: 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.
>>> 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


More information about the kde-core-devel mailing list