MP4 Layout — moov Atom at End
The default MP4 layout, with the index written last. A progressive-download player must fetch the entire file before it can start — the classic 'video buffers forever' bug, and invisible unless you look at the atom order. Byte-for-byte the same encode as its twin in this group; only the atom order differs, which is why comparing the two is the clean way to demonstrate the effect.
Browser-playable test video · 1 seconds
Specifications
- Resolution
- 480x270
- Fps
- 24
- Codec
- H.264 (libx264)
- Moov Position
- end
- Progressive Download
- must download fully first
Testing contract
Expected to pass- Scenario
- Serve the file over HTTP without range requests and measure how much must arrive before playback starts.
- Expected result
- The moov index is written last - the default MP4 layout - so the entire 23,711-byte file must be fetched before a progressive player can start. This is the 'video buffers forever' bug, and it is invisible to every check except atom order. Its faststart twin in this group is the same encode within one byte.
What is a .mp4 file?
MP4 (MPEG-4 Part 14) is the dominant container for digital video, holding video, audio, subtitle, and metadata tracks in a tree of typed boxes. `ftyp` declares the brand, `moov` carries the sample tables that make seeking possible, and `mdat` holds the media; when an encoder writes `moov` last, playback cannot begin until the file has fully downloaded, which a faststart remux fixes. It derives from Apple's QuickTime format, generalized by ISO into the ISOBMFF base that MOV, 3GP, and HEIF share.
How to use this file
Use an example MP4 to test box parsing and track detection, seeking, range-request streaming, and transcode or thumbnail pipelines: verifying that a file with a trailing `moov` box is still handled, and that codec support is checked per track rather than inferred from the extension.
How to use this file for testing
“MP4 Layout — moov Atom at End” is a deterministic Novus Examples fixture for Video codecs, Conversion testing, Video QA. One source encoded as H.264, HEVC, AV1, VP9, MJPEG, and a ProRes-compatible mezzanine, across 8/10/12-bit and 4:2:0/4:2:2/4:4:4, for testing decoder support, transcode pipelines, and container remuxing.
Documented properties for this file: 24 fps. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Media fixtures are short and synthetic by design. Prefer waveform or transcript ground truth in the same group when measuring ASR, trim, upscale, or sync tools; do not assume broadcast-quality masters.
Code examples
<video controls preload="metadata" width="640" src="moov-at-end.mp4"></video>Related files
- webmAlpha Channel — Opaque VP9 TwinThe same codec and container with NO alpha plane, as the control for the alpha clip in this group. Useful for checking that alpha detection reads the pixel format rather than assuming every WebM is transparent — and for confirming a compositing bug is in the alpha handling rather than in the player.
- webmAlpha Channel — VP9 in WebMVideo with a real per-pixel alpha channel: VP9 yuva420p in WebM, the one alpha path browsers decode natively. Composite it over a page background and the transparency is genuine, not a chroma key. Roughly 90% of each frame is fully transparent. Two traps this file exists to expose. First, auto-alt-ref must be disabled at encode time or libvpx silently drops the alpha plane, producing a valid file with no transparency and no error. Second, WebM stores VP9 alpha in BlockAdditional and signals it with AlphaMode=1, so FFmpeg's NATIVE vp9 decoder reports pix_fmt yuv420p and decodes fully opaque — you must force `-c:v libvpx-vp9` to see the alpha at all. Probing this file with default settings and concluding it has no alpha is the expected mistake.
- mp4Codec — AV1The shared pan-city base plate encoded with AV1 (libaom-av1). Royalty-free and now decoded by every current browser. Encoding is far slower than H.264, which is why this fixture uses a fast preset; the bitstream is standard regardless. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
- mkvCodec — FFV1 (Mathematically Lossless)The shared pan-city base plate encoded with FFV1 level 3 (lossless). Mathematically lossless: decoding reproduces the source pixels bit for bit. Used for archival preservation, and the right reference when you need to prove a processing step, not a codec, caused a change. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
- mp4Codec — H.264 / AVCThe shared pan-city base plate encoded with H.264 (libx264). The universal baseline — decodes everywhere, hardware-accelerated on essentially every device shipped this decade. If a pipeline handles only one codec, this is it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
- mp4Codec — HEVC / H.265The shared pan-city base plate encoded with HEVC (libx265). Roughly half the bitrate of H.264 at the same quality, but patent licensing kept it out of browsers. Tagged hvc1 rather than hev1, which is what Safari and QuickTime require — the wrong tag is a common cause of a file that plays everywhere except on Apple hardware. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
Generated by generation/video_codecs_wave.py. Free for any use, no attribution required, license.