AVI or MKV won't play — what's actually fixable, and the header lie to watch for

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.

How AVI breaks

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:

• The header lies. The AVI header declares a frame count and duration that were written up front or copied by a recovery tool — they describe what the file was supposed to contain, not what it does. A 640 MB AVI can declare 4.6 minutes while holding two seconds of decodable data — or hold the full 4.6 minutes that a naive repair truncates to two seconds. Either way, any tool that trusts the header instead of measuring the payload will confidently hand you the wrong answer.
• Undelete damage. AVIs that come back from card recovery often have shifted or interleaved chunks — the container looks valid but the chunk boundaries no longer line up with real frames.

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.

How MKV breaks

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.

What repair looks like for these files

• Structure intact, container damaged: the streams are lifted out and rebuilt into a clean container. This is the common case for truncated MKVs and for AVIs whose index is missing but whose chunks are sound.
• Chunk-level damage (MJPEG AVI): frame-walk recovery — find every JPEG in the payload, validate each one structurally, rebuild the file from the frames that are actually whole.
• Verified, not assumed: the result is decoded end to end before you see it, and the reported duration is what actually plays — not what a header claims.

What honestly can't be fixed

• Header-only shells. A recovered AVI whose movi section is empty or zero-filled has no frames to rebuild — the free analysis will tell you that plainly.
• MKVs missing their track headers with no healthy sibling file to supply the codec setup.
• Re-encoded artifacts. If a previous "repair" re-encoded garbage into a valid-but-scrambled file, the original information is gone — always upload the original broken file, not another tool's output.

Free during the beta: there is no payment step today. When paid recovery eventually launches, you will pay only if we hand back a file that actually plays — for the duration we report, not the duration a header claims.

Frequently asked questions

My player shows the right duration but the video stops after a few seconds.

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.

Is a truncated MKV recoverable?

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.

A recovery tool gave me back my AVI but it's a mess of colors and blocks.

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.

Do you handle WebM files too?

Yes. WebM is a subset of MKV and breaks the same ways, so the same recovery applies.

What does it cost?

Nothing today. RepairMyVideo is free during the beta: there is no payment step, and analysis, repair and download all cost nothing. When paid recovery eventually launches, analysis and diagnosis will stay free, and payment will apply only to a successful repair, meaning a file verified to actually play, not just one that opens.