Bug 488858

Summary: Add option to force software H264 encoding even when a valid radeonsi device is present
Product: [Plasma] KRdp Reporter: Matt <m.mcnutt>
Component: generalAssignee: Unassigned bugs mailing-list <unassigned-bugs>
Status: RESOLVED FIXED    
Severity: wishlist CC: ahiemstra, akselmo, deadmeu, nate, xalt7x.service
Priority: NOR    
Version: 6.1.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Matt 2024-06-21 04:28:11 UTC 
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
Comment 1 Akseli Lahtinen 2024-06-24 07:08:37 UTC 
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?
Comment 2 Yevhen Popok 2024-06-25 07:38:26 UTC 
(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.
Comment 3 Arjen Hiemstra 2024-07-10 09:05:20 UTC 
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.
Comment 4 Matt 2024-10-02 07:35:45 UTC 
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