AlmaLinux: Issue with H.264 when client request color depth 32 bit (xorgxrdp) #3405
Comments
|
@hauihau - did you install xrdp using |
|
I've had a poke around in the source, and this looks currently like a memory allocation error of some sort. Are you able to provide the following?
Thanks. |
Both xrdp and xorgxrdp were installed with dnf from EPEL 9 repository, |
I'm not aware of any ini file, bit this is the content of the Default.rdp: I have two monitors connected to a USB-C/Thunderbolt docking station, both displays have 2560x1440. |
|
Thanks @hauihau - I'll try to reproduce this here using similar settings. |
|
I'm having a few problems with the debuffer on Alma 9, so I've not managed to reproduce this yet. A thought occurs to me however; what do you get for the following command? |
noopenh264-0.1.0~openh264_2.4.1-2.el9.x86_64 |
|
I have the same issue on RHEL 9.5 with latest updates. Was working before latest update. |
|
I think I can see what's going on here. With You should both have My (possibly incorrect) understanding is that there are some concerns over H264 patents which is why the I'll need to look into why this has happened with a fresh Alma install. The following command might fix things, but I'd only try it on a test system for the time being until I've looked in more detail. Please don't run this in production yet! |
|
I can see where I've made a vanilla installation of Alma 9.5 with EPEL using this procedure:-
Then:- $ sudo dnf install xrdp Last metadata expiration check: 1:55:56 ago on Sat Jan 25 14:36:39 2025. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: xrdp x86_64 1:0.10.2-7.el9 epel 593 k Installing dependencies: dbus-x11 x86_64 1:1.12.20-8.el9 appstream 24 k fuse3-libs x86_64 3.10.2-9.el9 appstream 90 k imlib2 x86_64 1.7.4-1.el9 epel 225 k noopenh264 x86_64 0.1.0~openh264_2.4.1-2.el9 epel 22 k tigervnc-license noarch 1.14.1-1.el9_5 appstream 17 k tigervnc-server-minimal x86_64 1.14.1-1.el9_5 appstream 1.2 M Installing weak dependencies: xrdp-selinux x86_64 1:0.10.2-7.el9 epel 13 k Transaction Summary ================================================================================ Install 8 Packages Total download size: 2.1 M Installed size: 7.4 M Is this ok [y/N]: There is no sign of the However, if at this point, I run a Now I can see the openh264 package:- and, more importantly:- $ sudo dnf install xrdp Last metadata expiration check: 0:01:19 ago on Sat Jan 25 16:56:06 2025. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: xrdp x86_64 1:0.10.2-7.el9 epel 593 k Installing dependencies: dbus-x11 x86_64 1:1.12.20-8.el9 appstream 24 k fuse3-libs x86_64 3.10.2-9.el9 appstream 90 k imlib2 x86_64 1.7.4-1.el9 epel 225 k openh264 x86_64 2.3.1-1.el9 epel-cisco-openh264 425 k tigervnc-license noarch 1.14.1-1.el9_5 appstream 17 k tigervnc-server-minimal x86_64 1.14.1-1.el9_5 appstream 1.2 M Installing weak dependencies: xrdp-selinux x86_64 1:0.10.2-7.el9 epel 13 k Transaction Summary ================================================================================ Install 8 Packages Total download size: 2.5 M Installed size: 8.5 M Is this ok [y/N]: Carrying on with the installation works perfectly. What is happening here, is that the If you are in the situation where xrdp has been installed along with
|
matt335672
changed the title
|
I doubt the issue is AlmaLinux specific because AlmaLinux doesn't have xrdp package. It comes from EPEL. Also openh264/noopenh264 comes from EPEL. However, I'll check it anyway |
|
My thinking at the moment is that it is Alma-specific Alma includes an epel-release package that doesn't contain On both of these scenarios I'm starting with a clean, fully updated Alma installation, without Scenario 1 - install
|
Rocky 9.5 - install
|
Ah, understood. That's definitely a Alma specific. |
|
Same issue with RHEL 9.5. I'll open a ticket with Redhat support. But why does xrdp work if color bit depth is 24, but not 36? What is xrdp doing that requires openh264 in this case? |
Actually, it is NOT working yet. Just xrdp does not try to use H.264 when bpp <= 24. Literally, you won't fail to use something you don't use. That is because xrdp does not use GFX when bpp <= 24.
When the following conditions are met, xrdp tries to encode screen by OpenH264.
When noopenh264 is installed instead of openh264, xrdp fails to use H.264. |
|
xrdp available from EPEL is compiled with As a workaround, there are some methods not to use H.264. The server-side approach and the client-side one.
|
|
@matt335672 Do you think it is possible to detect that noopenh264 is installed instead of openh264 in xrdp? If possible, I'm thinking of disabling H.264 on the xrdp side at runtime when xrdp is compiled with |
|
I had a think about this a day or two ago, before the reasons for the failure were clear. It's easy enough to detect noopenh264. Given the way the code is structured, it would be hard in that situation to fall back to x264, but relatively easy to fallback to GFX. Tomorrow, I'll look at a patch for discussion. |
|
I don't think fallback to x264 is required. Fallback to GFX-RFX is sufficient. EPEL doesn't have x264 package so xrdp is not built with x264 and fallback to x264 is not possible even if we implement such fallback on the RHEL-derivative systems. The AlmaLinux team just released the latest epel-release package containing the
It will be distributed to mirrors within a day. Then, |
|
Thanks @metalefty PR pushed for initial consideration. @thomaspmorgan - I can't comment on how this could happen with RHEL as we don't have access to it. Any other feedback you can add if you get anything useful from support would be useful - we might be missing something. |
|
I have never installed epel-release before, I have just a epel9.repo file which I copy over and modify it if we upgrade to a new major release. I have no idea why they have an extra repository just for openh264 instead of integrating it in the epel repository. I have seen that Fedora itself also has a seperate repository for openh264. I can confirm, that after switching from noopenh264 to openh264, 32 bit color depth is working. Just for my understanding: for color depth <32, H264 isn't used so there is no issue. Only for 32 bits H264 is used and fails, if noopenh264 is installed. Issue can be closed as it is working now for me. |
|
I don't think it is a very good way to enable EPEL but it's your decision. The old repo file may cause a problem like what happened on AlmaLinux. I think this is a better way but it's up to you.
This is due to the patent issue. Cisco covers patent royalties for the use of the binary form of the OpenH264 library. The OpenH264 library available in EPEL is provided by Cisco so end-users can use H.264 at no cost. I suspect there may be an agreement on redistribution between Fedora and Cisco that is what is causing the separate repositories. |
xrdp version
0.10.2
Detailed xrdp version, build options
Operating system & version
RedHat Enterprise Linix 9.4 / Almalinux 9.5
Installation method
dnf / apt / zypper / pkg / etc
Which backend do you use?
xorgxrdp 0.10.3
What desktop environment do you use?
Xfce
Environment xrdp running on
Physical and virtual systems
What's your client?
Windows 11 Microsoft Client
Area(s) with issue?
Graphic glitches, Other
Steps to reproduce
We have just updates to the lastest version of xrdp and xorgxrdp on our RedHat and Alma Linux systems.
When we connect to the systems with 32 bit color depth, we only see a blue screen and the systemd journal contains lot's of lines with
If we reduce the color depth to 24 or less, everything is working as expected.
There is also in the logs when conencting:
Color depth 32 bit:
Color depth <32 bit:
✔️ Expected Behavior
Seeing the Xfce desktop
❌ Actual Behavior
The window has just blue background, no Xfce desktop items visible
Anything else?
Please let me know if you need further details or logs.
The text was updated successfully, but these errors were encountered: