Your video was recording fine, then something went wrong. Now you've got a file that stutters, freezes, or throws up visual garbage at the same point every single time you play it. That's a corrupt MJPEG frame, and yes, it's fixable in most cases. This guide goes from the quick five-minute checks right through to byte-level hex inspection, so you can find exactly where the damage is and salvage as much footage as possible.

TL;DR

A corrupt MJPEG frame is usually caused by an interrupted recording or transfer. Start by testing in VLC vs Windows Media Player to rule out codec issues. If the problem is real, use FFmpeg to log decode errors and a hex editor to find missing or broken SOI (FF D8) and EOI (FF D9) markers. Trim the corrupt section and re-encode the rest.

⏱️ 13 min read ✅ 50-70% success rate 📅 Updated August 2026

Key Takeaways

A corrupt MJPEG frame has broken or missing SOI (FF D8) and EOI (FF D9) byte markers.
If corruption only shows in one player, it's a codec problem, not actual file damage.
FFmpeg can log the exact frame timestamps where decoding fails.
MJPEG frames are independent, so you can trim a corrupt frame without affecting the rest of the file.
AVI MJPEG files sometimes fail because of missing Huffman tables (DHT), not corrupt frame data.
Dedicated data recovery software can automate much of this process if manual methods feel out of reach.

At a Glance

Difficulty: Advanced
Time Required: 15 to 45 mins
Success Rate: 50 to 70% depending on extent of damage

What Actually Causes a Corrupt MJPEG Frame?

MJPEG (Motion JPEG) is exactly what it sounds like: a video format where every single frame is a full, self-contained JPEG image. That's useful because one bad frame doesn't cascade into the next, unlike H.264 where inter-frame dependencies mean one corrupt packet can ruin seconds of footage. But it also means that when something goes wrong during recording or transfer, the damage shows up as one or more visually broken frames at a specific point in the file.

The most common cause, by a long way, is an interrupted write. Power cuts out mid-recording, the capture app crashes, someone yanks the USB cable, the SD card fills up and the writer doesn't close the file cleanly. Any of those can leave you with a file where the last few frames are truncated or the container index is broken. The file exists, it opens, but at some point playback just falls apart.

Beyond that, there are a few other culprits worth knowing about. Faulty storage media is a big one. SD cards in particular degrade over time, and a sector error on the card can corrupt the bytes that make up a JPEG frame mid-write. You won't necessarily see any warning before it happens. File system errors from an incomplete download or a dodgy network transfer can do the same thing.

Then there's a subtler problem specific to AVI MJPEG containers. Some cameras and capture devices store the Huffman table (DHT) for JPEG decoding once in the container header rather than embedding it in every frame. If the decoder on your Windows machine doesn't know to look for it there, every frame looks corrupt even though the data is fine. According to Microsoft's DirectShow documentation on the MJPEG Decompressor filter, this is a known quirk of the AVI MJPEG format and affects compatibility between different decoders.

Finally, sometimes it's not the file at all. The wrong codec installed on Windows, or a player that doesn't properly support the specific MJPEG variant from your camera, can make a perfectly good file look broken. That's why the first step is always to test across multiple players before you start digging into the file itself.

Corrupt MJPEG Frame: Quick Fix

Before you do anything complicated, run through these checks. In a decent chunk of cases, the problem is a codec or transfer issue rather than actual frame damage, and these steps will sort it in under ten minutes.

Cross-Player Test and Re-Copy Easy

Test in VLC and Windows Media Player
Open your MJPEG file in VLC first. Scrub through the timeline to the point where you know the problem is. Note the exact timecode. Then open the same file in Windows Media Player and go to the same point. If the corruption only appears in one player, you don't have a corrupt MJPEG frame in the file itself. You have a codec issue on Windows. VLC uses its own internal MJPEG decoder which is much more tolerant of minor frame issues, while Windows Media Player relies on DirectShow decoders that can be stricter or simply missing.
Re-copy from the original source
If you copied the file from an SD card or external drive, copy it again. Don't drag and drop; use a proper file copy that verifies completion. On Windows, you can use robocopy from the command prompt: robocopy D:\DCIM C:\Videos\Recovery /E /LOG:copy_log.txt. This logs the transfer and flags any errors. If the fresh copy plays cleanly, the original copy was corrupted during transfer, not at the source.
Run a VLC re-wrap pass
Open VLC. Go to Media > Convert/Save. Add your MJPEG file. Click Convert/Save at the bottom. Choose a profile (MP4 is fine) and under Video Codec, tick 'Keep original video track' so it doesn't re-encode. Set an output path and click Start. Test the resulting file at the same timecode. This fixes container-level index corruption without touching the actual frame data.

If corruption disappears after re-copy or re-wrap, you're done. The frame data was fine all along.

A corrupt MJPEG frame that only shows in Windows Media Player but not VLC almost always points to a missing or mismatched codec on your system rather than damaged file data. Check your installed codecs before going further.

If the same corruption appears in every player and survives a fresh re-copy, the frame data itself is damaged and you'll need to go deeper. Dedicated data recovery software can automate the frame scanning process and is worth considering if you're not comfortable with command-line tools. The manual methods below give you full control, but they take time.

Advanced Corrupt MJPEG Frame Fixes

This is where you get into the actual byte structure of the file. You'll need FFmpeg (free, command-line) and a hex editor. Both are available for Windows. FFmpeg can be downloaded from the official FFmpeg documentation site and added to your system PATH. For the hex editor, any free Windows hex editor will do the job.

FFmpeg Error Logging to Pinpoint Corrupt Frames Advanced

Extract the raw MJPEG stream from the container
If your file is an AVI, the MJPEG video stream is wrapped in the container. Extract it first so you're working with raw frame data:
ffmpeg -i input.avi -map 0:v:0 -c copy output.mjpeg
This copies the video track only, no re-encoding, into a raw MJPEG stream file. If your file is already a raw .mjpeg file, skip this step.
Run FFmpeg with error verbosity
Now tell FFmpeg to decode every frame and report any it can't handle:
ffmpeg -v error -i output.mjpeg -f null -
Watch the console output. FFmpeg will print error messages for each frame it cannot decode properly, including the timestamp or frame index. Those timestamps are your corrupt MJPEG frame locations. Write them down.
Verify the frame count and timestamps
Cross-reference the reported timestamps with what you saw during frame-by-frame inspection in your editor. If they match, you've confirmed the exact corrupt frames. If FFmpeg reports no errors but you still see corruption in players, the issue is likely a missing DHT (see Step 4 below).

FFmpeg error output gives you exact frame-level timestamps for every corrupt MJPEG frame in the file, which is far faster than manual frame stepping for long recordings.

Hex Editor Inspection for Bad SOI and EOI Markers Advanced

Open the raw MJPEG in a hex editor
Open your output.mjpeg file in a Windows hex editor. You're looking at the raw bytes of the file. Each MJPEG frame must start with the SOI marker FF D8 and end with the EOI marker FF D9. Use the editor's search function to find each occurrence of FF D8 and FF D9 in sequence.
Check for missing EOI markers
If you find an FF D8 (start of frame) followed by another FF D8 before any FF D9 appears, the first frame is truncated. Its EOI is missing. That's a corrupt MJPEG frame. The frame data ends somewhere in the middle and the decoder has no clean termination point.
Check for garbage bytes after EOI
Look at what comes after each FF D9. In a clean file, the next thing should be FF D8 (start of the next frame) or container framing data. If there are random bytes between FF D9 and the next FF D8, those are garbage bytes, possibly from a write error or buffer overflow. You can edit them out in the hex editor, but be careful: only remove bytes you're certain are outside the frame boundaries.
Check for out-of-order markers
An FF D9 appearing before its matching FF D8, or markers in a sequence that doesn't make sense, points to a more severe corruption where the frame structure itself is scrambled. At that point, the frame data is unrecoverable and should be skipped entirely.
Supply missing Huffman tables if needed
If FFmpeg reports no errors but frames still decode badly, and your file is from an AVI MJPEG source, the problem may be a missing DHT. AVI MJPEG containers sometimes store the Huffman table once in the container header rather than in each frame. When you extract the raw stream, that table gets lost. FFmpeg can add it back: use the -huffman optimal flag or use a decoder script that prepends the correct JFIF header and DHT before each frame. This is a known quirk of the AVI MJPEG format.

Once you've identified exactly which frames have broken markers, you know precisely what to trim and what to keep. The rest of the file is clean.

Rebuild and Re-encode the Cleaned File Medium

Re-encode the cleaned stream to a new container
Once you've identified and trimmed the corrupt MJPEG frame regions, re-encode to a clean output. To stay in MJPEG format:
ffmpeg -i cleaned.mjpeg -c:v mjpeg -qscale:v 2 -an repaired.avi
The -qscale:v 2 sets high quality (scale is 2 to 31, lower is better). The -an flag drops audio, which you'd add back separately if needed.
Or convert to H.264 MP4 for better compatibility
If you don't need to stay in MJPEG format, convert to H.264:
ffmpeg -i cleaned.mjpeg -c:v libx264 -crf 18 -preset slow -an repaired.mp4
CRF 18 is visually near-lossless. This output will play on any Windows machine without any special codec installed.
Verify the output
Run the repaired file through the same FFmpeg error check:
ffmpeg -v error -i repaired.mp4 -f null -
No output means no decode errors. Play it in both VLC and Windows Media Player to confirm the corrupt MJPEG frame is gone.

A clean FFmpeg error check and successful playback in both players confirms the repair is complete.

If you're dealing with storage-level damage rather than just file-level corruption, the underlying problem might be a failing drive. Our hard drive health check guide covers how to test your storage media and catch problems before they cause more data loss.

Preventing a Corrupt MJPEG Frame

Most MJPEG corruption is preventable. The number one cause is an interrupted write, so the single most important habit is stopping your recording cleanly before you power off or disconnect anything. Don't pull the SD card while the camera is still writing. Don't force-close your capture application. Give the device a moment to finish closing the file properly. It sounds obvious, but this is behind the majority of corrupt MJPEG frame cases I see.

Beyond that, here are the things worth doing in rough order of importance:

Stop recording cleanly every time. Never pull power or disconnect storage mid-recording.
Check your SD cards and drives regularly. Use your camera's built-in format tool rather than formatting on Windows, and replace cards that are more than a few years old or show any errors during transfer.
Never interrupt a file transfer. If a copy gets interrupted, delete the partial file and start again from scratch. A half-copied MJPEG file is often worse than no file at all because it looks complete but plays back with corruption.
Use the right codec and player. Install the vendor-recommended MJPEG codec for your specific camera or capture device. Generic Windows codecs sometimes mishandle device-specific MJPEG variants.
Keep your capture system stable during recording. Avoid Windows updates, sleep mode, or heavy background tasks while an MJPEG stream is being written. An OS interruption mid-write is just as bad as a power cut.

If you're capturing MJPEG from a network camera or streaming source, also check that your capture hardware correctly signals packet boundaries. Partial frame buffering in custom pipelines is a less common but genuinely tricky cause of corrupt MJPEG frame problems that's hard to diagnose without reviewing the capture code or hardware documentation. Our network camera troubleshooting guide has more on that side of things.

Corrupt MJPEG Frame: Summary

A corrupt MJPEG frame is frustrating but usually fixable, especially when the damage is localised to a small section of the file. Start with the simple checks: test in VLC and Windows Media Player, re-copy from the source, and try a VLC re-wrap pass. Those three steps alone resolve a good portion of cases where the corruption is container-level or codec-related rather than actual frame damage.

When the corrupt MJPEG frame is genuinely in the file data, FFmpeg is your best diagnostic tool. The error verbosity mode gives you exact timestamps for every frame that fails to decode, which saves a lot of time compared to manual frame stepping. From there, hex editor inspection of the SOI and EOI markers tells you exactly what's broken at the byte level, whether it's a missing EOI, garbage bytes after a frame end, or a missing Huffman table causing every frame to fail.

The key advantage of MJPEG over inter-frame formats is that one corrupt MJPEG frame doesn't take down the frames around it. Trim the bad section, re-encode the rest, and in most cases you'll get back a clean, playable file with only a small gap where the damage was. That's a much better outcome than the same corruption in an H.264 file would give you.

corrupt MJPEG frame