Baike.dev
Log in
Back to tool/Back to issues
#13106·FreeRDP

MS-RDPECAM issue with xfreerdp3 (version 3.30.0 (6b107f0aa))

Author: noxxvilleCreated Jul 26, 2026Updated Sep 14, 2026
Labelswaiting-feedbackstale

Describe the bug

When using MS-RDPECAM (/dvc:rdpecam) to redirect a local webcam into a Windows 11 session, the video image is heavily pixelated and choppy as soon as there is any motion in front of the camera — clearing up briefly on keyframes, then degrading again. This happens even though the camera's own H.264 output is confirmed clean, screen-content H.264/RFX playback over the same RDP session is confirmed clean, and there are no USB disconnects at the kernel level.

Packet capture / debug logging of the rdpecam-v4l and drdynvc channels shows that the underlying per-device DVC sub-channels (named usb-<pci-path>-<port-path>) are being closed and re-opened roughly every 5 seconds throughout the entire session, each time re-allocating V4L2 buffers and re-issuing cam_v4l_stream_start. This forces a full stream/keyframe restart every ~5 seconds, which is the most likely cause of the visible pixelation.

To Reproduce

  1. Connect to a Windows 11 (24H2) RDP host with /dvc:rdpecam and a webcam that supports native H.264 capture (UVC 1.5 / H.264 passthrough).

  2. Open the Windows "Camera" app (or a Teams call using the camera).

  3. Observe the video: sharp while the camera is static, pixelated/blocky as soon as there's motion, clearing again after a moment.

  4. Run with /log-filters:com.freerdp.channels.rdpecam-v4l.client:TRACE,com.freerdp.channels.drdynvc.client:DEBUG and observe repeated cycles of:

    • drdynvc_process_close_request / dvcman_channel_close for the usb-<bus>-<port> channels
    • immediately followed by drdynvc_process_create_request / dvcman_open_channel for the same channel name
    • cam_v4l_get_media_type_descriptions re-enumeration
    • cam_v4l_stream_alloc_buffers (re-mapping 4 buffers)
    • cam_v4l_stream_start (Camera format: H264, ...)

    This cycle repeats approximately every 5 seconds for the duration of the session.

Expected behavior

The camera stream should be established once and remain stable for the duration of the session (no periodic channel teardown/rebuild), resulting in a smooth, sharp video image without recurring keyframe-only degradation.

Diagnostic steps taken to rule out other causes

  • Camera / local capture: Confirmed clean and smooth via ffplay -f v4l2 -input_format h264 -video_size 1920x1080 -i /dev/video0 while moving in front of the camera — no artifacts locally.
  • Screen-content H.264/RFX pipeline: Confirmed clean — played a fullscreen YouTube video inside the same RDP session (both with /gfx:AVC420 and with -gfx /rfx); playback was smooth with no pixelation, even at 55–65% host CPU load.
  • USB layer: dmesg -T | grep -iE "usb|reset" showed no disconnect/reset events on the client during the observed channel teardown cycles — ruling out USB autosuspend / physical disconnect as the cause.
  • VAAPI hardware decoding: Confirmed not in use / not initializing successfully (Failed to initialise VAAPI connection: -1 (unknown libva error), falls back to software decode) — tested both with default settings and with LIBVA_DRIVER_NAME=null forced; behavior was unchanged either way, so this is unrelated to the pixelation.
  • Network: Client and Windows 11 VM are on the same local 1 Gbit/s network (VM hosted locally); bandwidth is not a limiting factor.

Screenshot

Image

Application details

  • FreeRDP version (xfreerdp3 --version): This is FreeRDP version 3.30.0 (6b107f0aa)
  • Command line used:
xfreerdp3 /v:<server> /u:<user> /p:<password> /dvc:rdpecam

(issue reproduces with default /gfx settings as well as with -gfx /rfx and /gfx:AVC444)

  • Camera: Anker PowerConf C200 (UVC, supports MJPG / YUYV / H264 natively; H264 passthrough confirmed active via log: Camera format: H264, width: 1920, height: 1080, fps: 30/1)
  • Build configuration includes (from runtime warning): WITH_VAAPI=ON, WITH_VAAPI_H264_ENCODING=ON (marked experimental by the build)

Environment

  • Client OS: CachyOS (Arch-based), freerdp package (xfreerdp3)
  • Client CPU: AMD Ryzen 7 9800X3D (no iGPU)
  • Client GPU: NVIDIA GeForce RTX 5080 (no working VAAPI driver present; VAAPI init fails and falls back to software decode — separate issue, does not affect the reported bug)
  • Server: Windows 11 Pro (24H2), running as a local VM on the same 1 Gbit/s network as the client
  • RDP client used: xfreerdp3 directly, and via Remmina (same underlying FreeRDP behavior)

Relevant log excerpt (repeating cycle, /log-filters:com.freerdp.channels.rdpecam-v4l.client:TRACE,com.freerdp.channels.drdynvc.client:DEBUG):

[20:22:45:665] [INFO][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_start]: Camera format: H264, width: 1920, height: 1080, fps: 30/1
[20:22:45:666] [DEBUG][com.freerdp.channels.drdynvc.client] - [drdynvc_process_create_request]: ChannelId=19 ChannelName=usb-0000:45:00.4-2.2.2
...
[20:22:50:711] [DEBUG][com.freerdp.channels.drdynvc.client] - [drdynvc_process_close_request]: ChannelId=19
[20:22:50:711] [DEBUG][com.freerdp.channels.drdynvc.client] - [dvcman_channel_close]: listener usb-0000:45:00.4-2.2.2 destroyed channel 19
[20:22:50:712] [DEBUG][com.freerdp.channels.drdynvc.client] - [dvcman_channel_close]: listener usb-0000:45:00.4-2.2.2 destroyed channel 18
[20:22:50:726] [DEBUG][com.freerdp.channels.drdynvc.client] - [dvcman_channel_close]: listener usb-0000:45:00.4-2.2.2 destroyed channel 16
[20:22:50:727] [DEBUG][com.freerdp.channels.drdynvc.client] - [dvcman_channel_close]: listener usb-0000:45:00.4-2.2.2 destroyed channel 17
[20:22:50:730] [DEBUG][com.freerdp.channels.drdynvc.client] - [drdynvc_process_create_request]: ChannelId=16 ChannelName=usb-0000:45:00.4-2.2.2
[20:22:50:731] [DEBUG][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_get_media_type_descriptions]: Camera format: H264, width: 2560, height: 1440, fps: 30/1
...(re-enumeration of all supported formats)...
[20:22:50:738] [DEBUG][com.freerdp.channels.drdynvc.client] - [drdynvc_process_create_request]: ChannelId=17 ChannelName=usb-0000:45:00.4-2.2.2
[20:22:50:889] [DEBUG][com.freerdp.channels.drdynvc.client] - [drdynvc_process_create_request]: ChannelId=18 ChannelName=usb-0000:45:00.4-2.2.2
[20:22:51:575] [DEBUG][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_alloc_buffers]: Buffer 0 mapped, size: 1572864
[20:22:51:575] [DEBUG][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_alloc_buffers]: Buffer 1 mapped, size: 1572864
[20:22:51:575] [DEBUG][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_alloc_buffers]: Buffer 2 mapped, size: 1572864
[20:22:51:575] [DEBUG][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_alloc_buffers]: Buffer 3 mapped, size: 1572864
[20:22:51:754] [INFO][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_start]: Camera format: H264, width: 1920, height: 1080, fps: 30/1

This exact ~5-second close/reopen/restart cycle repeats continuously for the duration of the session (confirmed across multiple independent test runs).

Additional context

  • This looks closely related to #10274 ("Camera doesn't work in Microsoft Teams and Windows Camera") in terms of symptoms (repeated stream start/stop cycling), though in this case the stream does eventually produce a (degraded) image rather than never displaying anything.
  • Happy to provide full debug logs, a screen recording of the pixelation, or test patches if useful.

Source: FreeRDP/FreeRDP

View original on GitHubView discussion on GitHub