META: Firefox rendering issues since ~117

[saghul]

#13932
#13918
#13864
#13860

[fippo]

tagging @Pehrsons (hey, you should know each other by now!)

[Pehrsons]

We don't support encoding svc so we do not have any tests on decoding svc. To my knowledge there are no recent changes to Firefox here, so I'd be surprised if it's a regression in anything close to 117. If a regression is suspected however, please run through mozregression, and if something sensible shows up, please file a bug.

Have any changes been made recently to enable VP9 or SVC on jitsi's end?

[jallamsetty1]

@Pehrsons We had enabled K-SVC for VP9 on Chromium a while back but until recently we used to force Chrome to switch to VP8 whenever a Firefox endpoint joins the call.
Recently, we introduced support for asymmetric codecs in Jitsi so we enabled VP9 decode on Firefox. So instead of forcing all other endpoints to switch to VP8, we now let Chrome endpoints continue to encode in VP9 and they decode VP8 from Firefox.

Please note that these issues are reproducible only on Linux/Ubuntu. VP9 decode seems to be fine on both Windows and macOS.

[Pehrsons]

Are you sure you are not hitting bug 1832276 on mac?

[jallamsetty1]

Are you sure you are not hitting bug 1832276 on mac?

Jitsi uses K-SVC L3T3_KEY or L3T3 mode for VP9 encode on Chrome and in both of those cases, Firefox is able to decode the highest spatial layer on my M2 mac and the quality looks good.
I did have media.navigator.mediadatadecoder_vpx_enabled set to false in Firefox settings. when I flip it to true, Firefox is able to decode 720p as per stats but the quality looks bad. Is this what you expect?

[Pehrsons]

That sounds like bug 1832276, yes. If you check the videoWidth and videoHeight attributes on the video element you'll see what resolution was decoded.

Also if I turn on screensharing in jitsi on a chrome peer in a 3-way meeting, I see some corrupt decoded video in Firefox on Mac (using our decoder on top of Apple's VideoToolbox).

For some reason the remote camera streams were decoded with ffmpeg and that seemed to display the highest layer, but colors seemed a bit saturated.

I'll see if I can switch us over to a libvpx decoder until we can fix the regular decoders proper. We want to avoid libwebrtc's libvpx decoder (the one you get with media.navigator.mediadatadecoder_vpx_enabled=false) because it runs directly in the content process.

[Pehrsons]

I have filed bug 1859880 for this.

[saghul]

Thank you!

[Pehrsons]

This should work better in Firefox 120. It will all be software decode of vp9 for now, unfortunately also in non-SVC cases.

[himpierre]

What's the developers advice on how to deal with that firefox problem currently? Let's hope firefox 120 solves the issues but until then? Is unconfiguring vp9 support the way to go? Or should we disable the vpx decoder? Should we quit using firefox altogether for now? I'm a little bit confused right now. :)

cheers!

[jallamsetty1]

What's the developers advice on how to deal with that firefox problem currently. Let's hope firefox 120 solves the issues but until then? Is unconfiguring vp9 support the way to go? Or should we disable the vpx decoder? Should we quit using firefox alltogether for now? I'm a little bit confused right now. :)

cheers!

Can you try flipping media.navigator.mediadatadecoder_vpx_enabled to false in about:config and see if it fixes the issue for you?

[himpierre]

What's the developers advice on how to deal with that firefox problem currently. Let's hope firefox 120 solves the issues but until then? Is unconfiguring vp9 support the way to go? Or should we disable the vpx decoder? Should we quit using firefox alltogether for now? I'm a little bit confused right now. :)
cheers!

Can you try flipping media.navigator.mediadatadecoder_vpx_enabled to false in about:config and see if it fixes the issue for you?

I set this to false but still no video from other participants. Thanks though for the effort.

cheers, t.

[jallamsetty1]

I set this to false but still no video from other participants. Thanks though for the effort.

These are 2 different issues. The workaround that I provided earlier was for fixing bad video quality seen on Firefox endpoints. If you do not see the videos all together, it is because of bridge suspending video because of low bandwidth estimate. Are you seeing this on meet.jit.si or on your own deployment?

[himpierre]

On my own. Alright, your question suggests there will be a fix for wrong bandwith estimation in one of upcoming releases? cheers! Am 9. November 2023 18:25:02 MEZ schrieb Jaya Allamsetty ***@***.***>:

…

> I set this to false but still no video from other participants. Thanks though for the effort. These are 2 different issues. The workaround that I provided earlier was for fixing bad video quality seen on Firefox endpoints. If you do not see the videos all together, it is because of bridge suspending video because of low bandwidth estimate. Are you seeing this on meet.jit.si or on your own deployment?

[G0rd0n]

A solution for this would be great. It is quite helpful to actually see my coworkers in online meetings.
In the meantime, how would I go about fidgeting with the settings myself?
Do I go into Firefox Inspector or something like that? And which parts do I edit? This is my first time going to this level of depth, so I'd really appreciate a referral to online resources for some self-study.

[Pehrsons]

One can set some prefs on about:config (enter it into your address bar like any other URL), but I don't recommend it because it's to forget to restore changed prefs when no longer needed.

Firefox 120 with the fix should be rolling out tomorrow (Nov 21) though, so hopefully you can use that.

[G0rd0n]

@Pehrsons , thank you. This was indeed one of my idea's (and valid concern about forgetting the edited settings).
I had read some threads about using the Firefox inspector to download parts of the code, edit it where useful, and paste it back via the debugging console etc. But my lack of experience made me think twice about that whole process.
I will update asap and hope this will resolve some issues that became a hindrance during meetings.

[yashirot]

Hi,
I've been watching here once a while since I had a similar problem.

Now I'm happy to comment that my problem has gone after Firefox on my PC got updated to 120.
Thank you for providing good info with me!

FYI, the symptom I faced on meet.jit.si was that

• a shared screen blacks out just when a third participant joins
• it gets blurred after ending and getting started sharing the screen again

This happened only if a first and/or second participant join from Firefox.

Regards,

[jallamsetty1]

Closing this issue since all the issues related to Firefox have been fixed.

[ibrainventures]

@jallamsetty1
I am using the upcoming (24th of January) FF (Developer) Edition 122.0b4 64Bit Win10
and failing on a re-visit of a 1-Person (P2P) Conference Room. No Problem
with the public FF 121.xx Edition.

On the FF 122 Edition, the Stream shows / displays for a Microsecond up and then
it is getting black, audio works fine. No special happening in the Log files or in the
Stream Details. If it works (2 of 10 tries) it shows opus vp8.

I cant find any Web-RTC related changes in the changelog for FF122. May you have a
idea what is happening or coming?

(Jitsi Setup: Fresh install - yesterday - complete self-hosted on Ubuntu 22)

[TEQSConsulting]

@jallamsetty1 I can confirm what @ibrainventures says. With FF 122.0 (64-bit) - the current FF version - we have problems with video streaming. When Firefox users turn on video, all other browser clients do not see the video streams.
Sometimes when FF users start video, all other clients see the video stream short-term, but as ibrainventures says, only for a short time, then it goes black.
We also have the sporadically problem that FF users don't see the video streams of other browsers either. But as I said, this doesn't happen every time, it's rather sporadic.

[saghul]

Are you testing on meet.jit.si or a different server?

[ibrainventures]

This bug also exists on the (public upcoming) 123.xx FF Version ..

I invested 50+ Hours to find any bypass / workaround for this nasty bug.
Chrome or Safari as first / second Client, Websocket / Bosh, Public / vs nat-ted IPs,
different Video Resolutions, VP8 vs VP9 favorited, last 3 Editions of Jitsi-Meet Gits, and many more.

There is no "rule" or issue step-by-step logic. Mostly it happens when the
FF Client is "dithering / initial freshing" the incoming Video Feed (this first microseconds of
a Videofeed Element) on a re-visit with p2p,

It feels like this / the Videoelement has no (more) DOM Element, as the video element is
like magic "away"... (may some requestAnimationFrame / or timeout Logic may help to debug?)

Mostly, after the FF Client cant display the p2p Partner Stream it only helps to close the FF Task
completly.

Actually i disabled p2p in the config.js globaly, the get a more stable system for my FF customers.

[jallamsetty1]

@ibrainventures, thank you for the analysis. I am able to reproduce this with FF 122 now when I leave and quickly join a p2p call with Chrome. The remote media doesn't render on Firefox because the browser doesn't fire a canplaythrough event on the remote video element. It thinks that it doesn't have enough data to play the media. Since it happens only in a p2p call, I suspect its a Firefox bug. Will dig a little deeper and open a bug report.

[ibrainventures]

@jallamsetty1
Thank you very much for taking over. My FF 122 / 123 (on my own webapps) getting much more "picky" for getUserMedia constraints then the older version(s). It also fires much more Domexceptions according to play etc. handlings .. than before / or the current Chrome. It was so (nice) lazy :- ) ..

Btw, may you or @saghul can please answer a simple question: Is it necessary after a change in xyz.config.js to restart all / any (jicofo, videobridge, ..) services if there is no user on / inside the system to take effect?

[saghul]

No need to restart, just refresh the page and the new config will be used.

[Pehrsons]

Speculatively, but sounds like bug 1874471 might be a candidate.
If you figure that it is a Firefox bug, please gather logs (WebRTC preset on about:logging, upload the profile including hidden threads so you get a link for sharing) and file a bug with that link on bugzilla.

@ibrainventures you seem to suggest that there is a regression. If you think it's a bug please figure out the cause with mozregression and file a bug per above.

[ibrainventures]

The Issue-Opener of bug 1874471 points his version to the FF 120 release. May its a typing error - because he reported it 14 days ago, where the Version 121 was public and 122 in the dev-edition release.

I saw this issue three weeks ago coming (and commented here), as i had FF 121 and dev-122.00 parallel running.

It was fine under FF 121.xx for the complete Livespan (till my update today). 100% reconnect success.

And it started on FF (dev edition and now the "regular") 122 from the first 122.00 release.

[Pehrsons]

Like I said

please figure out the cause with mozregression and file a bug per above

[jallamsetty1]

If you figure that it is a Firefox bug, please gather logs (WebRTC preset on about:logging, upload the profile including hidden threads so you get a link for sharing) and file a bug with that link on bugzilla.

@Pehrsons Thank you, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1877552 for this issue. Please let me know if you need any other information.

[jallamsetty1]

And it started on FF (dev edition and now the "regular") 122 from the first 122.00 release.

@ibrainventures, this should be fixed on meet.jit.si now. Thank you for bringing this to our attention.