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.
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.
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/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.
My use case is live coding sessions in education btw.
It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog
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.
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
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.
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.