search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
42 stars 6 forks source link

Jitsi status #157

Closed kimdhamilton closed 3 years ago

kimdhamilton commented 3 years ago

Let's report out on jitsi status at the 10/6 meeting during action item review.

msporny commented 3 years ago

Update here: https://lists.w3.org/Archives/Public/public-credentials/2020Nov/0006.html

The Jitsi bridge was fixed a few days ago, but we were only able to do a scale/diversity test today. The scale/diversity test today was successful. All systems nominal.

The W3C CCG Jitsi system should be fully operational again:

In addition to getting our old capabilities back, the following upgrades have been made as well:

I'm considering a test this Friday for the broader community if folks are interested in taking the new system out for a spin. I'll shoot for 11am ET. Will send an invite out to the mailing list.

wyc commented 3 years ago

Due to stable performance of Jitsi over the past 3 conferencing sessions, I will close this issue. Please feel free to reopen if you feel that this was not addressed.

TallTed commented 3 years ago

Jitsi stability is sadly in the eye of the beholder.

Jitsi architecture has each client receiving a direct data stream from each other client.

"Video quality" setting impacts what each client sends but does nothing about what they receive. 10 clients, all sending default high-quality video, can saturate any or all of those 10 clients' connections to the internet and/or spike CPU usage on any or all client hosts. Perhaps not obviously, this gets worse as the number of participants increases.

There are some URI arguments which can change things somewhat -- limiting the number of video streams the local client displays to the last 3 speakers, for instance, with #config.channelLastN=3 (I think this is an abuse of the fragment identifier # which should be a query argument ?, though it makes some sense since the client-side is being controlled by these, not the server-side; multiple # arguments are separated by &); or #disableAudioLevels=true to disable the audio level monitoring that renders the blue dots when someone talks, triggering GUI updates.

I'll be trying with this URL next time -- https://meet.w3c-ccg.org/weekly#channelLastN=3&disableAudioLevels=true. Others may also find this beneficial.

TallTed commented 3 years ago

https://meet.w3c-ccg.org/weekly#channelLastN=3&disableAudioLevels=true

I used it today, with no obvious problems, in Jitsi Meet.app on macOS.

But today was lots of audio with no video, so not a test of whether it is actually helpful.

Maybe next time...

(@wyc @vsnt -- I don't have whatever permission is needed to re-open this issue, but it does seem to be the right place for these tests. I'm happy to leave it closed, open a new issue, or reopen this one, as you see fit.)

vsnt commented 3 years ago

@TallTed thanks for your test feedback.

Regarding these tests - they will be helpful when we do push the system and it crashes. Maybe there could be a place in the Infrastructure Task Force for these things @wyc.

wyc commented 3 years ago

Great idea. I’m okay leaving this issue open until then. This feedback is indeed helpful.

vsnt commented 3 years ago

Issue will remain open until it is transfered to the ITF.

TallTed commented 3 years ago

I used the https://meet.w3c-ccg.org/weekly#channelLastN=3&disableAudioLevels=true link again today. CPU (and laptop fans) spiked anyway (though not as badly as the last time someone shared their desktop for a slideshow), so maybe the channelLastN value should be lower than 3. (I was focused on the presentation, so I didn't drop out and rejoin with the URI I'll be trying next time, to wit -- https://meet.w3c-ccg.org/weekly#channelLastN=1&disableAudioLevels=true.)

msporny commented 3 years ago

I used the https://meet.w3c-ccg.org/weekly#channelLastN=3&disableAudioLevels=true link again today. CPU (and laptop fans) spiked anyway (though not as badly as the last time someone shared their desktop for a slideshow), so maybe the channelLastN value should be lower than 3. (I was focused on the presentation, so I didn't drop out and rejoin with the URI I'll be trying next time, to wit -- https://meet.w3c-ccg.org/weekly#channelLastN=1&disableAudioLevels=true.)

Hey @TallTed thanks for documenting the issues you are having with the Jitsi system -- a few questions to try and debug this issue (as we've heard of high CPU usage from different people a few times now). This tends to be when the browser, for whatever reason, chooses not to use hardware acceleration for video decoding and instead falls back on trying to decode high definition video using the CPU. Could you provide the following details, please:

TallTed commented 3 years ago

  • Type of computer and CPU (ideally, make, model, year, type of CPU, number of cores, etc.)

  • MacBook Pro (Retina, 15-inch, Late 2013)

  • 2.5 GHz Intel Core i7 (4 cores, 8 threads)

  • 16 GB RAM

  • macOS Yosemite (10.10.5) with all applicable updates from Apple

  • Browser used (and version)

  • my browsers are already overloaded, so I don't run conference apps there unless I have no choice (see: BigBlueButton which has no standalone app)

  • Jitsi Meet.app v2.4.2 (latest available) (github repo)

  • Does running Zoom with someone screen sharing result in similar CPU usage figures?

  • no similar issues with Zoom (again no browser -- zoom.us.app, currently 5.4.9 (59931.0110)), with 25+ users in one session, most or all sharing live video

msporny commented 3 years ago

no similar issues with Zoom

Unfortunately, nothing seems to be jumping out as an issue with your setup -- are you using Safari or Chromium or Chrome or Firefox or Brave or...?

TallTed commented 3 years ago

Again -- I'm not using a web browser at all. Not Safari.app nor Chromium.app nor Chrome.app nor Firefox.app nor Brave.app nor ...

(Rather, I do use several of those, but they are all overloaded as each has many, many tabs open, e.g., Chrome.app currently has 1358 tabs open, none of which are used for Jitsi.)

I'm using Jitsi Meet.app for Jitsi sessions. Just like I use zoom.us.app for Zoom sessions. And Cisco Webex Meetings.app for Webex sessions.

I try to use my web browsers for web browsing, as the ghods intended, not for every application under the sun.

msporny commented 3 years ago

Again -- I'm not using a web browser at all.

My bad, you said that, but it didn't register... now I'm really confused... you would think their app would be optimized. I know @jandrieu uses their app on Windows -- @jandrieu have you had any "Jitsi app uses a TON of CPU when watching someone screenshare issues?"

TallTed commented 3 years ago

Sadly, https://meet.w3c-ccg.org/weekly#channelLastN=1&disableAudioLevels=true did NOT resolve the problem.

Until video was shared, CPU was not a concern. When one user shared their desktop (Markus presenting on DID Core), and with no other active Jitsi video, Jitsi Meet.app spiked to ~400% CPU (vs 20-30% reported for Chrome.app, 20% for WindowServer, 20% for Mail.app...)

Absurdly, "hiding" or just moving Jitsi Meet.app to the back (behind Chrome.app, Mail.app, etc.) dropped its CPU to ~50%. It's apparently negative-optimized. :-/

Extra oddly, when Markus terminated his screen share, Jitsi kept his last frame as his avatar, and kept chewing CPU apparently for that (and then for the other screen-sharers). When the last person who'd shared their screen left the meeting, Jitsi CPU dropped to ~20%.

wyc commented 3 years ago

Continuing in ITF

vsnt commented 3 years ago

Where did this go? Can you please add a pointer @wyc?

At 2/24 meeting had audio issues. glitching of speakers, unable to hear speakers. Logged out and logged back in to get audio, but still glitching.

TallTed commented 3 years ago

@vsnt -- See https://github.com/w3c-ccg/infrastructure/issues/9 (which auto-linked from here when @wyc created it and mentioned this there).

Thoughts for future -- explicitly say "continuing in https://github.com/w3c-ccg/infrastructure/issues/9", or even move the ITF issues from this repo to that repo...