Re: Proposal: One media RTP packet stream (i.e. one SSRC) per RTCRtpSender/RTCRtpReceiver object

Agree with Peter's argument here.

It makes no sense to have multiple RtpSenders when doing SVC, and simulcast
is just a special case of SVC.

On Fri, Apr 8, 2016 at 7:31 AM, Peter Thatcher <pthatcher@google.com> wrote:

> ​Here are the minutes from the main meeting:
>
> https://www.w3.org/2015/09/10-webrtc-minutes#item08
>
> But that's probably hard to read.
>
> You could also check this more recent mailing list thread where I
> suggested using multiple RtpSenders in certain (bizarre) simulcast
> scenarios, and the disinterest in doing so.
>
> https://lists.w3.org/Archives/Public/public-webrtc/2016Feb/0020.html
>
>
> My memory is a bit fuzzy, but I remember the main reasons being:
> - It's much easier to reason about performance degradation if you know
> there are 3 encodings in one RtpSender than 3 RtpSenders.
> - It's much easier for implementations to get the performance right with 3
> encodings in one RtpSender than 3 RtpSenders.
> - When doing simulcast, it's easier to use the API with one RtpSender than
> many
> - Keeping simulcast and SVC more similar is nicer than making them look
> completely different.  It's not reasonable to have 3 RtpSenders when doing
> SVC.
>
> On Fri, Apr 8, 2016 at 1:25 AM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>> On 07/04/2016 23:05, Peter Thatcher wrote:
>>
>>
>>
>> On Thu, Apr 7, 2016 at 8:17 AM, Sergio Garcia Murillo <
>> <sergio.garcia.murillo@gmail.com>sergio.garcia.murillo@gmail.com> wrote:
>>
>>> Hi Peter,
>>>
>>>
>>> Also take note that 2, with current propossal can be implemented in two
>>> ways, one RTPSender per ssrc (same as my proposal) or all ssrcs in same
>>> RTPSender. In order to implement 3 with current proposal it is only
>>> possible to do it with several RTPSenders.
>>>
>>
>> ​ WebRTC only supports #2, and I think ORTC should only support #2.  You
>> are correct that with the current WebRTC and ORTC APIs, one could
>> accomplish the same thing with one RtpSender or many.  But requiring many
>> is an option that was rejected by the WebRTC WG.
>> ​
>>
>>
>>
>> Do you know what were the objections for rejecting multiple RTPSenders
>> for simulcast (with ssrc-multiplexing over same transport)?
>>  It is something that needs to be supported anyway by the browser and
>> given that each layer is an independent encoder there should be no
>> performance penalty.
>>
>> I mean, currently we can do this (in pseudocode)
>>
>> RTPSender.send({
>>     encodings: [
>>         {ssrc:1,pt:100,codec:vp8,},
>>         {ssrc:2,pt:100,codec:vp8,resolutionScale: 2.0},
>>     ]
>> })
>>
>> or
>>
>> RTPSender1.send({
>>     encodings: [
>>         {ssrc:1,pt:100,codec:vp8,},
>>     ]
>> })
>>
>> RTPSender2.send({
>>     encodings: [
>>         {ssrc:2,pt:100,codec:vp8,resolutionScale: 2.0},
>>     ]
>> })
>>
>> Both will produce the same result
>>
>> Best regards
>> Sergio
>>
>>
>>
>>
>>
>>
>>
>