WASM memories do have a hard 4GB limit, at least until the 64bit extension lands, but there's nothing technically stopping a tab from using more than that as a whole if the implementation chooses to allow it. I just tried creating a dozen TypedArrays of 1GB each and Chrome didn't panic, and the heap profiler shows ~12GB allocated as expected. Mobile browsers are much more strict about memory though so don't expect those to be so forgiving.
While doing my testings, it does not appear that a tab is limited to 4GB. A typical project in After Effects is not longer than a few minutes of duration. Let's say you work on a 2 hours movie, each AE project would be about a 1 minute shot where sfx need to be applied. Pikimov was created with the same behavior in mind, not made to edit a full movie in one go
Video editing is generally not done in memory at all. The videos themselves sit on disk and are played back from disk, and the desired cuts/effects are composited on the fly.
For speed, an editing app may also produce lower-res versions in memory for quick seeking and smooth playback, as a kind of quick preview. But that's easy to control how much memory you allocate for that, and even those previews can be stored or cached on disk.
Video editing is not especially memory-bound on modern machines. It's much more CPU/GPU-bound when it comes to applying effects, and IO-bound (including decoding-bound) when it comes to larger videos like 4K and 8K.
Lots of factors at play that makes your assumption not necessarily correct.
I.e.
1. Newer API such as directory access, which would let the app utilize something like swap as necessarily. And only ever loading the data it can currently handle from the filesystem (https://developer.mozilla.org/en-US/docs/Web/API/File_System...)
2. Input doesn't necessarily have to be RAW/8k. You get several h of 1080p AV1 video within 4gb.
I think it ultimately depends on how much effort the Devs wants to invest to support large video inputs. If none is invested, then your assumption would be true.
I was unable to find the source code, so I wasn't able to check for myself. We'll have to wait for the author to chime in, if they're willing.
1. Swapping to disk would kill the performance to an unnacceptable level.
2. I'm assuming video editing software works on a raw format in memory with access to individual frames? Just like Photoshop would need access to individual pixels from an importend JPEG, the actual canvas uses a lot more memory than the compressed input format.
I had a Macintosh Quadra 660AV that had 16MB of RAM and was able to edit multiple-gigabytes of video. Not everything needs to be in memory all of the time to effectively edit video in a non-linear fashion.
