M2TS to MXF Converter

M2TS to MXF: Camcorder Footage into a Broadcast Wrapper

M2TS and MXF both exist to carry professional-quality video, but they were designed by different worlds for different jobs. M2TS is the Blu-ray and AVCHD stream format — built for playback off a disc or a camcorder card, with the essence laid out for a hardware decoder to consume in order. MXF (SMPTE ST 377-1) is a broadcast interchange and archive wrapper — built to be ingested, catalogued, timecoded and handed between facilities.

Converting one to the other is what you do when camcorder footage has to enter a facility workflow that will not take a consumer stream. The output is an OP1a MXF with all-intra essence, which is exactly what a playout server or an archive expects and is also considerably larger than what you started with. Here is why, and what to check first.

M2TS vs MXF

We verified the source framing on a test file: the first bytes read 0e bf 46 22 47, with the transport sync byte at offset 4 rather than 0 — the BDAV signature that distinguishes .m2ts from a plain .ts. And we verified the output pattern from the wrapper's own metadata, which reports operational pattern 06.0e.2b.34.04.01.01.01.0d.01.02.01.01.01.09.00 and identifies its writer as an OP1a muxer.

One Thing to Check First: 48 kHz Audio

The MXF writer accepts 48 kHz audio and nothing else. At any other sample rate it refuses to write a header — the underlying muxer reports "only 48khz is implemented" — and the job ends with a zero-byte output rather than a partial file. We reproduced this by taking one clip and changing only the audio sample rate: 44 100 Hz produced nothing, 48 000 Hz succeeded.

For genuine AVCHD and Blu-ray material this is a non-issue, because both specifications use 48 kHz throughout. The failure shows up when the M2TS has been through something else on its way to you — consumer editing software, a screen recorder, a re-mux from a web download — and picked up a 44.1 kHz track. If a conversion comes back empty, check the source's audio sample rate before assuming the file is damaged. There is no sample-rate control on this page, so the fix has to happen before upload.

How to Convert M2TS to MXF

1. Upload Your M2TS File: Drag the file onto the page or click "+ Add Files". Camcorders often split a single recording across several M2TS files; each is converted independently, so queue them together to apply the same settings to all.
2. Choose the Video Codec: Open Advanced Options. Video Codec offers MPEG-2, which is preselected, and H.264. MPEG-2 is what traditional broadcast ingest and playout servers expect; H.264 gives a much smaller file for equivalent picture quality and suits a modern NLE. Audio Codec offers only PCM 16-bit Little Endian.
3. Set Quality or Conform the Frame: File Compression opens on Quality Preset ("Very High (Recommended)"). Video resolution can Keep original or conform the frame to a house delivery spec via Preset Resolutions or an exact Width x Height.
4. Trim and Convert: Trim starts at "Unchanged" and can export one Start time / Duration range. Click Convert and download the .mxf. No sign-up, no watermark.

Why the MXF Is Bigger, and by How Much

Three things push the size up at once, and they compound.

All-intra essence. The MXF muxer places strict limits on frame offsets, so the converter writes with a GOP of 1 — every frame complete, none predicted from its neighbours. We counted the frame types in an output and all 125 were I-frames. On our test clip the all-intra file came to 3.55 MB against 2.23 MB for an otherwise identical encode with a 15-frame GOP: about 1.6× larger at the same quantizer. Against AVCHD's long-GOP H.264 the gap is far wider — a 676 KB M2TS came back as a 3.52 MB MXF.

Uncompressed audio. PCM at 48 kHz 16-bit stereo runs at a flat 1 536 kbit/s no matter how quiet the scene is. That is correct for a mezzanine file — broadcast workflows generally refuse a second generation of lossy audio — but it is a lot of bytes for a long recording.

A minimum bitrate floor. MPEG-2 has no CRF mode, so the converter's MPEG-2 path translates quality-style settings into a bitrate, and refuses to go below a floor derived from the frame size. Asking for something very small will not get you under it.

This floor is also why the Constant Quality and Constraint Quality modes appear to do nothing on the default codec: the MPEG-2 path discards both and encodes at the resolution's minimum bitrate instead. If you want a slider that responds, switch the Video Codec to H.264, where Constant Quality reaches the encoder normally.

Frequently Asked Questions

My editor still refuses the file. What is wrong with it?

Most often the operational pattern rather than the file. This converter writes OP1a — one self-contained file with picture and sound interleaved — which is what delivery, interchange, playout servers, Premiere Pro and DaVinci Resolve expect. Avid Media Composer's media database instead wants OP-Atom, where every essence track lives in a separate file: picture in one, each audio channel in its own. A perfectly valid OP1a MXF is rejected by an Avid media import purely on that basis, and there is no setting here that produces OP-Atom. Avid's own transcode-on-import or consolidate step is the route.

Will my 1080i AVCHD footage be deinterlaced?

No. There is no deinterlacing filter anywhere in this pipeline, so 1080 50i or 60i footage keeps its field structure and the comb artefacts on moving edges are re-encoded exactly as recorded. For an ingest or archive master this is arguably correct — you are preserving what the camera captured, and the facility's own workflow decides how to handle fields. For a progressive delivery, deinterlace in your editor after import rather than expecting the wrapper to have done it.

Does wrapping in MXF improve the quality?

No, and it is worth saying plainly because "broadcast format" reads like an upgrade. MXF is a wrapper: it packages compressed picture and sound with timecode and metadata in a structure professional systems can read. The video is re-encoded on the way through — to MPEG-2 or H.264 as you choose — and re-encoding already-compressed AVCHD can preserve or lose detail but never add it. What you gain is acceptance by systems that reject consumer containers, not better pixels.

Should I pick MPEG-2 or H.264?

MPEG-2 if the destination is a traditional broadcast playout or ingest server, which is the environment MXF was built for and where MPEG-2 essence is the long-standing expectation. H.264 if the destination is a modern NLE and you care about file size — it will be dramatically smaller for comparable quality, and it is also the choice that leaves Constant Quality working. If you have a delivery specification, follow it; if you do not, MPEG-2 is the conservative answer at the cost of a much larger file.

Why can I only choose PCM for the audio?

Because uncompressed PCM is the audio essence this wrapper writes, and there is no second option to expose. It is the right call for a mezzanine file — broadcast and archive workflows want audio that has not been through a second lossy encode — but it is why an MXF of a long recording is so large. Your AVCHD source's AC-3 track is decoded and re-written as PCM; there is no way to carry the AC-3 across as-is.

Does the timecode from my camcorder come through?

The wrapper does get a timecode track, but do not assume it continues the camera's reel timecode. In our testing the output's timecode read 00:00:00:00 — a clean zero-based track rather than a preserved one — which is the normal result of a generic transcode, since AVCHD carries its recording timecode in stream-level structures that a wrapper change does not map across. If matching source timecode matters for a conform, read the camera's start time off the original M2TS before converting and set it in your NLE.

What happens to the multi-file split that camcorders produce?

Each M2TS is converted to its own MXF; the converter does not join them. Recorders split at a file-size boundary, so a long take can arrive as three or four files that are meant to play back to back. Join them in your NLE after import, or concatenate the M2TS files locally before uploading — transport streams generally concatenate cleanly, which MXF files do not.

How much bigger should I expect the MXF to be?

Plan for several times the source, and more on quiet footage. In our testing a 676 KB M2TS clip became a 3.52 MB MXF at the default settings — a bit over five times — and that ratio grows on material with little motion, because AVCHD's long-GOP prediction has the easiest job exactly where all-intra encoding has no advantage to take. Trimming to what you actually need, using Trim in Advanced Options, is the most effective way to keep the output manageable.

What happens to my file after the conversion?

It is uploaded over an encrypted connection, converted on our servers, and both the upload and the .mxf output are deleted automatically after a few hours. There is no sign-up, no watermark, and files are never shared or made public. The footage on your own machine is untouched. Because MXF output is several times larger than the source, the practical limit on a long recording is upload and download time over your connection rather than anything about the conversion itself. If you only need a viewable copy rather than a broadcast master, M2TS to MP4 is far smaller and far quicker to move around.