Why the crash left you with an unplayable file
An MP4 is two things in one file: the footage, a long block of compressed video and audio, and the index, a small table that tells a player where every frame is and how the audio aligns. While OBS records, it streams the footage to disk continuously. It cannot write the index yet, because the index records final sizes and offsets that aren't known until recording ends. So OBS writes the index last, at the instant you click stop.
A crash never reaches that instant. The process dies with the footage already on disk and the index never written. In MP4 terms the file has its ftyp header and its mdat block of media, and it is missing the moov atom that indexes them, which is why every player refuses it and ffmpeg says moov atom not found. Hours of footage can sit in a file that looks, to any normal player, completely empty. For the full anatomy of that index and why it lives at the end, see the MP4 moov atom explained, and for the exact error and its causes, "moov atom not found".
An OBS crash, drawn: the recording reached the disk, but the index OBS writes at stop was never written.
Is it really toast? Yes and no
Search this problem and you'll find forum thread after forum thread, many with an OBS contributor saying an unfinalized MP4 is essentially toast. They are not wrong, and it is worth understanding exactly what they mean, because it is a precise statement, not a shrug.
What they mean is that you cannot remux the file. Remuxing copies the streams into a clean container, and it is the normal way to salvage a wonky MP4. But remux has to read the existing index to know where the streams are, and an unfinalized file has no index to read. So remux fails on the spot, and every ffmpeg -c copy and faststart trick built on top of remuxing fails with it. Against that definition of "fixing," the file genuinely is toast.
The half they leave out is that remuxing is not the only option. Index reconstruction is a different operation: instead of reading an index that isn't there, it scans the footage directly for frame boundaries and rebuilds the index from what it measures. This is the class of repair that command-line tools like untrunc perform, and it is what recovers a recording the forums wrote off. The footage was never the problem; the missing index was, and an index can be rebuilt.
The reference-recording approach
Rebuilding the index means reconstructing the file's structure from the footage itself, and the most reliable way to do that is with a reference recording: a healthy, normally stopped clip made in OBS with the same settings, the same encoder, resolution, frame rate, and container. That healthy file carries a complete, valid index for exactly the format your broken recording used, which gives the rebuild a template that fits your surviving footage.
Producing one takes under a minute: open OBS with the same profile you were recording under, capture a few seconds, and stop normally so the file finalizes. The rebuild reads that reference to interpret your data, then writes out a playable file over the footage that survived.
Now the honest limits, stated plainly. The last few seconds before the crash were still in memory and never reached disk, so they are gone; the rebuild returns everything up to that point. A recording made with a strongly variable bitrate can come back with minor audio and video drift. The reference has to genuinely match, because a clip made with different settings gives a template that doesn't line up. And if the file reads 0 bytes or is a small fraction of its expected size, there is no footage in it to rebuild, which is a storage or recovery problem rather than a repair one. What a rebuild returns is your real recording, indexed and playable, never invented frames.
Prevent it next time: how OBS is meant to record
This whole failure mode is avoidable, and the OBS project has built the tools to avoid it. Three settings, in order of how much they help:
Record to MKV, then remux to MP4
The long-standing advice, and still the safest: set OBS to record in MKV. MKV is written so a recording stays usable even if OBS stops unexpectedly, because it doesn't hinge on a single index written at the end. When your session ends cleanly, use OBS's built-in remux to convert the MKV to MP4 losslessly, with no re-encoding, in seconds. You can even have OBS remux to MP4 automatically after each recording.
Use Hybrid MP4 on OBS 30.2 and later
If you need MP4 directly, perhaps for an editor that dislikes MKV, turn on Hybrid MP4, added in OBS 30.2. It writes the MP4 in a fragmented, crash-resistant structure, so an interrupted recording stays largely usable instead of being stranded without an index. It is the closest MP4 gets to MKV's safety.
Understand the fragmented-MP4 trick
Hybrid MP4 works because of fragmented MP4, a structure that writes small, self-contained index fragments throughout the file rather than one index at the end. If you are hand-configuring a custom output, the muxer setting is movflags=frag_keyframe+empty_moov, which produces the same crash-resistant behavior. It is the mechanism underneath the friendly toggle.
FAQ
Can I recover an OBS recording after a crash?
Often yes, if OBS was writing MP4 or MOV and the file has a healthy size. OBS writes the footage to disk continuously during recording and writes the index that ties it together only when you press stop. A crash skips that step, so the footage is on disk with no index and won't play. Rebuilding the index makes the recording playable again, minus the last few seconds that were still in memory when OBS died. A 0-byte file is a different problem with no footage to rebuild from.
Why is my OBS MP4 unplayable after OBS crashed?
Because the MP4 was never finalized. The index that a player needs, the moov atom, is written at the moment you stop recording, once the final sizes are known. A crash cuts power to the process before that write happens, so the file holds all of its footage but none of the indexing that points to it. Players and ffmpeg report this as 'moov atom not found'. The footage survived; the map didn't.
Should I record in MKV or MP4 in OBS?
Record in MKV if crash safety matters, which for long sessions it does. MKV is written so that a recording remains usable even if OBS stops unexpectedly, because it doesn't depend on a single index written at the end. When you're done, remux the MKV to MP4 losslessly from inside OBS in seconds, with no re-encoding. If you must record straight to MP4, use the Hybrid MP4 option in OBS 30.2 and later, which keeps a crash-resistant structure.
Can I remux a corrupted OBS MP4 to fix it?
No, and this is the misunderstanding behind most 'it's toast' advice. Remuxing copies the streams into a fresh container, but to do that it first has to read the existing index, and an unfinalized MP4 has no index to read. Remux fails instantly on these files. That is a real limit of remuxing, not proof the footage is gone. Rebuilding the index, a different operation, is what actually recovers an unfinalized recording.
What is Hybrid MP4 in OBS?
Hybrid MP4 is a recording option added in OBS 30.2 that writes the MP4 in a fragmented, crash-resistant way, so a recording interrupted by a crash stays largely usable instead of being stranded without an index. It gives you the convenience of an MP4 that most editors accept directly, with much of the safety that made MKV the standard advice for OBS recording.
The missing index at the heart of this, in full: MP4 anatomy and the moov atom.