LTX frame counts must be 8k+1; Sume durations are whole seconds

A valid LTX frame count is 8k+1: 9, 17, 25, 33 and so on up to 121. LTX's post says a request for 30 frames does not round up to 33; it is invalid input. Sume has no frame-count field. You send duration in whole seconds and the catalog says which seconds each model accepts.

The rule is from LTX's post How to make longer AI videos, read 2026-10-01. Sume's side is from Video generation.

What is the LTX frame-count rule?

The post states that frame count must satisfy (F-1) % 8 == 0, because the video encoder compresses time by 8 after the first frame. Width and height follow a similar rule: multiples of 32. Every segment in a chain must be valid on its own, so plan the runtime as a sum of valid counts before generating.

Why do valid frame counts rarely land on whole seconds?

Because most whole-second counts fail the rule. At 24 fps one second is 24 frames, and (24-1) % 8 is not 0, so it is invalid; the nearest valid counts are 17 and 25. Two seconds at 25 fps is 50 frames, also invalid, while 49 gives 1.96 s as in the table. Only some combinations, such as 25 frames at 25 fps, land on a whole second. LTX's hosted API therefore exposes duration as a fixed set of seconds, per the same post (for example 6 to 20 seconds in even steps for the fast tier).

What does Sume ask for instead?

duration is an integer number of seconds, and the catalog field supported_durations lists the whole-second lengths each model supports. The docs say to check which resolutions, aspect ratios and durations are supported before submitting. There is also no pixel-size field: every v1 model reports supported_sizes: null, so size returns 400 unsupported_parameter. Use resolution plus aspect_ratio.

Sume's docs do not list an LTX model id, so the 8k+1 rule applies to LTX-hosted or self-run pipelines. See what Sume lists instead of an LTX id.

How do I convert between frames and seconds?

Divide frames by the clip's frame rate, as in the table. For the reverse, probe the delivered file rather than trusting a request: convert frames to seconds and read fps from a clip cover both.