[BUG] Extremely sluggish mouse controls

[BlaM]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

With the latest update (the one requiring HTTPS) the mouse in the VNC session suddenly became extremely sluggish. The "virtual browser" went from very usable (barely noticeable delay) to awful to navigate. When moving the mouse over the screen with a steady speed the pointer jumps in small hops, making hitting links very difficult.

I see the same behavior both when accessing port 3001 directly on the machine hosting the Docker as well as over my reverse proxy going to port 3000.

The PC running Firefox is fast enough and has free resources. Also: The problem did not exist on the previous version.

Expected Behavior

Higher framerate/lower lag when moving the mouse over the screen.

Steps To Reproduce

• Docker on Unraid
• Open dockerized application via https://:3001/ (in my case it's 44301, but that's just a detail)
• Move mouse over the browser

Environment

- OS: Unraid 7.1.4
- How docker service was installed: "Apps" store
- Accessing Browser: Chrome 138
- Accessing OS: Windows 10
- Both Server and Client on the same network with 1GBit connection.

CPU architecture

x86-64

Docker creation

Via UI this command is executed:

docker run
  -d
  --name='firefox'
  --net='bridge'
  --pids-limit 2048
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="shinra"
  -e HOST_CONTAINERNAME="firefox"
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'UMASK'='022'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:3000]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/firefox-logo.png'
  -p '8800:3000/tcp'
  -p '44301:3001/tcp'
  -v '/mnt/bla1':'/mnt/download':'rw'
  -v '/mnt/user/bla2':'/mnt/bla2':'rw'
  -v '/mnt/user/appdata/firefox':'/config':'rw'
  --shm-size=1gb 'lscr.io/linuxserver/firefox'
5f94f21da3ad85ffac202b08d607461794cf28dd61df0ebf9e0a20c9595dd6aa

Container logs

INFO:data_websocket:PulseAudio connection established.
INFO:data_websocket:Applying client settings (initial=True): {'videoBitRate': 8000, 'videoFramerate': 60, 'videoCRF': 25, 'encoder': 'x264enc', 'h264_fullcolor': False, 'h264_streaming_mode': False, 'resizeRemote': True, 'isManualResolutionMode': False, 'manualWidth': 2160, 'manualHeight': 1958, 'audioBitRate': 320000, 'videoBufferSize': 0, 'initialClientWidth': 2160, 'initialClientHeight': 1958}
INFO:data_websocket:Initial client settings processed and event set by _apply_client_settings.
INFO:data_websocket:Initial client settings message processed by ws_handler.
WARNING:webrtc_input:No clipboard content to send
INFO:data_websocket:Received START_VIDEO for encoder: x264enc
INFO:data_websocket:x264enc pipeline is already capturing.
INFO:data_websocket:Received START_AUDIO command from client for server-to-client audio.
INFO:data_websocket:START_AUDIO: pcmflux audio pipeline already active.
INFO:data_websocket:Stats sender: WS connection closed.
INFO:data_websocket:Received STOP_VIDEO
INFO:data_websocket:Stopping X11 x264-striped capture...
INFO:data_websocket:Frame-based backpressure logic task cancelled.
INFO:data_websocket:Frame-based backpressure logic task finished.
INFO:data_websocket:Backpressure task was stopped. Calling _reset_frame_ids_and_notify.
INFO:data_websocket:Resetting frame IDs.
INFO:data_websocket:Broadcasting PIPELINE_RESETTING to 2 client(s).
INFO:webrtc_input:Set clipboard content, length: 27
INFO:webrtc_input:Sending clipboard content, length: 27
INFO:data_websocket:Cleaning up Data WS handler for ('127.0.0.1', 55390)...
INFO:data_websocket:Client from ('127.0.0.1', 55390) disconnected. Checking responsiveness of remaining 1 client(s)...
INFO:data_websocket:  Remaining client ('127.0.0.1', 42154) is responsive.
INFO:data_websocket:Client from ('127.0.0.1', 55390) disconnected. Responsive clients (1) remain. Global pipelines will NOT be stopped by this handler.
INFO:data_websocket:Data WS handler for ('127.0.0.1', 55390) finished all cleanup.
INFO:data_websocket:Received START_VIDEO for encoder: x264enc
INFO:data_websocket:Starting x264enc: 2160x1958 @ 60.0fps, CRF: 25, FullFrame: True
INFO:data_websocket:New frame backpressure task started (current encoder: 'x264enc').
INFO:data_websocket:x264enc capture started successfully.
INFO:data_websocket:Frame-based backpressure logic task started.
INFO:data_websocket:Client settings received, proceeding with backpressure loop.
INFO:data_websocket:Stats sender: WS connection closed.
INFO:webrtc_input:Set clipboard content, length: 27
INFO:webrtc_input:Set clipboard content, length: 27
INFO:webrtc_input:Set clipboard content, length: 27
INFO:data_websocket:Cleaning up Data WS handler for ('127.0.0.1', 42154)...
INFO:data_websocket:Last client (('127.0.0.1', 42154)) disconnected. Cancelling frame backpressure task.
INFO:data_websocket:No other clients in set after ('127.0.0.1', 42154) disconnected. Marking pipelines for stop.
INFO:data_websocket:Stopping global pipelines due to last client disconnect (('127.0.0.1', 42154)).
INFO:main:Initiating unified pipeline shutdown...
INFO:main:Queueing x264-striped capture stop.
INFO:main:Queueing pcmflux audio capture stop.
INFO:main:Waiting for 2 capture module(s) to stop...
INFO:main:All C++ capture modules have stopped.
INFO:data_websocket:Frame-based backpressure logic task cancelled.
INFO:data_websocket:Frame-based backpressure logic task finished.
INFO:data_websocket:Backpressure task was stopped. Calling _reset_frame_ids_and_notify.
INFO:data_websocket:Resetting frame IDs.
INFO:data_websocket:Frame IDs reset, but no clients to notify.
INFO:data_websocket:pcmflux audio chunk broadcasting task cancelled.
INFO:data_websocket:pcmflux audio chunk broadcasting task finished.
INFO:main:Unified pipeline shutdown complete.
INFO:data_websocket:Data WS handler for ('127.0.0.1', 42154) finished all cleanup.
INFO:data_websocket:Stats sender: WS connection closed.
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 2.00 EncStripes/s: 2.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 2.00 EncStripes/s: 2.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 2.00 EncStripes/s: 2.00
Capture loop stopped. X resources released.
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
X Shared Memory Extension available.
XShm setup complete for 2160x1958.
CPU cores available: 12
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 29.00 EncStripes/s: 29.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 14.00 EncStripes/s: 14.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 7.00 EncStripes/s: 7.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 12.00 EncStripes/s: 12.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 20.00 EncStripes/s: 20.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
[pcmflux] Status | Read: 108, Silent: 0 (0.0%), Encoded: 108, Rate: 1.30 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 6.00 EncStripes/s: 6.00
[pcmflux] Status | Read: 95, Silent: 0 (0.0%), Encoded: 95, Rate: 1.14 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 31.00 EncStripes/s: 31.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
[pcmflux] Status | Read: 98, Silent: 0 (0.0%), Encoded: 98, Rate: 1.18 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 6.00 EncStripes/s: 6.00
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 1.00 EncStripes/s: 1.00
[pcmflux] Status | Read: 99, Silent: 0 (0.0%), Encoded: 99, Rate: 1.19 kbps
Res: 2160x1958 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 0.00 EncStripes/s: 0.00
Capture loop stopped. X resources released.
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
[pcmflux] Stop requested. Cleaning up capture loop...
[pcmflux] Audio capture loop finished. Resources released.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[thelamer]

The only piece of information that matters here is your clientside browser, what are you landing on it with ?

[BlaM]

Chrome (latest version) under Windows. Worked nicely with that before the server-side update.

(Ticket description updated accordingly)

[thelamer]

Explain your server setup, so unraid is established, but like what proc/specs?
Does jpeg mode work any better for you?

[BlaM]

The server is running on a Intel® Core™ i5-10600 CPU with 6 cores at 3.30GHz. CPU load is at somewhere around 15-25% at the moment of testing right now (both confirmed by UnRaid and the Selkies UI).

There is no extra graphics card in the PC (so no nvidia acceleration possible), only CPU based GPU.

I didn't know that there are now tons of more settings apparently. Those were not here before the update I think?

JPEG encoder is not perfect, but significantly better than x264. x264-striped also improves performance but is somewhere between JPEG and x264 I would say.

With JPEG it runs relatively smooth with a stutter every second or so. I think I can live with that.

Enabling/disabling sound does not make a difference

[thelamer]

Yeah it is a new stack https://github.com/linuxserver/docker-baseimage-selkies/

You can try turbo mode that will work like a normal video encoder, the base mode tries to sip CPU and does not thread much stuff out.

Also take a look at the chromium image https://github.com/linuxserver/docker-chromium
If you hate google use the ungoogled chromium or brave image
https://github.com/linuxserver/docker-ungoogled-chromium
https://github.com/linuxserver/docker-brave

Firefox has its market share for a reason these days. You will notice a major difference particularly in audio.

Your proc has avx2 which really is the accel needed these days to do video codec with a cpu.
I test mostly with AM4/AM5 setups, this image is no longer geared towards the I need to hop in and look at static content crowd anymore my focus is on delivering a native experience for modern hardware, but JPEG still exists for a fallback to traditional VNC stuff.

Just for your SA, the jpeg mode has a known bug where it is not knocking down the quality on motion so you are always getting 90 quality jpegs this is more cpu usage and more bandwidth, but this will waterfall on Sunday with other bug fixes:
linuxserver/pixelflux@6ae8d8e

[BlaM]

Ok, let's try. I did this (verbose for documentation purposes, maybe others are looking as well):

• In Unraid I went to edit the container.
• "Add another Path, Port, Variable, Label or Device"
• Device, Name: "/dev/dri", Value: "/dev/dri"
• Confirmed that I now have this in the docker image:

  root@3fe1ecae1620:/# ls -la /dev/dri
  total 0
  drwxr-xr-x 2 root root            80 Aug  7 08:43 .
  drwxr-xr-x 7 root root           380 Aug  7 08:43 ..
  crwxrwxrwx 1 root videoef45 226,   0 Aug  7 08:43 card0
  crwxrwxrwx 1 root videoef45 226, 128 Aug  7 08:43 renderD128
  

• "Add another Path, Port, Variable, Label or Device"
• Variable, Name: "DRINODE", Key: "DRINODE", Value: "/dev/dri/renderD128"

This will add the following two parameters when runnind the docker image:

  -e 'DRINODE'='/dev/dri/renderD128'
  --device='/dev/dri'

So far, so good. It is running and right now it's running well on "x264enc". I'm currently on another client machine, I'll have to re-test on the client I was using yesterday later.

Small nitpick: I can't really say if it is using CPU accelerated encoding or just software as before.

But according to the logs it seems to be able to keep up with 60fps at roughly 2000x2000

[pcmflux] Status | Read: 101, Silent: 0 (0.0%), Encoded: 101, Rate: 1.21 kbps
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 61.00 EncStripes/s: 61.00
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 60.00 EncStripes/s: 60.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 61.00 EncStripes/s: 61.00
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 60.00 EncStripes/s: 60.00
[pcmflux] Status | Read: 100, Silent: 0 (0.0%), Encoded: 100, Rate: 1.20 kbps
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 61.00 EncStripes/s: 61.00
Res: 2010x2002 Mode: H264 (CPU) CS_IN:I420 LR FF Stripes: 1 CRF:25 EncFPS: 60.00 EncStripes/s: 60.00

It struggles with 60fps at 4k resolution, but manages 30fps, which should be more than enough for general browsing. Most important thing: It's steady and not chunky.