4 ms·
As a user, I think Google Meet probably has the most cpu-friendly default settings for screensharing. They limit the framerate to 5fps, and they're careful to u
by kwindla 6y ago
As a user, I think Google Meet probably has the most cpu-friendly default settings for screensharing. They limit the framerate to 5fps, and they're careful to use either the native size of the screen or half the native size (which avoids at least some expensive scaling code paths).
This is hard/impossible to get right on every machine, because encoder implementations vary widely across all the hardware and operating system combinations. For example, using h264 instead of vp8 might help with cpu usage a lot on an older macOS machine, but make cpu usage worse on a newer macOS machine or some specific windows machine.
Here are settings we recommend to developers building apps that include screen-sharing using our video APIs: https://gist.github.com/kwindla/5d5a8190aee36dc00a5ef8e6c9011a63 https://gist.github.com/kwindla/5d5a8190aee36dc00a5ef8e6c901...
Max-width of 640 for the camera. Max-width of 1920 for the screenshare, framerate limited to 5fps, and manually decimate the screenshare width by half if it's larger than 1920. ymmv, but these settings use ~30% of the cpu on a typical mid-range Windows or macOS machine, for the sending side of a two-person cam+screenshare call.
- cloogshicer 6y agoHey, thank you for the recommendation and detailed info! Sadly Google meet is empirically one of the worst one, even without screen sharing CPU hovers at ~60%, with screen sharing it's completely unusable. My use case is live coding sessions in education btw.
- kwindla 6y agoI'm always interested in data points, so thank you! If you don't mind, I'd love to hear what hardware/OS you're using. We have a lot of test devices, and it sounds like your particular setup is one that Google (and possibly we) aren't doing a good job factoring into our settings defaults/workarounds/special cases. So I think we maybe need another test device. :-)