URGENT - Low image quality after update

To give you guys more details. Our most recent instance runs on Debian 10. This is what got installed there:

prosody/stable,now 0.11.2-1 amd64 [installed,automatic]
jitsi-meet-prosody/stable,now 1.0.4466-1 all [installed,automatic]
jitsi-meet-tokens/stable,now 1.0.4466-1 all [installed]
jitsi-meet-turnserver/stable,now 1.0.4466-1 all [installed,automatic]
jitsi-meet-web-config/stable,now 1.0.4466-1 all [installed,automatic]
jitsi-meet-web/stable,now 1.0.4466-1 all [installed,automatic]
jitsi-meet/stable,now 2.0.5142-1 all [installed]
jitsi-videobridge2/stable,now 2.1-376-g9f12bfe2-1 all [installed,automatic]

The default configuration worked well enough. Videobridge communication was using websockets out of the box, which I was able to confirm by seeking WS communication in Chrome Dev Tools Network tab. Simulcast is ON.

The out of the box quality was not the best tough. I had to change few things in config.js.
I saw the biggest difference when I’ve changed videoQuality.maxBitratesVideo.high to a bigger value.
You should also note that I’ve seen an increased CPU usage due to those changes.

resolution: 1080,
// ...
maxFullResolutionParticipants: -1,
// ...
constraints: {
    video: {
        height: {
            ideal: 1080,
            max: 1080,
            min: 240
        }
    }
},
// ...
maxBitratesVideo: {
    low: 200000,
    standard: 500000,
    high: 2 * 1500000
}
// ...
desktopSharingFrameRate: {
    min: 1,
    max: 5
},

We also have a few other instances that were not updated properly and experience those quality issues, but I’m pretty sure it’s because of the missing websocket channel to videobridge.

1 Like

I do not know the details, but see enableTcc and enableRemb options in config.js. There’s a comment about it from the developer somewhere on the forums. Jicofo seem to be involved.

I was told lately that this part of the config file gets overide by the part at the end… Some other posts suggest that they both need to be setup… In doubt, I set both parts to the same settings !

Lower part:

Yeah, configuring jitsi is far some straightforward. Plus, it changed a bit recently. This post might be helpful.

I know… I made a bash script to override the settings after deployment… Makes the changes in less than a second! :slight_smile:

Ah, this thread helped a lot:

Yeah, but you can make them in 0 seconds by using the custom-config.js file. I have a script that “cleans” the config directory after I make changes to .env, but it leaves the custom-config.js file intact.

Good point! :stuck_out_tongue:

The thing is though, that my bash script is editable, and is the central point for all my settings. Some days we need 1080p res for “big presentations” and some other days we drop it to 720p… This is a single line in my bash file that I change and re-run… that is why I did it this way :slight_smile:

1 Like

What’s the expected out of the box experience with the latest release (stable-5390-3)? Because I have LD quality all the time, while the server has 2 cores, 4 GB of RAM and 1Gbit/s up/down link. It’s setup with the docker-compose method. My client has 16 GB of RAM and a modern i7 CPU using a 200Mbit/s up/down link. I’m using a Google Pixel 3 with the Jitsi app as a second client. Both clients work fine with HD when using meet.jit.si.

@AquaL1te check your js console for websocket errors.

1 Like

I do indeed see websocket errors. I run my Jitsi Docker setup behind a reverse proxy (Nginx). Could this be the cause of this?

The error I see is: BridgeChannel.js:86 WebSocket connection to 'wss://meet.host.community/colibri-ws/172.31.0.4/e7efe0a3544b0493/6f5a5a80?pwd=2tfiaorl15g7u1rj6ds54645nt

Obviously there is a problem with my Docker setup, right? So as the docs state, I put my public IP in the .env var DOCKER_HOST_ADDRESS. But now the error looks like: BridgeChannel.js:86 WebSocket connection to 'wss://meet.host.community/colibri-ws/192.168.0.5/dd877a811151ee47/e41ce275?pwd=25vk2u8vsvgtn9qln4g61lmv7j'

So, first error had the IP of my docker0 interface. And now it advertises the IP of my jitsi-meet_meet.jitsi Docker network bridge. Is the latter correct?


Or would this be the solution? This leaves me with a few questions.

  1. What’s the tradeoff to use websockets over WebRTC? Is there a downgrade in terms of performance or security in any sense?
  2. Is there an easy method to set this up with containers without creating a custom Docker overlay? I don’t see anything in the .env that relates to this (on first glance).

I tested all ports that should be open: TCP/80, TCP/443, TCP/4443 and UDP/10000. They are all responsive. Below is my current Nginx config.

server {
  server_name meet.host.community;
  include tls_params;
  include hardening;

  add_header Content-Security_Policy "default-src 'self'; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; object-src 'none'";
  add_header Content-Security-Policy "frame-ancestors forum.host.community;";
  add_header Permissions-Policy "microphone=(self),camera=(self),fullscreen=(self)";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Frame-Options "DENY" always;
  add_header Referrer-Policy "strict-origin";

  client_max_body_size 0;

  location / {
    error_page 502 =502 /errorpages/generic_offline.html;
    proxy_intercept_errors on;

    proxy_pass http://localhost:8000;
    proxy_http_version 1.1;
    include proxy_params;
  }

  location /errorpages/ {
    alias /var/www/errorpages/;
  }
}

The reason I want to use Nginx as a reverse proxy is to make use of IPv6. My VPS doesn’t have an /48 IPv6 subnet, so I cannot allocate a /64 IPv6 subnet for Docker. It’s also nice to have an offline page for when I rebuild my containers.

This is fine.

The problem is the reverse proxy. Documentation: Add Reverse Proxy Guidelines · Issue #962 · jitsi/docker-jitsi-meet · GitHub
You need to fix it for colibri-ws, the upgrade thingy…

With sctp channels we have seen random crashes when jvb is loaded, which we haven’t fixed.

For the rest, sorry, Docker is not my thing, and I cannot answer those questions …

1 Like

These crashes you mention here, are they incidental? When do they occur? When launching the Jitsi containers? Or when someone opens a meeting room? If it’s the latter, then a reconnect fixes it? Just trying to get the picture of how severe these crashes are. If it names Jitsi unusable in this setup or that it’s something a user can fix. It’s not perfect, but then at least there is a known fix :slight_smile:

Not known, at some point jvb crashes by segfault and someone need to start jvb process, if you have a single jvb this makes the whole system unusable till you fix the jvb.

1 Like

Is it this bugreport? videobridge crash SIGSEGV after SCTP resource temporary unavailable · Issue #6 · jitsi/jitsi-sctp · GitHub
Because then I might follow that bug report and in the meantime will just use Jitsi on a non-standard port (8443). Then the setup is easy and stable. Once that bug has been solved, I’ll put the reverse proxy in front of it again, create a custom Docker overlay with my websocket settings and done. :slight_smile: Not great, but not terrible either for the time being. Jitsi will mostly be used via the Discourse forum I host. So I can probably configure the Jitsi Discourse plugin to use this non-standard port, then it’s transparent for the users.

I doubt that this will be fixed, we tried years ago and we could not figure out anything … and we moved to websockets, and this is what we use in production.