Re: Fifth iteration of Settings API now available

On 12/05/2012 04:43 PM, Harald Alvestrand wrote:
> 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}))

"append" sounds like you're adding a new constraint at the end of the 
list; what happens if there is already a "framerate" constraint (but 
with another value) in the set?

(That was a detail)

Even if you have no code to prove it, I agree that we could solve all 
settings by using a constraint structure in the way you indicate. 
However, regarding API design, I think the "get" and "set" way is more 
in line with what web authors would expect (and my preference). This is 
mostly a matter of taste.

I brought the "order of preference" thing up; but perhaps it is not that 
big a thing. I think the only potential conflict would be between 
resolution and framerate; the others are orthogonal to each other 
(referring to the list at 
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v5.html#idl-def-VideoConstraints).

Stefan

Received on Thursday, 6 December 2012 08:36:41 UTC