[Bug] Hardware encoding not working properly linux

[developer-iname]

Discord Account

No response

Operating System

Linux(Arch)

Linux Only ~ Desktop Environment

Sway

Package Type

pipewire wireplumber xdg-desktop-wlr xdg-desktop-portal mesa

What happens when the bug or crash occurs?

Stream is unviewable

What is the expected behaviour?

I expect discord to stream and be viewable for others.

Actual result:
Others see an infinite loading screen, or the stream is garbled mess of black and white with some visible screen elements.

On launching vesktop from the terminal i see this
ERROR:vaapi_video_decoder.cc(1225)] failed Initialize()ing the frame pool

Which I believe is the culprit, I have not found a solution, however I believe it may be that vesktop is fallbacking to software decoding. As if the person recieving the stream on the other end disables their hardware encoding, it fixes the issue.

Also, perfomance while streaming is degraded massively.

How do you recreate this bug or crash?

1. Stream
2. Receiver sees errors
3. End Stream
4. Receiver turns off hardware acceleration
5. Stream
6. Receiver sees stream

Debug Logs

ERROR:vaapi_video_decoder.cc(1225)] failed Initialize()ing the frame pool

Request Agreement

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

[mazeratibooloo]

Also having this exact same issue, I've been having it for nearly a week now. On Arch / KDE Plasma. Though, I'm not
getting a similar error running from terminal. Instead, I get:

'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:425 pw_thread_loop_wait()

Though this implies to me an issue with the audio on screen-share, which I definitely wasn't having previously. I'm having the exact same bug though. The workaround did work though. Something seems wrong with hardware encoding.

A friend of mine took a screenshot of what it looked like after it took forever to load for them. For many others, it just fails to load.

EDIT: I am now getting the same exact error in my debug logs. Would appear we have the same issue.

[Skeletonek]

Have the same issue as you but my has been closed (#997)
I am having the same error in console regarding va-api drivers on my Arch Linux system (Mesa 24.3.1)

I've checked running Vesktop 1.5.4 Appimage through distrobox running Ubuntu Noble with Mesa 24.0.9 and the stream seems to be working properly there. Running natively on arch is causing the stream to be super dark for the viewers of official discord client

[mazeratibooloo]

If they plan to close this one similarly, it'd be nice to have an explanation further than marking the issue with tags and then just closing it. If it's not fixable by Vesktop and it's an issue with something else, it'd be great to know where to post an issue up about it.

[Kerko0]

Getting the same error and it seems to not matter whether the reciever is using Vesktop or the official Discord client (on Windows too). I'm using Vesktop on Linux and whenever I try screensharing it infinitely loads for the reciever. And like you explained in the repro steps I asked her to disable hardware acceleration and after that she could view the stream.

[Vendicated]

If it's not fixable by Vesktop and it's an issue with something else, it'd be great to know where to post an issue up about it.

I don't know. It could be Chromium, Electron, Discord, your system, etc

It works flawlessly for me (rpm package on Fedora + Gnome (Wayland)) so it's definitely an issue specific to your systems

[Kerko0]

Narrowing it down further it seems to be an issue with Vesktop and X11. Since that's what I use. I switched to another discord client and screensharing worked just fine there.

[Skeletonek]

I'm using wayland and the issue is present there so it's not only X11
I'm wondering if this is connected to the mesa driver / va-api version.

Arch

vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 24.3.1-arch1.3 for AMD Radeon RX 6600 (radeonsi, navi23, LLVM 18.1.8, DRM 3.59, 6.12.4-arch1-1)

Ubuntu Noble via Distrobox

vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 24.0.9-0ubuntu0.3 for AMD Radeon RX 6600 (radeonsi, navi23, LLVM 17.0.6, DRM 3.59, 6.12.4-arch1-1)

[Kerko0]

Interesting observation though the 2.22.0 version of libva was released back in July and this issue didn't start until a few days ago for me. (should note that i also use Arch which does line up with the issue being persistent on mostly Arch systems). Either way like I said I tried a different discord client (GoofCord) and screensharing seemed to work fine so maybe that's a clue. Could do more poking around tomorrow with different scenarios if no one has any more clues by then

[mazeratibooloo]

If it's not fixable by Vesktop and it's an issue with something else, it'd be great to know where to post an issue up about it.

I don't know. It could be Chromium, Electron, Discord, your system, etc

It works flawlessly for me (rpm package on Fedora + Gnome (Wayland)) so it's definitely an issue specific to your systems

This is understandable. Thanks for the clarification nonetheless. My only guess is it's VA-API related since that's the error we're seeing popup. But yeah, it would appear to be unrelated. I'm gonna re-test with the Flatpak version and see if that helps.

[ZacharyVarney]

It is not just happening on there systems I'm also getting it on fully up to date CachyOS system which is (Arch) based

[Vendicated]

seems as though the vast majority of people experiencing this use Arch Linux. like Łukasz said, it might be related to a regression in the new version of some driver

You could also try downgrading Vesktop to 1.5.3 and 1.5.2 to see if it was a regression in electron / chromium. Both of those releases upgraded the major version of electron. Do not go lower than those versions though because otherwise it will likely mess up your Vesktop settings

[Covkie]

ERROR:vaapi_video_decoder.cc(1225)] failed Initialize()ing the frame pool is a very common log from chromium/electron on linux and verrry likely has nothing to do with this.

I am on latest arch kde plasma and can stream from vesktop just fine. Maybe others need to play around with flags like --disable-gpu-driver-bug-workarounds or --ignore-gpu-blocklist

[mazeratibooloo]

seems as though the vast majority of people experiencing this use Arch Linux. like Łukasz said, it might be related to a regression in the new version of some driver

You could also try downgrading Vesktop to 1.5.3 and 1.5.2 to see if it was a regression in electron / chromium. Both of those releases upgraded the major version of electron. Do not go lower than those versions though because otherwise it will likely mess up your Vesktop settings

Downgrading to 1.5.3 fixed it on my system.

[Vendicated]

then it's an electron / chromium regression. you should try creating a minimal electron reproduction app and report it to electron

[ArbitraryRenaissance]

I'm trying to downgrade, but the AppImage seems to be forcing the latest version when I run it. I do not have auto-update enabled in my settings.

[ArbitraryRenaissance]

Okay, I ended up successfully downgrading to 1.5.2, but the issue persisted for me.

[mazeratibooloo]

I was going to add that my appimage kept updating too. Trying to downgrade the Flatpak also didn't work either. Doesn't seem too easy to downgrade.

[Kyr4l]

not only arch is affected but also OpenSUSE TW since a few weeks
screensharing is unusable, it would be nice to have a dedicated thread for all the users experiencing this problem, hunting for non-locked issues on github will make it hard for everyone to find a solution.