Resolution Problem and CPU problem

Hi,

I use the last Jitsi version on a Debian 10 with 8 cores and 32Go of ram.
The server works well, the ram usage is around 5% and the CPU 4%.
The server as a 10Gbps network and each computer in the meeting have 1Gbits of network with only 3mbits of usage. Computers are I7 last generation with 16Go of Ram.

I have 3 problems:

  1. The resolution of each participants is very low, 320X180
  2. The sharing screen quality is also bad , it’s not possible to read what we are sharing
  3. The CPU of Computers is very very High (99% - 100%)

From the server side the performances are perfect.
All computer see the green light with Good and 3Mbits/s in download for each computers but resolution 320X180 If we are 3 or 6 it’s the same.

I have the same problem on meet.jit.si.

Here is my server configuration:
// Video

// Sets the preferred resolution (height) for local video. Defaults to 720.
// resolution: 720,

// w3c spec-compliant video constraints to use for video capture. Currently
// used by browsers that return true from lib-jitsi-meet's
// util#browser#usesNewGumFlow. The constraints are independent from
// this config's resolution value. Defaults to requesting an ideal aspect
// ratio of 16:9 with an ideal resolution of 720.
 constraints: {
     video: {
         aspectRatio: 16 / 9,
         height: {
             ideal: 900,
             max: 900,
             min:360 
         }
     }
 },

// Enable / disable simulcast support.
// disableSimulcast: false,

// Enable / disable layer suspension.  If enabled, endpoints whose HD
// layers are not in use will be suspended (no longer sent) until they
// are requested again.
// enableLayerSuspension: false,

// Every participant after the Nth will start video muted.
// startVideoMuted: 10,

// Start calls with video muted. Unlike the option above, this one is only
// applied locally. FIXME: having these 2 options is confusing.
// startWithVideoMuted: false,

// If set to true, prefer to use the H.264 video codec (if supported).
// Note that it's not recommended to do this because simulcast is not
// supported when  using H.264. For 1-to-1 calls this setting is enabled by
// default and can be toggled in the p2p section.
 preferH264: true,

// If set to true, disable H.264 video codec by stripping it out of the
// SDP.
// disableH264: false,

// Desktop sharing

// The ID of the jidesha extension for Chrome.
desktopSharingChromeExtId: null,

// Whether desktop sharing should be disabled on Chrome.
// desktopSharingChromeDisabled: false,

// The media sources to use when using screen sharing with the Chrome
// extension.
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],

// Required version of Chrome extension
desktopSharingChromeMinExtVersion: '0.1',

// Whether desktop sharing should be disabled on Firefox.
// desktopSharingFirefoxDisabled: false,

// Optional desktop sharing frame rate options. Default value: min:5, max:5.
 desktopSharingFrameRate: {
     min: 30,
     max: 60 
 },

// Try to start calls with screen-sharing instead of camera video.
// startScreenSharing: false,

Do you know what I can see in the confuguration to a good resolution of Webcam please?
Do you know how to decrease the CPU load on computers please?
Do you know how to increase the sharing quality please?
Do you think it’s a codec or a configraution problem?

Thanks for you help

1 Like

Solution for #3: Client computer CPU bottleneck
Jitsi meet work out of the box with up to about 15 participants. After that you will start to run into bottlenecks for users with slow computers that the user-interface redraw itself too much and consume 100% cpu.
This can be solved by profiling using the chrome performance monitor and disable all things that consume CPU time.

For example audio level monitoring that render the blue dots when someone talk trigger GUI updates. With many users these GUI updates will cause the client web-browser to redraw too frequently that will cause the user to have a bad audio experience due to missed audio updates. The solution is to simply disable the AudioLevels monitoring.
disableAudioLevels: true,

On the left only 10% CPU when audio levels are disabled. On the right 100% CPU time when audio levels are enabled due to frequent audioLevelReport processing and GUI re-layout.

1 Like

Thanks for this audio optimisation , we won 40% of CPU usage with disableAudioLevels: true,

If somebody else has an idea about my resolution problem please

1 Like

problem #1: Try enable the
resolution: 720,
option

it is currently commented out… remove the // to enable the option

thanks for your reply, I just removed // and put resolution: 900, then rebooted the server.
I tried again and resolution is still 320X180 :frowning:

localy we see our webcam at 1280X720 but participant see 320X180

1 Like

i am clueless: double check if the video quality slider is set to HD
press A
… (button) -> Manage Video quality -> set to HD

1 Like


image

Locally:
image

Yes it’s per default set to HD , 3Mbps for 180p it’s a lot :slight_smile:

1 Like

The Manage Video quality controls only what you will be receiving. 720p are sent in 3Mbps not 180p.

1 Like

@damencho thanks for this information. All particpants use HD and receive 3Mbits but see only a 180p resolution. Do you have any idea plz?
On a small window 180p looks ok but in full it’s horrible, 180p on a full HD or 4K screen it’s horrible :frowning:

1 Like

You get 180p streams when in Tile View unless you change the settings for the resolution in Tile View. This is intentional so you save tremendous amounts of bandwidth when viewing all streams at once.

1 Like

@voxter thanks for your reply.
In tile View I have 180p and in full screen 180p too. it’s my problem.
I don’t want to save bandwidth , the video flow can use 10Mbits, 100Mbits 500Mbits or 1Gbit per user it’s not a problem for us. I just need to find the good setting and where to fix or force the best resolution everytime in Tile View and in full screen. For me the minimum should be 720p.
You say it’s intentional but do you know where I can change this setting please for example to put 720p or 1080p or I don’t know 4K 8K please?
Also with 2 users I have 720p everytime I have the 180p problem with more than 2 user. So it should be a settings on the jitsi server somewhere :frowning:

In 180p our the resolution is bad we are pixelised: see my head or try to read this book.
image
image
Our users complain every day about the Tile View bad quality.

An other thing with no link with my problem if somebody doesn’t know that :
If you share you screen then enable your webcam then disable the webcam you will have a good resolution 2560X720 and 30-33 frame per second.
You can share a video game or a film without problem.(1.4Mbps)
I’m not using the youtube share but the standard full screen sharing.
Also If somebody know how to have everytime the max resolution and max frame per second without doing this technic , let me know.

And I did a sharing test in tile view: I have 3840X1080 not 180p why we can’t have high resolution with webcam? (our webcam are 720P Full HD and 4K but stay at 180p)

I did a test again with sharing full sreen with a video running in full screen in 720P 33 Frame per second it’s perfect:

And forza 4 trough Jitsi in 720p using full screen sharing (it’s not a video it’s the game) :slight_smile: :

When I see that I don’t understand why we see webcam in 180p and sometime 135p.
If the sharing can do high resolution with 32 frames per second it mean the network is good and the server too but why 180p for webcam lol.

1 Like

If you see 180p on stage view, this means that datachannels do not work and basically jvb is not receiving information who is on stage to be able to switch to HD layer.

1 Like

Here is an example of 180p in full screen

Only the screen sharing is perfect with the technic I explained but webcam video stay at 180p.
In which file can I check the configuration or where can I see if there is a problem please?

1 Like

For your use-case where you are only interested in the HD stream and bandwith is plenty try disableSimulcast, that would make the streamer only send the full HD variant thus then the videobridge has to forward the one and only HD stream.

disableSimulcast: true,

1 Like

@xranby hi thanks for you reply.
I did the test and now we can see 720p and more instead of 180p in full screen. thanks.
50Mbits for 4 users with dimultcast disabled
So with disableSimulcat the resolution is good in full screen but now all CPU use 100% (I7 and I9 last generation) lol

The good (not perfect but ok) settings for me could be 360p (instead of 180p) in tile view and 720p for webcam in full screen (instead of 180p) with simulcat but with 360 720 and 1080 (and not always 180p).

Is there something between disabled simulcast and enabled simulcast?

Sorry for all of my questions and problems I trying to find the middle way.

1 Like

Good to hear that HD is working.

I am interested to know what is causing 100% CPU, can you profile the user-interface using chrome or firefox inspect performance tab and see what is consuming most CPU time?

To further improve optimal bandwidth I think you need to change the react user-interface to change the video mode on the fly depending what mode the remote user is at possibly in combination with Off stage layer suppression: https://jitsi.org/blog/new-off-stage-layer-suppression-feature/

@xranby


image

As you can see now it’s in HD. we se my face and the resolution is good compare to my previous post.
everything in close on this laptop and the CPU is at 100%
OK i’m going to check the performance




image
Thanks again for your help

1 Like

Look at the flame graph, (it is hidden i the profile images you posted) it will reveal what triggers the start that eventually cause the re-layouts. Check the Main flamegraph, zoomed into the spike like shown in the image of this example:

you may save the profile to disk and upload it here.

@xranby ranby
Everything is closed on this computer. All application, all signet and all programm is the taskbar.
We are only 3 in the meeting.



image

Please find the capture here (remove .txt):
The cpu was not completly at 100% for this test but very very high
Profile-20200420T183756.zip.txt (3.1 MB)

Thank you, I have taken a look at your profile and examined the two top CPU eaters:

28% of CPU time have been used for _updateCanvas -> drawImage - this is done by LargeVideoBackground …
Try disable the LargeVideoBackground in interface_config.js !
DISABLE_VIDEO_BACKGROUND: true,

25% of CPU time have been used for VAD (voice activity detection) “calculateAudioFrameVAD”, this is unexpected high!
Not sure why… i have to think about it.

1 Like