Friends, a question: Is our Jitsi server intentionally set for only low definition? I try to use it as much as a I can—largely to show people that co-op videochat is possible—but people are often disappointed by the low video quality. I know we’re also trying to accommodate quantity perhaps more than quality. But is there a way we can afford bringing the video quality up a bit for evangelization purposes?
Thanks to all those who make this Jitsi service available.
Hi Nathan - Thanks for checking in. And the short answer is yes, we do intentionally lower the quality in an effort to avoid problems on the client side, particularly when people connect with lower powered machines.
I think in particular, it’s this setting, which sets the max height to 240 pixels, which is fairly low quality. And, if you are in a one-on-one call, in which you are seeing the person you are talking to in full screen, it won’t look great (on the other hand, in gallery view it generally looks ok unless the quality has been downgraded due to a detected low bandwidth client).
constraints: {
video: {
aspectRatio: 4 / 3,
height: {
ideal: 240,
max: 240,
min: 120
}
}
},
I think we may want to experiment with increasing it… but I’m not sure we’ll want to do that until after the final membership meeting in early December. This year we’re going for it and organizing all of our membership meetings on Jitsi Meet for the first time ever. I’m pretty sure we’ll do fine for the discussion metings which generally don’t draw more then 20 or 30 participants. But, our main meeting in December will need to draw at least 60 and could have up to 100.
I’m not sure we’ll go forward with Jitsi Meet on the last meeting unless it goes super smooth for all the initial meetings.
On the other hand… we are limiting the system to just 8 active video streams regardless of how many people are on the call. So maybe if we increase this limit and it works with meetings with more then 8 people, we can expect it to work the same regardless of how many people are on the call?
Open to suggestions.
Thanks for this. Yeah, I would definitely be in favor of upping the quality a bit. I generally use Jitsi just for 1x1s because the quality tends to fall off with larger numbers.
It might be worth considering using meet.coop’s BigBlueButton for the meetings, since it can handle breakout rooms and the like, and is designed for bigger groups (though it too has trouble with lots of people on camera at once). But not sure how it is with simultaneous interpretation, which I know you’ve been working on with Jitsi.
I really like Jitsi for its simplicity and intuitiveness, and I’m so glad we support it. I just want people who experience it to feel like co-op hosting is a real alternative, not a crappier version that makes them wish they were on Zoom:)
Jitsi meet is supposed to be capable of adjusting the quaility based on bandwidth automatically based or user preference. In our early tests this didn’t work as well as we hoped.
I was originally a proponent of intentionally limiting to a much lower quality and members with low bandwitdh requirements in Mexico for example have definfitely commented to us that they’ve had more success using our instance for larger meetings compared to the main Jitsi meet instance. But another thing has always been true since we did this and that is some browser client combinations simply do not respect the video quality restriction and I will often be in a meeting with varying levels of video quality. I think this is because the limit we set is not something the server can actually enforce as the server does not do the encoding, rather it becomes a suggested preference for the javascript client where the encoding actually happens. But some browser clients don’t get the message and simply ignore it. I’ve also noticed that the browser client allows you to select quality and assuming that preference actually works I wonder if it is possible to simply override our suggested preference by setting it yourself? I’d be happy to connect and try this with you.
Thanks for sharing about the Mexico context. Makes a lot of sense, and we want to prioritize use-cases that are not well served by other options.
Yes, I’ve been wondering about that override. Currently it doesn’t seem like it works. But maybe if we kept ideal at 240 but raised the max, that would allow users to override?
Something to share and keep in mind is data consumption impacts the environment and energy usage. Improved video quality increases data consumption. This makes Mumble more attractive from an environmental perspective, too, and is a good reason to reduce to retention of all emails, etc., as well.
Kate Singer has been writing ‘Letters to Greta’ on the costs of technology, and she has one about online meetings which provides some calculations. #44 | Reduce Our Internet Footprint
I’m full on reducing our impact on energy and more.
However, I do also recognize that audio only is not the same and audio and video.
I’d like to experiment with frames per second (FPS) as the limitation.
Based on some old experiences I believe that a low video refresh with a high audio quality uses less bandwidth but keeps the “feeling” of the live conversation.
Can we experiment with something like this in our Jitsi instance and measure it?
Thanks for this. I only recently learned about how significantly video framerate affects energy usage. I would like to withdraw my proposal above and redirect it toward an education proposal: Is there a way we can better educate our members on why we use lower framerates, and on how that is part of a strategy for reducing our collective environmental impact?
Perhaps, for instance, there could be a message at the https://meet.mayfirst.org, or even a pop-up in Jitsi itself to inform new users why the quality is lower than they might be used to.
Ultimately it is up to each browser to respect the video size and framerate defaults we set through the server and they don’t all do it. I think creating documentation about how to adjust Jitsi locally for low bandwidth consumption makes sense and we may want to go ahead and increase the default resolution, (keeping framerate low?) .
Good enough for now and safe enough to try. 
What parameters can be set from the server that don’t depend from the browser?
(a looong time after) If someone points me to the documentation to do this, I can create a wiki page explaining it.
(muuucho tiempo luego) Si alguien me apunta a la documentación para hacer esto, puede crear una página en el wiki que explique cómo hacerlo.
Sorry I never followed up here.
Our current settings are:
constraints: {
video: {
aspectRatio: 4 / 3,
height: {
ideal: 240,
max: 720,
min: 120
}
}
},
The default minimum is 240 (so we lower the bar - allowing a client to choose a smaller image). And the default ideal is 720, so we are aiming for a lower resolution by default.
On my browser (using Chromium), my preformance setting is already set to highest quality. I checked my console output and I changed it and see a message saying: Setting sender resolution to XX depending on what I choose:
So… I’m not really sure what this means…
Me neither, but I’d like to help too.
I will be happy to make a wiki page helping people with low-bandwith to use our videoconference services, but I need someone who knows about this.
Does someone knows about this things, or someone who does? I can arrange a talk with that person and after it, will make a draft.
Yo tampoco, pero también quiero ayudar.
Me encantaría hacer una pg wiki para que las personas con poco ancho de banda puedan usar nuestros servicios de videoconferencia, pero necesito a alguien que sepa de este tema.
Alguien sabe, o conoce a alguien que sepa? Puedo combinar una charla con esa persona y luego arma un esbozo en el wiki.