Trim an AI clip first, or use source_in on the timeline?

If you only need a shot shorter inside a stitched film, do not trim it first. Give the Timeline 1.0 slot a source_in (the in-point into the file) and a duration, and the render cuts it inline. Run video trim when you need a separate MP4 that another tool will consume.

Trim is cheap at $0.02 per job, but it is still an extra job, an extra artifact and an extra thing to track. Most shot-length edits do not need it.

What does source_in do on a timeline slot?

Each video[] slot takes source_url, start (where it lands on the spine), duration (how long it is on screen, at least 0.2 s) and source_in (the in-point into the file). A 15-second generated clip whose first 2 seconds are a slow settle can go in with source_in: 2 and duration: 6. The source file is untouched, so the same artifact can appear in another cut with different numbers.

There is no extra fee for this: a render is $0.10 per rounded-up output minute, whatever the slot settings.

When is video_trim the right tool?

Trim takes one media.sume.com clip plus start and exactly one of end or duration, and returns a new MP4 with only [start, end). The result is a new artf_ artifact, never the source. Use it when the cut itself must be a file:

- a downstream step needs a standalone file rather than a slot setting,

- you want to review or share the shortened clip on its own,

- you need the output conformed to a size or frame rate with the optional output field (exact precision only).

Trim's caps are a source up to 1800 seconds and an output of 0.2 to 900 seconds. end past the source clamps and warns trim_clamped_to_source.

Exact or keyframe: which precision?

For shots you will stitch, stay on exact. A keyframe cut that starts early puts a few unwanted frames at the head of your shot, which is exactly what you were trying to remove.

What does the request look like?

A trim is one POST with an Idempotency-Key. It is async by default, so poll GET /v1/jobs/:id/status and read GET /v1/jobs/:id/result, where video_url is the new artifact. Drop it into video[] with source_in 0.

Both routes reject ffmpeg fields such as vf, codec or crf with ffmpeg_fields_rejected; Sume compiles the cut itself.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: film-42-s2-trim-v1" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/s2.mp4",
    "start": 2,
    "duration": 6,
    "precision": "exact"
  }'

A quick rule for a multi-shot film

Use source_in and duration for pacing edits you will tweak several times. Use video_trim when a downstream step demands a file. If you are unsure where a clip's good frames start, pull a few stills first with video frames at the candidate in-points; it is unbilled, and at values must fall inside the clip or the worker fails with frame_time_out_of_range.

One honest limit: the docs do not state that timeline source_in is frame-accurate to the same degree as an exact trim. If a cut must land on one specific frame, render a short test and check the first frame with video_frames at 0 before you rely on it.