Maximum number of participants on a meeting on meet.jit.si server

We have seen today in a conference with 60+ users on a jvb2 on a powerful server (8 cores):

Jicofo 2020-03-31 09:54:14.622 SEVERE: [1115] org.jitsi.jicofo.SSRCValidator.log() Too many sources signalled by 8efe0c3f - dropping: ssrc=1942396848
Jicofo 2020-03-31 09:54:14.640 WARNING: [1115] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Not sending source-add, notification would be empty

maxSourcesPerUse are defined in jicofo/JitsiMeetGlobalConfig.java

    /**
     * The default value for {@link #maxSourcesPerUser}.
     */
    private final static int DEFAULT_MAX_SSRC_PER_USER = 20;

   /**
     * The name of configuration property that sets {@link #maxSourcesPerUser}.
     */
    private final static String MAX_SSRC_PER_USER_CONFIG_PNAME
        = "org.jitsi.jicofo.MAX_SSRC_PER_USER";

So does it make sense to increase this value in the jicofo settings?

3 Likes

This means that one endpoint advertised more streams (ssrcs) than the limit. It’s likely a bug somewhere, I don’t know if it’s related to the size of the conference. You can try to work around it by increasing the limit, but that’s not a long term fix.

Boris

1 Like

Hey there,
hows the scenario if voice only without video, is jitsi able to handle up to 100 participant? or less than 75 participant (max 35 participant) ?
thanks, regards

100 should be fine, I think.

4 Likes

Hey Demencho,
Is there any maximum participant or limit if we use voice only?
Thanks,
Regards

You can always extend capacity by adding more bridges.

1 Like

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.

5 Likes

Can you suggest a server configuration you think it could support up to 200 participants?

2 Likes

@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?

3 Likes

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?

1 Like

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.

3 Likes

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.

1 Like

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.

2 Likes

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.

4 Likes

Hello @damencho
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.

1 Like

@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.

1 Like

@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.