CPA ChunkPad

LTX-2.5 will not accept an arbitrary number of frames. The video VAE compresses time in groups of eight, so the length has to land on 8n+1 - 49, 33, 25, 17 - and the spatial size has to be a multiple of 32. CPA ChunkPad is the node that takes your messy real-world chunk and hands the sampler something it will actually accept.

It's the first thing downstream of the plate on every LTX pass, and it's an internal node: hidden from the node menu (the pack flags its /internal stages deprecated so they don't clutter search), visible only when the generator expands its graph on Queue.

What it does, exactly

Four inputs. images is the full processed range. start is the 0-based index of the chunk's first frame. length is how many frames you want. end defaults to -1, which means "no limit" - the slice is images[start:start+length]. Set end to a positive number and you get min(start+length, end) instead, so a chunk near the tail of a shot can't run past the range you actually picked.

Then the padding, in two steps:

Time. If the slice came up short of length - the last chunk of a shot almost always does - the final frame is repeated to fill. With start=200, length=49 on a 220-frame shot you get 20 real frames and 29 copies of frame 220. The stitch stage later weights those padded frames at zero, so they never reach your alpha; they're structural filler, not content.

Space. Height and width get replicate-padded up to the next multiple of 32. This is the mechanism behind the pack's "best quality at 1920x1088" line: feed it 1920x1080 and this node quietly pads to 1088, which is why you don't have to do it yourself, and why a 1080p plate doesn't need to be resized to 1088 first.

Output is a single chunk: float32 in 0–1, uint8 inputs divided by 255, length frames of the padded size. From here it goes into the IC-LoRA guide node as the image input - the guide frames that steer alpha-gen.

Why it's a separate node at all

Because every stage in this pack is its own node so it gets cached. Changing a late setting - output format, the overlap-mode tuning, temporal smoothing - should reuse the expensive LTX pass. If padding were folded into the guide node, a cache miss anywhere in the pad path would re-render 49 frames of a 22B model for nothing. It also means the padding logic exists once, in one place, and every LTX pass in the pack - the 1080p pass, the isolated pass, the v13 attention passes, the native-resolution tiles - goes through the same code. That's the sort of thing that matters when the fourth pass you bolted on is where the off-by-one bug would live.

The knobs and what they're for

length is exposed on the generator as chunk (frames per chunk), and the default of 49 exists because that's what fits a 1920x1088 render on a 32 GB card. If you're running out of memory, drop to 33 or 25: more chunks, more joins to cross-fade, slower overall, but each pass is smaller. Going the other way is for people with headroom who would rather have fewer joins.

start and end you never set - the graph does, per chunk.

Install

Ships with the pack; nothing to add beyond the pack itself:

cd ComfyUI/custom_nodes
git clone https://github.com/rik-python/ComfyUI-Comfy-Pro-Alpha-Generator.git
pip install -r ComfyUI-Comfy-Pro-Alpha-Generator/requirements.txt

Restart ComfyUI, and reload the browser tab if you updated rather than installed fresh.

Where it bites

The one that catches people out is expecting an exact frame count back. length is a maximum for content and an exact size for the output tensor - a 20-frame slice comes back as 49 frames, most of them duplicated. If you hand-wire this node and then compare lengths downstream, don't.

The other is end. It's an absolute index in the connected batch, not a relative one, and it truncates a chunk that would otherwise be full. Pass the end of your processed range, or leave it at -1 and let the repeat-last-frame behaviour do its job.