Keyframe trim starts early: fix it with actual_start_seconds

If a video-trim with precision: "keyframe" gives you a clip that starts a little before the time you asked for, that is how stream copy works: the cut begins at the nearest earlier keyframe. The job result tells you where it really began in actual_start_seconds, and the docs say to re-base against that value. If you need the exact frame instead, use precision: "exact", the default.

The two modes

Trim takes a start and exactly one of end or duration (0.2 to 900 s) and always returns a new artifact.

Re-basing

Say you asked for start: 100 and the result reports actual_start_seconds: 98.2. The new file begins 1.8 s earlier than you wanted. Anything that used source time 100 as its anchor now sits 1.8 s into the new file. In a Timeline 1.0 slot that means source_in: 1.8 skips the early part and lands on the frame you asked for. The same offset applies to caption timings or cue points that you measured on the original.

• New position in the clip = old position - actual_start_seconds.
• Use source_in on the timeline slot, so you do not need a second trim.
• If the offset is more than you can tolerate, switch to exact and pay the re-encode time.

When to pick which

Use keyframe mode for a first pass over many long sources where speed matters and a second or two of lead-in is harmless, for example when you are going to place the file in a timeline slot with source_in anyway. Use exact mode for final cuts that start on a spoken word or a visual beat. If a clip will be captioned, remember the captions run on the file you give them, so caption the trimmed result, not the original.

Limits

Keyframe mode is for speed and for keeping the source quality bit for bit, not for precision. A source with sparse keyframes can start several seconds early. output conforming (resize, fps) is not available in this mode, and the audio option keep or drop still applies. Check warnings[] on each result.