Recovering GoPro and drone footage after power loss

What power loss actually does to the file

Action cameras and drones record into an MP4 or MOV container, and that container has a specific, unforgiving quirk. While you record, the camera streams the compressed video and audio to the card as one growing block. It does not yet write the index: the table that tells a player where every frame starts, how long it lasts, and how the audio lines up. The camera can only write that index once recording ends, because until then it doesn't know the final sizes. So the index is written last, at the moment you press stop.

Cut the power before that moment and you get a file with a valid start and all your footage, but no index. In MP4 terms the file has its ftyp header and its mdat block of media data, and it is missing the moov atom that indexes them. A player opens it, finds no index, and refuses. Tools like ffmpeg report it bluntly as moov atom not found. It is the single most common way in-flight and mid-record footage breaks, and, importantly, the most recoverable, because the data survived and only the map is gone.

Power loss mid-record, drawn: the footage reached the card, but the index the camera writes at stop never got written.

For a byte-level tour of that missing index and why it lives at the end of the file, see what "moov atom not found" means.

Try the camera's own repair first

If you shoot GoPro, the first move is free and official, and most repair guides skip it because it doesn't sell anything. When a GoPro finds an unfinalized clip, usually after a dead battery or a card pulled early, it offers to repair the file itself on the next power-up. Depending on the model you'll see a repair icon or the words REPAIRING FILE on the screen. Press any button to let it run. If it works, you get a playable clip straight out of the camera with no software involved.

Two honest limits on the in-camera repair, both by design. It only fixes truncated files, the exact power-loss case above; it can't do anything about a physically failing card. And it only works on files recorded by that same camera model, because it leans on the camera's own knowledge of its recording format. If the repair loops or stalls, power the camera off, reseat the battery and the SD card, and give it one more attempt before moving on. DJI aircraft, worth saying plainly, have no equivalent in-camera repair, so drone footage goes straight to the software approach below.

When in-camera repair fails

The camera's own repair is a good first pass, but it gives up easily, and there are common situations it won't touch:

• Power lost mid-write. A hard cut, a battery yanked under load, or a drone that lost power in the air can leave the file in a state the camera declines to fix.
• The card was pulled early. Removing the card before the camera finished flushing data leaves a truncated file the camera may not recognize on the next boot.
• The card filled mid-recording. Running out of space during a clip is another way to strand an unfinalized file.
• The repair just loops. After a reseat, if it still won't complete, the camera has done what it can.

In every one of these the underlying file is the same: footage present, index missing. That is a job for a software rebuild of the index, on a copy of the file, so the original on the card stays untouched.

The reference-clip approach

Rebuilding a missing index means figuring out the structure of the footage from the footage itself, and the most reliable way to do that is with a reference clip: a healthy, normally finalized recording from the same camera at the same settings. The healthy clip carries a complete, valid index for exactly the resolution, frame rate, codec, and bitrate your broken file used. That gives the rebuild a template that fits, so it can reconstruct the missing index over your surviving footage and write out a playable file.

This is the same class of reconstruction that command-line tools like untrunc perform, and the reason the reference clip matters so much: it is not decoration, it is the map the rebuild reads to interpret your data. Get one by shooting a few seconds of throwaway footage on the same camera at the same settings, then stopping the recording normally so it finalizes.

The honest limits are worth stating up front. The last few seconds before the power cut were still in the camera's memory buffer and never reached the card, so they are gone; the rebuild returns everything up to that point. Footage recorded with wildly variable bitrate can come back with minor audio and video drift. And the reference has to genuinely match: a clip at a different resolution or from a different camera won't line up. What you get back is your real footage, rebuilt around a valid index, not invented frames.

When it's a 0-byte file: recovery, not repair

There is one case where none of the above applies. If the clip reads 0 bytes, or is a tiny fraction of the size it should be, or opens as an unbroken run of zeros, then the footage never made it to the card. That is not a broken index over good data; it is an absence of data. No repair tool can rebuild a file from nothing, and any tool that claims to is selling you a scan result.

A 0-byte clip means the card failed mid-write, or the filesystem lost track of where the data went. The right first step is recovery: card recovery software searches the raw storage for footage the filesystem no longer points to. If it finds something, you then have a file to repair. Recovery and repair are two different jobs done in that order, and the surest way to protect against needing either is a few reliable card habits, covered in how to avoid corrupting files on SD cards.