I've seen other reports on this happening on Chromebits starting in M57. 
+Alberto, who in your team could look into this?

Another report: https://plus.google.com/u/0/111251007721015193414/posts/ZoQuaYGndnz?cfem=1

Same happened to me with my Chromebit.
I bought it 2 weeks ago and with the build the device shipped with (unfortunately didn't note it down), the USB cam was working perfectly.

After installing the update, though, to , the image became red/yellow, over saturated, too bright and with too much contrast. I also notice this gets worse as the camera continues to be on. Feels like the software is trying to compensate the image wrongly.

I tested this with Logitech 270, 170 and 920 as well as Microsoft Cinema Lifecam. Same behavior across the board.


58.0.3029.40 beta
Piattaforma 9334.28.0 (Official Build) beta-channel veyron_mickey
Firmware Google_Veyron_Mickey.6588.197.0


V8
5.8.283.21
User-agent

Mozilla/5.0 (X11; CrOS armv7l 9334.28.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.40 Safari/537.36

Deleted: IMG_20170402_123702_2.jpg 198 KB

	IMG_20170402_123702_2.jpg 198 KB View Download

Deleted: IMG_20170402_124542.jpg 154 KB

	IMG_20170402_124542.jpg 154 KB View Download

Deleted: IMG_20170403_125419.jpg 351 KB

	IMG_20170403_125419.jpg 351 KB View Download

The most likely culprit is a combination between Os/driver and
the routine that resets the user/camera controls to their default
values [1]


[1] https://cs.chromium.org/chromium/src/media/capture/video/linux/v4l2_capture_delegate.cc?sq=package:chromium&dr=C&l=207

Ooops #5 was too fast :-)

resetting the user/camera controls to their default values provided
by UVC suffers from two problems:
- flaky USB or device communications, which makes the driver
 ioctl()s fail in surprising ways (like, saying it has failed
 when having succeeded).
- the USB-provided default value not being accurate or even
 legal.

In this case what we could do is to blacklist this camera model,
by its USB identifier.  

Could anyone dump here the contents of chrome://media-internals/,
"video capture" tab, please?

But it's every camera with the Chromebit ?

Issue 677573 has been merged into this issue.

I've tested it with the C920 and the same behavior is observed.
Also notice this was working previously...

I tested this on a veyron_minnie device with a Logitech C930 and found that the issue started with M57 and somehow disappeared with M59.

I confirmed that the issue is related to the camera settings being reset at [1]. When I commented this out, the symptoms disappeared.

Since there don't seem to be any significant changes in that code between the latest M57 and the earliest M59 builds, I assume something must have changed in the non-Chromium parts of Chromium OS that fixed the issue starting in M59.
It would be nice if we could confirm this theory and understand what made the difference. @posciak: could you help with this please? Who would be the right person to ask about this?

@affected users: If possible, could you please try an M59 build and check if it fixes the problem for your configuration as well?

Missing link at #19: 
[1] https://cs.chromium.org/chromium/src/media/capture/video/linux/v4l2_capture_delegate.cc?sq=package:chromium&dr=C&l=207

I am wondering if, as a temporary mitigation (maybe for M58?), we could store a (static, per-device) flag when the camera settings have been changed via SetPhotoOptions() [1] and then only call ResetUserAndCameraControlsToDefault() at [2] if this flag indicates that it is needed.

@mcasas: What are your thoughts on this?

[1] https://cs.chromium.org/chromium/src/media/capture/video/linux/v4l2_capture_delegate.cc?sq=package:chromium&dr=C&l=641
[2] https://cs.chromium.org/chromium/src/media/capture/video/linux/v4l2_capture_delegate.cc?sq=package:chromium&dr=C&l=207

Tested and working on M59 Dev Channel release.

Bit jumpy but that's just the dev release I expect

Thanks

This issue was observed on Minnie, Jaq and Jerry with M57 and M58.

Verified that it is working on Jerry with M59 59.0.3071.8 / 9460.1.0 dev

Is there an ETA on a fix for this?
Thanks

The issue appears to be fixed in M59, which is currently in beta.
With M58 already in stable, we may not be able to get a fix in for M58 anymore.

If you get the chance, could you please check on M59 and see if it fixes the issue for you?

I have to stay on the Dev channel OS59 for camera to work.

Dev channel causes random reboots though.

So 1 month without a decent working device coming up. 

Tried the Beta channel is gave me OS58 still.

Since we won't be able to get a fix for this into M58, I am marking this as won't fix.

just to clarify, is this fix coming to a later release?

It appears that the issue is fixed by newer firmware in M59.
If you can, please try M59 and check if it works for your configuration. If it doesn't, please let me know and I'll reopen this.

I'll check it out and let you know.

Tentatively updating the title.

Just to clarify, received version 59 but didn't solve anything.
Maybe just made the webcam more unreliable (shutting the video off even when the webcam is on sometimes).

This is becoming really frustrating.
Basically one day after purchasing the product it became totally useless and no fix after a quarter. Terrible customer experience.
Pix attached.

Any hope this will be fixed?

Deleted: IMG_20170612_120604.jpg 7.3 MB

	IMG_20170612_120604.jpg 7.3 MB View Download

Sorry, attached only one image. Attaching the other here:

Deleted: IMG_20170612_120515.jpg 3.9 MB

	IMG_20170612_120515.jpg 3.9 MB View Download

59 for me has issues with meet, the picture, although better, is slow and jumpy, and I get dropped off after around 15 minutes.

We were looking to adopt this device across the business, but I've had no option other than to delay that project.

Actually, I've checked again using also meets and I can confirm now, after my camera's LED powers up I directly get a message saying 'camera error' in both Hangouts and Meets.

So I guess we went from good to bad to worse.

leonardo.rossetti@: I am sorry to hear that 59 didn't solve the issue for you. In #4, you reported that you tried several different webcams. Do they still all show the same symptoms? To make sure there is no separate issue with Hangouts or Meets, please confirm that the issue reproduces when checking the video here: https://webrtc.github.io/samples/src/content/getusermedia/gum/ 
If it does, could you please post the names and usb ids of the webcams you tried? This information can be found at chrome://media-internals in the VideoCapture tab and should look similar to this (example for a Logitech C930): "Logitech Webcam C930e (046d:0843)".

graemehendry@: According to #22, the issue with the colors and contrast you reported in #1 was fixed for you with 59. It sounds like the issues you mention in #34 are different. Could you please confirm? 

Ok, so:
- the issue is happening also at the test URL you provided
- the webcam I tried is Microsoft® LifeCam Cinema(TM) (045e:075d)
- can't try more as I've already accumulated several credit cards at local retailers (in Italy they won't refund you if you return an item) and can't spend more money on of for this device
- I am attaching further details including a picture of the room and an image of the room through webcam
- if the above wasn't enough to make me regret the purchase, now hangouts doesn't even wanna use my cam (the camera app and other sites use it normally)

I am not able to estimate how many Chromebits were sold and what % of them uses webcams and have this issue but I fear this issue will never be prioritized and solved. disappointing given the lifecycle of these products. And that it was perfectly working when purchased.

Files attached here:

Deleted: IMG_20170615_153205.jpg 3.1 MB

	IMG_20170615_153205.jpg 3.1 MB View Download

Deleted: download_20170615_154337.png 138 KB

	download_20170615_154337.png 138 KB View Download

Deleted: download_20170615_154339.png 1.3 MB

	download_20170615_154339.png 1.3 MB View Download

We are currently trying to repro to confirm that 59 did indeed not fix the issue for all devices. Preliminary raising priority to 1.

I just tested on a Chromebit (veyron_mickey) running 59.0.3071.91 and testing https://webrtc.github.io/samples/src/content/devices/input-output/ with the following cameras:

Logitech UVC Camera (046d:0990)
Logitech C920 (046d:082d)
Logitech C930e (046d:0843)
Microsoft Lifecam VX-200 (045e:0761)
Microsoft Lifecam HD-3000 (045e:0779)

The result is that the Logitech cameras appear to work fine, but the Microsoft ones only delivered a black image. For the VX-200 the black image resized itself after about 5 seconds. For the HD-3000 it stayed at the default.

Unless this is a new issue, it is likely that M59 fixed the symptoms for the Logitech cameras but not for the Microsoft ones.

There is an existing issue for Blank video with Microsoft camera in  https://webrtc.github.io/samples/src/content/devices/input-output/ page : https://bugs.chromium.org/p/chromium/issues/detail?id=593513 

Cool. Let me reiterate this was working perfectly with Chromebit just out of the box.

Thanks!

I did more tests on the Chromebit (veyron_mickey) with the same set of cameras 
listed in #40 and the following software versions:

Chrome OS Version  Chrome Version   Channel
8872.76.0          55.0.2883.105    Stable
9000.97.0          56.0.2924.121    Stable
9202.64.0          57.0.2987.146    Stable
9334.74.0          58.0.3029.145    Stable
9460.60.0          59.0.3071.91     Beta
9592.22.00         60.0.3112.34     Beta
9657.0.0           61.0.3113.0      Dev
9657.0.0           M61 local build with image capture controls disabled

Some interesting things I learned:

1.) The LifeCam VC-2000 worked on neither of the builds.
2.) The Logitech cameras worked fine on all builds except for Chrome 57 where 
    they had the issue that was originally reported here. The 58 build I tested 
    did not have that issue. Maybe it was a never version of 58 that already 
    had fixes.
3.) The LifeCam HD-3000 does not work when testing with 
    https://webrtc.github.io/samples/src/content/devices/input-output/
    But it does work when testing with 
    https://webrtc.github.io/samples/src/content/getusermedia/gum/
4.) The LifeCam HD-3000 worked fine when I tested builds in the following order:
    61, 58, 56, 55. When I tried 57 after that, it showed the same symptoms as 
    the other cameras. But different from them, it did not recover when I moved 
    on to 59, 60, and even when I went back to the 61 build where it had worked 
    before. The image was always too bright. Sometimes it started out okay but 
    then quickly adjusted back to being too bright. I tried using the camera 
    on a Linux desktop, on a MacBook (with Skype) and a Windows 10 laptop 
    (Camera app) and it still had that issue. By adjusting the camera brightness
    control in the Win 10 Camera app, I could get it back to a proper picture.
    However, after restarting the app the setting would be back to too bright.
    It almost appears like a default value was overwritten in some persistent 
    camera memory.

Hello there, I was just wondering if there was any update on this or if
this won't fix.

Leo

Based on the tests in #43, the reported issue (which caused all webcams I tested to use wrong settings for their controls) appears to have been fixed with the Chrome OS versions 9460.1.0 or higher.

The LifeCam VC-2000 does not appear to have worked in earlier versions as well, so it does not look like there is a regression there.

As a result of the above considerations, I am going to mark the tracked issue as fixed. 

leonard.rossetti@:
I acknowledge your reports of still having seen issues in Chrome 59 with one particular LifeCam model, but based on the tests in #43 I have to conclude that these have probably been caused by something else, e.g. either the Chrome OS version that came with the updated Chrome did not yet have the fix (i.e. a Chrome OS version < 9460.1.0), or the camera did not refresh its default values.

It sounded like you may no longer have access to a Chromebit, but in case you do and still see a similar issue, please open a new bug entry for a separate investigation.

I do have access to a Chromebit and:
1. Still lifecam doesn't work properly with that ( I attached all the
details just a couple of weeks ago)
2. The webcam used to work perfectly. There has been a regression.

re #46: I filed this as new issue tracker entry:  https://crbug.com/739407