Follow

Spent half the night to wrap my head around this and finally getting somewhere with and and a loopback device so I can stream this "as fake webcam" over WebRTC in video conferences.

Getting this to run (and smooth!) on 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: beko.famkos.net/2017/10/27/son ) but(!) most WebRTC access out there is… flaky at best.

It e.g. always works on webcamtests.com/ but on test.webrtc.org/ basically only when I run FF with new/blank tmp profile reliable.

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: github.com/umlaeute/v4l2loopba

@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?

@tuxflo It does so just fine. In fact very good. My setup is unusual.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!