- 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