3 ms·

Does anybody know a video conferencing tool with low CPU usage while screen sharing? All the tools I've tried, including Jitsi, slow down my computer to a crawl

Does anybody know a video conferencing tool with low CPU usage while screen sharing? All the tools I've tried, including Jitsi, slow down my computer to a crawl.

mguerville 6y ago
I’ve had similar issues and have not found a tool that cooperated better. Here are a few things that helped though: - App police (mac app) to reduce cpu allocation for any given app - unplug external display monitor during video calls - turn off any video enhancing settings in app (mirror video, enhanced light, etc) as well as virtual background or background blur It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog
- cloogshicer 6y ago
  Thanks for your response! Unfortunately I'm already doing all those things. Agreed, I think it's insane. How come there isn't a single App out there that works well for such a key technology? I guess it's a really hard problem to solve.
- kwindla 6y ago
  > It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog It sure is. On the other hand, the big tech companies did not view video calls as a critical use case until ~9 months ago. You can see this in how much Chrome has improved in its last 3 releases. A year ago, you could play ~15 videos simultaneously in a page on Chrome before <stalling, chaos, and crashing>. Now, on the same machine, you can play >50. This matters for video calls because the standard stream topology these days for multi-party calls is 1 up, N down, where N is the number of participants in the call. Hardware and OS support is critical, too, so this is an ecosystem challenge. - encoder pipelines don't do low-resolution streams very well, which matters for large video calls - encoder pipelines don't do variable framerate, variable resolution, large resolution/low-framerate, and "non-standard" resolutions as well as they could - hardware support for newer codecs (vp9, h265, av1) would help - decoder pipelines aren't great at decoding lots of small videos in parallel Everyone focused on single-stream video playback for the last few years, which led to really amazing improvements watching video. Nobody complains anymore about their fan spinning up every time they watch Netflix. Now we have to put the same effort into the building blocks needed for video calls.
  - cloogshicer 6y ago
    Thank you for the detailed reply. On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore. That said I agree with a lot of your points and I totally get why it is this way. It's just sad that it's mainly due to business reasons. I think part of it that video conferencing is too cheap/free. It's just a bad business to be in.
    - kwindla 6y ago
      > On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore. Agreed! Modern GPUs are amazing, as is the software stack on top of them. (Crufty, fragile, maddening, inconsistent ... and amazing.) For the next-gen needs of video calling, some combination of Nvidia, Apple, Intel, Arm, Microsoft, Google, codec IP owners, and a bunch of mobile chipset manufacturers are going to have to agree on a bunch of stuff. That never happens in a logical, straightforward way. For the past 10 years Nvidia has been betting that a really big chunk of their future growth will come from powering machine learning applications of all kinds. They're probably ... right? (I mean, I have no idea.) But as someone who cares a lot about video and only intramurally about machine learning, I find that frustrating. There's a lot of relatively low-hanging fruit, from a technical perspective, in hardware codec support.
rkangel 6y ago
Fundamentally, generic screen sharing is going to involve running a video encoder live (because that's what you're doing - generating a video stream of your desktop). Something needs to do that work, and unless your GPU can it's going to be the CPU. The only way around it that I know is a 'remote desktop' type protocol where you send drawing primitives to reconstruct the desktop on the other end. That is obviously a much more complicated thing to get working and is better for different use cases.
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 ago
  Hey, 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 ago
    I'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. :-)

Does anybody know a video conferencing tool with low CPU usage while screen sharing? All the tools I've tried, including Jitsi, slow down my computer to a crawl.

mguerville 6y ago

I’ve had similar issues and have not found a tool that cooperated better. Here are a few things that helped though: - App police (mac app) to reduce cpu allocation for any given app - unplug external display monitor during video calls - turn off any video enhancing settings in app (mirror video, enhanced light, etc) as well as virtual background or background blur It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog

cloogshicer 6y ago
Thanks for your response! Unfortunately I'm already doing all those things. Agreed, I think it's insane. How come there isn't a single App out there that works well for such a key technology? I guess it's a really hard problem to solve.
kwindla 6y ago
> It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog It sure is. On the other hand, the big tech companies did not view video calls as a critical use case until ~9 months ago. You can see this in how much Chrome has improved in its last 3 releases. A year ago, you could play ~15 videos simultaneously in a page on Chrome before <stalling, chaos, and crashing>. Now, on the same machine, you can play >50. This matters for video calls because the standard stream topology these days for multi-party calls is 1 up, N down, where N is the number of participants in the call. Hardware and OS support is critical, too, so this is an ecosystem challenge. - encoder pipelines don't do low-resolution streams very well, which matters for large video calls - encoder pipelines don't do variable framerate, variable resolution, large resolution/low-framerate, and "non-standard" resolutions as well as they could - hardware support for newer codecs (vp9, h265, av1) would help - decoder pipelines aren't great at decoding lots of small videos in parallel Everyone focused on single-stream video playback for the last few years, which led to really amazing improvements watching video. Nobody complains anymore about their fan spinning up every time they watch Netflix. Now we have to put the same effort into the building blocks needed for video calls.
- cloogshicer 6y ago
  Thank you for the detailed reply. On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore. That said I agree with a lot of your points and I totally get why it is this way. It's just sad that it's mainly due to business reasons. I think part of it that video conferencing is too cheap/free. It's just a bad business to be in.
  - kwindla 6y ago
    > On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore. Agreed! Modern GPUs are amazing, as is the software stack on top of them. (Crufty, fragile, maddening, inconsistent ... and amazing.) For the next-gen needs of video calling, some combination of Nvidia, Apple, Intel, Arm, Microsoft, Google, codec IP owners, and a bunch of mobile chipset manufacturers are going to have to agree on a bunch of stuff. That never happens in a logical, straightforward way. For the past 10 years Nvidia has been betting that a really big chunk of their future growth will come from powering machine learning applications of all kinds. They're probably ... right? (I mean, I have no idea.) But as someone who cares a lot about video and only intramurally about machine learning, I find that frustrating. There's a lot of relatively low-hanging fruit, from a technical perspective, in hardware codec support.

rkangel 6y ago

Fundamentally, generic screen sharing is going to involve running a video encoder live (because that's what you're doing - generating a video stream of your desktop). Something needs to do that work, and unless your GPU can it's going to be the CPU. The only way around it that I know is a 'remote desktop' type protocol where you send drawing primitives to reconstruct the desktop on the other end. That is obviously a much more complicated thing to get working and is better for different use cases.

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 ago
Hey, 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 ago
  I'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. :-)