On July 7th I tested sharing an mp4 video in a Chromium tab. I repeated the test during the Aug 24th session. My chromium Debian Buster package was upgraded to 83.0.4103.116-1~deb10u3.
I tested by passing in the desktopSharingFrameRate.max=30 WebRTC setting in the URL.
Audio and Video performance was significantly better than in July. However, multiple users complained that the video was “robotic” and choppy with lost frames. Audio was almost good enough, but I was advised not to use the feature in a real event.
Some minutes after the test, we noticed an echo. Muting and unmuting myself did not fix it. So I reset my connection which fixed the echo.
I reset my connection without the WebRTC setting (by clicking on the URL bar and hitting enter to rejoin the conference) and played more of the video which I believe should have “forgotten” the FrameRate parameter. Some participants said it was better others said it was worse. I infer that random issues overwhelmed the FrameRate parameter as a factor.
The iOS on iPad user running Safari reports that the sound in this test was inaudible: sound could not be increased enough to hear.
Later I shared a YouTube video.
Two users running on iOS (one on iPhone iOS 13.6.1 with the Jitsi App; other on iPad using Safari). Both users were unable to see the YouTube video. Both users received a popup error message box - informing them they could not see shared YouTube video.
Here is my July 7th report: Meet.jit.si: Sharing a video in a Chromium tab on Linux is unusable