Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls?

[Iñaki Baz Castillo <[e-mail]>]

> I think the text would have to say that we discard encodings from either
the beginning or the end of the list (I'd suggest the end).
Sorting is going to make some of the people unhappy, some of the time.

If in my example above the browser discards encodings at the
beginning, those would remain:

- 400kbps
- 750kbps
- 1000kbps

which are not good for common simulcast usage.

If in my example above the browser discards encodings at the end,
those would remain:

- 150kbps
- 120kbps
- 400kbps

which are not good for common simulcast usage.

:)


On Mon, 5 Nov 2018 at 22:33, Harald Alvestrand <[e-mail]> wrote:
>
> On 11/05/2018 03:33 PM, Iñaki Baz Castillo wrote:
> > On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo
> > <[e-mail]> wrote:
> >> By the way, according to the simulcast draft that should not be a problem at all:
> >>
> >>    An answerer that receives an offer with simulcast that lists a number
> >>    of simulcast streams, MAY reduce the number of simulcast streams in
> >>    the answer, but MUST NOT add simulcast streams.
> > Not sure if that also covers "recv" simulcast items in the offer.
> > Probably yes, so ok.
> >
> > However still useless IMHO. Imagine an SFU that wants to receive, at
> > least those bitrates (because somehow it knows that all devices can
> > handle at least 3 simulcast streams):
> >
> > - 150kbps
> > - 400kbps
> > - 1000kbps
> >
> > Imagine there are also some devices supporting up to 5 streams, so the
> > SFU produces this simulcast settings in the offer for receiving:
> >
> > - 150kbps
> > - 120kbps
> > - 400kbps
> > - 750kbps
> > - 1000kbps
> >
> > If a device that just supports 3 simulcast streams receives such an
> > offer, it would discard 2. Which ones? ok, the SDP can include info
> > about the desired max-bitrate per rid, and we may think: oh, we can
> > get the list of rids and bitrates  after pc.setRemoteDescription() by
> > calling pc.getTransceivers()[1].receiver.getParameters().encodings, so
> > the app can decide which ones to enable.
> >
> > But that's not true since receiver.getParameters() should not contain
> > more rids than those supported by the device. Well, this constraint is
> > really about sender.getParameters(). So you may say: ok we somehow
> > read the maximum simulcast streams that our browser/device can send
> > and then choose the appropriate ones from the receiver can call
> > transceiver.sender.setParameters() with them.. Error! there is no API
> > for knowing the max number of simulcast streams the browser can
> > produce.
> >
> > Too many assumptions and non existing features in this text to make
> > this scenario really possible.
>
> I think the text would have to say that we discard encodings from either
> the beginning or the end of the list (I'd suggest the end).
> Sorting is going to make some of the people unhappy, some of the time.
>
>
> --
> Surveillance is pervasive. Go Dark.
>


-- 
Iñaki Baz Castillo
<[e-mail]>