Improve default screen sharing FPS, limiting capturing surface #972
Conversation
🦋 Changeset detectedLatest commit: db025ce The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
|
When removing the default resolution other than fixing the Safari bug we also did so in order to enable users to capture at native screen sizes. When applying a default like this, that won't be possible anymore. I think both makes sense: having a reasonable default, but also allowing users to capture uncapped resolution if they wish to do so. Maybe a |
|
@lukasIO I've added |
|
nice! was thinking whether explicitly passing |
| @@ -40,7 +40,7 @@ | |||
| "build:watch": "rollup --watch --config rollup.config.js", | |||
| "build-docs": "typedoc", | |||
| "proto": "protoc --es_out src/proto --es_opt target=ts -I./protocol ./protocol/livekit_rtc.proto ./protocol/livekit_models.proto", | |||
| "sample": "vite example -c vite.config.js", | |||
| "sample": "vite example -c vite.config.mjs", | |||
Previously when we didn't constrain screen share resolution, screen share tracks weren't resized to a reasonable size prior to publishing. Having to encode a huge frame caused FPS to be very low (often just 1-5 fps).
Because that's rather confusing behavior, we are now defaulting to 1080p when capturing