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

If an application wants to use multiple RtpSenders or one encoding per
RtpSender, it already can, and there's nothing difficult about that.  I
don't see any "easiness of use" advantage there.  On the flip, side
requiring all applications to use multiple RtpSenders has a definite
"easiness of use" disadvantage for those applications that want to have one
RtpSender with multiple encodings.

However, I do question the worth of supporting SVC with multiple
RtpSenders.  For simulcast, like I said, the app can always do so.  But for
SVC?  I don't see any good reason to support SVC across multiple
transports/RtpSenders, regardless of what the RFC says is possible.

On Tue, Apr 12, 2016 at 1:19 AM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> Hi Justin, Peter,
>
> According to RFC 7656, there are three "usages" of SVC
>
>    - SRST:  Single RTP stream on a Single media Transport
>    - MRST:  Multiple RTP streams on a Single media Transport
>    - MRMT:  Multiple RTP streams on Multiple media Transports
>
> Currently, only SRST and MRST are supported as all the encoding in the SVC
> must be in the same RTCRtpSender. The current spec also gives the solution
> on how to support MRMT with same API, just make the encodingIds global, so
> the SVC encodings could be owned by different RTCRtpSenders.
>
> Same terminology could be used on simulcast, and also only SRST and MRST
> would be supported  by current ORTC spec, and MRMT would be impossible with
> current API. Regarding performance of doing simulcast with several encoders
> vs single encoder instance, I fail to see how it could re-use encoding
> process for several unrelated streams, but if you say so, I have to believe
> you.
>
> This could be overcome with a similar solution as the one proposed for SVC
> MRMT, use the same encodingId in all encodings belonging to the same
> simulcast across different RTPSenders.
>
> We would handle simulcast and SVC exactly in the same way:
>
>    - SRST: Single RTPSender, one payload per encoding, one transport
>    - MRST: Multiple RTPSenders, one transport
>    - MRMT:  Multiple RTPSenders, multiple transports
>
> I completely disagree with the "easiness of usage" of current API, I feel
> that we are just using a jsonized-m-line containing all the information and
> passing it to a RTCPeerconnection-like object that is almost an static
> function. In this regards, IMHO, this is against the reasons why ORTC was
> created on the first place, and I don't see the benefits from moving from
> WebRTC to ORTC.
>
> Anyway, as stated above my main concern is the easiness of use, and this
> was a non-distruptive proposal to try to improve it, while doing the
> minimal changes required.
>
> I will follow Robin advice (
> https://github.com/openpeer/ortc/issues/440#issuecomment-207794630) and
> work on a set of slides to see if at least we agree on which are the issues
> with current API design (maybe everyone else feels they are fine as they
> are, and we are wasting our time here).
>
> Best regards
> Sergio
>
>
> On 12/04/2016 6:31, Justin Uberti wrote:
>
> 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>
>> 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>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>