Video filter caps sources at 300 s: handling 5-minute TikTok videos

Video filter accepts a source of up to 300 seconds, so a 5-minute TikTok video is the longest file it takes, and a 5:01 file fails with output_duration_exceeded. Trim the file into parts of 300 seconds or less first, filter each, and join if you need one file. Each trim is $0.02 and each filter is $0.02.

TikTok is reported to favour 3 to 5 minute videos right now, per Metricool (read 2026-10-03), which lands episodes on the edge of this limit. The cap is documented on the video filter page, and the sections below explain how the free check behaves around it.

Where the limit shows up

The video filter route runs ffmpeg filters on the worker and bills $0.02 per job. The free POST /v1/video-filter/check route validates the request body against the allowlist and probes the media URL. It does not prove that the job will fit: the length of the source is only measured when the worker runs. A request that passes /check can still fail on the worker for a source over 300 seconds, with output_duration_exceeded.

That is why the check result should be read as the allowlist verdict and not a guarantee. If you already know the length from a video inspect probe, compare it to 300 yourself before submitting.

Splitting first

Video trim takes a source up to 1800 seconds and writes an output up to 900. So a 7-minute episode (420 seconds) is trimmed into two parts, each under 300 seconds, and each part goes to filter. The helper below builds the ranges.

Trim re-cuts on the range you give it, so aim the break at a scene change or a quiet moment. For a stricter cut, inspect's sentence segments give you the seconds.

import math

def split_for_filter(source_seconds, limit=300):
    """Return trim ranges so each piece fits video-filter's 300 s source cap."""
    parts = math.ceil(source_seconds / limit)
    return [(i * limit, min((i + 1) * limit, source_seconds)) for i in range(parts)]

ranges = split_for_filter(270 + 30 + 120)   # a 7 minute episode
for start, end in ranges:
    print(f"trim {start}-{end} s, then filter")
print("extra cost: $", round(len(ranges) * 0.02, 2))

Worked examples

A 4:30 episode needs no split: one filter job, $0.02. A 5:00 episode is exactly at the limit; if you measure it as 300.04 seconds, trim to 299 seconds first and accept losing the last second, or trim in two. A 7-minute episode is two trims and two filters: $0.08 in total, and the helper above prints the ranges.

Take a 12-minute episode that you want to colour-correct and crop for a 9:16 post. Four trims of 180 seconds (all under 300) cost $0.08 and four filters cost another $0.08, so the pipeline is $0.16 before any join. A Timeline 1.0 render at $0.10 per output minute would add $1.20 for the 12-minute join, so decide whether you need one file at all.

If you only want a crop of the first 5 minutes, use trim with the end set at 300 seconds and run the filter on the result. That is $0.04 and no failure.

What Sume does and does not do here

• Sume does not split automatically: a source over 300 seconds fails the filter job rather than being chunked for you.
• Sume does give a free /check for the filter body, but it does not measure duration.
• Sume prices each step at a fixed public rate, so a split pipeline's cost is the count of jobs times $0.02.
• Sume results come back as an async job; poll GET /v1/jobs/:id/status until terminal.

What to do

Probe the length with inspect, route anything over 300 seconds through trim first, and keep each piece with a margin of a second or two. Use the free check for the filter body and your own comparison for length.

Log the probed length next to each job so that a refusal is easy to explain later. A source that is a fraction over the limit is the most common surprise, so keep a one-second margin in your split ranges and treat any piece over 299 seconds as needing another cut.