getUserMedia : disappointing performances with Chrome

[OBS Conferencing]

Hi,

I work on an application that share screen captures through websocket connection.
To get screen capture I use getUserMedia() and a worker.

That's ok but I notice that performances with Chrome are under performances with Firefox on some computers.

The algorithm is the same in both cases and basically is :
1. get screen stream using getUserMedia()
2. get "shots" with canvas
3. process and cut images (in a worker)
4. transform in b64
5. send b64 packets through a websocket

With Firefox, the frame rate seems constant. The GUI is a bit slow but all is very acceptable!
With Chrome, the frame rate decrease, the GUI slow down (about 5 seconds after a click). The CPU is "overloaded".

Note that I tested that feature on some computers with Chrome 42->44 64bits on Windows 7 x64 Enterprise:
A. Core i5 2400, 8Go, Intel HD Graphic Family : I have the issue
B. Core 2 Duo E8400@3Ghz, 8Go, Intel 4 Serie Internal Chipset : I have the issue
C. Core i7, 12Go, ATI Radeon 4800 : I have NOT the issue

The issue occurs on A and B but not on C.
Even if the global performances of C is logically better, is it enough to explain C run so easy?

Could-it be a hardware support issue? I can share the result of chrome://gpu if it helps.

Regards,

[Alexandre GOUAILLARD]

any reason why you would use WS and not a peer connection to send the screen capture?

I have not tested recently, but I remember the later to be much faster. 

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5838ddcc-8b95-4c44-9d8c-f3019d3bf52e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[OBS Conferencing]

Yes there is a reason :)

But I tried to descactivate that step. It does not improve anything so I think that is not the cause.

I notice :
- getUserMedia() response stream in step 1 is about 8-10 seconds (for a 1920*1080 stream).
- Step 2 and 4 are heavy but not WebRTC.
- unactivate step 5 does not change anything

So I would know what causes the issue. I had that 2 ideas :
- WebRTC with user media recovery, maybe caused by better hardware support on Firefox than Chrome ?
- browser with canvas and b64 conversion, that are better in Firefox than Chrome ?

[OBS Conferencing]

Hi,

I notice one detail more : performances are not so bad with Chrome 32 bits !
So Chrome 64 bits take 8-10 seconds of delay as I say previously.
But Chrome 32 bits (same version number) take only 2 seconds. That is acceptable.

Is 64-bits known for performance issue comparatively to 32-bits version ?

Regards,

[Stefan Wójcik]

Hi, can you share more info about which part is particularly slow on Chrome? Is it the resolving of `getUserMedia`?

We recently moved our app from a 32-bit CEF-based app to a 64-bit Electron-based app (both using Chromium under the hood) and we've seen a massive drop in `navigator.mediaDevices.getUserMedia`'s performance (~100ms to more than 1s). I think your findings might be related.

- Stefan from Close.io