Video inspect seek fast vs precise: stills up to one keyframe early

seek: "fast" in the video-inspect frames program moves each still to the keyframe at or before its time and skips the decode. The still can be earlier by at most one GOP, which the docs put at roughly 0 to 5 seconds on typical sources, and it is never later. Use precise, the default, when the timestamp has to be right.

Side by side

Quality, resolution and transcript do not change between the two modes; only the frame position does.

Reading the response

With fast, each grid carries seek: "fast". sample_times are the instants the tiles show; requested_times are the instants in your program. Compare them to see how far each still moved. If the gap is larger than you tolerate, rerun the same program with precise.

Request

Import the clip first with POST /v1/media-imports so it sits on media.sume.com, send an Idempotency-Key header, then poll GET /v1/jobs/:id/status and read GET /v1/jobs/:id/result. The API rejects off-host URLs at admit, so a bad URL fails before any work runs.

curl -X POST https://api.sume.com/v1/video-inspect \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: inspect-fast-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/talk.mp4","frames":{"fps":0.2,"seek":"fast","max_edge":512}}'

A rule of thumb

• Triage of many clips: fast.
• Checking that a logo is on screen at 3.0 s: precise.
• Picking a cover frame: precise, then use video frames for the source-size image.
• Fast does not change the 24-still cap or the 1800 s source limit.

Worked example

A 10-minute screen recording has keyframes about every 5 seconds. A fast request for stills at 12 s, 24 s and 36 s may return frames from 10 s, 20 s and 35 s, depending on where keyframes sit. That is fine for scanning which slide is on screen. It is wrong for checking that a caption appears exactly at 24.0 s. In that case use precise, which decodes to the instant. Both modes keep the 24-still and 1800-second limits. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.