A paused video seek finished, but the next video-frame callback did not arrive within my observation window. Treating that as a failed capture would have thrown away a usable result: the target still belonged to the frame already on screen. This happened in a controlled WebKit test, and it made me separate seek completion from waiting for a newly submitted frame. Neither signal could stand in for the other.
I tested a generated H.264 clip with an independently readable frame number encoded in its pixels. It contained 180 frames at 30 fps, with no B-frames. Three versions used fixed GOP lengths of 15, 60, and 180 frames. The pixel number was important: I could inspect what had actually been drawn instead of reading back the same currentTime value I had just assigned. This was a test fixture, not footage of a production incident.
After loading and pausing the clip, I let the initial frame callback finish. I then registered a new callback and a separate seeked listener before assigning the next position. In the WebKit 26.5 test build, seeking from zero to 0.017 seconds produced seeked for all three GOP versions. The canvas still contained frame zero. No new frame callback arrived within 1.7 seconds. That interval was my observation limit, not a measurement of decoding work.
At 30 fps, the requested 0.017 seconds lies within the first frame’s interval. The unchanged pixels were therefore not automatically a stale result. Each version then continued through eleven other targets; WebKit produced a new callback for all of those. The next target, 0.049 seconds, drew frame one. Comparing a same-frame request with a different-frame request explained more than treating every missed callback as the same error.
A separate sea-footage check showed why I would not fix this by accepting any existing canvas immediately. Here, assigning 5.017 seconds and drawing at once captured a different wave shape from drawing after seeking completed. Both displayed time values could already say 5.017. In the numbered test fixture, 99 of 108 immediate drawings still contained the previously presented frame. The remaining nine were the same-frame requests, where the old pixels also happened to satisfy the target.
This independent reproduction uses a six-second, resized copy of public waves footage. It illustrates that a changed time property is not proof of updated pixels. It does not illustrate the 1.7-second callback timeout, which came from the numbered fixture. Keeping those two observations separate is essential: otherwise an example of stale content could be mistaken for proof that every unchanged frame is wrong.
I also ran a product-side check with ImgIng, using the Chinese video-matting Beta workbench. I imported the waves, moved to 2.117 seconds, waited for seeking, and requested its current-frame preview. It returned a no-obvious-subject message. That confirmed only the observed preview path and result. I did not inspect its internal waiting strategy or test a complete thumbnail export, so the application cannot serve as evidence for a callback fix.
For an implementation, I would retain the requested position, seek completion, available pixel evidence, and callback outcome as separate results. A timeout should end the wait and preserve those observations; it should not automatically label the canvas black. Deciding whether an existing frame satisfies the request needs a defined tolerance or another trustworthy reference. In this fixture I had an exact frame number. Arbitrary variable-frame-rate inputs need a different validation method, which I have not tested here.
The waves are Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, under CC BY 3.0, trimmed, resized, and transcoded. WebKit here was a test build, not released Safari. Before adopting a capture helper, I would run both a same-frame target and a different-frame target against it, then check cleanup after a timeout or cancellation. Those last implementation paths remain work to verify; the bounded experiment establishes why a new callback alone is an incomplete completion condition.
Top comments (0)