How to deal with file/vram size for many animation frames?

[shut plank]

I'm working on a game where we want to have animated cutscenes and I was so happy to see that I could wiggle down the actual .import size of those pngs to a mere 40kb each using lossy compression.
But the projected memory ( I guess that's VRAM usage ) is insanely high at about 5mb per image. When I go with VRAM compressed I can get the memory usage down to 1mb but the import size goes up 25 times??

We are targeting HTML mainly and I think with itch.io we have a 200mb file size cap. Either way I don't want to come anywhere near that just because we have maybe some 200-300 animation frames for our cutscenes.
I don't exactly understand when the VRAM is being used though, how dynamic this is going to be. If it's only the image that's currently displayed in the VRAM then the memory obviously wouldnt have to be a consideration at all.

Then there's also the option of video playback, but I dont know what limitations I'm running into there.

I hope someone has experience with this and can point me in the right direction, because these numbers seem a bit crazy to me. For now the only option I see is to reduce the resolution of our animation frames from 1080p to 540p and hope thats enough..

This is one solution gpt suggests btw, which sounds reasonable

When VRAM is used
Godot uploads textures to GPU when they’re needed — if you’re showing one frame at a time and unloading the previous one, only that one frame will live in VRAM. But if you preload hundreds of frames (like in an animation framesheet or preloaded resource), yeah, they’ll all sit in memory and crush you. So the trick is to stream them in dynamically — load the next frame right before it’s displayed, free the last one.

[open summit]

textures are data that only exists on the VRAM of the GPU. Once the the texture is loaded in, it will exist there, no matter if it actually gets rendered or not. The equivalent to this for the cpu are images, and you can transfer data from one to the other using those classes (this tend to be very slow however).
This problem of the memory usage is the reason why videostreams exist.

So i would suggest converting all those frames to one video file.

[shut plank]

I assume if I dynamically load() those textures ( with a little buffer for safety ) this would work, but I don't know if Godot unloads them from the VRAM automatically

[shut plank]

I always assumed that video playback came with a lot of caveats too but never looked into it. guess I will do that rn

[open summit]

It does, but when what you need is practically a video, i don't think there really is a better alternative.

[open summit]

In the docs tutorial on VideoStrwams they even tspecifically mention using it for animations that would require too much memory otherwise.