https://bugs.kde.org/show_bug.cgi?id=526199
Winternewt <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Winternewt <[email protected]> --- Confirming this with a second client, plus a patch that fixes the root cause on the server side (kpipewire, not krdp/krdc). **Setup:** Debian 13 (trixie), Plasma 6.3.6, krdp 6.3.5, kpipewire 6.3.6, NVIDIA GTX 1080 Ti (no VAAPI encoding, so libx264 software encoding). Client: Windows 10, the built-in Remote Desktop Connection (mstsc.exe), not the Store "Remote Desktop" / Windows App. **Symptom with mstsc:** the session connects, the screen stays black (cursor visible), then Windows reports "Because of a protocol error, this session will be disconnected." The server log shows: [libx264] MB rate (32400000) > level limit (16711680) [libx264] profile Constrained Baseline, level 6.2, 4:2:0, 8-bit Turning on the client-side policy "Turn off hardware-accelerated decoding" makes the picture appear, so the GPU (DXVA) decoder rejects the level-6.2 stream. Software decoding of 4K, however, falls behind and causes 0.2–1 s of input lag that keeps building. While software decoding, mstsc also sets `SUSPEND_FRAME_ACKNOWLEDGEMENT` on almost every frame ack: about 6,700 in one session, against 5 after the fix. **Cause:** `LibX264Encoder::initialize()` sets `time_base = 1/1000` and no `framerate`, so x264 derives the level from an assumed 1000 fps. That's the "MB rate 32400000" line: 4K is 32400 macroblocks × 1000. It still does this in master. **Fix (attached, against master's `src/libx264encoder.cpp`):** declare a nominal frame rate and cap the level at 5.1, which covers 4K frame sizes: ```diff m_avCodecContext->time_base = AVRational{1, 1000}; + m_avCodecContext->framerate = AVRational{60, 1}; ... + av_dict_set(&options, "level", "5.1", 0); ``` **Result** (backported to 6.3.6 and tested): x264 now logs `level 5.1`. With hardware decoding re-enabled, mstsc decodes on the GPU, there's no protocol error and no lag, and suspended acks drop from thousands to 5. x264 still warns that 4K at 60 fps exceeds level 5.1's macroblock rate on paper. In practice frames arrive only on damage, and the decoder accepts it. 5.2 would match 4K60 by the spec, if preferred. The progressive codec fallback in 6.7+ avoids the black screen, but H.264 with GPU decoding is cheaper on bandwidth, so fixing the level seems worthwhile on its own. I tested the patch only against 6.3.6; the master version is the same two-line change but hasn't been compiled. I haven't tested it with FreeRDP/OpenH264, which is the original reporter's case. --- *Disclosure: I wrote this comment and the patch with an AI assistant (Claude). The setup, testing and validation on real hardware are mine.* -- You are receiving this mail because: You are watching all bug changes.
