https://bugs.kde.org/show_bug.cgi?id=526199
Bug ID: 526199
Summary: KRDP software H.264 encoding uses level 6.2, causing
black screen with FreeRDP/OpenH264; FFmpeg native
H.264 decoder works
Classification: Applications
Product: krdc
Version First unspecified
Reported In:
Platform: KDE Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: RDP
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
The below was generated by ChatGPT Astra after it helped me work around the
black screen issue by compiling freerdp with ffmpeg on and openh264 off. The
report is filed here instead of under FreeRDP because Astra seems to think this
is the relevant side of the boundary to report the level 6.2 issue on, but very
possibly this should just go to freerdp directly. I'm technical but this is
pretty deep in the weeds for me and I am mostly just summarizing what I
understood of what Astra output, so if the above wasn't very understandable
then please read on and see if you need any additional information after that.
The report includes relevant log snippets that are relevant to how the
workaround was found as well as some information about my system (both
computers).
I'm not sure what to put for version. Running `krdpserver --version` gives
`krdp-server 6.7.5`
## Summary
When connecting from a Fedora 44 client to a Fedora 44 KDE Plasma system
running KRDP, the RDP connection succeeds and remote input works, but the
client displays a black screen.
The KRDP server falls back to software H.264 encoding using libx264 because
hardware encoding is unavailable. The resulting stream is reported by libx264
as H.264 Constrained Baseline, level 6.2.
Fedora's packaged FreeRDP client, which uses OpenH264 for H.264 decoding, fails
while decoding the first video data. OpenH264 reports a failure parsing an SPS
with `level_idx (62)`. Rebuilding FreeRDP to use libavcodec together with
FFmpeg's native H.264 decoder instead of OpenH264 makes the same KRDP session
display correctly.
This appears to be an interoperability issue between the H.264 stream produced
by KRDP's software-encoding path and OpenH264. I am reporting it against KRDP
because KRDP is producing the level-6.2 stream and FreeRDP is listed as a
supported client, but I am not certain whether the appropriate fix belongs in
KRDP/kpipewire, OpenH264, FreeRDP, or Fedora's packaging.
## Environment
**Server**
* Fedora 44
* KDE Plasma / KRDP
* `krdp-6.6.5-1.fc44.x86_64`
* `x264-libs-0.165-5.20250608gitb35605ac.fc44.x86_64`
* Display resolution: 2560x1440
* Tested at both 144 Hz and 59.95 Hz
* Hardware encoding is unavailable, so KRDP falls back to libx264 software
encoding
* System contains AMD integrated graphics and an NVIDIA discrete GPU
**Client**
* Fedora 44
* FreeRDP 3.31.1 initially; also reproduced with FreeRDP 3.32.0
* `openh264-2.6.0-3.fc44.x86_64`
The Fedora FreeRDP build reported:
```
WITH_GFX_H264=ON
WITH_OPENH264=TRUE
WITH_OPENH264_LOADING=OFF
WITH_FFMPEG=OFF
```
## Steps to reproduce
1. Enable KDE Remote Desktop/KRDP on the Fedora 44 server.
2. Connect from another Fedora 44 machine using:
```
xfreerdp /v:<server> /u:<user> /dynamic-resolution
```
3. Authenticate normally.
## Actual behavior
Authentication succeeds and the RDP session remains active.
Mouse and keyboard input sent through RDP reaches the server correctly and can
be observed on the physical server display, but the client's display remains
black.
The KRDP server reports that hardware encoding is unavailable and initializes
libx264:
```
Hardware encoding is not supported on this device.
[libx264 @ ...] profile Constrained Baseline, level 6.2, 4:2:0, 8-bit
```
The server continues encoding frames. For example, at the end of one
approximately 12-second connection:
```
[libx264 @ ...] frame I:5 Avg QP:13.60 size:270165
[libx264 @ ...] frame P:415 Avg QP:15.48 size:724
[libx264 @ ...] kb/s:31453.54
```
This suggests that screen capture and software encoding continue while the
client displays black.
On the stock Fedora FreeRDP/OpenH264 client, the first graphics update fails in
the H.264 decoder. Typical messages are:
```
[openh264_decompress]: DecodeFrame2 state: 0x0004 iBufferStatus: 0
[log_decompress]: H264 decompress failed with -2002
[gdi_SurfaceCommand_AVC420]: avc420_decompress failure: -2002, ignoring update.
```
Subsequent updates produce errors such as:
```
Rectangle 0 {0x0-2560x1440} outside of bounding frame 0x0
[gdi_SurfaceCommand_AVC420]: avc420_decompress failure: -1015, ignoring update.
```
These later errors appear to be secondary to the initial H.264 decode failure,
since no decoded frame dimensions have been established.
The problem occurs with both FreeRDP 3.31.1 and 3.32.0.
## Additional diagnostic test: FreeRDP using libavcodec
To determine whether the failure was specific to FreeRDP's direct OpenH264
backend, I built FreeRDP 3.32.0 locally with:
```
-DWITH_FFMPEG=ON
-DWITH_OPENH264=OFF
```
Initially this was linked against Fedora's `ffmpeg-free`. That did **not** fix
the problem because Fedora's ffmpeg-free installation itself provided only the
`libopenh264` H.264 decoder.
This test produced a more specific decoder message:
```
[libopenh264 @ ...] [OpenH264] ... Warning:ParseSps(): level_idx (62).
[libopenh264 @ ...] DecodeFrame failed
[ERROR][com.freerdp.codec] - [libavcodec_decompress]: Failed to decode video
frame
[WARN][com.freerdp.codec] - [log_decompress]: H264 decompress failed with -1
[WARN][com.freerdp.gdi] - [gdi_SurfaceCommand_AVC420]: avc420_decompress
failure: -1, ignoring update.
```
The `level_idx (62)` message corresponds with the server's libx264 output
reporting H.264 level 6.2.
## Working configuration
I then replaced Fedora's `ffmpeg-free` with the full FFmpeg package from RPM
Fusion and installed its development libraries. This provides FFmpeg's native
H.264 decoder.
I rebuilt the same FreeRDP 3.32.0 source with:
```
-DWITH_FFMPEG=ON
-DWITH_OPENH264=OFF
```
and connected using that locally installed `xfreerdp`.
With FreeRDP using libavcodec backed by FFmpeg's native H.264 decoder, the KRDP
session displays correctly. There is no black screen.
Therefore, the same server and RDP session behave as follows:
```
KRDP -> libx264 -> H.264 level 6.2 -> FreeRDP/OpenH264
|
+-> H.264 decode failure / black screen
KRDP -> libx264 -> H.264 level 6.2 -> FreeRDP/libavcodec/native FFmpeg H.264
|
+-> working display
```
## Other tests
### Dynamic resolution
The problem is not specific to dynamic resolution. I also tested:
```
xfreerdp /v:<server> /u:<user> \
/size:2560x1440 \
/gfx:AVC420:on,AVC444:off,AV1:off
```
The initial OpenH264 decode failure was unchanged.
### Display refresh rate
The server display was originally configured for 2560x1440 at 144 Hz. I reduced
it to 59.95 Hz and restarted/retested KRDP.
KRDP still initialized libx264 as:
```
profile Constrained Baseline, level 6.2, 4:2:0, 8-bit
```
and the OpenH264 client still failed in the same manner.
Therefore the physical display refresh rate does not appear to explain why
level 6.2 is selected.
### Disabling H.264
I also attempted to disable AVC420/AVC444 in FreeRDP. The connection then
terminated during capabilities exchange rather than providing a non-H.264
display path. This appears consistent with KRDP relying on the RDP Graphics
Pipeline/H.264 path for video.
## Expected behavior
A supported FreeRDP client should be able to display the KRDP session when KRDP
falls back to software H.264 encoding.
Alternatively, if OpenH264 cannot decode the stream produced by the software
encoder, KRDP's software encoding configuration should ideally produce an H.264
stream/profile/level compatible with supported FreeRDP configurations.
## Suspected cause
The evidence appears to isolate the problem to H.264 decoder compatibility:
1. KRDP/libx264 reports that it is producing Constrained Baseline H.264 level
6.2.
2. OpenH264 explicitly reports `ParseSps(): level_idx (62)` and fails to
decode.
3. The stock FreeRDP/OpenH264 path consequently displays a black screen.
4. Changing FreeRDP versions from 3.31.1 to 3.32.0 does not change the failure.
5. Changing resolution negotiation and the server's physical refresh rate does
not change the failure.
6. Replacing OpenH264 with FFmpeg's native H.264 decoder, while retaining the
same KRDP server and FreeRDP version, makes the display work.
I do not know whether KRDP's selection of level 6.2 is itself incorrect. Level
6.2 is a defined H.264 level, and the fact that FFmpeg's native decoder
successfully decodes the stream suggests that the bitstream is not simply
invalid. The issue may instead be that KRDP's software-encoding configuration
produces a stream outside the capabilities accepted by OpenH264, despite
FreeRDP/OpenH264 being a relevant client configuration on Fedora.
It may therefore be appropriate either to constrain KRDP's software H.264
encoder to a level supported by OpenH264, or to address the incompatibility in
FreeRDP/OpenH264/Fedora if level 6.2 is expected to be supported.
--
You are receiving this mail because:
You are watching all bug changes.
