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

SVC with multiple senders makes no sense to me, either with MRST or SRST.  You would have a single bitstream that would need to be packetized by two or more senders, creating a lot of complexity in implementation. That said, given that VP8/VP9/AV1 are all SRST, the MRST case is probably not worth much of our attention (assuming that the HEVC vampire stays in its crypt).

On Apr 12, 2016, at 12:38, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

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<mailto: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<mailto:pthatcher@google.com>> wrote:
​Here are the minutes from the main meeting:

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2015%2f09%2f10-webrtc-minutes%23item08&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c8032f83dba90425e8a6508d362f0e881%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bgfC%2fqexEcweXH9iKLkbWHkio6h4UGWOkky06I3r738%3d>https://www.w3.org/2015/09/10-webrtc-minutes#item08<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2015%2f09%2f10-webrtc-minutes%23item08&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c8032f83dba90425e8a6508d362f0e881%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bgfC%2fqexEcweXH9iKLkbWHkio6h4UGWOkky06I3r738%3d>

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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.w3.org%2fArchives%2fPublic%2fpublic-webrtc%2f2016Feb%2f0020.html&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c8032f83dba90425e8a6508d362f0e881%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7aIH7SBlhginkPT7oAFpKR1JmhPAxLAPDfGiJ6a3VNY%3d>


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 <<mailto:sergio.garcia.murillo@gmail.com>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 <<mailto:sergio.garcia.murillo@gmail.com>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