LTX 2.3 Resolutions and Frame Count Rules

Two numbers decide whether an LTX 2.3 run starts at all, and both look arbitrary until you know where they come from:

• Width and height must be divisible by 32
• Frame count must follow the 8k+1 pattern — 97, 193, 385, and so on

Neither is a preference. They fall directly out of the Video VAE's compression, and every pipeline that accepts a video enforces them. Get them wrong and you get a rejection or a silent snap to a different value.

This guide explains why the rules exist, how two-stage upscaling changes which resolution you should request, and how to think about clip length in a model where audio and video are tokenized differently. Sourced from the LTX-2.3 model card, ltx-core documentation, and the pipeline docs, checked July 2026.

Where the ÷32 rule comes from

The Video VAE encoder compresses pixels [B, 3, F, H, W] into latents [B, 128, F', H/32, W/32].

There it is: H/32, W/32. 32× spatial compression into a 128-channel latent space. A dimension that does not divide evenly by 32 has no clean latent representation, so the constraint is structural rather than a validation choice someone made.

The 8k+1 frame rule comes from the temporal side of the same compression — frames compress in blocks, and the +1 is the anchor frame that makes block arithmetic work out.

Once you see it this way, the rules stop feeling like obstacles and start working as a planning tool: pick dimensions in multiples of 32 from the start and you will never see the error.

Legal frame counts worth memorizing: 97, 193, 289, 385, 481.

Common legal resolutions:

Note what is missing: 1920×1080 is not legal — 1080 ÷ 32 = 33.75. The nearest legal height is 1088. This catches almost everyone once, usually while trying to match a delivery spec.

The two-stage twist: request half, deliver double

Here is the planning subtlety that trips up people who have the ÷32 rule memorized.

The recommended production pipelines are two-stage: stage 1 generates at low resolution, stage 2 upsamples to 2× with distilled-LoRA refinement. So the resolution you configure for stage 1 is not the resolution you get.

Which means your stage-1 target must be legal and its doubled result must be legal too:

Work backwards from the delivery resolution: halve it, confirm both numbers are multiples of 32, and use that for stage 1.

There is also a 1.5× spatial upscaler (ltx-2.3-spatial-upscaler-x1.5-1.0.safetensors) if a 2× jump leaves stage 2 inventing more detail than you want. Smaller jump, closer to target in stage 1, less drift between stages.

And if you skip two-stage entirely: TI2VidOneStagePipeline outputs typically 512×768 and is documented as primarily for educational purposes. It is not the shortcut to fast production renders that it looks like.

Not sure which delivery resolution you even need yet? Format decisions are easier once you have seen output. ltx23.app runs LTX 2.3 in the browser, including native portrait, so you can check framing before you plan a render pipeline around it.

Portrait works natively

ComfyUI's documentation notes LTX 2.3 handles native 9:16 portrait output without any cropping — one of the more practically valuable properties for anyone doing short-form.

Generating landscape and cropping to vertical loses composition and forces you to shoot loose. Generating vertical natively means the framing you prompted is the framing you deliver. Just keep both dimensions on the ÷32 grid: 704×1280 and 1088×1920 are your friends.

Frame rate, duration, and the temporal upscaler

Frame count and frame rate together determine duration — and different pipelines handle them differently, which is the source of most confusion here:

• Standard pipelines take frame count and frame rate as arguments; keep the count on 8k+1.
• LipDubPipeline derives both from the reference video, and the frame count is silently snapped to the nearest 8k+1. The CLI does not accept --num-frames or --frame-rate at all. If your dub comes out marginally shorter or longer than the reference, that snap is why.
• T2AOneStagePipeline derives audio duration from --num-frames and --frame-rate, using the same 8k+1 convention even though there is no video.
• A2VidPipelineTwoStage adds --audio-start-time and --audio-max-duration for working with a section of a longer track.
• HDRICLoraPipeline has --high-quality, which generates 2× frames internally for smoother output and is roughly 2× slower.

For frame rate specifically, there is a temporal upscaler — ltx-2.3-temporal-upscaler-x2-1.0.safetensors, described on the model card as an x2 temporal upscaler for higher FPS. Before you plan around it, read the status note in the README: it is supported by the model and will be required for future pipeline implementations. The capability is in the weights; the shipped pipelines are not built around it yet.

Why longer clips cost more than you expect

Once latents are patchified into a token sequence, attention cost scales with sequence length — and sequence length is driven by resolution and frame count together. Doubling duration is not a small ask.

Audio scales separately: the Audio VAE tokenizes at roughly 1/25 s per token, so audio cost tracks duration alone, regardless of frame size. A long clip is expensive on both axes for different reasons.

The workflow that follows:

1. Generate short. Prove the shot works at a modest frame count.
2. Extend rather than regenerate longer — video and audio extension are supported conditioning modes in the trainer's config set.
3. Retake bad windows instead of rerolling whole clips.
4. Assemble in an editor. LTX Desktop ships a video editor and editing projects for exactly this reason.

As for the headline capability numbers — native 4K, up to 50 fps, clips beyond 60 seconds — those are reported for the LTX-2 family in third-party coverage such as Wikipedia's entry, which is a secondary source. What the LTX 2.3 model card itself constrains is the ÷32 and 8k+1 arithmetic. Plan against the documented rules, treat the ceiling numbers as marketing-adjacent until you have hit them on your own hardware.

A planning checklist

• Delivery resolution chosen and both dimensions ÷32
• Halved for stage 1, and that is also ÷32
• Frame count on 8k+1
• Portrait? Use native dimensions, do not crop later
• Long clip? Plan to extend rather than one-shot
• Using LipDub? Expect the reference video to dictate length
• Source footage for retake/v2v re-encoded to legal dimensions first

FAQ

What resolutions does LTX 2.3 support? Any where width and height are divisible by 32. 1920×1080 is not legal; use 1920×1088.

Why 8k+1 frames? Temporal compression in the Video VAE works in blocks with an anchor frame. 97, 193, 289, 385 are typical legal counts.

What resolution should I set for a two-stage render? Half your delivery resolution, with both stage-1 and doubled dimensions divisible by 32.

Does LTX 2.3 do vertical video? Yes — native 9:16 portrait without cropping, per ComfyUI's documentation.

How do I increase frame rate? A temporal upscaler exists for higher FPS, but the README notes it will be required for future pipeline implementations; today's shipped pipelines are built around the spatial one.

How long can a clip be? The documented constraints are the ÷32 and 8k+1 rules, not a published maximum. Longer clips cost more on both video tokens and audio tokens; extending from a short clip is the recommended shape.

Bottom line

The two rules that look arbitrary — ÷32 and 8k+1 — are the VAE's compression showing through, and planning around them takes about thirty seconds if you do it before rendering instead of after a rejection.

The one that actually needs thought is the two-stage halving: work backwards from delivery, keep both stages legal, and pick the x1.5 upscaler when a 2× jump drifts too far. To sanity-check framing before any of that, generate one at ltx23.app.

Sources

Verified July 2026 against primary documentation:

1. Lightricks/LTX-2.3 — Hugging Face model card — ÷32 and 8k+1 rules, upscaler variants including temporal "higher FPS"
2. ltx-core package documentation — Video VAE 32× compression, Audio VAE ~1/25 s per token, patchification
3. LTX-2 available pipelines documentation — one-stage 512×768, LipDub frame snapping, A2Vid audio args, HDR --high-quality, retake constraints
4. Lightricks/LTX-2 — official GitHub repository — temporal upscaler status, two-stage recommendation
5. ComfyUI official LTX-2.3 tutorial — native 9:16 portrait without cropping
6. LTX-2 installation & CLI flags — shared CLI arguments
7. LTX-2 optimization documentation — sequence length and compute trade-offs
8. ltx-trainer configs — video and audio extension conditioning modes
9. Lightricks/LTX-Desktop — editor and assembly workflow
10. LTX-2 technical paper (arXiv 2601.03233) — architecture reference
11. Wikipedia: LTX-2 — third-party capability reporting (secondary source, cited as such)

Legal resolution examples are derived from the published ÷32 rule; always confirm against the model card for your release.