Your video will not play after a power cut

Why losing power breaks a file that is otherwise complete

A camera writes your recording to the card continuously while it runs. What it does not write until you press stop is the index: the table listing the exact byte position and size of every frame. In an MP4 or MOV that table lives in a block called moov, and it is written at the end because the camera cannot know what goes in it until the recording is over.

Cut the power before that moment and you are left with the whole recording and no map of it. The file is the size you would expect, every frame is sitting inside it, and every player refuses to open it because none of them will guess where the frames are. The exact error and what it means.

Power loss has three outcomes. Which one you got is already decided.

It was settled at the instant the power went, by how far the device had got. Nothing you do now changes which case you are in, and they need different tools, so it is worth a minute to find out rather than working through fixes for the other two.

The file is a normal size but nothing opens it

This is the recoverable case, and it is by far the most common one after a power cut during recording. The picture data is on the card. Only the index is missing, and an index can be rebuilt by reading the recording and working out where each frame begins. Everything below is about this case.

The file is zero bytes, or a few kilobytes

Then the camera never flushed the recording to the card. There is no footage inside the file to find, and no amount of index rebuilding invents it. This is the honest answer to my video file is 0 bytes: rebuilding tools cannot help you, and software that claims otherwise is selling you a scan of an empty file.

Your remaining route is card level recovery, which ignores the filesystem and searches the raw card for data the camera wrote before the directory entry was updated. PhotoRec is free, open source and is the standard tool for exactly this. Run it against the card, not against the zero byte file.

The card will not mount, or the files look scrambled

Losing power damaged the filesystem rather than one recording. Repair the card first, or image it and carve it with PhotoRec. Trying to rebuild an index on a file read through a broken filesystem gives you nothing useful, because the bytes you are handed are not reliably the bytes the camera wrote.

Telling them apart in the terminal

On a Mac, two commands settle it. Substitute your own filename:

ls -l GH011234.MP4
strings -t d GH011234.MP4 | grep -m 5 -E 'ftyp|mdat|moov'

A size in the hundreds of megabytes or gigabytes, with ftyp and mdat present but no moov, is the good outcome: the footage is there and only the index is missing. A size of zero, or a handful of kilobytes, is the second case above. If the drive will not even list the file, work through the failure types here first.

Check whether your footage survived, free

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.

This checker has its own page at cinesalve.honorboxx.workers.dev/check, which is easier to pass to someone else who needs it.

The free things to try, in order

Let the camera try first. Many cameras carry their own repair pass for a recording they never closed. GoPro calls it SOS and it triggers by putting the original card back in the camera that shot it and powering on. It costs a minute and sometimes it is the whole fix. The GoPro steps in detail, the same for a DJI drone, or for a Canon DSLR, where a long take is split across several files and most of them are usually fine, or for an iPhone, where the first job is getting the original off the phone unconverted, or for a Sony camcorder, which keeps a catalogue of the card that can break while every recording on it stays intact.

Look for a proxy next to the clip. GoPro writes an .LRV low resolution copy alongside every recording, and it is written separately, so it is often intact when the main file is not. Rename a copy of it to .MP4. It is not what you shot, but it tells you at once that the recording really happened.

Then rebuild the index. untrunc is free, open source, and does this well if you are comfortable compiling a command line tool and giving it a healthy reference clip from the same camera. Try it before paying anyone. If it will not build on your Mac, these are the errors and what they mean.

Cinesalve

A Mac app that rebuilds the index. An interrupted recording is the case it is built for: its test suite takes footage straight off real cameras, cuts each file short the way a power cut does, and then checks every recovered frame against the original by byte position and size. These are the results of that run.

GoPro recordings carry their own codec configuration, in the H.264 and the HEVC modes alike, so for those you hand it the file that will not open and nothing else. The other makes keep that configuration in the part of the file the power cut took with it, so they need a healthy clip from the same camera, which the app asks for by name rather than guessing. Nothing is uploaded and the recovery runs offline. $69 once.

On the Apple muxed recordings the sound comes back too, roughly nine frames in ten landing correctly. Action cameras and drones write timecode and telemetry into the same block as the picture, and those bytes cannot be told from audio confidently enough to place, so on those Cinesalve returns the picture and says it left the sound out rather than writing bytes it cannot verify into your recording. Picture is exact either way.

If none of it works

Send the clip, or just describe it, to cinesalve@proton.me (or the contact form) with the camera model and roughly what happened. You will get a straight answer about whether it can be recovered, including when the answer is no. That costs nothing and there is no pitch attached.