Sume video trim output: libx264, yuv420p, AAC, exact vs keyframe
Exact trim re-encodes with libx264 and yuv420p, audio as AAC; keyframe copies the stream. Neither YouTube's Shorts nor TikTok's ad page names a codec.

Sume's video trim has two modes. exact, the default, re-encodes with libx264 and yuv420p and remuxes kept audio as AAC. keyframe copies the stream with no re-encode, and the cut can start a GOP early. YouTube's Shorts help page and TikTok's ad spec page, the two I could read, name no codec, so neither mode is called required or forbidden.
The two modes
| Option | What it does | Use when |
|---|---|---|
| precision: exact (default) | Frame-accurate re-encode: libx264, yuv420p; audio AAC | You need the cut on the frame, or to change width, height or fps |
| precision: keyframe | Stream copy; cut may start a GOP early; re-base times with actual_start_seconds | The source codec is already right and a few frames of slack are fine |
| YouTube Shorts page | No codec listed | - |
| TikTok non-Spark ad page | Codec not specified | - |
What else trim can do
The output field conforms width, height and fps for exact mode only, with width and height from 256 to 2160 and fps of 24, 25, 30 or 60. audio: "drop" removes the sound, which helps when you will lay your own track in Timeline. Limits are a source of up to 1800 seconds and an output of 0.2 to 900 seconds.
That output range matters for the Shorts case. A 3-minute Short is well under 900 seconds, so a trim of a rendered Timeline file is fine.
{
"video_url": "https://media.sume.com/artifacts/artf_demo/long.mp4",
"start": 2.0,
"duration": 58.0,
"precision": "exact",
"audio": "keep"
}Choosing for a Short
For a finished Short, use exact. You are cutting a clip you will publish, and a start that lands a few frames early is a visible flaw on a 3-second hook. The cost is one re-encode, which for a clip this short is small in time and in the price the doc lists for the job.
Use keyframe for scratch work. If you are cutting a long source to find the good section, a stream copy is faster and loses nothing, and you can follow it with an exact pass on the part you keep. Remember to re-base times against actual_start_seconds after a keyframe cut, since the real start can differ from the one you asked for.
Neither mode changes the platform's view of the file. Whether it is accepted depends on rules that the two pages I read do not state. A first upload of a trimmed file to the real platform is the only test that counts.
Tradeoffs and unknowns
Exact costs a re-encode and a generation of quality loss; keyframe does not, but its start time may be early. Whether an H.264 file with AAC audio is accepted by a given platform is a question for that platform's upload tool, since the pages I read are silent on it. The trim input must be a Sume-hosted clip: the doc rejects off-host URLs. Plan for the clip-first step, as in the vertical Short order.
Sources
Related posts
More in Media tools
- Timeline slots must reach within 0.5 s of the voiceover: 24 s example
Lay out Sume Timeline 1.0 for a 24-second voiceover: four 6-second slots from 0, last within 0.5 s of the end. Plan it free, render for $0.10.
- Sume timeline with silent audio: audio.mode silence and its limits
Set audio.mode to silence in Sume Timeline 1.0 for a declared length with no spine file. Do not send url, parts, gain_db or source_in, and no ducking bed.
- Compose stacks a still over a video for up to 300 seconds, flat $0.02
A 3-minute Short with a headline image on top fits Sume timeline compose's 300-second ceiling at a flat $0.02. How the stack is sized and what clamps.
- Timeline invalid_segment_timing and segment_overlap: fix your starts
Sume timeline returns invalid_segment_timing or segment_overlap when video starts do not increase or slots overlap past the transition. Fix the start values.
Written by Sume