With more investigation the bug seems to be intermittent. Trying to find a sequence of events that reliably breaks the camera. Seems to be an interaction between Hangouts and Chrome that then makes the camera unavailable.

I am collating reports from more users. 

Problem is not limited to Macbook Pro, seems like a generic OSX / Chome issue.

Problem is intermittent. For example:

"so I unplugged my second monitor, started a viewing, camera not found, checked Hangouts, no camera access either, then we tested Photo Booth and the camera worked then went to the HTML 5 camer test and then it prompted to Allow Camera Access then it all worked"

i.e. Chrome's detection of Camera was temporarily broken, then opening native program Photo Booth fixed, it, then camera worked again in Chrome.

Previous comment was from a user with a 2011 Macbook Air 

If this is a bug in Chrome, and if it did start ~2 weeks ago, it could've been something from the stable refresh we did a few weeks back. However at first glance I don't see anything related in the changelog:

https://chromium.googlesource.com/chromium/src/+log/52.0.2743.82..52.0.2743.116?pretty=fuller&n=10000

+govind@, do you know if there's anything in the refresh that could've caused an issue like this?

+ Ligi, can we please try to repro and bisect if possible. 

hi all

Thanks for the quick response. It could also be an OSX update. There are a few security updates around the relevant time window that affect Quicktime, Audio, ImageIO interfaces (clutches at straws). 

https://support.apple.com/en-la/HT206903

For clarity on dates, our system has been used to access the webcam in Chrome by more than 30,000 users this year. Prior to 15th July 0.34% of users had a camera fault (we detect as no frames were delivered from the camera). Since 15th July 9% of users have a camera fault (7,000 users).

+ Narayana & Prudhvi, can any one of you please try to repro this on M53?

[triage] This seems important to look at. 

niklase/tommi/anatolid: can you have a look?

Just double-checked that this should not be related to QTKit deprecation. That was landed on Mar 31, meaning it should be in Chrome 51.

[triage]: Re #9: Any luck reproing?

Re #11: Niklas, can you find an owner to investigate this issue? It does look pretty serious.

Tommi, you're the owner of 582889, can you check if it's a dupe?

Just an update:

I have camera faults up to and including the 30th August but none since then. However, I've only had about 400 webcam sessions since then as the system has been quiet. But based on August numbers I'd expect about 30-40 faults in that sample.

I started collecting navigator.platform and navigator.appVersion on the 4th September.

Example data (note: No fault from this one):

"navigator":{"platform":"MacIntel","appVersion":"5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"}

Assuming the problem continues, hopefully this will at least be enough to track it to a particular OS or Chrome version. If other data accessible in Javascript is useful, let me know.

Did anything happen on the 1st Sept. that could've fixed the problem?

Divad, have your user failure stats gone down as well?

By failures do you mean camera faults? I have zero camera faults in my
system since 1st Sept. There were many every day since the 10th August
(looking back, that's when the fault rate spikes) and it stopped
abruptly on the 30th August. Note the end of the month is the 31st not
the 30th. Weird.

Decent stats take a few days to accumulate as the load is quite
variable depending how many sessions clients have booked. So while I'd
say it's not definite yet it looks like things have improved.

Hangouts updated on the 31st.

http://www.droid-life.com/tag/hangouts/

[triage]: divad, that sounds promising, although it would be nice to understand why this happened in the first place. I guess https://bugs.chromium.org/p/chromium/issues/detail?id=582889 is our best guess so far.

Hi Phoglund

 Issue 582889  doesn't really match the descriptions I have, which are all Apple/OSX. Also in the reports I have the problem manifests as Chrome can't detect any camera, so it won't serve a black image (see screenshot in original report). 

I just checked and I still don't have any new crashes since the 30th.

Personally I suspect that the problem was some interaction between Hangouts and Chrome that was killing Chrome access to the camera, and that the problem was resolved when Hangouts Desktop update rolled out on the 31st. 

But yeah, it's not nice being unable to find a confirmed resolution with the concern that the bug could come back...

Maybe all that we can do now is close this issue.

[triage] can you confirm that the camera is accessible in general on the machine? I.e. does it show up in system information > camera and can the OS X camera app use the camera?

I can confirm that, on the examples I saw in person, the camera
normally works in Chrome and in other applications. When the problem
was occurring, the camera was not detected by Chrome at all. Reboots
seemed to fix it.

I am currently (as in, right now) having the same problem on an early-2014 13-inch Air.  Chrome Version 53.0.2785.116 (64-bit), OS X 10.11.5.  No webcam detected.  Hangouts works in Safari.  Failure is intermittent for me too, and I unfortunately don't have a sense for reliable steps to reproduce.

I'm still getting a few user reports (example below) but volume of faults has definitely dropped after 30th August.

"- Macbook pro mid 2012 running macOS Sierra v10.12
- Chrome Version 53.0.2785.116 (64-bit)

Interestingly after the extension attempted to start, the Facetime camera stopped working. A system reboot fixes this."

divad.nosnilwar@: should we interpret #24 as the problem is solved by Chrome/OSX updates and that it just needs additional time to roll out?

@kjellan I am not confident it is solved. I think most likely there was a very frequent fault (probably due to Hangouts) which has been resolved, but there is also another intermittent fault with OSX and Chrome webcam driver. Possibly Hangouts was making a single fault occur more often. 

Unfortunately, as with Claire, I don't have any clues as to what is triggering the fault or any way to reliably reproduce. 

I'm going to keep watching this and will continue to update the thread with any new evidence as to what is causing it.

This is a duplicated of  https://crbug.com/582931 , however, since
this bug has so much investigation, I'll merge that one into this.
perkj@ stays as assigned since he did most of the work over there.

 Issue 582931  has been merged into this issue.

So this seems to be an OS problem that we have not been able to solve. See  https://crbug.com/582931  #1 for a little bit more info. Basically, when we ask AvFoundation for available devices, the OS reports zero devices. The only thing that seems to work is to kill the process, in this case the chrome browser process. 

We hope that moving capture to a separate mojo process will mitigate the problem. 
Work tracked here: https://bugs.chromium.org/p/chromium/issues/detail?id=584797

Also, from our UMA stats, 10.12 seems to behave much better.

Do we have an update.
- This is not resolved in 54 either: b/32753725 has more reports.

Applying "Release Block Stable label" for tracking. 

Applying RBS based on the intent in #32

Re #32, Afaik there's no way this can be fixed easily and in a way that could be safely merged to a release branch.

This is too late for M54 we already pushed our last planned refresh.  M55 will  start being shipped to stable in a few weeks, this may be able to get fixed in time for that?

As I said in #34, this is not something that can be done in a mergeable fix. This is a OS problem that manifest itself with apps like Skype and Facetime as well. The only possible workaround is to move out video capture to a separate process that can be restarted when this happens. This is already being worked on by moving video capture to mojo: https://bugs.chromium.org/p/chromium/issues/detail?id=584797

Restarting the browser process is obviously not an option, and marking this bug as a release blocker will not magically change the situation. 

Based on comment #36, this is unlikely going to be fix with M55 ( https://bugs.chromium.org/p/chromium/issues/detail?id=584797 is targeted for M56). 

**** Bulk edit -  please ignore if not applicable ****


A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

Removing "ReleaseBlock-Stable" based on comment #36.

Bumping to M57. Please update if that's wrong.

Niklas, does it make sense that you guys own this as part of mojifying video capture? 
If not, please reassign to mflodman or magjed.

that makes sense

 Issue 432868  has been merged into this issue.

Should this be bumped to M59?

Given there was no action on this for more than 5 months -- is it really a pri-1?

Yes, and there's tons of action in https://bugs.chromium.org/p/chromium/issues/detail?id=584797 that should resolve this. Still it makes sense to keep the bugs separate.

Oh, I see. Thanks for the update!

Any updates on when this fix will be released? Will it go out in M60 and if so when?

Thanks

We are currently targeting M61 for rolling it out.
In M60 there is a command-line flag where you can manually enable the video capture service (warning, this is experimental). If you run into this issue frequently and want to try it with the flag in M60, please let me know if it helps.

--enable-features=MojoVideoCapture

What's the latest status here? Shall this be bumped to M62?

We still hope to see some improvement for this with the changes we are rolling out with M61. However, our changes may not be addressing the root cause of the issue, so I don't expect we will be able to close it.

Not sure what the appropriate milestone label is for this case.

Well, I'd say that if the last meaningful commit (i.e. not a cleanup of unit tests or similar) in this bug lands in M61, then it will be M61.

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

commit b1473362a219c088d6cb06cfe0dd43d442612f71
Author: Christian Fremerey <chfremer@chromium.org>
Date: Tue Sep 05 17:44:12 2017

[Video Capture] Add more verbose WebRtc logs for video capture

This is to facilitate the investigation of camera issues for which WebRtc logs
are available but no detailed bug reports or reproduction steps can be obtained.

Bug: 643068
Change-Id: I0b8db85d749788f1897926bfef7d8b5f9312e41d
Reviewed-on: https://chromium-review.googlesource.com/642567
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#499670}
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/in_process_video_capture_device_launcher.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/in_process_video_capture_provider.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/in_process_video_capture_provider.h
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/media_devices_dispatcher_host_unittest.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/media_devices_manager_unittest.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/service_video_capture_device_launcher.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/service_video_capture_provider.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/service_video_capture_provider.h
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/service_video_capture_provider_unittest.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_controller.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_controller.h
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_controller_unittest.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_manager.cc
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_manager.h
[modify] https://crrev.com/b1473362a219c088d6cb06cfe0dd43d442612f71/content/browser/renderer_host/media/video_capture_manager_unittest.cc

Looks like this is going to continue in M64?

correct

Should this be bumped to M65?

Yes.

Is there any update on this issue?

+Amit, Narayana to triage.

There has been investigation effort put into this, but there is still no known repro or root cause. So we unfortunately have to keep bumping the target further out.

Team do not have 10.11.6, Hence checked the issue on latest stable 65.0.3325.162 and latest canary 67.0.3372.0. Issue is not reproducible using Mac 10.12.6/13-inch/Macbook Air ; 10.13.3/13-inch/Macbook Air ; 10.13.3/15-inch/Macbook Pro, 10.13.1/15-inch/Macbook Pro.

Unable to reproduce the issue on Mac 10.13.3 using chrome -53.0.2761.0, stable-	66.0.3359.181 & Canary-	69.0.3443.0 as per C#0 steps.

Steps Followed:
1. Launched chrome
2. Navigate to http://html5demos.com/gum 
3. Observed 'block', 'allow' popup
4. Clicked on 'allow'
5. Camera detected & camera is working as intended.

System details:
--------------
Mac OS High siera 10.13.3
8GB Memory
1.7GHz processor
Intel HD Graphics 5000 1536 MB

divad.nosnilwar@,
Please find the attached screencast for reference and check the issue on latest chrome versions & let us know your observations on the same.

Thanks..!

Deleted: 643068-M53.mp4 4.2 MB

	643068-M53.mp4 4.2 MB View Download

Deleted: 643068-Canary.mp4 4.9 MB

	643068-Canary.mp4 4.9 MB View Download

I confirm problem appears fixed, tested just now on Chrome
(66.0.3359.181) and the latest macOS (10.13.4) on 13” MacBook Pro
(Early 2015). Got a few others to test too.

To be honest think the problem was fixed a while ago - it lasted only
a couple of weeks I think but it was very acute at the time. We do
webcam eye tracking, about 500,000 persons past 2 years so we are
pretty sensitive to webcam issues.

regards
Dave

Also working on other versions of OSX, e.g.
Chrome: 66.0.3359.181 (64-bit)
macOS Sierra 10.12.6

chfremer@,

As per C#67, reporter confirmed that issue got fixed on M66.Please confirm on the fix & let us know anything is pending?

Note:
We are unable to repro this issue on reported version from our end on C#66.
Thanks..!