Re: Proposed Change to RTCRtpSender "doohickey" proposal

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
Genesys

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