[mediacapture-main] "user-chooses": Does required constraints make any sense now? (#669)

henbos has just created a new issue for https://github.com/w3c/mediacapture-main:

== "user-chooses": Does required constraints make any sense now? ==
The purpose of prompting and the user picking is...
1. Address privacy issues. If the user makes the decision, the application does not need to know what other options are available.
2. Ensure consistent prompting behavior across browsers.

My gut-reaction to the user making the choice is that we don't need a lot of constraints anymore.
But there is still value in specifying desired resolution and frame rate. If the application only wants X then exceeding X is just wasting resources. For example if the application is happy with VGA 20 fps then it wastes resources to open the camera at UltraHD 60 fps.

But what if your device(s) can't do what the application asks for?

**Example 1: I have a single device and it can only do 30 fps but the application is asking for 60.**
I would argue that 30 fps is better than no camera whatsoever.
I would also argue that if the requests rejects because of over-constraining, then we are exposing unnecessary information to the application.
- "60 fps" makes sense as a _guideline_, not as a _requirement_.
- Constraints should not be a way to probe for capabilities.

**Example 2: Front/back camera or multiple cameras. E.g. I have two cameras, one pointing at me and one pointing at my living room.**
Maybe one of the cameras can do HD and the other can't and the application is asking for HD. When it was the application's job to do the picking for you, it made a lot of sense to rule out which device to pick. If the user is picking anyway, I'm not sure it is valid to rule out options. In getDisplayMedia() we purposefully [prevented the application from influencing selection](https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices-getdisplaymedia), ensuring that we [only provide fingerprinting surface to whether audio, video and display surfaces are present](https://w3c.github.io/mediacapture-screen-share/#constraints).

I don't see why getUserMedia(), in a world where device picking is not the application's job, would be any different from getDisplayMedia(). I don't think it is valid to rule out one camera or the other. It is the user's decision whether to show their face or their living room.
- Constraints may possibly influence device settings, but should not influence user choices (e.g. which device).
- Device capabilities is not a valid guideline for what the "right choice" is. Example: even if HD is generally preferable, whether or not my camera can do HD has nothing to do with what the direction that camera is facing, which I as a user definitely care more about.

**Example 3: Audio+video? No, only audio? Re-prompt!**
Today, getUserMedia() asks for the kinds of media that was specified. And they're required, with "audio+video" you either give both or none. So the application may ask for both only to have a mute button later (unnecessarily opening both camera and microphone, not ideal for privacy), or it asks, rejects and then asks again. Or the application asks the user in an application-specific UI which kinds to pass in to getUserMedia(), doing some of the choosing for the user outside the browser UI.

---

Discussion:
- Should constraints be able to limit the user choices? I would argue no.
- Do constraints need to be more complicated than limits used for downsampling? Possibly not?
- Should audio/video be optional? Seems like a good idea.

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/669 using your GitHub account

Received on Friday, 20 March 2020 08:45:20 UTC