Poor Video Quality Latest Jitsi Update (5142-1)

Recently upgraded to the latest version (5421-1) and the video quality has dropped significantly. Prior to the update, I was able to maintain a 640 resolution at the minimum in tile view; with the update, I’m now seeing a max of 240 (which is actually my set minimum). My constraints are set as follows:

Screen Shot 2020-10-23 at 12.13.32 AM

I haven’t had to mess with layer suspension or any of that in the previous version, so would prefer not to, if at all possible. Any idea on how to fix this?

Hi @Freddie, when you say 640, do you mean 640x360 ? We recently made a change where we check the height of the video thumbnail for deciding on the resolution to be requested, making it harder to request higher resolutions in tile view. In order to receive 360p, the height of the thumbnail should be atleast 360 pixels. You can override this behavior by specifying your own thresholds using minHeightForQualityLvl setting in config.js.

If you want higher resolutions to be requested, you can lower the thresholds needed for requesting SD and HD resolutions - https://github.com/jitsi/jitsi-meet/blob/master/config.js#L277

Hi @jallamsetty! Thanks so much for responding.

Yes, I meant 640x360. I was able to get 1280x720 on my own feed and 640x360 on every other participant’s feed in the tile view. Although I wanted 1280x720 for everyone, 640x360 worked fine. But the latest update changed that. I suspected some changes were made and also suspected I would need to override them (even suspected it would be the specific segment you pointed out). I guess I’m just wondering what the improvement is in this latest version? Maybe the previous version might be better for me after all. I’m trying to understand the justification for me being on this latest version. Any thoughts?

In the latest version, we have done a lot of cpu/bandwidth performance optimizations so both the client and the server are not loaded more than they need to be. With layer suspension, we make sure only the relevant streams are sent up to the server. This saves cpu and bandwidth on the clients and also reduces the processing power needed per participant on the bridges.
Requesting lower resolutions based on the heights of the video tile has similar benefits on both the bridge (pushing fewer bits) and the client (decoding lower resolutions).

1 Like

Aaaah I see. Thanks kindly. This information helps a ton!
I appreciate your time. :pray:t5:

1 Like

Hi @jallamsetty,

Reaching back out to you on this issue. So, since we now support 1080 resolution, I tried to allow up to 1080 feeds on my installation. I set my constraints like this:
Screen Shot 2020-11-03 at 11.13.50 AM

To then override the default and lower the thresholds for my resolutions, I uncommented the “minHeightForQualityLvl” property. It appears to have a syntax error, by the way (there’s a missing apostrophe after “standard” - please correct me, if I’m wrong):
Screen Shot 2020-11-03 at 11.17.06 AM

I corrected the error and set me property like this in my config:
Screen Shot 2020-11-03 at 11.20.03 AM

The result for me was a resolution disaster. Yes, it allowed my local video to scale to a higher resolution, but every other participant was pegged at 180p resolution and lower - EVEN in Speaker view! And on their end, they also saw my resolution at 180p! :fearful:

Please, help me to understand what I’m missing here, because I’ve never had resolution this bad. I want to take advantage of the latest improvements, but not at this price.

@Freddie, can you please provide browser console logs from one of the clients ? If the client is configured to use 1080p, the corresponding LD stream would be 270p and not 180p. Are you able to check if your client upload is fine ? Have you configured maxBitratesVideo under videoQuality in config.js ?

@jallamsetty, I tested again last night with 4 clients - 2 different browsers on a mac (mac 1, mac 2), the desktop app on a windows machine (win) and one client connecting through the mobile app (mobile). The camera on the mac only goes up to 720p. Findings are:

Reading from Mac 1
Mac 1 - 1280x720
Screen Shot 2020-11-03 at 11.44.03 PM

Mac 2 - 320x180
Screen Shot 2020-11-03 at 11.47.01 PM

Win - 320x240
Screen Shot 2020-11-03 at 11.43.29 PM

Mobile (Android) app
Screen Shot 2020-11-03 at 11.43.52 PM

Reading from Windows Machine
Mac 1 - 320x180 (both in tile view AND speaker view!)

Mac 2 - 240X135
Screen Shot 2020-11-03 at 11.46.39 PM

Win - 640x480

Mobile - 320x180

Not sure how well you can see these, but these are screenshots of Mac 1’s feed during the same call:

Mac 1 Local feed (1280x720)
Screen Shot 2020-11-03 at 11.51.19 PM

Mac 1 viewed from Mac 2 (320x180)

I then commented out the “minHeightForQualityLvl” settings to set back to default and the results were the same. I tried changing values for layer suspension as well, no change. I didn’t touch “maxBitratesVideo” throughout (remained at default values - commented out). I didn’t see a need to change that because I wasn’t trying to restrict the maximum resolution.

Bandwidth measurement is:

I didn’t see anything significant in the browser js console log, but here’s a snip:

And it just occurred to me you mighthave been asking for the logs from the “save logs” link. Not sure I have one of this actual test, but here’s one from a similar test a day before.
meetlog-test.txt (441.7 KB)

So, there you have it.

One deeply-concerning observation is that the link/feature “Save Logs” is actually available to ALL participants in a meeting (not just the authenticated moderator). This log contains very sensitive information (IP addresses, server details e.t.c…). Not sure why making this information available to all participants was considered a positive, but it’s not an exposure I can risk. So, I’ll be downgrading my Jitsi to a previous version - for that reason and also for these feed quality issues.

Are you saying that you were running 2 browser instances on the same mac. That would be a no-no when you are measuring performance. The browser automatically throttles the send resolution when it is cpu constrained.

I factored that into the test, that’s why I had another machine as well as a mobile device.

@jallamsetty, fact is there is a performance issue with this version. I downgraded to the previous stable and immediately, performance went back to stellar (without even doing any adjustments whatsoever). It was immediately obvious even just looking visually and of course when I checked the stats, they were much better.

Hello

I started jitsi meet with kubernetes.
I am based on this project:

I manually applied the content of the latest commits to support websockets.
It works in my kubernetes cluster.
However, I have errors for the E2E ping.
As well as the video quality for the remote participant remains fixed on 320x180 on my PC.
This is of course produced for all participants regardless of the PC.
I configured the new limits as mentioned above, disabled simulcast.
I am at the end of the solutions

Do you have an idea ?

Thank you