Call via the JVB (p2p.enable=false) doesn’t change the behavior of the quality (and Chrome’s AvailableOutgoingBitrate), only difference between the bridge and p2p is the indication in the Jitsi API. I have tested today with:
- PC1 on a fast internet connection (up/down 1Gbit/s) and
- PC2 on wifi a bit further from the router, but still a stable connection (all wifi bar’s full on Windows 10, up ~90 Mbit/s and down ~40Mbit/s):
Via P2P, the local indication on PC2 is about equal to the remote indication of PC2 seen from PC1:
Via JVB, same behavior wrt quality, the same local indication on PC2, but the remote indication of PC2 seen from PC1 is now suddenly much better:
This maybe caused by the JVB, telling PC1 that PC2 has a good connection, while it is actually poor. This doesn’t really bother us, it might have something to do with the false indication we noted before (Question 1 in my previous post)
The real problem (for us) and our theory on this:
What bothers us is the poor quality of many users in our one-on-one calls and I believe that this is not particularly caused by any p2p or one-on-one call related issue in our Jitsi config, but because of our users notice this much more because our API is always used in full screen mode. In a group calls with (much) more than 2 participants the majority of the users are in tileview and the poor connections are not really noticed. We have always two participants looking to each other for at least an hour and always in full screen view. In that case a 180p video will be noticed straight away and I assume that’s why we get so many complaints about the quality of Jitsi. I hope this theory makes sense, because I tried to prove it with some additional tests today. Sorry for the long texts, but we hope you can help us out on this.
I did some further testing today between Jitsi/8x8/our-own-server and Google Meet and the problem seems not to be related to Jitsi, but to the Chrome WebRTC AvailableOutgoingBitrate, which absolutely doesn’t represent the actual available upload bandwidth. It is much lower than the actual availability, especially when users have a slightly lower bandwidth, like our PC2 on wifi. Btw, it doesn’t matter if we call with Jitsi or with Google Meet in Chrome, the problem seems to be in the browser/WebRTC, not in the VC-software. Here’s for example our WebRTC log using Jitsi via 8x8 on PC2:
Seems to be a bit unstable, right? It seems that when the wifi is ok (or when using a cable connection), Chrome gives a stable availableOutgoingBitrate of 4Mbit/s, but when the wifi quality slightly decreases (but still a full wifi bar in Windows 10), this unstable availableOutgoingBitrate phenomena occurs. The result is that the Jitsi video from PC2 is continiously switching between SD (360p) and LD (180p). I thought that this was caused by the wifi connection of PC2, which might be very unstable and slow, but speedtest.net showed a stable 30-40 Mbit/s upload every time we test it. Same story as we hear from our users, telling us that their internet is fine (Zoom works very well, blah, blah.) but Jitsi quality on our platform is always poor.
We did another test with Google Meet and after a couple of minutes we noticed that the availableOutgoingBitrate went down to less than 100Kbit/s, like with Jitsi before. Immediately we started speedtest.net on PC2 and surprisingly it showed a stable 20Mbit/s, which we could also see in our network monitor on the right. Strange thing is that Chrome’s availableOutgoingBitrate remained low at the exact same time:
I have also added a screenshot after the test, where you can see that the availableOutgoingBitrate is continiously very low (causing Jitsi to send a poor 180p) while in the same time the upload speed is proven to be 20Mbit/s:
I did another test with Jitsi (8x8) and Google Meet in parallel and this showed that both VC-tools struggle with availableOutgoingBitrate on non-optimal wifi connections. For both Jitsi as Google Meet the quality of the outgoing video quality went exactly up and down with the availableOutgoingBitrate and not in parallel! From time to time Jitsi had a much better quality then Google Meet, and vice versa. Note that during these 5 minutes recording I ran speedtest.net several times, resulting in an upload bandwidth of 20-30Mbit/s each time. The wifi/internet upload bandwidth is perfectly capable to send 720p, so why does PC2 send 180p quality video?!
I repeated this on Chrome/Edge 94 and Chrome Beta 95 multiple times, all with comparable behavior, from time to time very low availableOutgoingBitrates while the actual upload speed is 200 times better. Question rises: how does Chrome measure the availableOutgoingBitrate???
Assumed conclusion and question:
Chrome’s WebRTC availableOutgoingBitrate measurement is far lower than the real available upload bandwidth when a wifi connection is less than perfect. Jitsi (and Google Meet) use this availableOutgoingBitrate to define the quality of the outgoing video, which results in unnecessary low quality.
Final question: When we exclusively work with one-on-one calls, would it be possible to improve this quality for Jitsi? For example by enabling layerSuspension, disabling multiCasting, changing the bitrates or the newBandwidthAllocationStrategy maybe?