Getting this to run (and smooth!) on #Linux was a PITA. Who would have guessed. And all because I don't want a "streaming" service or some gorram gold membership in a specific video conference "app".
Expect an article!
@bekopharm I did this a few weeks back and have been using v4l2loopback with OBS to get a higher fps screenshare through Jitsi, working very well :)
Which part was a pain in the ass to you?
@unicorn v4l2loopback is indeed in use (awesome btw - fiddled with it in 2017 already using my action cam as webcam: https://beko.famkos.net/2017/10/27/sony-fdr-x1000v-as-webcam/ ) but(!) most WebRTC access out there is… flaky at best.
It does detect my devices but somehow never asks permission for any device but my first "two" cameras probably not liking the "features" (codec is fine).
@unicorn Also I tried to run without obs-v4l2sink that has to be compiled before too by using a ffmpeg stream but that's so slow…
Puzzling all this together is not userfriendly at all.
I can do it. Joe Webuser? Unlikely.
@bekopharm I agree it's not super consistent, I remember seeing an alternative to v4l2loopback and a chart showing some applications in which either do/don't work. You might also want to give one of the options mentioned on the GitHub a try that is supposed to enable compatibility with chrome/chromium based things. It's mentioned somewhere in the readme :)
The need to self-compile is definitely a barrier, but these two were easier than most things I have attempted to compile.
@bekopharm Overall it's not optimal, but possible in not too much time. It just has a bit of an entry barrier for people who don't mess with their system very much.
Still it was a breeze compared to my attempts to route desktop audio and microphone into a single virtual input device so that the other person can hear things I am hearing 😄
That took me several attempts over the span of a couple of months. Spent like 4 days figuring it out overall, giving up multiple times 😅
@unicorn Been there, done that :)
Fiddled with this all night and learned more than I ever wanted about.
…Chrome is all "loopdevice is not upstream kernel - don't care".
About compiling: That's IMHO luck in this case. I compiled this several times since 2017 and I had to patch stuff manually again and again.
Last commit on obs-v4l2sink e.g. is ~1.5yrs ago. That's never a good sign.
@bekopharm Yeah obs-v4l2sink is not without its issues, for example it just crashes OBS if I try to run it with 720p downscaled video, even though I could swear it worked before 🤷♂️
Compilation luck may also depend on the distro; I did it on Debian and Ubuntu, for which there are even some repo packages for v4l2loopback and a .deb file for obs-v4l2sink. Overall it's not great, yeah. Very useful when it works though, would not be able to play a game with my partner over Jitsi without it :)
@bekopharm how did you get the resolution fixed? Last time I tried the resolution was too bad to see anything on the remote end (local and test were fine)
@tuxflo Not sure _where_ you mean. Resolution may degrade in the browser due to bandwith. The stream, once negotiated, never changes:
> Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, q=2-31, 331776 kb/s, 30 fps, 30 tbn, 30 tbc
I had to compromise here. Cam can higher resolutions but the fps degrade badly in that case. It's simply at it's limit so the real webcam operates at ~800x600.
There's also "keep_format:1" that can be set on the video loopback device.
@bekopharm this is what the commandline of ffmpeg prints here too. However when using in Jitsi or similar WebRTC based app it looks way too pixelized like described here: https://github.com/umlaeute/v4l2loopback/issues/264
@tuxflo ouch. Is that your own preview or the remote?
I see you use x11grab. I didn't even think about this. Tried udp, rtmp and tcp streams and while looking good in preview they were 2-4 seconds lagging behind.
The obs-v4l2sink plugin really did the trick and ffmpeg just passes it through (in/out video7=>video8) without touching.
Has the nice bonus that when I stop the streaming (or obs crashes) the last pic in the buffer shows as still until I restart obs (and re-start the sink device).
@bekopharm this is the one on the remote end (second device I used for testing). My own preview looked good.
I also tried the OBS sink and stuff like Webcamdroid (which provide their own v4l2loopback implementation). None of them seemed to work...
I'll try it again when I got time (maybe on the weekend)
@tuxflo in that case it's as described in the ticket. It's the video conference killing it. There's a quality slider in Jitsi. If that doesn't work you've a bottleneck going somewhere.
@bekopharm yep, bottleneck somewhere might be true. I think the x11grab was neccessary because I'm using mutliple monitors and I just wanted to share a single one. But OBS can handle multi monitor setups on his own, doesn't it?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!