Can you provide more details, like device model and so on?
With the information given, this is not reproducible and not actionable.

Thanks for your email.

Please see attached screenshot of the mobile device with details of device.

Regards,
Vipin

Thank you for providing more feedback. Adding requester "guidou@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Please attach the screenshot directly in the bug  http://crbug.com/756831 .

Attached

Deleted: Screenshot_2017-08-21-16-36-03-883_com.android.settings.png 89.1 KB

	Screenshot_2017-08-21-16-36-03-883_com.android.settings.png 89.1 KB View Download

Thank you for providing more feedback. Adding requester "guidou@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I can reproduce the problem on a Redmi Note 3.
Also tested on other Xiaomi models and it does not reproduce.
Will look into it.

I can reproduce the problem in Chrome stable (60) and Dev (62.0.3185.0), but not in Beta (61.0.3163.51).
So, apparently the issue was inadvertently fixed in 61 and regressed in 62.

I bisected and it starts failing at r493950.
This is the CL that allows listing all supported formats.
Perhaps the device advertises a mode that it does not actually support?
Assigning to chfremer@, who owns this part of the code.

chfremer@: if you can't reproduce and need any help, please let me know.

I believe the problem is that newer Chrome versions include 480x640 modes in the list of supported modes and the device does not actually support it. Before r493950, chrome://media-internals did not report any 480x640 mode for this device.

In this case, the constraints algorithm is by default choosing 480x640 over 640x480 because both are equally good for the constraints algorithm since they have the same area and 480x640 is listed first.

I can produce a patch that prefers 640x480 over 480x640 by default and the bug will be significantly mitigated. getUserMedia will still fail if the application explicitly requests 480x640 or any other misreported mode.

Note that with the current Canary, if any supported mode is requested via constraints, gUM does not fail on this device.

chfremer@: If you think this patch to the constraints algorithm is the way to go, please reassign the bug to me. OTOH, if you think there is a bug in the new code for listing supported modes and you can fix it, go for it.

I find it odd that r493950 is causing this trouble on an Android device since that patch looks largely Windows specific.

re #10: Yes, r493950 is largely Windows specific, but one part of it affects all platforms. There is a "filtering" mechanism that "thins out" the formats reported by the platform-specific implementations. Before r493950 this used to treat resolutions with the same area as equal and would discard duplicates. It probably used to be the case that 640x480 (out of pure luck) was listed before 480X640, and therefore 480x640 got discarded. After r493950 we control the ordering more explicitly, moving resolutions with lower width before ones with higher width, and also we no longer treat resolutions with the same area as duplicate.

From what you report it really seems like the device reports 480x640 as supported but fails when we try to open that. Since portrait formats are more common, a possible fix could be to change the ordering such that resolutions with higher width are listed first. If you agree that this is a reasonable solution, I can go ahead and create a CL for that.

Or maybe, since you have a Redmi Note 3 for testing and I currently don't, could you try to flip the "<" to ">" in https://cs.chromium.org/chromium/src/media/capture/video/video_capture_system_impl.cc?l=24 and see if this mitigates the issue?

Besides fixing the regression for M62, we still need investigate why things are not working on M60 stable.

guidou@: Could you take a look at that?

chfremer@: flipping "<" to ">" works.

The flip trick should be enough to mitigate the issue for the vast majority of cases.
I will look at the issue with M60 tomorrow, although we can't fix that one anymore.

Thanks Guido!
I can create a CL for the change (unless you already created one, then we can use that) and send it out for review.

I tracked the fix from M60 to M61 to r478517, which is a switch from GCC to Clang. I have no idea why the compiler change fixed this particular issue. 

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

commit 1a113d423eecfcdf82a5354be090bdee22efb408
Author: Guido Urdaneta <guidou@chromium.org>
Date: Wed Aug 23 16:15:16 2017

Update ordering of reported video modes in VideoCaptureSystemImpl.

The new ordering gives preference to landscape modes over portrait
modes. This also fixes a bug in some devices that report support
for 480x640 but fail when opened with that mode.
This change ensures that 640x480 takes precedence, given that both
have the same area.

Bug:  756831 
Change-Id: I83ee454211d2eb5d50c785cb12e522a2f933032a
Reviewed-on: https://chromium-review.googlesource.com/628256
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496700}
[modify] https://crrev.com/1a113d423eecfcdf82a5354be090bdee22efb408/media/capture/video/video_capture_system_impl.cc

CLosing as fixed. I will land a minor fix to the constraints algorithm as well, but r496700 is enough to address this issue.

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

commit 1aa2006fca6be7ca091e5b2320265e887ed7d730
Author: Guido Urdaneta <guidou@chromium.org>
Date: Fri Aug 25 14:39:25 2017

Update constraints algorithm for video device capture.

The new algorithm replaces resolution area with Euclidean distance to
default resolution. The reason is that, in practice, the expected
default resolution is 640x480, but under the old criteria 480x640 is
equally good and might be selected depending on the order in which they
appear. To make matters worse, some devices that report support for
480x640 fail to open when that resolution is requested.

Bug:  756831 
Change-Id: I4cac68d5661cb8b3f30a2d523e3083c98fb86241
Reviewed-on: https://chromium-review.googlesource.com/628536
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497403}
[modify] https://crrev.com/1aa2006fca6be7ca091e5b2320265e887ed7d730/content/renderer/media/media_stream_constraints_util_video_device.cc
[modify] https://crrev.com/1aa2006fca6be7ca091e5b2320265e887ed7d730/content/renderer/media/media_stream_constraints_util_video_device_unittest.cc