You can always extend capacity by adding more bridges.
Short additional Question - is the number of participants & stability of the conference call only a server side topic? Is there any limit on client side also?
We are doing also improvements on the client side when working on big conferences.
Can you suggest a server configuration you think it could support up to 200 participants?
@damencho How does Jitsi handle video streams from participants that are off screen for the presenter at any given moment? Generally, the maximum number of streams that can feasibly fit on the screen would be about 6 or 7 in the active speaker with thumbnails layout and maybe 10 to 15 in the grid layout. For most applications, it would be perfectly fine to have Jitsi broadcast to the audience only those streams the presenter can see on the screen. Wouldn’t it make sense for Jitsi to at least provide that option to significantly reduce the server loads? Basically, such a solution would be far more easily scalable, since the amount of video data that needs to be pulled in from the users would never exceed the number of visible streams. On the transmission side, of course, you will still have to send the video to all the users, but at least the downstream volume would be sharply reduced.
My other question is whether jitsi routs the multiple streams around individually or combines them on the server and then sends them out as a single stream to each user. Again, if you already have a server that’s acting as a middleman, wouldn’t it make sense to reduce parallel packet processing at the source?
I am wondering about this too, so your experience is helpful.
I wonder if by using a private link in YouTube the stream could be embedded into a LMS, where it could tied to the chat or discussion functions there?
Would this enable a greater number of participants in a conference?
According to the performance evaluation (https://jitsi.org/jitsi-videobridge-performance-evaluation/), ‘1000+ video streams’ is theoretically possible - it is unclear if that is a single conference, or many conferences.
Freifunk München Jitsi Server Setup kindly shows stats through Grafana (https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1&refresh=1m) and this shows over 300 participants using the cluster from time to time however rarely over 40 per conference.
Yeah, I think that link is highly misleading. From our own testing, we can easily cause 100% cpu usage on an i3-8100 CPU (comparable to the E5-1620 v2 being used in the above link) with only 25 participants in a single conference. I was pretty disappointed with these results, considering the page advertises 1000 streams at 20% cpu usage and 500+ mbit/s on that Xeon CPU. We could not even come close to these results.
I mean, with 25 users, if what I understand is correct, every user uploads 3 streams (video in different qualities) - so 25 * 3 = 75 incoming streams. Output should be only 1 stream per user, so another 25 streams totals 100 streams - and with that we already reach CPU capacity. That seems a far cry from the advertised 1000 streams with 20% cpu usage on a similar CPU…
Maybe our setup is faulty? We are running a simple debian installation with the jitsi docker image. It is VMWare esxi virtualized, but there is pretty much no other VM running on this machine…
/edit: Sorry, I made a calculation mistake. I assume that currently jitsi sends a stream of every person in the video chat (thumbnail video streams plus one big stream) to a client. So that means, 25 * 3 incoming streams and 25 * 25 outgoing streams which is 700 streams. I mean, that’s already closer to the 1000 advertised streams but the CPU usage is still far off. Anyways, I agree that some sort of mechanism to only send streams i.e. of the last 10 persons that have spoken would solve a lot of problems with big conferences. It would also clean up the UI for large conferences.
is it possible to configure YOUTUBE_URL in jibri to use a custom rtmp server like a selfhosted nginx-rtmp?
I, too, would like to show my support for a general rtmp option instead of the “insert Youtube key” for livestreaming. Why is there a need to tie an open-source project to a proprietary solution like Youtube? I mean Youtube also gives you an rtmp server URL.
JVB seems to only run on one CPU therefore that looks to be the limiting factor. We are setting up load-balancing (https://github.com/jitsi/jicofo/blob/master/doc/load_balancing.md) next week to see if this spreads one conference over many JVB therefore many CPU, enabling use of all of the cores - the documentation is fuzzy on this.
Follwing this, an Octo configuration (https://github.com/jitsi/jitsi-videobridge/blob/master/doc/octo.md) to spread load between our sites.
There doesn’t seem to be any other bottlenecks from our experience outside JVB.
I had a pretty similar question than @sjm . In a completed in-house hosted solution (including with multiple Xeon/EPYC servers if necessary) would it be possible to have more people in the same conference ?
Or even the Jitsi hosted solution with Videobridge has the limitation where all participants of the same videoconference must be handled by the same server ?
With regards the UI in a large conference I believe it doesn’t need to show all participants at the same time, but just those who are either speaking or spoke more during the conference.
Hello, I must teach online at the university. My students are between 60 and 70. I am the only person who would speak. They would have their microphones and cameras turned off. Do you think the experience could be successful?
I too would like to know what kind of hardware would be required to host a meeting with about 700 participants.
@Sh3nron - there are several potential roles, you could have one speaker and many watchers, like a broadcast, or you could have a panel who interact with each other.
It may be that the watchers communicate with the speaker or panel via electronic means, and maybe they have the option to join in by invitation. It is unlikely for any situation where there are 700 people all with camera, and talking together. It may be that some only require audio, or that there is a screen-share taking place.
Please clarify which roles your ‘participants’ might have - could everyone talk or do you have a few people presenting and many people listening? This helps work out the configuration that would suit you, and how Jitsi could help with this.
@jitsiuser2 - that seems straight forward. The performance challenges seem to be based on the quantity of video streams so this would be reduced to only send yours. You can also set lower quality video in your settings which would help further.
With some small development on the clinet, you could create an interface where the students have no option to turn on the camera or screenshare.
One meeting with 700 participants, currently is not possible. This sounds like you just need livestreaming.
we have tested with 55 participants and the network kept disconnecting but it was running Jitsi old version and I did try install multiplay JVB on Jitsi old version but It was not success.
So I would like to try multiple Bridge (JVB2) on new Jitsi Version. So anyone has the JVB2 installation document.
I am working on a solution:
- Normal users are both radio and video muted by default, with hidden microphone and camera button.
- Only moderator and allowed user can open their microphone and camera in the meeting.
By this way only several tracks are real payloads. It is still needed to test if it is possible to break the hard limit of 75 participants in a meeting.
How can you make the users of a room have the camera and microphone seized by default?
Let us know if you found a good solution for this - sounds super interesting