Sample MP4 Generator

Quick Tips for the Right Test Video

Features

A Container Built From Boxes Inside Boxes

Every container this library has built so far is, structurally, a flat sequence of pieces — EBML elements one after another for Sample WebM, pages for Sample OGG, chunks for Sample WAV. MP4 is genuinely different: it's boxes nested inside boxes inside boxes, several layers deep. A single video track's duration, for instance, lives inside a media header, inside a media box, inside a track box, inside the movie box — four levels down from the top of the file, not one flat list away.

That depth is exactly why finding and correcting anything in an MP4 file means actually walking that structure programmatically rather than scanning for a fixed byte pattern the way a simpler container might allow. This generator reads real box headers — a 4-byte size, a 4-byte type — recursing into container boxes exactly the way a real MP4 parser has to, since there's no shortcut around the hierarchy MP4 itself defines.

Three Places the Wrong Duration Was Hiding

The honest version of this story starts with a wrong assumption. It seemed reasonable to expect Chromium's MP4 muxer would either get duration right everywhere or leave it wrong everywhere — instead, checking a real generated file against a trusted, independent MP4-reading library showed something stranger: the movie-level header already reported the correct total, while a completely real, separate library reading the same file back reported roughly two-hundredths of a second for what was actually a two-second recording.

The reason turned out to be exactly where that library was looking. MP4 doesn't store duration once — the movie header holds one value, but every individual track also carries its own track header and media header, each with an independent duration field, and Chromium's live muxer only ever finalizes the movie-level one correctly, leaving each track's own fields at a stale, placeholder value. This generator now corrects all three kinds of field, in every track, rather than assuming one fix covers the whole file.

One More Ignorable Box, One Less Constraint

ISO-BMFF, the box format underneath MP4, defines free and skip as real box types whose entire purpose is to be ignored — space real encoding tools genuinely reserve or add without touching actual video or audio content. Growing a generated clip up to a bigger target here means appending one real free box, built with the same 4-byte size and 4-byte type header as any other MP4 box, just carrying no meaningful payload.

Unlike Sample WAV's RIFF container, which enforces an even-byte rule on every chunk, ISO-BMFF box sizes carry no parity requirement at all — a free box can be exactly the size needed to hit an odd or even byte target alike, with no rounding or one-byte overshoot required the way RIFF-based formats sometimes need.

Why Fragmented, and Why That's Not a Compromise

A desktop encoder writing MP4 from a finished file on disk can afford to record every sample's location up front and write one classic sample table once, at the very end, because it already knows exactly how many frames exist before it writes a single byte. A browser recording a live MediaStream has no such luxury — it doesn't know how long the recording will run until the user stops it, so MediaRecorder writes movie fragments incrementally instead, each one a self-contained moof/mdat pair covering a short span of real time.

That's the same structural approach real live-streaming formats use for the identical reason, and it plays back completely normally in a browser or any modern media player. The one real wrinkle is exactly the one this generator's duration fix targets: simpler, non-streaming-aware tools that expect one classic sample table sometimes read a fragmented file's duration incorrectly unless the movie, track and media headers are each corrected explicitly, which is precisely why that patch exists here rather than being left to chance.

Who Actually Needs a Real Test MP4

Mobile and web developers validating a video upload or playback pipeline need a genuinely encoded MP4 with real container structure, since a renamed screen capture or a malformed box tree can fail a real content-sniffing or transcoding check outright. QA teams testing playback across browsers and devices benefit from working through several content types on purpose — a player handling Solid Color correctly can still stumble on Random Noise's worst-case bitrate demand, or on Moving Shape's genuine motion, in ways one convenient clip never reveals.

Teams building or testing MP4 parsing logic of their own — a thumbnail generator, a duration display, a transcoding queue — get more genuine signal from a file with real fragmented structure and a correctly patched duration than from a file quietly authored by a desktop tool that never has to handle a live, browser-recorded stream at all.

The Boundaries of a Browser-Only Encoder

This generator is limited to exactly what a browser can genuinely verify it supports — no VP9/VP8 alternative the way Sample WebM offers, and no HEVC/H.265 option, since WebCodecs' own real capability check for it came back unsupported rather than silently falling back to something else. Resolution stops at 1080p for the same reason it does for Sample WebM: sustained real-time software encoding in a browser tab is heavier work than a single rendered frame, and this generator produces synthetic reference signals rather than realistic recorded footage, the same honest scope every content-generation tool in this library shares.

None of this should be mistaken for a limitation to work around — it's a deliberate line between a fast, honest test-fixture generator and a real video production tool, and this generator was only ever built to be the former.

Frequently Asked Questions