Calculate LTX Frames

LTX is a picky eater. It won't accept just any frame count - the model requires frames to land on 8n + 1 (1, 9, 17, 25, ...), and on LTX 2.3 an off-grid count fails outright rather than silently rounding. Every time you chunk a long video into segments to fit VRAM, you're slicing up your clip and handing each slice to a model that will throw it back if the boundary isn't on the grid. That's the gap Calculate LTX Frames closes: give it a chunk duration in seconds and it tells you the exact frame count, plus the overlap and trim values you need to make chunking perfectly accurate.

It's part of this pack's answer to the "chunk to fit VRAM" problem - and given the KB's own note that LTX's resolution and frame constraints are hard (off-grid values fail, they don't round), having a node that does this arithmetic for you instead of relying on a hand-rolled expression is genuinely useful.

How it works

Two inputs: chunk_secs (a FLOAT, your raw chunk duration with no overlap added yet) and fps (an INT, usually 25). The node multiplies them to get a raw frame count, then rounds up to the next valid 8n + 1 boundary.

The clever part is what it does with the extra frames it just added. Rounding up from, say, 23.5 frames to 25 frames means you're generating two frames the raw chunk didn't ask for. Instead of silently bloating the segment, the node splits those extra frames evenly - half on the front, half on the back - and reports them as trim values. So you generate with the overlap baked in (which keeps LTX happy) and trim the overlap back off afterward (which keeps your timeline accurate).

The outputs

Five of them, and they wire together like a kit:

• frame_count - the LTX-valid count you ask the sampler to generate.
• overlap_ms - milliseconds of overlap per side; feed this to the audio chunker instead of a hardcoded value.
• start_trim_frames / end_trim_frames - how many frames to cut from each end after generation; feed these to TKTrimImageOverlap, which trims the front/middle/last segments accordingly.
• actual_secs - the true duration your padded frame count represents, for sanity-checking.

Where it slots into a workflow

The canonical wiring: audio chunker → this node → sampler (with the padded frame count) → TKTrimImageOverlap (with the trim values) → concat. The node was written to be the "guarantees perfect LTX boundaries" step in exactly that chain - if you're hand-typing LTX frame math into a MathExpression node today, this is the less clumsy replacement.

Installing it

Part of trashkollector/TKNodes ("ComfyUI Handy Nodes"). Install via ComfyUI Manager (search "Handy Nodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/trashkollector/TKNodes

Restart, and it's under TKNodes/video. No models or extra installs - it's pure arithmetic. (Note it's LTX-specific: for Wan 2.x's 4n + 1 grid you'd want the pack's TKSnapFrames instead.)

Common issues

The one real trap is feeding it a chunk duration that already has overlap baked in - the node's comment is explicit that it expects the raw duration, and double-counting overlap will push your frame counts up and your trim values off. Keep the raw number on the input and let the node own the padding. And if your actual_secs looks longer than the chunk you asked for, that's not a bug - that's the overlap you're meant to trim later.