- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2019 21:24:31 +0000
- To: public-webrtc-logs@w3.org
> At least the way Chrome is implemented, you would never reconfigure a camera such that existing tracks become overconstrained. That's spec mandated and true in other browsers as well. *applyConstraints* is first-come first-served. TL;DR: I see no practical uses of the *overconstrained* event, locally or remotely. I suspect it's there to complete a general pattern. I'd rather remove it than look for uses for it, as I prefer use-cases driving design over symmetry. * It's redundant: just measure the output directly and react to it. * It's undesired: demand has not materialized in 5 years. The given rationale for *overconstrained* is physical manipulation of the camera or environment. [11.1](https://w3c.github.io/mediacapture-main/getusermedia.html#interface-definition): *"For example, the user might physically manipulate a camera in a way that makes it impossible to provide a resolution or frameRate that satisfies the constraints"*. - a hypothetical *fillLightMode* in ["The model"](https://w3c.github.io/mediacapture-main/getusermedia.html#the-model-sources-sinks-constraints-and-settings). A [low-interest](https://github.com/w3c/mediacapture-main/issues/193#issuecomment-135452690) [example](https://w3c.github.io/mediacapture-main/getusermedia.html#constrainable-interface) mentions: *"Note that the frameRate minimum might be within the capabilities of the camera and satisfiable in ideal lighting conditions, but not in low light, and could therefore result in firing of the onoverconstrained event handler under poor lighting conditions."* > Why do we have overconstrained if not for remote tracks? Circular reasoning. They may both be useless. They don't validate each other. 😉 -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/573#issuecomment-470700204 using your GitHub account
Received on Thursday, 7 March 2019 21:24:32 UTC