Issue with low quality video

We are running the latest version of the stable released Jitsi Meet on our own server. It is NAT’d but all ports are open, etc. The VM we are running it on has 16GB RAM, and a Xeon 2.4Ghz (1 core allocated) CPU.

We use the Jitsi Android client to video operations in a factory environment with people connecting remotely to via this. On the LAN the quality is in SD, and externally nearly ALWAYS LD. We rarely get HD. The network is a 10GBit network, with a 200mbit fibre connection to the internet. We struggle to get more than 2 or 3 people with good quality video connecting with Firefox, Chrome, Edge, etc. Tried multiple clients, Wifi, 4G, LAN connections. etc.

The configuration files are more or less default (we’ve changed the watermark image). Today I could connect with Firefox and see the video (in SD), but Chrome showed nothing from the same computer. Multiple months we’ve been trying to get at least SD quality video over the internet and LAN, and it just doesn’t work. Please can someone assist us with this?

Thanks

Not sure how long you’ve had your installation, but you should consider updating to the latest stable release (came out a little over a day ago, if I’m not mistaken). Perhaps that would solve your problem. There were some performance issues with the previous release.

Freddie thanks. We do quite regularly do an apt update, though there is one waiting (we have to do it out of hours, so from home). It has solved the CPU leaks (i.e. over a week or two it gets to 100% load with no usage) and that seems to work.

Surely we should be able to have a 5/6 way video call without ANY issues, and in at least SD quality?

I believe you should, looking at the stats of the resources you’ve posted, although being that it’s on a VM, I wonder if that could have some impact. Notwithstanding, just to rule out any other issues, try updating to the latest stable version first and then go from there.

Thanks again for your reply freddie. On what you said we updated this morning when i read your message (not happy on the shop floor as took down a meeting, oops).

Anyway, we all connected locally over the LAN with 2 video feeds using FF, Chrome and Edge to watch. SD was fine. When connected with a android app everyone dropped to LD, and when they DC’d it stayed in LD, if a video sender DC’d and then joined again they were back in SD (we didn’t get to HD). CPU usage on the server remained < 20% for the duration, and dropped to 2% when meeting ended. The NAT, etc is fine, although we were all LOCAL this morning on a goodLAN (min 1GBit)/Wifi.

Frustrating as really love the look of this project, but we’re struggling to get buy in as text that needs to be visable on the normally ONE video sender (from an Android phone) is unreadable in LD, is fine in SD, but HD we’ve not managed, and SD we can’t get stable. Very strange

Just wondering what impact using Android phone, Firefox, edge, chrome etc mixed has an impact? I can’t really work out (and we’ve been using Jitsi for months now) what impact using different clients has. We can’t control external viewers, but getting it to work reliably locally is proving problematic. This morning on my PC I could see video on FF and Edge, but not chrome (from a FF video source, and we’re on the same 10gbit switch!)

So, there was a decision made not too long ago to limit resolution on mobile devices to 360. I’m not sure if that’s playing a role here. I find it interesting that you’re not getting HD at all, even with just 2 participants. Personally, I don’t allow Firefox on my installation because it’s just been known to be a resource-hog (that may have changed in recent times, but I don’t bother risking it). I mandate Chrome on my installed instance.

I’ve seen some mention about disabling layer suspension to remove the hard-coded limit on the mobile resolution. Maybe try that? Screen Shot 2020-10-16 at 11.58.33 AM

Also, did you play with the resolution settings to see what difference that makes?

Both of these can be found in the config file (/etc/jitsi/meet/example.config.js)

Have you considered maybe building a test image to see if you somehow missed something in the initial deployment? That’s what I would do, at the very least. Honestly, I would just do a complete overall (start from scratch, like on a weekend when there’s no production use). I feel like something is not configured properly and that could be affecting your performance.