WebRTC screen share flickering
Reported by
skadb...@cyviz.com,
Dec 6 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: Using chrome.desktopCapture.chooseDesktopMedia, share a fullscreen source. What is the expected behavior? Screen is shared with no visual artifacts. What went wrong? About 5-10% of the times, the video initially flickers between the actual image and one that is mostly black. Once areas and/or windows are selected, the affected areas are updated and drawn as intended. I've attached three GIF animations which are renditions of the effect. While the issue is quickly resolved by moving around a few windows or restarting the stream, the flicker is visually disturbing and are perceived as something being broken. Did this work before? N/A Does this work in other browsers? N/A Chrome version: Version 62.0.3202.94 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: N/A
,
Dec 18 2017
Is the flickering only visible locally or does it also transmit to the other side?
,
Dec 19 2017
When present, the flicker is visible on both the sending and receiving side.
,
Dec 19 2017
To clarify, on the sending side, the flicker is present in the outgoing video preview, not the actual desktop. I took a second look at the previously reported bugs and found https://bugs.chromium.org/p/chromium/issues/detail?id=678203. While the effect is similar, there is a small difference. The video flicker in the issue I reported never degrades once the affected areas have been fixed. Additionally, it flickers to black, not the background.
,
Dec 21 2017
There has been some fixes done to the Windows capturer, can you verify that this still happens on Chrome 63 or newer?
,
Jan 3 2018
Yes, I was able to reproduce the bug on Chrome 63.0.3239.108
,
Jan 3 2018
Thank you for providing more feedback. Adding requester "niklase@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 4 2018
Unable to reproduce this issue on reported version 62.0.3202.94 and on latest stable 63.0.3239.108 using two windows 10 machines with steps mentioned below. 1. Installed https://chrome.google.com/webstore/detail/crankwheel-screen-sharing/dooinopjfnhlmmdkdepajfipfhlcmjgp ans signed with valid credentials. 2. Clicked on Fullscreen button and started screenshare. shared meeting id and opened in another win 10 machine 3. Observed no flickering of screen on both machines. @Reporter: Could you please let us know by using which extension you checked the issue. This would help in further triaging of the issue. Thanks!
,
Jan 4 2018
I was unable to reproduce the bug with the suggested extension. Unlike our webrtc application, it appears to use a custom websockets server to produce base64 screenshots as preview, which is sent back to the user. I believe it's essential to use the html5 blob representation of the video stream to showcase the bug. (The extension was also extremely buggy, not sharing video when displaying preview, sharing video while appearing to be off the call, etc.) I've attached a new (slightly modified) screenshot of the reproduced bug using Windows 10, Chrome 63.0.3239.108, https://www.webrtc-experiment.com/screen-sharing and it's associated plugin, demonstrating the partially working video stream, as rendered in "webrtc_flicker_3.gif".
,
Jan 4 2018
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18 2018
Unable to reproduce this issue on reported version 62.0.3202.94 on windows 10 with steps mentioned below. 1. Added https://www.webrtc-experiment.com/screen-sharing extension and shared screen 2. Unable to see any flicker on sending side,receiving side and outgoing video preview. @Reporter: Could you please check the video and let us know if we miss anything.This would help in further triaging of the issue.
,
Jan 18 2018
The bug appears to be random, but I've reproduced on multiple machines, usually with failure rate of 1-2 in 20 attempts. I still don't know what the conditions are, but I suspect minimum of two monitors may be a requirement. I managed to capture a video of the bug, please let me know if there is any technical information I can collect to help debug the issue.
,
Jan 18 2018
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 19 2018
,
Jan 20 2018
skadberg@, I noticed that you have multiple monitors connected, through a dock station I suppose? Maybe it's related to https://bugs.chromium.org/p/chromium/issues/detail?id=764258. I can't reproduce the problem with my setup: X1 Yoga V2(Win10) + Thunderbolt 3 Dock. Is a USB dock station in your tests? Some questions: - without a dock station, can you reproduce this problem, with or without an external monitor? - with thunderbolt dock setup, can you reproduce this problem?
,
Jan 22 2018
No, the none of the systems use any type of USB or Thunderbolt adapter. The system the video was taken from is a 3-monitor setup using a nVidia GeForce GTX 660 Ti. The other system I have access is a 2-monitor setup using Intel HD Graphics 520. That said, it may still be related. I can also reproduce the bug you linked, as outlined in my duplicate bug report here https://bugs.chromium.org/p/chromium/issues/detail?id=796078
,
Jan 22 2018
OK. Interesting. So you can also reproduce this problem with 1-monitor and 2-monitor cases on those machines? I'd like to simplify the replication criteria. BTW: if there is other driver versions to test with?
,
Jan 23 2018
Upgrading nVidia driver from 373.06 to 390.65 had no effect. After further testing, it's evident that multiple monitors is required. Specifically, I am unable to reproduce the bug on the primary monitor. The location of the taskbar, desktop icons, windows or any other content does not seem to matter. As demonstrated above, selecting an area or dragging a window fixes the flickering in a limited region. Certain actions, such as opening the start menu fixes the flickering for the entire screen. I suspect that the appearance of dialog "Example is sharing your screen with example.com" is reliably fixing the issue on the primary screen before it can be observed.
,
Jan 23 2018
Thanks for testing! Finally I did see the reproduction locally. Still have no luck with my X1 Yoga V2(Win10) + Thunderbolt 3 Dock + 2 external monitors so far. With 1 or 2 monitors connected to my windows desktop, still can't reproduce it so far. Managed to connect 3 monitors to my windows desktop. And finally I get: It's more easy to see the problem at capturing the 3rd monitor. It's more hard to see the problem at capturing the 2nd monitor. No reproduction with capturing the 1st monitor yet. Opening start menu on that monitor will fix the flickering. It's hard to say if it's a problem in Chrome or in OS(most likely) yet and what we can do here. Will investigate more when there is cycle.
,
Mar 5 2018
,
Aug 1
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by guidou@chromium.org
, Dec 8 2017