A Variety of Screensharing Issues

AdalynBlack commented 10 months ago

Describe the bug

impossible to stream fullscreen applications. Normally in Discord, it has some issues, but if you alt tab to the fullscreen application and back, it shows up for a bit, then disappears, and if you click it during that time, you can stream it. On Vesktop, there simply is no way to stream a fullscreen application. The best I've gotten is by making it windowed mode, streaming it, then going to fullscreen, at which point it only sends a new frame every time I alt tab from the game.
stream enters an infinite loading screen initially, with the only way to fix it being to go to the stream options and switching applications, at which point it works fine. Also, there's no way to customize the bitrate, which while not an inherent bug, is somewhat annoying if any parties have a poor internet connection.

To Reproduce

Steps to reproduce the behavior:

Start a call
Attempt to stream a fullscreen application
The fullscreen application doesn't appear as an option
Attempt to stream a windowed application
The stream loads forever and never shows a single frame
Change windows to any application/screen (including the current one)
Stream suddenly works?

Expected behavior

Streaming a screen or application works, regardless of windowed or fullscreen status, and works on the first attempt without needing to switch the stream target to make the stream actually start.

Screenshots

Desktop (please complete the following information):

OS: Windows 11
Version: 22H2

Command line output

[19036:0201/112448.098:ERROR:wgc_capturer_win.cc(255)] Source is not capturable.
[19036:0201/112449.130:ERROR:wgc_capturer_win.cc(255)] Source is not capturable.
[19036:0201/112506.812:ERROR:cert_issuer_source_aia.cc(34)] Error parsing cert retrieved from AIA (as DER):
ERROR: Couldn't read tbsCertificate as SEQUENCE
ERROR: Failed parsing Certificate

Vendicated commented 10 months ago

The second issue is that the stream enters an infinite loading screen initially, with the only way to fix it being to go to the stream options and switching applications, at which point it works fine

issue either with discord or your desktop environment. this even happens on stock discord sometimes

Vendicated commented 10 months ago

as for your other issue, any reason you can't just share the monitor the fullscreen app is on?

AdalynBlack commented 10 months ago

For the second issue, I've never had that happen on stock discord. I also can't exactly change my DE given that I'm on windows. I might be able to mess with some settings, but I wouldn't know where to start with that even. I'll check for a driver update, but I have my doubts that it will help, given that it worked fine yesterday when I first installed it, and I've never had the issue on Discord/Vencord with everything else otherwise being the same

For the first issue, that's the workaround I've been having to use. That or switching to borderless windowed, but some apps don't have that. It's just not exactly convenient, nor is it really the same given that, should I ever alt tab (I only have one monitor), viewers will be able to see everything going on. It also means that desktop audio will be streamed rather than just game audio, and that notifications will show up in stream

Curve commented 10 months ago

as for your other issue, any reason you can't just share the monitor the fullscreen app is on?

I can share full screen applications just fine

AdalynBlack commented 10 months ago

Interesting For me it's always been a bit buggy on Discord/Vencord, with the option only showing for a second or so after alt tabbing With Vesktop, it just flat-out doesn't show up Are you using windows? And if so, what version, and what graphics drivers?

Curve commented 10 months ago

Interesting For me it's always been a bit buggy on Discord/Vencord, with the option only showing for a second or so after alt tabbing With Vesktop, it just flat-out doesn't show up Are you using windows? And if so, what version, and what graphics drivers?

Using Arch Linux, Latest Nvidia drivers

AdalynBlack commented 10 months ago

I see I'll update my graphics drivers and test once I get the chance to. I'm also using NVidia, but I'm also a version or two behind right now I believe

Also, I had a friend that had the same issue the other day, and they're running AMD. I can ask what driver version specifically if that helps for debugging

AdalynBlack commented 10 months ago

I checked my drivers, and I am using driver version 31.0.15.4617, which appears to just be another name for version 546.17. I am using this with an RTX 3070 from ASUS

Vendicated commented 10 months ago

drivers shouldn't have anything to do with this. i made the desktop comment referring to Linux desktop environments, it doesn't apply to windows

Vendicated commented 10 months ago

im not sure how fixable this is. screenshare framework is provided by electron/chromium and the one calling it is discord, so both issues are out of our control. maybe there is some weird workaround for fullscreen windows but it seems like it's a chromium limitation

try opening discord.com/app in a chromium based browser (like edge or chrome) and see if you can share full screen apps in them. if not, there's likely not much we can do

AdalynBlack commented 10 months ago

I just updated my graphics drivers and the issue of needing to switch stream inputs seems to be fixed now, but last time it broke after a reboot, so we'll have to see if it works after a reboot or not. As for the fullscreen apps, the same issue is still present

TacoCake commented 10 months ago

~~I know this is wontfix, but~~ just for the sake of tracking this;

I have the same screensharing issues.

System info

OS: openSUSE Tumbleweed Desktop: KDE Plasma 5.27.10 (Wayland) Vesktop Version: 1.5.0 (Flatpak)

AMD GPU with mesa 23.3.4 drivers.

Pipewire 1.0.1

Vendicated commented 10 months ago

im not sure how fixable this is. screenshare framework is provided by electron/chromium and the one calling it is discord, so both issues are out of our control. maybe there is some weird workaround for fullscreen windows but it seems like it's a chromium limitation

try opening discord.com/app in a chromium based browser (like edge or chrome) and see if you can share full screen apps in them. if not, there's likely not much we can do

^

TacoCake commented 10 months ago

Works correctly in Google Chrome for me

TacoCake commented 10 months ago

In my case, it might be related to Wayland/xdg-desktop-portals, because it seems that Google Chrome, at least for me, is running under XWayland whilst Vesktop is running in Wayland mode.

Might be an issue with the desktop portal implementation for getting the video stream?

Anyway, the issue is not consistent, it works for a moment, then at some point, it will refuse to share anything.

Vendicated commented 9 months ago

it shouldn't depend on whether you run in wayland or xwayland. it will use the pipewire capturer either way, which in turn uses your desktop environment's xdg portal

inconsistent behaviour with chrome is strange, that should not happen. but it might be related to vesktop using a slightly older chrome because the past few chrome versions have brought many improvements. try running with latest electron

there's not much we can do anyway as we just use the apis provided by electron & chrome

stevenre3d commented 7 months ago

Can confirm I and my partner see this issue regularly. Usually right after Vencord starts up screen sharing will work, but if it's been more than a few minutes, I often get this infinite loading loop. A working stream will also eventually stop working spontaneously. I didn't know about using "Change Windows" as a workaround, but can confirm this does work. I've also never seen this behavior with the stock client or the browser client, but obviously those don't share sound.

My suspicion is that something is getting moved around in pipewire, and maybe electron has a bug where it doesn't track the state change appropriately, and restarting (or changing windows I guess) forces it to re-query the state, or something.

I'm on manjaro, with QTile WM, and an AMD GPU, and my partner is on Mint, with Cinnamon, on an Nvidia GPU. I also saw this same behavior with Webcord, so yeah, I'm convinced it's electron's fault.

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

Curve commented 7 months ago

Can confirm I and my partner see this issue regularly. Usually right after Vencord starts up screen sharing will work, but if it's been more than a few minutes, I often get this infinite loading loop. A working stream will also eventually stop working spontaneously. I didn't know about using "Change Windows" as a workaround, but can confirm this does work. I've also never seen this behavior with the stock client or the browser client, but obviously those don't share sound.

My suspicion is that something is getting moved around in pipewire, and maybe electron has a bug where it doesn't track the state change appropriately, and restarting (or changing windows I guess) forces it to re-query the state, or something.

I'm on manjaro, with QTile WM, and an AMD GPU, and my partner is on Mint, with Cinnamon, on an Nvidia GPU. I also saw this same behavior with Webcord, so yeah, I'm convinced it's electron's fault.

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

I doubt it's an issue related with pipewire, once the stream is stopped everything goes back to the default state (i.e. venmic node and all associated links are deleted)

stevenre3d commented 7 months ago

I agree, I said I think it's a bug in electron.

GsK380 commented 7 months ago

The only thing that I wanna to say - is that for me, it worked sometime and stopped on the newest version (v1.4.2), at first, everything worked, then the same issue, but then Flatpak's version of Vesktop (v1.4.1) started working, I have no idea what happened, all actions were done on Fedora 40 with AMD Based system on vanilla GNOME with minimal extensions, Vesktop v1.4.2 were installed using rpm package from this GitHub while Vencord v1.4.1 - from Flathub

yumio7 commented 5 months ago

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

this. seemingly just starts an infinite loading loop after a time, sometimes its once every few minutes, and other times it runs for like an hour before i see it, but i have absolutely no idea what the cause is. Arch Linux, Wayland, AMD drivers

NullCub3 commented 4 months ago

Chiming in to say that the issue where screensharing works for a few minutes and then turns into an infinite loading loop has been plaguing me too on Wayland. Restarting sharing/changing windows works until it decides to break again, rinse and repeat.

I've tested with both the wlr and hyprland xdg desktop portals and it's the same deal with both, and I get the following line in the console when the screensharing breaks:

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

Relevant line in the pipewire code

I did some testing and in just the Chromium browser with stock discord I had the same issue, but without the error in the console as far as I can tell. Using just a regular screen sharing test appears to work just fine however. Same story with Firefox. I'm really not sure where the underlying issue could be coming from or if its just a config/setup issue on my end, but a workaround as mentioned to restart the sharing/change windows in the background would be greatly appreciated, if possible.

System Info OS: NixOS (unstable) Desktop: River (Wayland/wlroots) Vesktop Version: 1.5.3 (nixpkgs) XDG Desktop Portal: wlr (also tested with hyprland) GPU: AMD

Dazukodesu commented 2 months ago

This same exact thing is happening to me System Info OS: EndevourOS Desktop: Hyprland (Wayland) XDG Desktop Portal: Hyprland GPU: Nvidia RTX 4070 Vesktop Version: 1.5.3

[11283:0902/120952.547443:ERROR:interface_endpoint_client.cc(722)] Message 6 rejected by interface blink.mojom.WidgetHost [11283:0902/120952.547466:ERROR:interface_endpoint_client.cc(722)] Message 7 rejected by interface blink.mojom.WidgetHost [11321:0902/120952.631968:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11321:0902/120952.632114:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11321:0902/120952.632135:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11321:0902/120952.632265:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11321:0902/120952.632405:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11321:0902/120952.632471:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.636621:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11391:0902/120952.815264:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11391:0902/120952.815579:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11391:0902/120952.815868:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11391:0902/120952.816073:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11391:0902/120952.816220:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11391:0902/120952.816476:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.826446:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11420:0902/120952.987019:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11420:0902/120952.987130:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11420:0902/120952.987147:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11420:0902/120952.987189:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11420:0902/120952.987204:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11420:0902/120952.987270:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.990474:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11328:0902/120953.054659:ERROR:command_buffer_proxy_impl.cc(132)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer. 'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:425 pw_thread_loop_wait() [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (handle) found default metadata: 38 [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo-output" [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (get) running venmic 6.1.0 [11283:0902/121039.747149:ERROR:screen_capture_portal_interface.cc(48)] Failed to request session: Timeout was reached [11283:0902/121039.747186:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3

Vencord / Vesktop

A Variety of Screensharing Issues #372

System info