Intent to implement and ship: MediaStreamTrack.getSettings()

[Harald Alvestrand]

Contact emails h...@chromium.org Spec https://w3c.github.io/mediacapture-main/getusermedia.html#media-stream-track-interface-definition Summary Returns the current settings of a MediaStreamTrack, including information such as (for video) width, height or framerate. Motivation

This is the best API surface to use to get information about an open media stream where use of stats is not appropriate.

One example of this usage is to query the facing mode of a camera. Interoperability risk Firefox: Shipped (with width, height and framerate) Edge: No public signals Safari: No public signals Web developers: Positive

This has been in the spec for a very long time, and has been in development for a while as part of crbug.com/543997 (the constrainable pattern).

The developers have now had requests to expedite shipping the feature.

Compatibility risk

Low. Since Firefox already ships it, the presence of the API should not break

anything that currently works on Firefox.

There is a risk that shipping the feature without the full set of values from the

specification may cause confusion, but since Firefox is already doing that, the

compatibility risk seems manageable.

Ongoing technical constraints

None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes. OWP launch tracking bug https://crbug.com/681824

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5648690194677760 Requesting approval to ship?

Yes.

[PhistucK]

Please, back up your claims when you mention "Web developers: Positive" (or anything other than Shipped and No public signals, though irrelevant here)...

(I will look into suggesting changes to the template later)

What exactly is shipping, then? What properties are supported? You mentioned width, height and frameRate and then you mentioned facingMode, are those supported? Anything else?

Anything that Firefox supports but Chrome will not support at this stage? And vice versa?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Harald Alvestrand]

1) It was a web developer who asked me to expedite this one. I haven't heard anything negative.

2) I suggest shipping width, height, framerate and facing mode.

3) Firefox supports on audio:

echoCancellation, mozAutoGainControl, MozNoiseSuppression

on video:

frameRate, height, width

This is from a console test on Firefox 50.1.0, which was what my workstation happened to have installed today.

We're not going to support moz-prefixed attributes.

The long term plan is to support all specified attributes when they have values (no width on audio, for instance). I'm asking for approval to ship with width, height, framerate and facing mode.

I'd think that adding new values would be a "minor change"; YMMV.

[PhistucK]

Hey

You sent this directly. Hit "Reply to all" instead to send it to the groups so others could benefit or help.

☆PhistucK

[PhistucK]

Oops. Did GMail just trick me? :O

Thank you for the clarification.

It is so sad that Firefox added more prefixed properties, but I heard that the WebRTC stories of Chrome and Firefox in terms of prefixes is a common one, unfortunately. Hopefully, that will be over soon.

What about echoCancellation, for non-prefixed feature parity with Firefox?

☆PhistucK

[Harald Alvestrand]

It's specified, and it (or something like it) has been asked for. I'll see what I can do.
(At the moment, I'm not sure whether WebRTC offers a way to read out the state of echo cancellation or not. If they do, it's easy; if they don't, it's more plumbing to add. Just business as usual.)

[Boris Zbarsky]

On 1/17/17 11:29 AM, PhistucK wrote:
> It is so sad that Firefox added more prefixed properties

I was a bit surprised by it in this instance, so I made some inquiries.
https://bugzilla.mozilla.org/show_bug.cgi?id=987186#c62 and
https://bugzilla.mozilla.org/show_bug.cgi?id=987186#c63 were the response.

-Boris

[PhistucK]

Huh, I did not know it was a new addition, that makes me more sad. :(

And the responses are unfortunate...

Thank you for looking into this.

☆PhistucK

[Harald Alvestrand]

The current text of the spec wrt constraints:

"Future specifications can extend the MediaTrackConstraintSet dictionary by defining a partial dictionary with dictionary members of appropriate type."

and similar for the other dictionaries.

This consists of the WG making two decisions:

- The current text of this specification won't add more constraints
- Methods for restricting other specs from adding constraints are rather pathetic, so we'd better just admit that new specs can add more constraints, and ask them to tell us if they do.

The text on adding constraints is here:

https://w3c.github.io/mediacapture-main/getusermedia.html#defining-a-new-constrainable-property

So far, nobody's taken us up on the "offer" - I have some hopes for the mediacapture-image spec still.

(The process for getting new specs out the door, even in WICG, seems to be more challenging than I expected - I'm still waiting for someone to use the Discourse to comment on https://discourse.wicg.io/t/proposal-a-frame-level-event-logging-mechanism-for-webrtc/1780 after 3 months of prodding various people to comment on it.)

[Harald Alvestrand]

Ping.... so far, most of the mail on the subject has been about what the extension procedures are for the constraint namespace, which is not a focus of this intent-to-ship.

Is there anything more needed in order to get approval for shipping getSettings?

[Aleksandar Stojiljkovic]

+1 for removing the need for --enable-blink-features=MediaGetSettings.

On Tuesday, January 17, 2017 at 10:44:53 PM UTC+2, Harald Alvestrand wrote:

The current text of the spec wrt constraints:

"Future specifications can extend the MediaTrackConstraintSet dictionary by defining a partial dictionary with dictionary members of appropriate type."

and similar for the other dictionaries.

This consists of the WG making two decisions:

- The current text of this specification won't add more constraints
- Methods for restricting other specs from adding constraints are rather pathetic, so we'd better just admit that new specs can add more constraints, and ask them to tell us if they do.

https://w3c.github.io/mediacapture-depth/#mediatracksettings-dictionary:

depth near, far, camera focal length.

WIP on other camera intrinsics and extrinsics:

https://github.com/w3c/mediacapture-depth/pull/144

[TAMURA, Kent]

LGTM1.  I agree that the risk is low.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

LGTM2

I've taken a look at Blink's IDL and it does line up with the spec, which includes more than what MediaStreamTrack::getSettings can set, which is frameRate, width, height, deviceId and facingMode. (deviceId wasn't mentioned upthread, but I guess it works?)

Can you trim MediaTrackSettings.idl to just the bits will be supported?  It won't change anything because any dictionary members that aren't set will not be copied over to the JS object, but would be clearer I think. WDYT? 

[Jochen Eisinger]

lgtm3

[Harald Alvestrand]

I can trim it to the implemented ones, with a comment pointing to this bug for implementing the remainder. Does that make sense?

More IDL churn, less chance of somoene reading the code and thinking we support the ones we don't.

[Philip Jägenstedt]

Thanks, that would be great, I think that extra bit of churn is worth it in this case. (This way tooling and humans can see easily that e.g. echoCancellation is not supported yet.)