Camera died mid-recording — why the file won't play, and what's recoverable

The battery ran out, the camera overheated and shut off, or someone pulled the power — and the recording you can't redo is now a file that no player will open. In most of these cases the footage is still inside the file. Here is what actually broke, and how recovery works.

What actually happened inside the file

An MP4 or MOV file has two main parts: the mdat box — the raw compressed video and audio frames, written to the card continuously while you record — and the moov box, the index that records which bytes belong to which frame, at what timestamp, in which track. Most cameras keep that index in memory and write it once, at the moment you press stop.

Lose power before that moment, and the card keeps every frame recorded up to the cut — but the index never gets written:

what a healthy file looks like     what your file looks like

ftyp   32 B   (file type)          ftyp   32 B   (file type)
mdat   1.9 GB (the frames)         mdat   1.4 GB (the frames — intact)
moov   6 MB   (the index)          <nothing — power died here>

The frames are there. The map to them is not.

Why every player refuses it

Players don't scan a video's raw data — they read the index first and seek from it. With no moov there is nothing to read, so you get "the file is corrupted", "format not supported", error 0xc00d36c4, a 0:00 duration, or a player that opens and shows nothing. Note the tell-tale sign: the file size is still large. A multi-gigabyte "unplayable" file usually means the data survived and only the index is missing.

What's recoverable — and how

The repair is to rebuild the index the camera never wrote: walk the mdat payload byte by byte, recognize the compressed frame boundaries (length-prefixed H.264/HEVC NAL units, interleaved AAC audio blocks), and reconstruct the sample tables from what is actually on disk. The rebuild also needs the codec parameters (SPS/PPS for video, the AAC configuration for audio) — sometimes they survive in-band in the stream, and when they don't, a healthy clip recorded on the same camera at the same settings (a "reference file") supplies them.

• Tail index: some devices manage to flush a partial index near the end of the file before dying — we look for that first, it makes the rebuild far more accurate.
• Reference file: a healthy clip from the same camera unlocks the harder cases.
• No reference? For camera models our catalog already knows, the matching template is applied automatically — no reference upload needed.

Audio is recovered alongside video by default, not dropped for convenience. And every result is verified before you see it: our playability check decodes the output end to end and refuses to hand back a file that plays for two seconds and then goes black.

What honestly can't be fixed

• 0-byte (or nearly empty) files. That's filesystem loss, not container damage — the recording never made it to the card, or the entry was lost. A card-level photo-recovery tool is the right next step, not a video repair service.
• Encrypted files. If the card or camera encrypts recordings, the payload is ciphertext — no repair service can rebuild an index for data it cannot read.
• "Recovered" files that are wall-to-wall filler. Undelete tools sometimes return a file of the right size that is actually repeating zero-blocks — flash storage discards deleted data (TRIM). No service can conjure frames out of zeros, whatever their marketing says.

The free analysis tells you which case your file is before anything else happens — including when the answer is "this one is gone".

Want to try fixing it yourself first?

Fair — two honest notes before you do:

• untrunc (open source) genuinely fixes this failure when you have a healthy clip from the same camera and are comfortable building the tool yourself. If that's you, it's worth a try — our honest untrunc guide covers setup and the failure cases to watch for.
• The ffmpeg myth: ffmpeg -i broken.mp4 -c copy fixed.mp4 copies streams using the index. When the moov was never written there is nothing to copy from — remuxing tricks only work on files whose index survived. Full map: can ffmpeg fix a corrupted MP4?

Free during the beta: there is no payment step today. When paid recovery eventually launches, you will pay only if we hand back a file that actually plays. If it can't be recovered, we say so plainly.

Frequently asked questions

The file shows its full size — doesn't that mean it's fine?

The size reflects the frames that were written, and that's genuinely good news for recovery. But playability depends on the index, which is written at stop-record. Large file + won't play is the classic signature of a missing index, and it's usually fixable.

Can VLC or ffmpeg repair a video with no index?

VLC can sometimes play a damaged stream, and ffmpeg can rewrap one, but both rely on the moov index existing. When power loss prevented the index from being written, there is nothing for them to copy — the index has to be rebuilt from the raw frames.

Do I need a reference file?

It helps a lot: a healthy clip from the same camera at the same settings supplies the codec parameters the broken file may lack. For camera models our catalog already knows, a matching template is applied automatically and no reference is needed.

Does this apply to MOV files too?

Yes. MP4 and MOV are the same container family, and this is the same failure with the same recovery path. GoPro, DJI, dashcams, phones and dedicated cameras all write these containers.

What does it cost?

Nothing today. RepairMyVideo is free during the beta: there is no payment step, and analysis, repair and download all cost nothing. When paid recovery eventually launches, analysis and diagnosis will stay free, and payment will apply only to a successful repair, meaning a file verified to actually play, not just one that opens.