Trim an AI clip's slow intro for a Short: keyframe cut or exact cut?

Use precision: exact when the cut must land on the frame you asked for, and keyframe only when a slightly early start is acceptable. The video trim docs say exact is a frame-accurate re-encode with libx264 and yuv420p, and keyframe is a stream copy where the cut can start a GOP early.

Why trim at all

AI clips often open with a settling second: a camera drift, a fade from nothing, or a subject that has not yet entered. Cutting that off makes the first frame of a Short count. Both precisions take the same start, and the difference is where the cut lands and what the file looks like afterward.

Two precisions

The docs name the differences in their own words. The rows below are from the page (read 2026-10-05).

What keyframe costs you

Because keyframe copies the stream, it does not re-encode and can be faster. The docs do not give a speed figure, so I do not state one. The trade is accuracy: if you ask for start: 2.0 and the nearest earlier keyframe is at 0.9, the output opens on that earlier frame, and the response gives you actual_start_seconds so you can see the real in-point.

An exact cut

For a Short, exact is the safer default, and it is the default in the API when you leave precision out. This cut drops the first 1.5 seconds of a clip and keeps 20 seconds:

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: trim-intro-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4",
    "start": 1.5,
    "duration": 20,
    "precision": "exact",
    "audio": "keep"
  }'

Rules for the range

Send either end or duration, not both. A missing range gives video_trim_range_required. A value past the end of the source clamps, and the result warns with trim_clamped_to_source. The output must be at least 0.2 seconds and at most 900 seconds, from a source of at most 1800 seconds. The price is $0.02 per job.

Conform while you cut

With exact precision you can also conform the output with output: { width, height, fps }, where width and height run from 256 to 2160 and fps is 24, 25, 30 or 60. If you leave it out, the output keeps the source values. That is handy when a model returns an unusual frame rate and you want 30 for the upload.

Check against the platform

Then check the result against YouTube's own limit. The YouTube Help page for Shorts (read 2026-10-05) gives 3 minutes as the maximum length, and a 20 second cut is well inside it.

Why a stream copy starts early

A GOP, or group of pictures, is the run of frames between two keyframes. A stream copy cannot start in the middle of one, because the frames in the middle depend on the keyframe before them. That is why the docs say a keyframe cut can start early, and why the page tells you to re-base your times against actual_start_seconds. The docs give the figure for typical sources only in the inspect page, where a fast still can be about 0 to 5 seconds early; do not assume the same number for a trim, and read the field.

A rule of thumb

A workable rule: if the first frame matters, because it is the frame a viewer sees before they scroll, use exact. If you are only cutting a long recording down to a section and a second of lead-in does not matter, keyframe is fine. Many pipelines use keyframe for a first rough cut and exact for the final upload file, and since each call is $0.02, the cost of doing both is small.

Look at the first frame

Check the result with stills. A video inspect call with frames.at set to [0] shows the first frame of the trimmed file, and a second at the end shows how it finishes. If the first frame is not the one you wanted, re-run the cut with a later start and exact precision.

The takeaway

Use exact for anything you will upload, keyframe for a quick rough look, and read actual_start_seconds whenever you use keyframe.