New issue
Advanced search Search tips

Issue 718826 link

Starred by 1 user
Status: Fixed
Owner:
guidou@chromium.org
Closed: May 2017
Cc:
guidou@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment

getUserMedia: Receiving wrong video stream when having multiple cameras and asking for higher resolution than supported

Reported by adr...@heftlab.com, May 5 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36

Steps to reproduce the problem:
1. Have two cameras connected (e.g. FaceTime and Logitech)
2. Go to https://webrtchacks.github.io/WebRTC-Camera-Resolution/
3. Select lower resolution camera (in my case: FaceTime)
4. Press "Quick Scan"

What is the expected behavior?
FaceTime camera should only support 1280x720 and down.
getUserMedia for FaceTime camera and 1080p constraints should return "ConstraintNotSatisfiedError".

What went wrong?
Chrome m58 reports that FaceTime supports 1920x1080.
When trying getUserMedia with FaceTime id and 1920x1080 we receive the other camera's stream.

Camera ids:
HD Pro Webcam C920: db9f094e0f9b46be518f0ade12916aa195df9b82b97be2510e6f8a5f50192f16
FaceTime HD Camera: 5b9874d6752884976d83c9895f7b2f68e37886e527f1303a354276adf9b85d7b

JS call: 
getUserMedia({"audio":false,"video":{"mandatory":{"sourceId":"5b9874d6752884976d83c9895f7b2f68e37886e527f1303a354276adf9b85d7b","minWidth":1920,"maxWidth":1920,"minHeight":1080,"maxHeight":1080}}})
.then((stream) => { localVideo.srcObject = stream; //this is the Logitech stream, even though we've asked for the FaceTime stream});

For getUserMedia calls with correct video resolutions for the FaceTime camera (e.g. 1280x720 and lower), the correct stream is provided in the promise.

Does not happen on m57.

Did this work before? Yes 57

Does this work in other browsers? Yes

Chrome version: 58.0.3029.96  Channel: stable
OS Version: OS X 10.12.4
Flash Version:

Comment 1 by guidou@chromium.org, May 6 2017

Components: -Blink>WebRTC Blink>GetUserMedia
Labels: Needs-Feedback
Owner: guidou@chromium.org
Status: Assigned (was: Unconfirmed)
Note that neither M57 nor M58 correctly support spec-compliant constraints processing.
that said, this looks like a regression in M58. What result do you get M59?
Also, can you try with the new syntax in both M58 and M59?

{video: {
  deviceId: "5b9874d6752884976d83c9895f7b2f68e37886e527f1303a354276adf9b85d7b",
  width: {exact: 1920}, 
  height: {exact: 1080}
}}

Comment 2 by guidou@chromium.org, May 6 2017

Labels: -Needs-Feedback -OS-Mac OS-All
Status: Fixed (was: Assigned)
I looked at the code for 58 and found the problem.
It is probably too late to fix it in M58, but the issue was fixed in M59, so closing the bug as fixed.
Please reopen the bug if you find that this is still an issue in M59 or later.

Comment 3 by kjellander@chromium.org, May 9 2017

Labels: MissingTests
It seems like it would make a lot of sense to write unit tests to verify this kind of logic. Is that something we can do?

Comment 4 by guidou@chromium.org, May 9 2017

Labels: -MissingTests
We have plenty of unit tests for this. See https://cs.chromium.org/chromium/src/content/renderer/media/media_stream_constraints_util_video_device_unittest.cc

Of course, the search space is infinite (constraints strings and number and configuration of devices can be arbitrarily large), so we cannot test every possible case, but we have a very reasonable coverage.

The problem with this particular bug was that when we were trying to introduce spec-compliant constraints processing in M58, it caused some regressions in large applications such as Hangouts (see  issue 690336 ). The specific problem is that in M57 and older, getUserMedia always asks for permission even if the constraints cannot be satisfied (see  issue 690491 ) and Hangouts and other applications expected this, while the spec says that getUserMedia should fail early if constraints cannot be satisfied.

In order to give more time for applications to adjust to the standard behavior, we patched the initially spec-compliant getUserMedia in M58 so that it doesn't fail early in some cases of constraints failure. Unfortunately, that bug-compatibility patch inadvertently introduced this regression (which occurs only on very particular hardware/constraints combinations) which is rare enough that it didn't surface during the beta period. 

For M59 we reverted the compatibility patch so getUserMedia always fails early if video constraints cannot be satisfied, which is the case in this example. Note that we haven't closed  issue 690491  because we are still working on spec-compliant constraints for audio.

Given these considerations, I don't think we need new tests to cover for this particular already-fixed bug.
►

Sign in to add a comment