With latest builds of freerdp for F39 appear to have ffmpeg enabled. When RDP connections are attempted with gnome-connections, remmina or xfreerdp, the screen appears blank. The error messages in the log contain something to the effect of: - No VA display found for device /dev/dri/renderD128 - Could not initialize hardware decoder, failing back to to software: Invalid argument Forcing a downgrade to F38 packages makes all of these RDP clients work again. Reproducible: Always Steps to Reproduce: 1. Install F39 as Hyper-V VM. 2. Open gnome-connections and attempt to connect to another machine via RDP. 3. Blank screen. Actual Results: Blank screen. Expected Results: Should work, like it did in F38.
This is obviously because of the https://src.fedoraproject.org/rpms/freerdp/c/2424f54884289948c8b2cec4e359573b4115d83d change. Can you please file a report on https://github.com/FreeRDP/FreeRDP/issues and add here a comment with the link to that issue?
Got a reply upstream that with xfreerdp, one can use /gfx or /gfx:rfx options to get stuff on the display. I tested this and indeed, the blank screen and hung client situation is done. Of course, this is not optimal, because it requires that users do things by hand, so I asked whether this fallback can be done automatically. Also, I am not really sure that such options can be easily passed into the library that gnome-connections, remmina etc. use.
From https://github.com/FreeRDP/FreeRDP/issues/9447#issuecomment-1753371883: > I've looked through the parts here on the weekend and couldn't spot an issue. Whenever something fails, FreeRDP prints out an error message. You didn't get one here, so the issue is in your FFMPEG build. The message Could not initialize hardware decoder, falling back to software: Invalid argument comes from FreeRDP though. The Invalid argument refers to why the hw decoder could not be created (the provided path was invalid). Not an issue, since FreeRDP falls back to software encoding. From then it is the same, as if you built with WITH_VAAPI=OFF, which works just fine here. > The difference between Archlinux' build and Fedoras is that Arch uses x264 and Fedora patched their FFMPEG to dlopen openH264. Considering the amount of custom patches, that Fedora applies here (including the dlopen openH264), this looks to be an issue in Fedora. @bsmojver Please open an issue in Fedora against their FFMPEG pkg regarding this. > Some addendum: It doesn't make sense, that Fedora builds FreeRDP with WITH_VAAPI=ON btw, because Fedora does not build mesa with AVC decode support (anymore) and also afaik patched that functionality out of their Intel media driver too. So, it looks like FreeRDP may need a change in how it is built in Fedora. And this bug should likely be moved to ffmpeg after that, so that it can be looked at there as well.
Does -WITH_VAAPI=OFF fix your issue? Or some other changes are needed?
I haven't tried. Someone in the upstream report mentioned that. I can do a local build and see what happens.
I had another look at all this and libopenh264 definitely gets dlopen()-ed by remmina. So, it seems that indeed ffmpeg isn't using that quite correctly or something like that. I'll move the bug to ffmpeg first, just to see whether anyone there knows what could be causing the problem.
I commented in upstream ticket. I'm not convinced it's a bug in ffmpeg.
(In reply to Ondrej Holy from comment #4) > Does -WITH_VAAPI=OFF fix your issue? Or some other changes are needed? It'd be better if lack of VA-API support for H264 in Fedora was handled gracefully, because you can install VA-API drivers for Intel and AMD from RPM Fusion that support this.
We don't change anything about the ffmpeg-openh264 codec support itself other than switch to dlopen. However, the FFmpeg OpenH264 code is fairly barebones, and it's entirely possible that FreeRDP expects something that's not there (for example, SEI header extraction isn't supported in ffmpeg-openh264). That said, since FreeRDP has direct support for OpenH264, it would be better for it to enable this directly. Does enabling FreeRDP's OpenH264 support make it work?
(In reply to Neal Gompa from comment #9) > That said, since FreeRDP has direct support for OpenH264, it would be better > for it to enable this directly. Does enabling FreeRDP's OpenH264 support > make it work? I'm told freerdp does not dlopen OpenH264. Since OpenH264 cannot be a build dependency, we cannot enable that unless it's changed. Maybe Fedora should use noopenh264 to dodge this problem (a dummy openh264 installation just for building against), which is what Endless and GNOME both do.
(In reply to Michael Catanzaro from comment #10) > (In reply to Neal Gompa from comment #9) > > That said, since FreeRDP has direct support for OpenH264, it would be better > > for it to enable this directly. Does enabling FreeRDP's OpenH264 support > > make it work? > > I'm told freerdp does not dlopen OpenH264. Since OpenH264 cannot be a build > dependency, we cannot enable that unless it's changed. > > Maybe Fedora should use noopenh264 to dodge this problem (a dummy openh264 > installation just for building against), which is what Endless and GNOME > both do. Is noopenh264 up to date? Last I checked it was a bit behind: https://github.com/endlessm/noopenh264 seems to be at 2.3.0 instead of our current 2.3.1.
That is a problem indeed. See https://github.com/endlessm/noopenh264/pull/13
I've rebuilt this with ffmpeg and vaapi disabled and it fixes all of the issues I've been having with RDP on F39. diff --git a/freerdp.spec b/freerdp.spec index 388eb7b..b2d7d5f 100644 --- a/freerdp.spec +++ b/freerdp.spec @@ -162,8 +162,8 @@ find . -name "*.c" -exec chmod 664 {} \; -DWITH_CHANNELS=ON -DBUILTIN_CHANNELS=OFF \ -DWITH_CLIENT=ON \ -DWITH_DIRECTFB=OFF \ - -DWITH_DSP_FFMPEG=%{?_with_ffmpeg:ON}%{?!_with_ffmpeg:OFF} \ - -DWITH_FFMPEG=%{?_with_ffmpeg:ON}%{?!_with_ffmpeg:OFF} \ + -DWITH_DSP_FFMPEG=OFF \ + -DWITH_FFMPEG=OFF \ -DWITH_GSM=ON \ -DWITH_GSSAPI=%{?_with_gss:ON}%{?!_with_gss:OFF} \ -DWITH_ICU=ON \ @@ -194,7 +194,7 @@ find . -name "*.c" -exec chmod 664 {} \; -DWITH_ZLIB=ON \ %ifarch x86_64 -DWITH_SSE2=ON \ - -DWITH_VAAPI=%{?_with_ffmpeg:ON}%{?!_with_ffmpeg:OFF} \ + -DWITH_VAAPI=OFF \ %else -DWITH_SSE2=OFF \ %endif Making this changes fixes gnome-connections, gnome-remote-desktop, remmina-plugins-rdp and directly using freerdp.
Yup, it is expected that disabling all those options fixes the issue as it effectively reverts the https://src.fedoraproject.org/rpms/freerdp/c/2424f54884289948c8b2cec4e359573b4115d83d change. I did some tests. Disabling just the -WITH_VAAPI=OFF option doesn't fix the problem, just the errors disappear from the log. With `-DWITH_OPENH264=ON` it works fine, however, the noopenh264 package is not available. The freerdp upstream thinks the problem is in the downstream ffmpeg patches, but Fedora maintainers obviously think the opposite. So I will have to probably disable the ffmpeg support altogether for now as I don't have the capacity to debug this further. Or any other ideas?
It is not possible to keep just the DSP part enabled (i.e. "-DWITH_DSP_FFMPEG=ON -DWITH_FFMPEG=OFF") though this is maybe just a bug in "CMakeLists.txt". So I am going to revert the problematic change altogether for now.
FEDORA-2023-b2ea3656bb has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b2ea3656bb
FEDORA-2023-b2ea3656bb has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b2ea3656bb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b2ea3656bb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b2ea3656bb has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.