Video freezing (track muted event) for some clients but not others


we’re developing our own client on top of lib-jitsi-meet, JVB, etc.

What we’re seeing is that, if, for instance, you have clients A,B,C in a jitsi room, occasionally, A will freeze for B but not C. B also receives a track mute event in that case (the actual MediaTrack, not JitsiTrack). B will continue to receive C’s video with no issues

The track will usually emit an unmute event and resume after some time (anything from some milliseconds to more than a minute).

We’re trying to figure out what is causing this or how to mitigate it. Our understanding is that JVB sends the same media to all clients connected to the same room. Is this correct or is there a chance that JVB freezes a track if a client (B in this case) has low connectivity?

Also, is there a way to restart the remote stream for the receiving client, if the freeze goes on for too long? That is, without re-joining the room and so having to restart the incoming video from C.

Yes, there is a message about a participant entering/leaving lastN set send by the bridge, which is indication that the bridge will not send video for that participant, and in jitsi-meet we show a ninja icon in this case.

Yes, we have seen that event in some cases. Is this all documented somewhere? We have read the documentation about lastN and played around with the org.jitsi.videobridge.TRUST_BWE flag but still have quite a few questions. Could you maybe point me to the right place?

It’s still hard to figure out patterns - sometimes one stream freezes for everyone, sometimes just for one recipent (the recipient in question continuing to receive streams from other people).

Is there some clear way to differentiate between the two cases?

Also, in the former case, recovery seems to be very slow or never (at some point we waited for about 2-3 minutes but the stream did not restart).

In the stream frozen for one recipient case, is there an easy way to restart it or force it to resume?

Finally, we’re assuming that setting org.jitsi.videobridge.TRUST_BWE to false will interfere with simulcasting. Is that right?

@ada we are facing the same issue. Did you find a solution.

Hi, we did solve it more or less – we did a few things to achieve it:

The most important part of it was to use colibri messages to set an array of pinned streams (PinnedEndpointsChangedEvent)

We also did switch simulcast on and have DisableRtx set to true

The reason for the above is that we realised, even if the streams where not freezing, people with low bandwidth would fall way behind the others unless we used either low quality globally or simulcast.

Like I said though, the critical change seems to have been the pinned endpoints

Hello @ada thanks so much for your response.

We can only find pinParticipant which does pinEndpoint for only one person. Did you add a call in lib-jitsi-meet to do what you described? Any insight on this would be super helpful.

We are using selectParticipants which did not fix the issue in our case, the participants stay in “interrupted” connection status for some of the participants while for others they get the video correctly.

We also are using simulcast, but not DisableRTX. We will try to learn about that one.

Any suggestions you got would be super helpful.

Thanks again!!

i can not unmute or turn my camra on help me

Any solution?

1 Like


in 2022 we have still the same issues :D. Can you explain in greater detail how you solved this problem, because i can’t find “PinnedEndpointsChangedEvent” in any doku of jitsi?

Thanks in advance


we are using JitsiConference.setReceiverConstraints and setting selectedEndpoints
I can’t remember where or if this is documented, however, the code is here:

You also have to make certain that lastN is at least the number of selectedEndpoints

In any case, this seems to have improved freezing drastically, and especially recovery from frozen incoming streams, although, of course, with receivers with really low bandwidth, there’s only so much you can do.


Thanks mate for ur effort. I will have a closer look!