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

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 
> <mailto: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
>     <mailto: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
>>         <mailto: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
>
>
>
>
>
>
>
>