Closed Bug 1213524 Opened 9 years ago Closed 3 years ago

Implement MediaStreamTrack::onoverconstrained

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Product:
Core
Component:
WebRTC: Audio/Video
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox44 --- affected
Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: jib, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dev-doc-needed)

The only thing I can think of that would fire this is frameRate dipping (e.g. in low light).
backlog: --- → webrtc/webaudio+
Rank: 21
Priority: -- → P2
A potential complication here is that lighting conditions can affect effective frameRate, which I think isn't knowable ahead of time. If implemented like any other constraint, I think this can lead to a situation where a mandatory constraint like frameRate: { min: 60 } on getUserMedia might succeed with a stream from a camera, only to immediately mute and fire an overconstrained event when the effective frameRate turns out to be lower because of low light. This might surprise some web developers, but is probably the most deterministic behavior. I can't think what would be better. I don't think anyone would expect browsers to turn on each camera for a second to learn the effective frameRate in the current lighting conditions.
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

Removed from the spec.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.