Max Frames Calculator (by Resolution)

This does the same basic job as this pack's MaxFramesByResolution - estimating how many frames of video you can generate before running out of VRAM - but keyed off actual width and height instead of a single resolution figure, and it gives you two numbers back instead of one.

How it differs from its sibling node

Unlike MaxFramesByResolution, this node's display name carries no GPU-tier hint, so there's no equivalent clue about what hardware the underlying estimate assumes - treat that as unstated rather than guessing a specific card. What it does add is a second output: alongside max_frames, you get safe_frames, which suggests the author built in some margin rather than handing you a number sitting right at the edge of an out-of-memory error.

VRAM is genuinely the binding constraint for local video generation - it's bandwidth- and hardware-specific in a way image generation mostly isn't - so a calculator like this is trying to save you the generate-OOM-retry loop everyone doing video work eventually settles into.

Inputs and outputs

• width, height (INT, 64–8192, step 8, defaults 1280×720) - your target generation dimensions.
• Outputs: max_frames (INT) and safe_frames (INT, presumably max_frames with margin subtracted).

Installing it

No models or extra dependencies mentioned in the README - a plain calculation node. Search ComfyUI Manager for the repo name first; a small personal pack like this may not be indexed there, so the manual clone is the reliable fallback:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist.git

Restart ComfyUI afterward.

Common issues and troubleshooting

Neither output accounts for your actual model or precision. Like its sibling node, this one only ever sees width and height - nothing about which model you're running, its precision (fp8, fp16, GGUF), or what else is loaded alongside your sampler. Two setups at the same resolution can have very different real ceilings depending on all of that, so treat both numbers as a starting estimate, not a guarantee.

Start conservative with safe_frames on a new resolution. If you're testing a resolution you haven't run before, start at safe_frames rather than max_frames - only push toward the higher number once you've confirmed your specific model and precision combo actually fits without erroring.

If you're working from a round resolution number instead of explicit dimensions, the sibling node is more direct. MaxFramesByResolution, elsewhere in this pack, takes a single resolution value rather than width and height - reach for that one if that's the shape your workflow already thinks in.