Bug 1537986 Comment 37 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to guest271314 from comment #36)
> both links to Media Capture and Stream specification https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack which means that "unless otherwise stated" at Media Stream Recording directly incorporates by reference `MediaStreamTrack` at Media Capture and Streams. thus `getSettings()` should return the relevant constraints of a `MediaStreamTrack` when `captureStream()` is executed to get the `MediaStreamTrack`.

"unless otherwise stated" is not a quote from anywhere I can find. Yes, those specifications normatively say the `getSettings()` method must be implemented for tracks of those sources, but do not say to return anything, or to implement any constrainable properties for those sources.

This used to be under-specified, but got the stronger mediacapture-main language recently, because implementers need specific instructions on how to implement constraints for a specific source, since it's not always obvious how to do so. That's why mediacapture-main now admonishes each spec to spell out not only the constraints an implementer is required to support, but also *how* they must work.

There are many examples of constraints unique to a source (e.g. `facingMode`), and even where there's overlap (e.g. `width`) there can be subtle differences (screen capture tracks, for instance, [must not crop](https://w3c.github.io/mediacapture-screen-share/#downscaling-and-frame-decimation) because that might lose important info and/or window borders and look bad, whereas camera tracks were (and still are) allowed to crop to create mock 16:9 out of 4:3 etc. Also `resizeMode` isn't `"none"` on retina displays.)

Another example is remote peer connection tracks, where there's questions around whether lowering `width` should impact the network congestion algorithm, or whether `resizeMode = "none"` would guarantee the dimensions sent by the other peer (probably not, because that's quite literally "action at a distance"). So right now constraints on remote tracks might be left to an extension spec, even though Chrome has some support.
(In reply to guest271314 from comment #36)
> both links to Media Capture and Stream specification https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack which means that "unless otherwise stated" at Media Stream Recording directly incorporates by reference `MediaStreamTrack` at Media Capture and Streams. thus `getSettings()` should return the relevant constraints of a `MediaStreamTrack` when `captureStream()` is executed to get the `MediaStreamTrack`.

"unless otherwise stated" is not a quote from anywhere I can find. Yes, those specifications normatively say the `getSettings()` method must be implemented for tracks of those sources, but do not say to return anything, or to implement any constrainable properties for those sources.

This used to be under-specified, but got the stronger mediacapture-main language recently, because implementers need specific instructions on how to implement constraints for a specific source, since it's not always obvious how to do so. That's why mediacapture-main now admonishes each spec to spell out not only the constraints an implementer is required to support, but also *how* they must work.

There are many examples of constraints unique to a source (e.g. `facingMode`), and even where there's overlap (e.g. `width`) there can be subtle differences (screen capture tracks, for instance, [must not crop](https://w3c.github.io/mediacapture-screen-share/#downscaling-and-frame-decimation) because that might lose important info and/or window borders and look bad, whereas camera tracks were (and still are) allowed to crop to create mock 16:9 out of 4:3 etc. Also `resizeMode` isn't `"none"` on retina displays.)

Another example is remote peer connection tracks, where there's questions around whether lowering `width` should impact the network congestion algorithm, or whether `resizeMode = "none"` would guarantee the dimensions sent by the other peer (probably not, because that's quite literally [action at a distance](https://en.wikipedia.org/wiki/Action_at_a_distance_%28computer_programming%29)). So right now constraints on remote tracks might be left to an extension spec, even though Chrome has some support.

Back to Bug 1537986 Comment 37