Re: Fifth iteration of Settings API now available

On 12/04/2012 11:20 PM, Martin Thomson wrote:
> 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])

And, if you don't supply position/importance info the supplied setting 
is considered as the most important. This could work.

>
> 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.

Agreed.

>
> --Martin
>

Received on Wednesday, 5 December 2012 12:22:34 UTC