MJPEG to MXF Converter

MJPEG to MXF: Putting a Camera Capture Into a Broadcast Wrapper

An .mjpeg file sits at one extreme of the video world: a bare run of JPEG frames with nothing wrapping them, written by IP cameras, capture cards and machine-vision rigs because a dropped frame costs exactly one frame. MXF sits at the other: SMPTE's Material Exchange Format, the professional interchange wrapper that broadcast ingest, playout servers and NLE bins expect, carrying structural metadata a raw frame stream has no concept of.

Going from one to the other is almost always about admission rather than quality. A facility's ingest watch folder accepts .mxf and refuses everything else; an archive policy names MXF as the deliverable; an edit system will import the material but not the raw stream. This page re-encodes the JPEG frames into an essence MXF can carry and writes the wrapper around them.

How to Convert MJPEG to MXF

1. Upload Your MJPEG File: Drag the .mjpeg onto the page or click "+ Add Files" to browse. Several captures can be queued and they all convert with the same settings.
2. Pick Video Codec — MPEG-2 or H.264: The list has exactly two entries because those are the only essences this wrapper is built to write, and it opens on MPEG-2, the codec traditional broadcast MXF delivery is built around. Switch to H.264 only if the receiving system accepts AVC-in-MXF.
3. Choose a File Compression Mode That Your Codec Actually Honours: On MPEG-2 the useful modes are Constant Bitrate, Variable Bitrate and Specific file size — the quality-shaped modes do not survive on that encoder, for the reason set out below. On H.264 all of them work, with Constant Quality running the familiar 16-51 CRF scale.
4. Set Video resolution and Convert: Video resolution opens on Keep original; Resolution Percentage, Preset Resolutions, Width, Height and Width x Height are available. Click Convert and save the .mxf. Files upload over an encrypted connection, are re-encoded on our servers and are deleted automatically after a few hours — no sign-up, no watermark.

Why the MXF Comes Out Bigger Than You Expected

The MXF muxer places a hard constraint on GOP structure: the frame offsets it can record must fall within a narrow range, and a long GOP with B-frames blows past it. Our video processor therefore pins GOP=1 on every MXF output, which means every frame is coded as an I-frame with no inter-frame prediction at all.

We measured what that costs. Encoding the same 100-frame capture to H.264 at a fixed quality, the all-intra MXF came to 1,691,193 bytes against 934,969 bytes for the same encode with a normal GOP — a little over 1.8 times the size for the same picture. Frame-type counts confirm the mechanism: 100 I-frames out of 100 with GOP=1, against 9 with the encoder's default.

There is a silver lining specific to this source. MJPEG is already intra-only — every frame in your capture is a complete JPEG — so an all-intra MXF is not throwing away compression your source was benefiting from. Both ends of this conversion are keyframe-only formats, which makes the pairing a more natural fit than it looks.

MJPEG Source and MXF Output Side by Side

The Rate Control Surface Depends Entirely on Which Codec You Pick

Both codecs show the same six File Compression modes, but they behave very differently once the job runs.

That minimum-bitrate substitution is not a small number. A 2 Mbit/s floor applies below about two-thirds of a megapixel, and above that the formula scales with the pixel count — a 1080p frame resolves to roughly 7.5 Mbit/s. If you pick a quality mode on MPEG-2 you will get a file sized by that formula rather than by your input.

The honest recommendation: on MPEG-2, name a bitrate or a byte budget. On H.264, the quality modes work normally and are the easier way to get a consistent-looking result across a batch of captures.

Frequently Asked Questions

Why is MPEG-2 the default rather than H.264?

Because MXF's install base is broadcast, and broadcast MXF delivery grew up around MPEG-2 essence — the D-10/IMX and Long-GOP profiles that ingest and playout chains were built to read. An MXF holding H.264 is entirely legal and modern systems handle it, but a decade-old playout server may not, and the cost of guessing wrong is a rejected deliverable. Check your facility's delivery spec; when there is no spec to check, MPEG-2 is the safer file to hand over.

Will the MXF have an audio track?

No. A raw .mjpeg has no container and therefore no audio stream — cameras and capture cards that write MJPEG either record no sound or save it as a separate file beside the video. The Audio Codec control still renders because MXF genuinely carries audio, and it offers exactly one entry, PCM 16-bit Little Endian, which is what professional wrappers expect. With nothing in the input to encode, the output is a lone video track. If a playout spec demands an embedded channel, lay the clip on a timeline in your NLE and add a silent PCM track before delivery.

What frame rate will the MXF declare?

Twenty-five, unless the capture happened to be recorded at that rate anyway. This is the raw MJPEG problem carried forward: the source stores no rate, the demuxer assumes 25 fps, and the wrapper records the rate it was handed. A 30 fps camera capture therefore arrives in the MXF running about 20% slow, and a 15 fps one runs fast. There is no frame-rate control on this page to correct it. Declare the true input rate in a tool that lets you do so, write that to a container, and convert the corrected file.

Is this an OP-1a file or Avid's OP-Atom?

It is a single-file interchange wrapper in the OP-1a shape — video in one .mxf — which is what most ingest and playout servers expect and what Premiere Pro and DaVinci Resolve read directly. Avid Media Composer supports OP-1a as well as its own per-track OP-Atom layout, where each essence track lives as a separate file inside the Avid MediaFiles folder. If your facility specifically requires OP-Atom media, bring this file in through Avid's import or transcode rather than dropping it into MediaFiles and expecting it to appear.

My capture is 4K. Which codec should I use?

H.264, and check your delivery spec first. MPEG-2 is capped at 4096 pixels per side in our encoder and its efficiency at UHD frame sizes is poor enough that an all-intra 4K MPEG-2 MXF becomes very large very quickly. H.264 handles the frame size comfortably and the all-intra constraint costs it much less. If the destination refuses AVC-in-MXF and the material really must be MPEG-2, drop the frame size with Video resolution before you convert rather than after.

Can I trim a section out of the capture before converting?

Only from the start. The Trim group renders and takes a Start time and a Duration, and a Duration on its own works normally. A Start time above zero does not, because the seek happens on the input side and a container-less .mjpeg carries no timestamps to seek against — the result is an empty file. To take a section from the middle, put the capture into a container first with MJPEG to MP4, cut it in the video cutter, then convert the cut.

Will timecode, reel names or camera metadata appear in the MXF?

No. Those fields are what MXF is famous for, but they have to come from somewhere, and a raw JPEG frame stream carries no metadata layer at all — no timecode, no reel or tape name, no essence descriptors, no captions. The wrapper is written with the structural information the encode itself produces and nothing more. If a downstream system keys on start timecode, set it in your NLE after import.

Why does the picture look softer than my capture did?

Because this is a lossy-to-lossy re-encode and MJPEG frames are unusually expensive to reproduce. Each frame is a complete JPEG with its own quantisation noise, and asking MPEG-2 or H.264 to reproduce that noise faithfully costs a lot of bits — which is exactly what a bitrate-shaped preset will not give it. Raise the target: on MPEG-2 set Constant Bitrate well above the 3.4 Mbit/s the preset assumes, and on H.264 use Constant Quality at a low CRF. Leaving Video resolution on Keep original also matters, since a rescale adds a second softening pass.

What happens to my files after the conversion, and is there a size limit?

Your capture is uploaded over an encrypted connection, re-encoded on our servers, and both the upload and the finished .mxf are deleted automatically after a few hours. Nothing is shared or made public, there is no watermark and no account is required. There is no fixed per-file cap — the limit you will feel is upload size and connection speed, and raw MJPEG is bulky, so a long capture takes a while to send before any encoding begins. If a consumer-friendly file would do instead, MJPEG to MP4 is dramatically smaller than an all-intra MXF.