Re: Handling simulcast

On 6 September 2013 01:33, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> One use of simulcast I had in mind was for the usual multiparty, with
> central node, conferencing case where the active speaker is shown in a
> large video window (with thumbnail videos for others).

Right.  The reason I'm thinking this way is that it makes the use of
meshed video conferencing possible (probably only for small groups
though).  Being able to simply disable send on the video when the
audio is not active makes this a pretty elegant and cheap way to save
bandwidth.

> For this case I think we already have the basic things needed:

Yep.  I think that's perfectly OK.

> What is missing is the possibility to stop sending the high (or low)
> resolution video from the end-point to the central node if it is not
> forwarded to anyone. This would basically be to save transmission, and
> we would need pause/resume, but as others have pointed out a video track
> can be disabled (which would lead to encoding blackness) which also
> saves a lot of bits.

I think that disabled is perfectly adequate.

> To handle the case you describe below we would need to add some kind of
> meta data to the track, but it does not seem that hard to do.

Yes, playback is a little tricky without something like that, as above.

Received on Friday, 6 September 2013 17:03:22 UTC