Jitsi-meet: Enable resolution constraints on mobile apps (iOS/Andriod) to save bandwidth.

[Moltey]

Hi Jitsi Team,
thank you for your great tool! My jitsi server has limited upload bandwidth to the Internet - therefore, I would love to limit the data to be forwarded by videobridge2:

Resolution constraints are working fine in browsers. However, I realized that properties set up via the meet config.js are not recognized by the mobile applications (neither in iOS, nor in Android):

`

resolution: 360,

 constraints: {
     video: {
         aspectRatio: 16 / 9,
         height: {
             ideal: 240,
             max: 360,
             min: 180
         }
     }
 },

`
Consequently, I kindly request to implement a check on these values in the mobile apps to limit the data to be sent to (and forwarded by) videobridge.

Alternatively, it would be great to have an option selectable in videobridge to only forward low resolution streams to the clients to improve connection reliability.

Thanks & best regards

[bcostescu]

A related issue is that the mobile apps only offer the option 'Enable low bandwidth mode' which switches off video, but do not offer the intermediate resolution choices available in a browser.

[Fahad-Alsaidi]

I confirm this bug.

[saghul]

Mobile should be honoring the "resolution" option these days.

[bcostescu]

@saghul: tested with current stable iOS app version 20.2.1 build 68 and with the current stable packages on the server side (jitsi-meet 2.0.4416-1, jitsi-meet-web 1.0.3992-1, jitsi 2.10.5550-1, jitsi-videobridge 2.1-169-ga28eb88e-1, etc.) in a local install: the browsers obeyed the "resolution" setting and constraints of ideal and max to 360p, the iOS app transmitted at 480p. The difference in resolution could also be seen in the bandwidth usage.

Which versions of apps, and - if relevant - server components, are supposed to honor the "resolution" setting?

[WolfganP]

A related issue is that the mobile apps only offer the option 'Enable low bandwidth mode' which switches off video, but do not offer the intermediate resolution choices available in a browser.

100% agree, in these times of stay at home orders and explosion of videoconf services, having the ability to control the upload quality from any device may help a lot to the overall meeting experience.

An alternate solution to comply with low bandwidth but not degrading the UX too much, may be send 1fps camshots/stills (in some mid resolution) that won't affect bandwidth too much, but at least will provide some video feedback to other meeting participants.

[WolfganP]

An alternate solution to comply with low bandwidth but not degrading the UX too much, may be send 1fps camshots/stills (in some mid resolution) that won't affect bandwidth too much, but at least will provide some video feedback to other meeting participants.

Based on the w3c mediatrack constraints full list at https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints I noticed a set of constraints.video.frameRate are supported by the browsers, I'll experiment with the settings and measure upload rates client side and will report back once done.
Any other suggestions please let me know.

[chenlione]

hello,how do you have any idea for change resolution and frame rate in android app?

[geraldmwangi]

I would like to work on this problem. I saw that the video track is created in getUserMedia() in GerUserMediaImpl.java. The constraints are passed to getUserMedia but I have no idea from where getUserMedia is called. Can someone help me out? I'm a C++ dev and not quit firm in Java and android dev but I'd like to get my feet wet

[geraldmwangi]

getUserMedia is an @ReactMethod, as such is interfaced to java-script code right?

[SmartAkashNara]

Hello, how do you have any idea for change resolution and frame rate in ios app?

[enterux]

Any further update on this issue ? Anyone have had success with making the app honor server bandwidth settings ?

Maybe the core app developers can put some light on this issue.

[saghul]

Isn't the resolution setting being honored? The constraints property is unused. FRamerate is not controllable at the moment.

[rba4062]

Putting a comment to get attention to this issue. This issue is also referred here https://community.jitsi.org/t/ultra-focused-low-bandwidth-mode-for-desktop-smartphones/37048

[Boby]

+1 on this, on mobileapps its very needed and calls voice seems distrupted and not stable

[Bellusterra]

@saghul the resolution settings do not appear to be honored.
config.js settings:

resolution: 480,

constraints: {
    video: {
        height: {
            ideal: 480,
            max: 480,
            min: 240
        }
    }
},

getting 480 from the chrome browser but 720 coming into the chrome browser from the jitsi mobile app on ios. with proper url in the settings.

[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.

[Bellusterra]

not stale

[saghul]

We are experimenting with hardcoding mobile to 360p. That's how it has been for the past couple of releases, with good results.

[Bellusterra]

@saghul yes, i did notice that on the jit.si servers, but saw no change on the self hosted build with regards to the 360p, unless I’m missing something?

[saghul]

Regardless of the server, mobile should send 360p maximum right now. If it doesn't, then we have introduced a bug.

[Bellusterra]

@saghul I believe that might be the case, at least with ios. And it seemed more rather a max it would accept, not a max on what it would send, which seemed to be 180p. I saw the threads filling up with issues which i think are related. My desktop was sending hd and as soon as i would connect to the server with ios desktop would send 180p and i could not get ios in simulcast to have a clear picture had to disable simulcast. But then wouldn’t play on Android. I have the latest ios build 20.4.2 88 on ios 14.01

[Bellusterra]

I did just notice on the jitsi forum about the jitsi servers being maybe a little ahead of self hosted released code which may be the issue. I will have to test a bit more.

[Bellusterra]

@saghul it appears the hardcoded 360p is on andriod only on ios it is somehow hardcoded to 180p and is not usable. I have tested it several times with the exact same results join with ios and sends max 180p then add in andriod and goes up to 360p for all devices, disconnected android and it drops back down to 180p on ios. This is video being sent from the desktop to the mobile devices I’m referring to just to clarify.

[saghul]

@jallamsetty1 Any chance you can take a look at this?

[darylhutchings1]

Some interesting ideas here about slowing framerate to reduce bandwidth.
May be an interesting idea for remote users, if we can get this granular
based on login type (in our case)

Office device = full framerate up and down
remote user = audio off - slow framerate up and down / audio on - full
framerate up and down

On Tue, 29 Sep 2020 at 13:56, Saúl Ibarra Corretgé [e-mail]
wrote:

@jallamsetty1 https://github.com/jallamsetty1 Any chance you can take a
look at this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jitsi/jitsi-meet/issues/5808#issuecomment-700683302,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJGCH2P3JL5KMJTJMHPGDETSIHKOLANCNFSM4MEJS5EA
.

--

Daryl Hutchings

Collaboration Squared

US mobile: [phone]
UK mobile: [phone]
Email: [email protected]
Web: http://collaborationsquared.com/

Offices
New York: [phone]
London: [phone]
Hong Kong: [phone]
Singapore: [phone]
Sydney: [phone]

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments

[Bellusterra]

Jit.si gives me 360p on ios which is odd if its hardcoded, unless that was changed. I’m not aware of what config could even effect this?

[saghul]

I hardcoded it on both Android and iOS. Here is the latter: https://github.com/jitsi/jitsi-meet/blob/25271d7eec974dfcdd01e5630ae19107a26a3c98/ios/app/src/AppDelegate.m#L37 now, there is a sizable machinery which deals with send / receive resolution, so something might have been broken since.

[saghul]

Some interesting ideas here about slowing framerate to reduce bandwidth. May be an interesting idea for remote users, if we can get this granular based on login type (in our case)

I don't think that is useful. User locality need not be related with available bandwidth.

The bigger problem here is that despite having enough bandwidth processing so much video may kill your CPU.

[Bellusterra]

It appears on jit.si it defaults to initially sending 180p to ios and then increasing to 360p somehow its not always making the switch.

[Bellusterra]

It does seem that on jit.si it is working well. So i assume it is something with my setup, but again I couldn’t tell you what it is being that I am using the latest ios app build.

[Bellusterra]

self hosted with as close to defaults as I can get. latest build on linux as far as i can tell running apt update and upgrade and running the latest ios build 20.4.2 build 88 only way to get quality above 180p going to ios is disabling simulcast or running h264.
I think related to This Thread The Problem is definitely the bridge, because this does not happen in p2p mode. and possibly the way that it is handling simulcast?
jitsi-meet 2.0.5076-1 jitsi-meet-prosody 1.0.4428-1 jitsi-meet-turnserver 1.0.4428-1 jitsi-meet-web 1.0.4428-1 jitsi-meet-web-config 1.0.4428-1 jitsi-videobridge2 2.1-351-g0bfaac1c-1

[jallamsetty1]

Hi @Bellusterra, the config that @saghul is referring to is the send/receive max resolution configured on the mobile client. The resolution that the mobile client receives from the bridge also depends on the available downlink b/w calculated by the bridge. When you have just iOS devices and desktop in a bridge call, can you please check what simulcast streams desktop client is sending
You should see a log like this

[modules/xmpp/JingleSessionPC.js] <w.setSenderVideoConstraint>: JingleSessionPC[p2p=false,initiator=false,sid=36gjj5okshckk] setSenderVideoConstraint: 360
[modules/RTC/TraceablePeerConnection.js] <A.setSenderVideoConstraint>: TPC[2,p2p:false] setting max height of 360, encodings: [{“active”:true,“networkPriority”:“low”,“priority”:“low”,“adaptivePtime”:false},{“active”:true,“networkPriority”:“low”,“priority”:“low”,“adaptivePtime”:false},{“active”:false,“networkPriority”:“low”,“priority”:“low”,“adaptivePtime”:false}]

If the desktop client is indeed sending SD stream and the iOS client is not receiving the SD stream, it is possible that bridge b/w estimates are little off or there are local network issues.
I am able to verify that iOS Jitsi meet app 20.4.2 build 88 is requesting 360p and able to get 360p on meet.jit.si

[Bellusterra]

@jallamsetty1 Thank you for your reply. meet.jit.si is definitely working well and exactly as you say. I'm using the packaged ubuntu 18.04 installed through 'sudo apt install jitsi-meet' after trying to find the problem I purged jitsi-meet and reinstalled through the command mentioned. through the chrome inspect console tab I get the same results as jit.si (max 360p) to ios when in p2p. As soon as it switches to the bridge (I add another device) and it switches out of p2p the resolution drops to what appears to be 180p on the ios not on andriod just ios devices, additionally the (max 360p) goes away and shows a resolution output on desktop of 1280x720. as far as network my home network works fine with jit.si so that is not the problem and as far as self hosting it is installed on aws external. so unless there is something that I'm missing the problem is the install script or code with the the bridge correct? Edit: I will continue to check my configuration, because it is more then likely that, that is the problem.

[vvv-ca]

Regardless of the server, mobile should send 360p maximum right now. If it doesn't, then we have introduced a bug.

Any chance you could introduce a way to disable this limitation on Android? I'm using self-hosted Jitsi only for p2p meetings and 360p quality is just sad on a 4k display when bandwidth is not an issue.