Screensharing Frame Rate


#1

Hello everyone,

Starting to feel pretty good with my set up, successfully using simulcast (or at least a notable improvement once enabled).

One glaring thing that I have been having an issue with is frame rate. So right now, during calls I get consistent 30 frame rate for video call, which is awesome, however, I get a consistent 5 for screensharing which makes things a bit choppy. Since a lot of what I use Jitsi for in my environment is more for code review (screensharing) than it is video chatting it can be an issue sometimes.

It seems that it is essentially maxing out at 5 FPS, and it almost seems like there is a setting that I am just overlooking to bump that up even more.

I noticed in this post ([jitsi-dev] How to change resolution and frame rate (FPS) of Jitsi?) someone mentioned that you can change - *private static final long TS_INCREMENT_PER_FRAME = 90000 /* Hz */ / 30 /* the Hz to FPS and force it to be higher. I have been having trouble tracking this bit down in the config.

Is it located in the Video-bridge config? or do I need to append it to a different config? Is there a MAX screensharing FPS that the system allows? What is the best practice to boosting screensharing FPS if there is one.

Thanks for helping out!
Nate


#2

This is coming from the clients (lib-jitsi-meet https://github.com/jitsi/lib-jitsi-meet/blob/f86e86bba5c09bfe2c8c3ff1bb4a2e078706bc02/modules/RTC/RTCUtils.js#L71)

Have you tried these settings, doesn’t those work for you?


#3

Embarrassingly, no, but thanks for showing!

Changed MIN to 15 and MAX to 30 and it now moves like butter. However when you hover over the stats it still shows a frame rate of 5. Ultimately, I’m thrilled that screensharing moves very smoothly.

Could I be missing something that would allow that function to reflect what sort of frame rate I actually am getting?

EDIT: would editing the default const solve that issue?


#4

No, not sure about that. The frame rate is taken from webrtc getStats … it can be that there is a bug. You can open chrome://webrtc-internals and then try sharing the desktop and then in webrtc-internals you need to find the send stream and see its frame rate, if there it is correct (more than 5) then there is a bug probably in our logic of extracting that data.