Video upscale tops out at 30 s: trim the hero seconds first

Sume's video upscale accepts a duration_seconds from 1 to 30 and is priced per input second, so a long clip is the wrong thing to feed it. Cut the seconds that matter with video trim first (an exact cut is $0.02 per job), then send that short cut to the upscaler with the matching duration.

Facts here are from the Sume API routes and schema (POST /v1/video-upscale-1.0/upscale) and Video trim. For the per-second rate itself see the existing cost post, and confirm live prices in GET /v1/catalog.

What are the video upscale limits?

The request takes a public HTTPS video_url, a scale between 1.1 and 4 (scale_ratio, with upscale_factor also accepted), an enhancement_tier of fast, standard or pro, and duration_seconds from 1 to 30. If you omit duration_seconds, 5 seconds are reserved. Pricing is described as per input second after Sume's margin.

Why trim before you upscale?

Two reasons. The cap: a 90-second source cannot be declared as 90 seconds, so you must cut it anyway. And the money: the reservation follows the seconds you declare, so a 6-second hero shot declared as 6 is reserved as 6 rather than defaulting to 5 or inflating toward 30.

The docs do not say whether the upscaler itself cuts a longer input down to your declared duration. Do not rely on it: send a clip whose real length equals the duration_seconds you declare.

How do I do it?

Video trim reads a Sume-hosted clip. Import first with POST /v1/media-imports if it is elsewhere. Trim returns a new MP4 on media.sume.com, which is an HTTPS URL the upscaler can take. Use precision: "exact" (the default) so the cut lands on the frame you chose; a keyframe cut can start a GOP early, and you would then declare the wrong length.

Read duration_seconds from the trim result and pass it on, rounded up to a whole second. Upscale jobs take minutes, so poll with jobs_wait on MCP or GET /v1/jobs/:id/status.

# 1) cut 6 s starting at 12.5 s
curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: hero-trim-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/long.mp4","start":12.5,"duration":6}'

# 2) upscale the cut 2x, declaring its length
curl -X POST https://api.sume.com/v1/video-upscale-1.0/upscale \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: hero-up-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_trim/long.mp4","scale_ratio":2,"enhancement_tier":"standard","duration_seconds":6}'

How do I estimate the cost before running it?

The public description says video upscale is priced per input second after Sume's margin. Multiply the seconds you declare by the per-second rate shown in GET /v1/catalog, and add the trim job, which the docs list at $0.02. For a 6 second hero cut that is six seconds of upscale plus one trim job. The existing cost post works through the per-second figure; read the catalog for today's number, since list prices are the part most likely to change.

Insufficient credits show up as a 402 at submit. Reservation happens up front, which is why declaring a sensible duration_seconds matters: the reserve follows what you declare.

A last tip on tiers. fast, standard and pro are the three values the schema accepts, and the docs I read do not publish a quality comparison between them. Test one clip on fast and standard and look at both before you commit a batch to pro.

What if I need the whole long video upscaled?

Split it into pieces of 30 seconds or less, upscale each, and join them with Timeline 1.0. That is more jobs and more moving parts, and the docs do not promise matching color or motion at the seams between separately upscaled pieces. For most deliverables, upscaling the hero seconds and leaving the rest at native resolution is the cheaper trade.