I expected a video’s seeked event to tell me that a jump to six seconds had worked. That was too much to ask of one event. In a small playback experiment, I could request that position and still end up at zero. My next check had to be the resulting position, followed by the presented frame’s time. Counting an event as a successful thumbnail would have hidden the difference.
The test used two publicly available clips of ocean waves. I prepared eight-second H.264 MP4 files at 960×540, with no audio, then made front-metadata and end-metadata versions without changing their encoded media payloads. Those are controlled comparison files, not recordings of a problem on someone’s website. Each browser started in a fresh context. I deliberately sought early: 500 ms after its first video-frame callback.
The delivery setup matters here. A local HTTP server gave all active responses for a test a shared 256 KiB/s write budget. Each request also started with an 80 ms delay. I switched between honoring Range requests and returning the whole file. This is an application-level delivery experiment, not a simulation of every property of a slow internet connection. In particular, that initial delay should not be read as a measured network round-trip time.
The smaller clip’s front-metadata version looked encouraging in Chromium. With Range ignored, its first frame appeared after 0.479 and 0.483 seconds. Yet both early requests to jump to six seconds were clamped to zero. The recorded seekable range was also zero to zero. An early picture had told me that playback could start; it had not established that my chosen destination was currently available. I had been checking the easier half of the task.
This separate illustration shows the same front-metadata comparison file 1,250 ms into a local no-Range load. It is a native player view, not an ImgIng interface. The visible coast is useful evidence of a picture at that moment, but it cannot prove that the six-second jump in the timed runs succeeded. For that I used the event and frame records, keeping the screenshot’s timing separate.
Firefox gave me another reason to keep the actual result. Under the smaller clip’s front-metadata, no-Range condition, the two requested six-second jumps landed at 1.16 and 0.36 seconds. They did not land at the same wrong number, so checking only for zero would have missed the problem. With Range supported, the same file reached the target frame in both runs, after about 3.919 seconds at the median. That wait belongs to seeking, not initial playback.
I had also used ImgIng to export the source videos as MP4, operating its Chinese compression workbench for the actual test. Those outputs were fragmented MP4s and were tested separately. They were not the eight-second silent files above. This distinction stopped me from attaching the comparison files’ timing to a tool’s export performance. I wanted to understand a playback check, not produce a compression speed ranking.
The original Iceland footage is Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, under CC BY 3.0. The illustrated test copy was trimmed, resized, and transcoded. I did not shoot it. The experiment used Chromium 149, Firefox 151, and a WebKit 26.5 test build on macOS; that last build is not released Safari. Each ordinary MP4 condition ran twice. These early-seek observations do not show that a fully downloaded file will remain unseekable.
My next capture check will retain the requested time, the position reported after seeking, and the time attached to the presented frame. For this experiment, reaching six seconds meant a frame callback within 0.15 seconds of that target; it was not a test of exact pixels. I would keep a clamped destination as a separate outcome and inspect the available range before retrying. A fired event is worth recording, but the destination still needs its own check.
Top comments (0)