- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Sat, 27 Feb 2021 16:02:06 +0000
- To: public-webrtc-logs@w3.org
> This would make all implementations work in a more predictable way, especially in the common cases where few or no constraints are passed to gUM I'm sympathetic to web compat concerns, which we experience as well. However, I'm not sure this would be better for users. Constraints were purposely designed to balance control between two stakeholders: the user and the application, perhaps best illustrated by their two extremes: 1. The user configures the camera and settings they want in their OS or browser, perhaps with per-site exceptions. 2. Each application configures what camera and settings to use 1 is an unconstrained track. 2 is a constrained track. This is why constraints were purposely designed to _not_ specify defaults, and why constraints are distinct from settings in the API in the first place. User agents conspiring on a fixed set of default settings forever for all devices in the interest of web compat for apps, would wreck 1. For example: If a user inserts a stereo microphone they just bought, why shouldn't they get stereo on every site out there? One of the advantages of the native WebRTC stack is that this can just work without requiring each app to support it. Browsers may not be doing much with their defaults atm, but defaulting to 640x480x30 mono forever doesn't seem very forward looking. I don't think we should lock ourselves down there. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/775#issuecomment-787094875 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 27 February 2021 16:02:08 UTC