Keyframe or exact trim for a TikTok ad: which keeps 516 kbps?

Use precision: "keyframe" when the source already clears TikTok's 516 kbps floor and you can accept a cut that starts a little early; the stream is copied, so the encoding is not changed. Use precision: "exact" when the cut must be frame-accurate, and expect a new libx264 encode whose bitrate you do not control. Sume rejects codec, crf and similar keys with ffmpeg_fields_rejected, so you cannot ask for a bitrate. In both cases, measure the result: file bytes x 8 / duration_seconds / 1,000 gives the average kbps.

The two modes

Video trim 1.0 cuts [start, end) from one Sume-hosted clip and returns a new MP4. The source does not change. The public rate is $0.02 for each job in both modes.

What TikTok asks for

The TikTok ad specification page (read 2026-10-08) lists, for non-Spark ads: 9:16 recommended with 540x960 as the minimum, mp4, mov, mpeg, 3gp or avi, up to 10 minutes, up to 500 MB and a bitrate of at least 516 kbps. The page states the floor and does not say which encoder to use. Sume's docs do not state a target bitrate for the exact re-encode either, so the floor is something to verify and not something to assume.

• A 15-second ad at 516 kbps is at least 967.5 kB (516 x 15 / 8 = 967.5 kB).
• A 30-second ad is at least 1.935 MB.
• If your measured result is under the floor, try the other precision on the same source, or re-trim from a higher-bitrate source.

A decision rule

Check the source first. If its average bitrate is well above 516 kbps, a keyframe cut keeps it, and the only cost is a cut point that may be up to one GOP early (the trim docs say it can start a GOP early and ask you to re-base your times against actual_start_seconds). For a hard 15-second limit that is a real risk, so check duration_seconds and actual_start_seconds in the result. If you need exactly 15.0 seconds, use exact and measure the size.

Whichever you use, upload the trim output as it is when a single clip is the whole ad. Sending it through a Timeline render adds a second job that compiles its own ffmpeg program, and the Timeline docs do not state a bitrate target either, so you would have to measure again. The same rule holds for video filter: it returns a new MP4 and gives you no bitrate field.

A small worked check helps. A 15-second result of 1,100,000 bytes has an average of 1,100,000 x 8 / 15 / 1,000 = 586.7 kbps, above the floor. The same cut at 900,000 bytes is 480 kbps and fails. Because the average includes the audio track and the container, treat a result near 516 kbps as a fail and re-cut.