Repair a corrupted Android video

The Android media stack is explicit about when a recording becomes playable. During capture, MediaRecorder (or a camera app using MediaCodec + MediaMuxer directly) appends encoded samples to the mdat. The moov atom — sample sizes, chunk offsets, timing tables and the codec's parameter sets — is assembled in memory and flushed to the end of the file only when stop() and release() run. Miss that step and the bytes on disk are a headless MP4: real frames, no map.

Three interruptions cause it. The Camera app crashed or was killed. A bug, or Android's low-memory killer reclaiming a background/foreground app under memory pressure, ends the process before stop() — so nothing writes the index. Storage filled up mid-record. 4K HEVC writes fast; when internal storage or the SD card hits zero free bytes, the muxer's write fails partway and the file is truncated with no moov. The phone powered off. A dead battery or forced restart during capture skips finalization the same way.

The codec inside is either HEVC/H.265 (the default for high-resolution modes on most modern Androids, chosen for its efficiency) or H.264/AVC (the compatibility fallback). The container behaviour is identical for both, which is why the repair path is the same regardless of codec.

Because the frame data survives in the mdat, the fix is to reconstruct the index that MediaMuxer.stop() never wrote. The tool scans the surviving stream, recovers each frame's boundaries and timing, and rebuilds the sample tables so a player can decode from the start — turning a headless file back into a normal, seekable MP4. Where the file was also truncated by a full disk, it salvages the frames that were completely written before the cut and closes a playable container around them, so a clip that captured 80% of a take gives back that 80% instead of failing whole. All of this runs in your browser as the file is read from storage.

The honest limit is that frames written after the interruption don't exist — a full disk stops the write, a crash stops the encoder, and no tool can invent bytes that were never stored. When only the truncated copy remains, salvage is the right move; if the original file is still on the phone and can simply be re-copied cleanly, do that first, because a good copy beats any repair.

Rebuilding the index is most reliable when the tool knows the exact codec configuration the broken file omitted. A healthy clip from the same phone, recorded by the same app in the same mode, supplies precisely that — the HEVC parameter sets (VPS/SPS/PPS) or the H.264 SPS/PPS, plus the resolution and frame rate — so the reconstruction reproduces the original instead of approximating it.

Practically: record a few throwaway seconds with the same camera app and the same quality settings, and keep it handy. Match the codec (HEVC reference for an HEVC clip, H.264 for H.264), and you'll only be asked for it if the repair needs it. A sample from a different phone or a different app usually won't match, because the parameter sets differ.