Frames against seconds for the same decision
One card states that quality holds below 257 frames at thirty frames a second and that accepted counts divide by eight plus one. One reference states an integer in the range two to thirty seconds. Every ad slot in this register is written in seconds. As of 2026-09-22.
| What the pages state | LTX-Video | Wan 3.0 |
|---|---|---|
| Unit | Frames, with a rate stated separately | Whole seconds |
| Legal values | Divisible by 8, plus 1 | Any integer in the range |
| Directly comparable to a slot | No | Yes |
Inclusion rule. Length statements from each page in the unit each uses. No conversion is recorded, because a converted figure would carry a check date it did not earn. Order. The unit first, then what constrains the values inside it.
1What the conversion throws away
Frames below 257 at thirty a second is a little over eight seconds. Legal counts are 249, 241, 233 and downwards in eights, so the available lengths are a sparse set rather than a range, and a seconds figure implies a range.
On the seconds row every whole value between two and thirty is available. The two cells look like the same kind of statement in a table and describe a continuum on one row and a lattice on the other.
2Why the pages are written differently
One is a model card for weights someone runs, where the frame count is the quantity being budgeted against memory. The other is an API reference for a hosted service, where a caller thinks in seconds because that is what the brief says.
Neither is careless. The register records the unit as part of the cell for that reason, and marks the frame row hollow in the seconds column rather than filling it with arithmetic nobody published.
3Against the same slot the two rows diverge sharply
Thirty seconds is one request on the seconds row and four on the frame row, working from the card's own guidance. Sixty is two against seven, and every extra piece is a seam.
The frame row also states its resolution as a single pixel pair and its rate as a single value, so nothing about the output can be traded for length. The seconds row publishes three tiers with no condition tying any of them to the range at all.
4The rest of the column behind these two
| Generator | Duration |
|---|---|
| Amazon Nova Reel | 6 s increments, up to two minutes |
| CogVideoX | 6 s, at 49 frames |
| Google Veo | 4, 6 or 8 s |
| Grok Imagine | 1 to 15 s |
| Hedra | 10 minutes |
| HeyGen | 30 minutes per scene |
| Kling AI | Not stated |
| LTX-Video | Frames, never seconds |
| MiniMax | 4 to 15 s |
| Pika | 5 s and 10 s, 20-25 s on Pikaframes |
| PixVerse | 1 to 15 s on version 6 |
| Runway | 5 to 15 s on Gen-4.5 |
| SceneMixer | Thirty seconds on the Wan tiers, fifteen on H3 |
| Vidu | Not stated |
| Wan 3.0 | 2 to 30 s |
Inclusion rule. Every generator this register carries, on the one column this pair disagrees about. Rows that state nothing keep their place and are marked hollow. Order. Alphabetical by generator name.
Why these two. The arithmetic between them is trivial and it destroys a constraint: a seconds figure computed from the frame ceiling lands on counts the model refuses. The unit carries information the conversion loses.
- Where the card says quality holds; length is published in framesWorks best on resolutions under 720 x 1280 and number of frames below 257not seconds
- Duration parameterAn integer in the range [2, 30] seconds, and input plus output must not exceed 30 seconds
5Sources
Read from the Lightricks LTX-Video model card and the Wan3.0 API reference, both checked 2026-09-22. The column is described on duration, and each entry has its own cell page at LTX-Video and Wan 3.0, and the rule that keeps surfaces and generators apart is on method. Nearby pairs: Runway and HeyGen on files, CogVideoX and LTX-Video.