Jitsi-meet: Improve bandwidth management

[mvglasow]

Steps to reproduce:

1. Use an ADSL connection with 3 Mbit/s down, 786 kbit/s up; client connected to router via Ethernet cable (to rule out radio interference on wifi)
2. Start a meeting on meet.jit.si using the web client
3. Have someone else on a different connection join the meeting
4. Set call quality to LD

Expected behavior:

• Smooth experience with low latency.
• Some spare bandwidth to access other web services (e.g. IMAP, Google Drive, web browsing) and still get decent response times.
• Call quality affects the video stream I send as well as the one I receive
• If bandwidth is insufficient, video and audio quality are automatically reduced to prevent overloading the connection

Actual behavior:

• Latency is quite high. If the other end uses a loudspeaker, I hear myself with several seconds of delay.
• Jitsi Meet seems to max out my bandwidth (if I monitor bandwidth, upload rates seem close to the limits of my Internet connection). Other web services become unusable; even simple web sites take an unacceptably long time to load.
• Call quality only seems to affect what I receive from others; my own video stream always seems to go out in HD (outgoing bandwidth is much higher than incoming)—despite the bottleneck on residential Internet connections typically being upload.
• No apparent adaptation to bandwidth.

Software used:

Ubuntu MATE 18.04 (64 bit) with all patches installed as of June 8, 2018.
Firefox 60.0.1
https://meet.jit.si with web client (as of June 8, 2018)
The other end used Windows and Internet Explorer (versions unknown).

Additional information:

The first step in addressing this would be to monitor bandwidth usage. Something like this seems to be in place already (there’s a little badge in the participant image indicating connection quality). When bandwidth usage approaches available bandwidth (connection quality decreases), adopt bandwidth reduction measures such as:

• Increase video compression (at the cost of compression artifacts)
• Reduce video frame rate
• Reduce video resolution
• Increase audio compression (at the cost of compression artifacts)
• Reduce audio sample rate
• As a last resort, suspend video

My recommendation is that Jitsi Meet should never consume more than about 50% of upload and download bandwidth (measured separately for each direction) for more than a few seconds.

As a stop-gap measure, giving participants more control over what they send (i.e. the above parameters for their outgoing video and audio stream) would alleviate the issues on low-bandwidth connections.

[c526537207]

I have the same problem with the jitsi that reducing bandwidth is necessary, and we can discuss the specifics together.

[Ark74]

IMHO you should run the jitsi-framework (jicofo/meet/vb/etc) on a dedicated connection.
Preferably on a VPS which datacenter is closer to you or your user base at least on the same country / continent with known short ping response.
Since RT communications is not the usual http static traffic, so far my complain is that Jitsi won't allocate enough bandwidth so I believe we are on the opposite side of the coin.

Cheers!

[reetp]

I agree with @mvglasow that there should be some controls for setting/fixing the bandwidth.

We too have low bandwidth connections - downstream isn't too bad but, as ever on old slow ADSL, the upstream is the limiter.

Yes, you can set it on the server in /etc/jitsi/meet/your.server-config.js but it would be better for the room admin to have some control.

@Ark74 this is not a server side issue per se. I have my Jitsi server on a sufficiently powerful central server. The issue is with the bandwidth of the clients. No amount of server horsepower will cure that.

I think it may be made worse when the two ends have varying bandwidth and the server is trying desperately to second guess what is the best rate for both.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[reetp]

Why won't fix?

It is clearly an issue.

[reetp]

Still no comment from the devs on this?

[saghul]

Our approach to bandwidth adaptation is to do it dynamically, by estimating the available bandwidth and using it.

There is now a possibility to manage the call quality and request lower quality for other participants, though this doesn't yet affect the sent bandwidth.

I don't see more manual bandwidth controls happening here. While I understand some (a small minority AFAICT) may want them, that's not something we plan on pursuing.

[reetp]

That's regrettable when your algorithms simply don't work well.

Not everyone has great bandwidth, particularly upstream with the asymmetric nature of ADSL. Quite possibly your 'small minority' are the only ones who actually bothered to try and make it work - perhaps the rest decided it was too much trouble and just used another medium and never bothered to tell you.

And ironically you DO allow manual control via the conf file - it's just a pain to have to keep trying to adjust it. So why not allow modifications to that from the interface? It just doesn't make any sense.

Turn off dynamic bandwidth, enable manual bandwidth, and choose your speed limits.

This isn't exactly rocket science so I can only presume that there are other factors at play here.

[saghul]

That's regrettable when your algorithms simply don't work well.

Not everyone has great bandwidth, particularly upstream with the asymmetric nature of ADSL. Quite possibly your 'small minority' are the only ones who actually bothered to try and make it work - perhaps the rest decided it was too much trouble and just used another medium and never bothered to tell you.

It's our choice. We keep working at it to make sure it works as expected. When did you test it last? Your own deployment or meet.jit.si.

And ironically you DO allow manual control via the conf file - it's just a pain to have to keep trying to adjust it. So why not allow modifications to that from the interface? It just doesn't make any sense.

What setting do you mean, IIRC we don't allow for setting "X amount of uplink / downlink".

This isn't exactly rocket science so I can only presume that there are other factors at play here.

It's not rocket science, but it's also not as easy as you put it.

[reetp]

Last tested just before Christmas I believe, on my own deployment. Just tested the install again this morning and it is all over the place. The bandwidth numbers it seems to guess are completely wrong.

Re limits, I was mistakenly referring to trying to limit the Video Quality/Size via the conf files.

Unfortunately trying to upgrade seems to show you have swallowed the systemD KoolAid. This commit around 4th Dec refers:
https://github.com/jitsi/jitsi-videobridge/commit/7bac711f02e2799dd1efba69d73047c288965b4e

Clearly deb packages weren't released for a while after.

Forced systemD dependency with no apparent reason for doing so or increase in usability is a blocker so I'll use something else instead thanks.

[saghul]

@reetp You seem to just be looking for anything you can pick on at this point, so I'm going to stop here.

We have made several stabkle releases since then, and they are available in our Debian repo.

Of course, feel free to use whatever tool best suits your needs.

[reetp]

It wasn't my bug - I was following up on someone elses as I experienced the same issue during testing.

I don't 'pick' on things. An issue was logged. Devs effectively say 'it works wonderfully'. In my own experience that was incorrect.

I wanted to follow up further with some tests to try and see if there is a potential resolution but can't install updated packages on my system due to dependencies that serve no purpose (init support could have been left in and no hard dependency on systemd - just add a unit file for systemd users)

Note I was looking at this as we use Rocketchat, and Rocket want users to move to using Jitsi for video calls/conferences hence testing.

If there are issues with bandwidth management it may affect a lot of people, particularly if those issues are caused by problems with upstream bandwidth that cannot be manually be managed, and it will be irrelevant whether they use meet.jit.si itself, or a self hosted instance.

I'll leave that with you.

[reetp]

FWIW I managed to manually hack together an updated instance so running current versions to test.

It's still extremely poor.

Ability to fix the video size/quality would probably help but that can only be done manually via the config files.