Some outputs:

lsmod | grep facetime

facetimehd             98304  0
videobuf2_dma_sg       20480  1 facetimehd
videobuf2_v4l2         28672  1 facetimehd
videobuf2_core         36864  2 facetimehd,videobuf2_v4l2
videodev              176128  4 v4l2_common,facetimehd,videobuf2_core,videobuf2_v4l2

dmesg | grep facetime

[    4.702915] facetimehd: module verification failed: signature and/or required key missing - tainting kernel
[    4.703270] facetimehd 0000:03:00.0: Found FaceTime HD camera with device id: 1570
[    4.703460] facetimehd 0000:03:00.0: Setting 64bit DMA mask
[    4.709236] facetimehd 0000:03:00.0: S2 PCIe link init succeeded
[    4.709268] facetimehd 0000:03:00.0: Refclk: 25MHz (0xa)
[    4.719222] facetimehd 0000:03:00.0: PLL reset finished
[    4.719235] facetimehd 0000:03:00.0: Waiting for S2 PLL to lock at 450 MHz
[    5.023688] facetimehd 0000:03:00.0: Failed to lock S2 PLL: 0xc902c902
[    5.043642] facetimehd 0000:03:00.0: DDR40 PHY PLL locked on safe settings
[    5.043656] facetimehd 0000:03:00.0: STRAP valid
[    5.043657] facetimehd 0000:03:00.0: Configuring DDR PLLs for 450 MHz
[    5.043665] facetimehd 0000:03:00.0: DDR40 PLL is locked after 0 us
[    5.043675] facetimehd 0000:03:00.0: First DDR40 VDL calibration completed after 2 us
[    5.043687] facetimehd 0000:03:00.0: Second DDR40 VDL calibration completed after 2 us
[    5.043688] facetimehd 0000:03:00.0: Using step size 157
[    5.043693] facetimehd 0000:03:00.0: VDL set to: coarse=0x10008, fine=0x1011c
[    5.043698] facetimehd 0000:03:00.0: Virtual VTT enabled
[    5.064112] facetimehd 0000:03:00.0: S2 DRAM memory address: 0x22159559
[    5.064126] facetimehd 0000:03:00.0: Rewrite DDR mode registers succeeded
[    5.064326] facetimehd 0000:03:00.0: Full memory verification succeeded! (0)
[    5.526288] facetimehd 0000:03:00.0: Loaded firmware, size: 1392kb
[    5.566281] facetimehd 0000:03:00.0: ISP woke up after 0ms
[    5.566287] facetimehd 0000:03:00.0: Number of IPC channels: 7, queue size: 44865
[    5.566324] facetimehd 0000:03:00.0: Firmware requested heap size: 3072kb
[    5.576332] facetimehd 0000:03:00.0: ISP second int after 0ms
[    5.576334] facetimehd 0000:03:00.0: Channel description table at 00800000
[    5.586439] facetimehd 0000:03:00.0: magic value: 00000000 after 0 ms
[    5.586441] facetimehd 0000:03:00.0: Enabling interrupts
[    5.661587] facetimehd 0000:03:00.0: Direct firmware load for facetimehd/1871_01XX.dat failed with error -2

I'd like to clarify that this issue has been reproduced on several distributions and kernel versions. Consistently, as of Chromium 59, Facetime HD cameras [on linux] stopped working where they work with 58 or earlier.

I had downgraded and upgraded packages to test.

Last known working version: Chromium Version 58.0.3029.110 (64-bit)
First known regression version: Chromium Version 59.0.3071.104 (Developer Build) (64-bit)


Previously, I have removed the permission for camera access by hangouts.

I have downgraded my package to Chromium Version 58.0.3029.110 (64-bit), and it works, asking for my camera permission.

Upgrade to Chromium Version 59.0.3071.104 (Developer Build) (64-bit), it stopped working. Doesn't ask for camera permission.

This might be related to newer Chromium Version accessing camera controls which it did not in earlier versions. Some drivers seem to be sensitive to that.

Unfortunately, we currently do not have a switch to disable this to help confirm that this is really the cause. I am planning to add a switch for this.

What is the behavior in the latest 61 dev release?

Is this a Mac or Linux issue? 

Mac doesn't touch the capabilities or try to get the settings,
see [1,2].  takePhoto() is wired and has some code to back it
up [3], but needs to be called explicitly from JS, which I 
don't think is the case.


[1] https://cs.chromium.org/chromium/src/media/capture/video/mac/video_capture_device_mac.mm?sq=package:chromium&dr=C&l=392
[2] https://cs.chromium.org/chromium/src/media/capture/video/mac/video_capture_device_mac.mm?sq=package:chromium&dr=C&l=420
[3] https://cs.chromium.org/chromium/src/media/capture/video/mac/video_capture_device_avfoundation_mac.mm?sq=package:chromium&dr=C&l=398

According to the report, this is Linux running on a MacBook Pro.

Yup, this is linux-only, on recent MacBooks. This most likely affects these MacBook models:

iMac (21,5", since mid 2011)
iMac (27", since mid 2011)
MacBook Air (since mid 2011)
MacBook Pro (15", since early 2011)
MacBook Pro (17", since early 2011)
MacBook Pro (13", since early 2011)

Exactly what controls does the new version interact with? Maybe this can also be addresses (or at least, taking into consideration) on the driver side.

Not sure whether it is the same, using Google Chrome Version 61.0.3128.3 (Official Build) dev (64-bit)

Hangouts asks for microphone permissions, didn't ask for camera's permission i.e. not working.

> What is the behavior in the latest 61 dev release?

In case it's related. I get the following on stdout

[28373:28412:0624/141205.937416:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)

To be clearer I see

[28373:28412:0624/141205.937416:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)

The first time a webrtc page loads. e.g. https://test.webrtc.org/

Doesn't happen again after. I assume it's cached

https://chromium.googlesource.com/chromium/src/media/+/master/capture/video/linux/video_capture_device_factory_linux.cc#138 is the code in question.

and the bcwc_pcie code
https://github.com/patjak/bcwc_pcie/blob/master/fthd_v4l2.c#L549

I think it's unrelated since I compiled the driver with a different frame size type and still get the error. 

This is affecting me too since the release of Chrome 59 for Linux. Using patjak's bcwc_pcie facetimehd driver.

I also get this problem using chrome, on ubuntu Xenial on a MacBook Retina and the bcwc_pcie drivers (working with other software). This is my chrome version:

google-chrome-stable
Versions: 
60.0.3112.78-1 (/

And this is the error:

[28820:28858:0726/110814.496684:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)

Wondering when this might be fixed in future release?

Seeing this as well on Fedora 26 on my Macbook. I'm using the bcwc_pcie kmod on kernel 4.11.11-300.fc26.x86_64. Chrome Version 60.0.3112.78 cannot recognize my camera, and I see the same video_capture_device_factory_linux.cc error on the console. The webcam works fine in Firefox 54.0.1 or Cheese for me.

I have the same behaviour with Chrome unstable : Version 62.0.3175.4 (Official Build) dev (64-bit)

google-chrome-unstable --enable-logging --v=1

(google-chrome-unstable:25223): Gtk-WARNING **: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(google-chrome-unstable:25223): Gtk-WARNING **: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(google-chrome-unstable:25223): Gtk-WARNING **: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version
[1:19:0808/142918.077719:ERROR:adm_helpers.cc(62)] Failed to query stereo recording.
[25517:25517:0808/142918.120495:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)
[25517:25517:0808/142918.240219:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)
[25622:25622:0808/142957.649621:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)
[25622:25622:0808/142959.432864:ERROR:video_capture_device_factory_linux.cc(139)] Not implemented reached in void media::(anonymous namespace)::GetSupportedFormatsForV4L2BufferType(int, media::VideoCaptureFormats *)

Is there a possibility of a fix anytime soon?

There is a possibility. The first thing we need to do is figure out what change caused the regression. One potential change that could have caused this is what I mentioned in #8. However, since the issue seems to start with M59, another likely candidate is a new (spec-compliant) constraint handling. We have seen several cases where cameras started getting rejected, because they were reporting invalid or out-of-range frame rates.

Unfortunately I do not have a Macbook with Ubuntu or Fedora on it. To test if it is a constraint handling issue, please do the following:
1. Try to access a camera, e.g. by navigating to https://webrtc.github.io/samples/src/content/getusermedia/gum/
2. Open a new tab and navigate to chrome://media-internals
3. In the Video Capture tab, check if the camera is listed and copy/paste the list of supported formats to this thread.

The list of supported formats shows which frame rates the constraint handling sees as supported.

WebRTC test does not work (as expected):

getUserMedia error: NotFoundError

Here is the JSON output from the Video Capture tab:

[{"captureApi":"V4L2 SPLANE","formats":[{"resolution":"0x0","fps":"0.00","storage":"CPU"}],"id":"/dev/video0","name":"Apple Facetime HD"}]

Same here:

[{"captureApi":"V4L2 SPLANE","formats":[{"resolution":"0x0","fps":"0.00","storage":"CPU"}],"id":"/dev/video0","name":"Apple Facetime HD"}]

Thanks. I think these values make it very likely that the camera is rejected in the constraint handling because of the 0.00fps. I am not sure if the resolution can also lead to the device getting rejected.

guidou@: With your CL for allowing invalid frame rates [1], would we expect this to work again, or does a reported resolution of 0x0 lead to the device getting rejected as well?

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=739953

It will be rejected due to the 0x0 resolution.
Fixing the constraints algorithm to accept 0x0 resolutions is probably not worth it. Instead I'll make a patch to remove modes with 0x0 resolutions so that a fallback list of video modes is used instead.

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

commit 9c77470ff34bac937ceb765a27cee1703f0f2426
Author: Guido Urdaneta <guidou@chromium.org>
Date: Wed Aug 16 14:01:30 2017

Ignore 0-size resolutions when requesting video-input capabilities.

Some video-capture devices with faulty device drivers report resolutions
of 0x0. These devices are then rejected by the constraints processing
algorithm of getUserMedia since they are considered unable to support
any video mode selected by the algorithm.

By discarding these invalid formats, a fallback list of standard video
modes will be used instead, just like with devices that do not report
any video mode.

Bug:  733859 ,  740505 
Change-Id: Idc6610ad9abde02bf139736da0f7e183f8fcab6d
Reviewed-on: https://chromium-review.googlesource.com/615246
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494764}
[modify] https://crrev.com/9c77470ff34bac937ceb765a27cee1703f0f2426/content/browser/renderer_host/media/media_devices_dispatcher_host.cc
[modify] https://crrev.com/9c77470ff34bac937ceb765a27cee1703f0f2426/content/browser/renderer_host/media/media_devices_dispatcher_host_unittest.cc

Is there any more work planned here?

I believe with guidou@'s fix from #28, the issue may have been resolved. Can anyone who was affected by this confirm that it works again in 62.0.3188.0 or later?

I can confirm my camera works with 62.0.3202.9 (Official Build) dev (64-bit)!

Yay, Thanks guidou! This has been a bain. Awesome work.

The stable v62 has your fix implemented and works fine. However, the image is now stretched horizontally - like 4:3 image is shown as 16:9. Hopefully even this can be fixed. Thank you.

Yes, I am noticing the above behaviour too. The image is very stretched horizontally.

Thanks.

Interestingly, https://webrtc.github.io/samples/src/content/getusermedia/gum/ test shows normal aspect ratio but hangouts video call shows stretched image.

Think this is fixed in official Version 62.0.3202.89 (Official Build) (64-bit)