We tried deploying 2.0.6689 (2021-12-06) and 2.0.6726 (2021-12-10) then we noticed some slowness in rendering the shared screen of the participants. We are using lib-jitsi-meet.min.js in our front end with function room.addTrack/room.removeTrack when we want to show/hide the participant’s screen. As we continuously show/hide the shared screen of the participants we observed that rendering the screen become slow as compared to older version 2.0.5963 (2021-06-10).
During our testing, we have atleast 11 participants who shared their screen and there’s only one who’s viewing all the shared screens. Repeatedly we show/hide the participants shared screen and at some point it got slower to render it.
Here’s the only console log we have seen
We observed that whenever we show/hide the shared screen this number before “Halt” log increases
Also, even after that console log sometimes it takes time to render the shared screen
Can you run the same test on meet.jit.si and see if your findings are similar?
What other factors could affect the rendering of the shared screen? I just tried using our app with 4 participants who shared their screens sometimes loading takes time (25sec) sometimes within a sec or two. In this test, the conference is running for more than 4hrs showing/hiding participants’ shared screen.
During our testing with meet.jit.si all 9 participants shared their screen and when I click “Toggle tile view” the shared screen becomes full screen and back to tile view without any delay (almost). I assumed that meet.jit.si implementation did not remove the track during “Toggle tile view” action. In our case, every time we change the layout from 7x6 to 5x4 we use to remove/add track that’s why there’s a bit of delay to render the shared screen of the participants. We are not really aware of the jitsi changes but using the latest version the slowness of rendering is noticeable.
One reason why we use to remove track when we select a single participant (full view) so that all other participants shared screen will not send their data (shared screen).
You can send the bridge a message to stop sending certain videos. Look at the messages in the network console, this is how tile view works you receive videos only for those that are visible.
Could you give us a code reference for this? Every time I choose a full view of the shared screen from “Toggle tile view” there’s only http-bind message
Open the network tab before connecting the conference, you will see then all network activity, including the websocket ro the bridge and you can check its messages
Ok, thanks… I was able to see some network messages
where can we get a good reference for jitsi meet ui?
Is this the code GitHub - jitsi/jitsi-meet: Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
Does Jitsi Meet UI uses lib-jitsi-meet API?
I think that we are not using the API properly and some of the behavior is really unknown to us.
did you find cause for this? i’ve the same scenario - Turn on Video → Share screen → Turn off share screen (replace desktoptrack with Video track) results into slow connection.