Video quality and resolution automatic scaling

Dears,
maybe a stupid question.
How does Jitsi select the video quality during a call?
Does it check bandwidth, CPU or what else?

I’m asking this because doing some benchmarks I couldn’t find the point.
Moving computers or smartphones in slow and fast networks I see no difference.
Using weak or powerful computers I see no difference.

I see H264 works better, but some guests have problems with their browser or computer, so I can’t enforce it.
Also, I can’t set minimal resolution to 720 as some weak computers are not enough powerful.

Any suggestions?

Regards

There is a feedback mechanism from the client to the JVB, where the client reports the sequence numbers of packets it has received. This means that the JVB is aware of which packets it sent that were not received. From this, it can calculate a % of packet loss. A higher % of packet loss indicates that the client’s available bandwidth is being exceeded (it can also indicate that the client’s CPU is overloaded for very low-performance clients).

When the packet loss exceeds a threshold, JVB will reduce the resolution/framerate that it’s sending, and keep doing so in steps, eventually even stopping sending video entirely for the least-recently-dominant endpoints, until the packet loss returns to normal levels. Once it reaches a steady state, it will try to slowly increase the bandwidth usage again (probing), increasing resolution/framerate and bringing back suspended streams, in case the loss was temporary, and as long as loss is not encountered it will move all the way back to the maximum bandwidth.

1 Like

Ok, thanks for information.

I updated my server on yesterday and, at the end, I found all the domain.config.js commented, including lines affecting resolution and quality.

I’m testing with a i7 computer and a Galaxy S20 smartphone, on 1000/300Mbps internet connections, and it keeps SD with very poor qualty…

Regards

The defaults should generally be fine, so it’s no problem that the lines were commented.

The speed the Internet connection is marketed at has no bearing on its quality for realtime audio/video. Even normal browser-based speed-tests are not very useful, because they mostly measure TCP performance, which is a good indicator of your speed when downloading a file, but can hide levels of packet loss and jitter that would be catastrophic for realtime communication.

You would need to measure the packet loss and jitter when sending a fixed bitrate between the client and server using a tool like iperf in UDP mode.

If you see no difference no matter the client connection you use, then you probably have a bandwidth or CPU constraint at the server side.

1 Like

Now I enforced 720p in the config.js, but it doesn’t care, it’s still SD with very bad quality.
Nothing changes enabling/disabling simulcast or h264.

Regards

What you set in config.js is still subject to your available bandwidth. If you can’t pass enough bitrate between client and server for 720p without packet loss, then the resolution will reduce.

I have a throughput of at lease 300Mbps one side and 30Mbps on the other side.
It can’t be a problem of bandwidth…

As I said, the speeds your connections are marketed at are irrelevant here. You need to do a proper speed test using UDP to verify the speeds your ISP / server provider claim.

Something like iperf?
Do you have suggestions about options or just UDP?

To test 5Mbit/s from server → client:

On server side:

iperf -s -u -p 12345

On client side:

iperf -c server.ip.address.here -u -p 12345 -R -b 5M -e -i 5 

Make sure udp/12345 is open on the server or change it to a port that is open. It will print output every 5 seconds until you Ctrl-C. The important values are packet loss and jitter.

2 Likes

Well, option -u is not valid on server and option -e is not valid on client.

Here’s server output:

-----------------------------------------------------------
Server listening on 80
-----------------------------------------------------------
Accepted connection from 192.168.25.74, port 1056

Here’s client:

C:\Users\Downloads\iperf-3.1.3-win64>iperf3 -c 172.16.0.229 -u -p 80 -R -b 5M -i 5
Connecting to host 172.16.0.229, port 80
Reverse mode, remote host 172.16.0.229 is sending

Nothing happens, I see no datagrams flowing…

Probably you are not using the same version as me, but as usual with most commands, you can use --help or the man page to find the relevant options.

If using iperf3 on the client, make sure you are also using iperf3 on the server.

Options for iperf3 would be something like:

Server

iperf3 -p 12345 -s -i 5

Client

iperf3 -c server.ip.here -p 12345 -u -b 5M -R -i 5

If you still have trouble, refer to the --help output or the man page.

OK, awful performances, I can’t get why being a i7 Intel® Core™ i7-6770HQ CPU @ 2.60GHz × 4 with 8GB RAM and SSD:

iperf3 -c 172.16.0.229 -u -p 10000 -u -b 5M -R -i 5
Connecting to host 172.16.0.229, port 10000
Reverse mode, remote host 172.16.0.229 is sending
[  4] local 192.168.25.74 port 57557 connected to 172.16.0.229 port 10000
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec  3.02 MBytes  5.06 Mbits/sec  1.698 ms  0/386 (0%)
[  4]   5.00-10.01  sec  2.98 MBytes  4.99 Mbits/sec  0.042 ms  0/381 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.01  sec  5.99 MBytes  5.02 Mbits/sec  0.042 ms  0/767 (0%)
[  4] Sent 767 datagrams

iperf Done.

Any suggestions?

This looks fine. No loss, reasonably low jitter. I would have run the test a bit longer to rule out some intermittent connectivity issue but apart from that, it looks fine. You can try increasing the bandwidth in subsequent tests to figure out what your connection is really capable of, but for a small call 5Mbit is plenty.

Next would be to check that your server is not overloaded during a call, run top or similar on the server during a call and look at CPU usage.

I have some doubts about the accuracy of iperf3 when using low volume of data. I just checked and on my 1Gbits/s link iperf3 returns 40 Mbits/s for b=50M and 950 Mbits/s for b=5000. This said I have not found a really good bandwidth test for UDP.

@gpatel-fr What about those numbers are you doubting? You asked iperf3 to send 50Mbit/s, and it reported 40, there is some overhead so a slightly lower number is not surprising (20% lower is quite a lot though, I guess you had some packet loss).

The metrics you should be looking at are loss and jitter, not the bandwidth values (which will just be approximately whatever you asked it to send, up to the capacity of your link, minus any loss). In UDP mode with a bitrate specified, it’s not a “speed test”, it’s measuring how reliably you can send a fixed throughput.

Yes that was it and that’s what I can’t understand about iperf3, why I had packet loss when I was asking for a speed far below the hardware capability, and none when I was asking for actually far more than the hardware allows.

You are certainly right about iperf3. Other tools are claiming to measure bandwidth using UDP and none are doing it reliably. That’s sad because most people plagued by firewalls won’t open TCP just to do a test so UDP is the only option readily available with Jitsi-meet servers.

That’s precisely why testing packet loss and jitter are so important. Many times I’ve seen connections advertised as supporting 1Gbit/s that can transfer something close to that with a TCP bulk transfer, but have unacceptable loss when sending only a few tens of Mbit/s with UDP.

As for your test results though, it might be worth repeating them a few times, or for longer periods. It may have been a transient issue. For example, if you run this test on a 2.4GHz Wi-Fi and then turn on a nearby microwave, you will often see packet loss and jitter spike very high while the microwave is running! Or it can be congestion that goes unnoticed on bulk transfers but spikes packet loss high enough to affect UDP. I once had a router in an outdoor cabinet, that would spike to 20% packet loss for just about 10 minutes every afternoon. Turned out the sun would be directly on the cabinet for just those 10 minutes, and the CPU temperature would get high enough that it would throttle and start dropping packets. Ruined realtime activities like video calls, but hardly noticed it with general web usage.

2 Likes

My memory tells me that I tried a few times (well, at least 2) but I tried it again this morning and you are right on the money, I got more logical results. Maybe I should not have been such a miser and forked out for shielded ethernet after all.