Checkout https://github.com/jitsi/jitsi-meet/blob/master/config.js there are options like disableH264 …
Good findings. Thanks for sharing!
Were your tests with more than two participants?
Yes, up to eight. One Sender and seven receiver with muted audio and video.
The case where it reports LD is sent and uploads 3K with vp8 in that case the video was turned off for some/all clients? And that uploader was FF, right?
Yes, the uploader was Firefox and the video was turned off for some clients.
I ran another test using the exact same scenario only with different jvb versions.
Test 1 with JVB 2.1-416-g2f43d1b4-1 (12.1.2021)
No log outputs mentioning bandwith suspension.
Test 2 with JVB 2.1-538-g062e9f56-1 (16.8.2021)
Frequently: BandwidthAllocator.allocate#359: Endpoints were suspended due to insufficient bandwidth (bwe=3188938 bps)
The overall user experience is way better with the January version. For example in classroom or live performance situations it is even essential.
So for the time being I switched back. Unfortunaly I can’t use the UI improvements which are very nice especially on mobile devices.
It seems that I am not the only one who is affected by it.
Is there any chance that this issue will be fixed? Can I do somehow help to make it happen?
Have you tried setting trust-bwe=false in the JVB config ? We had the same issue (BandwidthAllocator.allocate: Endpoints were suspended due to insufficient bandwidth) quite frequently, especially with Firefox, and disabling the bandwidth estimator solved it.
I was not sure whether simulcast works with bwe=false. But it seems to work.
When I turn off bwe and use Chrome as a sender it works. I’ll perform some more tests.
The problem with turning off BWE is that JVB won’t suspend endpoints when the receiver doesn’t have enough bandwidth to receive them, so users with restricted bandwidth may just face random packet loss (caused by sending at a faster rate than they can receive) instead of suspended streams. Random packet loss may even affect audio. Some suspended video streams are probably preferable to choppy audio.
trust-bwe=false may be fine in a particular environment where you are in full control of the network between all participants and sure of their connectivity. On the wider Internet or when anyone is using Wi-Fi, mobile data, etc, it’s a bit of a risk.
Hey @damencho, has this landed on meet.jit.si yet? Just yesterday I was testing something and the same problem occurred while live streaming with jibri. Jibri displayed the message “Video turned off to save bandwidth” even though my bandwidth was enough (in stats it said 2000 Kbps up).
On a related note, any ETA for new stable release?
Was that with Firefox on meet.jit.si?
Yes, this was with Firefox on meet.jit.si
Hi @damencho. Since some fixes for such bugs may take more than a few days to get into the stable release, what’s the recommended action for us, administrators of Jitsi systems? Rollback to the previous .deb package?
We believe all the bugs are fixed now Firefox stuck at 180p, Safari 13.1.2 not receiving media - Recent Unstable - #6 by damencho
You may update to that one or wait for pushing us that to stable … or you can revert for now to older version but I don’t think with older stable all the FF issues will be gone.
Hey everyone (@damencho) - our users are having their video turned off with the “Video turned off to save bandwidth” message in Chrome (Jitsi version 2.0.6293-1). We tried ignoring the bandwidth estimator as mentioned here.
It looks like most people experiencing this issue only observe it in Firefox/Safari. Does anyone have a recommendation to fix the issue in Chrome? Should we upgrade to unstable as mentioned here?
Also, if we do update to unstable, is the easiest method to just run
apt-get install jitsi-meet=2.0.6415, then update the other packages as indicated by the install script? Thank you!
Use latest from unstable
Perfect, thanks for the help I’ll follow the instructions you documented here in case anyone else is curious how to do that.
i still experience the problems described in this thread with Firefox on https://meet.jit.si/ aswell as on my own jitsi instance. I have the latest stable versions:
jitsi-meet/stable,now 2.0.6433-1 jitsi-videobridge2/stable,now 2.1-570-gb802be83-1
I still get the following in my jvb.log, whenever I am using Firefox:
BandwidthAllocator.allocate#326: Endpoints were suspended due to insufficient bandwidth (bwe=56280 bps): 950ab7a8
It seems that the issues are not resolved in that version? Will these issues likely be resolved in future stable versions? Should I just wait for that?
Until then I will be using an older version on an other server.