Suddenly shared screen is hard to read (blurred) -

Hello, does anybody know, why since around 2 weeks suddenly shared screens are not sharply seen anymore? is there a change of servers? or can I change that anyhow? Thank you for helping me…

1 Like

Welcome to the forum.

You can now change the screen sharing frame rate dynamically. Just go to settings and in the “More” tab, select a higher framerate.

Screen Shot 2021-07-14 at 11.03.15 AM

Note that as the instruction states, you’ll need to restart the screenshare if you’re already sharing, for the new settings to go into effect.

1 Like

Thank you. I have seen and tried that already, but it doesn’t make any change.
I let my students try as well, no change; we dont see a good picture - can’t bring it into focus…
I’ve used the whole last year, and it was always working fine.
now since about 2 weeks cannot be focused anymore.

Any changes from the side of jitsi? new provider? New server?
It’s really a shame, because I was so happy to use jitsi (instead of Big Blu Button…)

I’m really looking forward, if someone has an Idea…

We identified an issue about that and fix is already merged, and today or tomorrow the fix will be out on
Thank you for the report.

jippieh - thank you very much

Could you share some information about the nature of this bug and the correct fix (we are seeing something similiar on our jitsi instance from time to time)

@jallamsetty what was the fix for the blurred screenshare we were seeing on

1 Like

@damencho, we had to make some tweaks to the number of simulcast streams sent to the bridge for screensharing after we defaulted Chrome to unified plan. Unified plan had simulcast always enabled which was causing the client to not send higher resolution streams on some low end machines. It is possible that those changes are not in the stable repo yet.

1 Like

@jallamsetty, i tried latest lib-jitsi-meet from github (9.8.) and this problem still occurs… is there any plan to merge the fix? we are testing jitsi with unified plan for chrome, since we didn’t update for long time, so we need something that doesn’t have such problem and is up-to-date…
is there any lib-jitsi-meet version, that is not affected by this and has support for unified plan? or if the merge is planned in upcomming days, we can wait a little, but end of august is closing for Chrome 93…

The latest lib-jitsi-meet has the fix. There were some optimizations done on the bridge side as well to do better bitrate allocation for the screenshare. What bridge version are you running ? Are you able to reproduce the issue on ?
Chrome plan-b deprecation has been pushed out to M94 which is scheduled to be released to stable on Sep 21st.

@jallamsetty ok, so probably missing complementary changes in jvb, we use a little old 2.1-416-g2f43d1b4-1, i’ll test with latest stable jvb - i read here in forum that there are some reported problems with excessive logging, will see…

Wau, thank you for that information! Is there some oficial statement from google? I didn’t find any yesterday, but we saw that the necessary changes were only in m94 canary, so we were not sure, if we can bet on this… that would give us some time to test…

So M93 will still throw the error in Canary and Dev but not in Beta and Stable channels.

upgrading our bridges to jvb 2.1-508-gb24f756c-1 helped solve the problem after update of lib-jitsi-meet.

@jallamsetty after update, users are experiencing really often fluctuations in quality… after update of lib-jitsi-meet the screenshare was blurred, we solved this with also updating jvb, but now it’s sometimes just switching from one quality to another, from blurred to sharp and back, without any apparent reason… sometimes quality stays the same and doesn’t switch for long time…
i tried and can’t reproduce it here…
are there some new configuration parameters, that can influence this? we are using unified plan with chrome 92… or is the bwe just this agressive in new version of jvb?

No there are no new configuration parameters. What codec are you using and do you have desktopSharingFrameRate.min/max set in your config.js ? If you are using the default of 5 fps, then the blurring is a problem with the source since the client sends only 1 stream that the bridge simply forwards to the other endpoints.
If you have desktopSharingFrameRate.max > 5, then simulcast is enabled for screenshare and the bridge then picks what stream to forward based on the receiver b/w.

@jallamsetty yes, we have desktopSharingFrameRate.min/max set to 5/15… We have tried VP8 and h264, both with the same result. i think that using h264 disables simulcast, at least that is what the config says and what i found in code.

I’m thinking whether there are some changes in BWE on jvb, since we are using same configuration on jvb. Maybe something changed here and bridge does detects bandwidth differently.
We are using cable connections with 1gbit network (our office), so i think there should be no network limit, but still the problem appears.

I think i need to identify, whether this is a jvb thing or jitsi-meet thing and then either tune jvb or setting in jitsi-meet.

If desktopSharingFrameRate.max is set to 15, simulcast is enabled for screenshare. There were some changes in how bitrate is allocated for the screenshare and camera streams for a given participant based on BWE values computed by jvb. Have you tried with the latest stable that got pushed out yesterday ?

@jallamsetty i will test with latest stable on friday, since business have some important conferences and we had to downgrade to our latest known version that works…

EDIT: sorry it was a mistake. After purging jvb and reinstalling it, the issue got fixed and the lower layers are not sent anymore when the framerate is < 6.
The following is no longer true!

We have the same issue with latest stable. Simulcast is always enabled during screen sharing and for some participant the layer selection seems to keep switching, so the quality goes from blurred to sharp and back.

Even when setting desktopSharingFrameRate min and max set to 5, (or even with capScreenshareBitrate set to 1) I can see in webrtc-internals that there are 3 RTCOutboundRTPVideoStream with different resolutions sending data.

Is there any other configuration to disable simulcast during screen sharing?

I thought it was fixed after reinstalling jvb but when doing meeting with more people and make sure to have various condition (some people looking at tile view, some people pinning someone else etc), then I can see that the screen sharing keep switching resolution again. And when checking webrtc-internals I can see again 3 RTCOutboundRTPVideoStream sending data, so there is simulcast.

What about you @nosmo could test with latest stable ?

However on, not only the resolution of screen sharing always use the highest layer (and I checked that the two others RTCOutboundRTPVideoStream are not sending data), but the framerate of the screen sharing goes sometimes higher than 5 (sometimes even reaching 30), so I’m confused at what configuration use. @jallamsetty can you shed some light?

About low fpg screen sharing (framerate less or equal than 5), I did some investigation and if I understand correctly the part of the code that disable the lower spatial level in low-fps screensharing is in lib-jitsi-meet TraceablePeerConnection.js, in the function setSenderVideoConstraint This part:

        // Disable the lower spatial layers for screensharing in Unified plan when low fps screensharing is in progress
        // There is no way to enable or disable simulcast during the call since we are re-using the same sender.
        // Safari is an exception here since it does not send the desktop stream at all if only the high resolution
        // stream is enabled.
        if (this._isSharingLowFpsScreen() && this._usesUnifiedPlan && !browser.isWebKitBased()) {
            const highResolutionEncoding = browser.isFirefox() ? 0 : this.encodingsEnabledState.length - 1;

            this.encodingsEnabledState = this.encodingsEnabledState
                .map((encoding, idx) => idx === highResolutionEncoding);

But the issue I have is that I never reach that code when I start screen sharing. The function exits way before:

TraceablePeerConnection.prototype.setSenderVideoConstraint = function(frameHeight = null) {
    if (frameHeight < 0) {
        throw new Error(`Invalid frameHeight: ${frameHeight}`);

    // XXX: This is not yet supported on mobile.
    if (browser.isReactNative()) {
        return Promise.resolve();

    // Need to explicitly check for null as 0 is falsy, but a valid value
    const newHeight = frameHeight === null ? this.senderVideoMaxHeight : frameHeight;

    this.senderVideoMaxHeight = newHeight;

    // If layer suspension is disabled and sender constraint is not configured for the conference,
    // resolve here so that the encodings stay enabled. This can happen in custom apps built using
    // lib-jitsi-meet.
    if (newHeight === null) {
        return Promise.resolve();

At this point, newHeight is always null, so the function exit and simulcast with all layer stay activated. The comment say that “If layer suspension is disabled and sender constraint is not configured for the conference resolved here”, but I have sender constraints configured in my jitsi-meet config.js (like constraints:{video:{height:{ideal: 540, max: 540, min: 135 }}}), and the constraints are applied correctly, so I don’t understand why setSenderVideoConstraint exit early…