Closed bradkrane closed 1 year ago
Is this on meet.jit.si? Do you reproduce the issue with previous versions of Firefox? Do you reproduce the issue with chrome?
I've encountered the same problems with a flaky video connection on an older jitsi version as well as the latest one. I think the bug is related to changes in the latest Firefox version (117, 64bit, Linux) as chromium seems to work fine for me. When I downgraded to FF 116.0, the video-connections returned to the expected normal behavior
I have seen this issue on previous versions of Firefox maybe the last six months of them. If that's the issue it's the worst it's ever been. I can't see that though as Firefox conforms to standards obviously and it should work regardless.
I've been connected to another server I'm not sure the version I will figure that out & post back!
I can reproduce this over my LAN with Jitsi 2.3-25-g1da507fa-1 and Firefox 117, both client and server running on Ubuntu Linux 22.04. Chromium works well. I will try and grab bridge logs later today.
I had the same issue on:
With Chrome Version 117.0.5938.62 (Offizieller Build) (arm64) its seems to work normally again.
Has been happening for a while. Also see https://github.com/jitsi/jitsi-meet/issues/12578 Experiencing this with 117.0.1 on MacOS, Windows and Linux, regardless if connecting a local jitsi server or hosted ones or meet.jit.si . Other browsers work fine for us.
We are hoping that this will fix the issue.
@bradkrane The above fix has been applied to meet.jit.si. Can you please give it a try and let us know if the issue is fixed for you on Firefox 117?
Now we can see the green color of good bandwidth, but it seems that FF is not decoding vp9 as expected #10657, maybe we should open a new issue. In these tests, there is a Chrome sending video, other chrome's see it in 720p but the firefox is blurry. Firefox:
Chrome:
This seems to be separate issue like you said. I am closing this issue since its fixed.
When will this correction be released? Or has it already been released?
I believe it will be part of the next stable release. Or you could use the nightly / unstable releases.
To get this fix I updated my test installation to the unstable nightly from yesterday and I am still seeing the problem of Firefox 118.0.2 dropping the video streams and JVB generating messages like "Sources suspended due to insufficient bandwidth (bwe=-1 bps)". Would the Jingle messages to/from the client be helpful here?
@jallamsetty1 I had the same problem with Firefox >= 117 and Jitsi Docker ver. stable-8319. I tried on meet.jit.si and it seems work. I guess the fix will be release in the next stable release. When do you plan to release? Thx
This fix hasn't been released to the stable yet. We hope to make a stable release by the end of this week or early next week and that should include the fix.
To get this fix I updated my test installation to the unstable nightly from yesterday and I am still seeing the problem of Firefox 118.0.2 dropping the video streams and JVB generating messages like "Sources suspended due to insufficient bandwidth (bwe=-1 bps)". Would the Jingle messages to/from the client be helpful here?
Are only Firefox clients experiencing this issue? When you run into this issue, can you please execute the following on the browser console and check if that makes any difference?
APP.conference._room.setReceiverConstraints({ 'assumedBandwidthBps': 2000000 });
No difference after executing this command, got same issue with own jitsi instance
No difference after executing this command, got same issue with own jitsi instance
If this doesn't make any difference then probably there is a network issue in your instance. This command tells the bridge to ignore its BWE and assume the client has 2 Mbps downlink and send sources accordingly.
To get this fix I updated my test installation to the unstable nightly from yesterday and I am still seeing the problem of Firefox 118.0.2 dropping the video streams and JVB generating messages like "Sources suspended due to insufficient bandwidth (bwe=-1 bps)". Would the Jingle messages to/from the client be helpful here?
Are only Firefox clients experiencing this issue? When you run into this issue, can you please execute the following on the browser console and check if that makes any difference?
APP.conference._room.setReceiverConstraints({ 'assumedBandwidthBps': 2000000 });
That workaround seems to fix my issues :+1:
Any ETA for the next Jitsi release?
Facing the same issue here with stable version 2.0.9111-1. No luck by executing APP.conference._room.setReceiverConstraints({ 'assumedBandwidthBps': 2000000 });
.
Got the instance upgraded with much more network resources as well.
Connection status turns Poor on Firefox as soon as I turn video on.
I little bit random but usually after open 3 or 4 tabs the video is suspended.
BTW, I could not reproduce the same scenario on meet.jit.si.
Which Firefox version? There is a known issue with SVC handling that has been fixed in Firefox 120.
see https://github.com/jitsi/jitsi-meet/issues/13933#issuecomment-1769251765
Which Firefox version? There is a known issue with SVC handling that has been fixed in Firefox 120.
see #13933 (comment)
Firefox 120 (Ubuntu 22/04)
Still experiencing it in 2 different environments. Everything works well on meet.jit.si
Video from Firefox has been suspended for other participants, usually when the fourth participant gets in, but its random. Something like this also happens when switching from tile view to full screen or even when participants resize the page. Looks like all the time resolution changes for some reason the application reacts and suspends the video, but only when the video comes from Firefox.
Are those environments updated to latest stable? That is the version meet.jit.si is running.
I just had this in a meeting running the latest release (9364) toward my own server, but not involving Firefox. Latest Chrome, Safari & Jitsi iOS app.
I just had this in a meeting running the latest release (9364) toward my own server, but not involving Firefox. Latest Chrome, Safari & Jitsi iOS app.
Hi, did the videos recover at some point? Can you please share browser console logs from the user who did not see the any remote videos?
It recovered when one participant left. Don't have the logs but I will keep an eye out and get back with more information if it keeps occurring.
Description:
I am experiencing an issue where I cannot consistently receive video from other participants. While others can view everything without any problems, I rarely receive any video. My bitrate usage indicates that the download bitrate is approximately 84 kilobits per second, whereas the upload bitrate can be and often is much higher. This is puzzling, especially considering the minimal bitrate required for video & And that my bandwidth limits and speed tests during the sessions indicate I can send or receive far more bandwidth.
Steps to reproduce:
Expected behavior:
I should be able to consistently view video from all participants without any interruptions.
Actual behavior:
While others can view everything without any problems, I rarely receive any video. When I rejoin the session, I can briefly see everyone's video, but it cuts out after about three seconds.
Server information:
Client information:
Additional information:
I've conducted a network speed test with my ISP, and my connectivity is significantly higher than the bitrate being used for the video download. It's worth noting that other participants do not face this issue, I do.
There are no errors in the dev console When experiencing the issue.
How can I help to resolve this?
I would appreciate any information on how I can help to come to a conclusion or resolve this issue.