That's why this week we're trying a #JitsiMeet instance hosted locally in our country by a community member. It *still *has too much lag to be useful.
Yet, all the centralised videoconf services have no problem keeping up on exactly the same network and computers in this building.
So, what's Jitsi Meet doing differently that makes it so laggy, and can it be markedly improved?
@Matter @bignose @klaatu No, it doesn't work like that. It just don't mixes the video channels into a composite video stream, instead it relays the recieved video channels to all call participants. Doing so allows to have unexpensive videocalls which can run on simpler hardware and have low latencies. But it does need a server and a good bandwidth on it.
@Matter @bignose @klaatu Maybe this. Also if a user has a bad internet connection quality will not be any good (as expected). A solution could be trying to use an instance which has the server closer to your location. As far as I have tested, quality has been really good for all users (I tested it with 4 users, no more).
@renor @Matter @bignose @klaatu In my tests it started crapping out at about 15 participants, about half of which had video enabled. That was after changing server side config to downgrade max quality video upload from 720p to 480p (this is more effective than all participants setting their video quality to SD since that only affects download quality, not upload. VPN bandwidth seemed to be the bottleneck; the VM hosting the bridge was running at <50% CPU and ram.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!