(Might be related to bug 643068)

chfremer, do you think this is a dupe?

Thing that may or may not make this a dupe:
1. When this happens it is system wide - no application (Chrome, Skype, Photo Booth etc) can access the camera.
2. The problem resolves itself in all programs (i.e. the program does not need to be restarted) bar Skype by doing "sudo killall VDCAssistant" and even Skype is OK after it is restarted.
3. Apple say "The USB camera was opened by Google Chrome on wake" but when I've tried Chrome on a WebRTC page it too is unable to access the Camera (perhaps I didn't try Chrome soon enough) and quitting Chrome doesn't make the problem go away, only doing the action described in (2) does.
4. This problem only seems to happen after the Mac has been suspended for long enough. Just closing/reopening the lid doesn't make this happen and not every suspend will make it happen though.

Should Chrome be opening the camera directly - won't it go through VDCAssistant like ever other app? Why is it happening on wake (I had to send Apple a sysdiagnose if extra options enabled for them to eventually get to this stage and then close the issue in Radar)? Is there a command-line option that just tells Chrome to never try and use any camera/USB device?

I do not think this is a dupe.

sitsofe@: From what you are reporting, I understand that you are have Chrome running before you send the MacBook Pro to sleep. It also sounds like you do not have any websites or extensions opened in Chrome that are accessing the Webcam. Could you please confirm that I understand that part correctly? 

If that is the case, I don't see why Chrome would try to access the Webcam at all (including when the system wakes up). At least not the video capture module. Not sure if there are any non-video-specific modules that would perhaps try to list all USB devices and this way trigger the camera driver?

There is a command-line flag --use-fake-device-for-media-stream that tells the video capture module in Chrome to use a fake camera instead of any real device. When using this flag, the video capture module will not access the actual camera. You could try using that and see if it changes anything. When you do, please let us know the result.

@chfremer: That is correct - Chrome is running as the MacBook Pro is sent to sleep and there are NO websites/extensions/flash accessing the webcam that I'm aware of.

I'll try the command line flag you suggested and see what the result is like.

Note that even when launching with that command line option and seeing the test video on https://webrtc.github.io/samples/src/content/getusermedia/gum/ Chrome still shows up when doing
lsof | grep VDC
suggesting it is still opening the VDC.plugin.

#9: Does it only opens the VDC.plugin when you open the test video page or does it already open it before that or with non-video pages?

I tried reproducing on a MacBook Air (13-inch, Early 2015) running mac os 10.12.3 and Chrome 56.0.2924.87 but was unsuccessful. Neither lsof nor Activity Monitor show any entries related to VDC, even when video is being captured from the camera. Could it be that my system does not have/use VDCAssistant, or do I need something different in order to see it?

It only opens VDC.plugin when going to the test page video page (https://webrtc.github.io/samples/src/content/getusermedia/gum/ ) or the GMail web page. Note that the VIDEO prompt doesn't have to be accepted for it to open VDC.plugin.

Just to reiterate my set up is MacBook Pro (13-inch, Mid 2012), macOS 10.12.3 (16D32), Chrome 57.0.2987.110 .

VDCAssistant should at least be used by Photo Booth but perhaps this has changed with newer MacBook models?

Having run with --use-fake-device-for-media-stream overnight I resumed today and found that Photo Booth was not complaining that it couldn't find the camera but wouldn't actually show a video - only a black square. Further the take photo button at the bottom of Photo Booth was unresponsive and could not be pressed. Chrome has no trouble showing its fake video on the webrtc demo page.

This problem is still here with 59.0.3071.86 ...

Thanks for continuing to track this.
I have by now seen this issue myself, and my current best theory is that this is related to the Chromium device monitor interacting with VDCAssistant at "a bad time" during sleep/wakeup cycles. I have tried to find repro steps that would allow testing this theory, but unfortunately the issue does not seem to be easily and quickly provokable. 

The two times I was able to observe the issue was after the following:
1. Run Chrome on MacBook.
2. Access the video camera in Chrome. It does not matter how, e.g. visit https://webrtc.github.io/samples/src/content/getusermedia/gum/. This step enables the device monitor, which after this will continue to run until Chrome is closed.
3. Keep Chrome open for a few days, occasionally using the MacBook to work or browse, but have it sleep/closed most of the time.
4. Try using an external camera (in my case I tried the built-in camera of an Apple Thunderbolt Display).
=> Camera does not work or does not even show up in the list.
=> Camera also does not work in PhotoBooth
=> Closing Chrome does not help
=> Only killing VDCAssistant makes things recover.

@chfremer: Apple had me gather diagnostic logs using the following steps:

sudo defaults write com.apple.cmio Debug -bool YES
sudo defaults write com.apple.cmio CMIO_DPA_VDC.Debug -integer 8
sudo reboot

once issue occur collect sysdiagnose

to disable extra log

sudo defaults write com.apple.cmio Debug -bool NO
sudo defaults write com.apple.cmio CMIO_DPA_VDC.Debug -integer 0
sudo reboot

It would be really useful if they could explain what they saw in the logs further given the popularity of this particular third-party app...

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

commit c0f7856fc099d07a7b11c7b7d9e5e0a7d6281ebd
Author: Christian Fremerey <chfremer@chromium.org>
Date: Fri Jul 14 23:25:03 2017

[Video Capture] Add feature switch for DeviceMonitorMac

On Mac it can happen that certain cameras stop working system-wide after Chrome 
has been running for a while (potentially days) and the computer has gone 
through sleep/wakeup cycles.

This could potentially be related to DeviceMonitorMac interacting with 
VDCAssistant either at a bad time or in a bad way. To be able to test this 
theory, this CL adds a feature switch that allows disabling the use of 
DeviceMonitorMac.

Bug: 699446
Test: Run chromium on Mac with --disable-features=DeviceMonitorMac
Change-Id: Id2a06c75bca7ec8e2db37b4b9647fe508edb0327
Reviewed-on: https://chromium-review.googlesource.com/558199
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486933}
[modify] https://crrev.com/c0f7856fc099d07a7b11c7b7d9e5e0a7d6281ebd/content/browser/renderer_host/media/media_devices_manager.cc
[modify] https://crrev.com/c0f7856fc099d07a7b11c7b7d9e5e0a7d6281ebd/content/public/common/content_features.cc
[modify] https://crrev.com/c0f7856fc099d07a7b11c7b7d9e5e0a7d6281ebd/content/public/common/content_features.h

This problem is still here in 61.0.3163.79. Some steps that provoke a problem on a MacBook Pro (it's unclear that it is this exact problem though):

1. Run
sudo pmset -a hibernatemode 25
to force hibernation on sleep.
2. In a Terminal start Chrome like so:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/chromedatadir/ "https://webrtc.github.io/samples/src/content/getusermedia/gum/" 
3. Reload the page and click Allow to "Use your camera".
4. In another terminal run the following
while true; do echo -n "Press RETURN to sleep: "; read; echo -n "$(date) "; pmset relative wake 1; pmset sleepnow; done
5. Press enter at the prompt and a hibernate followed by a wake should occur.
6. If when the computer starts the camera light at the top of the bezel is not green then a problem has been triggered.
7. repeat steps 5-6 if the camera light is showing and a live picture from the camera continues to be shown.

Generally a problem occurs within 10 tries. This problem seems slightly different to the original one (Photo Booth refuses to show a picture rather than saying "There is no connected camera." although very rarely you will get that problem instead.

sitsofe@: Thanks for these steps. If these steps allow us to reproduce the issue within several minutes with reasonable reliability, this should allow us to finally narrow down the cause of this issue, which would be extremely helpful.

I tried the steps from #17 on a Macbook Air (Early 2015) running Mac OS 10.12.6. Here are my findings:

1. To get the machine to actually hibernate, in addition to setting hibernatemode to 25 and deactivating standby by setting it to 0, I need to send it to sleep and then wait about 60s before waking it up again. I believe this is the time it takes the machine to write the memory to disk. If I press any button during this time, it will abort the hibernation. On a Macbook Air it is hard to tell when it has reached hibernation, because the display turns off immediately and there are no power or activity lights. The only way to tell is that it won't wake up from key presses other than the power button and it will show some grey bars during startup while restoring the memory from disk.
2. "pmset relative wake 1" won't wake the machine up for me. I have to do it manually by pressing the power button on the keyboard.
3. I tried about 15 cycles of hibernate/wakeup while having the page https://webrtc.github.io/samples/src/content/getusermedia/gum/ open, but the issue did not occur.

sitsofe@: Could you please confirm that when you reproduce the issue your Macbook indeed completes hibernation and powers off, or does it already reproduce with regular sleep mode?

@chfremer: Ah that's a pain. Yes it needs a full hibernation cycle, yes it takes around 60 seconds for it to power down.

I was originally doing it with hibernate only mode but manually powering the laptop back on until I found out about "pmset relative wake 1". However I'm on a non-retina 2012 MacBook Pro with a DVD drive and spinning fans so I can actually hear a ker-chunk from the DVD drive when it is actually powering up after being fully off (as opposed to suspended). As you found, if I press a key/power button too early then the computer immediately resumes without actually powering down and the problem is never triggered. Going by the power light alone turned out to be useless because the laptop wasn't actually powered down - I actually wound up having to listen for the fans to stop spinning before pressing a key on the keyboard. I don't see a grey bar on resume though - does that suggest you're seeing some sort of safe suspend being resumed (I think I only tended to see that when I lose power on a safe suspend)?

I'm on 10.12.6 (16G29). 

re #19: Yes, I think the grey bars (they look like here [1], just with different color) indicate a resume from disk after power off. I am wondering if we are reaching the same suspend state or not, and whether or not the issue depends on which one is reached. Here [2] is a doc from apple describing some different states.

As far as I can tell, there are at least 3 different types of suspend modes:
1. "Sleep": Memory stays powered
2. "Standby Mode": Memory is written to disk, Power to Memory and USB is cut, wakeup still happens when pressing any key (I am guessing)
3. "Safe Suspend": Memory is written to disk, Power to Memory and USB is cut, wakeup requires pressing the power button

If you haven't disabled Standby Mode, could it be that you are actually going into Standby Mode instead of Safe Suspend?

[1] https://support.apple.com/library/content/dam/edam/applecare/images/en_US/macos/macos-sierra-mbp-progress-bar-after-deep-sleep.png
[2] https://support.apple.com/en-us/HT202824

sitsofe@: After you wake up the device, if you do the following command, what does the latest entry show:

pmset -g log | grep -i "wake from"

For me, when waking up from "Safe Suspend" on Battery power, I get something like "Wake from AutoPowerOff". When waking from "Standby Mode" on Battery power, I get "Wake from Standby". When waking from "Standby Mode" on AC power, I get "DarkWake to FullWake from Standby". When interrupting the suspend mode before it has written the memory to disk, I get no entry at all.

Which one do you get when you successfully repro?

OK I've just disabled standby mode (pmset -g reports it as 0) and no change - no grey screen with bars going across. Perhaps this is because the screen fades to black and/or because my laptop only has 4GBytes of RAM.

Hmm I'm seeing this:
2017-09-11 23:00:23 +0100 Wake                	Wake from Standby [CDNVA] due to RTC/Alarm: Using AC (Charge:82%)           
when standby 0 and wake using wake relative.

However I do get the grey screen and progress bar if I wake manually with standby 0. Here's what was recorded in the log:

2017-09-11 23:06:39 +0100 Wake                	Wake from Standby [CDNVA] due to EC.PME/User: Using AC (Charge:84%)           

Hmm, looks like it is Standby Mode then. I have no idea why it is going to Standby Mode even when standby is set to 0. Could be that it is also affected by standydelay, autopoweroff, and autopoweroffdelay. When going to actual "Safe Suspend", I had all of these set to 0, and I had the AC power unplugged.

But that may not matter much, since your reproduction steps seem to work for you with Standby Mode. So I am trying to see if I can reproduce the issue with Standby Mode on my machine as well. So far no luck ...

Just reproduced the "refuse to show a picture in Photo Booth problem" again on the first try which is unusual. Here's the wake from output:

2017-09-11 23:15:48 +0100 Wake                	Wake from Standby [CDNVA] due to RTC/Alarm: Using BATT (Charge:84%)           

Nice. Could you please post the complete output of "pmset -g" for reference here? I will try to match your settings.

Also, do you have any USB devices/cameras plugged in?

I can't make it happen if I have two Chrome instances open - I must have exactly the one that has the webcam showing open and only that.

$ pmset -g log | grep -i "wake from" | tail -1
2017-09-11 23:38:38 +0100 Wake                	Wake from Standby [CDNVA] due to RTC/Alarm: Using BATT (Charge:76%)           

$ pmset -g
System-wide power settings:
Currently in use:
 standbydelay         4200
 standby              1
 halfdim              1
 sms                  1
 hibernatefile        /var/vm/sleepimage
 disksleep            10
 sleep                10 (sleep prevented by AddressBookSourceSync)
 autopoweroffdelay    14400
 hibernatemode        25
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         2 (display sleep prevented by Google Chrome)
 acwake               0
 lidwake              1

Forgot to say no USB devices plugged in bar the built-in Facetime camera. Bluetooth is on and discoverable but nothing is connected.

sitsofe@: Thanks a lot for this. I am trying to repro with the same settings now. In the meantime, one thing you could try to help narrow down the cause is the following: When starting chrome 61.0.3163.79 or newer, add the following command-line flag:

--disable-features=DeviceMonitorMac

If the issue does not reproduce with this flag, then this would indicate that the issue is related to the DeviceMonitorMac feature.

chfremer@ I did
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/chromedatadir/ "https://webrtc.github.io/samples/src/content/getusermedia/gum/" --disable-features=DeviceMonitorMac
Cfollowed by a manual boot and the camera failed to come back on. Chrome is 61.0.3163.79. I'm off to bed for the day so any follow up from me will be tomorrow.

That should have been followed by a sleep and a manual wake...