[Bug] Very low FPS when Screensharing

[PacketAuditor]

Discord Account

No response

Operating System

EndeavourOS (Wayland)

Linux Only ~ Desktop Environment

KDE

What happens when the bug or crash occurs?

When screensharing, the quality is not ideal, but the biggest issue is the framerate is horrible. ~2-10 FPS.

What is the expected behaviour?

The frame rate selected is respected.

How do you recreate this bug or crash?

1. Start Screensharing

Debug Logs

[p@p-pc ~]$ vesktop
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] listening on 6463
[arRPC > process] started
src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[2024-05-28 17:38:33.624] [venmic] [info] [patchbay] (get) running venmic 3.4.2
[2024-05-28 17:38:33.629] [venmic] [info] [patchbay] (handle) found default metadata: 37
[2024-05-28 17:38:33.629] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.pci-0000_0b_00.4.iec958-stereo.2"

Request Agreement

• [X] I have searched the existing issues and found no similar issue
• [X] I am using the latest Vesktop and Vencord versions
• [X] This issue occurs on an official release (not just the AUR or Nix packages)

[PolisanTheEasyNick]

Can you please send screenshot of stream debug? You can get it by:

1. Enabling Developer mode in Discord settings
2. Starting Stream
3. Clicking on "Voice connected" green text and "Debug" upper screenshare button in bottom left corner
4. Picking "Output" under "Debug RTC: Stream"

Also, please specify which content type you are using (smoothness or clarity).

[PacketAuditor]

Can you please send screenshot of stream debug? You can get it by:

1. Enabling Developer mode in Discord settings

2. Starting Stream

3. Clicking on "Voice connected" green text and "Debug" upper screenshare button in bottom left corner

4. Picking "Output" under "Debug RTC: Stream"

Also, please specify which content type you are using (smoothness or clarity).

Captured playing CS2 (Framerate dips in the graph are due to sitting at Desktop not interacting with system):

Thank you for sharing the debug feature; I had no idea it existed. Now that I have played around with it and watched the debug output, I don't think the actual stream framerate is an issue.

The two issues I am experiencing are:

1. Quality often settles at 1280x720 despite having plenty of upload capacity and not having this issue on Windows.
2. Every window I have tried seems to exhibit major stuttering. Oddly, games (both Xwayland and Native) don't seem to have the issue, except in some menus, like the CS2 console, for example.

(Recording with OBS does not have the same behavior)

https://github.com/Vencord/Vesktop/assets/140283647/07c0f385-0680-4381-bfd4-ee28ce434f46

[PolisanTheEasyNick]

Quality often settles at 1280x720 despite having plenty of upload capacity and not having this issue on Windows.

It is because of big motion at stream and 8k bitrate is not enough for 60 fps target streaming.

exhibit major stuttering

That's because of Chromium bug with DMA-Buffers. Today fix was merged to Chromium), so we just need for Chromium to release new Tag version, then wait for Electron to use this Chromium version and then use this Electron version in Vesktop for getting rid of slutters while streaming.

[PacketAuditor]

Quality often settles at 1280x720 despite having plenty of upload capacity and not having this issue on Windows.

It is because of big motion at stream and 8k bitrate is not enough for 60 fps target streaming.

exhibit major stuttering

That's because of Chromium bug with DMA-Buffers. Today fix was merged to Chromium), so we just need for Chromium to release new Tag version, then wait for Electron to use this Chromium version and then use this Electron version in Vesktop for getting rid of slutters while streaming.

It seems to be doing slightly better in 1440p/30FPS, I'd say about 50% of the time it will be 1440p, but it still sometimes settles at 720p or 1080p for the other 50% of the time despite having 8-9k bitrate. Is there any way to force it?

so we just need for Chromium to release new Tag version, then wait for Electron to use this Chromium version and then use this Electron version in Vesktop for getting rid of slutters while streaming.

Also any idea when this might happen?

[PolisanTheEasyNick]

Is there any way to force it?

You can try to set minimal weight and height here and here, but I'm not sure how it will work then.

Also any idea when this might happen?

No idea :c

[PhantomShift]

I suspect that this is the same bug that some people are experiencing in this issue https://github.com/Vencord/Vesktop/issues/545. You may notice that the FPS is only dropping when the cursor is moving in the area that's been screenshared (i.e. in menus when playing games); if so, it's definitely that issue and is a bug that is set to be fixed in chromium 126 I'm dumb and didn't see this comment, whoops https://github.com/Vencord/Vesktop/issues/629#issuecomment-2136191619 https://bugs.kde.org/show_bug.cgi?id=486081 https://webrtc-review.googlesource.com/c/src/+/349881

[winlith]

using electron 31, the bug with flickering on mouse move is gone, however now the stream's fps drops to 1-2 when NOT moving the mouse inside the streamed window arch, kde 6.1, nvidia beta 555

https://github.com/Vencord/Vesktop/assets/19815169/46b467f4-9194-4500-94eb-d28b8e31174b

[PolisanTheEasyNick]

stream's fps drops to 1-2 when NOT moving the mouse inside the streamed window

What's your hardware? CPU and GPU? Looks like encoder struggling bc bitrate looks good.

[winlith]

What's your hardware? CPU and GPU?

amd r9 5900x, rtx3080 i dont think hardware is the problem, since when the mouse is moving, the stream is smooth, also under x11 the fps is constant 60 no matter if the mouse is moving or not, i guess it's kde 6.1 that broke something on wayland but im no expert

update: has to be kde issue, just installed gnome and the problem is gone there (kinda, it's tearing badly but fps is always at 60)

[dmizelle]

I was running into this problem earlier today where screensharing was running at around 11 FPS according to the debug window people were using above.

After seeing this comment: https://github.com/Vencord/Vesktop/issues/629#issuecomment-2136191619 I decided to "rebuild" my vesktop installation with the latest Electron 31 (31.0.2). I'm using NixOS (did the Arch meme of "btw" move to NixOS yet?), so it kind of worked like below. I had to use a local fork of nixpkgs as Electron 31 hasn't landed there yet:

{pkgs, inputs, ...}: let
    electron-31 = (import inputs.nixpkgs-forked {}).electron_31-bin;
in {
  home.packages = [
    (vesktop.override {
        electron = electron-31;
      })
  ];
}

Once I rebuilt and launched Vesktop, I ran vkcube with gamescope vkcube to simulate how I launch Steam games (modifying the launch options to use gamescope by default.) Then, I did a screenshare and can verify that I am hitting the desired framerate:

Before this both the input and the encode were ~10-12 FPS.

It may be worth noting as well that:

• I'm using xwaylandvideobridge
• I had to launch vesktop with the following arguments, or when I chose the gamescope window in the popup, the screensharing popup (where you select smoothness vs clarity, etc.) would close:

vesktop \
  --ozone-platform-hint=auto \
  --enable-webrtc-pipewire-capturer \
  --enable-features=WaylandWindowDecorations \
  --enable-features=UseOzonePlatform \
  --ozone-platform=wayland \
  --use-gl=angle \
  --use-angle=gl \
  --enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder

My console is being spammed with this line, but I think it is benign for now:

[25550:0624/184132.515716:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE

If there is any additional info that I can provide, please do not hesitate to ask.

[PhantomShift]

The issue where capture is low framerate when there isn't mouse movement has been reported to KDE. I actually wasn't having this issue for a while but it popped up for me today, and posted some additional details in the tracker. As I noted there, the issue doesn't seem to happen on Firefox, only on Chromium.

I tried using vesktop with electron31 as dmizelle did but am still getting low framerates. Looking at the debug screen, this seems to be an issue specifically on the capture side and not encoding or anything since the input framerate is low whereas the encoding time is well within acceptable levels

Just for some additional footage of the issue in action. https://github.com/Vencord/Vesktop/assets/83253309/345975ef-2a83-400c-bee3-71946b808eac

[PacketAuditor]

That's because of Chromium bug with DMA-Buffers. Today fix was merged to Chromium), so we just need for Chromium to release new Tag version, then wait for Electron to use this Chromium version and then use this Electron version in Vesktop for getting rid of slutters while streaming.

Is this supposed to be fixed now? I still get these stutters when dragging windows, latest Vesktop.

[Covkie]

that patch has not reached chromium stable yet so we are still waiting.

[lukas0098]

When could we expect the update?

[AAGaming00]

no idea, we don't control chromium and electron releases

[lextra2]

Possible fixed by #703 ?

[PhantomShift]

Possible fixed by #703 ?

I can confirm that with these changes it fixes the low framerate when the cursor isn't moving for me.

https://github.com/Vencord/Vesktop/assets/83253309/91bb0371-014e-42cf-98fc-3a19c0c0020c

[PacketAuditor]

Possible fixed by #703 ?

I can confirm that with these changes it fixes the low framerate when the cursor isn't moving for me.

Is this also a fix for the original issue when dragging windows around?

[PhantomShift]

Is this also a fix for the original issue when dragging windows around?

I do not believe so, no, just the low framerate when the mouse isn't moving.

[Frankiscophil]

Can confirm. The issue of the stream dropping FPS when cursor is moving still persists.

[PolisanTheEasyNick]

We need to fully wait for Chromium M127 then.

[lukas0098]

so waiting room till 23 :(

[aaomidi]

Can you send a link to the M127 status page?

[viasux]

I also have this issue on windows

[zastrixarundell]

Can you send a link to the M127 status page?

https://chromiumdash.appspot.com/schedule

Can't wait to have more stable FPS~

[xanni3]

I believe Chromium 127 is out now :)

[lewisakura]

I hate to break it to everyone, but Electron's release schedule is only on even-numbered Chromium releases since 2021, and they've only just released M126/Electron 31 last month. You will have to wait until M128/Electron 32 before we can update (which is apparently scheduled for full release in August), and if that will actually fix the issue once and for all... well we'll wait and see.

You can check the timelines for Electron releases here: https://www.electronjs.org/docs/latest/tutorial/electron-timelines

[fliplus]

Any updates?

[C0Nd3Mnd]

@fliplus Electron 32 reached stable today, so now Vesktop needs to be updated with this Electron version. I'd say give it a few days.

[tsuza]

Screenshares have had a terrible, terrible, quality on Vesktop on Linux. Hopefully the latest Electron version fixes it.

[Redemption198]

I've run a quick test of Vesktop on Electron 32 and screensharing seems to perform well, the only issue I found is that sometimes the selected application starts to lag, until the screenshare is restarted.

Here is how I tested it:

git clone https://github.com/Vencord/Vesktop
cd Vesktop

pnpm i

pnpm add -D electron@32

pnpm start

[tsuza]

I've just given it a try. Still terrible quality.

[zastrixarundell]

The exact bug of the stuttering is gone. But generally the stream is super slow. Maybe with 720p @ 30FPS it's okay, but 1080p @ 60 FPS is just bad.

[Covkie]

Maybe with 720p @ 30FPS it's okay, but 1080p @ 60 FPS is just bad.

If you dont have nitro youre probably hitting the bitrate cap

[PARoby]

Had the same problem on Ubuntu with X11 and PulseAudio. Not sure if this could help for troubleshooting. I have an Intel 11th gen cpu (i7-11700) and an Amd graphics card(6650 xt) on a Dell motherboard (not sure the model). The vesktop version was up to date and not altered by any customization script i could have added. I used it as downloaded. Both vesktop and videogame suffered for massive fps drops when screensharing was active(less than 20 fps for both).

I now switched for Fedora so i cannot provide any error logs. If it is not helpful feel free to delete my comment. Cannot comment for Fedora (wayland and pipewire) but i am willing to try it if needed for troubleshooting purposes.

[PhilVoel]

Possibly fixed by 37db07807a62435b99a6a11037c84184517ebc69 if somebody wants to test with a build from current master

[theghuze]

Possibly fixed by 37db078 if somebody wants to test with a build from current master

I used to have this issue but it has been gone for some time now on my end (I'm using the flatpak version of Vesktop)

[Yamakaky]

Hum, I had this issue a few days/weeks ago. I just tried master, no issue. I retried with vesktop 1.5.3/electron 31, no issue... I don't remember doing system updates in the mean time, maybe I did. Anyway, the problem seems fixed on my end!

[Yamakaky]

Is anyone still having this issue with latest version? If not I think we can close this.

[tsuza]

It hasn't been pushed yet, so I doubt a lot of people are using it and are able to confirm it.

[Yamakaky]

oh right, my bad

[lrussell887]

I've encountered a similar issue on the new Kubuntu 24.10, which now defaults to Wayland. In the current release build, screen sharing works for just a few seconds before getting "Your stream currently has reduced video or audio quality." At which point, the viewer stops seeing any changes to the screen at all. In Debug, the frame rate drops from 30 (or 60) fps to around 4 fps. I’m using an Intel Arc A770 GPU, but I didn’t notice any difference after disabling "Hardware Acceleration" under Video Codec settings.

That being said, after testing the latest main build from source, the issue seems to be fully resolved and appears to be using hardware encoding. I hope to see the next release soon. 😄