Issue metadata
Sign in to add a comment
|
chrome.DesktopCapture 'screen' is very low performance on OSX
Reported by
florent....@ubicast.eu,
Mar 16 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce the problem: 1. install https://chrome.google.com/webstore/detail/screen-capturing/ajhifddimkapgcifgcodmmfdlknahffk or similar 2. use chrome.desktopCapture.chooseDesktopMedia(['screen'] to access the desktopCapture api 3. record using MediaRecorder (e.g. using h264) Reproduced on macbook air 2015 (1,6 Ghz Core i5) <-- 1440x900 What is the expected behavior? At least 30 fps capture; note that * capturing the webcam does produce 30 fps 1080p recordings on the same hardware, so this is not an encoding performance issue * on Windows 10 (on i3 Skylake) and Linux (i7), getting solid 30 fps when capturing the screen What went wrong? Capturing the desktop does produce ~15-20 fps recordings. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3325.162 Channel: beta OS Version: 10.13.4 Flash Version: I am creating this ticket to track the OSX-specific performance issue; the windows-specific issue was being tracked (and fixed) by https://bugs.chromium.org/p/chromium/issues/detail?id=466879#c42 which implemented Windows 8' Desktop Duplication API As such, reproduction steps from the other ticket can be used too (see comments at the bottom concerning OSX specifics).
,
Mar 19 2018
,
Mar 20 2018
Tested the issue on chrome reported version 65.0.3325.162 using Mac 10.13.3 with steps mentioned below: 1) Launched chrome reported version and installed the extension with URL: https://chrome.google.com/webstore/detail/screen-capturing/ajhifddimkapgcifgcodmmfdlknahffk 2) Opened Devtools > Console and typed chrome.desktopCapture.chooseDesktopMedia(['screen'] (as provided in Comment#0), system shows errors (find the attached screenshot for the same) @Reporter: Please find the attached screen shot for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which helps us in further triaging it, if possible could you please provide screen cast of excepted behaviour which helps in better understanding. Thanks!
,
Mar 20 2018
Hi Sorry for the wrong reproduction instructions, here is a test html file; remember it needs to be hosted over https, and not displayed within an iframe. The attached page should ask for the desktop (if https://chrome.google.com/webstore/detail/screen-capturing/ajhifddimkapgcifgcodmmfdlknahffk is installed), then record 10 seconds of video, then offer a link to download the mkv file. Running this on Linux/Windows results in a good framerate, and poor on OSX
,
Mar 20 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 20 2018
Here is a recording done on a 2015 13" macbook of a 30 fps video
,
Mar 20 2018
Analyzing the above video with https://github.com/UbiCastTeam/qr-lipsync measures ~ 15-17 fps
,
Mar 20 2018
Here is a recording done on Windows 10 (i3 6100U)
,
Mar 20 2018
Analyzing the windows10 video with https://github.com/UbiCastTeam/qr-lipsync measures 30 fps
,
Mar 23 2018
,
Mar 23 2018
The 15~20 fps of screen capture on Mac is quite as expected. At present capturing one frame of screen will cost about 40ms, varying with screen resolution, in which about 25ms spent in OS API invoking. So it's hard to reach 30fps. I believe that with the below issue solved, https://bugs.chromium.org/p/webrtc/issues/detail?id=8652, 30fps can be achieved.
,
Mar 23 2018
Hi Florent, I confirm above comment #11 though this is possible that you can already get some improvements by passing --webrtc-max-cpu-consumption-percentage-100 (see http://crbug.com/796959 ) |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by guidou@chromium.org
, Mar 16 2018