How Video Repair Works: Understanding File Structure

Video repair can feel like magic — you feed in a broken file and get back a working video. But there is nothing magical about it. Understanding how video repair works comes down to understanding how video files are structured, what goes wrong when they get corrupted, and how software can piece things back together.

If you are still diagnosing the problem, start with our guide to fixing videos that won't play. If you already know the damaged file came from a specific device, the iPhone video repair guide and GoPro video repair guide walk through device-specific recovery steps.

Think of it this way: a video file is like a book. The actual content (video frames and audio samples) is the body of the book, and the metadata is the table of contents. When the table of contents is damaged or missing, you cannot navigate the book — even though all the pages are still there. Video repair is essentially the process of rebuilding that table of contents.

Understanding Video File Structure

Most modern video files — MP4, MOV, M4V, M4A, 3GP — use the same underlying container format defined by the ISO Base Media File Format (ISO 14496-12). This format organizes data into nested structures called atoms (also known as boxes).

Each atom has a simple layout: a size field, a four-character type code, and its payload. Atoms can contain other atoms, forming a tree structure. A typical MP4 file contains dozens of atoms, but three are critical:

• ftyp — The file type declaration. It sits at the very beginning and tells players what format and codecs to expect.
• moov — The metadata container. This is where all the structural information lives.
• mdat — The media data container. This holds the actual compressed video frames and audio samples.

The moov Atom — Your Video's Table of Contents

The moov atom is the single most important piece of metadata in an MP4 file. Without it, a media player has no idea how to interpret the raw bytes inside mdat.

Inside moov, you will find a hierarchy of sub-atoms:

• mvhd — Movie header with global properties like duration and timescale.
• trak — One track atom per media stream (typically one for video, one for audio).
• stbl — The sample table, nested inside each track. This is where the real mapping lives.

The sample table (stbl) contains several critical sub-atoms:

• stsd — Sample description: codec type, resolution, frame rate, audio sample rate.
• stts — Time-to-sample mapping: how long each frame is displayed.
• stsc — Sample-to-chunk mapping: how samples are grouped into chunks.
• stco / co64 — Chunk offset table: the byte position of each chunk within the file.
• stsz — Sample size table: the byte size of every individual sample.

Together, these tables let a player say: "I want frame #5000. It is in chunk #312, which starts at byte offset 4,521,088 in the file, and the frame is 12,847 bytes long." Without this information, the raw data in mdat is just an opaque blob of bytes.

The mdat Atom — Where Your Actual Video Lives

The mdat atom is conceptually simple: it is a container for raw compressed media data. Video frames encoded with H.264 (or H.265, VP9, etc.) and audio samples encoded with AAC (or MP3, Opus, etc.) are packed sequentially inside mdat.

The key insight is that mdat contains no structural information of its own. There are no markers saying "video frame starts here" or "this is audio sample #47." All of that mapping is handled by the sample table in moov.

This separation of data and metadata is what makes MP4 files both efficient and fragile. Efficient because players can seek to any point in the video by consulting the sample table without scanning the entire file. Fragile because losing the moov atom means losing the ability to interpret the data at all.

What Happens When a Video Gets Corrupted

Now that you understand the video file structure, it becomes clear why corruption is so devastating — and why repair is possible.

Video files get corrupted in predictable ways:

• Recording interrupted — The camera lost power, the app crashed, or the SD card was removed while recording. The camera wrote the mdat data in real time but never got the chance to finalize the moov atom (which is typically written at the end of recording). This is especially common with action cameras and dashcams that lose power unexpectedly.
• Incomplete transfer — A file copy or download was interrupted. The file is truncated, and the moov atom at the end is partially or completely missing.
• Storage failure — Bad sectors on an SD card or hard drive corrupted portions of the file. The moov atom might be partially overwritten or contain invalid offsets.
• Software bugs — A video editor or converter produced a file with incorrect chunk offsets, mismatched sample counts, or other structural errors.

The most common scenario — and the one that causes the most heartbreak — is the first: a camera that lost power mid-recording. In this case, the mdat atom contains perfectly good video and audio data, but the moov atom was never written. The file is essentially a book with all its pages intact but no table of contents. If your video won't play at all, this is very likely the reason.

This is exactly the kind of damage that video repair tools are designed to fix.

Three Strategies for Video Repair

Not all corruption is the same, so effective MP4 repair requires multiple strategies. VideoRepair uses a tiered approach, automatically selecting the best strategy based on what it finds in the damaged file.

Strategy 1: Fixing Chunk Offsets

This is the simplest and most reliable repair strategy. It applies when the moov atom exists and is structurally intact, but the chunk offset table (stco/co64) contains incorrect values.

How does this happen? When a video editor or muxer writes an MP4 file, it needs to record the exact byte position of each data chunk. If the moov atom is moved (for example, from the end of the file to the beginning for "fast start" optimization) but the offsets are not updated accordingly, every pointer in the chunk offset table will be wrong by a fixed amount.

The repair process:

1. Parse the moov atom and extract the existing sample table.
2. Calculate the offset delta — the difference between where the data actually is and where the offsets say it should be.
3. Apply the correction to every entry in the stco or co64 table.
4. Rebuild the moov atom with corrected offsets.

This strategy preserves all original metadata — codec parameters, timestamps, sample sizes — and only adjusts the pointers. The result is a perfect repair with no data loss.

Strategy 2: Rebuilding from Raw Data

This is the most technically challenging strategy, and it is needed when the moov atom is completely missing — the classic "camera lost power" scenario.

Without a moov atom, the repair tool must reconstruct the entire sample table from scratch by scanning the raw data inside mdat. This is like rebuilding a book's table of contents by reading every single page and figuring out where each chapter starts and ends.

Here is how it works:

1. Frame scanning — The tool scans through the mdat data byte by byte, looking for frame start codes. H.264 video frames begin with specific NAL (Network Abstraction Layer) unit patterns. AAC audio frames have their own sync markers (ADTS headers). These patterns are like fingerprints that identify each frame type.
2. Sample table reconstruction — As each frame is identified, the tool records its position, size, and type. This builds up the stsz (sample size), stco (chunk offset), and stsc (sample-to-chunk) tables from scratch.
3. Timing recovery — The tool estimates frame durations based on detected frame rates and audio sample rates, reconstructing the stts (time-to-sample) table.
4. Codec parameter extraction — H.264 streams contain special frames called SPS (Sequence Parameter Set) and PPS (Picture Parameter Set) that describe the video dimensions, profile, and level. The tool extracts these to build the stsd (sample description) atom.
5. moov assembly — All the reconstructed tables are assembled into a complete moov atom, which is prepended to the original mdat data.

This strategy can recover most of the video, but there are limitations. Without the original timing information, the tool must estimate frame durations, which can occasionally result in minor audio-video sync issues. The quality of the actual video and audio data, however, is preserved exactly as recorded.

Strategy 3: Using a Reference File

Sometimes the damaged file is missing not just the moov atom but also the codec parameter frames (SPS/PPS for video, AudioSpecificConfig for audio). This can happen when the very beginning of the recording was lost, since cameras typically write these parameters in the first few frames.

In this case, the tool needs a reference file — a healthy video recorded with the same camera using the same settings. The reference file provides:

• Codec configuration — The exact SPS/PPS parameters, audio codec settings, and channel layout.
• Track structure — The number and order of tracks (video first or audio first).
• Timing parameters — The timescale and default frame duration.

The repair process combines Strategy 2's frame scanning with the reference file's codec parameters:

1. Scan the damaged file's mdat to locate and catalog all frames.
2. Extract codec parameters from the reference file's moov atom.
3. Build a new moov atom using the reference file's codec configuration and the damaged file's actual frame positions and sizes.

Why Browser-Based Repair Matters

Traditional video repair tools require you to download and install desktop software, then upload your files to a server or process them locally with a native application. VideoRepair takes a fundamentally different approach: everything runs directly in your browser.

This is made possible by WebAssembly (WASM) — a technology that lets high-performance code written in languages like Rust run inside the browser at near-native speed. The core repair engine is written in Rust, compiled to WebAssembly, and executed entirely on your device.

This architecture has three significant advantages:

Privacy by design. Your video files never leave your device. There is no upload step, no cloud processing, no server that temporarily stores your footage. For journalists, lawyers, medical professionals, or anyone working with sensitive video content, this is not just a convenience — it is a requirement.

No installation required. Open the website, drop your file, and start repairing. There is nothing to download, no system requirements to check, no compatibility issues with your operating system. It works on any modern browser — Chrome, Edge, Safari, or Firefox — on any platform.

Performance. WebAssembly runs at near-native speed, which means the repair engine processes video data almost as fast as a desktop application would. The streaming architecture processes files in chunks, so even multi-gigabyte videos can be repaired without consuming excessive memory.

The combination of privacy, accessibility, and performance makes browser-based repair a practical choice for both casual users recovering a single vacation video and professionals dealing with corrupted footage on a deadline.

---