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

​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
>
>
>
>
>
>
>