Issue metadata
Sign in to add a comment
|
Chrome Canary AppRTC Call Shows Camera Artifacts, Possibly Inverted Colors |
||||||||||||||||||||||
Issue descriptionChrome Version: 58.0.3013.0 (Official Build) canary (64-bit) OS: Windows 10 What steps will reproduce the problem? 1. Install Chrome canary with Windows 10 Chrome canary installer 2. Open Powershell App 3. Create a chrome profile directory eg test4 (used in step 4) mkdir C:\> mkdir C:\Users\<user_name>\mytemp\test4 5. Change to directory where Chrome canary is installed: cd "C:\Users\<user_name>\AppData\Local\Google\Chrome SxS\Application" 4. Open a Chrome canary instance with logging enabled: .\chrome.exe --enable-logging --v=1 --vmodule=*/webrtc/*=1 --no-sandbox --user-data-dir=\Users\<user_name>\mytemp\test4 5. In the resultant Chrome canary instance, open a new tab and a join an AppRTC call https://appr.tc/ click "Join" (Allow camera if not already done previously) 6. Delete the tab (click the 'x') 7. Close the Chrome Canary browser (Click 'X' in top right hand corner) 8. Repeat steps 3-5 a few time eg 5-10 times What is the expected result? Step 8: User sees a smooth clear camera video with call control icons What happens instead? Step 8: The web camera video has artifacts (perhaps inverted colors) with call control icons, as shown in the screenshot attachment Other info: The bug is intermittent and you may need to carry out step 8 (above) several times to produce the fault The log file has the line: "Collections of all histograms Histogram: Accessibility.InvertedColors recorded 1 samples, mean = 0.0 (flags = 0x41)" This may or may not be related to the fault
,
Feb 16 2017
,
Feb 16 2017
It looks like there may be some experiment that, when active, somehow leads to inverted colors being used for rendering. At least that would explain the symptoms. The reason it is needed to start with a fresh user profile is probably that this re-rolls the random variables deciding which experiments are active. Since the video capture pipeline does not include the functionality of inverting colors, it is most likely on the render side of things. I am currently trying to find out which experiment may triggers this. Is 58.0.3013.0 the first build where this happens?
,
Feb 16 2017
The log output "Collections of all histograms Histogram: Accessibility.InvertedColors recorded 1 samples, mean = 0.0 (flags = 0x41)" seems to suggest that Accessibility.InvertedColors was NOT active, so maybe it really is unrelated to the actual root cause. jkallar@: Could you do a manual bisect to find which version is the first that shows this issue? It may also be useful to record the Variations entries from chrome://version and see if active Variations correlate with the symptoms.
,
Feb 20 2017
Confirming this issue is happening for me on 58.0.3013.3, I've tried it in a couple different WebRTC apps, same discoloration issues as reported above. Attaching some screen shots for reference. This does not happen on 56 or 57 -- the problem appeared for me on 58.
,
Feb 20 2017
,
Feb 21 2017
Unable to reproduce this issue on Windows 10 with chrome Canary #58.0.3018.0 Followed the steps as per mentioned in the comment #0 and didn't observe any inverted colors on screen. Looks like it is fixed in Issue 691522 . jkallar@ could you please re-try the scenario on Chrome canary #58.0.3018.0 and let us know your observations.
,
Feb 21 2017
Verified (no longer a fault) Google Chrome 58.0.3018.0 (Official Build) canary (64-bit) Revision 5e7216844858ad1d08a70ac7aeef88547db2be7f-refs/heads/master@{#451537} OS Windows JavaScript V8 5.8.244 Flash 25.0.0.113
,
Feb 21 2017
,
Feb 22 2017
As per comment #8 & #9, removing needs-bisect,needs-triage and needs-feedback labels |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jansson@chromium.org
, Feb 16 2017