
- Jitsi security configuration form install#
- Jitsi security configuration form full#
- Jitsi security configuration form plus#
- Jitsi security configuration form download#
This is why I try to find an MCU solution in foss.

In any case Jitsi with SFU can not handle nicely any group above 10 with the networks we have here.
Jitsi security configuration form download#
At my home I have 16Mbps download and about 768 Kbps upload. Download is descent but upload is very low. And as you describe it, it is not as good. In Greece Deutsche Telekom, the German company, owns the telephone network. With Jitsi we can not pass the 8 or 10 participants. Zoom never has a problem, except sometimes with latency but rarely. We use them in the University that I work with our own servers for Jitsi and pay service with Zoom. Other than that there is experience with Jitsi and Zoom. For such things we look the order of magnitude and this is n^2 for both. And the difference between n^2 and n(n+1)/2 may be considerable for small n but it is unimportant for big n. I probably do not know much about how it works. *in Theory, but we have an upload/download injustice in Europe with a potent download and a small upload Its not a big issue.Įdit: 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* 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.Īnd with more watching folks, if not on the big screen, the avatar picture got smaller and smaller. 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. 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). And myself and some other are the small picture in the difference for each. Because for 10 folks, a Group of 4 and another 4 will have the same stream, with just 2 differences … in each group.
Jitsi security configuration form full#
(Because for small groups Jitsi looks currently optimal and there is no much to ask there).ĭo 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.Īnd if others got the (n+n) stream, it can be broadcast to the others as well.
Jitsi security configuration form install#
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? So having a powerful server you take care of the low bandwidth a user may have, so the user has a better experience.Īs a consequence SFU looks best for small groups but MCU is better for large groups.
Jitsi security configuration form plus#
So now the server has to handle 2n streams plus the cpu power to multiplex and each user handles only 2 streams.

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. 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. ( n+n(n-1) = n^2 ), and each user will have to handle n streams. So the SFU server (like JitsiVideobridge or Element Beta 3) will have to handle exactly n^2 streams 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.Īn SFU server will still have to send order n^2 streams (precisely n(n-1) streams) and receive n streams.

The enterprise version uses SFU but I just realized that the “correct” method is MCU (multi control unit)for large groups.
