Trim, filter, frames, inspect or detach: which Sume media call?
Pick the Sume media API by the output you need: trim cuts an MP4, filter dims or crops, frames gives stills, inspect probes, detach gives audio.

Choose by the thing you want back. Need a shorter MP4: video-trim. Need the same clip darker or cropped: video-filter. Need still images at times you name: video-frames. Need facts about the file (duration, audio present) or a transcript: video-inspect. Need the sound as a wav or mp3: audio-detach. All five take one clip already on media.sume.com, never change the source, and are priced as small fixed or compute-based jobs rather than model generations.
Which output does each one return?
The five docs pages each end with a short table of neighbouring surfaces, and they agree with each other. The table below merges them, with the public rate where the page states one.
| Need | Route | Returns | Source limit | Public rate in docs |
|---|---|---|---|---|
| A shorter clip | video-trim | New MP4 | 1800 s (output up to 900 s) | $0.02 per job |
| Dim or crop | video-filter | New MP4 | 300 s | $0.02 per encode job; check is free |
| Stills at times | video-frames | Image artifacts | 300 s, 24 frames per call | Modal compute plus platform fee |
| Probe, stills, transcript | video-inspect | Probe, stills, optional text | 1800 s, 24 stills per call | Compute-based; transcript $0.01 per audio minute |
| Audio track | audio-detach | wav or mp3 | 1800 s (output up to 900 s) | $0.01 per job |
What if I need more than one step?
Chain them, because every result is a new media.sume.com artifact you can pass to the next call. A common order is inspect first (with frames: false to get only the probe), then trim to the part you want, then filter if the footage needs a dim or crop before text goes on top. Trim's result can go straight into a timeline as a video[] clip with source_in 0.
Check which limit bites first. Filter is the tightest at 300 seconds, so trim a long recording down before filtering it rather than the other way around. Detach needs an audio track and fails with detach_source_has_no_audio otherwise, so read probe.has_audio from an inspect first.
How do these calls report back?
Frames always returns 202 and is read from its own GET. Inspect defaults to a 30 second sync wait. Trim, filter and detach default to async, with an optional mode: "sync" that waits up to 30 seconds. In every case a 202 means poll the job, never resubmit. Writes need an Idempotency-Key, and the same operations exist as hosted MCP tools such as video_trim, video_filter, video_inspect and audio_detach.
- Off-host URLs are refused; import the file with
POST /v1/media-importsfirst. - The server compiles ffmpeg, so client fields such as
vf,cmd,codecorcrfreturnffmpeg_fields_rejected. video-filter/checkis an unbilled dry run that returns diagnostics and an estimate.
Sources
Related posts
More in Media tools
- Pixelate part of a video by API: a fixed-region mosaic
Hide a label or a screen area with a mosaic using one Sume video-filter graph: crop a region in 24-pixel multiples, shrink, enlarge with neighbor, overlay.
- Remix cut refused with only a start time: the 120 s budget
Why a remix media cut with start but no end fails remix_cut_too_long, how the 120 second and 20 span limits add up, and when to use video trim instead.
- Remix notes lint: FORMAT.md needs a Captions heading
What the remix media notes verb checks: a Captions heading in FORMAT.md, media.sume.com links only, the 200,000 byte cap, and why a lint failure still saves.
- Remix tile: 96 cells per call, and how to count yours
A remix media tile call is refused above 96 cells with remix_tile_too_many_cells. How each selector is counted, worked examples, and ways to split a request.
Written by Sume