maximbaz/dotfiles

[Question] Screen sharing via fake video device

mordax7 opened this issue ยท 5 comments

Hello @maximbaz ,

I was looking at your solution for screen sharing under Wayland and took a look at ~/.local.bin/sway-screenshare. What I am interested in more precisely is your script's possibility to capture/share only a selected area of your screen. The script on its own works I believe, I can see that a /dev/video9 device gets created, but it does not seem to get it picked up by my Chromium. Since WebRTCPipeWireCapturer is enabled, the only possibility I can pick from the options is the to share the entire screen.

Am I missing something?

Here the output from the script:

selection cancelled
Bad geometry: , capturing whole output instead.
selected region 0 0 0 0
Choosing pixel format yuv420p
Output #0, video4linux2,v4l2, to '/dev/video9':
    Stream #0:0: Unknown: none (rawvideo)
[video4linux2,v4l2 @ 0x7f061c000d00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Terminated

Ahh, I answered my question inside the question. The captured screen is streamed as a webcam video input, not the screen sharing itself. So it seems like it works.

I used Google Meet to test this, and another question came up while using it. The quality of the shared screen was inferior, and I wondered if either Google doses some decompressing of the webcam stream or is this the driver's fault?

Also: Do you think something similar would be possible using the screen sharing method?

Hey ๐Ÿ‘‹

Yeah this method is my absolute final fallback if nothing else works... Luckily screensharing is possible via WebRTC so this is what I usually use, in the apps that support it (e.g. Chromium-based browsers, and soon in all Electron apps, the support was added in Electron 12 which is going to be released in March).

You can check the quality of the recording using mpv av://v4l2:/dev/video9. I believe the problem is that with this approach it's not possible to record in downscaled resolution, so the stream is actually too large, and then apps like Google Meet try to decrease this but they can't do it very intelligently, and thus quality becomes terrible.

Funnily enough, you asked the question in the very appropriate moment - I spent this evening researching https://github.com/screego/server, it looks amazing, I'm in the process of setting it up. It uses WebRTC, so proper peer-to-peer connection, works in a browser, and quality is amazing.

So to summarize, I hope we'll soon be able to completely remove this sway-screenshare script, especially once Electron 12 is being released, as many apps are based on it. But for now, if regular WebRTC screen sharing is not possible, and screego doesn't work, then we can at least try to fallback to this script...

Thanks!

Screego does look exciting, and I might throw an eye on it too. When I was researching screen sharing yesterday under Wayland using Pipewire, I found out that Fedoras fork of Firefox has a native Wayland support and supposedly uses the newer version of Pipewire, which supports also sharing single windows. I did not check it out yet, but here's the AUR repo to it: https://aur.archlinux.org/packages/fedora-firefox-wayland-bin

Ill take a look at it today and report back what I found out.

So I was digging around some more and found this: flatpak/xdg-desktop-portal-gtk#204

I directly try using it in my Arch+Gnome(Wayland) setup, and it worked as described in the ticket. I then tried installing Fedora's Wayland Firefox fork and xdg-desktop-portal-gtk under Sway but had no luck. The window did not come up, and it went directly to share the entire screen.

Need some more digging.

Will close but if you learn something else interesting, please share here ๐Ÿ˜‰