W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2014

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>
To: public-media-capture@w3.org
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 

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