Logs here : https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/812529

Issue also reproducible in Chromebox Guado. 

It may be also that Its broken in M-65. testing this in M-64 and I will get back to you on this. 

Yes, It works in M-64 Indeed. Attached screenshot. 

(Hope I'm adding the right people here...)

In chrome book, when we open the camera (native app) without any external cameras, feed keeps flickering. It seems like a regression. Tried to switch to stable build and this issue is not observed in it.

Reproduced in Winky and Reks. (Possible in other chrome books too)

65.0.3325.65 / 10323.30.0 (Reproducible)
64.0.3282.144 / 10176.68.0 (Not reproducible)

I have opened a new bug for comment 7. Feel free to track it using https://bugs.chromium.org/p/chromium/issues/detail?id=813019

Looking at the screenshots you uploaded, it is the camera app feed and not the screen that goes black.
Before it goes black do you see any expected video feed from the 4K camera?
How consistent is this?

Can you generate full log at chrome://net-internals/#chromeos, and upload to same gs location after you reproduce again?

+ few folks from CFM team

Does this affect bluestreak setups with huddly 4k camera as well?

#11 @Kalin

Hi, I have attached the logs as requested. As soon as I open the camera, I could see only a buffering gif (with the blacked out screen). The camera feed is not observed even for a second. Lights on the camera is on though. 

This is 100% reproducible. Feel free to ask if you need any help. 

Hi rantonysamy@,
I am unable to open the log file (debug-logs_20180219-120858). What file format is it?

BTW, can you capture the console logs of the chrome camera app? After launching the app, you can go to chrome://extension in the browser and click on "views/main.html" in the camera app section. Chrome dev tool would pop up. You can see the console logs in "console" tab in the tool.

Hi Shenghao,

I think its a .zip file. When we unzip it, it has many files in it. I have renamed the file name now. (Note: For some reason when we download the file, it renames with a random name). 

Thanks for pointing it out.

Kindly see the new logs from camera console (camera_console_panther_65.0.3325.65.log)

Deleted: camera_console_panther_65.0.3325.65.log 1.0 KB

camera_console_panther_65.0.3325.65.log 1.0 KB View Download

Deleted: Screenshot 2018-02-21 at 9.40.46 AM.png 1.2 MB

	Screenshot 2018-02-21 at 9.40.46 AM.png 1.2 MB View Download

Hi,

The log files in https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/812529 can't be opened with "unzip" command. Could you share the plain text file with google drive? 

Sure I will get back to you with the plain text file. 

and It will take some time (until i get back to work tomorrow). check you can find some other ways to open it / take someones help on this. (feel free to assign yourself as well).

Adding the .zip extension on mac makes it possible to use the the built in extraction tool, I suspect it also supports tar.gz etc which is probably more likely since this is ChromeOS.

Hi Shenghao: I have unzipped it and uploaded in the same weblink. (Folder names: Log, Log2). https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/812529 

I can share it via email too.

I suspect that the camera steam can't be opened because we specify facingMode=user in https://chromium-review.googlesource.com/c/apps/camera/+/656919/5/src/js/views/camera.js#2251

I will need to get an external camera to verify it.

I tested another Logitech webcam (Logitech c615) on panther 10323.39.0 and the bug is not reproducible.
I think the bug only affect some specific webcams. Lowering priority to P2.
I will buy the exactly webcam to continue debug.

Sorry about the slow response time, I was side-tracked by another task.

The 4k camera issue has a different root cause and should be discussed in a new crbug.  

I am actively working on *THIS* issue, *NOT* the 4k camera problem.  
I created a new  issue 821553 

I moved comments 25-34 to that other issue.

Oh, geez. I just realized I messed this up. This is not the crbug I though it was. Got it confused with  issue 807974 .

This should not have been assigned to me. I know nothing about cameras or the media stack.  In fact I don't even know who this should be re-assigned to.

Putting back the comments I moved by error:

Comment 25 by vasanthakumar@chromium.org, Feb 27
Delete comment ⚐
@Shenghao: The camera we used is a 4K Camera. This issue could be reproducible for all 4K cameras. 

Feel free to try with other models with 4K (if possible). 
Comment 26 by bhthompson@google.com, Mar 7 (5 days ago)
Delete comment ⚐
This bug is marked as blocking 65 stable, which is going to try to promote next week, any chance we can get a fix this week?
Comment 27 by shenghao@chromium.org, Mar 9 (4 days ago)
Delete comment ⚐
Cc: shenghao@chromium.org
Owner: junov@chromium.org
I tested the exact webcam (Logitech BRIO 4K) on cyan with 10323.30.0. The bug is not reproducible, while on panther it is reproducible.

I think it has to do with the chrome media stack changes between 65.0.3325.65 / 10323.30.0 and 64.0.3282.144 / 10176.68.0. Chrome camera app is the same, but the former reproduces the bug while the latter doesn't.

junov@,
Could you take a look or assign to proper person?


Comment 28 by bhthompson@google.com, Yesterday (27 hours ago)
Delete comment ⚐
Labels: -Pri-2 Pri-0
This needs to be fixed today, or we need to reclassify it as non blocking.

Upping priority to reflect the release schedule.
Comment 29 by tovep@chromium.org, Today (3 hours ago)
Delete comment ⚐
Labels: -Pri-0 -ReleaseBlock-Stable ReleaseBlock-StableCFM Pri-1
I don't think we should block the general ChromeOS rollout on this, but we should really see what we can do about this issue before rolling out to CfMs.

Junov, are you working on this?
Comment 30 by tovep@chromium.org, Today (3 hours ago)
Delete comment ⚐
Labels: Hotrod-Platform-Tracking Proj-Hotrod
Comment 31 by tovep@chromium.org, Today (3 hours ago)
Delete comment ⚐
Labels: ReleaseBlock-Stable
I think I'm adding back the ReleaseBlock-Stable.

I believe that it is blocking a stable release on CfMs, but we can keep the CfMs pinned to 64 until it is resolved even if a ChromeOS stable release is done today with this problem.

However, I can't judge if this is a blocker for ChromeOS in general.  Who can make that judgement call?

(Please leave the ReleaseBlock-StableCFM label even if the ReleaseBlock-Stable label is removed.)
Comment 32 by tovep@chromium.org, Today (3 hours ago)
Delete comment ⚐
Labels: -Pri-1 Pri-0
Comment 33 by bhthompson@google.com, Today (2 hours ago)
Delete comment ⚐
We should certainly try to fix this, but using an external 4k USB camera is a somewhat obscure use case for the bulk of the fleet, the majority of the Chrome OS devices out there have built in camera.

If we get a fix we would merge it, but if it comes down to it we may punt the bug, we still have some time, if we can get a fix today or early tomorrow we can still make the first stable RC (last nights build has other blockers in it we need to clear). 
Comment 34 by tovep@chromium.org, Today (108 minutes ago)
Delete comment ⚐
From what I read above it seems reproducible on M65 but not M64.

Who can bisect and find the breaking change?
 

Assign to emircan@ in hope to route to relevant person.

fwiw, I tried the repro steps with a Logitech Meetup 4k camera and the Camera app in Chrome OS didn't get a camera feed in either M64 or M63. Might be different for other cameras, though.

Has anyone tested if this affects CfMs?

The first note about getusermedia in the original report indicates that CfMs might be unaffected.

Re# 44, the bug is about the native camera app (not sure what this app is based on) and a specific 4k camera. I wonder what resolution it tries to use?

Hangouts uses Chrome and thus getUserMedia and it works fine there however appear.in and apprtc (and Hangouts I guess) request 720p or less by default. 

I wonder the camera works in Chrome on a panther at 4k? https://webrtc.github.io/samples/src/content/getusermedia/resolution/ goes up to 8k.

Ref #45: In Chrome, It works fine in the test page - upto 4K. Its a native camera only issue. 

Yes, I tested the following versions on a panther CfM with the Meetup camera:

65.0.3325.65 / 10323.30.0
- Meetup camera works in Hangouts Meet
- Meetup camera does not work in camera App
- C920 works in camera app
64.0.3282.144 / 10176.68.0 
- Meetup camera works in Hangouts Meet

Thus, I do not think this is a blocker for CfMs.

I tested with 2 versions of CCA: 4.8 (the current public one) and 4.7 (released on 06/21/2017) on the following CrOS versions

R65-10179.0.0
R64-10106.0.0
R63-10009.0.0
R62-9807.0.0

All of them show black preview.

It seems that the bug exists for a very long time and is not a recent regression. Should we not block the release on it?

Thanks for the update, that sounds like we should not block on it.

If I understand correctly that the symptom is that a 4k camera works in Chrome via https://webrtc.github.io/samples/src/content/getusermedia/resolution/ but not in a Chromebox native camera app, then I am not the right owner for this.

I am not familiar with the Chromebox native camera app. Is that based on the Chrome video capture stack at all?

Unassigning to get this back to triage for Platform>Apps>Camera

tfiga@ could you help triage this, please?

The Chromebox native camera app is just the normal Chrome camera app we have in every CrOS devices. It's based on JS APIs, so yes, it's based on Chrome video capture stack.

re #52: Thanks. In that case I am probably the right owner and will see if I can find out what is going on.

Ping!

Duped the wrong issues. Reopening again.

This issue is still available in M67. 67.0.3383.0 / 10539.0.0

Ping!

 Issue 803443  has been merged into this issue.

I believe this is an issue with the UVC driver in older kernels. Cyan works because it has 3.18 kernel. We found that this issue seems to reproduce in 3.14 and earlier kernels. 

This problem was not reproduced on Guado (67.0.3383.0/10539.0.0) with Huddly GO, which is not a 4K camera.

We got a Logitech Brio 4K camera and Keiichi was able to do further testing. The observations are the same as #50.

The camera itself seems to be working fine, both in the demo page and Chrome OS Camera app in video capture mode. However, Chrome OS Camera app in still capture mode goes black.

I'd suspect this being a Chrome OS Camera app bug, so this goes to shenghao@.

I did futher testing.
The camera app worked fine when I connected the 4K camera to Guado via a USB2.0 hub.

I mean
not work: [Guado: USB3.0 port] -- [4K Camera]
work:     [Guado: USB3.0 port] -- [USB2.0 hub] -- [4K Camera]

I used Targus ACH115EU as the USB2.0 hub, and the version is 67.0.3383.0.

According to #67, I would say this is not an app problem though.
Unassigning myself.

Thank you Shenghao and keeichiw.

Can anyone help triage this issue to the right team/person? Thank you!

#67, Are you sure that simply connecting the camera in USB 2.0 mode doesn't expose 4K mode anymore and app bug doesn't trigger?

When this problem is happening, I got the following message from dmesg:
uvcvideo: Marking buffer as bad (error bit set).

So, I think a problem is in kernel side.
ition, I confirmed that this problem is also reproduced on samus, but not on caroline.
This supports #61. I think v3.14 kernel has some problems related high resolution video feed.
Thus, it might be useful to investigate patches added between v3.14 and v3.18.