- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Aug 2017 15:54:25 +0000
- To: public-media-capture-logs@w3.org
@fippo I think that expectation faces a couple of hurdles: 1. From a browser standpoint it's really undesirable to have constraints be able to detect camera use in other tabs, for privacy and security reasons. We're probably [more inclined](https://bugzilla.mozilla.org/show_bug.cgi?id=1388667#c2) to downscale in these nonoptimal edge-cases, to abstract away knowledge of other tabs. 2. From what I've seen, frame rates fluctuate on most cameras depending on lighting etc. so it's normal for actual frame rate to dip below constrained target-`frameRate`, even with `exact`. AFAIK none of the browsers implement the [overconstrained](https://w3c.github.io/mediacapture-main/getusermedia.html#event-mediastreamtrack-overconstrained) event. How can we implement it at this point when users are already using `exact` to force rescaling? I'm pretty sure those users would complain if we suddenly began muting their tracks. The rare app that wants this is probably better off [measuring actual frame rate](https://jsfiddle.net/jib1/suLvcr3a/ ), and making its decision off of that instead. 4. Constrainable properties may be configured settings, not actual values. https://github.com/w3c/mediacapture-main/issues/470 3. We can decimate from 60 to 24 fps without creating "fake" data, it just won't be smooth. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/466#issuecomment-324070691 using your GitHub account
Received on Tuesday, 22 August 2017 15:54:24 UTC