VIDEO TO FRAMES · PRACTICAL GUIDE
Video to Frames Timestamps: Match Requests to Saved Frames
The short answer
A sampling interval sets the times the extractor asks to capture; the encoded video determines which picture is displayed at each request. If two requests fall while the same source frame is on screen, they may produce identical images. Check each result’s timestamp label and preview when you need a specific moment. Use every original frame when you need the decoded sequence.
Request time and frame time answer different questions
A request time says when the sampler asked the decoder for an image. A frame time says which displayed source picture the decoder returned. Those values need not be equal: video frames exist at discrete presentation times, not at every decimal fraction of a second. The visible result can also repeat when a clip holds one picture for longer than the sampling interval.
For example, if a 2 fps clip displays a picture for half a second, requests at 0.0 and 0.4 seconds can both fall inside that display period. That does not mean the interval control malfunctioned. It means the clip offered no new displayed picture between those sample requests.
What happened in our interval test
We loaded the three-second, 640 × 360 synthetic H.264 clip from our measurement set into PickVideoFrame in Chrome on Windows. The clip contained six original frames at two frames per second. We set an inclusive start of 0 seconds, an exclusive end of 3 seconds, PNG output and a 0.4-second interval.
The page reported eight requested samples and completed eight PNGs. The labels read 0.000 twice, then 0.500, 1.000, 1.500, 2.000 twice and 2.500 seconds. The two pairs at 0.0/0.4 and 2.0/2.4 therefore landed on the same displayed source pictures. The result illustrates this file and setup only; it is not a decoder rule for every codec or browser.
New test: shift the start, then compare saved files
Recorded 30 October 2026. These measurements use a new clip and three completed downloads.
A controlled follow-up with a shifted start
For a second experiment, we generated a new three-second H.264 clip at 320 × 180 pixels and four source frames per second. PickVideoFrame indexed twelve original frames. In Windows Chrome, we saved three PNG archives: run A sampled from 0 to 3 seconds every 0.3 seconds; run B used the same end and interval but started at 0.1 seconds; run C exported every original frame from 0 to 3 seconds. The end remained exclusive in all three runs.
The same count selected different pictures
Runs A and B each completed ten images, yet their source-frame sets differed. Run A included the pictures labelled 0.750 and 2.250 seconds; run B replaced those with 1.250 and 2.750 seconds. The other eight source timestamps were shared. Comparing the downloaded files confirmed that every shared timestamp had identical PNG bytes across the two runs. In this experiment, changing only the start by one tenth of a second changed two of ten selected pictures without changing the displayed image count.
How far did these samples land from the requests?
For run A, subtracting each saved source time from its request gave delays of 0, 50, 100, 150 and 200 milliseconds, followed by the same five-value sequence again. Run B produced the same values in a different order: 100, 150, 200, 0 and 50 milliseconds, then repeated. Each run therefore averaged 100 milliseconds earlier than requested, with a maximum difference of 200 milliseconds. No output label in either run was later than its request. These are calculated differences from our saved labels, not measurements of a display clock.
Checking the files against the complete sequence
The twelve-image control archive gave us a reference at 0.000, 0.250, 0.500 seconds and each subsequent quarter-second through 2.750. We unpacked all three archives and calculated SHA-256 for each PNG. All twenty sampled files matched the corresponding control PNG byte for byte. We separately decoded each image to RGB24 with FFmpeg 6.1.1: all twenty also matched their control image’s decoded pixel hash. Each decode contained 172,800 RGB bytes, consistent with 320 × 180 pixels and three bytes per pixel. This verifies the sampled pictures against this browser’s own complete export, not against another decoder’s video rendering.
What combining the two runs actually recovered
Combining the two ten-image archives yielded twenty files but only twelve distinct PNG hashes. The eight shared pictures accounted for the repeated files; the two pictures unique to each run completed the twelve-frame control set. Both combined coverage and exact picture identity were checked, rather than inferred from the file total. In this controlled clip, either interval run alone omitted two source pictures, while their union recovered every picture in the control. This happened because of these particular quarter-second source positions and request schedules; it is not a promise that shifting any interval will recover every frame.
Reading one request without assuming nearest-frame selection
Run A’s request at 0.900 seconds saved the 0.750-second picture, even though the next source picture at 1.000 seconds was closer to the request. Run B’s 0.100-second start also saved the picture labelled 0.000, before the selected range’s start. Both files matched the corresponding control PNG. These two observed mappings matter when interpreting this export: a saved label before a request need not mean a corrupted image or a failed range setting. Here, the selected picture was the one displayed across that requested moment. We did not establish this selection policy for other tools, codecs or browsers.
The saved spacing was not the requested spacing
The nine gaps between successive saved labels also differed between our runs. In run A, eight gaps were 0.250 seconds and one was 0.500 seconds, between the pictures labelled 1.000 and 1.500. Run B contained seven quarter-second gaps and two half-second gaps, from 0.500 to 1.000 and from 2.000 to 2.500. Neither archive had a 0.300-second gap between saved labels, despite both runs requesting that interval. The first-to-last saved span was 2.500 seconds in A and 2.750 seconds in B. The control sequence instead contained eleven equal quarter-second gaps, ending at 2.750. These differences describe the selected source pictures, while the input schedule remained regularly spaced in both runs.
Comparing file position gave a different result
Comparing the first file with the first, the second with the second, and so on revealed four changed positions between our ten-file archives: positions four, five, nine and ten. Position four changed from the 0.750-second picture to 1.000; position five changed from 1.000 to 1.250; position nine changed from 2.250 to 2.500; position ten changed from 2.500 to 2.750. Thus the same two archives had eight shared picture identities, but only six matching positions when compared by export order. We verified both counts from the saved PNG hashes. For this pair of exports, comparing only their totals would hide every change, while comparing file positions would report twice as many changes as the count of newly introduced pictures.
The request and output table and synthetic source clip are available for checking the results. The CSV contains measured output labels; it is not a manifest generated by the extractor.
How to find the moment you actually need
For one moment, use single-frame capture and inspect the saved frame label. For a broad sample, compare the request schedule with result labels and previews. If precision matters, open the PNG in your editing tool and compare the visible event there; a sequence number or rounded seconds label cannot establish exact edit time.
- Use the preview timeline to locate the event before choosing a broad interval.
- For one moment, switch to single-frame capture and inspect the saved frame’s displayed time.
- For a regular sample set, compare requested positions with result labels; repeated labels or identical previews mean the source picture was reused.
- For a complete decoded sequence, select every original frame and keep the run limits and available memory in mind.
- If a frame must align with an edit or transcript, confirm it in the destination editor as well; a rounded label is not frame-level timecode evidence.
How to use the result for different tasks
If you are making a storyboard, a regular interval is usually a quick way to cover the clip; repeated images simply show that a requested sample landed within the same displayed source picture. If you are checking one brief action, use a single-frame capture and move the preview around the event before saving. If you need to preserve the whole source sequence, choose every original frame rather than estimating a frame number from the interval setting.
For file naming, keep the generated sequence number together with its visible time label. The number makes a batch easy to sort, while the label helps you return to an approximate point in the original clip. Neither one alone proves exact frame-level synchronization, particularly when the source timing is variable or the label is rounded.
What the labels cannot tell you
A timestamp printed to three decimal places can look more precise than the underlying timing evidence. In this experiment, the output labels aligned with the six 0.5-second source-picture positions, while the sampler requested eight times spaced 0.4 seconds apart. That lets us identify which displayed picture appeared in this controlled clip. It does not reveal subframe timing, prove how another decoder rounds a seek, or provide a source timecode for an editing decision.
When a frame must match a spoken word, cut, or event, use the image preview to narrow the search, then verify the actual image in the editor that will receive it. Keep the chosen still beside the original clip until you confirm the intended event; use the timestamp as a search aid, not as a substitute for visual confirmation.
Why frame numbers are not timestamps
Sequence numbers count exported files. They do not identify elapsed time by themselves. Dividing a file number by a nominal frame rate can mislead when the video uses variable frame timing, when sampling skips source pictures, or when multiple requests select one displayed picture. Prefer the time shown with the actual exported result, and treat it as a practical label rather than a guarantee of a particular precision.
What we did not test
This run used one synthetic constant-rate H.264 clip and one Chrome setup. We did not test variable-frame-rate phone footage, other browsers, alternate codecs, subframe timing, or editorial synchronization. The test does not establish a universal nearest-frame or rounding policy. Our separate guide explains why repeated source images can appear in video-to-frames exports; this page focuses on comparing a requested time with the saved result label.
Read why timed exports can repeat images or try the frame extractor.