Nine immediate video drawings looked correct in my test, even though I had not waited for seeking to finish. I could have kept one of those results and convinced myself the capture sequence was safe. Looking at which requests succeeded changed the interpretation: all nine moved from zero to 0.017 seconds in a 30 fps video. The previous frame was also the frame I needed. The test had given the shortcut an easy case.
I used a generated clip containing 180 numbered frames at 640×360. The number was encoded in pixels so that drawing into a canvas could reveal the actual frame, independently of the video’s reported time. Three H.264 versions had GOP lengths of 15, 60, and 180 frames, with no B-frames. I tried twelve target positions in each version using Chromium 149, Firefox 151, and a WebKit 26.5 test build. That produced 108 immediate-drawing checks.
In 99 of them, drawing straight after assigning currentTime captured the previously presented frame instead of the target. In the other nine, the request still belonged to that previous frame’s interval. At 30 fps, each interval is about 0.033 seconds long. Asking for 0.017 seconds after starting at zero does not necessarily ask for new pixels. A canvas can therefore look correct without demonstrating that my waiting logic worked at all.
That is why I would not turn the count into a general failure percentage for video capture. The matrix contains deliberately chosen positions, repeated across particular files and engines. The nine convenient results share one explanation. What I learned was about test selection: I need a request that crosses a frame boundary as well as one that remains inside the same frame. Otherwise a stale image can accidentally satisfy the check.
The next position, 0.049 seconds, belongs to frame one in this fixture. Comparing it with 0.017 gave the test a meaningful change to observe. Seeking to 2.117 seconds after completion produced frame 63 across all three GOP versions; its start time is 2.100 seconds. The keyframe interval did not change that selected frame in this controlled sample. I stopped using a decimal time value as if every possible fraction of a second had its own picture.
This illustration was captured later by loading the existing fixtures and drawing after seeked. It shows generated measurement frames rather than filmed footage. It supports the frame-number and GOP comparison, not the original count of immediate drawings. The count came from the stored test records. Keeping that distinction helped me avoid asking one screenshot to prove every step of the experiment.
There was another same-frame surprise in WebKit. Moving from zero to 0.017 seconds completed seeking, but no new frame callback arrived within my 1.7-second observation window for any of the three GOP versions. The canvas still held frame zero. A missing callback during that window did not mean the image had become black. I have not implemented and validated a general fallback; the result only tells me that another callback is not guaranteed by this particular request.
For a separate product check, I used ImgIng through its Chinese video-matting Beta workbench. A six-second waves clip displayed, and the current-frame preview at 2.117 seconds reported no obvious subject. That was not a test of the product’s frame accuracy or a thumbnail export. The footage came from Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, under CC BY 3.0, trimmed, resized, and transcoded. The numbered fixture was a separate generated input.
My next regression check will include both a same-frame move and a different-frame move, and it will retain the actual canvas frame number. A same-frame success can check that I did not break an already usable picture; it cannot prove that a new frame has arrived. These desktop fixtures had constant frame rate and no B-frames, and the WebKit build was not released Safari. I would extend the inputs before making broader promises. First I want the test to require the change it claims to verify.
Top comments (0)