Video filter: a live replay over 300 seconds needs a trim first

Sume POST /v1/video-filter takes a source of at most 300 seconds. A longer clip, such as a full live-sale replay, fails with output_duration_exceeded when the worker reads it. The fix is to cut the moment you want with POST /v1/video-trim first, then send the trim's video_url to the filter.

The limit is in Video filter and the trim limits in Video trim (read 2026-10-06). Trim accepts a source of up to 1800 seconds and cuts up to 900, so a 20-minute replay goes through trim and not directly through the filter.

What does the order look like?

Trim, then filter, then captions. Each step returns a new MP4, and its video_url is the next step's input.

How do I avoid paying for a refused job?

Run the free check first. POST /v1/video-filter/check runs the same schema, allowlist, and host checks as the encode, with no job and no charge. It cannot see the length on the worker, so a program that passes can still fail on a long source. Trim first and the length is no longer a risk.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: replay-90s-for-filter" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/live-sale.mp4",
    "start": 600,
    "duration": 90
  }'

What about the output?

A 90-second highlight is well under the 300-second filter limit. After the trim completes, read its video_url and send that to the filter, with a dim or crop op as you need.

• Import the replay with POST /v1/media-imports before trimming.
• The filter keeps the geometry, rate, and audio of its source unless the program changes them.
• A failed filter job returns a structured error, and a trim you already paid for stays usable.