Can I recover an OBS recording after a crash?

Usually, yes, though the precise word is repair, not recovery: the data is already on your disk, written continuously while you recorded. What's missing is the index OBS would have written when you clicked stop. Rebuilding it makes the file playable again, everything except the final seconds still in memory when the crash hit.

Why is my OBS MP4 recording unplayable?

MP4 finalization writes the file's index (the moov atom) when recording stops cleanly. If OBS crashed, the PC lost power, or the process was killed, that step never ran — the file holds hours of real footage with no map to it. Players call it corrupted, but the stream data is intact on disk.

How do I use untrunc to fix an OBS recording?

You need three things: an untrunc build (compile it yourself or find a trustworthy binary), a healthy reference recording made by the same OBS setup with identical settings, and the command line: untrunc reference.mp4 broken.mp4. It works, and it's free; the cost is the setup.

Should I record in MKV or MP4 in OBS?

MKV — or Hybrid MP4 on OBS 30.2+. MKV survives crashes because it doesn't depend on a finalization step, and OBS can auto-remux to MP4 when recording stops, so you still get MP4s for editing. Plain MP4 is the one option where a crash costs the whole file.

Can I remux a corrupted OBS MP4 to fix it?

No. Remuxing (OBS's File → Remux Recordings, or ffmpeg -c copy) repackages a file that can already be read; an unfinalized MP4 has no index, so the remuxer fails just like a player does. That's the kernel of truth in the forum advice. Index reconstruction, rebuilding the missing map from the raw data, is the approach that can save it.

Fix a Corrupted OBS Recording

The short version

An OBS crash usually leaves an MP4 missing only its index — themoov atom OBS writes when you stop cleanly — while the hours of footage you recorded stay intact on disk. Drop the file above and IntactFile reads it locally to diagnose the damage and rebuild the container around the surviving video, entirely in your browser: 0 bytes are uploaded, which you can confirm in your DevTools Network tab. The honest limit: the final few seconds still in the encoder's memory when the crash hit were never written, so no tool can bring them back.

Repair your recording now

Drop the file above for a local diagnosis. It confirms whether this is the classic unfinalized-MP4 case. Two honest notes up front, because OBS files are large: the free tier covers files up to 500 MB, and a long session usually exceeds that, so a single repair with no size cap is €5.90, never charged if it fails. Second, the engine's current state: structural remux repair (damaged but readable files) runs today; full index reconstruction for unfinalized recordings (the deep fix this page is about) is in development.

Why the crash killed the file

While you record, OBS writes your compressed frames to disk continuously; that part never waits. What waits is the index: MP4 finalization writes the moov atom, the table mapping every frame's position and timing, only when recording stops cleanly. A crash, BSOD, power cut, or killed process skips that final write. The result on disk:

Your footage is physically present, gigabytes of it, in a file no player can navigate. The only genuine loss is the last few seconds still in the encoder's memory buffer at the crash; those were never written, and no tool can restore them.

Why the forums say it's unfixable

Search this problem and you'll find OBS forum threads where staff call an unfinalized MP4 "toast." They're not wrong; they're describing remuxing. OBS's remuxer, like ffmpeg's -c copy, repackages files it can read, and a file without an index can't be read. Within that frame, "toast" is accurate.

But remuxing was never the right tool for this failure. Index reconstruction is a different operation: scan the raw data for frame boundaries and write a new index around the surviving footage. It's what untrunc has been doing for years — proof the class of fix exists. Where we stand, honestly: that reconstruction path in our in-browser engine is in development, not shipped; the remux repair for damaged-but-readable files runs today. If you need the fix right now,the moov atom page covers untrunc — free, command-line, needs a healthy reference recording with identical settings, without pretending it's convenient or that we replace it yet.

Prevent it next time

Three settings, in order of preference — any one means never reading this page again:

Record to MKV, auto-remux to MP4. Settings → Output → Recording Format: mkv, then enable "Automatically remux to mp4" (Advanced). MKV survives crashes — everything written to disk stays playable — and you still get MP4s for your editor.
Hybrid MP4 (OBS 30.2+). Choose "Hybrid MP4" as the recording format: it writes recovery metadata as it goes, so a crash leaves a file that can be made playable instead of an indexless brick.
Fragmented MP4 via muxer flags. On older setups, add movflags=frag_keyframe+empty_moov to the custom muxer settings. Fragmented MP4 writes the index in small pieces throughout the file, so a crash costs the current fragment, not the recording. Some editors handle it less gracefully, which is why MKV is listed first.

What this can and can't fix

Repair applies to truncated, unfinalized recordings whose data reached the disk — the standard OBS crash case. Genuinely out of reach, for any tool: the final seconds still in RAM when the crash happened (never written, gone), and recordings whose file size is near zero, meaning the crash hit before OBS wrote anything. One nuance: recordings with wildly variable bitrate can come back with minor audio/video drift, because reconstruction must infer timing the index would have stated exactly. A file roughly the size hours of footage should be is a strong candidate; a 2 KB file is not.

Repair a corrupted OBS recording — the stream data is still there