My MP4 or MOV video became corrupted after an interrupted file transfer and now won’t open or play. I need help repairing the damaged video without losing the original quality or footage.
Repeated repair attempts can make things worse if the tool overwrites the damaged file, so keep the original untouched and work only on copies. Since the transfer was interrupted, first check the source device and try copying the video again with a different cable, card reader, or drive. The original recording may still be fine.
If the file has a normal size but won’t open, the MP4/MOV container metadata may be damaged. Try remuxing it with FFmpeg:
ffmpeg -i damaged.mp4 -c copy repaired.mp4
This does not re-encode the video, so there is no quality loss. If FFmpeg reports a missing “moov atom” or cannot detect any streams, a simple remux probably won’t work. You may need a repair tool that uses a healthy sample recorded by the same camera, resolution, frame rate, and codec to reconstruct the missing header.
If the file is zero bytes, much smaller than expected, or contains unreadable sections, no repair program can recreate footage that was never transferred or stored. In that case, recovery from the original SD card, phone, camera, or source drive is more promising. Stop writing new data to that device until recovery is finished.
Check whether the file plays directly from the original device before repairing it. If it does, the video itself is fine and the failed transfer is the problem, so recopying it is safer than modifying the damaged copy.
Do not run repair tools on your only copy. Duplicate the damaged file first and keep the original untouched, since some tools rewrite the container and can make recovery harder.
@binarystream3915 is right that a fresh transfer is the safest fix when the source device still has a playable version. If that is no longer possible, check whether the file size looks reasonable. A zero-byte or unusually tiny file usually means the footage was never fully copied, and software cannot recreate missing video data. If the size looks normal, the interruption may have damaged the MP4/MOV container or its index rather than the actual streams.
Try remuxing the duplicate with FFmpeg using stream copy, which avoids re-encoding and preserves the existing quality. If FFmpeg cannot read the file because the header or “moov atom” is missing, you may need a repair tool that uses a healthy reference clip recorded by the same camera, with matching resolution and settings. That reference-file method is often more useful than random conversion apps. Avoid re-encoding until the end because it will not repair missing footage and may reduce quality.
A repaired file that opens can still be silently truncated, so don’t judge success from the first few seconds. Check the reported duration, scrub through the beginning, middle, and final minute, and verify audio sync before deleting anything.
The basic FFmpeg remux above is the right first attempt. If it produces a playable file with a broken seek bar or odd duration, try timestamp regeneration on another copy:
ffmpeg -fflags +genpts -i damaged.mp4 -map 0 -c copy repaired_pts.mp4
That keeps the encoded video and audio unchanged, but it cannot restore missing media data or rebuild a file whose streams are completely undetectable.
For reference-based repair, “same camera” may not be close enough. Record the sample with the same video mode, codec, frame rate, resolution, audio setting, and ideally the same firmware. Start every repair method from a fresh duplicate of the damaged original rather than feeding one repaired output into another, since a partially successful tool may have already discarded packets or metadata.
If the transfer repeatedly stops when the file reaches roughly 4 GB, check the destination drive’s format before doing any “repair.” FAT32 cannot store a single file larger than 4 GB, and no amount of moov-atom wizardry will fix a copy that is simply missing everything after that point. Move it to an exFAT, NTFS, APFS, or another filesystem that supports large files, then copy it again.
More generally, compare the damaged copy’s exact byte size with the file on the camera, phone, or source drive. Matching filenames and a plausible-looking size are not enough. If the source is 11.8 GB and the copy is 7.2 GB, you have a truncated file, not merely a broken index. A repair utility might make the first 7.2 GB playable, but it cannot manufacture the missing end of the recording.
Before remuxing, I would run a quick inspection:
ffprobe -v error -show_format -show_streams damaged.mp4
If that lists recognizable video and audio streams, the FFmpeg commands already posted are reasonable. If it reports no streams or a missing moov atom, reference-based reconstruction may recover the media packets that are actually present. It still will not recover bytes that never arrived.
When the source is available, skip ordinary drag-and-drop for the next attempt. Use a copy method that can resume and report errors, such as Robocopy on Windows or rsync on macOS/Linux, and copy onto a healthy local drive with plenty of free space. Network shares, flaky USB hubs, nearly full disks, and cheap card readers have an impressive talent for turning a simple copy into an afternoon project.
@socket.git makes a good point about checking the whole result. I would compare the recovered duration against the original file’s expected recording time too. A file can open, seek, and look perfect for ten minutes while quietly ending an hour early. That counts as partial recovery, not a repaired original, regardless of how cheerful the repair app’s success message is.
Nobody’s asked whether the file ever finished recording in the first place. A transfer that cut out mid-copy is very different from a camera that died while still filming, since the second case means the moov atom was never written to the source either, and no re-copy will bring it back. Worth confirming that before you burn time chasing the transfer as the only culprit.
Matching file sizes do not prove the copy is intact. Compare a SHA-256 hash of the source and damaged copy. On Windows, use certutil -hashfile video.mp4 SHA256; on macOS/Linux, use shasum -a 256 video.mp4. Different hashes mean the transfer changed or skipped data, so repair is premature. Recopy it first.
If the hashes match and neither version plays, the damage was already present on the source, possibly because recording never finalized as @nanolynx5324 mentioned. At that point, work from a duplicate and try container repair or a matching reference clip.
If the source card gives read errors, disconnects, or copies at wildly changing speeds, stop repeatedly opening the file. Make an image of the card with a recovery tool that can skip bad sectors and retry them later, then recover from that image. Repeated repair attempts on a physically failing card can turn a partly recoverable video into a less recoverable one.