- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Wed, 17 Sep 2014 09:48:42 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, public-media-capture@w3.org
- Message-ID: <5419913A.5030209@mozilla.com>
On 9/17/14 8:05 AM, Harald Alvestrand wrote: > On 09/16/2014 11:00 PM, Harald Alvestrand wrote: >> https://github.com/w3c/mediacapture-main/pull/20 > + For all numeric non-required constraints > + (height, width, framerate, aspectRatio, > + sampleRate and sampleSize), use the > + formula <pre>(actual == 0) ? ideal : |actual - > + ideal|/actuall</pre>. Great! I've raised nits in git, but thought I'd raise discussion-worthy points here on the list: 1. I thought the algorithm was to divide by ideal, not actual [1] 2. Doesn't "All numeric ... constraints" include future numeric constraints? I suggest: * change text to: (currently: height, width, frameRate, aspectRatio, sampleRate and sampleSize)". * change algorithm to tolerate negative numbers: |(actual - ideal)/ideal|. 3. By summing up distances of different numeric constraints, we're comparing apples to oranges, which is fine as I don't have a better idea. But, shouldn't we at least give equal weight to each numeric constraint? I think having distances converge toward 1 would produce fairer comparison between constraints [2], and suggest: * change algorithm to have distance converge toward 1: |(actual - ideal)/max(|ideal|,|actual|)| > + For all non-required string and enum > + constraints (sourceId, groupId, facingMode, > + echoCancellation), use the > + formula <pre>(actual == ideal) ? 0 : 10</pre>. I think 1 rather than 10 would be the "equal weight" number, and that anything larger trumps the algorithm, and users should just use exact instead. The edge-cases lost by this were too complicated anyway, and should be weighed against the edge-cases afforded by 1. .: Jan-Ivar :. [1] http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0005/Finding_an_-Ideal-_Algorithm__2_.pdf#Page=4 [2] http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0041.html
Received on Wednesday, 17 September 2014 13:49:07 UTC