Summary: | Future of KDE Phonon Backends and HW acceleration on Intel GPU | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthias Nagel <matthias.nagel> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gstreamer, leio, matthias.nagel, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Matthias Nagel
2024-07-09 18:16:08 UTC
GStreamer provides Qt6 support fine, and we could package it, but it has nothing to do with phonon backends, as that one is about Qt6 QML plugin, i.e. rendering video with gstreamer into a QML scene graph or something. For phonon, it'd have to be a phonon gstreamer backend that is functioning for Qt6. Honestly, I don't understand why they wouldn't have that support as primary, but I guess I'm biased. Then again, I wouldn't use phonon but rather gstreamer directly :) Anyhow, tl;dr: nothing for gstreamer@g.o to do here, as the equivalent of bug 810814 but for the qt6 variant won't help here in any way. Sorry, for the technical impreciseness. When I wrote Gstreamer has not been ported to Qt6, I actually meant that the Gstreamer-based Phonon backend has not been ported to Qt6. However, from a user's perspective this is rather a technicality, but the general issue still stands. We are heading towards the unfortunate situation that KDE users either loose HW-accelerated video decoding and rendering or are stuck with old dependencies which sooner or later will become outdated. You (@Mart Raudsepp) write that you would rather use Gstreamer directly than via Phonon. You won't hear any objections from my side. You might be right and one layer of abstraction on top of another layer of abstraction has become simply one layer too much to maintain. (If I am not mistaken, Gstreamer is also only an abstraction layer on top of other multimedia libraries such as FFMPEG.) However, that is nothing what users (or package maintainers) can change. The KDE project decided to invent Phonon as another abstraction layer and that is the situation we have to face. That is why I wrote that I don't have a single, good solution or clear way forward. We either need a new Phonon backend (maybe based on MPV), or get the Gstreamer-based Phonon backend ported to Qt6 or get VLC 3 (or 4) to support VA API with FFMPEG 6. Yes, it's a horrible mess. I appreciate you filing it and I agree that the situation is pretty poor. phonon-mpv isn't perfect but forcing people onto VLC when it's incompatible with modern ffpmeg is also asking for trouble. I don't know what to do yet. There's some progress upstream on a backport to VLC 3.x finally but I don't know if it's going to go anywhere. I'm not sure why we need another bug next to bug 864721? I posted this bug in order to consolidate the issue. Any of the other, related issues only looks at a single specific package, like the bug you mentioned. While it is problematic for its own sake that VLC does not support VA API for FfMPEG >4, this wouldn't be such a big problem if there were viable alternatives. Hence, my intention was to provide the bigger picture and also show that there are several solutions out of this unfortunate situation. I listed some at the end of my initial post. |