> 4GiB of completely uncompressed 1080p video in memory is only 86 frames
How is that data stored?
Because (2^32)÷(1920×1080×4) = 518 which is still low but not 86 so I'm curious what I'm missing?
Re:WASM 3.0 Completed
by brokencube on Wednesday September 17, 2025 @06:39PM
(#45282277)
I would guess 3 colour channels at 16bit (i.e. 2 bytes)
(2^32)÷(1920×1080×4×3×2) = 86
Where does the 4 come from? I thought it was R+G+B+A, but you already have 3 colour channels in that calculation
Re:WASM 3.0 Completed
by brokencube on Thursday September 18, 2025 @05:39AM
(#45287595)
Yep, my logic is faulty there. And even if we assume that it's 24bpp color, that's still a factor of 2 out.
Apparently with 24 bytes per pixel instead of bits :)
Although to be fair, there's HDR+ and DV, so probably 4(RGBA/YUVA) floats per pixel, which is pretty close..
> How is that data stored?
So glad you asked. It's stored poorly because I'm bad at maths and I'm mixing up bits and bytes.
That's what I get for posting on HN while in a meeting.
Re:WASM 3.0 Completed
by flykespice on Thursday September 18, 2025 @12:01PM
(#45291302)
I'm strange to webdev, but can't you swap the remaining uncompressed frames that don't fit into memory to disk?
For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buffer this into memory. It's why most modern video editing machines are sold with 64-128GB of memory.
In the case of Figma, we have files with over a million layers. If each layer takes 4kb of memory, we're suddenly at the limit even if the webapp is infinitely optimal.