LTX-2 Ensure Frames (8n + 1)

LTX-2.3 has a hard rule that bites you exactly when you least expect it: the frame count of anything you VAE-encode must be 8n + 1 (81, 89, 97…), and width/height must be divisible by 32. The model card states it plainly, and unlike a soft warning it fails off-grid values rather than rounding them. That's what this node exists for - it takes an IMAGE batch that doesn't obey the rule and quietly makes it obey.

Where does the non-conforming batch come from? A video loader, a VAE decode of a previous segment, or a ControlNet-ish start-frame stack that just has whatever frame count it has. The IAMCCS LTX-2 extension family is built around feeding such batches back into the encoder on every pass, so the pack ships a few nodes that all do this math; this one is the one you put right on the image tensor before it hits the VAE.

How it works

It's honestly just arithmetic plus one image trick. EnsureFrames8nPlus1 checks (frames - 1) % 8. If the remainder is zero, it hands your images back untouched. If not, it pads or crops to the nearest valid count. The default pad_repeat_last mode copies your final frame and tiles it at the end of the batch - that's the workflow-safe choice, because it never shortens a clip and a frozen final frame is exactly the "hold on this last frame" behavior a video model expects. crop_end instead trims the tail, which is deterministic but drops content, so it's best when the last frames are junk anyway.

The fix widget (up / down / nearest) decides the direction of the correction. up is the default and is right for almost everything: you'd rather add a few frozen frames than lose real ones.

The inputs and outputs that matter

Only three inputs, and you'll touch two of them:

• images - the IMAGE batch to fix. This is the only thing you wire in from your graph.
• mode - pad_repeat_last (default) or crop_end. Leave it on the default unless you have a reason.
• fix - up / down / nearest, defaults to up. This only really matters if you're also using crop_end.

Outputs: images (the corrected batch, ready for the LTX VAE encode), frames (the corrected count as an INT, handy if a downstream node wants the number), and report (a STRING that tells you exactly what it did - pad_repeat_last 98 -> 105 (pad=7, fix=up)). The report is the fastest way to figure out why your "81 frame" video is suddenly 89 frames.

Installing it

This node ships in IAMCCS-nodes, so it's one install for the whole family. In ComfyUI Manager, search "IAMCCS" and install. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Then restart ComfyUI. It'll land in the IAMCCS/LTX-2 menu. No model downloads and no Python deps for this one - it's pure tensor fiddling. The heavy lifting is the LTX-2 model itself, which you'd be running regardless (and yes, that's the part that wants 16GB+ VRAM and a big page file on low-RAM rigs).

Common issues

The classic mistake is chaining this after a latent exists. It fixes IMAGE tensors, not latents - if you already encoded, you're too late, and the encode already failed. Fix the batch before the VAE.

Second gotcha: if you set fix=down or nearest with padding mode, the node can end up cropping instead of padding when the nearest valid value is below your input count. If a clip mysteriously lost its last few frames, that's what happened. The pack's LTX2 Frame Count Validator (FrameCountValidator) is the pure-math version if you want to sanity-check the arithmetic before committing pixels to it.