Field notes
Your camera lost power mid‑recording and now nothing will open the file. Here is exactly what happened, how to check in one command whether the footage survived, and what actually gets it back.
The footage is almost certainly still in the file. What is missing
is the index that tells a player where each frame lives. An MP4 or MOV keeps its
picture and sound in one big block called mdat, and the map of that
block in a much smaller structure called moov. Cameras write
moov last, when you press stop, because they only know the
final sizes and timings once recording ends.
Pull the battery, pop the card, or crash the camera, and you get a file with all
the footage and no map. Every player refuses it, because without moov
a player cannot know the codec, the resolution, the frame rate, or where frame one
begins. It is not damaged footage. It is unlabelled footage.
Before trying anything, find out whether there is footage in there at all. You are
looking for three four‑letter markers: ftyp in the first bytes,
mdat shortly after it, and whether moov appears anywhere.
On macOS or Linux:
ls -l yourfile.mp4 strings -t d yourfile.mp4 | grep -m 5 -E 'ftyp|mdat|moov'
The numbers on the left are byte offsets, so ftyp should appear at or
near 0 and mdat within the first few hundred bytes. To look at the very
start of the file directly:
xxd -l 64 yourfile.mp4
Three outcomes, and they decide everything that follows.
ftyp and mdat, but no moovThis is the good case, and it is by far the most common one after a power loss. The recording is intact and the index was never written. It is recoverable.
ls shows 0 bytesThe camera created the file and never wrote the footage. There is nothing to recover from the file itself. Your remaining option is card‑level recovery software that scans for orphaned data, and it is worth stopping all use of that card immediately. Which free tool does that, and the rest of what a power cut can do.
That is a different problem, usually a partially overwritten mdat or a
failing card, and rebuilding the index will not fix it.
Do not let anything write to that card. Copy the file off it first and work on the copy. If the card is still in the camera, take it out. Every additional recording risks landing on top of the data you want back.
This runs in your browser. The file is not uploaded, and only the first and last megabyte are read, which is where the markers that decide the answer live. Works on any computer, including Windows, even though the app itself is Mac only.
Not sure this is your failure? The three things “corrupted” usually means, and how to tell them apart.
Most recordings do not need a second clip at all — why, and how to tell whether yours does.
This checker has its own page at cinesalve.honorboxx.workers.dev/check — easier to pass to someone else who needs it.
This is the advice you will find most often, and it is why so many people conclude
the file is beyond help. The moov atom is not a header you can
transplant. It contains, for every single frame in the recording:
A 10‑minute clip at 30fps has 18,000 video frames and roughly 26,000 audio frames, and every one of those numbers is specific to your recording. Copying another file's index gives a player a map of a different building. It will either refuse the file or produce garbage.
So the index has to be rebuilt, not borrowed. That means walking
the raw mdat block and working out where every frame begins and ends,
with nothing marking the boundaries.
Video is the tractable half. Inside an MP4, H.264 and HEVC frames are stored as a run of units, each preceded by its own length. So if you guess a frame start correctly, the length you read points exactly at the next valid unit header, and if you guess wrong the chain collapses within a hop or two. That asymmetry is what makes video recovery reliable rather than statistical.
Audio is harder. AAC frames in an MP4 carry no length prefix and no sync word, so the boundaries have to be inferred. Get them wrong and the audio decodes to noise even though the video is perfect. This is the part most tools quietly do badly.
Both halves need something the damaged file no longer states: which codec, what resolution, what frame rate, how the camera interleaves picture and sound, and the encoder's own configuration. That information exists in any other clip from the same camera at the same settings. This is why every serious tool asks for a reference file, and why the reference has to be from the same camera and the same recording mode. It is not an inconvenience, it is the whole mechanism.
untrunc does genuinely good work
and costs nothing. It is a command line tool you compile yourself or run through
Docker, you pass it a reference file and the broken one, and it writes a repaired
copy. If you are comfortable in a terminal, try it first. Camera specific metadata
sometimes needs the -s flag to stop it aborting.
Its limits are practical rather than technical: you find out whether it worked by opening the output, and if it produces nothing useful you are left without a next step and without knowing whether the footage was ever recoverable.
Several exist and some will fix your file. Read the refund terms before paying: it is common in this category to be charged up front with no refund if the repair fails, which is the complaint that dominates their reviews. If a service asks you to upload the footage, consider what is in it first.
No other clip from that camera? Record one now. A few seconds at the same settings is enough. The damaged file no longer states its own codec settings, so they have to be read from a working recording, which is why every tool that can do this asks for one.
A Mac app that does the rebuild described above. Every recovered frame lands at the byte offset and size the camera originally wrote, measured that way against footage from GoPro HERO5 through HERO8, Karma, Fusion, MAX, a DJI Mavic 3 Pro, a Canon EOS 5D Mark II and Apple's own muxer. The GoPro models measured are recovered from the damaged file alone, in both the H.264 and the HEVC modes the range records; the rest ask for any clip from the same camera that plays. Nothing is uploaded, it runs entirely on your Mac and the recovery runs offline. $69 once, every Mac you own, for good.
On the test suite, video frames come back byte‑exact: a frame decoded from a repaired file is identical to the same frame in the original.
Send the file, or just a description of it, to cinesalve@proton.me (or the contact form) with the camera model and recording mode. You will get a straight answer about whether it is recoverable, including when the answer is no and when a free tool is the right call. That costs nothing and there is no pitch attached to it.