What does "getSettings" return?

[alvestrand]

In implementing getSettings(width, height), I have been faced with a quandary.
There are 3 width/height pairs to consider:

1. The device native width/height. Given that we do cropping, this is not what we want.
2. The target width/height. This is a bit tricky to calculate, since it's not necessarily a fixed value - it is influenced by the size of the image from the source and the applied constraints, including aspect ratio, and considering that some directions may be unbounded; it's not clear that the answer will make sense if we just look at the target independent of the image from the source.
3. The frame size actually delivered (after cropping). Given the previous point, this may be the easiest value to return consistently - but it leaves us at 0x0 until the first frame arrives.

What do people think "getSettings" should return?

[jan-ivar]

Firefox Developer Edition already implements getSettings and can be seen in action here: https://jsfiddle.net/7udgdbbu/

For width/height it returns the same thing as element.videoWidth and element.videoHeight. This is spec compliant AFAIK.

There's no mention of cropping in the spec, so I consider cropping in Chrome to be a hack, which to be spec compliant, must be considered just another virtual camera resolution.

We believe Firefox implements getUserMedia to the spec, as a discovery API. There's an inherent conflict when you add rescaling of any sort: If you get exactly what you want then you've discovered nothing. (One can play tricks with min/max, but in general this is true).

So Firefox does not support cropping. It doesn't even support rescaling, though we are feeling the pressure to implement rescaling at least, in https://bugzil.la/1286945 , as privacy properties are better and surprises fewer with concurrent gUM access (less discovery == more privacy).

[jan-ivar]

but it leaves us at 0x0 until the first frame arrives.

When is cropping not deterministic?

[jan-ivar]

getSettings(width, height)

getSettings takes no arguments I believe.

[alvestrand]

Replying in reverse order:
I was using getSettings(width, height) as a shorthand for getSettings().then(results) where results.width has value and results.height has value.

Deterministic: If the constraint is "width.max = 640, height.max = 400", and the frame that arrives is 640x480, our current code will crop it to 640x400. If it's 640x320, we will deliver 640x320.
This will probably only be a real issue with sources that can vary in shape and size such as capture windows, but the code path that does the adaptation is the same for both cases.

element.videoWidth / .videoHeight on Chrome returns 0x0 before the first frame arrives; is that also the behavior on Firefox?

[jan-ivar]

The settings from getSettings() are available immediately once the promise resolves. No need to hook up any element. Unsure about element.videoWidth, though that sounds right (needs loadedmetadata event to have fired)

[alvestrand]

The question I wanted to ask was what you show as width from getSettings() before the first frame arrives. Sorry for not being clear.

[jan-ivar]

We show the width as determined by the constraints algorithm, taking all concurrent requests into account (the spec covers this poorly). This is all deterministic, so we don't rely on the first frame at all.

[ShijunS]

We show the width as determined by the constraints algorithm, taking all concurrent requests into account... This is all deterministic, so we don't rely on the first frame at all.

Edge follows the same logic in implementation.

[alvestrand]

There seems to be consensus that getSettings() should return values that correspond to the chosen configuration after getUserMedia() has resolved, and that it's normal for these to remain constant over the lifetime of the track (unless the UA has a reason to change them).

I'll propose some language to say that.

[jan-ivar]

@alvestrand And applyConstraints change them too of course. The existing text mentions the latter, but does not mention getUserMedia at all, which seems like an omission, I agree.

[alvestrand]

Re apply constraints vs The intent of the latest rewrite I remember was to specify "apply constraints" once, and have getUserMedia say "and then you apply the constraints". So this link should have been to "the <dfn>applyConstraints</dfn> algorithm", not to the applyConstraints function. Thanks!