I wanted a video-delivery test in which a changed picture could not explain a changed loading time. Re-encoding a clip at a lower bitrate would have moved too many things at once. Instead, I kept the encoded media payload identical and changed two other inputs: where the ordinary MP4 stored its movie metadata, and whether the HTTP server honored byte-range requests. That gave the playback results a narrower meaning.
The inputs were two public waves clips, each prepared as an eight-second H.264 MP4 at 960×540 without audio. The smaller comparison file was 1,433,114 bytes; the larger was 5,068,844 bytes. For each source, I made front-metadata and end-metadata versions by copying the encoded packets during remuxing. Their mdat payload hashes matched within each pair. The complete files did not need to match, because their container layout was the variable being tested.
I served the files from a local HTTP process with two modes. One honored a Range request and returned a partial response with status 206. The other ignored the requested range and returned the whole file with status 200. All active responses in a test shared a 256 KiB/s write budget, scheduled in 40 ms steps, and each request began with an 80 ms delay. Giving every simultaneous response its own full budget would have changed the total delivery capacity when a browser opened another request.
That setup still has limits. It throttles application writes rather than network packets, so socket buffering, scheduling, and decoding affect the observations. The 80 ms initial wait is not a complete model of an 80 ms round trip. I used fresh browser contexts and no-store responses, then repeated each source, engine, layout, and server-mode combination twice. Across three engines, the ordinary MP4 matrix contained 48 runs.
The smaller end-metadata file made the server-mode difference clear in Chromium. With Range supported, its first-frame times were 0.776 and 0.813 seconds. With Range ignored, they were 5.773 and 5.792 seconds. The media bytes were unchanged. In one supported run, requests moved from byte zero to byte 1,409,024 near the end, then back to byte 32,768. The browser had a way to obtain the late metadata before reading all intervening media.
This is a separate no-Range illustration of the larger file at 1,250 ms, not a screenshot of the smaller file’s measured runs. It comes from a native player in the local reproduction. The larger file’s two Chromium first-frame waits in the main matrix were 20.272 and 20.278 seconds. A screenshot can show the waiting state; it cannot replace the event record used to calculate that interval.
I also made real exports with ImgIng, operating the Chinese video compression workbench. Those outputs were fragmented MP4s from the complete originals, retaining audio and different durations. I kept them out of this paired ordinary-MP4 comparison. Otherwise a product export, a shortened silent derivative, and a changed container structure would all be competing as if only one variable had changed. Their playback checks are useful, but they answer a different question.
The illustrated source is דוד שי’s Water waves in Herzliya beach, under CC BY-SA 4.0; the comparison copy was trimmed, resized, stripped of audio, transcoded, and remuxed. The test engines were Chromium 149, Firefox 151, and a WebKit 26.5 test build rather than released Safari. One larger-file WebKit condition failed before producing a frame, so I did not convert every non-success into a slow-loading measurement.
For a repeatable check, I would keep the file-pair hashes, actual response mode, request ranges, and first-frame event together. Seeking should have its own result and target, rather than being inferred from startup. Only after that local comparison would I test the final hosted URL with its real cache and delivery behavior. These numbers isolate behavior in the test server; they do not certify a CDN configuration or predict public-network startup times.
Top comments (0)