Conference video quality drops when a user is on an Electron window

[jeanfbrito]

Description:

Hello, I work on Rocket.Chat and we are having some users reporting an issue with Jitsi.
On our Desktop app we open Jitsi inside a new Electron window.

In a conference (a meeting with more than 2 users) when a user is inside our Desktop App, the quality is dropped of video sharing for everyone.
I tried investigating what we could do to fix that, but doesn't seem to be something from our side.
On the console log, I could find that when an Electron client is connected the ReceiverVideoConstraints is set to "maxHeight":360.

There is any way we can change this? The only way today is to make the video call open on the browser.

Steps to reproduce:

1. Create a meeting with more than 2 clients.
2. Enter the meet with an Electron window.
3. All the videos will drop quality, users said that even webcam video drops the quality.

Expected behavior:

Work on Electron as it works on Chrome, if possible.

Actual behavior:

The video quality is dropped to 360p.

Server information:

• Jitsi Meet version: meet.jitsi.si version
• Operating System: unknown

Client information:

• Browser / app version: Rocket.Chat Desktop App
• Operating System: MaOS and Windows

Additional information:

[damencho]

Which version of electron is that?
It is normal to drop the video to 360 when you show the meeting in tileview. If you switch to stage view, only the stage participant will be requested with HD and the rest with 180p.

[jeanfbrito]

Which version of electron is that? It is normal to drop the video to 360 when you show the meeting in tileview. If you switch to stage view, only the stage participant will be requested with HD and the rest with 180p.

Electron 22, but I tested it even on Electron 27, and happened too. The video shared makes it unreadable when the Electron window enters the call. There is any limitations on the version known for this?

[jallamsetty1]

Can you check what is the tile height thats calculated on the electron client? The log should look something like this

2024-02-22T18:02:43.997Z [features/video-quality] <sF.register.deepEquals [as listener]>: Video quality level for thumbnail height: 587.5, is: 360, override: false, max full res N: 2

For example, in this case, the height of each of the tiles is 587.5 pixels, so the client is going to request the bridge to send 360p videos.

Only if the calculated height >= 720, the client will request 720p videos from the bridge as seen in the below log.

2024-02-22T18:04:57.845Z [features/video-quality] <sF.register.deepEquals [as listener]>: Video quality level for thumbnail height: 1078.1333333333334, is: 720, override: false, max full res N: 2

[moell9]

We have the same problem on our site. How can I check this in the electron client ?

[saghul]

You can enable developer tools and check in the console tab.

[jeanfbrito]

Sorry for the late reply, I got sick last week.
The size doesnt seem to deteriorate, I tried opening on big window sizes and seems to do the same thing.
The unique thing that I could see is that when there are more than two users the call changes to conference and stop using p2p and start using a url that shows on the console.
I tried opening more clients on safari and Firefox along and seems to be deteriorating too. So I dont know if there is any limitation on quality for conference?
I need help to understand what could do the screen sharing video decrease it quality and how this can be handled on this cases.

[jeanfbrito]

Can you check what is the tile height thats calculated on the electron client? The log should look something like this

2024-02-22T18:02:43.997Z [features/video-quality] <sF.register.deepEquals [as listener]>: Video quality level for thumbnail height: 587.5, is: 360, override: false, max full res N: 2

For example, in this case, the height of each of the tiles is 587.5 pixels, so the client is going to request the bridge to send 360p videos.

Only if the calculated height >= 720, the client will request 720p videos from the bridge as seen in the below log.

2024-02-22T18:04:57.845Z [features/video-quality] <sF.register.deepEquals [as listener]>: Video quality level for thumbnail height: 1078.1333333333334, is: 720, override: false, max full res N: 2

This will show on the console as the new users enter the call?

[saghul]

It will show up with layout changes.

[jeanfbrito]

It will show up with layout changes.

There isnt any log with video-quality nor nothing that is on the line of example. So dont seem to be this the change.

[jeanfbrito]

Chrome Screen sharer console log:
chrome screen sharer.log

Chrome viewer console log:
chrome viewer.log
quality:

Electron viewer console log:
electron viewer.log

quality after electron client enter the call:

[saghul]

Did you make window size changes, for example?

[moell9]

We did the following change from:
disableSimulcast: false,
to:
disableSimulcast: true,
And now we can use the application window again.
But I don't think this is a proper solution ?

[saghul]

Not it isn't. How big is your window and are you resizing it at runtime?

[moell9]

We are always working in fullscreen mode. The application window is I think around 800x600 at the beginning. That is the standard size. And we normally resize it to fullscreen.

[saghul]

Then you should see the messages @jallamsetty1 mentioned in the console logs.

[moell9]

Perhaps @jeanfbrito can test this. He is the developer at RocketChat.

[jallamsetty1]

Chrome Screen sharer console log:
chrome screen sharer.log

Can you please share the full log from the screen sharer? I see the logs only upto the moment when the electron client joined and nothing after so it is hard to tell if having the electron client in the call changed the sender characteristics. Please share the full log for both the sender and the electron clien.

[moell9]

I cannot open the developer tools (CTRL SHIFT I or F12) in the application window. Please tell me how to do this easily. It doesn't make sense to do this in the browser, because the problem doesn't appear there.

[jallamsetty1]

Are you saying that you are seeing the share blurry only on the electron client? If everyone in the call is seeing the share blurry as soon as the electron client joins the call then the problem should be on the sender.

[moell9]

Yes. Not only is the sharing blurred, but also the participants are all displayed with too low a resolution. Mostly in 180p.
With disableSimulcast: true, the resolution is fine, up to 720p and also the sharing.

[jeanfbrito]

Did you make window size changes, for example?

No because I was using fullscreen windows for testing, something near 1440p height.

[jeanfbrito]

Chrome Screen sharer console log:
chrome screen sharer.log

Can you please share the full log from the screen sharer? I see the logs only upto the moment when the electron client joined and nothing after so it is hard to tell if having the electron client in the call changed the sender characteristics. Please share the full log for both the sender and the electron clien.

It was my intention, let me do again, maybe I cleaned up before entering with other clients.

[moell9]

I can't see here any progress. The RocketChat users are waiting for a solution.
@jeanfbrito What about your logs ?

[saghul]

You can also try to repro with our Electron app, though we haven't received any reports like this one...

[jeanfbrito]

Chrome Screen sharer console log:
chrome screen sharer.log

Can you please share the full log from the screen sharer? I see the logs only upto the moment when the electron client joined and nothing after so it is hard to tell if having the electron client in the call changed the sender characteristics. Please share the full log for both the sender and the electron clien.

Here are all the logs from the screen sharer since the start until I close the Electron window. Resized the window on Electron, other windows was very big already.
jitsi.rocket.chat-1711566752911.log

[jeanfbrito]

I can't see here any progress. The RocketChat users are waiting for a solution. @jeanfbrito What about your logs ?

Until we found whats going on you can ask the users to open the calls inside web browser. Dont seems to be nothing that we changed from our side.

[jeanfbrito]

Screen.Recording.2024-03-27.at.4.29.23.PM.mov

Here is the degradation that users are reporting. You can see that I open the Electron window. Even resizing it dont changes, if I close the Electron window it maintains that quality. I sent the screen sharer logs for this video. I kept it very small so I could attach here, if needed I can record more.

https://github.com/jitsi/jitsi-meet/assets/1177482/a64f33f8-7372-4ce3-ac37-193d10af7407
jitsi.rocket.chat-1711567793807.log

[saghul]

I honestly don't know.

Since it doesn't seem to reproduce with the Jitsi Meet app targeting meet.jit.si it could be an issue of the deployment. I'd say it's unlikely to be related to Electron itself, but I'm not 100% sure.

[jallamsetty1]

2024-03-27T19:27:57.184Z [FeatureFlags] <Object.init>: Source name signaling: false, Send multiple video streams: false, SSRC rewriting supported: false, uses Unified plan: true

It appears that you are running a very old version of the client that has source-name signaling and multi-stream mode disabled. We have made them the default behavior long time back and the backwards compat code has been removed from the bridge already. Are the client and backend versions out of sync by any chance?

If you are running the older versions of both client and backend and the issue started happening recently then it could be something in your application or settings.

[jeanfbrito]

2024-03-27T19:27:57.184Z [FeatureFlags] <Object.init>: Source name signaling: false, Send multiple video streams: false, SSRC rewriting supported: false, uses Unified plan: true

It appears that you are running a very old version of the client that has source-name signaling and multi-stream mode disabled. We have made them the default behavior long time back and the backwards compat code has been removed from the bridge already. Are the client and backend versions out of sync by any chance?

If you are running the older versions of both client and backend and the issue started happening recently then it could be something in your application or settings.

This can be the issue, there is any console command that I can run to see the versions?

[damencho]

Filter console logs with word version

[jeanfbrito]

Filter console logs with word version

Only one is this:

Logger.js:154 2024-03-27T19:27:59.133Z [modules/version/ComponentsVersions.js] Got focus version: 1.0.900

This is the frontend version @damencho ?

[damencho]

Nope this is jicofo, part of backend that was released on 17-Jun-2022. For The frontend you need to check the index.html source there are several places with v= which match the jitsi-meet-web version

[moell9]

In our environment the version is v=7712 (/usr/share/jitsi-meet/index.html).

[damencho]

Which is from 20-Dec-2023. Your frontend and backend are not compatible with each other. Not sure how you managed to update the packages with such a combination.

[moell9]

What does that mean now ?
The problem is with the RocketChat Electron ?
Reminder: When I start a videocall from the RocketChat Electron, I have the choice between an application window or within a web browser.
The problem only occurs with the application window within the RocketChat Electron client.
Not when the call is opened in the web browser.
The application window takes default settings from the RocketChat Electron client, the web browser uses Jitsi Meet directly.
Would that be summarized correctly?

[damencho]

As mentioned by @jallamsetty1 it can be the settings passed to the jitsi-meet client. Can you extract from the electron window the settings that are passed to the iframe that loads jitsi-meet?

[moell9]

No, sorry, I can't. But @jeanfbrito can do perhaps. He is the developer of the RocketChat Electron.

[jeanfbrito]

No, sorry, I can't. But @jeanfbrito can do perhaps. He is the developer of the RocketChat Electron.

On electron side we don't add any settings, we just open the URL on a new window. But I'm reaching the people who maintain the Jitsi app on the Marketplace so we can update it and see what's going on.

[moell9]

But the Jitsi app is also needed when the web browser is used for video calls. Or am I wrong ?

[damencho]

Both load the same web app, it is just when loading with iframeAPI config overrides are done, I was thinking about those.

[moell9]

I was looking for this now:
[FeatureFlags] <Object.init>: Source name signaling: false, Send multiple video streams: false, SSRC rewriting supported: false, uses Unified plan: true
But I can't find it. Can you give me some advice please ?

[saghul]

It's in the JS console logs.

[moell9]

Still can't find it. Can you show me in a screenshot or screencast ?

[saghul]

It should show very early when the iframe was loaded.

[moell9]

Can't see any [FeatureFlags] ...

[saghul]

That log line was removed when we changed the defaults. What lib-jitsi-meet version are you seeing? The log should look like this:

2024-04-11T13:43:03.031Z [features/base/lib-jitsi-meet] lib-jitsi-meet version:d1333434

[moell9]

[features/base/lib-jitsi-meet] lib-jitsi-meet version:ca40744f

[jallamsetty1]

[features/base/lib-jitsi-meet] lib-jitsi-meet version:ca40744f

This client version is from Dec 2023 and your backend is from Jun 2022. They are not compatible. The client logs @jeanfbrito shared doesn't have the above log line but instead prints the old log that has since been removed. Something is wrong with the client versions, sometimes the new version gets loaded and its the older one at other times.

[moell9]

We updated yesterday Jitsi Meet to version 2.0.9364 and RocketChat to version 6.7.0.
Now wit have the lib-jitsi-meet version: [features/base/lib-jitsi-meet] lib-jitsi-meet version:311766e3

[saghul]

Did you update all components? Do you observe the problem now?

[moell9]

What do you mean with all components ?
We have upgraded all Jitsi components that were offered to us via upgrade (apt upgrade --> Ubuntu Server).

[saghul]

That's what I meant: the frontend, jicofo and the jvb.

[moell9]

BTW, the problem seems to be solved after the updates. Just had a meeting with 15 users and the quality is back to normal.

[saghul]

Good to hear! I'm going to go ahead and close this then.