Corrupt Video Checker — is your video repairable, and how badly is it broken?

A video that will not open is not one problem; it is one of several distinct failures that look identical from the outside. The file might be empty, it might contain every frame but lack the index that makes them playable, it might play but drift out of sync, or it might have one healthy stream and one dead one. Each failure has a different prognosis and a different fix, and guessing wrong can destroy what is left. This checker asks you two questions — what the container is and what the file does when you try to open it — and returns a verdict calibrated to those answers, along with the single safest next action.

The five verdicts, and what each one really means

Healthy. The container opens, duration matches the recording length, seeking works, and no warnings appear. Nothing needs fixing. The useful action here is preventive: confirm your container and path choices so the next scare never happens.

Playable with warnings. The file opens and runs for a while, then stutters, desyncs, or stops partway through. This usually means the media data is mostly intact but the timing information is damaged — often a truncated tail or a damaged timestamp table. A stream-copy repair that regenerates timestamps typically recovers everything up to the damage point without re-encoding.

Likely repairable — missing index. The file is a plausible size for its length but nothing can open it, and the tool reports the index atom is absent. This is the signature MP4 failure after a crash: every frame is present, sitting in order inside the media box, but the map that tells players where everything lives was never written. Recovery requires rebuilding that map from a reference file recorded with matching settings. Odds are good if you can produce the reference.

Severely damaged. A header exists but decodable media is sparse or absent, or the file is cut off mid-structure with too little payload to reconstruct. Some streams might be extractable as raw elementary streams, but a normal playable file is unlikely without a full re-encode of whatever fragments survive.

No usable media detected. Zero bytes, or so few bytes that nothing was meaningfully flushed to disk. There is nothing to repair in this file. The productive move is diagnosing why the write failed — wrong path, vanished mount, full disk, permissions — so the next recording actually lands.

Why the container decides your odds

The same crash produces wildly different outcomes depending on which wrapper OBS was writing.

MP4 and MOV centralize their index. Everything a player needs to seek and decode — sample tables, durations, offsets — lives in one structure that the recorder writes in a single pass when recording stops cleanly. Interrupt that pass and you have a large file that no player can navigate. The bytes are not gone; they are just unindexed. That is why this verdict is "likely repairable" rather than "lost": tools that rebuild the index from a reference file usually succeed when the media bytes are contiguous and undisturbed.

Matroska (MKV) and fragmented MP4 distribute their bookkeeping throughout the file. Each chunk carries enough information to be decoded on its own, and the index grows as recording proceeds. Interrupt the write and you sacrifice only the chunk in flight — typically a few seconds. The rest is already self-describing. This asymmetry is why OBS ships with MKV as its default recording format and why this checker treats an unopenable MKV as far more salvageable than an unopenable MP4 of identical size.

MPEG-TS behaves similarly to MKV for crash tolerance, which is why broadcast workflows favor it. FLV is legacy but also append-friendly. If you find yourself repeatedly recovering MP4s, the durable fix is changing the container, not getting better at recovery.

How to identify your symptom correctly

The verdict is only as good as the symptom you report. Before choosing one, do this two-minute check:

1. Look at the file size. Zero or a few kilobytes means choose "0 bytes" — nothing arrived on disk. A plausible size for the recorded duration means the media probably exists and the problem is structural.
2. Try opening it in VLC, not just your editor. VLC is far more tolerant of damaged containers. If VLC plays it but your editor will not import it, that is a codec or wrapper compatibility issue, not corruption — a different path than this checker handles.
3. If it plays, watch and scrub. Does it play cleanly then stop at a specific moment? Does audio continue while video freezes, or vice versa? Does seeking work? "Plays partially / desync" and "plays but warnings" lead to different fixes.
4. Listen for audio when video fails (and vice versa). One surviving stream changes the recovery plan: you extract the survivor and rebuild or replace the other.

Three verdicts in action — hypothetical walkthroughs

Note for corrupt-video-checker: The three cases below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — composite pictures of common failures, not documented incidents.

Case 1: the crashed MP4. A two-hour interview recorded to MP4 ends when the application crashes. The file shows 8.4 GB on disk; double-clicking produces an error, and ffprobe reports the missing index atom. The checker classifies this as likely repairable via index rebuild. The workflow: preserve the original, record ten seconds with identical settings to create a reference, run a rebuild tool such as Untrunc against the pair, then remux the result with stream copy. Because no re-encoding occurs, the recovered file is bit-for-bit the quality that was captured. Expected outcome: full recovery minus nothing, provided the disk itself is healthy.

Case 2: the power-cut MKV. A livestream recording in MKV loses power mid-broadcast. The file is 15 GB and refuses to seek, though it plays from the start and dies partway. The checker calls this playable-with-warnings territory: remux with stream copy and let the tool rebuild timing data while skipping the damaged tail. Expected outcome: everything up to a few seconds before the cut, playable and seekable, with zero quality loss. The lost tail is unrecoverable because it never left the write buffer — no tool can reconstruct frames that were never written.

Case 3: the zero-byte file after recording to a network share. The session appeared to run fine; the file on the NAS is 0 bytes. The checker returns no usable media, and that is the truth — no software anywhere can recover bytes that were never written. The value of the verdict is redirecting effort: verify the share stayed mounted, check permissions, confirm the NAS did not sleep, and move the recording path to a local disk. Then enable a segmented or verified upload path so a single point of failure never owns the entire recording again.

The decision tree, step by step

When a file misbehaves, walk this sequence rather than guessing:

1. Is the size effectively zero? Stop. Nothing to recover here; fix the recording path for next time.
2. Is it MP4/MOV and unopenable but correctly sized? Assume missing index. Do not run any tool that writes a new encoded file. Obtain a reference recording from the same preset and rebuild the index.
3. Is it MKV/TS/FLV and unopenable or partially playable? Copy first, then remux with stream copy, adding error-detection flags if the first attempt stumbles. Accept the truncated tail as the price of the crash.
4. Does it play but one stream is dead? Extract the survivor immediately, then decide whether the missing stream is worth a rebuild attempt or must be accepted as gone.
5. Does it play with desync or stutter? Regenerate timestamps with a stream copy pass; only re-encode if that fails, and only then at high quality to limit generational loss.

At every branch the rule is identical: never operate on the only copy, and never re-encode before every lossless option has been exhausted.

Mistakes that turn recoverable into unrecoverable

• Opening the file in an editor that tries to "repair" it on import. Some editors write a new file on import, re-encoding and discarding data the original still held. Inspect and copy before any editor touches it.
• Running a one-click repair app that re-encodes. If the app's first action is to decode and re-encode, it is gambling your quality against its convenience. Index problems need index solutions, not a fresh encode of partially decodable input.
• Recording over the folder. If the crashed file sits in the same directory OBS records to, a new session can reuse or crowd the space. Move the damaged file somewhere safe immediately.
• Trusting a partial copy. If you copied the file off a failing drive, verify the copy's size matches before deleting anything. A truncated copy of a truncated file compounds the problem.
• Guessing the reference file's settings. An index rebuild from a reference recorded at a different resolution, frame rate, or encoder setting produces garbage that looks like recovery until you scrub it. Ten seconds recorded on the exact preset is cheap insurance.

What this checker deliberately does not do

It does not touch your file; it returns a classification and a direction. It does not upload anything; the decision tree runs on the facts you enter. And it does not promise recovery — words like "likely" and "good chance" are there because disk-level damage, overwritten clusters, and encrypted volumes put some files beyond any software's reach. When the verdict is severe, the honest answer is extraction of whatever survives and prevention next time, not a miracle.

How this connects to WeaverClip — without bullshit

This checker exists because damage happens; the product exists so damage stops mattering as much. The recording helper segments footage into one-minute files and verifies each against the vault before releasing the local copy, so the failure unit is a minute, not a session. Gaps are marked explicitly rather than guessed at, which means downstream clip suggestions never point at footage that isn't there. If you are standing here with a broken file, use the verdict above and fix it. If you are tired of standing here, change where the recording lives next time.

FAQ

Can a 0-byte file ever be recovered? No. Zero bytes means no data reached the disk. Any tool claiming otherwise is selling hope. Recover the workflow instead: fix the path, the permissions, and the free space, then protect the next session.

Is an unopenable MP4 worse than an unopenable MKV? Usually the opposite. The MP4 likely holds all of its media with only the index missing — rebuildable with a good reference. An unopenable MKV more often means severe truncation. The checker weighs container behavior when it assigns odds.

Will re-encoding fix corruption? Only as a last resort, and it never restores lost data. A re-encode can make a glitchy file watchable by decoding what survives and writing a fresh container, but every re-encode degrades quality and freezes the damage into the output. Exhaust stream-copy options first.

How do I keep this from happening again? Record MKV or fragmented MP4, keep at least ten percent of the target disk empty, record to a local internal or fast external drive rather than network or removable media, and verify copies before deleting originals. Those four habits eliminate the overwhelming majority of these failures.

Does the checker work on phone recordings? Yes for the classification logic — phone MP4s fail the same way desktop ones do when an app crashes before finalizing. The reference-file technique applies too: a fresh few seconds from the same phone app and settings can anchor an index rebuild.

Gathering evidence before you ask for a verdict

The checker answers from two inputs, but the quality of your own diagnosis improves dramatically if you spend ninety seconds gathering evidence first. Here is the checklist a forensic-minded user runs before touching any repair tool:

1. Exact size, in bytes. Not "about 4 GB" — the precise number from file properties or ls -l. Compare it against what the session should have produced: expected GB = total Mbps × 0.45 × recorded hours. A file at 95 percent of expectation lost its tail; a file at 60 percent lost far more than a crash at the end would explain, which points at an earlier write failure.

2. The exact error message. "Will not open" covers at least four different errors with different meanings: moov atom not found (MP4 index missing), Invalid data found when processing input (truncated or damaged stream), No such file from a player that cannot parse the container at all, and a silent zero-length read. Write down which one you got — or paste it into ffprobe: ffprobe -v error broken.mp4 prints the decoder's actual complaint.

3. The recording context. Which container OBS was set to, whether the session ended with Stop Recording or with a crash/power loss, and whether the disk was near full. Each of these changes the prior probabilities: a crash on MP4 almost always means missing index; a crash on MKV almost always means a truncated tail; a full disk can mean both plus filesystem damage.

4. The disk itself. If the drive reported errors, disconnected, or is making noise, the file problem may be a symptom of a media problem. In that case, image the drive first (ddrescue on Linux/macOS) and run every repair against the image — repairing on a failing disk can destroy the last good copy.

Only after those four facts are in hand does the symptom selection in the checker become a confirmation step rather than a guess. The tool is designed to be used with as little as the container and the symptom — but evidence-first is how you avoid running a moov rebuild on what is actually a truncated stream, or a remux on what is actually a zero-byte file.

The recoverability matrix — container × symptom at a glance

Odds of full recovery with lossless tools, based on where each container keeps its index and how each failure class damages it:

| Symptom | MP4 / MOV | MKV | FLV / MPEG-TS | |---|---|---|---| | Will not open, plausible size | High — index rebuild from reference | High — remux with error tolerance | High — streams are self-framing | | Plays partially, then stops | Medium — tail may be unrecoverable | High — remux rebuilds cues, tail loss only | High — cut at last good frame | | Plays but desyncs | High — timestamp regeneration | High — timestamp regeneration | Medium — depends on stream damage | | One stream only (audio or video) | Medium — extract survivor, rebuild other | Medium — same approach | Medium — same approach | | 0 bytes / tiny file | None — nothing was written | None — nothing was written | None — nothing was written | | Wrong file size for duration | Medium — check expected-size math first | Medium — same | Medium — same |

Two readings of this table matter most. First: no container recovers a zero-byte file — when nothing reached the disk, no software anywhere can help, and any tool claiming otherwise is selling hope. Second: MP4 and MKV trade places depending on the symptom. MP4 is worst when the tail is damaged (the single end-of-file index is exactly where the damage is) but excellent when the index alone is missing; MKV is the opposite. That is not a contradiction — it is the direct consequence of where each format stores its bookkeeping.

What recovery actually reconstructs, byte by byte

Understanding what each repair rebuilds makes the verdicts less mysterious and prevents misapplied fixes.

An index rebuild (missing MP4 moov). The media bytes are intact and in order; what is reconstructed is a table of offsets, sizes, and timestamps — one entry per sample — plus the track headers describing codec, resolution, and time base. The reference file supplies the codec parameters (SPS/PPS for H.264, decoder config for AAC) that cannot be reliably inferred from raw stream bytes alone. This is why the reference must match settings exactly: a 30 FPS reference against 60 FPS footage assigns every timestamp wrongly, producing a file that "recovers" into fast-forward garbage.

A remux with error tolerance (damaged MKV or truncated tail). Nothing is reconstructed so much as re-walked: the tool reads every intact cluster, copies its media bytes verbatim, rebuilds the seek index from what it found, and stops cleanly at the first unreadable structure. The -err_detect ignore_err family of flags tells the demuxer to treat a damaged structure as an end-of-data signal rather than aborting. Output is bit-identical media with a fresh, honest index — and a duration that reflects reality.

Timestamp regeneration (desync, stutter). The media is fine; the presentation timestamps are missing, duplicated, or non-monotonic. Regenerating them (+genpts) assigns a fresh, monotonic timeline based on frame counts and frame rates. The risk is a wrong frame-rate assumption producing drift — which is why a known-good frame rate from the original settings improves the result.

Stream extraction (one dead stream). The surviving stream is copied out into its own file (audio.m4a or video.h264), preserving it independently of the damaged container. This is both a salvage move — the audio of a three-hour lecture is worth saving even if the video is gone — and a setup move, because a separately preserved stream can be remuxed back later against a repaired or re-recorded counterpart.

What none of these do is invent data. Frames that were never flushed from the write buffer are gone from every recovery path; the honest ceiling for any crash is "everything up to the last flushed byte."

Prevention — making the checker a rarity in your workflow

Every hour spent on recovery is an hour the container choice could have saved. The durable fixes, in order of leverage:

1. Record MKV or fragmented MP4. This single dropdown moves crashes from "forensic project" to "one-line remux." Remux to MP4 after the session for compatibility: ffmpeg -i in.mkv -c copy -movflags faststart out.mp4 — lossless, seconds, and the fragile format only ever holds a finished file.
2. Keep a reference file per preset. Ten seconds recorded on each OBS profile, stored in a known folder. If the worst happens to an MP4, the index rebuild becomes a five-minute task instead of an hour of reconstructing settings from memory.
3. Record to internal or dedicated storage, never to network shares or removable media. A NAS hiccup or a bumped USB cable mid-session produces exactly the zero-byte and truncated classes above. Local APFS/NTFS with real free space is the boring, correct answer.
4. Leave the drive at least 10–15 percent empty. Filesystems and encoders both degrade near full, and a disk-full crash is the one failure that can damage the filesystem itself, not just the current file.
5. Verify off-disk copies before deleting. Size match first, checksum when the footage matters. A recording is not safe because it was uploaded; it is safe because the upload was verified.