Closed Bug 1508567 Opened Last year Closed 3 months ago

firefox cannot limit framerate in getusermedia with screen


(Core :: WebRTC: Audio/Video, defect, P2)

63 Branch



Tracking Status
firefox71 --- fixed


(Reporter: itpandey.88, Assigned: dminor)



(1 file)

+++ This bug was initially created as a clone of Bug #1376276 +++

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce:

i want to limit the stream get form getusermedia in screen

Actual results:

when i set 10 fps,but in firefox53, the fps actually is 40-60

Expected results:

I think if i set 10fps, i shoud get the stream is limit in 10,not 40?

Facing same issue :
<p>I'm still facing this issue on windows system that cannot limit the fps for screen sharing. I'm trying to limit the frameRate to somewhere close to 10 and it reaches to 20( x2).
Browser : Firefox Quantum 63.
OS      : Windows 10
Processer : Intel I5 @ 2.60HGz
System Type : 64 bit operating system, x64-based processor.</p>

Let's get this triaged.

Priority: P2 → --

I don't know if this fully explains comment 0, but I'm able to reproduce a doubling of frame-rate on Windows 10 vs OSX and expected frame-rate:

  1. In about:config, set media.navigator.permission.disabled = true (don't forget to set it back to false after!)
  2. Open and click the various buttons
Button clicked OSX Windows 10
unconstrained 3360 x 2100 x ~20 1920 x 1080 x ~30
x1 352 x 220 x ~1.00 373 x 210 x ~2.00
x2 352 x 220 x ~2.00 373 x 210 x ~4.00
x5 352 x 220 x ~5.00 373 x 210 x ~10.00
x10 352 x 220 x ~9.00 373 x 210 x ~18.00
x15 352 x 220 x ~13.00 373 x 210 x ~26.00
x20 352 x 220 x ~15.00 373 x 210 x ~30.00
x30 352 x 220 x ~21.00 373 x 210 x ~30.00
x60 352 x 220 x ~30.00 373 x 210 x ~30.00
Flags: needinfo?(dminor)
Ever confirmed: true
Priority: -- → P2
Assignee: nobody → dminor
Flags: needinfo?(dminor)

The reason for this is that we use a separate mechanism for limiting framerate on Windows than on other platforms [1]. That code was added in Bug 1060738 to avoid deadlocks while accessing HWNDs, etc. from non-ui threads. Looking at the PlatformUIThread::Run code, it looks like we run the user callback every time we get a message instead of only when we receive WM_TIMER messages [2]. That would explain why we are getting a faster capture than expected on Windows.


This moves the call to run_function_deprecated_, which ensures it is called at
least once prior to the thread exiting, to outside of the do/while loop. As
written, it is being called every time a message is received, causing desktop
capture frame rates on Windows to be higher than expected.

Pushed by
Move call to run_function_deprecated_ to outside of message loop; r=pehrsons
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
You need to log in before you can comment on or make changes to this bug.