Issue 466879 in chromium: chrome.DesktopCapture 'screen' is very low performance

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Bug OS-Windows

New issue 466879 by leighton...@gmail.com: chrome.DesktopCapture 'screen'
is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce the problem:
1. Create an extension to do desktop capture for a WebRTC getUserMedia
request.

2. Use chrome.desktopCapture.chooseDesktopMedia(['screen'] to access the
desktopCapture api

3. Track performance using chrome://webrtc-internals

4. (Optional) compare with performance using
chrome.desktopCapture.chooseDesktopMedia(['window']

What is the expected behavior?
Chrome DesktopCapture 'screen' will capture a Windows7 desktop at between
20fps and 30fps.

(desktopCapture-'window' works at up to 60fps at 1920x1080)

What went wrong?
Capture fluctuates between 10-15fps.

Did this work before? Yes Pre - Chrome38 - previous versions of this API
(going back chrome://flags days) worked at ~25fps consistently.

Chrome version: 41.0.2272.89 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 17.0 r0

If resources are a concern there should be an option to allow Chrome to use
more resources for higher rate capture.

Also note that WebRTC / DesktopCapture 'Window' are happy to send a 1080p30
stream at 2Mbps, no problem at all!

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Labels: Needs-Feedback

Comment #1 on issue 466879 by durga.be...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

leighton.carr@ : Thanks for the issue.Can you please provide a sample
extension to reproduce the issue from QA end to further triage it.

[chro...@googlecode.com]

Comment #2 on issue 466879 by jan...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

durga.beheraw@ @You should be able to use the desktop capture extension
example in the WebRTC github repo:
https://github.com/webrtc/samples/tree/master/src/content/getusermedia/desktopcapture.

[chro...@googlecode.com]

Comment #3 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Hi,

Here are the files from the extension. I add them via developer mode since
all my work is on work intranets (no or limited internet access).

Cheers,
Leighton.

Attachments:
lg_background.js 788 bytes
lg_content.js 816 bytes
icon.png 1.6 KB
manifest.json 690 bytes

[chro...@googlecode.com]

Comment #4 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Here are some screenshots of a second performance test I've run
between 'screen' and 'window', from the point of view of both the sender
and the viewer. Hope it helps!

Attachments:
screen_sendergraph.PNG 130 KB
screen_senderstats.PNG 44.8 KB
screen_viewergraph.PNG 147 KB
screen_viewerstats.PNG 40.7 KB
window_sendergraph.PNG 113 KB
window_senderstats.PNG 45.6 KB
window_viewergraph.PNG 131 KB
window_viewerstats.PNG 42.6 KB

[chro...@googlecode.com]

Updates:
Cc: mflo...@chromium.org tnak...@chromium.org
Labels: -Needs-Feedback Cr-Blink-GetUserMedia-Desktop Cr-Blink-Webrtc-Video

Comment #5 on issue 466879 by tnak...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Cc: ji...@chromium.org

Comment #6 on issue 466879 by jan...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

leighton.carr@ Thank your for the screenshots, it's clear that there is a
performance difference in your case. We will take a look.

[chro...@googlecode.com]

Updates:
Status: Assigned

Comment #8 on issue 466879 by smok...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Changing the status to assigned so that issue can be triaged further.

[chro...@googlecode.com]

Comment #11 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Is there a problem with the math in the CPU limiter? I can't get remotely
close to 50%.

I ran up both the Desktop and the Window capturer, both capturing a full HD
video (transformers trailer playing in VLC), and sending the stream via
WebRTC to a viewer on the same computer.

You can see screenshots of CPU usage with both the Desktop and Window.
Desktop never went above 10% for any Chrome process, whereas Window had one
sitting up closer to 20%.

If this is really the issue, then I'd suggest throttling to 10% CPU is
vastly over aggressive for the Desktop capturer, and it should be raised
closer to 50%.

Attachments:
CPU_Desktop.png 629 KB
CPU_Window.png 431 KB

[chro...@googlecode.com]

Comment #12 on issue 466879 by rbl...@jupiter.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

As currently implemented, the CPU limiter is based on how long it takes for
a capture to complete (using one thread running on one CPU). For a system
with multiple CPUs (most modern PCs) this means the throttle will limit the
capture rate to a very low system CPU usage, specifically no more than half
of one CPU.

[chro...@googlecode.com]

Comment #13 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

So 12.5% is the hard limit then? Seems over aggressive given 4 cores has
been the standard for a while now. Do you happen to know what sort of CPU
limit gets you to 30fps on your i5-2450m?

[chro...@googlecode.com]

Comment #20 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Well the problem on Windows (as I understand it) is that if you are doing a
standard D3D capture then you have to wait for Aero to sync up its draw for
all of the windows, which causes a timing issue for getting all of them.
You essentially have to wait for DWM to get around to redrawing all of the
windows individually before you complete the frame.

A single window capture can probably just pull the current render from the
DWM api, or at least it only has to wait for the redraw for one window.

The point I was trying to make is that even taking that into consideration
we should be seeing more that 10-15fps, and there is no point having such a
naive CPU throttling algorithm (as you pointed out).

The other point is that there are other ways to do screen capture. I don't
know heaps about it, but it's pretty clear that at least one of those
methods works better than whatever API chrome uses (Bitblt?), and that this
is surely important enough to warrant a bit more than a dismissive 'it
can't be done'.

[chro...@googlecode.com]

Comment #21 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Ok I'm almost certain that's the issue. I disabled Aero and started
getting 1080p30 from the desktop capturer.

[chro...@googlecode.com]

Updates:
Status: Available
Owner: pthatc...@chromium.org

Comment #22 on issue 466879 by pthatc...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

rbl...@jupiter.com,

We'd be willing to review a patch if you write one. It's not top priority
for us right now for us to do the work, but we'd like to see a fix, so
patches are welcome, and we're willing to review.

Do you still want to work on it?

[chro...@googlecode.com]

Updates:
Cc: ser...@chromium.org

Comment #23 on issue 466879 by pthatc...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Issue 477171 has been merged into this issue.

[chro...@googlecode.com]

Comment #25 on issue 466879 by fla...@sensingplaces.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

We run into the exact same issue and we were wondering if someone has
figured out a solution or a workaround.

[chro...@googlecode.com]

Comment #26 on issue 466879 by fla...@sensingplaces.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

We run into the exact same issue and we were wondering if someone has

figured out a solution or a workaround. Our use case involves one-way
desktop casting in Chrome from a sender to a receiver both on the same
network. For comparison we run the same test using a chromecast device as a
receiver and the Google Cast (Beta) extension. I noticed than casting the
desktop from the sender onto a chromecast device instead achieves a higher
frame rate than casting to a browser on another machine (always within the
same network) using our extension built on webRTC. CPU load is also higher
on the sender's laptop when the chromecast is receiving -- using the latest
Google Cast beta extension. What is different on the sender-side when using
the chromecast extension? Can we get the same functionality available in
webRTC?

[chro...@googlecode.com]

Comment #29 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Some more testing - it looks like the alternative desktop compositor has
been removed in Windows 8 and Windows 10, which is why you can't "disable
Aero".

In terms of the future of screen sharing (particularly as more people move
over to Win 10 over the next year or so), I hope this is considered
important!

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: nik...@chromium.org
Cc: ptha...@chromium.org
Labels: -Hotlist-Recharge

Comment #30 on issue 466879 by tnak...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Owner: ser...@chromium.org
Cc: nik...@chromium.org

Comment #31 on issue 466879 by nik...@chromium.org:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Sergey, you know what the current status of this is?

[chro...@googlecode.com]

Comment #33 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Didn't you (or JiaYang) mention on the webrtc discussion that the
Magnification API is only used for single monitors and Bitblt is used for
dual monitor desktop capture?

[chro...@googlecode.com]

Comment #35 on issue 466879 by leighton...@gmail.com:

chrome.DesktopCapture 'screen' is very low performance
https://code.google.com/p/chromium/issues/detail?id=466879

Hi Sergey,

Can you clarify what you mean by "hide the notification bar" please? In
Chrome the desktop capturer seems to grab everything (see attached screen
shot).

I ran up the Desktop Duplication API sample here:
https://code.msdn.microsoft.com/windowsdesktop/Desktop-Duplication-Sample-da4c696a

It seems to perform excellently. I didn't modify it to show frame rate,
but qualitatively it was matching a Youtube 30fps video. I'd say it's a
great candidate for a Win 8/10 capturer.

Regards,
Leighton.

Attachments:
Chrome.PNG 339 KB
DesktopDuplication.PNG 337 KB