W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Proposed Change to RTCRtpSender "doohickey" proposal

From: Jim Barnett <1jhbarnett@gmail.com>
Date: Sun, 04 May 2014 08:55:43 -0400
Message-ID: <536638CF.2040103@gmail.com>
To: public-webrtc@w3.org
Would the API allow the receiving side to indicate which parts of the 
Offer it wanted to accept?  In other words, it wouldn't change the 
offer/answer model, but would make it easier to avoid parsing SDP.

On 5/4/2014 5:31 AM, Stefan Håkansson LK wrote:
> On 30/04/14 22:55, Cullen Jennings (fluffy) wrote:
>> So this is probably the most important email I am sending on this
>> thread … A small change that would make me like this doohickey
>> proposal much more …
>> First would be a way to add a new encoding to a Sender or tell the
>> sender to create another encoding or something like that.
>> On Apr 28, 2014, at 9:58 AM, Justin Uberti <juberti@google.com>
>> wrote:
>>> // used with RTCRtpSender interface RTCRtpEncodingParams { double
>>> priority = 1.0;  // relative priority of this encoding unsigned int
>>> maxBitrate = null;  // maximum bits to use for this encoding
>>> boolean             active;  // sending or "paused/onhold" };
>> The second would be a way to update constraints at the encoding
>> level, this would allow us to set things like resolutions, aspect
>> ratios, and frame rates at the encoding level.  That is one one of
>> the use cases driving doohickeys.
>> The third would be a have RTCRtpReceiver also have a set of
>> RTCRtpEncodingParams.
>> I think we will need something like this to make this proposal work
>> because what is sent over the wire is not solely selected by the
>> sender but is a negotiation between the sender and receiver.
> That is correct, but are you proposing that the apps should be actively
> involved in the negotiation (i.e. the app at the receiving end uses the
> RTCRtpEncodingParams to influence the negotiation)?
> I thought the SDP O/A was the negotiation, and that it would be
> sufficient to have an API on the sending side where the app _can_
> indicate wanted layered/simulcast configurations (as Martin proposed).
> I also think that we could postpone the simulcast/layered stuff for a
> later version.

Jim Barnett
Received on Sunday, 4 May 2014 12:56:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC