getUserMedia / Application Window - stream stops updating in some applications |
||||||||||||||||
Issue descriptionChrome Version: 58.0.3029.110 (Official Build) (64-bit) OS: macOS Sierra 10.12.5 Note that a very similar or identical bug has been reported by several users of CrankWheel, usually on Windows platforms but now also on Mac platforms. These reports have come in for a while (maybe 6-9 months), but more frequently in the last several weeks. They are typically associated with Microsoft Office on Windows, but other Windows programs have been mentioned (including in-house apps developed in .NET) and now this latest report on a Mac which we find reproduces quite consistently and easily. What steps will reproduce the problem? (1) Download ChicagoAgent 3.0 lite for the Mac from http://www.chicagoagent.com/ (2) Go through the registration process and choose "ChicagoAgent lite" and "no sales rep" in the last steps of the registration process (3) Use CrankWheel, appear.in or another tool relying on getUserMedia to share the application window of the ChicagoAgent app, and drill down a couple of levels deep as in the video linked to below. What is the expected result? Should be able to share this application window for as long as you like. What happens instead? It's as if the video stream stops updating at some point, usually consistent with a large update (like a full screen refresh) happening in the app. In certain cases it seems also possible to get the video stream to terminate by taking an action in the app. See a screen recording I made to show this happen in both CrankWheel and appear.in: http://recordit.co/G2VvU0tdBC
,
Jun 23 2017
Can you get the chrome://webrtc-internals information for a call like this? Especially interesting are the stats graphs for video receive and send, where you can see frame rate coming from capturer (googFrameRateInput) sent (googFrameRateSent), received (googFrameRateReceived)
,
Jun 23 2017
Hi niklase@! I'm happy to grab any reports that I can as this reproduces easily for myself and one of my team members. I think I may need some further instructions to get those stats graphs; all I'm seeing on chrome://webrtc-internals is a list of the GetUserMedia requests, and a way to do diagnostic recording for audio and for packets and events, neither of which seem to generate files.
,
Jun 23 2017
When you have an active session you'll see another tab besides "GetUserMedia Requests" with the page name. There you can find and expand the "Stats graphs for XXX" to see what's going on. You can also download the stats under Create Dump -> "Download the peerconnection updates and stats data". But looking at the graphs is imo the best way to get a quick view of what's going on.
,
Jun 23 2017
Thanks niklase, I figured out that I need to have an ongoing peer-to-peer connection to see it. We don't have that in CrankWheel (custom transport), but once I attached a viewer to an appear.in session I see it. I'm attaching several screen shots showing the send and receive video stats graphs for one end of the connection. I opened the connection, then almost immediately reproduced the problem (as seen on my full screen screenshot), then waited maybe 20 seconds before taking the screenshots. I'm also attaching the text dump which I downloaded.
,
Jun 23 2017
Thanks, it looks like it's the actual window scraping that stops for some reason, Brave can you take a look?
,
Jun 26 2017
Here is a video of the same (or similar) bug reproducing on Windows, with Microsoft Word. The repro with that does not seem to be as consistent, we've heard from users who were seeing this bug one day and then not the next. https://share.viewedit.com/q3cP4cHVRHM8DhZ3QpTxrU
,
Jun 26 2017
The issue on OSX with ChicagoAgent app is WAI. It's the ChicagoAgent app's problem that it doesn't draw all the content within same window with same window ID. - When you launch the app and start to present its start page with window ID1. - Then you click 'Buyer'->'Quick Estimate' to get a new page. At this time, the presentation will freeze at previous page. It's because the quick estimate page is within window ID2. - The interesting thing is when you click 'Back' to go back to the start page again, it's within window ID3. And since the original window ID1 is destroyed, window sharing will be terminated because of this. I can't test with Microsoft Office (which is not available here) on Windows to see if it's based on the same reason(just pay attention that if any new window is created after presenting). If there is consistent way to reproduce it with other apps on Windows, please file another issue and I'll have a look. And this issue will be closed for now.
,
Jun 27 2017
Thanks braveyao@, that makes sense. We'll see if we can find again a consistent repro on Windows and check if the same thing is happening with the window actually changing. |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by joi@chromium.org
, Jun 23 2017