W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: [Bug 23820] New: Add special values for PropertyValueRange to enable preference specification in optional constraints

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 20 Nov 2013 17:41:36 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Jan-Ivar Bruaroey <jib@mozilla.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3F291A@ESESSMB209.ericsson.se>
On 20/11/13 18:27, Martin Thomson wrote:
> On 20 November 2013 08:17, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> Shouldn't we first nail down what min and max mean? e.g.
> This I agree with.  But the answer might not be as deterministic as
> you might like.
>> - Does { mandatory: { width: { min: 1024 } } } conservatively give me
>> 1024x768
>>    or the highest available because I didn't constrain upward?
>> - Does { mandatory: { width: { max: 2880 } } } aggressively give me
>> 2880x1800
>>    or the lowest available because I didn't constrain downward?
>> - Given choices, what does { mandatory: { width: { min: 1024, max: 2880 } }
>> } give me?

I'm going to throw in one more thing here (relevant only to 
width/height/aspect): how do we relate this to the width and height of 
the consumer?

Say a video MediaStreamTrack with mandatory setting of width min 1024 is 
only attached to a video element with a width of 200. Should the camera 
really produce a stream with width 1024, only to have it scaled at 
display time?

> The answer to these is universally, "I don't know".  And I think that
> I am perfectly comfortable with that.
>> I think we need to establish default behavior of the algorithm here (please
>> point me to it if this is already done).
> I disagree.  Obviously, we would like to have a situation where the
> "best" source is selected, but that is a multi-dimensional
> optimization problem that the browser is required to manage.  Then
> there is user preference thrown in.
> When you get down to it, constraints on selection are just additional
> input into the selection algorithm that the browser chooses to
> implement.
> Given that, I think that it would be folly to specify an algorithm to
> the extent that different browsers produce identical results for all
> variations of constraints and sources.  There's a place for
> standardization, but I don't think that this is it.
> I don't think that having additional preferences is necessary.  That
> is the function that optional constraints fulfill already.  Having
> more ways to influence the selection algorithm is only going to make
> it harder to build and understand.  I worry that we are already in
> that situation; let's not make it worse.
> (Actually, I do like the "prefer" suggestion.  But it's duplicative,
> so I'd be interested only if you also remove optional constraints at
> the same time.  I consider that to be an unlikely outcome at this
> stage.)
Received on Wednesday, 20 November 2013 17:42:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC