- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Jan 2019 17:23:54 +0000
- To: public-webrtc-logs@w3.org
It makes sense to me for the WG to first decide whether filtering constraintName is feasible or not, and if so, as a MAY or a MUST.
> but also bet against it succeeding (have you seen [section 7.2](https://w3c.github.io/mediacapture-main/getusermedia.html#overconstrainederror-object)? someone must really want it) 😉
Let's try to see whether we can make it succeed!
It would be nice if the people supporting this error reporting could chime in and express whether such change would break their use cases and why it is important to have it pre-grant info compared to post-grant.
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}) or getUserMedia with both audio/video deviceId constraints.
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.
> I think that's going to be harder to get through at this point (this spec is in CR).
Well, this spec is expected to go into another CR soon which means substantive changes have been made since the first CR.
Maybe we should delay a little bit the publication of this new CR if it reduces our ability to properly fix those issues.
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/562#issuecomment-457648893 using your GitHub account
Received on Friday, 25 January 2019 17:23:56 UTC