MediaDevices.getUserMedia() add constraints

[hamishwillee]

FF144 added a new constraint parameter resizeMode for use with MediaDevices.getUserMedia().

We haven't documented the constraints before so this attempts to do so as there are other compat differences.
The results are based on the test https://wpt.live/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html, and more specifically, by bisecting based on the wpt results using product tests like:

• Chrome: https://wpt.fyi/results/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html?label=master&product=chrome-80&aligned
• Firefox https://wpt.fyi/results/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html?label=master&product=firefox-115&aligned
• Safari https://wpt.fyi/results/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html?label=master&product=safari-12&aligned

The tests and results do not run on the earliest version that constraints should be supported for, so I have used ≤ to indicate the earliest version I could test in each case.

Note that there are some constraints I have not documented:

• backgroundBlur is in spec but not in tests. Assuming it is not implemented though it might be.
• volume is not in spec, but shows up in some very old builds. Ignoring.
• voiceIsolation is supported by Chrome but is not in spec. Ignoring.

Note that there a related test https://wpt.live/mediacapture-streams/MediaDevices-getUserMedia.https.html but everything passes in this for things that support the associated constraint, so this does not lead to any compatibility difference to record.

Related docs work can be tracked in mdn/content#41132

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

I'm wondering:

1. Would it be better to document this under getSupportedConstraints()?
2. Should we link to the individual MediaTrackConstraints pages (e.g. autoGainControl)?
3. Could we make it clearer that the constraints go inside the audio/video options?

For (3), I could imagine this structure instead:

api.MediaDevices.constraints_parameter.aspectRatio_constraint

[hamishwillee]

@caugner Thanks for the review

1. Would it be better to document this under MediaDevices.getSupportedConstraints()?

@caugner Yes, as that what we're actually testing. I have moved the features.

2. Should we link to the individual MediaTrackConstraints pages (e.g. autoGainControl)?

Yes. I thought the infrastructure did that automatically - but this is done now.

3. Could we make it clearer that the constraints go inside the audio/video options?
   I could imagine this structure instead:

api.MediaDevices.constraints_parameter.aspectRatio_constraint ``

This I am not so sure about. Firstly, after moving these to getSupportedConstraints it is a return value. Secondly, isn't it usual to document the features in a flat structure.

Upshot, if you tell me to do this I will as you know the rules better than me.

Thoughts?

[hamishwillee]

@caugner I originally did this under MediaDevices.getUserMedia() because the documentation work I'm looking at is for resizeMode on that method.

So I'd quite like to record at least this particular constraint on this method. I've done that here but its a TBD because I am assuming that the other browsers match the data in the getUserConstraints method.
Or do you think I should make that assumption and duplicate everything here, or do something else.

Note, also pending your response on whether you want this all under a sub feature for the constraint parameter.