Enable setting desktop sharing framerate default in config.js

[zerodeux]

What problem are you trying to solve?

Currently running Jitsi Meet 2.0.9457, with my 10 colleagues the desktop sharing is unusable at the default 5 fps (very coarse encoding and slow motion), and works perfectly when switching to 15 fps.
It currently means that every presenter must remember to change the setting, then maybe restart its screen sharing, which is pretty disruptive at every webconference...

What solution would you like to see?

As a far as I could see, SS_DEFAULT_FRAME_RATE is set to 5 in react/features/settings/constants.ts, then the webconf state inherits it in react/features/device-selection/functions.web.ts

I could obviously recompile my Jitsi with a different SS_DEFAULT_FRAME_RATE, but it would be much more simple if I could change it with something in config.js

Is there an alternative?

Well, yes, recompiling Jitsi Meet Web with a different SS_DEFAULT_FRAME_RATE, but for one constant that seem to be site/infrastructure dependent, it does seem unpractical at scale.

[zerodeux]

Oh I forgot to mention, I tried to no avail in my config.js :

desktopSharingFrameRate: {
    min: 15,
    max: 15
},

Which might be in itself a bug, because although I asked for a minimum of 15 fps, I do get 5 fps every time I start a new video conf.

[saghul]

Ping @jallamsetty1

[jallamsetty1]

@zerodeux, What makes you think that the setting isn't working? What browser (version) are you testing this on and what codec have you configured on your deployment? I just checked it on Chrome and I can see that the capture fps is set 15. You can check it in chrome://webrtc-internals for the getDisplayMedia call and I see the correct constraints. The settings can only control what fps is used for capturing by the browser. What exactly gets sent on the wire depends on the available cpu/bandwidth on the local machine.

[zerodeux]

What makes you think that the setting isn't working?

The settings display, stuck at "5 fps" :

What browser (version) are you testing this on and what codec have you configured on your deployment?

Chromium 125.0.6422.112 (Official Build) built on Debian 12.5, running on Debian 12.5 (64-bit)

check it in chrome://webrtc-internals for the getDisplayMedia

I checked it right after starting the screen sharing and found indeed this :

getDisplayMedia call
Time: 22:23:10 GMT+0200 (Central European Summer Time)
Audio constraints: true
Video constraints: {frameRate: {max: 15}}

Thus you're right. I didn't know how to check the real fps via the chrome://webrtc-internals, now I know better.

It looks like the bug only pertains to the Settings dialog, which shows that "5 fps" is selected although I clearly get at least 15 fps. Thanks for the help.

[jallamsetty1]

Yes, the bug seems to be in the UI, it doesn't reflect the capture frame rate correctly if it was set through config.js. We will fix it, thanks for bringing it to our attention.