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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 6 Aug 2014 06:32:14 +0000
To: Peter Thatcher <pthatcher@google.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D03B38C@ESESSMB209.ericsson.se>
On 05/08/14 18:47, Peter Thatcher wrote:
> We reached a rough consensus on pursing "min distance" in general, but
> there are still a few details we need to decide on:
> 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?

This makes a lot of sense (and in fact Giri brought this up already in 
the DC meeting and we said that all algorithm definitions should have 
that text).

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

I think we should. Ideal has gravity, so if you want a high framerate 
you should put a high value (and if there is a min framerate you 
tolerate we have tools for that too).

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

Do we really need "strong match"? We have exact, we have advanced. I'm 
with Jan-Ivar on this one.


Received on Wednesday, 6 August 2014 06:32:41 UTC

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