1152328 - Improve framerate cap of CanvasCaptureStreams

Status: RESOLVED INVALID

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

Description

[Andreas Pehrson [:pehrsons]]

See bug 1032848 comment 60.

jesup wrote:
> I have a concern about mFPS for two reasons - one is that we're doing exact
> comparison with 0.0 (admittedly semi-reasonable in this case, but really
> being used as a flag).  Second we're dividing by mFPS, which could yield
> silly FPS values if not capped (as we do below) causing serious perf/DoS
> issues by monopolizing MainThread, especially if the programmer naively
> calculates or allows users to set the value.
> 
> There may be some cases where a high rate is reasonable (>60fps when
> generating a local recording of a rendering), but we need to be careful
> about overloading MainThread.  So, that said, we should consider if values
> >> 30fps are reasonable, and if not what the limit should be (and if it
> should be in some way adaptive).  I doubt 1000fps is reasonable, for
> example.  Down below we cap it to 60fps, which likely is reasonable for
> live/WebRTC use, but might not be optimal for some recording uses.  However:
> 60fps isn't a bad place to start.
> 
> I suggest reaching out to Vlad and/or other people who interact with
> WebGL/games/etc, but land as-is

I.e.:
* Should cap be dynamic somehow or is fixed OK?
* Should cap be different for WebGL and 2D canvases?

Comment 1

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.

Comment 2

[Andreas Pehrson [:pehrsons]]

This is moot. A captureStream can never capture faster than the refresh driver. The fps value is there to say whether a frame should be captured on a particular refresh driver tick.