- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Feb 2015 05:31:01 +0000
- To: public-media-capture-logs@w3.org
Aren't these problems theoretical rather than important to solve in
implementations?
#### Case 3: Linked configuration parameters
Last I checked, the Logitech C910 on Windows supports about 54
combinations of width/height/framerate/codec. The OSX camera driver
seems to only like multiples of 40x30 and 128x72, in less than 25
working increments (multiplied by framerate I suppose).
Why not leave it to implementations to optimize prematurely?
#### Case 2: Orthogonal configuration parameters
Orthogonal capabilities are just that, orthogonal. E.g. a { zoom: {
min: 0.0, max: 1.0 } } capability would work the same regardless of
other settings, which in practical terms means that "constraining on
width/height/zoom" is no more interesting than constraining on
width/height and then "setting" (constraining) zoom on the result.
Said differently: A settings dictionary of { width: 640, height: 480,
zoom: x } where x allows any legal zoom value, is the logical
aggregate of an infinite number of sets that lets you stick with the
Case 1 algorithm. Since x adapts (by the algorithm effectively
ignoring x) it has no 'actual' value and would not contribute fitness
distance.
I realize this sounds like your min-max triplet, but why track changes
to x at all, except to support contradictory combinations in the
advanced algorithm?
advanced: [ { zoom: { max: 0.2 }, width: 640 },
{ zoom: { min: 0.3 }, width: 800 } ]
And why would anyone care about such nonsensical cases?
--
GitHub Notif of comment by jan-ivar
See
https://github.com/w3c/mediacapture-main/issues/118#issuecomment-74207377
Received on Friday, 13 February 2015 05:31:10 UTC