- From: Coread via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Mar 2023 16:21:20 +0000
- To: public-webrtc-logs@w3.org
I think I was being confused by the naming here. getUserMedia takes an argument called "constraints" which is NOT the same as a the constraints returned from getSupportedConstraints. getDisplayMedia takes options, which is similar to the getUserMedia "constraints" but has extra parameters for various things. So "displaySurface" is a valid MediaTrackConstraint (althought only in the context of getDisplayMedia) and so appears in getSupportedConstraints. It is interesting how things that relate to either audio or video are instead added at the options e.g. systemAudio, instead of being added as a media track constraint. Is that something to do with this line: "Constraints serve a different purpose in [getDisplayMedia](https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices-getdisplaymedia) than they do in [getUserMedia](https://www.w3.org/TR/mediacapture-streams/#dom-mediadevices-getusermedia)(). They do not aid discovery, instead they are applied only after user-selection." anyway, with regards to getSupportedOptions, yes it is does seem like a useful idea, especially since things that act in a constraint like way are included in the options and so it is hard to feature detect them otherwise. -- GitHub Notification of comment by Coread Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/260#issuecomment-1479879008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 March 2023 16:21:22 UTC