Jitsi available in HD, but recordings and YouTube streams are in horrible resolution

I’ve installed Jitsi by using the docker-compose solution. It works very well. However, when I record and stream a conference, it’s displayed in a horribly low quality. While the participants all have a 720p resolution. And during the conference the quality is satisfying, but somehow this is not saved like that.

It can’t be bandwidth or server resources. Because the server is basically doing nothing (4GB RAM and 2 cores), storing locally shouldn’t come with bandwidth issues. And when I do, I think 1Gbit/s is sufficient :slight_smile:

I suppose it may be an ffmpeg issue? That the conversion is set to a low resolution? When I check the resolution of the video it still says 720p, but the image quality is just heavily pixelated.

Any advice? Is this a common thing and I just missed a magical config setting like originalQuality = true;?

Do you have additional JVBs or websocket issue?

I only have one JVB and I guess I do have a websocket issue, because my Jitsi setup only works when I set ENABLE_XMPP_WEBSOCKET=0 in .env, this was based on this issue: ENABLE_XMPP_WEBSOCKET=0 with nginx reverse proxy · Issue #902 · jitsi/docker-jitsi-meet · GitHub

I also use a reverse proxy on my Docker host to forward incoming requests to the Docker containers. This is how my config looks like:

server {
  listen 443 ssl http2; listen [::]:443 ssl http2;
  server_name host;

  ssl on;
  # change these paths as necessary
  ssl_certificate      /etc/letsencrypt/live/host/fullchain.pem;
  ssl_certificate_key  /etc/letsencrypt/live/host/privkey.pem;

  ssl_protocols TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  add_header Strict-Transport-Security "max-age=63072000;";
  ssl_stapling on;
  ssl_stapling_verify on;

  client_max_body_size 0;

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

    proxy_pass https://localhost:8443;
    proxy_http_version 1.1;
    include proxy_params;

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

I suppose this is not correct then? When I check the Docker docs again: Self-Hosting Guide - Docker · Jitsi Meet Handbook

They mention “Note that HTTP (not HTTPS) is also available (on port 8000, by default), but that’s e.g. for a reverse proxy setup; direct access via HTTP instead HTTPS leads to WebRTC”.

I tried to set the proxy to port 8000, but then nothing happens, I get a 502 error on the page.

I also see other topics about this and that this issue started to appear with recent Jitsi versions. I only host Jitsi very recently, so I wouldn’t know. So perhaps it’s a bug or something?

Jibri currently records in 720p (the resolution of the actual Chrome window) so it’s possible we request a lower resolution because the video element is a tad smaller.

We have switched to 1080p recorders, but Jibri in Docker hasn’t been updated yet.

Interesting. But my Chrome window is in 1080p and the streams were according to Jitsi in 720p. So it would be strange if a lower resolution was taken somehow.

Do you know when we can expect the new Docker containers? In meet.jit.si there is a new UI and some new features available. It would be cool to have that in my self-hosted setup as well.

Thanks for all your work! This is truly impressive :slight_smile:

Your window size is not relevant. Jibri basically opens Chrome and records its output using x11grab with. The X server where this Chrome browser runs has a resolution of 720p.

A new release is planned very soon. You can rebuild the images to the “unstable” repo yourself (see the Makefile) to check the latest features, but I don’t think 1080p Jibris are going to make it to this release.

Ah okay, I use Wayland already for a few years on Fedora. I’ll downgrade my session to X tomorrow or so and try again then. Hopefully it’s not related to that, I kinda like Wayland :slight_smile:

No no, no need to do that. Jibri uses X, you can use anything you want.

1 Like