TikTok ad 516 kbps bitrate floor: smallest file for 10 minutes

TikTok's In-Feed ads page lists a bitrate of at least 516 kbps and a file size of at most 500 MB for non-Spark video ads, with a duration of up to 10 minutes. For a 10-minute ad that is a floor of about 38.7 MB and a ceiling of 500 MB, and Sume gives you no knob to aim anywhere inside that window.

The numbers are quoted from TikTok's page (read 2026-10-10). The arithmetic is mine and treats a megabyte as 1,000,000 bytes, because the page does not say which megabyte it means.

What TikTok lists for non-Spark ads

The page's non-Spark list reads: vertical 9:16 recommended at 540 x 960 pixels or more, horizontal 16:9 at 960 x 540 or more, square 1:1 at 640 x 640 or more, formats mp4, mov, mpeg, 3gp and avi, duration up to 10 minutes, file size of 500 MB or less, and bitrate of 516 kbps or more. The page does not say whether the bitrate is video-only or the whole stream, so I treat it as the whole file's average.

The arithmetic at both ends

Bitrate in kilobits per second times seconds, divided by eight, gives kilobytes. At 516 kbps, 600 seconds is 309,600 kilobits, which is 38,700 kilobytes, or 38.7 MB. The ceiling goes the other way: 500 MB is 4,000,000 kilobits, and spread over 600 seconds that is about 6,667 kbps, or 6.67 Mbps. So a 10-minute ad has a legal average bitrate window from 0.516 to roughly 6.67 Mbps.

Where Sume fits, and where it does not

Sume's video trim and Timeline render run a server-compiled ffmpeg command. Codec, crf and related fields are refused with ffmpeg_fields_rejected, and the docs describe no bitrate field. Exact trims re-encode with libx264 and yuv420p, and kept audio is remuxed as AAC. You therefore cannot ask for 8 Mbps or 2 Mbps; you get what the encoder produces for your content.

What you can control is length and frame size. A 10-minute clip at 1080 x 1920 is a large file, and a lower output size makes it smaller in practice. Timeline accepts output width and height as even integers from 256 to 2160, and 540 x 960 meets TikTok's vertical minimum. I have not measured the resulting bytes, so do not treat any size as promised.

A gate worth keeping

After the render finishes, measure the file in your own code: bytes times eight, divided by duration_seconds from the result. If the average falls under 516 kbps, which is unlikely for real video but possible for near-static footage, or the file passes 500 MB, change the length or the output size and render again. For lengths, a video trim job costs $0.02, and the Timeline plan call is unbilled, so the length gate is cheap while the size gate costs a render.

Sume's Timeline renders $0.10 per output minute rounded up, so a 10-minute ad is $1.00, per the Timeline docs. Re-rendering a failed size check costs the same again.

Because the encoder is out of your hands, treat file size as an output to verify, not an input to set. A talking-head clip with little motion tends to compress small, and a fast montage tends to compress large, but that is general encoder behaviour and not a Sume promise. If a 10-minute render lands near 500 MB, the cheapest fixes are a shorter cut, which a trim handles, or a smaller output frame, which Timeline handles through output width and height.

It also helps to remember that the 500 MB cap and the 10-minute cap are separate rules on the same page. A 4-minute ad can still be too large if its bitrate is very high, and a 10-minute ad can be tiny and still pass. Check both numbers every time instead of assuming one implies the other.