- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Aug 2017 17:38:40 +0000
- To: public-media-capture-logs@w3.org
Let's contain the scope to keep this productive. To clarify my [problem statement](https://github.com/w3c/mediacapture-main/issues/472#issue-248089527), my intent here is only to try to bridge the gap between *existing browser features*. For new problems, open new issues: * Video mirroring is https://github.com/w3c/mediacapture-main/issues/452. Let's agree to disagree in that issue, not here. * Screen-sharing has its own [spec](https://w3c.github.io/mediacapture-screen-share/#constraints) which doesn't even allow constraints for initial selection, making most of your arguments there moot. Users read `track.getSettings()` modify them and set them with back with `track.applyConstraints()`. No need for `min`, `max`, `exact`, `ideal` or `advanced`. Disagree? Please open an issue in that spec. * Sky isn't falling. https://github.com/w3c/mediacapture-main/issues/473 adds a SHOULD around some existing browser behavior. *Reduces* entropy. * There's no gap in microphone constraints. No change there. * New features from new processing constraints are out of scope. File a separate issue please. * This thread is getting long. Let's try to be brief. People can scroll to see earlier arguments. > I agree that it's a good idea to allow applications to express that they prefer or require "native" values, even if no Chrome users have filed bugs asking for that feature. That problem seems unique to Chrome, because of its choice to not fully utilize the full expressiveness of the constraints language. > Our disagreement is about how to introduce that concept in the spec. That concept is already in the spec, as evidenced by Firefox and Edge users not having this problem. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/472#issuecomment-321028355 using your GitHub account
Received on Tuesday, 8 August 2017 17:38:40 UTC