EmptyLTXVLatentVideo

LTX's whole identity is speed, and the speed starts here - with the most compressed latent in consumer video. EmptyLTXVLatentVideo creates the blank video latent that every LTX text-to-video generation denoises into a clip. It's the video sibling of Empty Latent Image, but the shape tells you why LTX is fast: where SD-class models use a 4-channel latent at 8× compression, LTX uses a 128-channel latent at 32× spatial and 8× temporal compression. It throws away far more aggressively, which is exactly why it generates seconds instead of minutes - and why its detail ceiling sits below Wan's.

Four inputs:

• width / height - default 768×512, step 32. Notice the step: LTX latents are 32× smaller per side, so dimensions must be multiples of 32. Off-grid values fail.
• length - default 97, the number of frames, step 8. LTX compresses time 8×, so frame counts follow the 8k+1 pattern: 97, 121, 249... 97 frames is roughly 4 seconds at 24 fps, the classic launch-era clip.
• batch_size - default 1.

Output: a LATENT shaped [batch, 128, (length-1)/8 + 1, height/32, width/32] with downscale_ratio_spacial: 32 metadata.

The length math, made simple

LTX's temporal compression is 8×, so every 8 frames of video collapse into one latent frame. That's why the defaults look weird: 97 frames isn't an arbitrary number, it's (96/8)+1 - the +1 being the model's anchor frame convention. If you set a length that isn't 8k+1, it rounds to the nearest valid value or errors, depending on the node version. The community's old 0.9.x habit was 121 frames; LTX-2 era settled on ~97 at 24–25 fps.

Where it fits

The T2V graph: this node → KSampler with LTX conditioning (LTXVConditioning, or the LTX text encoder) → VAEDecode → Save WEBM. For image-to-video you don't use this node - LTXVImgToVideo builds the latent from a start image instead. This node is the "from nothing" path.

What people get wrong

• The 32× step is not negotiable. This is the #1 new-user error: 640×512 works, 650×512 fails. LTX-2.3 made the constraint explicit ("width and height must be divisible by 32, frame count divisible by 8 plus 1") but the node had the same rule all along.
• Resolution is a quality dial, not just a size. LTX-2 renders internally at half your requested resolution and upscales - so a 768×512 request is really ~384×256 before the internal upscale. If you want quality matching Wan's 720p, you need to ask for 1080p. The community consensus is blunt: request big, let the model's internal upscale do its job.
• Length versus duration. There's no FPS field here - duration is frames + your chosen frame rate on the conditioning/scheduler side. If your clip comes out wrong-length, check the frame rate on the LTX side, not this node.
• It's the 0.9.x / LTX-1-era node. Audio-video LTX-2 workflows use LTXV Empty Latent Audio for the audio half and this node (still, via the same 128-channel structure) for the video half. Don't go hunting for a different video node - this one is current.

The node with the strangest-looking numbers in the graph is also the one that explains the whole model: 128 channels and 32× compression is the bet LTX made on speed, and it's why a 6GB card can draft a clip in seconds. The numbers look like typos until you realize they're the point.