WPT mediacapture-streams/GUM-invalid-facing-mode.https.html fails
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
()
Details
Attachments
(1 file)
This is because the fake video device ignores all constraints except deviceId.
It seems ok to ignore the range ones, like width, height and frameRate, but right now for facingMode this accepts all sorts of values.
|
Assignee | |
Comment 1•5 years ago
|
||
This does two things:
It makes MediaEngineDefaultVideo::GetBestFitnessDistance include a facingMode
check.
It also makes FitnessDistance() for StringRanges take a Maybe<nsString>, since
the device might not have a value for all StringRange constraints, as is the
case for facingMode. This fixes this issue for a MediaEngineRemoteVideoSource
with no facingMode, since such a device would match a facingMode of the empty
string prior to this patch.
To be fully spec compliant, the Maybe should be a set instead, since a device
may support multiple values for the facingMode capability. We don't support
more than one value however, so this change can be made later as needed.
Pushed by pehrsons@gmail.com: https://hg.mozilla.org/integration/autoland/rev/324c7b90a7cc Check facingMode constraint in MediaEngineDefaultVideo and don't match empty string by default. r=jib
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•