Consider upgrading to the latest version.
But for the latest version I need prosody 0.11, am i right?
If your distro is not old then it has
prosody 0.11 in its official repo
We use the Ubuntu 18.04 LTS distro and there ist only 0.10.0-1 in official repo.
The server is used in a private network, with no connection to the internet. My last try
to install the prosody 0.11 source code manual, ends with a backup restore.
this problem still exists in latest stable. is there any fix or did i miss some info about which version should be used to fix this issue?
I have this problem on the latest stable Chromium (Raspberry Pi) and the latest stable version docker-jitsi-meet-stable-6726-1
I can’t update Jitsi at the moment, so i decide to downgrade. Is it enough if i only downgrade the jitsi-videobridge2 package? Or do you recommend all of them?
You should always run all component versions in sync. Downgrading just one can lead to unpredicted problems.
We’re also experiencing this with the latest update. Any ideas how to disable it?
We’re also experiencing this. Is there a workaround? is bwe=false worth a shot? my users are using all kinds of different (sometimes crappy) connections…
This will create worse issues for you, particularly since some of your users don’t have the best connections. Better to set resolution constraints and perhaps switch to VP9.
Hello. Same issue today, for the first time of mine. I’m on a Win10 machine, with MS Edge //meet.jit.si page. The odd thing is I was the only one in the meeting who experienced this issue, where the others six participants had no problems on viewing me. I’m sure I had the widest broadband connection among us, as I am on a T1 line, and the others were on DSLs, with two of them connected by their mobile phones. I wasn’t able to see all of them seconds after I entered the meeting room, but they saw me properly. No problem with audio.
I tried to search the avaliable meeting interface options, finding nothing useful but the “FellowJitster video was turned off to save bandwidth” message.
I read some posts here-and-there on the chat, but they speak about JSB settings or similar, and I have no idea on how to correct it - whatever it could be - and how could happen it has changed (as I never experienced this before). I wonder what could I do if this happened to an elder participant to the meeting.
it seems to me this issue is not really related to bandwidth, and not related on OS or browser. So devs, I wrote this hoping it’s helpful to find a fix.
This bug is so annoying. Why jitsi turns off the video without asking the user to do so? Isnt it possible to lower the quality rather than turning off the video when there is a bandwidth problem? Skype, Whatsapp, … all lower the quality and I have not seen a single app that decides to turn off the video out of a sudden except Jitsi.
So what exactly should Jitsi do when you don’t have sufficient bandwidth to support video? What should happen when your throughput just falls below the minimum required to send any kind of video stream? For 180p video, you need at least 200Kbps. What should Jitsi do when you only have 100Kbps, for instance?
I think the current policy may be a little bit aggressive. I mean restoring connection takes time and sometimes it may not be restored unless the user rejoins.
This, I think, is a legitimate argument. But it’s important to understand the challenges around bandwidth management. BWE (Bandwidth Estimation) is probably the most challenging aspect of WebRTC. There’s no single or simple perfect solution - you’re always trying to find a sweet spot between providing a reliable, steady stream that’s synchronous with actual activity and handling the unavoidable issue of occasional packet loss. What to do when throughput falls below what’s functionally possible to stream video is usually the big question. Should the last frame just be left frozen in place? Should the screen go blank? Should the screen go blank with a notice? So many considerations. But what’s inevitable is that packet losses will affect stream reliability. And that’s just a caveat of WebRTC (and frankly, videoconferencing in general).
I fully understand. This is why simulcast is a good solution. I think having few frames is better than none. It is subjective.
It’s not just the number of frames, it’s the availability and synchronicity of the frames.
Congestion control is not the easy ABC most people like to think it is. Think of it like a pipe funneling water. If there’s a temporary blockage in the pipe, water is pooled behind the blockage at a higher pressure. When that blockage is eased, all of that pressure bursts through pushing the water molecules at a higher velocity. So, first, water flow trickles to a stop (slows down), then gushes to relieve the pressure (speeds up) and then attempts to reattain normal velocity.
In the case of videoconferencing, when the throughput drops, video is no longer being successfully transmitted, so you have a congestion. When the throughput rises again to the point where traffic is possible, you have the option of completely dropping the congested frames (in order to keep the resumed stream synchronous), or allow all of the congested frames to go through (which means fast-forwarding and losing sync since light and sound don’t travel at the same speed). The latter will result in much worse and longer bad stream experience. Simulcast helps a ton, but it doesn’t completely eliminate bandwidth issues.
And it is absolutely untrue that this issue does not exist in Whatsapp. If throughput drops below a usable level in Whatsapp, you get a frozen, blurry screen with the word “Reconnecting” at the top of the screen. Every videoconferencing solution deals with this. In the case of Zoom, audio and video sync is further worsened (it’s already bad to start with) and affected participant loses video.
Quick question: I was under the impression that the problem that has been discussed in this thread for a while now is related to using firefox in a conference. Because the last posts are now talking about managing bandwidth in general.
For me it is still the case that https://meet.jit.si/ works perfectly fine when participants only use for example Chrome browser. However as soon as I try it with Firefox the “Video turned off to save bandwidth” problem occurs even though there is enouogh bandwidth.
So I was wondering if there is an agreement that there is a problem specifically with firefox or did i get that wrong? If so, is there an open Issue somewhere for this problem?
Any soluyion guys. This issue is hurting us too and we are not able to move apps to the next level beacuse QA team is continously rejecting it.