Details of problems during recent session with 12 connections (11 users)

This describes an meeting held recently, with specific purposes to test/diagnose issues causing problems on Jitsi. We had max 12 connections (11 users) simultaneously, with some connections being manually disconnected due to technical reasons (then reconnected).

This complements recent reports by community member @cjfsyntropy. This provides additional details on the same video conf/meeting intended to test and collect real-world data, for purposes of helping to diagnose what aspects of a user’s connections/setup may have contributed, or what aspects can be ruled out as non-causal to problems.


  • Participants: We had max 12 connections (11 users). 9-10 users were connected at all times. (User S3 was connected 2x, simultaneously from the same PC using 2 browsers)

  • Duration: 1 hour 40 minutes (approx)

  • Server: Jitsi’s public Meet server (

  • Encryption Point-to-point encryption was enabled during the entire Meet,
    between browser-clients and the Jitsi server.

  • Bandwidth All users were asked to set their session to use “Low Definition”.
    We believe most (90%) of users did this.
    This setting gave little improvement, compared to reducing the number of active cameras.

  • Devices: 10 participants used a computer (non-mobile). Most used a Windows PC.
    (user S3 had one computer but stayed connected twice, on two browsers)
    2 users (M & E) used only a smartphone for the entire meeting.
    (M’s smartphone had JITSI app; E tried both Safari browser then JITSI app)
    Later, user J stopped using PC and used an Android phone with JITSI app.

  • Internet: All users had high-speed broadband and/or high-speed cellular service.
    All had used the same device/internet with Zoom with no/few problems/lag.

  • Microphone: Everyone had their microphone enabled during the test meeting’s first part.
    Only after painful occurrences of audio feedback did we mute everyone.
    During the 2nd part, many people muted their mics after we all heard
    echoing/feedback coming from 1-2 unknown users. Most users remained
    self-muted for a majority of the meeting’s 2nd part (1-3 unmuted at a time).

  • Cameras: Initially 10 participants had cameras turned on. 8-9 set it for “Low definition”.
    (user E’s smartphone Safari browser did not permit the camera;
    subsequently user E switched to using the JITSI app) – so 11 cameras total.
    After about 40 minutes, most users turned off their cameras due to
    excessively poor video quality irrespective of the browser/device used.
    That allowed everyone to get/see better video (no lag, no distortion) from
    the main speaker who had their camera on. During this period (total 1 hour),
    only about 3-5 users had their camera on/transmitting at any time.

  • User profiles: 1-2 users were not tech-savvy. 4 were tech-experienced. Remaining
    users had moderate experience using their device, and followed instructions.

  • Users/Initials: R M J E N A V C S1 S2 S3; (I am user S3)

  • Browsers tested: Chrome, Chromium, Firefox, Safari, Opera, Iridium, Edge, Edge (old)

  • Test format: This was not a fully controlled test scenario. At times users were trying
    unscripted things, with others not knowing what they did until later. Generally
    we informed each other by voice or in chat, about what we did/experienced.
    This should be considered a real-world test, with non-systematic testing.

(additional details to be provided in a follow-on post)

1 Like


  1. AUDIO - During the 1.5+ hour meeting, audio quality was problematic.

    • Most users heard audio echoes, feedback, and/or distortion.
    • Users whose setup was found to cause audio problems then muted themselves.
    • Such users then tried other changes, including one/more of these:
      - reloaded their session (only refreshed the browser)
      - disconnected from the meeting + rejoining the meet
      - closing their browser + rejoining the meeting
      - or when possible they tried using a different browser.
  2. RECEIVED VIDEO - quality varied when a user used/compared more than one browser.

    • Some browsers had consistent better video display quality & performance than others.
    • For other browsers, we did not have enough users / test points.
    • As comparison (to assess whether problems could be causally linked to users’ hardware/internet), everyone had used Zoom prior and noticed Zoom’s video quality and performance was at least comparable but usually better than Jitsi Meet’s.
    • Of browsers used, I saw Firefox, Chromium, and Iridium had comparable video display performance (when we rule-out issues caused by screen sharing bad transmittal).
    • I (user S3) used both Firefox and Iridium, simultaneously, with no video problems (other than problems due to transmission issues or bandwidth saturation).
  3. SCREEN SHARING gave problems, and some browsers were unable to share.

    • 2 browsers (3 users) could share still images (using Firefox on Windows 10, and Chromium on Linux Debian 10.4).

    • Users V & S3 shared their live screen using Firefox. All participants confirmed

    • User C shared still images using Chromium. All participants confirmed.

    • I (user S3) tried to share using Iridium. However no one else saw my video feed and instead saw only a “monitor/CRT” icon.

    • Then I tried sharing using Firefox, and at first I did not understand Firefox’s sharing UI was different.

    • Eventually I successfully shared my screen - it outputted my entire screen. Since my screen was set to “speaker view” (and I was the speaker), the shared/sent video that others saw rapidly became an “infinitely nested” (aka video feedback) view of my screen.

    • Other users admitted seeing that “strange” screen. However they incorrectly assumed it was a bug. Their feedback confirmed they were seeing my screen-share.

    • I tried to explain to users that this “strange” screen was expected given the setup, and was a side-effect of sharing in this way.

    • To alleviate the problem, I switched my display to tile-view, and immediately other users saw a tiled view, with only one tile (of my screen) showing the “infinitely nested” / recursive display.

    • This indicated screen sharing using Firefox worked correctly.


    • User C used Chromium to share a mpeg video playing locally on his Linux computer.

    • Everyone saw his screen, though the video of his screen-share had lag and distortion.

    • Every user noticed the audio lagged the video, and the audio was choppy.

    • User C then disconnected from the JITSI server, and re-joined using Chromium.

    • Only upon rejoining did User C’s shared mpeg video become watchable by others.

    • User C’s 2nd try at the shared mpeg video played correctly (no lag, no distortion, audio ok).

    • During user C’s share, I had two browsers simultaneously connected.

    • During C’s first screen share try, my Iridium browser initially saw his video share (though choppy) but it soon lost his video share entirely. I didn’t understand why (though later he explained he had changed to “low bandwidth” [which stopped his video output - which I then saw as his video disappearing; thus the dissappearance was not due to Iridium but rather his “low bandwidth”=no video setting]. He then closed his session and re-entered Jitsi Meet, prompted by others saying his share was not working). Meanwhile I still believed my Iridium feed was gone due to something in Iridium (it was not) yet to try to fix this I reconnected my Iridium browser (disconnected from Jitsi, rejoined). It did not re-connect to his video share. Even after C’s 2nd video share was working and seen by others, my Iridium browser still did not show his properly working video (it put only a “monitor/CRT” icon in its place).

    • At that point I also disconnected +reconnected my Firefox session. When user C’s 2nd video-share attempt was already working, my rejoined Firefox session also did not re-connect to his video share, and instead showed the “monitor” icon. I was unable to re-connect to his screen-share, using neither browser. At one point User C restarted his video, and only then was I able to see it on Firefox. (I had not checked Iridium – too much confusion at that point – but possibly user C’s video share had restarted also on it but this I did not confirm).

    • I suspect a screen/video shared by another user is visible to recipient-users only when the recipient’s JITSI session is continuous and “unbroken” for the entire share. It appeared any interruption (from either side) caused the recipient’s view of the share to stop and never resume.

    • I (user S3) could share my active live screen using Firefox (see #4 above). Others saw it.

    • I consider this equivalent to a video share, since my live screen was active (as a video feed) and in terms of the video stream being output (from my browser) it would be indistinguishable to recipients as a video or otherwise. Their browsers would see my feed (of my screen) as any other streaming video (mpeg file or not). Thus, this I believe showed that video sharing using Firefox also worked successfully. This depends of course on whether/how encoding of an mpeg file differs (if at all) from a shared live screen, within browsers and Jitsi’s server…

  5. SHARING OF YOUTUBE VIDEO. User V shared a YouTube video using the “…” menu option.

    • A YouTube video began to play for all other users, in a newly appearing tile (if tiled view).
    • For in with “speaker view”, it was the only video playing / “feed” shown.
    • I switched during this, between live and speaker views, and confirmed the above.
    • The YouTube video played normally, with nearly no lag, no distortion, and audio was good.
    • That video completed playing but appeared to freeze at its end - with an overlay large icon representing what YouTube (site) overlays to convey “buffering in progress”. It appeared to me that the video had frozen.
    • Soon I and others realized the video had in fact finished playing. We could not explain the overlay icon. Perhaps an artifact of how YouTube’s API interacts with Jitsi’s interface?
    • No one could figure out how to close the tile for the YT video; We all looked for ways.
    • Eventually user V was able to close it, and we realized perhaps only the initiating user can close a YT video feed.
    • No other user started a YT feed. The first seemed to work successfully - no one reported a problem.
  6. We saw bandwidth saturation when 8+ simultaneous cameras were enabled.

    • When more than ~7-8 cameras simultaneously outputed, everyone’s video of the speaker degraded.
    • This was consistent for all users, even after the majority of users set “Low Bandwidth” setting.
    • Only when later in the meeting most users turned off their cameras, did video quality and stability became good/reasonable enough that we could watch & hear the speaker.
  7. POSSIBLE ISSUE regarding screen/video shares not resuming unless the initiator (sharer) re-starts their feed.

    • This is suspected but not confirmed. I noticed this occurred on 2 of my simultaneous browsers, at different times only after I restarted each browser session.
    • It is possible that screen-sharing issues observed by users were due to this effect, but was misunderstood or believed to be “their own system”. Most users were not knowledgeable in diagnostics/testing of computing tech, so they often seemed to assume problems were due to their own browser/setup.
  8. Jitsi’s approach of using Browser-based (interpreted) code to manage connections may be inherently less efficient (and more affected by browser architecture/CPU load) than competing systems (eg, webex) that rely on a native app using compiled highly optimized code. This is also why we observed smartphones (using a presumably compiled app) have fewer problems. Some browsers had worse performance, possibly from internal inefficiencies at processing WebRTC traffic and real-time management of multiple encrypted connections/video streams.

(additional details to be provided in a follow-on post)

1 Like


NOTE: Other than user S3, all other users who tested multiple browsers did so having only one browser connected to Jitsi Meet at any time.

  • That is, they ran only one browser, closed its session, then opened the next browser. We do not know if they also closed the browser app after its session was closed.
  • User S3 started 3 browsers simultaneously running (receiving and transmitting). However 1 browser was incompatible, and he continued running the other 2 browsers for the entire duration of the meeting.
  1. User “R” used a Windows OS (unknown version) and experienced either echoing/feedback of audio coming from others, or choppy/distorted audio. He tested 2 browsers (Chrome and Edge-Chromium)

    • He first used one browser (I believe Chrome, unknown version) and had audio problems.
    • He switched to a different PC running the latest Microsoft Edge (Chromium-based) browser and had the same audio problems. Both browsers showed slow/laggy video.
    • He left the meeting during this first part of our meeting, for unrelated/personal reasons.
    • It is possible the video laggy-ness was not from either of the two browsers that R used, and instead was affected by server bandwidth issues (the number of video participants, since during that first part of the meeting, we had 11 users transmitting their video and audio streams).
  2. User “M” was using a mobile smartphone with the Jitsi app. She used no other device/app.

    • She experienced few problems, though she was also the least tech savvy.
    • She reported no additional problems (she did experience the audio/video/sharing problems commonly affecting everyone).
  3. User “J” used two different browsers at different times on a Windows 10 PC, first Firefox exclusively then Chrome exclusively.

    • His configuration (OS, browser versions) was reported yesterday by user @cjfsyntropy. ( conference unusable with Chrome, audio issues with Firefox )
    • User J experienced similar (moderate) quality on both Firefox and Chrome browsers.
    • He said the quality was less than he has seen on Zoom, using the same internet and same PC (this provides a reference comparison, to baseline OS/hardware/internet effects).
    • He later switched to an Android smartphone with the JITSI app, and the quality was acceptable.
    • He reported no additional problems (he did experience the audio/video/sharing problems commonly affecting everyone).
  4. User “E” used an iPhone smartphone (unknown iOS version) during the entire meeting.

    • Initially he attempted to use the Safari mobile browser (unknown version).
    • When his camera did not work (likely due to camera permission not granted), he switched to the JITSI app which worked well.
    • He reported no additional problems (he did experience the audio/video/sharing problems commonly affecting everyone).
  5. User “N” used a computer (unknown OS) with first Opera (unknown version) then Chrome.

    • It worked acceptably (except for echo/feedback written above in GENERAL FINDING #1).
    • At one point she believed her browser was not displaying a shared video (by user C), but that problem was found to be due to screen-share (transmittal) difficulties.
    • At that point, she had already changed to Chrome browser (unknown version), and experienced the same problem (she again saw only the “monitor” icon instead of user C’s shared screen).
    • Both Opera and Chrome seemed to work similarly and acceptably for this user.
    • She reported no additional problems (she did experience the audio/video/sharing problems commonly affecting everyone).
  6. User “A” used a computer running Windows 10. She tested 2 browsers, Firefox and Chrome.

    • She began using Firefox (unknown version) and said the video “looks good”.
    • She experienced no problem with Firefox other than problems commonly affecting everyone.
    • After a few users had turned off their camera (thus network load through the Jitsi server/fork had lessened), user A switched to the Chrome (unknown version) browser and said it “seems to work okay as well.”
    • She had to leave but before leaving she began a zoom desktop app session, where she had zoom video and Jitsi video active simultaneously with no problem, and video on zoom was acceptable and on Jitsi as it was earlier.
    • This indicates her internet bandwidth & CPU load/capacity was sufficient to allow two simultaneous video sessions showing video performance & quality similar to one lone Jitsi session.
    • She made the comment that Jitsi on Chrome’s video was not as good as the Zoom desktop app’s video.
  7. User “V” used a computer (unknown OS & version). She used Firefox. She could screen-share.

    • She used the Firefox browser (unknown version).
    • She was one of three users who attempted to screen-share.
    • She was successful in sharing still images with Firefox.
    • She did not try to screen-share video from her computer.
    • She was the only user who attempted to (and was successful in) sharing a YouTube video directly from the YouTube site (not using a process from her PC / CPU).
    • That YT video was received by everyone clearly, fast, with proper audio.
    • After that YT video ended, it confused everyone because it looked as if the video had frozen (YouTube’s “queueing” semi-circle icon was overlayed on the video).
    • No one could understand how to resume or refresh the YT video.
    • We all soon assumed the video had finished playing but the display was not updated to show completion.
    • No one could understand how to close the tile for the YT video (that YT video was in its own tile, separate from user V’s tile that showed only her name and no video since her camera was off).
    • Eventually user V realized she was the only one who could close it since she started that feed.
    • She was able to close it.
  8. User “C” used a Linux computer (see @cjfsyntropy 's post). He used Chromium and Firefox.

    • He was one of three users attempting to screen-share.
    • He was successful in sharing still images, using Chromium.
    • He was the only user who attempted to share a video (mpeg) file from his computer).
    • His first attempt at video sharing was partly successful, with others seeing choppy distorted video with laggy delayed audio.
    • He exited Jitsi Meet and rejoined, and then could successfully share the same video in this 2nd attempt, using Chromium.
    • It is not clear if/when he tried to share (still and/or video) using Firefox.
  9. User “S1” used a computer (unknown OS or version). She used Opera (unknown version).

    • She reported no additional problems (she did experience the audio/video/sharing problems commonly affecting everyone).
  10. User “S2” used a computer (unknown OS or version). He used 1 unknown browser.

    • He reported no additional problems (he did experience the audio/video/sharing problems commonly affecting everyone).
    • This user was very frustrated with the JITSI platform and felt it was not ready for “prime time” use.
  11. I (user “S3”) used a Windows 10 PC. I simultaneously ran 2 browsers during the meeting. I was able to screen-share successfully (live video of my desktop) using Firefox, but not w Iridium.

    • One browser was Firefox (version 76.0.1, 64-bit)

    • The other was Iridium browser (version 2020.04 Official Build, 64-bit).

    • I was one of three users who attempted to screen-share.

    • I was successful in sharing my screen (which was effectively a live video feed, similar to a playing video file, but of my live active desktop) using only Firefox.

    • I was able to start screen-share using Iridium but it was not visible by anyone else.

    • I did not try to screen-share a playing video file from the computer.

    • During my screen share using Firefox, the Screen-share user interface between Iridium and Firefox confused me initially.

      • The Iridium UI was more sophisticated (allowed choosing whether to share my entire screen, a specific running app, or a browser window).
      • Iridium also created a small overlay window to let me easily END the screen-share.
      • Firefox UI did not present any of these - it simply defaulted to sharing my entire screen (initially I did not know this, and thought screen-share was not working).
    • With Firefox I soon realized its UI was different, and it led to my temporary inability to share.

    • After I got Firefox sharing my screen (I had to give Firefox permission to screen-share), it began streaming my live entire screen. I was in speaker-view.

      • This was seen by all others users, so this confirmed that screen-share worked correctly.
      • However some users incorrectly assumed there was a bug (because they saw “video feedback” (the image of my screen rapidly became an “iterative nested” scene [as one sees when standing between two parallel mirrors]).
      • This was not a bug, but an artifact (seen on any environment/platform when the sharer’s video output is looped back [re-shown] on their own screen, and that again is shared…).
      • I explained to other users this was not a problem and was expected given what I was doing.
    • Audio was not a problem during this - they heard my audio/voice.

    • An important aspect on audio echo is that early when I started both browsers, I did experience immediate echoing and slight feedback (everyone heard the same from my microphone).

    • This I realized soon, was normal expected behavior due to TWO browsers having simultaneous access to both my speaker and my microphone.

    • I realized the echo-cancelling algorithm in each browser, while it successfully worked with its own input/output audio-streams - was unable to cancel echos from the other browser (when browser 1’s microphone sent audio that was output on browser 2’s audio-out… and vice-versa).

    • Once I realized this was occurring, I muted the audio-out (muted the speaker) specific to one browser (Firefox) – and the echo/feedback disappeared completely for everyone.

    • I kept this config later for the entire meeting/sessions.

      • However, I noticed that later in the meeting when I had to leave the meeting (using one, then the other browser), and then rejoined using the same browser, upon rejoining by microphone and speaker were automatically re-enabled for a second or two – thus causing echo/feedback for others.
      • Each time it took me 3-4 seconds to stop it (by again muting 1 browser’s speaker-output).
      • However others didn’t understand this was the cause and said my system was giving problems.
      • It was a foreseen issue, not caused by browser or other issues but by the dynamics of running two browsers when both used the mic & speaker.
    • I also encountered problems (described in GENERAL FINDINGS #7 above).

    • Lastly, at the start of the test meeting, I also started the Microsoft Edge (non-Chromium) version.

    • However I received an error message saying it (non-Chromium) was unsupported by Jitsi.

    • User R said Edge has a new version using the Chromium-engine worked with Jitsi.

    • User R successfully used that version; I did not have time to download/try it.

1 Like