Lack of availability of the OBS Studio browser plugin for Linux distros

[olberger]

AFAIU, my main issue wrt OBS Studio, is the availability of the browser plugin for Linux distros.

AFAIU, the plugin depends on an embedded copy of Chromium, which leads to lots of complication for packaging in Debian-based distros, at least (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956086)

So, it seems that using OBS.ninja with OBS on Linux is quite a challenge... or there's an alternative to the browser source in OBS that would deserve better documentation/support, etc.

I initially posted this in the context of another issue, but I guess it deserves an issue of its own once I'm finding additional bits for discussion.

I'd like to get your views on this issue.

Originally posted by @olberger in #554 (comment)

[olberger]

It looks like https://github.com/steveseguin/electroncapture/ may offer a workaround, but seems to have been aimed primarily at MacOS users.

I think Linux users are probably interested too.

[steveseguin]

Hi Olberger, the Electron Capture app was originally developed for macOS, but since OBS 26.1.2 supports macOS now, it's actually mainly used by PC and Linux users.

It offers features like global hotkey support, ISO recording (via dual recording options), lower CPU loads, and is more stable than CEF.

It compiles for linux; binaries are provided for macOS and PC.

[ThePooN]

You can actually compile OBS with built-in browser source on Linux, just like Windows and macOS. But most distros exclude it, because it relies on an arbitrary older version of CEF.

On Arch Linux, you can get it by building obs-studio-git from the AUR.

[matiaspl]

On Ubuntu you can use Snap version of OBS which includes browser support and a lot of other cool stuff as well: https://snapcraft.io/obs-studio.

Bare in mind that the 2D performance is somewhat lacking, so don't expect full motion 1080p video (e.g. Youtube ran in the browser source does around 10-15 fps). Looks like the renderer loop waits for something before pushing new image. But there's actually HW accelerated 3D engine you can enable in the browser-source' built-in Chromium that doesn't have this limitation and does a pretty good job of running at high framerates and resolutions.
The workaround I found some time ago is to have an offscreen 2D canvas that the video is decoded onto and an onscreen WebGL canvas that shows the actual video (the pixel data has to be copied every n=fps times per second).
I got the idea somewhere around here: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL

SInce there's no chance for shared textures or buffers on linux from all GPU vendors in the near future (intel has it, Nvidia needs CUDA to work, I have no info about AMD), it might be the only way to get decent performance anyways.