- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 03 Apr 2014 12:22:48 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, public-media-capture@w3.org
On 4/3/14 5:21 AM, Harald Alvestrand wrote: > (continuing actual discussion on list, since it clutters up bugzilla) > > On 04/03/2014 11:14 AM, bugzilla@jessica.w3.org wrote: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22593 >> >> --- Comment #4 from Dominique Hazael-Massieux <dom@w3.org> --- >> Makes sense; so that leaves the question of the meaningfulness of having an >> array of values for facingMode in capabilities. >> >> In particular, the example in 11.3 has: >> facingMode": ["user", "environment"] >> which doesn't make sense to me; it may be that there is some (obsolete?) >> ambiguity about whether capabilities are at the UA level (which the text in >> 11.3 seems to imply) or at the source level. > [...] Each camera can only have a single value for facingMode, but it makes > perfect sense to say that multiple values for facingMode are acceptable. If cameras only had single values then wouldn't getSettings() suffice? :-) A camera that supports more than one facingMode is perhaps odd, but maybe it swivels? Why limit future cameras by limiting expression of limitations? Presumably, getCapabilities() in the context of a MediaStreamTrack is there to support applyConstraints() so that one can use it with some probability of success. If the UA factors out multi-functional devices into separate logical devices, then at some point there wont be much left to constrain. .: Jan-Ivar :.
Received on Thursday, 3 April 2014 16:23:08 UTC