[jitsi-users] "Video turned off to save bandwidth" on meet.jit.si

I further investigated the issue and want to share some insights.
It seems that the problem is related to streams sended via Firefox.
I testet the following browsers for sending video: Firefox Desktop,Edge Desktop,Firefox Mobile and Chrome Mobile

The following image shows the normal behaviour using Edge Desktop browser as sender:

When using Firefox Desktop as a sender it looks like this:

Especially interesting is the high bitrate even when sending LD quality.

Here the results using mobile browsers as sender:

Performing the same test with Firefox mobile reveals the following:

It seems that when using Firefox as sender the bitrate is not properly propagated, which could probably lead to wrong bandwidth estimations and even turned off video streams.
Moreover Firefox mobile uses the H264 encoder. When I remember right simulcast is not possible with H264. That is, it is not possible to degrade quality to save bandwith. The only option in this case is to turn the transmission off.

Would it be possible to
A: properly propagate the bitrate with Firefox?
B: prevent using H264 for Firefox Mobile?

I think both would produce a more consistent user experience.


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.

1 Like

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.

1 Like

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?

Not yet.

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.

1 Like

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 :slight_smile: I’ll follow the instructions you documented here in case anyone else is curious how to do that.

1 Like