Video conferencing with Jitsi

Posted Mar 24, 2020 11:38 UTC (Tue) by wodny (subscriber, #73045)
Parent article: Video conferencing with Jitsi

There is also an instance at https://jitsi.riot.im/ but I don't know if audio/video chat in https://riot.im/app/ is in anyway connected to that.

The Jitsi server package also has a not so pretty postrm script which fails on reloading HTTP daemons.

Jitsi Meet burns my CPU when conferencing with something under 10 people, but works with like 2-3 people. Skype seems more efficient but with many people or with video, keyboard input starts to malfunction and the system becomes sluggish and stays that way until Skype's restart. I hope for a keylogger so no chat is lost ;)

Also had to modify the Skype package before installation because it contains chrome-sandbox (installed as setuid binary of course).

Video conferencing with Jitsi

Posted Mar 24, 2020 12:06 UTC (Tue) by niner (subscriber, #26151) [Link] (4 responses)

There's a huge difference between Jitsi Meet with and without active video bridge. Without video bridge, all streams are peer to peer, so the more participants you have the more each client has to work and the more streams each participant's internet connection has to handle: O(n²). The video bridge bundles these streams on the server. This costs quite a bit of CPU on the server (but not terribly so) and obviously the bandwidth there, but it scales O(n) and works just so much better. I'm also quite sure that the video bridge is not active on meet.jit.si.

Video conferencing with Jitsi

Posted Mar 25, 2020 15:10 UTC (Wed) by sorokin (guest, #88478) [Link] (2 responses)

> it scales O(n) and works just so much better

I don't quite understand this. Even if all video streams get aggregated into one connection from server, that single connection still transmits n times the data.

My understanding is that total required bandwidth should be the same in both cases. Perhaps central server works better when participants' upload speed is limited?

Video conferencing with Jitsi

Posted Mar 25, 2020 15:23 UTC (Wed) by niner (subscriber, #26151) [Link]

It's quite possible that I misunderstood why the video bridge helps so much (which it does). It could simply be that the video bridge is a workaround for the Firefox issues mentioned in another comment. The linked hackernews discussion indicates that with peer-to-peer as soon as a Firefox user joins the meeting, performance is degraded for all participants.

It's also likely that you're right and the central server mitigates notoriously limited upload speeds of DSL and mobile (and sadly, where I live, even cable) connections.

Video conferencing with Jitsi

Posted Mar 25, 2020 15:41 UTC (Wed) by excors (subscriber, #95769) [Link]

From https://jitsi.org/jitsi-videobridge-performance-evaluation/ it sounds like the key for scalability is the "last N" mode. The bridge receives streams from all participants, but only broadcasts the streams from the N most recent "dominant speakers". That means the bridge's traffic scales linearly with the number of participants, and a client's traffic scales with N (which is a small constant).

If you don't use that mode then I think it's O(num_participants^2) on the bridge and O(num_participants) on the clients, though with better constant factors than peer-to-peer: each client only has to upload their stream once to the bridge (vs num_participants-1 times to every other peer), which is good since clients usually have much lower upload bandwidth than download.

Video conferencing with Jitsi

Posted Mar 27, 2020 21:00 UTC (Fri) by Sesse (subscriber, #53779) [Link]

I can understand why meet.jit.si doesn't; it uses 40% CPU just for sending on a measly 100 Mbit/sec of TCP! That's two orders of magnitude away from what an optimized web server does these days.