Re: Proposed Change to RTCRtpSender "doohickey" proposal

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.

Received on Sunday, 4 May 2014 09:32:10 UTC