fix: high CPU on Chrome with low fps screen sharing

[paweldomas]

It turns out that if 5 fps is set on the track constraints,
Chrome will capture the original video in 30 fps and only
further down the pipeline will downsample it to 5 fps.
This results in very high CPU usage. Specify max FPS in
getDisplayMedia to fix the problem.

Getting rid of track.applyConstraints should also fix another
issue on Firefox where it reports 0x0 screen size after this call.

[jallamsetty1]

LGTM! Good find about the gDM constraint vs track constraint.

[saghul]

Btw, I brought this up with Google and will be sending them some details, according to them this shouldn't happen, just when scaling fps.

[paweldomas]

@saghul You know thinking about it the current state of things makes sense to me. When a MediaStream is created via getDisplayMedia there's tons of different ways on how it can be used. You can put it on a canvas, you can send it via different peerconnections at the same time etc. A behavior where the pipeline is optimized to select the lowest fps used by all components is more of an optimization rather than expectation. Even to show local preview of this screen you need to decide on the fps and the most intuitive would be the one passed to get display media.

[paweldomas]

But then thinking about it some more, this was the constraint applied on a track which is the shared object here, so maybe it should be respected better.

[paweldomas]

🤷‍♂️