W3C home > Mailing lists > Public > public-ortc@w3.org > April 2016

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

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Fri, 8 Apr 2016 10:25:08 +0200
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-ortc@w3.org" <public-ortc@w3.org>
Message-ID: <57076AE4.1060003@gmail.com>
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
Received on Friday, 8 April 2016 08:25:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:59 UTC