New issue
Advanced search Search tips

Issue 862028 link

Starred by 1 user
Status: Duplicate
Merged: issue 829114
Owner:
chfremer@chromium.org
Closed: Jul 17
Cc:
guidou@chromium.org
niklase@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression



Sign in to add a comment

WebRTC getUserMedia facingMode 'environment' constraint stopped working

Reported by goo...@awe.media, Jul 10 
Steps to reproduce the problem:
1. Open a simple gum example that uses the facingMode 'environment' constraint in Chrome 69 on Android - e.g. http://awe.media/static/webrtc.html
2. Give permissions to access your camera
3. See your face staring back at you

What is the expected behavior?
In Chrome 67 and 68 the browser correctly selects the 'environment' (or back) facing camera.

What went wrong?
In Chrome 69 the browser silently falls back to selecting the 'user' (or front) facing camera.

We also tried this with the more explicit exact constraint e.g.

var constraints = {
  video:{ facingMode:{ exact: 'environment' } } 
};

But in this case the browser threw an overConstrained error in the console and didn't return any stream.

Did this work before? Yes 68

Does this work in other browsers? Yes

Chrome version: 69.0.2475.0 (Official Build) dev (32-bit)  Channel: dev
OS Version: 8.1.0
Flash Version: N/A

Let us know if you need any further information.
minimal_webrtc_sample.html
600 bytes View Download

Comment 1 by philipp....@googlemail.com, Jul 10

Components: -Blink>WebRTC Blink>GetUserMedia
do you know the latest version of Chrome 68 (from chrome://version) that still works? This helps with bisecting and identifying the commit that introduces the issue.

Comment 2 by goo...@awe.media, Jul 10 

68.0.3440.40 seems to be the latest version and that works.

Comment 3 by guidou@chromium.org, Jul 10

Labels: Needs-Feedback
I tested with Canary 69.0.3486.0 on several devices with various Android versions (including 8.1.0) and the back camera was correctly selected in all cases.

Can you let us know the device model you were using?
Also, can you try with the latest Chrome Canary?

Comment 4 by guidou@chromium.org, Jul 10

Components: -Blink>GetUserMedia Blink>GetUserMedia>Webcam

Comment 5 by goo...@awe.media, Jul 10 

Yep Chrome Canary (69.0.3486.0) seems fine - so it must just be an issue with Chrome Dev (69.0.2475.0).

Thanks - we'll make sure we test with Canary too from now on.
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 10

Cc: guidou@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by guidou@chromium.org, Jul 10

Status: Verified (was: Unconfirmed)
Good to know that the latest Canary contains a fix. Closing this bug.
Note also that, AFAIK, 69.0.2475.0 does not exist.

Comment 8 by goo...@awe.media, Jul 16 

Gah - this is actually still broken in Chrome Canary on Samsung Galaxy S7 (69.0.3492.0 (Official Build) canary (32-bit) on Android 8.0.0: SM-G930F Build/R16NW).

But does work ok on Google Pixel (first edition) in Chrome Canary (69.0.3492.0 (Official Build) canary (32-bit) on Android 8.1.0: Pixel XL Build/OPM4.171019.021.P1)

Can we re-open this please? Or should I raise a new ticket?

Comment 9 by guidou@chromium.org, Jul 16

Status: Unconfirmed (was: Verified)

Comment 10 by guidou@chromium.org, Jul 16

Owner: guidou@chromium.org
Status: Assigned (was: Unconfirmed)
I am able to reproduce on a Huawei P9. Several other devices work well.
Will take a look.

Comment 11 by guidou@chromium.org, Jul 17

Cc: chfremer@chromium.org
The earliest version with which I have been able to reproduce the bug is Canary 68.0.3410.0, which reproduces flakily on Huawei P9.
The bug reproduces reliably on the same Huawei P9 using the latest Canary.
I have been unable to reproduce the bug on the same device using builds compiled by me.

The changelog between 68.0.3409.0 includes r553992, which removes the hack of using the device label to detect the facingMode, since the facingMode is now set by the video-capture subsystem.

I suspect the bug is that the facingMode is incorrectly set to VIDEO_FACING_NONE sometimes (no idea when, where or why, since the bug is not easy to reproduce). On builds that reproduce the bug reliably, this fiddle
https://jsfiddle.net/guidou/cp4muo90/ suggests that the facingMode is not set correctly, but the device label is set correctly.

A possible mitigation for M69 would be to restore the hack in r553992. 
Note also that there are other issues related to this bug. For example I can reproduce  bug 862055  reliably only when this bug is active. It is possible that  bug 864268  is also related.

chfremer@: WDYT?

Comment 12 by chfremer@chromium.org, Jul 17

Cc: -chfremer@chromium.org
Owner: chfremer@chromium.org
I'll try to repro today and see if I can find out the cause for the facingMode not getting set correctly. I hope we can avoid having to restore the hack in r553992 :-).

Comment 13 by chfremer@chromium.org, Jul 17 

Also not able to reproduce on a local build, but able to reproduce on a Canary 69.0.3493.0.

I have the suspicion that this may be caused by the rollout of the video capture service on Android, which is currently enabled for 50% of Canary/Dev. This would nicely explain why this seems to happen only on Dev/Canary builds, not on local builds, and only sometimes. I will confirm by trying to force the feature off or on using command-line flag --enable-features=MojoVideoCapture or --disable-features=MojoVideoCapture

Comment 14 by chfremer@chromium.org, Jul 17 

Confirmed. The video capture service makes the difference. Probably the facing mode info is somewhere lost in the Mojo IPC. I will prepare a fix.

Comment 15 by chfremer@chromium.org, Jul 17

Mergedinto: 829114
Status: Duplicate (was: Assigned)
Apologies that this has cost everyone time to investigate. It looks like I had discovered this issue in the code a few months back already but then got sidetracked with other tasks.
►

Sign in to add a comment