Re: Fifth iteration of Settings API now available

I agree with most of Stefan's comments.  I particularly like the
simplifications for settings.  Fewer features === better.

bitRate is something that the sink (RTCPeerConnection) can communicate
back to its source, or it can resize at the encoder as it sees fit

On 4 December 2012 10:55, Travis Leithead <travis.leithead@microsoft.com> wrote:
>> e) We would need to specify if/how the change of one setting alters the
>> preference order. IIUC the constraints structure, if used only with
>> optional constraints, establishes an order of preference. If the first
>> constraint is framerate it says that maintaining framerate within the
>> bounds is more important than the following constraints. What happens if
>> you later on change one that has lower priority? Does it pop to the top
>> of the list?
>
> Yes this needs to be defined. To avoid having to re-apply all the prior constraints just to maintain relative priority, there should be some more elegant way to in-line adjust a setting that was previously specified using the same relative priority, or to specify that a setting change trumps prior priority. Any suggestions for such a mechanism or different approaches are welcome...

Given that settings/constraints are an ordered set, maybe 'set' is the
wrong paradigm.

  whatever.insertSetting(settings [, position = 1])

With this, settings are inserted ahead of any existing setting at the
given position.  Mandatory settings are at position 0, so by default,
a non-mandatory setting is inserted.  (sanity note: position =
Math.max(0, Math.min(position, existingSettings.length)))

Unless we can agree to drop non-mandatory settings, which would make
this even easier to describe.

--Martin

Received on Tuesday, 4 December 2012 22:20:57 UTC