LTXVConditioning

LTXVConditioning is a two-input, two-output node whose entire job is to tell LTXV (Lightricks' video model, the one that made local video generation feel fast) what frame rate to use. That's it. No latents, no images, no weights - it writes one number into your conditioning metadata and passes both sides through.

It sounds trivial, and honestly it is. But it's also required: LTXV is trained to interpret its temporal dimension in terms of a frame rate, and if the conditioning never states one, the sampler doesn't know whether 97 frames is 4 seconds or 6. That single number is the difference between natural motion and everything drifting in slow-motion mush.

How it works

You feed it the positive and negative from your CLIPTextEncode (LTXV uses its own text encoder), plus one float:

• frame_rate - default 25, the FPS the generation should be interpreted at.

It writes frame_rate into the metadata of both conditionings and hands them back unchanged otherwise. Outputs are positive and negative, which then go to your KSampler. There's a matching ModelSamplingLTXV node on the model side that patches the sampling schedule - the two work as a pair, but this node's job is purely the frame-rate stamp.

What matters in practice

• The default is 25 and usually fine. LTXV's community sweet spot for a clip is around 121 frames at 25fps ≈ 5 seconds. Set the frame rate to what you'll actually output at, then decode and interpret accordingly.
• Match it with your VAE decode. If you stamp 30 but your workflow decodes at 24, your timing is off even though the video renders. The frame rate is a contract between conditioning and playback.
• It's LTXV-specific. Same shape as ConditioningStableAudio, but that node targets Stable Audio and this targets LTXV - the metadata keys aren't interchangeable, so don't try to reuse one for the other.

Gotchas

Nothing happens if you're not on LTXV. Feed it Wan or SDXL conditioning and it writes a key nothing reads. This is a model-family node, pure and simple.

Don't expect it to change motion quality. People sometimes treat frame_rate like a motion dial - crank it to 60 and hope for smoother animation. It doesn't work that way. The model was trained around its native rates; the node just sets interpretation. If motion is stiff, that's a sampling or model issue, not a frame-rate field you can dial up.

Where it sits in the graph: after text encode, before the KSampler, alongside the LTXV latent/image nodes. It ships in ComfyUI core (comfy_extras/nodes_lt.py), and the whole LTXV 0.9.x line - the 2B that runs in seconds on modest GPUs and the 13B that needs real hardware - uses it. For the money, it's the easiest "why does my LTXV clip move wrong" fix in the pipeline.