Jitsi on mobile internet 3g hsdpa vs google meet)

A question about working at low speeds with latency.
Testing work on the mobile Internet 3G HSDPA (3mbps/1mbps >50ms)
our test lab:
2 laptops, the first is connected via wifi 5Ghz, the second via 3G mobile Internet
We turn on the camera only on a laptop with 3G:
When making a p2p call, the resolution is from 180p to 720p with traffic consumption up to 1 megabit in peaks.
When p2p is disabled (in the config, or just by connecting the 3rd client to the call), the resolution drops to 180p with no chance of a return.
The issue is reproducible on our latest stable server,
reproducible on meet.jit.si and beta.meet.jit.si servers.
For the experiment, I checked the work of meet google under the same conditions - it quietly dynamically changes the card on the same channel with some kind of magic despite the number of participants.
googlevsjitsi
All settings are identical to the public server (vp9, simulcast etc)

Is that a screen-share or the camera?

1 camera only on one client (muted, no screen-share)

Then it should ramp up to 360p at least I reckon.

@Jonathan_Lennox maybe you can help debug this?

there are no errors in the logs. Only if there are problems with communication at all, you can get errors of lack of bandwidth

Can you check if the reslution drops between the sender and the server, or between the server and receiver. I suspect the former, because the sender is on 3G. Can you look around in chrome://webrtc-internals to see if you spot any interesting differences between the p2p and bridge case? Specifically anything related to bandwidth estimation.

reduces sender flow due to supposedly low bandwidth

p2p

FrameWidth 1280
frameHeight 720
framesPerSecond 11
framesSent 5888
[framesSent/s] 11.011012840000104
hugeFramesSent 16
totalPacketSendDelay 844.661
[totalPacketSendDelay/packetsSent_in_ms] 169.9166666666656
qualityLimitationReason none

jvb

frameWidth 320
frameHeight 180
framesPerSecond 23
framesSent 11091
[framesSent/s] 23
hugeFramesSent 111
totalPacketSendDelay 1673.121
[totalPacketSendDelay/packetsSent_in_ms] 9.526315789473795
qualityLimitationReason bandwidth
qualityLimitationDurations {bandwidth:611.948,cpu:0,none:318.729,other:0}
qualityLimitationResolutionChanges 80

did some additional testing:
turn off the simulcast - the quality and resulution without p2p rises, but switching the quality of 180/360/720 only affects the resolution - the traffic from the sender always remains static more than 1 megabit (in reference conditions on wifi)

This confirms that the limitations is the sender->server bandwidth, which is somewhat surprising because the calculation performed by the sender. The receiver, whether it is our bridge or the other laptop in p2p, just sends feedback about the packets that it received.

I don’t understand what happened when you turned off simulcast. Is it comparable to p2p or different?

Can you select the “legacy” mode in webrtc-internals (the drop down menu at the top) and look at the “bweforvideo” graphs? This will show the transmit bitrate and bandwidth estimation over the last 5 minutes.

disabled simulcast works as p2p (even with 3 clients in call)
when simulcast is enabled, the graph does not display anything.
In this test, the traffic is approximately the same everywhere.
With all tests, the camera is turned on only on 3G Internet.
In all tests, we see approximately the same channel utilization (through the same task manager).
In all tests, the channel speed rating is also approximately the same, either a red icon or a yellow one.
In worst case on p2p (or disabled simulcast) we met the frame rate drop to 6fps, but the resolution remained at the level of 720p

  1. p2p test - the resolution did not fall below 720p in 5 minutes
  2. 3 clients (one is broadcasting, two are watching) simulcast is on, the resolution has not risen above 180p
  3. 3 clients (one is broadcasting, two are watching) the simulcast is off, the resolution has not dropped below 720p.

repeated the test on a public server.
p2p gives a larger channel, the picture does not fall, when working through jvb the channel is clearly smaller, the picture often drops to 180.
But all the same, under equal conditions for estimating the channel without a simulcast, it is quite realistic to get 720p from a 400kbs channel
photo_2022-07-22_13-42-10

update: my server without simulcast resolution during this call sometimes dropped to 180p, but in most cases was 720p-540p.
So my question - is it possible to get similar work with simulcast on resolution with same bandwidth
photo_2022-07-22_13-53-47

one more remark: i disable simulcast - traffic is always tends to the maximum (about 2.5mbs) but resolutions is still decreasing during the call. It starts on 720p and after 10-20 min decreases down to 180p. After reconnecting - it starts again at 720p
image

CAn you try changing the default codec (in the server’s config.js) to VP8? Any noticeable difference?

not a big difference
image
the most interesting, there is a call at vp9, it starts working well even at 720 for about 20 minutes. After 20-40 minutes, the resolution gradually decreases. Even after 2-3 hours of the call, we make a connection from under the firefox and immediately get picture 720 on vp8. But after a few minutes it goes down again.

1 hour test, dropped from 720p to 540p, i thinks it some better
image
one more observation:
the web client on the phone is much more stable than the sdk. Although it would seem that the application should be more optimized than the web client…

I think VP9 uses more CPU which could trigger throttling earlier on a mobile device.

Did you test the app or SDK? What version?

sdk 6.0.0
so what we have:

  1. Disabling simulcast allows you to get a better picture on a less stable connection. Yes, it consumes more traffic, but no one needs a blurry picture with traffic savings). - in this conditions google meet show some magic with simulcast.
  2. For some reason, a mobile application requires more resources than a web client on the same device.
  3. We took an additional device Xiaomi pad 5 pro (870 snapdragon 6gb ram) - in the same conditions it worked for more than an hour at 720p. The question of what minimum device is needed for full-fledged work without throttling.

I remembered something.

In order for simulcast to work we use the software encoders. We tried to enable the HW accelerated decoders, but alas they crash a lot on Samsung devices. You might, however, give it a try by editing this line: jitsi-meet/ReactInstanceManagerHolder.java at 6e1e6df952a60ab365ec4376e08029c0bd44acbb · jitsi/jitsi-meet · GitHub and initializing the decoder like so: react-native-webrtc/WebRTCModule.java at 95cf638dfaeef35e678cca231228540e84e563f5 · react-native-webrtc/react-native-webrtc · GitHub

That might free up some resources for the encoder to continue at the high resolution.

1 Like

I think it’s more of a RAM issue than a CPU issue. Yes, and replacing a mobile device with a more powerful one closes the issue with good communication channels.
My main question is that with simulcast enabled, even from the web client on unstable communication channels (like 3g mobile), I get worse resolution than with simulcast disabled.
Maybe there are some ways to adjust the aggressiveness of bwe?