Improve Quality of Screen Sharing on Chrome

Has anyone tried VP9? Can you share how you succeeded in applying it? Or do you have any ways to improve the video quality? Because there are Mosaics when some things move quickly in the video. Thanks.

I haven’t tried VP9, but IIRC it has a higher CPU usage (which is already high as it is). What device where you using when you saw the video artifacts? Any chance you can record a short video showing the issue?

Cheers,

Now we don’t know where to set it as VP9. :frowning:


Here you can see the problem, it’s not clear enough, a little blurry, and it freezes a little bit every several seconds.

So what’s happening there, are you using the YouTube share funcionality? On what browser?

No. When sharing the screen. The shared screen is not as clear as the original one.
This video is for showing the problem. I played a video on YouTube, and it was clear, but as I shared my screen, other people saw the shared screen was not clear, and it froze due to video frame skipping, not smoothly, as the video shows, it’s not as clear as the original video. Especially when objects move.
For YouTube share functionality, it works perfectly. The problem exists when sharing the screen, we want to improve the quality.

normally screen sharing fps is only 5, If you want fluid video in screen sharing u need to add it in the config file as shown here

2 Likes

Thank you very much!

Correct. Sharing the screen to wartch a video is not really something we support. Screen sharing is designed for more static content.

1 Like

ditto what @saghul and @Tanvir said. Just a quick note that Chrome supports high fps and simulcast while screen-sharing and making use of these features is in our immediate roadmap.

1 Like

We’ve tried as @Tanvir suggested, and changed the fps as min 30 and max 60. Now it works much better. Thank you so much. But we found that the performance on Firefox is better than on Chrome. On Chrome, the fps is always below 30, and the shared screen is not so clear. But the fps on Firefox can reach 60, and in general higher than on Chrome, and the shared screen is clear if the internet connection is good. Why is there a difference? Should we change it as min 60 and max 60?

I’m not familiar with the Chrome internals on this regard, but given they have made significant strides towards making the static content sharing more efficient, I wouldn’t be surprised if you are hitting some edge cases.

Now we use Firefox to share screens, and enabled H.264 on this line, and it turns out even better! But I saw it says that “Note that it’s not recommended to do this because simulcast is not supported when using H.264.” So is screen sharing a kind of simulcast? Will it bring some troubles when H.264 is used?

Simulcast means you send your video stream in 3 resolutions so the bridge can select the appropriate one when forwarding it to every other participant.

Now, since you are only screen sharing this is not all that important, but imagine you are in a 10 people conference without simulcast. If everyone has their video on you’d need 10*2.5 mbps of bandwidth to receive all videos. Also, a bigger resolution affects the CPU usage when rendering, so there is that too.

1 Like

Thank you. Now we have another problem :blush: Sharing screen on low-end computers may have worse performance. I’d like to show you our test result.
We disabled H.264, and used two laptops to share screen on Firefox. One’s configuration is i7 4810MQ 2.8GHz, 16G Ram, it performed very well, like this:

The other one is Intel® Celeron® CPU N2940 1.83GHz, 4G Ram. When I played this video(1080p) on Youtube while sharing the screen by jitsi, many frames of the YouTube video lost(on my side, not the shared screen); but after I closed the jitsi window, and only played this video, it went smoothly. Is it because this laptop has low configuration? Like this:

Do you know how to solve this problem? Because some of our uses’ laptops are not high end. We hope they can also have a better experience.

It’s hard to translate CPU models to actual performance. Celerons are Intels low end. This one has 4 cores, but it’s a model from 2014, so a pretty old architecture.

Once thing you can try is lower the resolution by using the “resoltuon” and “constraints” options in config.js

1 Like

Thank you for your reply :sunny:

Please have a look at the test results on another laptop. Thank you.

Here is the configuration:

Intel® Core™ i7-7700HQ @2.80GHz 8G Ram

Intel® HD Graphics 630

NVIDIA GeForce GTX 1050

On this laptop, the YouTube video was fluid and clear, but the shared screen froze sometimes.
On Firefox, it froze every several seconds, I don’t know why. Do you have any idea? But the picture quality was good, upload BitRates were always higher than 3,000 kbps, could reach 5,000 kbps; Frame rate was usually higher than 25, and sometimes higner than 30.
You can see the effect:

On Chrome, it frequently lost frames, Frame rate was not stable and low, about 6, and the picture quality was not as good as on Firefox,

but after playing the video for a while, it became fluid, but the Frame rate was still below 25, and the upload speed was always less than 2,000 kbps. So the shared screen was not clear.

We see that when the Frame rate remains 25, and the upload rates are higher, it’s fluid and gives users a good experience.

We saw a plugin jidesha on jitsi’s github but we haven’t installed it. What is it used for? Can it cause some problems if we don’t install it? For screen sharing, what plugins should we install?

Thanks for sharing those results!

You doin’t need a plugin sor screen-sharing, that’s a thing of the past now.

I’m not sure what to do here TBH. We can. pass parameters to the browser’s WebRTC engine (which we do), but then it’s sort of up to them.

In your case looks like Firefox is better suited due to how the implement screen-sharing. Chrome tends to optimize for more static content AFAIK, hence the worse results.

@gpolitis do you have any ideas?

Is it the lowend laptop doing 1080p decoding (from YouTube) and encoding (with Jitsi)? You can monitor the CPU while you’re performing these experiments, but higher CPU usage leads to poorer user experience as a rule of thumb, and the engine will limit the target bitrate (lower resolution/frame rate) if the CPU is stressed.

More on the Chrome vs Firefox screen-sharing implementation. I’m not even sure if Chrome respects the media constraints that we pass, at least when it’s screen-sharing. A recent Chrome with legacy simulcast signaling (which is what we signal in the SDP) streams 2 simulcast streams, one high frame rate with 2 temporal layers and 1 low-frame rate (5 fps max) again with 2 temporal layers but we don’t have proper support for that in the bridge. tl;dr; There’s more work to do on the bridge to improve our screen-sharing simulcast handling and I don’t think there’s much else you can do to configure things on your end.

Firefox, on the other hand, seems to have a more “traditional” “un-optimized” implementation for screen-sharing that doesn’t cap the frame-rate and hence works better if you want to screen-share video, as Saul suggested, so I’d stick with that for now.

On chrome, it has a lower Bandwidth usage than on Firefox, but its frame rate is low. Will it work better to use vp9 instead of vp8? Is it possible to use VP9? Do you intend to optimize this functionality?