Poor Video Quality Latest Jitsi Update (5142-1)

@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

Freddie,
I am having the same issue of video quality is sort of average, lot of pixels appearing, which does not give a smooth view.
Can you please share your findings what to do and if possible share some settings to achieve the best video quality results.

Thanks in advance.

I responded to you on your other post.

Thanks Freddie.
Are there any specs by default how many concurrent meetings and number of users can be handled by Jitsi?

I am using AWS memory intensive server, R5.xLarge.

How do you access this dialog in the browser showing bitrate, resolution, fps and so on which is on your screenshot where is tutorial to see this data?

If you move your mouse pointer to the top-left corner of a video feed in Tile View, you’ll see the indicator pop up. Check out this comprehensive user guide for more information - Comprehensive Jitsi User Guide

@Freddie, can you describe here what you think is broken in unstable ?

@jallamsetty Oh, sure.

I lowered the threshold for requesting HD resolution. When I do a 2-participant call, I get 720p as expected with tile height at 360p:

However, once a 3rd participant joins, the constraint is ignored and resolution falls to standard (at the same tile height):

But what about ramping up? If you wait a bit, it does not change?

@Freddie The client can request only 2 HD streams by default. There is a setting maxFullResolutionParticipants in config.js that lets the client request more HD streams by changing the minHeightForQualityLvl thresholds. If the client was able to request >2 HD streams without changing maxFullResolutionParticipants then it probably was a bug which got fixed by my latest changes.

You can check for the below log:
Here, the threshold for HD is 540, so client still requests 360p from the bridge.
2021-05-17T17:57:14.725Z [features/video-quality] <Object.H.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 424, is: 360, override: false, max full res N: 2

Here, the threshold for HD is 360 but its overriden since maxFullResolutionParticipants is set here to 2, so 360p is being requested from the bridge.
2021-05-17T18:14:53.490Z [features/video-quality] <Object.H.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 399, is: 720, override: true, max full res N: 2

Here the threshold for HD is 360 and maxFullResolutionParticipants is set to 6, so 720p is being requested from the bridge.
2021-05-17T18:16:44.875Z [features/video-quality] <Object.H.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 399, is: 720, override: false, max full res N: 6

3 Likes

@damencho no, waiting did not change the behavior. Jaya’s explanation helps to throw light on what’s going on.

@jallamsetty Thanks! This makes complete sense. I have in fact seen that property but never really tinkered with it. I’ll test this out later tonight.

In line with that though, is there any concern raising the number of HD streams the client can request (assuming bandwidth is sufficient)? I imagine it saves bandwidth to limit the HD streams, but in a case where available bandwidth is not really an issue (or participants can be advised to switch to lower resolutions on the fly), is there any potential detriment to raising the number of HD streams to the client?

Even if the client has enough available bandwidth, it might have not have enough cpu to decode multiple 720p streams, especially on low end systems. There is no mechanism available yet on the client that will detect this state (lagging videos and client becoming unresponsive) and take appropriate actions for recovery.

1 Like

@jallamsetty Thanks so much. This again makes absolute sense.

To the original issue: I ran a few tests, playing around with the values for maxFullResolutionParticipants. As detailed in your example, changing the value works - for VP8. For VP9 though, it appears that property is not considered.

I ran the same test using the same everything, but just changing the codec. The threshold for HD is set to 360 and maxFullResolutionParticipants is set to 4.

For VP8:
2021-05-18T01:31:21.885Z [features/video-quality] <Object.H.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 522, is: 720, override: false, max full res N: 4

Here, all videos (in tile view) are displayed in HD [720p]. Works as expected.

For VP9
2021-05-18T01:38:07.684Z [features/video-quality] <Object.H.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 522, is: 720, override: false, max full res N: 4

Exact same setting, but this time, all tiles display in SD [360p]. Not the expected result.

So it appears the constraint is not being respected by VP9. Or perhaps there’s something else I need to tinker with?

It’s interesting to note also that in both instances, the log says the override is false, but in the VP8 case, it actually worked as expected.

1 Like

Hi Freddie,

Even with 2 participants, I got low resolution on my test. I could not succeded to get full resolution with the new VP9 Support Jitsi VideoBridge commit. I had no problem with 5142 for VP9 btw.

I just tried requesting 3 720p streams and the client was receiving 3 remote 720p streams from the bridge. Depending on how you are testing it, it is possible that the encoding clients are not able to encode full 720p if you are running multiple instances on the same machine. VP9 is more cpu intensive than VP8 and that would explain why VP8 would work for you but not VP9.

1 Like

Hi @jallamsetty,

Can you advise on how you tested (presumably with VP9)? No, this is not a cpu issue - I tested initially on a 12 core, 32GB Mac Pro that handles almost 30 users (tabs) reasonably easily. For this test, I only ran 3 tabs (2 on Brave, one on Chromium).

But to rule out the possibility of resource-constraints, I just checked with multiple machines and the results are the same - 720p with 2 participants, once a 3rd participant joins, downscales to 360p.