- 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