video-inspect fast seek: sample_times vs requested_times on a Short

With seek: "fast", a Sume video-inspect still can come from earlier than the time you requested, never later. Fast mode moves each still to the keyframe at or before its instant and skips the decode, so the picture can be up to one GOP early, roughly 0 to 5 seconds on typical sources. Read sample_times to see the instants the tiles actually show, and compare them with requested_times, the instants in your program. If the timestamp must be exact, use precise, which is the default.

Why would a Short hook check show the wrong second?

A common use of video-inspect is checking what a viewer sees in the first seconds of a vertical clip, for example stills at 0, 1 and 2 seconds. In fast mode the tool does not decode to the exact frame. It jumps to the nearest earlier keyframe, so a still you asked for at 2 seconds may be the picture from 1 second. The quality, the resolution and the transcript do not change; only the instant does.

That matters when you are judging a hook, a text card or a product reveal against a specific second. A reveal at 1.8 seconds can look as if it has not happened yet in a fast still.

Which field tells me what I really got?

When you use fast seek, each grid carries seek: "fast". Two fields describe the times. requested_times are the instants in the program you sent. sample_times are the instants the tiles show. If the two lists differ, the stills are earlier than you asked, and you should label them with sample_times in any review notes.

When should I pick fast, and when precise?

Use fast for a first pass over a long file, such as scanning a recording before you decide where to cut. Use precise when a decision hangs on one second, such as a hook check, a caption-timing check or a frame you will reuse.

Two limits apply to either mode: the source can be at most 1800 seconds, and one call returns at most 24 stills. An at value outside the range from 0 up to the duration returns frame_time_out_of_range, and the error includes the duration, so a request at exactly the clip length is refused.

• Send frames: { at: [0, 1, 2] } for named instants, or frames: { fps: 1 } for an even sample.
• Add seek: "precise" explicitly if a script depends on exact instants.
• For one accurate frame at the source size, use the video frames route instead of inspect.

Does this change anything for the new Shorts player?

YouTube's June 25, 2026 post describes a Clear Screen mode that temporarily hides all icons and text from the playback view. Burned-in text is part of the picture, so it stays. Checking that your burned-in lines appear at the second you intended is a precise-seek job, because a fast still may show the frame before the text arrives.

Once the stills confirm the timing, cut with the video trim route, which takes a start and either an end or a duration.