Jitsi meet performance: comparison to hangouts, teams and bigBlueButton

I’m currently testing different platform for videoconferencing. In particular, I’m comparing jitsi, hangouts, teams and bigBlueButton. According to this, jitsi should support at least 200 users and up to 1000 video stream with private instance. By using the free instance of jitsi, I found that it does not work very well compared to hangouts and teams.
Is it a problem limited to the public instance? Is there something that I can set up.
Thank you


What is the problem you see? What browser do you use? How do you test? What is your comparison based on?

1 Like

I see almost continuous disconnection problems. Maybe they are related to heavy load of the server. I tried with brave, firefox, opera and chrome. I’m testing a conference room of 20-40 users. The comparison is based on accessibility of the conference by the users.

When did you last experienced it?
We had load problems the last few days and today everything seems fine, although we are still working on it, improving and monitoring.
But the last week we had a lot of reloads, especially during the European day and on the European shards.

In the last week. I’m in Europe. I will try again in the next days and I will let you know.

Yeah we had problems in Europe due to the extremely heavy traffic, should be fine now. Check the recording of the community call from Monday for more information.

I tried again and it was better than last week. However, I could not have a good experience with a conference room of 20-40 users plus a speaker with a single video/shared screen. What are the bandwidth (download/upload) and jitter requirements?
The performance test used 515 kbit/s per endpoint. Is this the minimum number even with low definition quality?

Mind that performance test was done 5 years ago and many things had changed since then like that is not using simulcast.
Not sure about what requirements are you talking? The requirements are that you need a good (5mbit) upload to send a video, if you want to send 720p and another 5 for download for the main speaker and let’s say 200k for every thumbnail, these are very rough estimates.
How did you do the test? How much of those participants were senders? Where were those located? Did they had enough bandwidth? Were they on wifi or wired? Asking as if they are in the same location local bandwidth maybe a problem, a problem we had seen, sometimes.

1 Like

I’m talking about bandwidth requirements: for instance hangouts has minimum of 300 kbit/s while teams has a minimum of 500 kbit/s.
My setting is one sender/speaker that shares its desktop so just one video at low definition and 20-40 users audio only (muted if they do not talk). All the participants are located in the same region and country in Europe and have a ADSL connection (good downlink and bad uplink).
I noticed that jitsi quality is comparable with teams (slightly better with video), but worse than hangouts.
A possible explanation is that hangout is using VP9 while teams h.264 codec: VP9 is comparable to h.265.
Does jitsi will add support to VP9?

Yes, we will resume vp9 work when times permit.


Thank you. Do you have any roadmap? Do you confirm that jitsi is using VP8 and requires a bandwidth around 500 kbit/s as h.264?

Yes it is using vp8.

1 Like

damencho, I’m also using Jitsi for our deployment on our own infrastructure, and had a user attempting to run a 34 person workshop in Europe. Reported high rate of disconnects and reconnects.
Once the workshop lost a number of people due to instability and landed on 24 people, the stability and video and audio quality was reported to be better.

We are running on a Last N config and checking out our servers the network and cpu utlisation didn’t go above 50% of allocated capacity, all users connected through a european JVB.

We will be investigating to see if we can do anything from our side

Ignore the above–
Analysis of our logs found no issues. Also browser analysis found that the browsers having connect issues were primarily Safari, IE and Edge.

1 Like

Great news!

Do you have a time frame of when it will be available?
What about JVB2.0 will/does it support VP9? If not, what is used on the new bridge? VP8, H.265 or H.264?

Appreciate your great support :+1:

There is already an issue on github about adding VP9 codec support to JVB v2.0.


Hi erotavlas,

thanks for the link.

So JVB2 does not support VP9 yet. But it might be in the future. Is there a time frame?

However, what codec is instead used? H.264, H.265 or VP8?

The codec is VP8. I do not know about the time frame. I hope as soon as possible since it is very important to have VP9 support.

yes, I agree! Hopfully it will be very soon.

Until then, I see in the Config a option to enable H.264. To get the best performance and lowest latency, what would you recommend to use, VP8 or H.264?

In case H.264 would be the better codec in is enabled, would there be any performance brake due to any interpreting job between the codecs at server or client side?

VP8 and H.264 belong to the same generation of codec. From the point of view of performance (bit rate and perceived quality) there is not a great differences. Moreover, VP8 is free while H.264 requires to pay royalties.

P.S. you can have a look at VP8 vs VP9 with WebRTC.

1 Like

I have been testing several video conferencing systems over the last two weeks.
Jitsi-Meet using jit.si was very poor. Two people were unable to hold a steady conversation with video. The fourth and fifth people could not join.

I tried Skype, which was better but not good with only two connections. I then loaded jitsi-meet on to a dedicated server here in the UK and the performance was similar to that with jit.si.

Finally, I tried Zoom. It was impressive - eleven connections and no problems.

Zoom appears to use H.265.

Please accelerate the adoption of H.265 or VP9. It is vital both for competitive reasons and to help people during this Covid-19 pandemic.

Devices used on the calls were Linux Mint, Mac, Windows, Android, iOS. Browsers were Safari, Edge, Firefox, Chrome, etc.