Zoom has changed the Terms of their license and they now use peoples data to train AI without giving the possibility to users to opt out (admins can opt out, users can not):
Is there another way to conferencing? I have been using Jitsi but for large meetings it can not beat zoom because the number of network connections grows as n^2, where n is the number of users. Zoom multiplexes the strems so the total connections to the server remains at n (or n+1).
Is there a foss alternative that multiplexes the streams?
I just know Jitsi, BigBlueButton (I don’t know if they use Jitsi or something own) and Matrix. For Jitsi I know that issue and heard that it works well if not all stream videos together (so always speakers enable videostream, others do not). I don’t know where you need it, but that could be an option for school classes for example.
Matrix in Element has a new solution and I’m not familiar with it yet. If you want to keep a look into it, please give a feedback, I’m also interessted in.
From my own experience Element just integrates a Jitsi call for videostream into a chat. You need to close it manually later on for example even if nobody is connected anymore. I also experience the same issue as with Jitsi itself (limited bandwidth for video because of it’s meshnet P2P topology).
But maybe it depends on the Matrix server how it’s implemented though.
You’re outdated. They already implemented an own solution - that’s not totally finished yet. Jitsi was in past. For desktop streaming I had no sound last time I tried it, video call worked fine so far. But I didn’t test group video calls.
I see. It seems to be in beta now and the matrix server I use is not using the latest release, I assume. So that explains it.
Well, I hope it works better. The E2EE shouldn’t be the most difficult part actually but solving the bandwidth and latency issues (at least if it’s a decentralized solution). If they go for a more centralized approach routing everything through the matrix server, it could limit the ability to host your own matrix server depending on your users. ^^’
The link I gave you describe what they have done until last year (is not an up to date blog post) and where they want to go. I shared it for a little overview.
About Jami again we have the same problem if I understand correctly. Jami is P2P, so if we have a conference of n users, each user must open n-1 network connections. A total of n(n-1) connections, which is of order n^2. This is too much for a group of say 25 people.
With zoom the client opens a stream to the zoom server and gets back a multiplexed stream of all participants, which is of order n^1 and not n^2.
So an organization, say a University, can not escape zoom for large groups even if it is willing to install its own server. There seems to be no such “product” in the foss world. And since zoom does not allow users to opt out from analysis of their data, we are trapped.
Element seems to follow the same route. Too many streams.
As I said, I never tested it (and don’t even know where I could). But as I read, it’s online. You may have to enable the beta for it in options menu. Better you research for it by yourself since I’m also not completely up to date.
Next cloud is still P2P. The enterprise version uses SFU but I just realized that the “correct” method is MCU (multi control unit)for large groups. The pros of SFU (selective forward unit) is that the user can do things like mute a user, or organize his screen the way he wants but there is no network advantage.
An SFU server will still have to send order n^2 streams (precisely n(n-1) streams) and receive n streams. So the SFU server (like JitsiVideobridge or Element Beta 3) will have to handle exactly n^2 streams
( n+n(n-1) = n^2 ), and each user will have to handle n streams. When you get to 25 participants you already need 25^2=625 streams for the server and 25 per user, and 30 participants require 900 streams for the server and 30 for each user. This is too much.
With MCU (and I guess zoom is using this method) the receiving n streams by the server are multiplexed in one video that is streamed back to the users. So now the server has to handle 2n streams plus the cpu power to multiplex and each user handles only 2 streams.
So having a powerful server you take care of the low bandwidth a user may have, so the user has a better experience.
As a consequence SFU looks best for small groups but MCU is better for large groups. So I need to modify my first question: is there an MCU Video Conference tool in the FOSS world that an organization can install and use?
(Because for small groups Jitsi looks currently optimal and there is no much to ask there).
I informed myself right now what’s the difference between MCU and SFU (didn’t know until now). And MCU merges all streams together to a single stream. Bandwidth-wise it makes most sense, yes. On the other hand it also takes most CPU-power to run and the technique is most complex one. Also E2EE seems to be not possible (only transport encryption). I don’t think there is a FOSS solution right now.
However, I think there should be a way to lower resolutions of every stream to save bandwidth in a way that SFU has not to deal with much more than MCU. Let’s say each user (9 in total) send to MCU 1080p video streams and server merge them together to a single 1080p stream … why not just send 360p videos from each user to SFU server with a total amount of data of a single 1080p stream plus a very little overhead of metadata etc? In my opinion this should be the most efficient way for the server and not much worse for users.
Do you know how broadcast work antonis? With one more addition stream, you have to half the transmitted resolution, or have a one big for all screen, delivered to all in full resolution.
And if others got the (n+n) stream, it can be broadcast to the others as well. So you have maximum a n/2(n+n) Stream. Because for 10 folks, a Group of 4 and another 4 will have the same stream, with just 2 differences … in each group. And myself and some other are the small picture in the difference for each. So 25 participants have just a broadcasted stream by 12,5 for each and tow differences for self and counterpart (by a parted broadcasted share by two).
You have to handle out two groups for that in the first part, and each group calculate together by p2p what mixed picture for others will be generated and broadcast with the other group. The other group do the same, and afterwards just the client self picture got added in real time to its real time broadcast frame, the others got just a some ms copy of that sound and picture from the past.
And with more watching folks, if not on the big screen, the avatar picture got smaller and smaller. Its not a big issue.
Edit: And by Broadcasting a listening client in a p2p group can receive the information form additional group of senders… which got that information so it will increase the speed with more participants*
*in Theory, but we have an upload/download injustice in Europe with a potent download and a small upload
It’s in first case an issue of our old German networks where we often have no glass fiber. In glass fiber both signals (up and down) can have same speed, but DSL shares upload and download and because of that download gets prioritized, because users mostly need more download.
People who have access to glass fiber (luckily me too) have 2 options: pay less for different speed or pay more for maximum speed for both. At this point it’s just a matter of capitalism.
As far as I know it’s better in some other EU-countries. But our politicians in past create this issue for Germans.
I probably do not know much about how it works. However, I know some Mathematics. And the difference between n^2 and n(n+1)/2 may be considerable for small n but it is unimportant for big n. For such things we look the order of magnitude and this is n^2 for both.
Other than that there is experience with Jitsi and Zoom. We use them in the University that I work with our own servers for Jitsi and pay service with Zoom. Zoom never has a problem, except sometimes with latency but rarely. With Jitsi we can not pass the 8 or 10 participants. At 8 it already has network problems
In Greece @Ick Deutsche Telekom, the German company, owns the telephone network. And as you describe it, it is not as good. Download is descent but upload is very low. At my home I have 16Mbps download and about 768 Kbps upload.
In any case Jitsi with SFU can not handle nicely any group above 10 with the networks we have here. Zoom on the other hand does a nice job. This is why I try to find an MCU solution in foss. The same issues appear with the public Jitsi servers. It is not a bad configuration of our own University servers.
