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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 08 Aug 2014 14:38:41 +0200
Message-ID: <53E4C4D1.9080306@alvestrand.no>

```I actually don't see much use for the "weak match" - there seems no
strong argument for keeping facingMode to a value of 1 while groupId has
a value of 1000, but there seems to be good arguments for both being
regarded as "more important" than a minor discrepancy in framesize.

I suggest having MATCH be the only defined mode, and the "not-match"
distance be 10, not 1.

(I pulled "10" out of a hat. It will trump most mode changes, including
being given QVGA when the ideal is 4K, but won't trump a discrepancy
when someone thinks QVGA is ideal, and the only camera available is
4K-only).

On 08/05/2014 08:46 PM, Peter Thatcher wrote:
> On Tue, Aug 5, 2014 at 11:42 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> On 8/5/14 2:13 PM, Peter Thatcher wrote:
>>
>> 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.
>>
>>
>> I tried your spreadsheet and this seems to be because it produces a negative
>> distance, which seems wrong.
>>
>> I suggest changing the algorithm from abs(actual-ideal)/ideal to
>> abs((actual-ideal)/ideal) to avoid that. Then it's just a long absolute
>> distance and no harm done.
> That sounds like a good idea.  In that case, we'd only have to deal
> with divide-by-zero.
>
>>
>> 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.
>>
>>
>> That's clever and sort of oddly binary, and then only works with sourceIds.
>> And wouldn't this tend to work with a value of 1 as well?
>>
>>
>>    { 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.
>>
>>
>> I think the more special cases we make then the weaker it makes the
>> algorithm seem. I'd like to think we've found some inherent relationship.
>>
>> .: Jan-Ivar :.
>>
```
Received on Friday, 8 August 2014 12:39:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:29 UTC