qagalaxy8@: Thanks for the report. If you happen to have a Win10 machine available, could you test some of these cameras on there as well? I am curious to see if it makes any difference. And for the failing configurations, could you please post the name and id of the cameras as described in #18?

I just tested a "HD Pro Webcam C920 (046d:082d)" on Windows 10 and it worked fine. This indicates that maybe this camera uses a different driver on Windows 8, which behaves differently.

Not to sound ignorant, but why must this fix be a blacklist? Is there really no other way to detect if a camera has this "image capture" capability? This fix only seems partial to me. Will there be a method for companies to blacklist their own cameras in the future?

The current situation of blacklisting a wide range of video camera devices on the basis of a missing still image capability is horribly over simplifying the use cases in the real world. 

If I want the camera for a WebRTC video call, I don't give a damn if it can't take a still properly. 

The use and the capability must be linked if you are going to blacklist. Instead of blacklisting, why not raise error on the API call that you know will fail with the missing capability?
  

#27: as you can read in #7,8,9, the blacklisting would only affect the
image capture capabilities reading/setting.

At the moment we're trying to figure out which combination of camera,
OS version and any other variables is the one causing the problems to 
arise, also considering that we haven't been able to repro so far. The
decision as to what and if to blacklist would depend on how widespread
and/or specific are the problems, information that takes a bit to gather 
since we are not seeing crashes.

 Issue 733136  has been merged into this issue.

 Issue 732389  has been merged into this issue.

Windows 7 Pro x64 i3,  Logitech HD C270, 60.0.3112.24 
This combination fails with black screen.

Works on new chrome beta version 60.0.3112.24
- Logi Group HD 1080p Camera (046d:0858)
- HP HD Webcam [Fixed] (04f2:b270)
- HP HD Webcam [Fixed] (04f2:b230)
- Microsoft LifeCam HD-3000 (045e:0779)

Does not work on new chrome beta version 60.0.3112.24
- HP HD Webcam (04f2:b477)
- Logitech HD Webcam C310 (046d:081b)
- Logitech HD Webcam C270 (046d:0825)

Win10
Doesn't work:
Logitech HD Webcam C310 (046d:081b)
Integrated Camera (04f2:b221)

Works:
Logitech Webcam C930e (046d:0843)

I'm running windows 10 build 15063.296 on lenovo T460s, and have an external camera connected as well (logitech C920). It does not seem to be related to cameras at all in my case, as I've tried 3 more cameras (for 2 of them I don't know which model, as they're really old).

It seems like New beta version is not supporting some specific web cameras. 

Works on new chrome beta version 60.0.3112.24 on Win10, Win8 :
  1) Microsoft LifeCam HD-3000 (045e:0779)
  2) Logitech C170 (non HD)
  3) DBPOWER MD740 USB Camera

Does not work on new chrome beta version 60.0.3112.24 on Win10, Win8 :
  1) (HD) Logitech Webcam C920 (1080 pixel)
  2) (HD) Logitech HD Webcam C615 (1080 pixel)
  3) (HD) Logitech HD Webcam C270 (720 pixel)
  4) (HD) Logitech B525 HD Webcam

 Issue 733616  has been merged into this issue.

 Issue 731710  has been merged into this issue.

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 734144  has been merged into this issue.

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

commit f21fba7db4b89356077c052c49b165f3e48c9305
Author: Christian Fremerey <chfremer@chromium.org>
Date: Tue Jun 20 22:38:34 2017

[Video/Image Capture] Put Windows image capture controls behind feature flag

The drivers for several devices on Windows appear to not properly handle
querying for controls used in the context of Image Capture. These cases lead to
video capture being broken and users seeing only a blank image.

This CL adds a feature flag kImageCaptureControls Image Capture on Windows. 
For now, we disable this feature by default. The feature can be enabled by 
adding --enable-features=ImageCaptureControls to the command-line.

Bug:  722038 
Test: Manual tested on Windows using iSpy virtual device.
Change-Id: I654ff72772af10c2d5356d5131ed7ed98e300c1f
Reviewed-on: https://chromium-review.googlesource.com/530076
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#480999}
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/content/browser/webrtc/webrtc_image_capture_browsertest.cc
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/media/base/media_switches.cc
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/media/base/media_switches.h
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/media/capture/video/win/video_capture_device_factory_win.cc
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/f21fba7db4b89356077c052c49b165f3e48c9305/media/capture/video/win/video_capture_device_win.h

does this fix need a merge?

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

commit 109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab
Author: Sami Kalliomäki <sakal@chromium.org>
Date: Wed Jun 21 11:27:06 2017

Revert "[Video/Image Capture] Put Windows image capture controls behind feature flag"

This reverts commit f21fba7db4b89356077c052c49b165f3e48c9305.

Reason for revert: Speculatively reverting, might have caused
chromium.webrtc tests to start failing. Failing tests:
https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/35162
https://build.chromium.org/p/chromium.webrtc/builders/Win10%20Tester/builds/17320

Original change's description:
> [Video/Image Capture] Put Windows image capture controls behind feature flag
> 
> The drivers for several devices on Windows appear to not properly handle
> querying for controls used in the context of Image Capture. These cases lead to
> video capture being broken and users seeing only a blank image.
> 
> This CL adds a feature flag kImageCaptureControls Image Capture on Windows. 
> For now, we disable this feature by default. The feature can be enabled by 
> adding --enable-features=ImageCaptureControls to the command-line.
> 
> Bug:  722038 
> Test: Manual tested on Windows using iSpy virtual device.
> Change-Id: I654ff72772af10c2d5356d5131ed7ed98e300c1f
> Reviewed-on: https://chromium-review.googlesource.com/530076
> Reviewed-by: Dan Sanders <sandersd@chromium.org>
> Reviewed-by: Emircan Uysaler <emircan@chromium.org>
> Commit-Queue: Christian Fremerey <chfremer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#480999}

TBR=mcasas@chromium.org,sandersd@chromium.org,emircan@chromium.org,chfremer@chromium.org

Change-Id: I12d976ca1c81c55a685360bb23817dca605085ad
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  722038 ,  735379 
Reviewed-on: https://chromium-review.googlesource.com/543137
Reviewed-by: Henrik Kjellander <kjellander@chromium.org>
Commit-Queue: Sami Kalliomäki <sakal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481173}
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/content/browser/webrtc/webrtc_image_capture_browsertest.cc
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/media/base/media_switches.cc
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/media/base/media_switches.h
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/media/capture/video/win/video_capture_device_factory_win.cc
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/109eab7e4104da3f5ae4c5387a1ce54e6b74e0ab/media/capture/video/win/video_capture_device_win.h

#43: Yes, this needs to be merged into M60. I am expecting to reland today, and assuming it sticks, we can request the merge approval tomorrow.

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

commit 0034bdea7ead45fc8738b68bbf1eb9d037eece33
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Thu Jun 22 02:00:49 2017

Image Capture win: initialize camera controls lazily

ToT initializes |camera_control_| and |video_control_| 
during AllocateAndStart(), which causes issues for clients
who just want video capture. This CL corrects this by
delaying initialization of the said member variables to
when they are needed, that is, when calling GetPhotoState()
or SetPhotoOptions().

Bug:  722038 
Change-Id: I9d98075c53ec1519057187a722f5f8747fd12fde
Reviewed-on: https://chromium-review.googlesource.com/543198
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481401}
[modify] https://crrev.com/0034bdea7ead45fc8738b68bbf1eb9d037eece33/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/0034bdea7ead45fc8738b68bbf1eb9d037eece33/media/capture/video/win/video_capture_device_win.h

Can anyone please try again when #46 lands in Canary ([1]
will tell us the exact revision).  If it solves the problem
it's safe to consider a merge back to M60.

[1] https://storage.googleapis.com/chromium-find-releases-static/index.html#r481401

61.0.3139.0 has the fix in #46.

cmorgan@cafex.com, onuryazd@gmail.com, hrundik@gmail.com, reniar123@gmail.com, 
qagalaxy8@gmail.com (and anyone else in this thread), could you guys give it a
go and share your experiences?  If this fixes the problem we'll merge back to
M60 to address this issue while we work on a longer term fix.

Thanks for updates... 

We tried today installing Canary latest version(61.0.3139.0). It got installed normally. On four systems we installed and here are the results:

- On one system it could not even launch the Canary application.

- On two system it was launched and worked fine with the normal camera. As soon we connected HD camera (Logitech c625) it crashed the app and then onwards could not relaunch. ( Specific observation, in this case, is HD camera was connected prior to launch Canary application).

- On one system it worked with normal and HD camera (Logitech c615). ( In this case, initially HD camera was not connected, just inbuilt camera from the laptop was checked. Later we connected Logitech c625 HD cam, and refreshed the web app and found its working with both normal webcam and HD webcam). After closing the Browser, we could not relaunch the Canary App.


OS Information: Win8.1, Win10

Browser Information:  Canary  61.0.3139.0
 
HD Camera Info:  Logitech HD Webcam C920, Logitech HD Webcam C615,  Logitech HD Webcam C270 

Having installed 61.0.3139.0 Canary now fails to start at all. 

Win7 Pro, Logitech HD Webcam C270

Windows 7 x64
Chrome 61.0.3139.0
Logitech c615

Local Crash ID b235c555-4b47-4c07-87e8-901b1f8770db

1. Plug in the camera
2. Open Chrome and navigate to https://github.com/webrtc/samples
3. Click the "Allow" button in the security prompt
4. Observe Chrome crashing
5. Failed to re-open Chrome afterwards

I meant to paste this link: https://webrtc.github.io/samples/src/content/getusermedia/gum/

Looks like Canary was rolled back

qagalaxy8@, xsvengolix@, thanks for trying, perhaps this
canary had other issues. Also thanks for mentioning the
crash id - one thing, can you provide the "Uploaded Crash Report ID"
instead of the "Local Crash ID"? (You might need to click the
"Send now" link -- thanks.

Sorry about that. I have a feeling that report wasn't even the correct crash report anyways. I'm having a hard time getting Chrome to open up again after I perform the test. I installed 61.0.3139.0 on another Windows 7 machine and tried again. I pulled the attached dmp files from "...\AppData\Local\Google\Chrome SxS\User Data\Crashpad\reports"

I hope this helps. If you have any insight on getting Chrome to start again properly, I'll perform the test again and attempt to send the crash report through Chrome. There's something lingering on the machine, even after uninstalling, that's causing the startup issue.

"ae8f..." is probably what you're looking for. The other two were probably from me trying to start Chrome after the test.

Deleted: ae8fe0ff-4bbf-49ba-a64f-9bb3f2c1753a.dmp 1.8 MB

ae8fe0ff-4bbf-49ba-a64f-9bb3f2c1753a.dmp 1.8 MB Download

Deleted: 132faa06-be81-4a0a-910d-d31d33527057.dmp 5.2 MB

132faa06-be81-4a0a-910d-d31d33527057.dmp 5.2 MB Download

Deleted: 9eebd8d0-2797-4430-9040-adf4a0020314.dmp 1.8 MB

9eebd8d0-2797-4430-9040-adf4a0020314.dmp 1.8 MB Download

#54: yeah, it seems like this Canary is broken for some other reasons,
the one I'm using on my Mac won't even start, let's wait for the next
one.

canary 61.0.3139.0 on my windows 10 machine crashed after i approve the camera/mic permission

attached dmp files from "...\AppData\Local\Google\Chrome SxS\User Data\Crashpad\reports"

Deleted: 69cff36a-415f-4b33-8804-25c6ee06d276.dmp 5.4 MB

69cff36a-415f-4b33-8804-25c6ee06d276.dmp 5.4 MB Download

also had to cleanup entire "..\AppData\Local\Google\Chrome SxS\User Data" first time after install, and each time after crash, in order to lunch the canary, other wise it won't exeucte.

with 61.0.3141.0 (Official Build) canary (64-bit) (cohort: 64-Bit), i get a nullptr deref crash at video_capture_device_win.cc:507 in the browser process, which is worse than the camera not working. looks like the new CL doesn't handle the case where camera_control_ can't be created. here's the crash stack (this is reported in issue 736368):

 # Child-SP          RetAddr           Call Site
00 (Inline Function) --------`-------- chrome_7ffc998e0000!media::VideoCaptureDeviceWin::GetPhotoState::__l2::<lambda_6cd7ea6c7f787307d773671349decf6d>::operator()+0x28 [c:\b\c\b\win64_pgo\src\media\capture\video\win\video_capture_device_win.cc @ 507]
01 (Inline Function) --------`-------- chrome_7ffc998e0000!media::RetrieveControlRangeAndCurrent+0x28 [c:\b\c\b\win64_pgo\src\media\capture\video\win\video_capture_device_win.cc @ 75]
02 000000e9`2b9ff280 00007ffc`99f1fc6e chrome_7ffc998e0000!media::VideoCaptureDeviceWin::GetPhotoState+0x72 [c:\b\c\b\win64_pgo\src\media\capture\video\win\video_capture_device_win.cc @ 505]
03 (Inline Function) --------`-------- chrome_7ffc998e0000!base::internal::FunctorTraits<void (__cdecl media::VideoCaptureDevice::*)(media::ScopedResultCallback<base::Callback<void __cdecl(mojo::StructPtr<media::mojom::Blob>),1,1> >),void>::Invoke+0x21 [c:\b\c\b\win64_pgo\src\base\bind_internal.h @ 209]
04 (Inline Function) --------`-------- chrome_7ffc998e0000!base::internal::InvokeHelper<0,void>::MakeItSo+0x21 [c:\b\c\b\win64_pgo\src\base\bind_internal.h @ 275]
05 (Inline Function) --------`-------- chrome_7ffc998e0000!base::internal::Invoker<base::internal::BindState<void (__cdecl media::VideoCaptureDevice::*)(media::ScopedResultCallback<base::Callback<void __cdecl(mojo::StructPtr<media::mojom::Blob>),1,1> >),base::internal::UnretainedWrapper<media::VideoCaptureDevice>,base::internal::PassedWrapper<media::ScopedResultCallback<base::Callback<void __cdecl(mojo::StructPtr<media::mojom::Blob>),1,1> > > >,void __cdecl(void)>::RunImpl+0x3f [c:\b\c\b\win64_pgo\src\base\bind_internal.h @ 351]
06 000000e9`2b9ff580 00007ffc`9a44fe30 chrome_7ffc998e0000!base::internal::Invoker<base::internal::BindState<void (__cdecl media::VideoCaptureDevice::*)(media::ScopedResultCallback<base::Callback<void __cdecl(mojo::StructPtr<media::mojom::Blob>),1,1> >) __ptr64,base::internal::UnretainedWrapper<media::VideoCaptureDevice>,base::internal::PassedWrapper<media::ScopedResultCallback<base::Callback<void __cdecl(mojo::StructPtr<media::mojom::Blob>),1,1> > > >,void __cdecl(void)>::Run+0x46 [c:\b\c\b\win64_pgo\src\base\bind_internal.h @ 329]
07 (Inline Function) --------`-------- chrome_7ffc998e0000!base::Callback<void __cdecl(void),0,0>::Run+0x12 [c:\b\c\b\win64_pgo\src\base\callback.h @ 91]
08 000000e9`2b9ff5d0 00007ffc`9a4003a6 chrome_7ffc998e0000!base::debug::TaskAnnotator::RunTask+0x1b0 [c:\b\c\b\win64_pgo\src\base\debug\task_annotator.cc @ 59]
09 000000e9`2b9ff780 00007ffc`9a4005b2 chrome_7ffc998e0000!base::MessageLoop::RunTask+0x1f6 [c:\b\c\b\win64_pgo\src\base\message_loop\message_loop.cc @ 423]
0a 000000e9`2b9ff8e0 00007ffc`9a400e98 chrome_7ffc998e0000!base::MessageLoop::DeferOrRunPendingTask+0x62 [c:\b\c\b\win64_pgo\src\base\message_loop\message_loop.cc @ 436]
0b 000000e9`2b9ff910 00007ffc`9a4503b1 chrome_7ffc998e0000!base::MessageLoop::DoWork+0x4d8 [c:\b\c\b\win64_pgo\src\base\message_loop\message_loop.cc @ 540]
0c 000000e9`2b9ffb10 00007ffc`9a450024 chrome_7ffc998e0000!base::MessagePumpForUI::DoRunLoop+0x71 [c:\b\c\b\win64_pgo\src\base\message_loop\message_pump_win.cc @ 174]
0d 000000e9`2b9ffb80 00007ffc`9a4266e4 chrome_7ffc998e0000!base::MessagePumpWin::Run+0x54 [c:\b\c\b\win64_pgo\src\base\message_loop\message_pump_win.cc @ 58]
0e 000000e9`2b9ffbd0 00007ffc`9a3fed24 chrome_7ffc998e0000!base::RunLoop::Run+0x64 [c:\b\c\b\win64_pgo\src\base\run_loop.cc @ 112]
0f 000000e9`2b9ffc80 00007ffc`9a3d4da0 chrome_7ffc998e0000!base::Thread::ThreadMain+0x1d4 [c:\b\c\b\win64_pgo\src\base\threading\thread.cc @ 341]
10 000000e9`2b9ffd50 00007ffc`ce1c8364 chrome_7ffc998e0000!base::`anonymous namespace'::ThreadFunc+0xf0 [c:\b\c\b\win64_pgo\src\base\threading\platform_thread_win.cc @ 91]
11 000000e9`2b9ffdb0 00007ffc`ceb470d1 KERNEL32!BaseThreadInitThunk+0x14
12 000000e9`2b9ffde0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

61.0.3141.0 crashes for me as well

61.0.3141.0  :- It worked fine with the normal camera. As soon we connected HD camera (Logitech c625) and checked with below Url it crashed the app.

URL: https://webrtc.github.io/samples/src/content/devices/input-output/

Hey.. Please guide when will you planning for next Stable release and will that stable release involve fix for this issue as well?

It's important for us to know that because lots of application component on the live platform will be impacted by this issue.

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

commit 6a99b678a21703b15f0886acddfd24e4171b878d
Author: Erik Chen <erikchen@chromium.org>
Date: Mon Jun 26 22:10:00 2017

Revert "Image Capture win: initialize camera controls lazily"

This reverts commit 0034bdea7ead45fc8738b68bbf1eb9d037eece33.

Reason for revert: Reverting on recommendation of ligimole@ for being a top crasher in Canary:
https://bugs.chromium.org/p/chromium/issues/detail?id=736368

Original change's description:
> Image Capture win: initialize camera controls lazily
> 
> ToT initializes |camera_control_| and |video_control_| 
> during AllocateAndStart(), which causes issues for clients
> who just want video capture. This CL corrects this by
> delaying initialization of the said member variables to
> when they are needed, that is, when calling GetPhotoState()
> or SetPhotoOptions().
> 
> Bug:  722038 
> Change-Id: I9d98075c53ec1519057187a722f5f8747fd12fde
> Reviewed-on: https://chromium-review.googlesource.com/543198
> Reviewed-by: Christian Fremerey <chfremer@chromium.org>
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#481401}

TBR=mcasas@chromium.org,chfremer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  722038 
Change-Id: I573d6a956e6ab7614df981c966dc15b5c2349a0f
Reviewed-on: https://chromium-review.googlesource.com/549059
Reviewed-by: Erik Chen <erikchen@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482432}
[modify] https://crrev.com/6a99b678a21703b15f0886acddfd24e4171b878d/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/6a99b678a21703b15f0886acddfd24e4171b878d/media/capture/video/win/video_capture_device_win.h

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

commit 89ec7939fd60622719d440296e99f1feacc09ac1
Author: erikchen <erikchen@chromium.org>
Date: Mon Jun 26 23:25:03 2017

[Merge to 3141] Revert "Image Capture win: initialize camera controls lazily"

This reverts commit 0034bdea7ead45fc8738b68bbf1eb9d037eece33.

Reason for revert: Reverting on recommendation of ligimole@ for being a top crasher in Canary:
https://bugs.chromium.org/p/chromium/issues/detail?id=736368

Original change's description:
> Image Capture win: initialize camera controls lazily
>
> ToT initializes |camera_control_| and |video_control_|
> during AllocateAndStart(), which causes issues for clients
> who just want video capture. This CL corrects this by
> delaying initialization of the said member variables to
> when they are needed, that is, when calling GetPhotoState()
> or SetPhotoOptions().
>
> Bug:  722038 
> Change-Id: I9d98075c53ec1519057187a722f5f8747fd12fde
> Reviewed-on: https://chromium-review.googlesource.com/543198
> Reviewed-by: Christian Fremerey <chfremer@chromium.org>
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#481401}

TBR=mcasas@chromium.org,chfremer@chromium.org

Bug:  722038 
Change-Id: I573d6a956e6ab7614df981c966dc15b5c2349a0f
Reviewed-on: https://chromium-review.googlesource.com/549059
Reviewed-by: Erik Chen <erikchen@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#482432}
Review-Url: https://codereview.chromium.org/2962613002 .
Cr-Commit-Position: refs/branch-heads/3141@{#7}
Cr-Branched-From: 180095eb1bca7df1cdcb02547340499c2ee3af6e-refs/heads/master@{#482153}

[modify] https://crrev.com/89ec7939fd60622719d440296e99f1feacc09ac1/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/89ec7939fd60622719d440296e99f1feacc09ac1/media/capture/video/win/video_capture_device_win.h

qagalaxy8@gmail.com: the original CL I landed to address this problem
got reverted while I was AFK :( :(

having another go at it in https://crrev.com/c/549956, hopefully 
tomorrow's Canary will pick it up and we can try again.

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

commit 0591491eb3bd9b7e416ba5dce25bbd667b75bd6a
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Tue Jun 27 18:49:35 2017

RELAND: Image Capture win: initialize camera controls lazily

The original CL was reverted due to unhandled initialization
problems with either |camera_control_| or |video_control_|.
This CL corrects that, making InitializeVideoAndCameraControls()
return a boolean that is then checked on the caller site. 

PS1 has the original CL verbatim to compare new changes against.



Original CL description ---------------------------------------
ToT initializes |camera_control_| and |video_control_|
during AllocateAndStart(), which causes issues for clients
who just want video capture. This CL corrects this by
delaying initialization of the said member variables to
when they are needed, that is, when calling GetPhotoState()
or SetPhotoOptions().
Original CL: https://chromium-review.googlesource.com/543198

Bug:  722038 
Change-Id: I56febecd87e741c3f98f1f915cbd9ee6ec8575fd
Reviewed-on: https://chromium-review.googlesource.com/549956
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482698}
[modify] https://crrev.com/0591491eb3bd9b7e416ba5dce25bbd667b75bd6a/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/0591491eb3bd9b7e416ba5dce25bbd667b75bd6a/media/capture/video/win/video_capture_device_win.h

Hi,

This has been raised by Woolworths, a large Google Gsuite customer, the bug is  affecting them.

Hi, I am from woolworths, we picked this up in testing of Beta CHrome Browser, it is not released to production users yet but we will need resolved before we can. 

#66 landed as Commit 0591491e... initially landed in 61.0.3143.0,
can you guys give it a go and ping this issue with the results? thx

Hi,

61.0.3143.0 is still failing : same behaviour as Chrome 60.

tried with the following page, on Win7 with a Logitech Pro9000
https://webrtc.github.io/samples/src/content/getusermedia/gum/

I'm seeing the same results as #70 with my Logitech c615 camera on Windows 7. The stream immediately becomes inactive; no video. Doesn't crash though!

I can confirm that 61.0.3143 on Windows 10, with a Logitech C615, it is
still failing without crash.

This was raised on May 13 and it is now June 29, and quite a serious bug,
which will a profound impact on WebRTC users.

 Is there a way to escalate attention to this so that we are not faced with
similar experiences to m59 release where people were scrambling for fixes
to critical issues days before release.

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

commit 6b50cd75ccdc4cc1f15a9edeffbb56fadfca8c53
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Thu Jun 29 02:13:55 2017

ImageCapture: Disable PhotoState collection in Windows

Disable PhotoState collection in Windows because it seems
to prevent normal video capture (see bug).  

Disabling the collection of the PhotoState (capabilities and
current settings) also prevents in practice any 
setOptions()/applyConstraints() operations since the intended
options/constraints are checked against the valid ranges,
which would be nonexistent if no capabilities were collected.

Bug:  722038 
Change-Id: I4f98eadc4a486040791eedee280a06c88ca83d1d
Reviewed-on: https://chromium-review.googlesource.com/553525
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483261}
[modify] https://crrev.com/6b50cd75ccdc4cc1f15a9edeffbb56fadfca8c53/content/browser/image_capture/image_capture_impl.cc

A patch has landed as part of 61.0.3145.0. I tested it on my Windows laptop and it appears to be effective. 

Could you please check one more time with the new version and let us know if it works for you?

Windows 7 x32 w/ Logitech c615 is working on 61.0.3145.0 canary.

Windows 10 64-bit chromium canary 61.0.3146.0 with Logitech C920 fails.   Test page https://webrtc.github.io/samples/src/content/getusermedia/gum/ and hangouts both continue to show black box.  

Windows 10 64-bit Chrome canary 61.0.3145.0 also fails with Logitech C920.

Windows 10 64-bit Chrome canary 61.0.3145.0 works fine on Lenovo T460s -- same machine fails on 60.0.3112.50

Windows 7 x64 w/ Logitech c615 and Logitech c920 works.

Thanks for checking.

pfilsinger@: Not sure where you got a version 61.0.3146.0. From what I can see there is no newer canary build than 61.0.3145.0 as of right now. Also, could you please confirm that your C920 is working with a build prior to 60.0.3092.0, just to double-check that this is not a different issue?

Will this fix make it back into v60 beta?

Yes, we are planning to merge it into M60 Beta as soon as it is confirmed working.
It appears that it is, so I am going to add the merge request.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

wait - it is not ready to merge yet !!!
the new canary camera, doesn't behave normally comparing with the chrome release.

check my recording of canary vs latest chrome (59)
link -
http://www.maspick.co.il/records/canaryissueswithcamera1.webm


open latest chrome in production
Version 59.0.3071.115 (Official Build) (64-bit)

let see how camera works now...
as you can see works smooth and normal display not artifcats!


on canary latest  61.0.3147.0
as you can see delayed motions, and many artifcats on the camera
itself!!!

this can not be used in production.!!!!

many many thanks
Danny

dannymendelmn@: Thanks for the recording, which is super helpful and clear! No question that the camera capture is not working correctly on your configuration using 61.0.3147.0. 

Since the code path that we identified as the cause for the issue where lots of camera models would just show a black video has been deactivated in 61.0.3145.0, there is the possibility that issue you are experiencing is something new. How does video capture behavior on your configuration with versions between 60.0.3092.0 and 61.0.3144.0? Is the the same as with 61.0.3147.0 or different?    

chfremer@: no problem! glad helping as much as possible

as far as i know, 
only between very recent version 61.0.3146 to 61.0.3147 it start working the camera, previous old versions such as you were suggesting
such as 60.0.3092.0 or 61.0.3144.0 didn't show camera at all just black frame container (BTW i'm the creator/reporter of this bug/issue)

to help more specifically, if you can kindly send me a direct link(s) for binary(ies) of specific version(s) you want me to test with my configuration, please let me know.

this behavior also appear on other machines with different camera configuration, my friend andy200...@gmail.com also reported same like me.

i have a feeling it has to do with vast range of cameras configurations

 Issue 738518  has been merged into this issue.

Win10 Chrome Version 61.0.3147.0 canary (64-Bit)
Logitech HD Webcam C270

confirmed working again

My cameras work again as well

These two builds could be the hint where to search:
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/483242/
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/483263/

483242 - camera not working like it was described by this report starter
483263 - camera start working but has video artifacts like is was described in this comment: https://bugs.chromium.org/p/chromium/issues/detail?id=722038#c82

Thanks for updates... Cameras (C920, C615, C270) works fine with Canary new version.

Windows 7 Pro x64 i3,  Logitech HD C270

Thanks for the update.

The camera now produces an image, but I see exactly the same issues as Danny in #82. Looks like red / blue ghosting on a moving image, not at all smooth as in the current release.

I would consider this is still a regression.

I confirm I can see same artifacts. But I do think it's a separate problem as it affects all the cameras: both ones that don't work in M59 and those that do.

Thanks everyone for checking and reporting the results with the latest canaries.

Based on what you have reported, my conclusion is that the change in 61.0.3145.0 (which is the first build that contains r483263), is effective at fixing the issue with cameras just displaying black.

It appears that some of us (but not everyone) are experiencing a new issue (red/blue ghosting) that seems to have sneaked in while the other issue prevented us from noticing. I will open a new bug entry for the investigation of that issue.

In the meantime, I believe we should merge the current fix back into the M60 beta asap. This will reveal whether or not the new issue is already in M60 (red/blue ghosting) or only started in M61. Getting the beta fixed should be our top priority.

Created an entry for the red/blue ghosting issue: https://bugs.chromium.org/p/chromium/issues/detail?id=738928

Everyone who is seeing these symptoms, please post your Webcam model, Windows version, and Chrome version to that new thread.

+bustamante@ for Merge-Review-60.

chfremer@: quick Question:

how to track the "green flash" light with camera first capture as seen here:

http://www.maspick.co.il/records/greetlight.webm

under current "black frame" issue
or the new "red/blue ghosting"
or perhaps would you like to create a new "green light flash" issue?

please advise!

many thanks
Danny

re #95: I believe this is a symptom of the red/blue ghosting issue. Essentially the first frame is all-green because the u and v planes of the yuv image are somehow delayed.

This bug meets the bar for M60 approval. branch:3112

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

commit d2fc9a9acf207842dd2649882f36649a2daaf39e
Author: Christian Fremerey <chfremer@chromium.org>
Date: Thu Jul 06 20:52:03 2017

RELAND: Image Capture win: initialize camera controls lazily

The original CL was reverted due to unhandled initialization
problems with either |camera_control_| or |video_control_|.
This CL corrects that, making InitializeVideoAndCameraControls()
return a boolean that is then checked on the caller site.

PS1 has the original CL verbatim to compare new changes against.

Original CL description ---------------------------------------
ToT initializes |camera_control_| and |video_control_|
during AllocateAndStart(), which causes issues for clients
who just want video capture. This CL corrects this by
delaying initialization of the said member variables to
when they are needed, that is, when calling GetPhotoState()
or SetPhotoOptions().
Original CL: https://chromium-review.googlesource.com/543198

TBR=mcasas@chromium.org

(cherry picked from commit 0591491eb3bd9b7e416ba5dce25bbd667b75bd6a)

Bug:  722038 
Change-Id: I56febecd87e741c3f98f1f915cbd9ee6ec8575fd
Reviewed-on: https://chromium-review.googlesource.com/549956
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#482698}
Reviewed-on: https://chromium-review.googlesource.com/562619
Cr-Commit-Position: refs/branch-heads/3112@{#534}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/d2fc9a9acf207842dd2649882f36649a2daaf39e/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/d2fc9a9acf207842dd2649882f36649a2daaf39e/media/capture/video/win/video_capture_device_win.h

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

commit abef2a84be955f95f499abc7494ef81d41e406c7
Author: Christian Fremerey <chfremer@chromium.org>
Date: Thu Jul 06 20:54:11 2017

ImageCapture: Disable PhotoState collection in Windows

Disable PhotoState collection in Windows because it seems
to prevent normal video capture (see bug).

Disabling the collection of the PhotoState (capabilities and
current settings) also prevents in practice any
setOptions()/applyConstraints() operations since the intended
options/constraints are checked against the valid ranges,
which would be nonexistent if no capabilities were collected.

TBR=mcasas@chromium.org

(cherry picked from commit 6b50cd75ccdc4cc1f15a9edeffbb56fadfca8c53)

Bug:  722038 
Change-Id: I4f98eadc4a486040791eedee280a06c88ca83d1d
Reviewed-on: https://chromium-review.googlesource.com/553525
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#483261}
Reviewed-on: https://chromium-review.googlesource.com/562736
Cr-Commit-Position: refs/branch-heads/3112@{#535}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/abef2a84be955f95f499abc7494ef81d41e406c7/content/browser/image_capture/image_capture_impl.cc

 Issue 739805  has been merged into this issue.

The fix should be available in the M60 betas now (starting with 60.0.3112.0).

Affected beta users, please confirm.

I'm still seeing the 'inactive stream' problem:
60.0.3112.50 (Official Build) beta (64-bit)
Windows 7 x64
Logitech c615

Sorry, my bad, I mixed up the revision numbers.
The fix will be in M60 betas starting with 60.0.3112.59. The current beta release 60.0.3112.50 does not yet include it. Let's wait until an updated beta becomes available.

Verified the fix on Win-10 using Chrome beta version #60.0.3112.66 as per the comment #0. Observed a normal web camera capture / input as expected.
Attaching screen shot for reference.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: webcam.JPG 173 KB

	webcam.JPG 173 KB View Download

Do we have a date yet for this version?

We just shipped 60.3112.66 on Beta channel today, it should be available.

Confirmed as working for me

confirmed working on Win10 Chrome 60.0.3112.66 beta (64-Bit), Logitech C270

I can also confirm it's working now for my setup in Chrome beta.

Confirm working for Beta, Windows 7 Pro x64 i3,  Logitech HD C270

Also confirmed OK on Windows 10 with Logitech 615 camera.

Thank you.

Hi

Thank you very much for testing

fwiw, it's likely this also affects Linux. Since upgrading to Chromium 59 in Arch Linux, I've gotten a couple of reports of webcams not working. One webcam reported as not working is an old Logitech QuickCam Messenger (046d:08da). [1]

If my assumption that retrieving photo capabilities on Linux was added in M59 (compared to M60 for Windows) is correct, then it does seem like it's the same bug as the one discussed here.

Unfortunately, I only have a webcam on my laptop and that one is working fine, so I can't troubleshoot this myself. Any chance a Chromium dev would have the required hardware to try and repro on Linux?

[1] https://bugs.archlinux.org/task/54450

re #114: The issue with the QuickCam Messenger is very likely the same as  issue 739953 , which is unrelated to this one.

Sorry, seems the auto link generation did not work. Here is the link to the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=739953

Thanks for the pointer to the other bug; I'll keep an eye on it (and merge any fixes to our Chromium package in Arch). Sorry for the noise here. :-)

guys please check this bug
https://bugs.chromium.org/p/chromium/issues/detail?id=750431

i didn't get any response so far. perhaps can you escalate it ?

many many thanks 

Funnily enough, this bug affects all the apps which use Electron - e.g. Skype. Version 62 fixes my webcam problems, so now we have to wait for https://github.com/electron/electron/pull/10213 and https://github.com/electron/libchromiumcontent/pull/376 and then for the app vendors to update Electron.

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

commit be9d1264fb2ebfdf9ee0b1307e56aad9b456187a
Author: Réda Housni Alaoui <alaoui.rda@gmail.com>
Date: Wed Apr 18 20:12:24 2018

[Video Capture Win] Enable GetPhotoState call for MediaFoundation implementation

GetPhotoState was disabled on Windows because of  issue 722038 . The issue
only impacts the Video Capture DirectShow implementation.

This prevents video stream from being stopped when
InitializeVideoAndCameraControls fails on DirectShow and let
GetPhotoState calls reach the MediaFoundation implementation.

Bug:  833449 ,  722038 
Change-Id: Ifad3fa1ee86938ee62a306bbf5900bf645a5eb9f
Reviewed-on: https://chromium-review.googlesource.com/1013697
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551800}
[modify] https://crrev.com/be9d1264fb2ebfdf9ee0b1307e56aad9b456187a/content/browser/image_capture/image_capture_impl.cc
[modify] https://crrev.com/be9d1264fb2ebfdf9ee0b1307e56aad9b456187a/media/base/media_switches.cc
[modify] https://crrev.com/be9d1264fb2ebfdf9ee0b1307e56aad9b456187a/media/base/media_switches.h
[modify] https://crrev.com/be9d1264fb2ebfdf9ee0b1307e56aad9b456187a/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/be9d1264fb2ebfdf9ee0b1307e56aad9b456187a/media/capture/video/win/video_capture_device_win.h

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

commit cf6b1f00e622a21669eb808acf9d790d93d4198e
Author: Réda Housni Alaoui <alaoui.rda@gmail.com>
Date: Fri Apr 20 20:51:06 2018

[Video Capture Win] Enable GetPhotoState call for MediaFoundation implementation

GetPhotoState was disabled on Windows because of  issue 722038 . The issue
only impacts the Video Capture DirectShow implementation.

This prevents video stream from being stopped when
InitializeVideoAndCameraControls fails on DirectShow and let
GetPhotoState calls reach the MediaFoundation implementation.

Bug:  833449 ,  722038 
Change-Id: Ifad3fa1ee86938ee62a306bbf5900bf645a5eb9f
Reviewed-on: https://chromium-review.googlesource.com/1013697
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551800}(cherry picked from commit be9d1264fb2ebfdf9ee0b1307e56aad9b456187a)
Reviewed-on: https://chromium-review.googlesource.com/1017820
Cr-Commit-Position: refs/branch-heads/3396@{#173}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/cf6b1f00e622a21669eb808acf9d790d93d4198e/content/browser/image_capture/image_capture_impl.cc
[modify] https://crrev.com/cf6b1f00e622a21669eb808acf9d790d93d4198e/media/base/media_switches.cc
[modify] https://crrev.com/cf6b1f00e622a21669eb808acf9d790d93d4198e/media/base/media_switches.h
[modify] https://crrev.com/cf6b1f00e622a21669eb808acf9d790d93d4198e/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/cf6b1f00e622a21669eb808acf9d790d93d4198e/media/capture/video/win/video_capture_device_win.h

Able to reproduce the issue on win-10 using chrome reported version #60.0.3092.0

Verified the fix on Win-10 using Chrome version #67.0.3396.18 as per the comment #0.
Attaching screen shot for reference.
Observed normal web camera capture / input and no black screen.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 722038.PNG 2.3 MB

	722038.PNG 2.3 MB View Download

Webcam on chrome version 70.0.3538.102 is still showing a black frame.

Tested using the website https://webrtc.github.io/samples/src/content/getusermedia/gum/

Setup: Windows 10, Chrome Version 70.0.3538.102 (Official Build) (64-bit). Webcam: Logitech webcam C615.

This webcam works fine with mozilla firefox version 63.0.3 (64 bit). So I do not suspect the webcam.

Deleted: ChromeWebcamError.png 15.5 KB

	ChromeWebcamError.png 15.5 KB View Download