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 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)
@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?
chaos.social – a Fediverse instance for & by the Chaos community