I would really appreciate a dev point of view about these questions.
Now I have been interested to test some parameters using the MCU:
So it's probably worth mentioning from the start that Jitsi Videobridge is NOT an MCU. It is an SFU (Selective Forwarding Unit). This is *very* important because it makes for all the difference in terms of scalability.
- CPU performances on the client side. Should I expect a gain using
A gain compared to what?
Compared to full mesh WebRTC conferences: Yes. In those scenarios the browser would typically create one encoding per receiver and this would be quite heavy on the CPU. Given the full mesh architecture though, you'd probably hit an upstream bandwidth limitation much earlier than a CPU one.
Compared to a regular MCU that mixes everything and sends it back to you as a single stream: No. But the small added client-side CPU efficiency of the MCU (compared to the SFU) comes at the expense of added latency, lower quality, *significantly* higher server-side cost, and degraded UX (not possible to switch to a specific participant).
- CPU/Memory performances on the server side. What is for you the
maximum number of client the server can handle at the same time? Under
It is very hard to say. It depends on bandwidth, topology (how many send and how many receive), stream quality, server configuration and many more. But, in order to give you a perspective we recently had the following data point from a user:
In a scenario with one sender and 180 receivers (i.e. the bridge decrypts one stream and then re-encrypts it 180 times) it uses
400 MBits of bandwidth on the server and on an i7 quad core the bridge was taking 30% CPU.
- Scalability of the MCU. If you would have to handle 1 000 000 of
users I believe you would distribute the load on more than one MCU.
Although on the documentation I don't see this scenario being
considered. What would be your approach in this case?
I assume these people are not all in the same conference (which would be a scenario we haven't much thought about right now) but if you simply mean 1 000 000 users in different conferences then that kind of scalability would depend on the business logic fronting Jitsi Videobridge. You can easily run a fleet of a thousand JVB instances and simply have to make sure that you take load into account before choosing one to create your next conference on.
- What is your evaluation of the stability of the MCU currently?
Jitsi Videobridge: *Very* stable.
Jitsi Meet: rather stable with some quirks now and then (but nothing that wouldn't go away after a page reload).
Hope this answers your questions.
On 28.05.14, 04:14, Regnoult Francois wrote:
On 19/05/2014 11:38, Regnoult Francois wrote:
Francois From Temasys
Francois From Temasys
dev mailing list
Unsubscribe instructions and other list options: