⏱️ Auto FPS Limiter

Every video you feed into a generation pipeline carries a frame rate, and here's the thing: you often don't need all of it. A 60fps source being used as a reference for a 24fps output is carrying 2.5× the frames it needs - and every extra frame is VRAM you're spending on data the model is going to throw away anyway. AutoFPSLimiter figures out the biggest legal frame skip and hands you the numbers to do it, without you doing division in your head.

It's a pure math node, and that's its charm. It answers one question: "if my source runs at X fps and I refuse to exceed Y fps, how many frames can I drop and what's the resulting fps?"

How it works

It takes your source_fps and a target_max_fps (default 30). If the source is already at or below the target, it returns nth = 1 - process everything, no change. If the source exceeds the target, it computes the smallest skip that gets you under the ceiling: nth = ceil(source_fps / target_max_fps), then new_fps = source_fps / nth.

Example: 60fps source, 30fps target → nth = 2, process every other frame, end up at exactly 30fps. 48fps source, 30fps target → nth = 2, land at 24fps - under the target, which is the point. The ceil matters: it guarantees you never exceed your cap, even if that means landing a little under it.

The outputs

• select_every_nth (INT) - feed this into the select_every_nth port of the pack's Auto Loop Calculators. That's the field that tells the loader "grab every Nth frame."
• new_fps (FLOAT) - the actual resulting rate, so your audio sync math stays honest.
• log (STRING) - the math spelled out.

That's the whole node - three wires, no state, no models. It's the sort of helper that disappears into a workflow and quietly stops a 60fps clip from doubling your VRAM bill for zero visible gain.

Why it matters in a loop workflow

Inside the Sequential Batcher flow, this is the frugality layer before the chunking math. The calculators divide your timeline by select_every_nth, so a higher skip means fewer frames per chunk means less VRAM per cycle - and because the audio is sliced against the same frame math, the pace stays synced even as you drop frames. If your source is already at your target fps, the node is a no-op passthrough and costs you nothing.

One honest caveat: dropping frames is a real trade. If the source motion is fast and smooth, skipping every other frame can make the reference look steppy. For slow, controlled footage - which is most of what you'd feed a video-to-video pipeline - it's free memory.

Install

ComfyUI Manager → search "comfyui-sequential-batcher", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Meisoftcoltd/comfyui-sequential-batcher

Restart ComfyUI. No model downloads, no FFmpeg involvement for this one. Standard pack rule: don't launch with --highvram, since the loop's memory purge is what makes multi-cycle video work at all.