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.

4 min readSume
All posts

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

Video trim precision options from Sume's docs, with platform codec rows (read 2026-10-06)
OptionWhat it doesUse when
precision: exact (default)Frame-accurate re-encode: libx264, yuv420p; audio AACYou need the cut on the frame, or to change width, height or fps
precision: keyframeStream copy; cut may start a GOP early; re-base times with actual_start_secondsThe source codec is already right and a few frames of slack are fine
YouTube Shorts pageNo codec listed-
TikTok non-Spark ad pageCodec 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

All Media tools posts

Written by Sume