Further debugging indicates that the issue is frameRate.min being specified at all. I can only get Android front camera in a getUserMedia() request if I completely remove frameRate.min as a constraint.

Would be best to edit the title of this bug to "OverconstrainedError on Android front cameras when frameRate.min is specified"

thehunmonkgroup@: Do you get this problem with all Android devices or with a specific device?

If you get OverconstrainedError it is possible that the your back camera does not support 15fps, or that it does not support it after having opened the front camera.

I tried with a device and got a NotReadableError for the second stream instead instead of an OverconstrainedError, which means that the second track could not start, possibly due to hardware issues. I got this error even without specifying a min frameRate or any other constraint different from deviceId.

Can you try https://jsfiddle.net/guidou/z0qx48o2/ 

This fiddle calls getUserMedia without a frameRate constraint, but reports the frame rate for all the obtained tracks. If you get less than 15fps for the back camera that would explain why you get an OverconstrainedError.

My primary testing device is a Samsung Galaxy S7, which historically has accepted the frameRate code I showed without error until this bug appeared. I've also tested it with a few other Samsung devices and also gotten this error. I can run a few more tests across other Android devices and report back results.

Here are the results of running the jsfiddle on my S7, looks like the frame rate on both cameras is within the constraint range:

1. Using video device: camera2 1, facing front(3cc77f50cc66718b3c6128d01d797acb2a10bfa9bbe832786605aa369e0acc5c)
2. Frame-rate Range for device is [1, 60]
3. Using video device: camera2 0, facing back(9c1312bf14eca65ad641ba408bb134a1f1eb8818754ffbb8986e0f199049730a)
4. Frame-rate Range for device is [1, 60]
5. Got stream for device camera2 1, facing front, frameRate is 0, deviceId = 3cc77f50cc66718b3c6128d01d797acb2a10bfa9bbe832786605aa369e0acc5c
6. Could not get stream for device camera2 0, facing backNotReadableError: Could not start video source

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

OK, so it's the same error I'm getting. I'll take a closer look.

The NotReadableError issue is not a bug. The problem is that both jsfiddles (both https://jsfiddle.net/t1hurqm0 and https://jsfiddle.net/guidou/z0qx48o2/) are trying to get video streams from both cameras at the same time, since stop() is called after both getUserMedia calls. Many phones are not able to use both cameras at the same time due to internal bandwidth limitations, hence the NotReadableError.

thehunmonkgroup@: Can you try https://jsfiddle.net/guidou/4qsjw923/, which uses facingMode to force the back camera and requests a minimum frameRate of 15. It works fine for me on a couple of devices where I tried it.

@guidou, I don't think those gUM errors are caused by camera contention, but instead a bug with trying to do this on jsfiddle. When I print the caught error for the failed gUM to console, I get this:

err = ReferenceError: info is not defined at https://fiddle.jshell.net/thehunmonkgroup/ekbqhsg2/20/show/:58:13

So instead, here's a more focused test case on one of my servers:

https://staging-connect.circleanywhere.com/public/frame-rate-fail.html
https://staging-connect.circleanywhere.com/public/frame-rate-success.html

This test only asks for the front camera, so no camera contention issues.

Here's the diff between those two files:

--- frame-rate-fail.html	2018-07-12 12:26:37.993250516 -0500
+++ frame-rate-success.html	2018-07-12 12:26:53.937397157 -0500
@@ -26,9 +26,9 @@
                 exact: device.deviceId,
               },
               frameRate: {
-                // Front camera fails on Android devices when min is set.
+                // Front camera succeeds on Android devices when min is not set.
                 ideal: 15,
-                min: 15,
+                //min: 15,
                 max: 30,
               }
             },

I tested both cases on three devices, Samsung Galaxy S7, Samsung Galaxy S9, HTC One. The problem occurred on both Samsung devices, but not on the HTC One (which is 5 years old at this point). Also a reminder that the S7 already indicated it could support a frame rate of 15, so it's not failing for that reason. Something is going on here... ;)

I was able to reproduce the issue on a Samsung Galaxy S6. Looking into it.

The bug is because the phone reports that it only supports 0fps on the front camera. You can see this in chrome://media-internals.

So, the device reporting 0fps is probably a device bug, but we can work around it using a fallback frame rate.

There is another bug in the capabilities reported by InputDeviceInfo.getCapabilities() which will be handled separately. This is the reason [1,60], which is incorrect for this phone, is reported.

@guiduo, any idea why this used to not throw a constraints error until recently?

Can you cross link the InputDeviceInfo.getCapabilities() here?

 Bug 863426  tracks the getCapabilities bug.

thehunmonkgroup@: Do you know a Chrome version where this worked correctly?
I don't think this could have worked in versions that support the frameRate constraint on these phones.

Unless the 0fps is a recently introduced Chrome bug and not a device bug.
In this case it would be good to know a version where this worked.

@guiduo, I can't remember accurately when it stopped working, but it definitely did work before.

Is there any easy way to access old Chrome versions (similar to the channels)? If so I could probably do a bisect-y thing to figure out when it broke.

I'll try to bisect this issue next week to see if this is a Chrome regression.
Anyway, we have seen devices reporting incorrect formats in the past, so I'll prepare a patch to replace zero frame rates, which are invalid, with a fallback frame rate.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5f2f53511ff7caca516d4565faac10ec001dace1

commit 5f2f53511ff7caca516d4565faac10ec001dace1
Author: Guido Urdaneta <guidou@chromium.org>
Date: Fri Jul 13 22:33:18 2018

Use fallback frame rate in MediaDevicesManager::GetVideoInputFormats()

Some devices report zero frame rates in their supported video formats
and this makes getUserMedia() fail if frame-rate constraints are used.

This CL replaces zero frame rates with a fallback frame rate to work
around this issue.

Bug:  862325 
Change-Id: If7e844856d9652480ed6bca607037dc0a4b9b7c4
Reviewed-on: https://chromium-review.googlesource.com/1136642
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575096}
[modify] https://crrev.com/5f2f53511ff7caca516d4565faac10ec001dace1/content/browser/renderer_host/media/media_devices_manager.cc
[modify] https://crrev.com/5f2f53511ff7caca516d4565faac10ec001dace1/content/browser/renderer_host/media/media_devices_manager.h

I did report the issue to the manufacturer:

https://developer.samsung.com/forum/board/thread/view.do?boardName=SDK&messageId=353199

From my little bit of research, I'm not overly optimistic they'll do anything with that...

I was able to do a bisect and before r527699 no formats were reported, so fallback formats were used.
After r527699 a fix to how frame rates were computed was introduced and formats started to be reported. However, for some phones the reported frame rate is zero.
Assigning the bug to chfremer@ in order to double check that r527699 is indeed correct. If it is, the fallback frame rate introduced in r575096 should be enough and we should close this bug.

Yes, before r527699, capture formats were reported as PIXEL_FORMAT_UNKNOWN, which then probably got filtered out somewhere on the way to the constraint handling logic.

It looks like frame rate gets reported as 0 in case the code fails to obtain the actual frame rate, see [1].

With that I believe r575096 should be an effective fix.

[1] https://cs.chromium.org/chromium/src/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java?l=691

Curious what versions this fix will be included in? Will 68/69 get it? If so, when?

The fix has first landed in 69.0.3491.0, which I believe is supposed to hit the Beta Channel sometime soon.

I don't currently think the issue is severe enough to be likely to get approved for a merge in to M68.