Distros such as Fedora Kinoite report hardware openh264 capability using noopen264 package even tho it is not present. I am not fully across the reasoning for it being this way, however krdpserver will attempt a session with hardware encoding regardless and this results in a black screen on the client. This can be worked around by adding a complex set of ostree overrides and replaces, adding the rpmfusion repositories (https://pagure.io/fedora-kde/SIG/issue/522). However if we could override hardware encoding for software (knowing there is a performance hit), we could use the krdp feature without having to pull apart our ostree. There may be other use cases for overriding hardware encoding (such as mesa bugs https://github.com/stashapp/stash/issues/4701). STEPS TO REPRODUCE 1. Run krdpserver on standard kinoite 2. Connect via client get black screen OBSERVED RESULT Black screen EXPECTED RESULT Open264 video feed SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 (available in About System) KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Travier has stated adding openh264 to the base system remains problematic in kinoite, this would get this feature into the hands of Kinoite users sooner
You can try to force software encoding with following: KPIPEWIRE_FORCE_ENCODER=libx264_baseline krdpserver -u test -p test or KPIPEWIRE_FORCE_ENCODER=libx264 krdpserver -u test -p test Does either of these work for you? If so, maybe this flag could be used in Fedora Kinoite to force it, until if/when we can come up with additional GUI setting?
(In reply to Akseli Lahtinen from comment #1) > You can try to force software encoding with following: > > KPIPEWIRE_FORCE_ENCODER=libx264_baseline krdpserver -u test -p test > > or > > KPIPEWIRE_FORCE_ENCODER=libx264 krdpserver -u test -p test > > Does either of these work for you? If so, maybe this flag could be used in > Fedora Kinoite to force it, until if/when we can come up with additional GUI > setting? The problem is that libx264 is not in the main repository but on the RPMFusioion (https://github.com/rpmfusion/x264). Which means that just like with openh264, that still requires user actions.
OpenH264 is not a hardware encoder, it's a software one. We use VAAPI to detect whether hardware encoding is working or not. If that succeeds but doesn't actually work, then that's a distro bug that should be fixed by your distro. However, what I think is happening here is that it tries hardware encoding, fails because of missing drivers, then tries software encoding which also fails because currently we only support libx264 for that. There's a merge request in the works to add support for that, which will probably be released with Plasma 6.2. Once that is in, I think this issue will be fixed.
This is resolved between plasma 6.2 supporting openh264 and on the fedora side with the welcome app offering package layering as an option from Fedora 42 https://pagure.io/fedora-kde/SIG/issue/549