3 ms·

> Please do a small experiment: make a 30 minutes video call on your laptop using both: natively compiled skype and google meet. I don't think this is a Wasm i

by paulgb 3y ago

> Please do a small experiment: make a 30 minutes video call on your laptop using both: natively compiled skype and google meet. I don't think this is a Wasm issue. IIRC Google Meet uses WebRTC for encoding, which is the compute-heavy part of a video call. They might use Wasm for background blurring or something like that. In general I suspect that the issue here is that Skype as a native app can access some video-specific hardware acceleration that the browser can't. CPU-bound workloads should be close to native speed (OP says within 10% of native which tracks with my experience)

saiya-jin 3y ago
I agree, virtualization layers always add a bit of overhead by principle, but in 2023 we use plenty of those and the hit is small enough to ignore it for most uses. Either some bad coding/lib dependencies or lack of direct access to better hardware as you mention, but then browsers should allow this, with some good permission process.
- paulgb 3y ago
  > but then browsers should allow this Agreed! Between WebCodecs and WebGPU compute shaders, I think we’re getting closer to this ideal.
rjsw 3y ago
WebRTC can use hardware offload for video decoding, at least in Firefox.
- lxgr 3y ago
  Even that is both browser and OS dependent, in my experience.
doctorpangloss 3y ago
The user writing: > In my case meet drains almost 2x amount of power and after an hour-lasting meeting I have no battery left, but on one-hour meeting on skype I still have 56% of battery. is comparing apples to oranges via an uncontrolled comparison. > WebRTC for encoding, which is the compute-heavy part of a video call On Windows in Chrome, Google Meet will correctly use the same hardware acceleration for video encoding that Skype does. Both will ultimately use DXVA on modern hardware. On macOS, the story is complicated and I know less about Skype's internals.
- chii 3y ago
  > comparing apples to oranges it is because the laymen simply doesn't know how to account for their own bias. They conceived an experiment to try to show an objective truth, but was in fact biased - and probably didn't even really know it. This is why science isn't done this way; you need to put in a lot of effort to design the experiment, so that preconceived biases don't show up. Things like double blind, and randomization, etc.

by paulgb 3y ago

saiya-jin 3y ago

I agree, virtualization layers always add a bit of overhead by principle, but in 2023 we use plenty of those and the hit is small enough to ignore it for most uses. Either some bad coding/lib dependencies or lack of direct access to better hardware as you mention, but then browsers should allow this, with some good permission process.

paulgb 3y ago
> but then browsers should allow this Agreed! Between WebCodecs and WebGPU compute shaders, I think we’re getting closer to this ideal.

rjsw 3y ago

WebRTC can use hardware offload for video decoding, at least in Firefox.

lxgr 3y ago
Even that is both browser and OS dependent, in my experience.

doctorpangloss 3y ago

The user writing: > In my case meet drains almost 2x amount of power and after an hour-lasting meeting I have no battery left, but on one-hour meeting on skype I still have 56% of battery. is comparing apples to oranges via an uncontrolled comparison. > WebRTC for encoding, which is the compute-heavy part of a video call On Windows in Chrome, Google Meet will correctly use the same hardware acceleration for video encoding that Skype does. Both will ultimately use DXVA on modern hardware. On macOS, the story is complicated and I know less about Skype's internals.

chii 3y ago
> comparing apples to oranges it is because the laymen simply doesn't know how to account for their own bias. They conceived an experiment to try to show an objective truth, but was in fact biased - and probably didn't even really know it. This is why science isn't done this way; you need to put in a lot of effort to design the experiment, so that preconceived biases don't show up. Things like double blind, and randomization, etc.