Video inspect fast seek: requested_times vs sample_times

When a Sume video_inspect call asks for frames.seek: "fast", each grid in the response carries seek: "fast", requested_times (the instants your program asked for) and sample_times (the instants the tiles actually show). Cut from sample_times. A fast still snaps to the keyframe at or before its instant, earlier by up to one GOP, which the docs put at roughly 0 to 5 seconds on typical sources, and never later.

Skimming is how you review auto-assembled cuts quickly. Instagram's First Draft builds a first pass in under 10 seconds (TechCrunch, read 2026-10-04); a fast inspect lets you skim what came out without decoding every frame.

Which array answers which question

From the video inspect docs: use fast when skimming and precise (the default) when the timestamp must match, as with explicit at[] instants and the default eight mid-bin midpoints. Quality, resolution and the transcript are unchanged by fast.

Measure the snap

The difference between the two arrays is how early each still is. If it is large on a clip you will cut, switch to precise for that program. The trim side has the same trade: precision: "keyframe" may start a GOP early and reports actual_start_seconds.

grid = {
    "seek": "fast",
    "requested_times": [5.0, 10.0, 15.0, 20.0],
    "sample_times": [3.2, 9.6, 12.0, 19.8],
}

for want, got in zip(grid["requested_times"], grid["sample_times"]):
    early = round(want - got, 2)
    flag = "snap > 2 s" if early > 2 else "ok"
    print(f"asked {want:5.1f}  shows {got:5.1f}  early {early:4.2f}  {flag}")

worst = max(w - g for w, g in zip(grid["requested_times"], grid["sample_times"]))
print("worst snap:", round(worst, 2), "s")

Inspect reads one clip of up to 1800 seconds on media.sume.com, with at most 24 stills per call. Default mode is sync with a 30-second wait; a 202 means poll with jobs_wait. See fast seek for the basics.