Issue metadata
Sign in to add a comment
|
tabCapture Lag
Reported by
vi...@useloom.com,
Apr 23 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Steps to reproduce the problem: 1. Record a tabCapture stream via the MediaRecorder 2. Observe resulting recording is very laggy 3. Example video: https://stage.useloom.com/share/8efaf1b26d2c4b59a58bb65279703cd8 What is the expected behavior? The video should not be this laggy. Example of laggy video: https://stage.useloom.com/share/8efaf1b26d2c4b59a58bb65279703cd8 What went wrong? We've been doing tab recordings with Loom (useloom.com) for a long time now. We noticed a major regression in the frame redraw of our video camera bubble in the latest version of Chrome (66). We place a camera bubble in the tab and when the tab gets recorded, so does that bubble. Here is an example video showing how bad the problem is: https://stage.useloom.com/share/8efaf1b26d2c4b59a58bb65279703cd8 Did this work before? Yes Does this work in other browsers? N/A Chrome version: 66.0.3359.117 Channel: stable OS Version: OS X 10.13.4 Flash Version:
,
Apr 24 2018
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #66.0.3359.117 but the same is not reproducible in the latest canary #68.0.3404.0. Reverse Bisect Information: ===================== Good build: 67.0.3377.0 Bad Build : 67.0.3375.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/a4fb5a0a223bcb625ae11c75b1ee58e4f46cc1d5..fab9f78151c81b9243405e6b8b815234a430f627 From the above change log suspecting below change Change-Id: I81253b94800f31fe8f4379395bec2fda119ebf9a Reviewed-on: https://chromium-review.googlesource.com/967601 miu@ - Could you please check and merge the fix to M-66 if it is a valid candidate. Adding label RBS as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Apr 26 2018
Vinay, it looks like this issue was already fixed for Chrome 67 (see bug 809867 ), which is planned for stable release in ~6 weeks. The problem manifests when display updates are only occurring within the sub-frames of captured web pages (generally, an iframe within the web page being captured). Given that M66's release this week has revealed that I gravely underestimated the impact of the bug, I have requested that the fix be merged back to M66 (in bug 809867 ).
,
Apr 26 2018
AWESOME! Thank you so much! Would you mind updating this when it does get merged back?
,
Apr 26 2018
BTW--Just to make sure the issue is actually fixed for your use case: Would you mind doing a quick sanity-check with Chrome Canary? (https://www.google.com/chrome/browser/canary.html)
,
Apr 26 2018
confirmed that it's working flawlessly in Canary and is not working in M66. :-)
,
Apr 30 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Apr 24 2018