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.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.