[jitsi-users] Restrict some participants from receiving video


#1

Hello everyone,

I asked today's call about a feature about stopping the video in a conference.
Emil mentioned the audioOnly mode. I've tested it, but I am looking
for a feature a little different.

I was very ambiguous, so I will describe it to be clearer.

Suppose a conference with multiple moderators and multiple participants.
Moderators and participants can share their video, but only moderators
can see/receive videos.
In this scenario:
1. Moderators can see/receive each other's videos.
2. Moderators can see/receive participants' videos.
3. Participants cannot see/receive anyone's video.

It's easy to remove the 'seeing' part of the participants, but I
remove it superficially because I keep receiving video streams
(according to the webrtc-internals).

By using audioOnly, I am setting the channelLastN config that will be
applied to the whole conference, correct?

Camilo


#2

Hi Camilo,

Hello everyone,

I asked today's call about a feature about stopping the video in a conference.
Emil mentioned the audioOnly mode. I've tested it, but I am looking
for a feature a little different.

I was very ambiguous, so I will describe it to be clearer.

Suppose a conference with multiple moderators and multiple participants.
Moderators and participants can share their video, but only moderators
can see/receive videos.
In this scenario:
1. Moderators can see/receive each other's videos.
2. Moderators can see/receive participants' videos.
3. Participants cannot see/receive anyone's video.

It's easy to remove the 'seeing' part of the participants, but I
remove it superficially because I keep receiving video streams
(according to the webrtc-internals).

By using audioOnly, I am setting the channelLastN config that will be
applied to the whole conference, correct?

I'm not sure I understand your scenario, but an answer to this last question: using audioOnly changes the channelLastN value, but this value affects only the specific channel/endpoint, not the whole conference.

As for the scenario: I don't understand whether this is something that you want implemented in jitsi-meet, or something that you want to implement on your own using the library and other existing tools (setting lastn, selected, pinned endpoints).

Regards,
Boris

···

On 24/04/2017 13:32, Camilo wrote:


#3

Hi Camilo,

Hello everyone,

I asked today's call about a feature about stopping the video in a
conference.
Emil mentioned the audioOnly mode. I've tested it, but I am looking
for a feature a little different.

I was very ambiguous, so I will describe it to be clearer.

Suppose a conference with multiple moderators and multiple participants.
Moderators and participants can share their video, but only moderators
can see/receive videos.
In this scenario:
1. Moderators can see/receive each other's videos.
2. Moderators can see/receive participants' videos.
3. Participants cannot see/receive anyone's video.

It's easy to remove the 'seeing' part of the participants, but I
remove it superficially because I keep receiving video streams
(according to the webrtc-internals).

By using audioOnly, I am setting the channelLastN config that will be
applied to the whole conference, correct?

I'm not sure I understand your scenario, but an answer to this last
question: using audioOnly changes the channelLastN value, but this value
affects only the specific channel/endpoint, not the whole conference.

Ok, I will check on that. It may be enough for this feature. Thank you.

As for the scenario: I don't understand whether this is something that you
want implemented in jitsi-meet, or something that you want to implement on
your own using the library and other existing tools (setting lastn,
selected, pinned endpoints).

No. I don't want it in jitsi-meet. I only would like to know if this
is possible with the current state of lib-jitsi-meet and
jitsi-videobridge.

···

On Mon, Apr 24, 2017 at 4:08 PM, Boris Grozev <boris@jitsi.org> wrote:

On 24/04/2017 13:32, Camilo wrote:

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Hi Camilo,

Hello everyone,

I asked today's call about a feature about stopping the video in a
conference.
Emil mentioned the audioOnly mode. I've tested it, but I am looking
for a feature a little different.

I was very ambiguous, so I will describe it to be clearer.

Suppose a conference with multiple moderators and multiple participants.
Moderators and participants can share their video, but only moderators
can see/receive videos.
In this scenario:
1. Moderators can see/receive each other's videos.
2. Moderators can see/receive participants' videos.
3. Participants cannot see/receive anyone's video.

It's easy to remove the 'seeing' part of the participants, but I
remove it superficially because I keep receiving video streams
(according to the webrtc-internals).

By using audioOnly, I am setting the channelLastN config that will be
applied to the whole conference, correct?

I'm not sure I understand your scenario, but an answer to this last
question: using audioOnly changes the channelLastN value, but this value
affects only the specific channel/endpoint, not the whole conference.

Ok, I will check on that. It may be enough for this feature. Thank you.

As for the scenario: I don't understand whether this is something that you
want implemented in jitsi-meet, or something that you want to implement on
your own using the library and other existing tools (setting lastn,
selected, pinned endpoints).

No. I don't want it in jitsi-meet. I only would like to know if this
is possible with the current state of lib-jitsi-meet and
jitsi-videobridge.

I think it depends on whether you need to enforce it or not.

> 1. Moderators can see/receive each other's videos.
> 2. Moderators can see/receive participants' videos.
> 3. Participants cannot see/receive anyone's video.

You can achieve 3 by setting channelLastN to 0 on participants' channels (provided that you trust participants not to change it back). There's nothing special needed for 1 and 2.

Regards,
Boris

···

On 24/04/2017 14:55, Camilo wrote:

On Mon, Apr 24, 2017 at 4:08 PM, Boris Grozev <boris@jitsi.org> wrote:

On 24/04/2017 13:32, Camilo wrote: