MJPEG to Xvid: What the File You Download Actually Is
Motion JPEG stores every frame as an independent JPEG and never compresses across frames, which is why a .mjpeg capture is enormous relative to how much footage it holds. Xvid is the opposite approach: an open-source implementation of MPEG-4 Part 2 Advanced Simple Profile that stores mostly the differences between frames. Converting one to the other is a genuine size win. There is one thing to know before you start, and it is about the filename rather than the picture: Xvid is a codec, not a container, so the .xvid file you download is an AVI wearing an unusual extension.
How to Convert MJPEG to Xvid
- Upload Your MJPEG File: Drag the
.mjpegonto the page or click "+ Add Files". Several raw streams can be queued and converted with the same settings. - Check the Video Codec and Audio Codec: Video Codec has a single entry here, Xvid, so there is nothing to decide. Audio Codec opens on MP3 — the classic Xvid-in-AVI pairing — but a raw
.mjpegholds no audio, so on this source the setting has nothing to act on. - Choose a File Compression Mode and Resolution: File Compression opens on Quality Preset at Very High (Recommended), with Specific file size, Constant Bitrate, Variable Bitrate, Constant Quality and Constraint Quality available too. The section below explains which one to reach for on this source. Video resolution opens on Keep original; leave Trim on Unchanged.
- Convert and Download: Click Convert and save the file, then rename it. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.
Rename It to .avi
We inspected the bytes of a finished conversion. The file begins RIFF....AVI and its stream table declares a video stream with the FourCC xvid — in other words, a completely ordinary AVI file containing Xvid-coded video, saved under a .xvid name because that is the extension this page's slug implies. Tools that probe it report the codec as mpeg4, which is correct: Xvid is MPEG-4 Part 2, and the codec tag is what distinguishes an Xvid encode from another MPEG-4 ASP encoder's output.
Nothing is wrong with the file, but very little software recognises .xvid as something it should open. Rename the download to .avi and it plays in VLC, MPC-HC, mpv, older Windows builds with a DivX or Xvid codec pack installed, and the DivX-certified hardware players that Xvid was aimed at. That single step resolves the overwhelming majority of "the file will not open" reports on this conversion.
Choosing a Compression Mode When the Source Has No Bitrate
| Mode | What it does on Xvid | Use it here? |
|---|---|---|
| Quality Preset | Xvid has no CRF scale, so the preset multiplies the source's bitrate — 1.5x at Highest down to 0.3x at Lowest, 1.32x at the Very High default | Only if you accept the assumed baseline described below |
| Specific file size | Targets a byte count you name, with Auto Scale allowed to reduce dimensions if quality alone cannot get there | Good when you have a hard ceiling |
| Constant Bitrate | Holds a rate you set | The most predictable choice on this source |
| Variable Bitrate | A target rate with minimum and maximum bounds you set | Better quality per megabyte when you know your range |
| Constant Quality | Emits a quantiser, on a 1-to-31 scale opening at 5, where lower means better | Works, but the scale is not CRF — do not carry a CRF number across |
| Constraint Quality | The same 1-to-31 quantiser plus a maximum bitrate ceiling | The right pick when you want quality-driven encoding with a rate cap |
The Quality Preset caveat matters on this page specifically. A raw MJPEG stream declares no bitrate at all, so there is nothing for the preset to take a percentage of; our probe substitutes a fixed 2.56 Mbps baseline and the multipliers apply to that. The default Very High preset therefore targets roughly 3.38 Mbps regardless of what your capture actually needed — generous for a low-motion surveillance stream and possibly thin for a busy 1080p one. Constant Bitrate is the more honest control on a raw stream, because you set the number rather than inheriting a placeholder.
For a sense of scale: we converted a five-second 1280 x 720 raw MJPEG stream of 7,288,681 bytes at that default target and got back 2,295,478 bytes — about 31% of the original. Re-running at the Lowest preset's 0.77 Mbps target produced 799,598 bytes, about 11%.
MJPEG and Xvid Compared
| MJPEG (source) | Xvid (output) | |
|---|---|---|
| Standard | Each frame is a baseline JPEG (ISO/IEC 10918-1) | MPEG-4 Part 2 Advanced Simple Profile (ISO/IEC 14496-2) |
| Origin | A convention rather than a single standard, used by capture hardware since the 1990s | Community project begun in 2001 as a fork of OpenDivX; final build 1.3.7, 28 December 2019 |
| Interframe compression | None — every frame is whole and independent | Yes, with I, P and B frames |
| Typical size for the same footage | Several times larger | Roughly a third or less, depending on the rate you set |
| Every frame independently decodable | Yes | Only keyframes |
| Container written here | None — a bare stream | AVI, under a .xvid filename |
| Best for | Capture, frame-accurate inspection, machine vision | Storage, playback on legacy hardware |
If your reason for leaving MJPEG is simply that the files are too big and you want something that plays everywhere, MJPEG to MP4 is a better destination than Xvid — H.264 in an MP4 is both smaller and far more widely supported. Xvid earns its place when the target is specifically an older DivX-certified player, a car head unit, or a set-top box from that era.
Frequently Asked Questions
Why will nothing open my .xvid file?
Because the extension is unusual, not because the file is broken. Xvid is a codec rather than a container, so the file we produce is an AVI holding Xvid video — we checked the header and it starts with the standard RIFF / AVI signature and declares the xvid FourCC. Rename it from .xvid to .avi and the usual players will open it immediately. No re-encoding or repair is needed; the bytes are already correct.
Why is the Audio Codec dropdown offering options when there is no sound?
Because the control is shared across every video target on the site, and it renders before your file has been examined. A raw .mjpeg is a run of JPEG images with no container able to hold an audio track, so there is no source audio to encode and none is created in the output. If you have audio in a separate file, it has to be combined with the video before conversion — this page cannot pick it up.
How much smaller will my file get?
Substantially, because MJPEG never compresses across frames and Xvid does. In our test a five-second 1280 x 720 raw stream of 7,288,681 bytes came back at 2,295,478 bytes using the default preset's target rate, and at 799,598 bytes when we targeted the Lowest preset's rate instead. Your ratio depends heavily on motion: a mostly static surveillance shot compresses dramatically, while continuous movement compresses far less because there is less similarity between frames to exploit.
Should I use Quality Preset or Constant Bitrate?
Constant Bitrate, on this source. Xvid has no CRF scale, so Quality Preset works by scaling the source's own bitrate — and a raw MJPEG stream declares no bitrate, which means the preset falls back to a fixed 2.56 Mbps assumption and multiplies that. The result is not tied to your footage at all. Constant Bitrate lets you name a rate that actually suits the material, and Constraint Quality is a good middle ground if you would rather drive the quantiser and just cap the peak rate.
Is the "CRF" box on Constant Quality really a CRF value?
No, and this catches people out. Xvid uses a quantiser, not a CRF, and the box on this page runs from 1 to 31 opening at 5 — where a lower number means better quality, the opposite of how a CRF number below 23 works on H.264. A value copied over from an H.264 workflow will produce a wildly wrong result. Treat it as its own scale: 2 to 4 is high quality, around 5 is a sensible default, and above 10 degrades quickly.
Will the clip play at the right speed?
Probably not, and there is nothing on this page to fix it. A raw MJPEG stream stores no frame rate, so a decoder assumes 25 frames per second. Footage captured at 10 fps therefore plays two and a half times too fast and comes out two and a half times shorter. Every frame is present and undamaged — only the assumed spacing is wrong. If exact timing matters, export from your capture software to a container that records a frame rate.
Can I trim the clip while converting?
Only from the start. The Trim control seeks into the input, and the demuxer that reads a raw JPEG stream cannot seek — a non-zero Start time produces a file with no frames in it. Leave Trim on Unchanged, convert the whole stream, then cut the result with Video Cutter, which handles the finished AVI properly.
Is Xvid still worth using in 2026?
Only for compatibility. The project's final build, Xvid 1.3.7, was released on 28 December 2019, and MPEG-4 Part 2 was superseded by H.264 for practical purposes many years before that — H.264 delivers noticeably better quality at the same bitrate and plays on essentially everything. Convert to Xvid when a specific piece of older hardware demands it. For anything else, MJPEG to MP4 is the better conversion.
What happens to my file after the conversion?
It is uploaded over an encrypted connection, decoded and re-encoded on our servers, and both the upload and the finished file are deleted automatically after a few hours. Files are never shared or made public, there is no sign-up and no watermark, and your original .mjpeg is left untouched — the Xvid encode is written as a new file for you to download.