source_too_large on trim or filter: the 300 MiB source cap

source_too_large means the hosted file is bigger than the 300 MiB download budget: 314,572,800 bytes. The API reads the file's Content-Length with a HEAD request at submit and refuses before any job is created, so nothing is billed. The cap is on bytes, separate from the duration limits, which is why a short 4K clip can trip it while a long compressed one passes.

Which tools check it, and what are the other limits?

In the API source (apps/api/src/media-l2.ts and apps/api/src/video-filter.ts) the same preflight runs for video trim, audio detach, and video filter, and the error carries max_bytes and the offending content_length. The Video trim and Video filter pages list the duration caps next to it.

The free POST /v1/video-filter/check runs the same Sume-host and HEAD preflight as the encode, without a job, credits or a box, per the Video filter page. It is a cheap way to test a source before you commit.

Isn't trimming the way to shrink a big file?

Not here. Trim goes through the same preflight, so a 400 MB source is refused before the cut can make it smaller. With raw FFmpeg that problem does not exist, because ffmpeg -i reads whatever it is pointed at.

The practical routes are to make the file smaller before it is hosted (a lower bitrate or a shorter export from the tool that produced it), or to import a smaller rendition. Check the size yourself first. The helper below mirrors the byte and content-type checks and runs with the standard library only.

MAX_BYTES = 300 * 1024 * 1024  # 314,572,800

def preflight(content_type, content_length):
    ct = (content_type or "").split(";")[0].strip().lower()
    declared = ct and ct not in ("application/octet-stream", "binary/octet-stream")
    if declared and not ct.startswith("video/"):
        return "unsupported_media_type"
    if content_length is not None and content_length > MAX_BYTES:
        return "source_too_large"
    return "ok"

print(MAX_BYTES)
print(preflight("video/mp4", 120_000_000))      # ok
print(preflight("video/mp4", 400_000_000))      # source_too_large
print(preflight("text/html; charset=utf-8", 5)) # unsupported_media_type
print(preflight("application/octet-stream", None))  # ok

What about Timeline sources?

Timeline has its own source preflight, which also tests each file against the 300 MiB per-file budget and against a 4 GiB total across the document, per the same source constants. A document with 200 slots can therefore fail on the total even when each clip passes.

If a refusal names a url, that is the file to replace. Everything must stay on media.sume.com: import first with POST /v1/media-imports, as each page says.

How do I read the refusal?

The body is a standard API error: a code, a message, and for this case the max_bytes and content_length values. Compare the two numbers to see how far over you are. A file at 330 MB is about 5% over and a small bitrate change fixes it, while one at 1 GB needs a different source.

Because the check happens at submit and creates no job, you can retry as often as you like while you adjust the file. Nothing is reserved, and the Idempotency-Key is only consumed by a request that is accepted.

Where do duration and size interact?

Duration and bytes are independent gates. A trim source can be up to 1,800 s and a filter source up to 300 s, but both must also fit in 300 MiB. A 20-minute screen recording at a modest bitrate can pass the byte check, and a 90-second 4K export at a high bitrate can fail it.

When you plan a pipeline, check the byte size at the moment a file is produced, and keep a lower-bitrate rendition next to the master. That way the media calls always have a source that passes the preflight.