Fix it now
- Drop the file
- Repair runs locally
- Download the result
The DJI FPV is a single-camera aircraft built to be flown first-person through goggles, and that immersive, high-speed flying is exactly what puts its footage at risk. It records one onboard stream — up to 4K at 60 fps, at a demanding 120 Mb/s in H.265 (HEVC) — straight to the microSD in the airframe, with RockSteady (and HorizonSteady) electronic stabilization and wide-lens distortion correction applied in-camera and baked into that file as it is written. Unlike a stable, dual-camera drone such as the Air 3, the FPV is meant to be thrown at gates, trees and terrain at speed — so on this aircraft the single most common reason a clip won't open is blunt: a high-speed crash stopped the recording on impact, before the drone could stamp the moov index an MP4 needs to be playable. The frames — RockSteady stabilization and all — are almost always still in the file; only the map to them is gone. (That full-quality onboard clip is also separate from the low-resolution DVR feed cached in your goggles; both are MP4s, but the onboard file is the one to prioritize.) Drop the clip above and the tool checks exactly that, in your browser, and rebuilds the container when the footage is recoverable.
Why an FPV crash strands the clip that was in progress
On a camera drone that flies smooth lines, the last clip usually breaks because the battery ran down. On the FPV it is almost always the crash. You fly inches from obstacles at speed, so the recording rarely gets the clean stop it needs: an MP4 becomes playable only once the drone writes its moov index — the table that says where every frame lives and how the H.265 stream is configured — and that index is stamped last. Cut the flight short and it never lands.
- Crash on impact — the usual culprit. A clipped gate, a branch, or the ground stops the airframe instantly, and the write stops with it. A high-energy hit truncates the final
mdatmid-GOP, so the file ends abruptly with nomoovbehind it. This is the single most common way an FPV clip is lost. - Power torn away mid-maneuver. A battery ejected on impact, a pack flown flat, or a brownout during a hard punch-out cuts power the instant it happens, leaving the current file headless.
- A card that couldn't keep up. That single 120 Mb/s H.265 stream is demanding; a microSD too slow for it — or one knocked loose in the crash — can truncate the recording even without a hard hit.
What you are left with looks intact from the outside: a clip of a believable size, often hundreds of megabytes, that a player still calls corrupt, reports as 0:00, or opens to a black frame. That weight is the reassuring part — the encoded, already-stabilized frames are sitting in the file; what the crash took was the index, not the footage. Clips from earlier in the same session play fine because they were finalized before the run that ended in the crash.
How the container gets rebuilt — and why earlier clips help
With the moov gone, it can be regenerated by scanning what survived in the mdat and rebuilding the sample tables the drone would have written on a clean stop. Because RockSteady and the lens-distortion correction were applied in-camera and encoded into those frames, whatever the rebuild recovers comes back already stabilized and corrected, exactly as the drone recorded it — this tool re-maps the existing frames, it does not re-process the picture. For a faithful result the rebuild needs the clip's exact stream configuration — codec (H.265 or H.264), resolution, frame rate and the parameter sets — and the best source is a healthy clip from the same DJI FPV shot in the same mode. Since a crash normally leaves the earlier clips on that same card untouched, you usually have an ideal reference already; you'll only be prompted for one if the file needs it.
Two honest limits for a crashed FPV. First, the truncation is the ceiling: the rebuild recovers every frame that actually reached the card before impact, but the frames the drone never got to write — the split-second after the hit cut the recording — were never saved, and no software can invent them. Second, if the aircraft went into water, mud, or a long tumble, inspect the microSD itself before anything else; a physically damaged card can return zeros for stretches of the file, and zeros can't be rebuilt. Copy the card to your computer first; if the bytes are there, the container rebuild does the rest. (If all you have is the goggle DVR clip, this tool can rebuild that too, but it will only ever be the lower-resolution copy of the onboard 4K.)
What this can and can't fix
Can fix
- The clip that was recording at the moment of a crash on impact (unfinalized MP4, missing moov) — the most common FPV failure
- Onboard H.265 (or H.264) .MP4 files that copied off the card but won't open in any player — RockSteady footage recovered exactly as it was baked in
- Container damage: missing index, wrong offsets, zero-length duration, when the encoded frames survived
- Files a recovery tool handed back unplayable, when the footage itself is intact
Can't fix
- Frames the crash cut off before they were written — truncation past the point of impact can't be invented
- Data physically lost to a microSD damaged in the crash (recover the card first, then repair)
- Full onboard 4K from the goggles' DVR alone — that cached feed is a separate, lower-resolution file (repairable on its own, but never a substitute for the drone's 4K)
- Files that read as 0 bytes or mostly zeros
If a repair fails, we tell you why (missing data versus broken structure), and you are never charged for a failed repair.