Re: Follow-up questions for details on the "min distance" algorithm

On Tue, Aug 5, 2014 at 10:57 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> On 8/5/14 12:46 PM, Peter Thatcher wrote:
>>
>> 3.  What do we do with ideal values <= 0?  For all the constraints we
>> have so far, I think it would be easiest to just reject them with an
>> error.  Would that be OK?
>
>
> What harm do negative values cause? It seems to me that the algorithm just
> handles them, so why preclude them in future numerical constraints?

Weird stuff happens when I put in "-640" as my width.  Then things
further away from 640 are better then things closer.

>
>> 4.  When we want a "strong match", such as for sourceId, what should
>> the value be?  1000000?  "Infinity" has problems.  We really just need
>> a "big value".  Is that a "big value" good enough?
>
>
> This seems like a hack to make { sourceId: x } work like exact. If you want
> a specific camera, write:
>

It's no exactly like exact.  A different camera (not matching the
sourceId) could still be choosen if the specified camera (matching the
sourceId) had no modes that fell within the min/max/exact value of
other constraints.  For example, if you said you wanted min of 1080p,
and the camera with the matching sourceId only did 720p, but a second
camera did 1080p, the algorithm would still choose the 1080p camera,
because min/max/exact filters out before ideal comes into play.

>   { width: 2880, sourceId: { exact: x } }
>
> like we just agreed. ;-)
>
> Instead, why not 1 like we do for enums? I have no reason for 1 other than
> it seems consistent and is different from exact. If camera x doesn't support
> 2880 and I say:
>
>   { width: 2880, sourceId: x }
>
> how is that different from no user-facing camera supporting width=2880 and
> saying:
>
>   { width: 2880, facingMode: "user" }
>

We could do 1 instead of a "big value", in which case we would remove
the STRONG_MATCH bucket.  It seems like if an app says "use the
sourceId", that ought to have more weight then, say, framerate, but
maybe not.  You could make a case for simplifying here and not
guessing that the app wants such weight.  If the app has that much
preference, it could always use "exact".  I'd don't have a strong
preference either way, but it seemed like some extra weight behind
"sourceId" would make sense.



> ?
>
> .: Jan-Ivar :.
>

Received on Tuesday, 5 August 2014 18:14:28 UTC