- Nationwide Digital Forensic & Cyber Investigation Services
The wrapper tells a player where media lives and when to present it. A structural examination tests whether those instructions agree with the supplied bytes.
Home › Digital Evidence Authentication › Video Evidence Authentication › MP4 and MOV File Structure Explained
Quick Answer. MP4 and MOV files organize media using boxes, also called atoms in QuickTime. The moov hierarchy describes tracks, timing, sample sizes, and storage locations; mdat holds media payload. Examiners validate box boundaries, follow sample references, and compare declared durations with actual playback. A coherent structure establishes internal consistency, not an unedited recording history.
This structural guide is part of our Video Evidence Authentication series. It follows the path from a box header to the compressed samples a player decodes. Use the video magic bytes guide to establish the format first, then the video metadata guide to interpret descriptive fields. MP4 and MOV share important structural concepts, but particular brands, versions, and recording workflows determine which layouts and optional features are expected.
| Question | Short answer |
|---|---|
| What does an MP4 or MOV box contain? | A typical box begins with a size field and a four character type, followed by a type specific payload. Some boxes contain child boxes; others contain tables, metadata, or compressed media bytes. |
| Where does MP4 moov store playback instructions? | The moov hierarchy contains the movie header and track structures. Within each track, media information and sample tables describe the media type, timing, sample descriptions, sizes, and locations in a conventional file. |
| Does MP4 mdat contain only video? | No. An mdat payload can contain compressed video, audio, or other media samples, often interleaved. Track tables identify which byte ranges belong to each track. |
| Why are MP4 stco and co64 offsets important? | They identify chunk locations using different offset widths. Examiners combine those locations with sample to chunk mappings and sample sizes to check that referenced media ranges exist and are coherent. |
| Can MOV udta identify the recording device? | User data may include device or software descriptions, but fields vary across writers and can be rewritten. Their placement and values should be compared with source context and other structural characteristics. |
| Does MP4 faststart mean the video was edited? | No. Faststart generally places moov before media data so playback can begin without first downloading the file's end. It can be created during ordinary recording or by relocating metadata after capture. |
File type box declaring a major brand, minor version, and compatible brands.
Movie header containing movie level timing and other presentation fields.
Track header identifying a track and carrying presentation attributes such as duration and display dimensions.
Media header defining a track's media timescale and duration.
Sample to chunk table describing how samples are grouped into chunks.
Sample size table giving a common size or individual sample sizes.
Chunk offset tables with 32 bit or 64 bit offsets.
User data container whose contents and placement depend on the format and writing application.
A conventional box starts with a 32 bit size and a four byte type. The ordinary header is eight bytes, and its declared size includes the header. A size value of 1 signals an extended 64 bit size field. A size value of 0 extends the box to the end of the file. Interpret these special values before calculating the next boundary.
| Header element | Example or role | Validation task |
|---|---|---|
| Ordinary size | Total box length in bytes | Check sufficient space for header and payload |
| Type | 66 74 79 70 means ftyp | Interpret bytes at a valid box boundary |
| Extended size | 64 bit size after size equals 1 | Check expanded header and containing boundary |
| Parent range | Child boxes inside moov or trak | Reject children extending beyond their parent |
An ftyp box declares a major brand, a minor version, and compatible brands. Values such as isom, mp41, and mp42 describe compatibility families. QuickTime uses a brand rendered as qt followed by two spaces. M4V followed by a space is another encountered brand. Preserve spaces in these four byte values.
Brands are not authenticated device identities. Applications share brands, and remultiplexing can replace them. Older QuickTime files may not follow the modern expectation of an ftyp box at the beginning. Use the full box tree and decoding behavior before declaring a file invalid.
The free box can reserve update space. Record padding boundaries and examine interpretable remnants. A raw search for moov is insufficient because those bytes can occur inside unrelated payload.
A useful box listing preserves offsets, sizes, parent relationships, versions, and raw values. The analysis becomes meaningful when those declarations are tested against actual sample ranges and playback.
Request Confidential Consultation Call (833) 292 3733The moov box describes the movie. Its mvhd header supplies movie level timing. Each trak describes a separate track, such as video, audio, or telemetry. The tkhd header carries track identity and presentation properties. Inside mdia, mdhd supplies media timing, hdlr identifies the handler type, and minf contains media information including the sample table hierarchy.
| Box path | Information | Forensic comparison |
|---|---|---|
| moov/mvhd | Movie timescale and duration | Overall declared presentation length |
| moov/trak/tkhd | Track ID, duration, display attributes | Track identity and movie timeline relationship |
| moov/trak/mdia/mdhd | Media timescale and duration | Track timing in its own units |
| moov/trak/mdia/hdlr | Handler type such as vide or soun | Declared role against actual sample description |
| moov/trak/mdia/minf/stbl | Sample descriptions and indexing tables | Connection between instructions and media bytes |
A timescale is a count of units per second, not a camera frame rate. For example, a movie duration of 12000 at timescale 1000 describes twelve seconds. An audio track can use a different media timescale. Convert each field using its own declared basis before comparing durations. The tkhd duration uses the movie timescale, while mdhd uses the media timescale.
Creation and modification fields in these header families use seconds counted from 1 January 1904 UTC under the format definition. Version 0 and version 1 use different field widths. Zero values, clock errors, and writer conventions require interpretation before presenting a calendar date. A displayed local time produced by a parser should not replace the raw integer in the examination record.
Track display dimensions and transformation matrices can affect rotation and presentation without changing the encoded picture dimensions. Compare them with the visual sample entry and codec configuration. The metadata analysis guide explains descriptive dates and orientation; structural reporting should preserve where each value was actually found.
Track edit lists map media time onto movie time. Consequently, unequal audio and video media durations do not automatically mean that material was deleted. Reconstruct the presentation timeline before interpreting any mismatch.
In a conventional unfragmented file, stbl connects the track description to compressed samples. Chunks group indexed samples for storage. Samples from multiple tracks can be interleaved within an mdat. The payload is not organized as a simple sequence of human readable frames with their own filenames.
The stsd table holds sample entries and decoder configuration. The stts table supplies decoding time deltas. Where present, ctts supplies offsets relating composition time to decoding time. The stss table identifies sync samples when that table is used. The stsc mapping, stsz sample sizes, and stco or co64 chunk offsets together locate individual sample ranges.
A chunk offset locates the chunk, not every sample. Calculate successive sample locations from their sizes and preserve the supporting table entry indexes.
Reordered compressed pictures require care: decoding order and display order can differ. A naive export sorted only by storage position can misrepresent the sequence. Sync sample declarations also need interpretation against codec behavior. Our codec and GOP analysis guide follows the compressed picture layer beyond these container indexes.
Multiple mdat boxes are possible. Some formats permit external media references, which must be resolved explicitly rather than assumed to identify local payload. A sample table that points outside available media can indicate truncation, an incomplete collection, a parser assumption, or malformed construction. Determine which explanation fits the complete structure.
Faststart is a placement strategy: moov appears before the media payload so a client can obtain playback instructions early. Moving an existing moov requires updating affected chunk offsets. A correctly relocated file can retain the same compressed media while changing its overall hash and byte layout. That is a container transformation, not necessarily a change to depicted events.
User information can appear under udta, with metadata structures such as meta, keys, and ilst depending on the convention. Entries may describe software, device model, location, or a creation date. QuickTime keys can include com.apple.quicktime.creationdate and com.apple.quicktime.model. Parse the actual metadata scheme rather than treating every similarly named entry as the same field.
Compare metadata order, padding, and brands with controlled files from the suspected workflow. These characteristics do not uniquely identify a device.
Fragmented media distributes sample information across movie fragments. A moof contains track fragments, with boxes such as tfhd, tfdt, and trun providing defaults, timing, and sample run information. Media bytes commonly follow in mdat. Initialization metadata can therefore lack the populated conventional sample tables an examiner expects from a single completed camera file.
A missing moov in a conventional recording can prevent normal playback because the sample index and decoder configuration are unavailable. A crash or incomplete transfer is a plausible explanation. Recovery may require a valid reference recording and careful reconstruction; any recovered file is a derived object whose assumptions must be documented. Do not silently replace damaged evidence with the reconstructed version.
Check the parsed map with independent interpretation and byte inspection. The video authenticity checklist combines structural findings with source records and visual review.
Use a preserved working copy and retain a machine readable box listing alongside the narrative findings. Each calculated location should be traceable to its source table entry.
We reconstruct the relationship between container instructions and media bytes, explain timing and addressing discrepancies, and distinguish ordinary layout changes from observations requiring further investigation. Findings identify the exact boxes, offsets, and sample ranges supporting the interpretation. The analysts doing this work are subject matter experts in MP4 and MOV file structure who read every box and atom in the container directly.
Elite Digital Forensics is an independent digital forensics practice serving attorneys, paralegals, in house counsel, insurers, lenders, businesses, and individuals nationwide. Our team includes former law enforcement forensic examiners and court qualified expert witnesses in computer, cell phone, cloud, document, and multimedia forensics. Every engagement begins with a scoped plan, hash verified evidence handling, and a clear explanation of what the examination can answer.
Yes. Multiple media data boxes are permitted in relevant layouts. Follow track or fragment addressing to determine which bytes belong to each sample instead of assuming one contiguous payload.
They can use different timescales and describe different timeline levels. Convert each duration to seconds and account for track edit mapping before evaluating disagreement.
No. Track display dimensions and matrices concern presentation. Compare the sample description and codec configuration to establish encoded dimensions and any display transformation.
In the conventional sample table model, absence means all samples are treated as sync samples. Evaluate that declaration alongside the applicable sample format and actual codec behavior.
Yes. Relocating movie metadata and rewriting affected offsets can preserve the compressed samples. The file digest changes because the container bytes change even if the media samples do not.
Identify the track, table entry, declared offset, calculated sample range, and available file boundaries. Explain tested causes such as truncation, missing media, or invalid rewriting, and preserve any repaired version separately.
Preserve raw headers and tables before interpretation. A defensible structural finding connects those declarations to actual bytes, decoded samples, and the specific disputed playback interval. Our court qualified experts in video forensics can explain how the container structure supports or contradicts the claimed recording device.
Request Confidential Consultation Call (833) 292 3733This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.
Elite Digital Forensics Assistant
By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.
IMPORTANT: Please remember to check your spam or junk folder