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

[Harald Alvestrand <[e-mail]>]

On 11/05/2018 10:37 PM, Iñaki Baz Castillo wrote:
>> 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.

If in your example, the writer of the SDP knew that the browser would
discard encodings at the end, it would send

- 150kbps
- 400kbps
- 1000kbps
- 120kbps
- 750kbps

That's predictable.

If it thought "biggest and smallest are most important", it could also
choose to send

- 120kbps
- 1000kbps
- 400kbps
- 150kbps
- 750kbps

If it thought "most clients are 400kbps, or 1000kbps, the 120kbps client
is only seen occasionally, and handles 3 streams anyway",
it could send

- 400kbps
- 1000kbps
- 120kbps
- 150kbps
- 750kbps

If the behavior of the responder is predictable, the initiator can
achieve the result it wants.

>
> :)
>
>
> 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.
>>
>

-- 
Surveillance is pervasive. Go Dark.