Filed this related bug on the webctc adapter: https://github.com/webrtc/adapter/issues/828

guido, can you please take a look?

getify@ Thanks for the issue.

Tested this issue on Mac OS 10.13.3 and Windows 10 on the reported version 67.0.3396.62 and the latest Canary 69.0.3452.0 by following the below steps.

1. Launched Chrome and navigated to the link https://webrtc.github.io/samples/src/content/getusermedia/resolution/.
2. Clicked on 'Full HD' and can see the 'getUserMedia: NotFoundError' thrown.
The same behavior is observed on Firefox as well.
Attached is the screen cast for reference.

Request you to check and confirm if this is the issue you are seeing?

Thanks..

Deleted: 850658.mp4 2.4 MB

	850658.mp4 2.4 MB View Download

Comment 4 is expected behavior since the macbook air is limited to 480p.

#4 it seems the error you get in the video is OverConstrainedError (which is expected given the macbook air has a 720p camera), not NotFoundError (which would indicate that no camera is there).

It seems Ravi in Stockholm has hardware where this reproduced in https://github.com/webrtc/samples/issues/955

I would suggest Ravi and Guido figure out what is going wrong on this particular hardware.

@jbrurar I don't think that's true. I am definitely able to access 720p camera resolution (1280x720) on both Chrome and Firefox on my 2015 macbook air.

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

Here's my screencast showing the misbehaving "Full HD" (ends up giving a 2x2 blank black video, not the 1920x1080 video as expected) on my 2015 macbook air with OSX El Capitan. As you can see, it has no trouble accessing the 720p camera resolution, and it properly throws the constraints error for 4k. It's just 1080p where I get this buggy in-between behavior.

Deleted: webrtc-issue.mp4 6.8 MB

	webrtc-issue.mp4 6.8 MB View Download

@get... thanks for the clarification, I got second hand info.

Regardless, that is still too low for the "Full HD" button [1] though, so comment 4 is still expected behavior.

[1] https://github.com/webrtc/samples/blob/6860281f43b1d01d6e6f065e92ebad9361f494de/src/content/getusermedia/resolution/js/main.js#L70

@get... Thanks for the info. Could you do me a favor and test the same thing in Firefox? That might help to see where in the stack the problem is.

@jbrurar, yes I'm aware that the macbook air doesn't support "Full HD". What I expect is a constraints error (as shown in #4) in that case, but as you see in my screencap in #9), I don't get one.

I will test Firefox in a bit... for now, perhaps this may shed some light? I dunno what "WebPluginVirtualCamera" is, but my guess is it came from google hangouts, as that's the only other WebRTC'ish thing I do. Since it reports supporting 1920x1080, maybe that's the problem here?

Deleted: media-internals.png 46.1 KB

	media-internals.png 46.1 KB View Download

In Firefox 62, if I try "Full HD", it opens a permissions prompt and only lists that "WebPluginVirtualCamera". If I try that feed, I get a blank video (not the black 2x2, but just totally blank).

If I instead try "HD", Firefox asks me to pick either my webcam or this plugin. So, it appears that Firefox filters that list of devices based on the constraints provided?

It seems like maybe the presence of this plugin is the culprit, in that it's advertising itself as supporting 1920x1080, but not actually able to feed any video to that resolution. So both Chrome and Firefox are taking it at its word and being fooled. It's slightly strange to me that they have different failures (one 2x2 black, the other just nothing), but it seems like both are choking on trying to use this plugin and being unable to.

I also can't figure out how to uninstall this plugin. I never authorized it (unless it came from Google Hangouts). The google search results for it seem to point to an app called Vidyo, which I also don't recognize/recall ever installing, and which is not currently installed (as far as I can tell).

As discussed in the github thread, this is working as intended.
The issue is that the WebPluginVirtualCamera is faulty, but is selected based on the capabilities it advertises and the given constraints. Since the device is faulty it does not produce any frame.
The 2x2 frame is played by the video element after the track, which did not produce any frame, is closed.