Not every broken video is an MP4. Older cameras, dashcams, CCTV systems and screen recorders write AVI; rips, OBS remuxes and archival files come as MKV or WebM. These containers break differently from MP4 — and one of them has a failure mode that fools repair tools into declaring success on a file that lost almost everything.
An AVI file is a RIFF container: a header block that declares the
stream formats and the total frame count, a
movi section holding the actual audio/video chunks, and an
optional idx1 index written at the very end. Interrupt the
recording and the index is missing — but unlike MP4, the chunks in
movi are individually tagged, so a truncated AVI is often
still partially readable. The real trouble is subtler:
We learned the header lie the hard way, from a real dashcam AVI: an early version of our own pipeline once accepted a fraction-of-a-second salvage as a "success" because the container math added up. The pipeline now measures the salvage ratio — how much genuinely decodable footage came out versus what the payload actually holds — and refuses to call a thin slice a recovery. For motion-JPEG AVIs (most dashcams and older cameras), recovery walks the payload frame by frame and structurally validates every single JPEG before it's allowed into the output.
MKV (and WebM, its subset) is the most damage-tolerant mainstream container: the stream is stored as a chain of self-describing, timestamped clusters. Cut an MKV off mid-write and players can usually still play it — you typically lose only seeking (the cues index was never written). The genuinely bad cases are damage to the track headers near the start of the file — without them no player knows how to decode the clusters — and recovery-tool output where cluster boundaries were reassembled wrong.
movi section is empty or zero-filled has no frames to
rebuild — the free analysis will tell you that plainly.You pay only if we hand back a file that actually plays — for the duration we report, not the duration a header claims.
AVI headers declare a duration that was written up front — it describes the intended recording, not what the file holds. The footage may genuinely end early, or it may all be there and the player is giving up at the first damaged chunk. The free analysis measures how much decodable footage actually exists, rather than trusting the header.
Usually, and often well: MKV stores self-describing clusters, so everything written before the cut is typically intact — commonly you lose only the ability to seek. Rebuilding the file into a clean container restores normal playback and seeking.
That points at chunk misalignment — the undelete tool reassembled the file in the wrong order, so chunk boundaries no longer match real frames. For motion-JPEG AVIs each frame can be found and validated individually, which recovers the frames that survived. Upload the recovered file as-is; don't re-encode it first.
Yes. WebM is a subset of MKV and breaks the same ways, so the same recovery applies.
Analysis and diagnosis are free. You pay only if the repair succeeds — meaning we hand back a file verified to actually play, not just one that opens.