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

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

From: Shijun Sun <shijuns@microsoft.com>
Date: Tue, 5 Aug 2014 18:50:30 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Peter Thatcher <pthatcher@google.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <c901f63ec27e4d9ea340a9d23628fa55@BLUPR03MB405.namprd03.prod.outlook.com>
Here is some additional consideration based on the 'min distance' proposal.

There seems still concern on the potential complexity of the algorithm since the UA needs to enumerate through all the devices and modes for the 'distance' calculation.

It can be more manageable if we break down step-4 in the algorithm into the following two parts.

4. 1. device selection: going through the facingmode, sourceId, groupId logics to pick a device for each kind (i.e. video or audio).  It is likely a system could have its default capture device defined already.  In case there is no specific preference from the apps, we should stay with the default ones.

4.2 calculate the distances based on the width, height, aspectRatio, framerate, etc. for the selected device(s).


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, August 5, 2014 10:01 AM
To: Peter Thatcher
Cc: public-media-capture@w3.org
Subject: Re: Follow-up questions for details on the "min distance" algorithm

On 5 August 2014 09:46, Peter Thatcher <pthatcher@google.com> wrote:
> 1. Harald proposed putting in the text something like "behave as 
> though this were the algorithm: ...", to make it clear that the 
> implementation doesn't have to implement it exactly like that, 
> especially when dealing with cameras that have ranges rather than a 
> set number of modes.  Is that OK with everyone?

The key here is to prescribe the output so that all browsers produce the same output based on the same input and starting conditions.  So whatever editorial convention you need to use in order to achieve that, I don't mind.

> 2.  Someone (I think Martin) suggested we not give framerate special 
> treatment for being greater than the ideal, and make it behave the 
> same as width, height, and aspect ratio.  I'm fine with that.  We can
> just remove the "CLOSE_OR_GREATER" bucket.   Should we go ahead with
> that?

Jan-Ivar raised the point.

> 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?

An error is good.  You could ignore the value entirely, but I don't like hiding problems.

> 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?

In this case, I think that any value more than about 10 will have the same effect, so pick 100, 1000, 10million or whatever.

> 5.  Some changes to the min distance calculation were suggested, such 
> as squaring values.  If you have any, please try it out by forking 
> this spreadsheet:
> https://docs.google.com/spreadsheets/d/1amhQGmxq5TeE7R510HXKhqFpc_fU6o

> iTaGGO7pF_DKg/edit#gid=0 and applying it to some examples.  If the 
> results look good, please let us know the formula change you would 
> suggest.

I don't much mind.

Sum of squares will minimize Euclidean distance.  That is intuitively better, but I don't care.

Received on Tuesday, 5 August 2014 18:51:02 UTC

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