640x480 (or the resolution closest to it) has historically been the default in Chrome, but there is nothing in the spec preventing a different default strategy.

cc'ing some people from the community who might have an opinion about this. Please cc more people who might be affected by a change here.

"highest resolution video stream the system could smoothly stream" is a very hard thing to estimate.

Constraints as shown on https://webrtc.github.io/samples/src/content/getusermedia/resolution/ allow developers to ask for higher resolution with a fallback easily so i don't think it is necessary to change the default.

In Android in particular there's a Key that might be helpful:

  preferred-preview-size-for-video=1920x1080;

See this doc where I gathered printouts of the capabilities for
some smartphones: https://goo.gl/WthsVe t

this happens also when specifying manually the constraints.
If I set minWidth: 0 and maxWidth: 1280, I expect chrome to take the max.
To be able to take 1280x720 as default without making multiple calls to getusermedia in case it fails, my only option is to make an array in the "advanced" option:

advanced: [{height: {exact: max}, aspectRatio: {exact: 16/9}}, {height: {max: max}}]

this will try first the EXACT 1280 and if it is not supported it fallbacks to MAX 1280.

But from 59 the order that chrome will try these resolutions changed, so we have to do advanced: advanced.reverse() which is pretty crappy way to manage the different case.

I hope that from chrome 60, de IDEAL constraints will be supported so we might do:
video: {width: {ideal: 1280}}

#4: Chrome 59 supports spec compliant video constraints, including ideal.

So, video: {width: {ideal: 1280}},  which is equivalent to  video: {width : 1280}, will work as expected.

Note that giving min: 0 and max: 1280 and expect to get 1280 is wrong. There is nothing in the spec that says the maximum should be preferred over any other value in the range. If nothing else is given, Chrome will use 640x480 if it is in the requested range.

The question for this bug is whether 640x480 is still a reasonable default.
Based on comment #2, it looks like it is. Especially now that spec-compliant constraints are supported.

yeah, but setting width: 1280 on chrome prior to 59 will result in a stream 640x480 (at least on macbook pro 2011/2012)

"Based on comment #2, it looks like it is. Especially now that spec-compliant constraints are supported." completely agree

have a nice day!

#6: I interpret your comment as support for keeping 640x480 as default in new versions since things like width:1280 will work as expected.
There is nothing we can do to change defaults for older versions where that kind of input results in the unexpected default output.

So, should we close as WontFix based on #7?