Desktop sharing frame rate config not working for remote racks

I’m using lib-jitsi-meet and have the problem that I need to have 30 fps for screen sharing but only the user who is sharing the screen can see the increased frame rate. All the other users will still see the default frame rate.

I tried to debug this problem but I couldn’t find any problem. Maybe someone can help me with that because I have no idea anymore how to fix or debug it.

1 Like

@jallamsetty can you help?

Hey there ! Can you please let us know how you are specifying the frame rate for screen sharing ? The documented way of passing minFps and maxFps to the options object that is passed to JitsiMeetJS.createLocalTracks seems to be broken (we will try to fix this). In the meantime, we have another config option that you can try.
@param {Object} options.desktopSharingFrameRate
@param {Object} options.desktopSharingFrameRate.min - Minimum fps
@param {Object} options.desktopSharingFrameRate.max - Maximum fps
Please give this a try and let us know if this fixes your issue, thanks !

Currently I’m using the following code with jitsi-meet_4168:

  devices: ['desktop'],
  desktopSharingFrameRate: {
    max: 30,

Because I didn’t know this config I also tried this one now. But with this one even the local track is stuttering.

  devices: ['desktop'],
  maxFps: 30,

Setting the min values too also didn’t helped.

@jallamsetty Do you have any idea what the problem might be? I could help debugging it if someone can point me in the right direction.

@sapkra, my apologies for not getting back to you sooner ! It seems to have slipped through the cracks :slight_smile:
Can you please give me some more details about your setup ?
Are you using old bridge or JVB2 ?
Are you seeing this issue with P2P as well ?

For calls going through JVB, we have a setting in config.js - capScreenshareBitrate which controls how we configure the desktop stream. When set to 1, we disable simulcast and set a max bitrate of 500Kbps on the screensharing session which can affect the frame rate. Can you please make sure this is set to 0.
Please note that this setting should not affect p2p session at all.

Also, will you be able to check chrome://webrtc-internals when the call is up to see what the captured and sent framerates are for the sreensharing session ?
I can give you more detailed info about what/where to look for if you aren’t familiar with webrtc-internals.

Thank you !

It seems like I’m using the old one. It shows: JVB 0.1.1126
But I have no idea how to upgrade to the new version. Do I just have to rebuild the docker images?

If I’m in a room with just one other participant then I have the same problems. But maybe these streams are also sent over the videobridge for some reason.

I’m using lib-jitsi-meet directly so I will check where I have to look there.

For each chrome tab I’ve got two tabs for webrtc-internals. I’ve found out that one tab has a RTCVideoSource with about 30 fps and the second one 5 fps after I’ve enabled the screen sharing. Both streams are mapped to an RTCOutboundRTPVideoStream.
So it seems like that for some reason the stream is created twice.

If I disconnect with the second user again the internals tab with 5 fps will becomes removed.
It looks quite similar to the webrtc-internals.

Screen Shot 2020-02-27 at 00.22.07
Screen Shot 2020-02-27 at 00.23.56

From my tests it appears that Chrome is throttling the frame rate for the screenshare, it starts at 30 fps and few seconds later the frame rate drops down to 4~5 fps as seen in the attached graphs for the send stream (pls look at googFrameRateInput and googFrameRateSent graphs). The next step would be bring it up in discuss-webrtc forum and see what others have to say about it or look for open bugs related to getDisplayMedia. Do you want to give that a try ?

I’m also interested in this issue. But I find it hard to believe that it’s being throttled by Chrome somehow… The presenter mode (desktop sharing and then un-muting the webcam) runs at full 30fps in Chrome. So that means that the desktop capture stream can be used at a frame rate higher than 5.

In presenter mode, we create a new HTML canvas, draw desktop and camera images onto the canvas and then capture the stream from the canvas at 30 fps before adding it to the webrtc peerconnection. Though you are getting full 30 fps, the desktop is still captured at 5 fps.

Really? I tried today and the desktop capture seemed much higher fps when the presenter mode was on. Also on the receiving end.

Oh, I see what you are saying !!
There is this intermediate step when the presenter is turned on. If the resolution of the desktop share is greater than 720p, we resize it to 720p by applying constraints on the desktop stream. I am seeing that we are getting full 30 fps from deskop stream when it is resized, otherwise we get only 5 fps.
You can test this out by sharing a small window, even with the presenter turned on, the desktop fps continues to be low.
Thank you for pointing this out, we will have to figure out why Chrome is doing this. We may not be able to get to it immediately. I will update here whenever we make progress on this.


I found this post which was really interesting. Maybe it will help going forward with this topic somehow.

Thanks for bringing this up, we disabled simulcast for screensharing on chrome a while back because of the way chrome was changing bitrates for the SS simulcast streams causing freezes for receiving endpoints with low downlink bandwidth.

You can play with this config.js option “capScreenshareBitrate” to see if that helps.
capScreenshareBitrate set to 1 will disable simulcast and cap max bitrate to 500 kbps
capScreenshareBitrate set to 0 will enable simulcast for SS.

Hi. I cant find capScreenshareBitrate in config files. Is it possible to change this setting in stable version?

It’s part of the testing config:

testing: {
    capScreenshareBitrate: 1,

Is it supported only by unstable version? Or stable too?

It is supported in the stable version as well.

Hi @sapkra, were you able to get 30fps for SS working ? I just tested it and it is working perfectly when we disable capScreenshareBitrate. There is bug in the p2p mode that got fixed last month, so it should work for both p2p and jvb case.

Just deployed the new release yesterday and everything seems to work now without configuring capScreenshareBitrate.