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])
>
> 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.
>
I think I've mentioned this before....

if an item is able to return the last successfully applied constraint 
set, and we set the complete constraint set rather than doing piecemeal 
application, a JS app can apply its own desired manipulations on the 
setting.

ie if you want to just insert a more important framerate.

whatever.applyConstraints(whatever.getCurrentConstraints().optional.append({framerate: 
120}))

if you want to make a mandatory framerate:

constraints = whatever.getCurrentConstraints();
constraints.mandatory['framerate'] = 120;
if (whatever.applyConstraints(constraints)) {
    // framerate is now set
} else {
    // no constraints changed at all
}

I have on my not-yet-done list an attempt to prove (in JS) that the 
interface proposed by Travis can be implemented on top of such a lower 
level interface. For now, I just have to state the claim.

Received on Wednesday, 5 December 2012 15:44:32 UTC