Zura · LTX Frame Padding

LTX Video's temporal VAE has an opinion about how many frames a clip can be, and the opinion is "8n+1". 121 frames, 89, 97, 113 - those work. A nice round 120 does not. GenjLTXFramePad ("Zura · LTX Frame Padding") is the twelve-line fix: it pads your frames up to the next valid count and stretches the audio to match, so the guide and the soundtrack stay in step.

The mechanism

It reads the video's components and computes extra = (1 - len(images)) % 8. That's the number of frames needed to reach the next 8n+1 total. If there are none and the clip already has an audio component, it passes the video straight through untouched - the fast path that costs nothing.

Otherwise:

• The pad frames are copies of the last frame, expanded to fill the gap. No interpolation, no invented motion: a static tail is the least damaging thing to hand a video model, and it's getting trimmed off the end anyway.
• The audio is refit to the padded duration, padding with silence or truncating as needed, so the audio VAE and the video latent agree on the timeline.

One edge case worth knowing: if the frame count is already valid but the clip has no audio, it doesn't take the fast path - it calls the same fit routine, which synthesises a silence track. That's the behaviour LTX's audio path wants, and it means a silent clip with a correct frame count still comes out with an audio component rather than a None that trips up LTXVAudioVAEEncode.

The single output is a VIDEO.

Where it sits in an LTX graph

After the clip selection and the optional reference-audio swap, before anything touches the audio VAE or the conditioning. In the pack's LTX 2.5 route the order is: reviewed shot → (GenjApplyReferenceAudio if you're replacing speech) → GenjLTXFramePad → split into audio and image components → audio VAE encode, and the pose guide gets padded the same way with a tail frame so the two agree frame-for-frame.

The important consequence is that the video model generates the padded length, and the decoded result is trimmed back to your chosen interval afterwards. The pack's own validation notes record exactly that: LTX "pads its generation guide to the model's required frame count, then trims the decoded result back to the exact selected interval", with five-second tests returning exactly 120 frames at 24 fps.

So: pad on the way in, trim on the way out, and never let a 120-frame take reach the sampler unfixed.

Install

ComfyUI Manager → search Zura Nodes → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_zura_nodes/requirements.txt

Nothing to download for this node, and no ffmpeg call - it's tensor padding. The LTX 2.5 stack around it is where the weight files live: the distilled 22B transformer, the video and audio VAEs, the spatial upscaler and the union control LoRA, all listed with links in INSTALL_STUDIO.md. LTX is the light end of local video - the pack measured motion-guided whole-scene 1080p at about three and a half minutes on a 16 GB card, versus about ten minutes for H3 and twenty-five for Wan.

Gotchas

• Don't pad twice, and don't pad by hand. If you add frames upstream with an ImageBatch, this node will happily pad the already-padded count to the next 8n+1 - which is fine, but your trim-back length is now wrong, and you'll get a take with a frozen tail.
• The audio is fitted, not preserved. If your reference track is longer than the padded clip, the excess is discarded here. Attach audio before this node, not after, and give it a track at least as long as the clip.
• A static tail frame is a real frame. Models will generate motion from it. On a clip that ends mid-gesture, the last half-second of a padded take sometimes drifts. Trim the decoded output back to your chosen interval and check the tail if the shot matters.