At least the way Chrome is implemented, you would never reconfigure a camera such that existing tracks become overconstrained.

That's spec mandated and true in other browsers as well. applyConstraints is first-come first-served.

TL;DR: I see no practical uses of the overconstrained event, locally or remotely. I suspect it's there to complete a general pattern. I'd rather remove it than look for uses for it, as I prefer use-cases driving design over symmetry.

• It's redundant: just measure the output directly and react to it.
• It's undesired: demand has not materialized in 5 years.

The given rationale for overconstrained is physical manipulation of the camera or environment. 11.1: "For example, the user might physically manipulate a camera in a way that makes it impossible to provide a resolution or frameRate that satisfies the constraints". - a hypothetical fillLightMode in "The model".

A low-interest example mentions: "Note that the frameRate minimum might be within the capabilities of the camera and satisfiable in ideal lighting conditions, but not in low light, and could therefore result in firing of the onoverconstrained event handler under poor lighting conditions."

Why do we have overconstrained if not for remote tracks?

Circular reasoning. They may both be useless. They don't validate each other. 😉

Circular reasoning. They may both be useless. They don't validate each other. 😉

That's part of my point, I'm questioning everything now. Overconstraining for a remote track doesn't make much sense to me because it doesn't just inform you that conditions are not met, it mutes the track (which has a different meaning for WebRTC's remote tracks). But I couldn't think of a how it would overconstrain if not for remote tracks. Given your frameRate example, I guess this makes "more" sense when capturing, but again why would you want to mute the track? Probably as to not spam the application with overconstrained events, but it makes overconstrained mean not just "FYI, diagnostics", but "hey, something is WRONG, and you need to do something about it, this track is now silenced".

I think it's up to the application whether or not to mute the track, otherwise this is a foot-gun.

• It's redundant: just measure the output directly and react to it.

If this is true I suggest we remove overconstrained event. @guidou

The benefit of overconstrained over "just measure the output directly and react to it" is 1) you don't have to poll frequently, the browser would allow you to react on the very frame that overconstrained it, 2) you don't have to implement application logic for diagnosing whether or not a track is constrained and 3) it reuses the same logic and algorithms that was used to configure the track.

Perhaps overconstrained should still exist but it should never mute the track, just set a "bool overconstrained" attribute. Applications that care can react, applications that don't won't. Otherwise you're forced not to use "min" and "max" when selecting your configuration/device or else you risk your track randomly getting muted, which would implicitly advice you to only use ideals.

Proposal A

In order of importance, but 2. and 3. are up for discussion.

1. Don't mute a track that gets overconstrained, it makes it a foot-gun and it contradicts the definition of being muted means: "live samples are not made available to the MediaStreamTrack".
2. Add a boolean overconstrained attribute to indicate whether or not it is currently overconstrained.
3. Add an onunoverconstrained event.

Proposal B

1. Remove overconstrained event. Let the application implement "is overconstrained" logic if it cares about this.

@armax00 @jan-ivar @guidou

I'd vote for B. Firefox never implemented it, and no-one has asked us for it.

I think it's up to the application whether or not to mute the track, otherwise this is a foot-gun.

Agree. I think it's a web compat issue at this point: if implemented literally, any application already using {frameRate: {min: 60}} today and not listening to the overconstrained event, would suddenly have its track muted in low light.

I claim no-one wants that. If the expectation is the application immediately corrects the overconstrained situation, then nothing seems lost by leaving the track unmuted. So 👍 for A.1.

Today's spec behavior would be trivial to polyfill for apps that truly want it:

track.onoverconstrained = () => track.enabled = false;

The opposite not so much without incurring a flicker.

There are cases where an event such as overconstrained might be useful, for example if the device firmware is malfunctioning; it could also be that the application developer has the intent to avoid wasting battery, wasting resources, or wants to guarantee certain behavior. Which means, that at least for local devices such an event might be useful, but I do not know how big a difference it would be between polling for stats to measure the state of the stream and throwing and event such as this.

I agree that the muting part is a great foot-gun and should not be implemented.

We can discuss proposal A vs propsal B at the interim.

I agree with @jan-ivar and would vote for B.
Option A requires a comprehensive list of use cases to properly design things, maybe it should be in scope of WebRTC NV.

I can see some usecases.

For local tracks, a browser might be able to support capture of two cameras at the same time, but not three. If one website is already capturing with 1 cameras, a second website might be able to do getUserMedia for 1 camera but not 2. It is unclear what kind of information should be given to the application so that it can take appropriate measures, whether the current OverconstrainedError is a good fit there, what the privacy implications are...

For remote tracks, I can see a case where a user agent may hit a decoder slot limitation, which is a resource shared amongst different applications. In this particular case, the straightforward option would be to have something on receiver side, not on the track. Again, not sure which kind of information should be given to the application.

Chrome is also happy to not implement this.

Since onoverconstrained has not been implemented, it probably should have been labelled as "at risk". I would agree that it makes little sense to mute the track, particularly if the track is remote.

While I can think of use cases where an event might be useful (e.g. for regulatory compliance with respect to signing support, being able to require a minimum framerate), the lack of developer requests speaks volumes.

As an app developer, it is critical that the browser let me know if something has changed such that is not longer meeting required constraints. Now if there is an argument there is no way for that to ever happen, great, but I don't believe that is true - particularly across mobile devices.

We haven't come across a case where this can happen today, which leaves us with nothing to implement and test. Without such an implementation, how can we keep it in the spec?

Seems like the rules for going to PR "encourage" us to remove it.
It seems more attractive to try to address the use case by an extension spec if we can figure out a case where it is really necessary to adddress it.

On the can not happen .... What about you have set a min frame rate of 30 and the camera decides to move it to 25 ? Am I missing something about how that can not happen today ?

@fluffy Yes you are right that this can happen, but I think we are trying to use constraints for different problems/use cases at the same time.

"Did I get what I asked for?" is actual two questions.

1. Is the track constrained the way I asked it? This means, is it configured with settings that are compatible with my constraints. I.e. it is configured with the right resolution? Is it configured to produce the framrate I asked for?
2. Is the source able to produce what it is configured to produce?

Note that 1) is the only thing that browser/constraints processing and thus application has any control over. And the answer to 1) is always Yes. The answer to 2) is probably always yes except for things like framerate, which could drop due to lighting conditions, CPU usage, etc.

Let's not confuse constraints processing and device configurations with device/network diagnostics. The source could be local, or remote, whatever. Conditions may vary, frames may drop, this is separate from whether or not things are configured properly. They are configured correctly, so "overconstrained" is misleading, and often times not actionable. Add to the fact that as defined it also mutes your track it's a total foot-gun, though that could be amended without removing it altogether.

A drop in framerate would have you ask "was it temporary? was it continuous?". How long do you wait until you give up on the device? This is totally use case and application-specific. Simplifying this problem to "am I overconstrained or not?" (forget "how/why am I overconstrained?") I would argue is not in anybody's best interest if alternatives are considered.

I don't think fixing this or considering alternatives should block "1.0". If need for something like this manifests itself stronger it would be better served addressed separately.

Uh, the point of all this has been since the very beginning for mandatory constraints to give an error if the system was not meeting the constraints for whatever reason.

Uh, the point of all this has been since the very beginning for mandatory constraints to give an error if the system was not meeting the constraints for whatever reason.

For getUserMedia/applyConstraints, you will get an error at the time you are setting the values.
If applyConstraints fails, you will still be able to continue the capture.
I do not think we would like a failing appplyConstraints to mean that the track gets ended.

I agree with the desire from a web developer to be notified of such kind of changes (and hopefully have ways to react upon them). Let's gather use cases and look at the best ways to address them.
This seems like something that could be done incrementally on top of WebRTC 1.0.

Remove "onoverconstrained" re-upload #579