W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [mediacapture-main] What constraint name should be exposed in case of a getUserMedia query with multiple failing constraints (#562)

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
Message-ID: <issue_comment.created-457726226-1548449996-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:54 UTC