Max Frames By Resolution (RTX 6000)

Video generation VRAM budgeting is normally a trial-and-error loop: generate, hit an out-of-memory error, lower your frame count, try again. This node tries to shortcut that by giving you a suggested max frame count up front, based on the resolution you're targeting.

What it's estimating, and for what hardware

The display name is doing real work here, and it's worth reading literally: "(RTX 6000)". That strongly suggests whatever curve or lookup this node uses internally was tuned against the VRAM headroom of an RTX 6000-class card - 48GB - rather than derived from a formula that adapts to your actual GPU. The schema backs that reading up: there's no VRAM or GPU-model input anywhere. It only ever sees the resolution you give it, so whatever assumption about available memory is baked into the code, not exposed as a setting.

This matters because VRAM is genuinely the central constraint in local video generation - bandwidth-bound, hardware-specific, and not something a resolution number alone can fully account for.

Inputs and outputs

• resolution (INT, 240–4320, step 8, default 720) - your target resolution.
• Output: max_frames (INT) - the suggested ceiling.

That's the entire interface.

Installing it

No models or extra dependencies documented in the README - it's 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 fallback:

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

Restart ComfyUI afterward.

Common issues and troubleshooting

Treat the output as a starting point, not a guarantee. If you're not on an RTX 6000-class card, the real ceiling for your hardware could be meaningfully lower (smaller consumer cards) or the number here could be needlessly conservative (bigger cards, or a quantized/lighter model freeing up headroom). Compare the suggested number against where your setup actually runs into an out-of-memory error once, and adjust your own margin from there rather than trusting it blindly.

It only knows about resolution. Model choice, precision (fp8 vs fp16 vs a GGUF quant), and whatever else is loaded alongside your sampler all materially affect real VRAM headroom, and none of that factors into this node's single input. Two workflows at the same resolution can have very different actual ceilings depending on what else is in VRAM.

There's a near-twin in this same pack. MaxFramesCalculator, elsewhere in this pack, does the same estimation but keyed off explicit width and height rather than one resolution figure, and it gives you both a hard max and a "safe" margin. If you're working from exact generation dimensions rather than a round resolution number, that one's the closer fit - see its own article for details.