- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Jan 2019 20:59:57 +0000
- To: public-webrtc-logs@w3.org
> FWIW, I believe constraintName might not be sufficient as is. > It does not provide, on its own, sufficient information for widely used cases like getUserMedia({audio: true, video: true}) Hmm? That's an unconstrained case. It would never fail with *OverconstrainedError*. > or getUserMedia with both audio/video deviceId constraints. The only cross-kind constraints are *deviceId* and *groupId*, so yes if you double up and get `OverconstrainedError` with an `error.constraint` of `"deviceId"`, then yes, you'll have to guess whether camera or mic was the problem, and try again. As I recall, the WG decided to punt on that. > I would think that in many cases, it is the combination of constraints that make the query fails. > Say I want a 4K/120fps camera, but my system only has 4K/60fps or HD/120fps. > Whether we return frameRate or width does not provide enough information for the web app to reason about it. This is covered in the [examples](https://w3c.github.io/mediacapture-main/getusermedia.html#constrainable-interface). Set your minimum requirements, then use `advanced`: ```js { height: {min: 1080, ideal: 2160}, frameRate: {min: 60, ideal: 120}, advanced: [ {height: 2160, frameRate: 120}, {height: 2160, frameRate: 60}, // I prefer resolution over frame rate {height: 1080, frameRate: 120}, // etc. ] } ``` -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/562#issuecomment-457726226 using your GitHub account
Received on Friday, 25 January 2019 20:59:58 UTC