Turning published lengths into a shot plan
A shot plan needs durations. Published lengths arrive as frames, as seconds, as a rule the code enforces or as an adjective, and turning them into a plan means normalising the units and then adding the work the units hide. As of 2026-09-12.
| Published form | What it needs |
|---|---|
| Seconds with a rate | Nothing |
| Frames with a rate | One division |
| Frames without a rate | The rate, from the code |
| An adjective | A test run |
Inclusion rule. Forms a published clip length takes. A form that cannot be planned with at all is listed, because it appears in this register. Order. From the form that needs no work to the form that needs a test.
1Assembly is the hidden cost of short clips
A release that produces four or five seconds cannot deliver a scene in one call, so continuity between clips becomes the production problem: the same face, the same light, the same room across a cut that was never planned.
That cost does not appear in any published figure. It is the reason a fully specified five seconds and an unspecified minute are not simply two points on one scale.
2Long clips move the cost into the run
A release that states a minute puts the scene inside one generation, which removes the assembly work and multiplies the memory the run holds. It also raises the cost of each failure, because a failed minute wastes far more card time than a failed five seconds.
Neither arrangement is better. They are different production shapes, and the published length is what decides which one a release imposes.
3Convert units before comparing anything
Frames and seconds are not comparable without a rate, and published rates in this register range from fifteen to thirty frames a second. A plan that mixes a frame ceiling from one release with a duration from another has compared nothing.
Where the rate is not published, the honest step is to find it in the code rather than assume a convention. An assumed rate is the part of a plan that will be wrong quietly.
4Accepted length is not usable length
A frame ceiling says what the code accepts. How far consistency holds across a long generation is a separate property that no repository in this register measures, and it is usually the binding constraint.
So a stated maximum is an upper bound on the plan and not a target. Testing one clip at the intended length is the only way to find where the real limit sits.
5Budget the retries explicitly
Generative video produces unusable output often enough that retries are a meaningful share of total compute. A plan that budgets one generation per shot will run out of card time before it runs out of shots.
No release publishes a failure rate, so the multiplier has to come from a pilot. One episode generated end to end is worth more than any published figure for this purpose.
6Write the target down before reading the column
The resolution and clip length the work actually needs should be decided before looking at any release, because otherwise the published headline becomes the plan. Most headline figures are the largest configuration a vendor measured.
With a target in hand, the column becomes a filter: which releases state a figure at or above it, and which leave the question open.
7Where the repository figures are kept
The techniques above are general. Which vendors have published what, under which licence and on what hardware, is recorded on the model pages, each figure quoted from the repository it was read from with its date.
- The length column — frames against seconds
- Clip length — what it changes about a plan
- Temporal drift — the limit behind a ceiling
Craft notes on reading releases. No row here is attributed to a vendor, and nothing on this page is a reading of anyone's licence obligations. The sourced material is on the requirements page. Related: A ten-minute check, Two figures.