Trailer from 24 shots in 30 seconds: Timeline fade and cut rules

24 shots of 1.25 seconds make a 30-second trailer in one Sume Timeline render at $0.10. Slot minimums, the 8-fade limit, chunking past 12 slots.

5 min readSume
All posts

A 30-second trailer of 24 shots at 1.25 seconds each is one Sume Timeline render: 24 video[] slots against a 30-second audio spine, billed at ceil(30 / 60) = 1 minute, $0.10. Three limits shape the edit. A slot must be at least 0.2 seconds, no more than eight transitions can chain, and a render past 12 slots is chunked.

Slot timing for 24 shots

Each slot has a start on the audio spine and a duration. video[0].start must be 0 and later starts must increase. Declared starts are authoritative, and the compiler compensates for crossfades without pre-shifting your times. Coverage can stop at most 0.5 seconds before the end of the spine, so 24 x 1.25 = 30 seconds fills a 30-second spine exactly.

Trailer program numbers, as of 2026-10-08 (docs.sume.com/models/timeline)
ItemValueRule
Shots24video[] allows 1 to 200 slots
Shot length1.25 sMinimum 0.2 s
Spine30 saudio.duration_seconds 1 to 1800
Billable minutes1$0.10 per ceil(output minute)

Fades, then a hard cut

A transition is allowed only on slots after the first. The type is one of fade, wipeleft, wiperight, slideup, slidedown, or dissolve. The duration is at most 1 second, at most 50% of the shorter neighbor, and at least one output frame. In a 1.25-second shot, 0.25 seconds is a safe fade.

More than eight adjacent fades fail with too_many_chained_transitions. In a fast trailer, fade on the beats that matter and leave the rest as cuts. A pattern such as fade, cut, cut, fade across 24 slots keeps you well under the cap.

Why the render is chunked

The default render.strategy is auto, which chunks once a render passes 12 segments. You can set chunked yourself. Sume refuses single above 12 slots with render_strategy_unsafe, so do not force it for 24 shots. The chunking changes how the worker builds the file, not what you pay: the price is still per output minute.

Plan, then render

POST /v1/timeline-1.0/plan compiles your program without creating a job. It returns duration_seconds, segment_count, billable_minutes, and estimated_cost_usd_micros. For this trailer, expect 24 segments and 1 billable minute. A plan cannot predict warnings about padded or looped short sources, so read warnings[] on the finished result.

Render needs an Idempotency-Key. Poll GET /v1/jobs/:id/status and GET /v1/jobs/:id/result since Timeline has no GET /v1/timeline-1.0/:id. Every source URL must be a media.sume.com artifact of your workspace.

Cutting the trailer from longer footage

Most trailer shots come from longer clips. Use video trim to cut each [start, end) to the slot length first, at $0.02 a cut, or set source_in on the slot to start inside the file. Trimming first costs more but gives you a durable clip you can reuse in a second cut, such as a 15-second version of the same trailer.

A 15-second cut is a second render of 12 slots at 1.25 seconds, also one billable minute. Two versions of the trailer therefore cost $0.20 in renders. Keep the slot list in a file you own and generate both programs from it.

Shots that run short

If a source clip is shorter than its slot, the job pads or loops it and adds a soft warning. That is not a failure, but a looped one-second clip in a two-second slot shows. For a trailer, trim to the exact slot length first, so the cut you see is the cut you planned. Add a soundtrack bed with duck_db only if there is a spoken line, because ducking needs a real spine.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume