LastN about jitsi-meet HOT 10 CLOSED

Can you show me some examples for LastN? How does the focus signal it?

from jitsi-meet.

In order to support LastN, two new attributes have been introduced in the channel element:

(1) The channel attribute endpoint specifies the identity of the conference participant who is streaming on that channel to Jitsi Videobridge. It is an opaque string as far as Jitsi Videobridge is concerned and is optional. For example, Jitsi uses the JID of the conference participant. For example, the following (schematic depiction of an) IQ tells Jitsi Videobridge that the audio streamed on c1 and the video streamed on c2 are coming from the same conference participant/endpoint [email protected]/resource:

<conference>
    <content name="audio">
        <channel endpoint="[email protected]/resource" id="c1" />
    </content>
    <content name="video">
        <channel endpoint="[email protected]/resource" id="c2" />
    </content>
</conference>

(2) The channel attribute last-n on a video channel specifies the maximum number of last active in the sense of audible audio endpoints/conference participants whose video is to be transmitted through the channel from Jitsi Videobridge. It is a positive number and is optional. For example, the following (schematic depiction of an) IQ tells Jitsi Videobridge that at most 8 videos of actively speaking conference participants are to be sent by Jitsi Videobridge on the video channel c2 i.e. to the endpoint [email protected]/resource

<conference>
    <content name="audio">
        <channel endpoint="[email protected]/resource" id="c1" />
    </content>
    <content name="video">
        <channel endpoint="[email protected]/resource" id="c2" last-n="8" />
    </content>
</conference>

As common with Jitsi Videobridge, the two new channel attributes endpoint and last-n may be specified at any time i.e. either during the allocation of a new channel or as an update to an existing channel.

from jitsi-meet.

Let's discuss this at fosdem. The plan at the RTP stream layer is not clear to me since the webrtc API doesn't give me clear indications that a stream is not progressing anymore. Well, getstats, but...

from jitsi-meet.

I guess that would require further signalling from the bridge ... and then the focus. @fippo would an RTCP bye help? Would that destroy the stream? If not, we have to send this from bridge->focus->participant

from jitsi-meet.

We discussed this today. Definitely doable. Would require a moderate amount of signalling from the bridge, to tell the application about the currently dominating speaker.

from jitsi-meet.

This is proving out to be our currently biggest performance bottleneck so we'd need to think about it in the short term. Since an SCTP implementation does not look as something easily achievable, we may have to resort to bridge->focus->participant signalling.

from jitsi-meet.

This would require active speaker detection and SCTP support at the bridge so March might be a bit optimistic. April sounds fine though. @bgrozev and @paweldomas are the likely victims here ;)

from jitsi-meet.

Already implemented.

from jitsi-meet.

How are stream changes signaled to lastN endpoints?

from jitsi-meet.

Through data channels. See here.

from jitsi-meet.