RM to MXF Converter

RM to MXF: Read the Audio Requirement First

MXF is the broadcast industry's wrapper — SMPTE ST 377-1, the container that carries programme masters, advertising deliverables and Digital Cinema assets. RealMedia is a 1997 streaming format from the dial-up era. Bridging the two is a legitimate job when an ingest system will only accept MXF, but this particular pairing has a hard constraint that catches most people, so it belongs at the top rather than buried in an FAQ.

The MXF muxer here writes 48 kHz audio and nothing else. We tested the boundary directly: feeding it audio at 8000, 22050 or 44100 Hz produced only 48khz is implemented and no output file at all, while 48000 Hz wrapped cleanly. RealAudio tracks are very often 8 kHz, 11.025 kHz, 22.05 kHz or 44.1 kHz, and there is no sample-rate control anywhere on this page — so a .rm whose soundtrack is not already 48 kHz will fail rather than convert. If that describes your file, the reliable route is to normalise it in a video editor or with a desktop tool first, then wrap the result.

How to Convert RM to MXF

1. Upload Your RM File: Drag the .rm onto the page or click "+ Add Files". Several clips can be queued and share one set of settings; this page accepts the .rm extension.
2. Confirm Video Codec and Audio Codec: Video Codec opens on MPEG-2, the broadest-compatibility choice for professional MXF ingest, with H.264 as the only alternative. Audio Codec lists PCM 16-bit Little Endian alone, which matches how broadcast and camera MXF carry sound — as linear PCM rather than a compressed codec.
3. Set File Compression, Video resolution and Trim: File Compression opens on Quality Preset at "Very High (Recommended)", with Specific file size, Constant Bitrate, Variable Bitrate, Constant Quality and Constraint Quality also rendering. On MPEG-2 the Constant Quality control is a 1–31 slider rather than the 16–51 CRF scale, and it does not reach the encoder — see the FAQ. Video resolution opens on "Keep original" and Trim on "Unchanged".
4. Convert and Download: Click Convert and save the .mxf. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark.

Why the Output Is So Much Larger Than the Source

Two things make an MXF from a RealMedia clip grow dramatically, and both are deliberate.

The video is written all-intra. The MXF muxer enforces a strict frame-offset range that long-GOP encoding overruns, so the pipeline sets the GOP size to 1 — every frame is a full I-frame, with no predicted frames at all. We isolated the cost by running the same source at the same quantiser and changing only the GOP: at GOP = 1 the file held 250 I-frames and came to 5,946,425 bytes; at the encoder's default GOP it held 21 I-frames plus 229 P-frames and came to 2,759,737 bytes. All-intra is normal for mezzanine and mastering files — it makes every frame independently decodable, which is exactly what an editor wants — but it is roughly twice the size for the same picture.

The audio is uncompressed. Linear 16-bit PCM at 48 kHz stereo is about 11.5 MB per minute on its own, regardless of what the RealAudio track originally cost. RealMedia typically carried heavily compressed, low-rate, often mono audio, so the audio side of the file can grow by two orders of magnitude.

Together those took an 821,853-byte test .rm to a 5,946,425-byte MXF for ten seconds of 640 × 480 footage — roughly a megabyte of that being the PCM audio alone. Your own ratio will depend on how heavily the source was compressed, but growth of several times over is the normal outcome and not a settings error. MXF is a mastering and delivery wrapper, not a distribution format. If size is what you care about, RM to MP4 is the right target instead.

What the Conversion Produces

RM as a Source, and What Does Not Survive

Nothing about wrapping a .rm in MXF improves the picture. RealVideo at streaming bitrates has already discarded a great deal, and re-encoding into MPEG-2 is a second lossy generation on top of that. Leave Video resolution on "Keep original": scaling a 320 × 240 RealVideo clip up to a 1080p preset gives an enormous all-intra file containing exactly the detail the original had.

Frequently Asked Questions

My conversion failed — why?

The most likely cause is the audio sample rate. The MXF audio mapping used here implements 48 kHz only; we confirmed the boundary by testing 8000, 22050, 44100 and 48000 Hz, and only 48000 produced a file — the rest returned only 48khz is implemented and wrote nothing. RealAudio tracks are frequently 8 kHz, 11.025 kHz, 22.05 kHz or 44.1 kHz, and this page has no sample-rate control, so the mismatch cannot be fixed from the interface. Resample the audio to 48 kHz in a video editor or desktop tool first, then wrap that file.

Why is my MXF several times bigger than the RM?

Two independent reasons stack up. The video is encoded all-intra with a GOP of 1, because the MXF muxer's frame-offset limits do not tolerate long-GOP encoding — in a controlled test where only the GOP changed, the all-intra version came to 5,946,425 bytes with 250 I-frames against 2,759,737 bytes with 21 I-frames and 229 P-frames. And the audio is uncompressed PCM, around 11.5 MB per minute for 48 kHz stereo, replacing a RealAudio track that may have cost a hundredth of that. Large mezzanine files are what MXF is for.

Why is the audio uncompressed PCM instead of something smaller?

Because that is how professional MXF carries sound, and PCM 16-bit little-endian is the only entry in the Audio Codec list on this page. Broadcast and camera MXF hold linear PCM rather than a compressed codec so that downstream tools can process the audio without decoding. It also means the audio side of this conversion is gentle: the RealAudio track is decoded once and written out as PCM without a second lossy generation.

Should I choose MPEG-2 or H.264 for the video?

MPEG-2 unless something specific asks for H.264. MPEG-2 is the long-established choice for professional MXF ingest and the widest-compatibility option in broadcast workflows, which is why it is the default here. H.264 in MXF is well defined and produces a considerably smaller file, but not every ingest system accepts it. If a delivery specification exists, follow it; if you are guessing, MPEG-2 is the safer guess.

Why does the Constant Quality slider make no difference?

Because MPEG-2 has no constant-quality mode in this encoder. When you choose Constant Quality or Constraint Quality on an MPEG-2 target, the value you set is discarded and the encoder is instead given a minimum bitrate calculated from the frame size — roughly 0.10 bits per pixel at 30 fps up to 720p, 0.12 at 1080p and 0.15 above, with a 2 Mbit/s floor at any size. The 1–31 control renders and accepts input; it simply does not steer the result. If you have a delivery bitrate to hit, set Constant Bitrate to that number directly. If you have a size budget, use Specific file size. Switching Video Codec to H.264 gives you a Constant Quality mode that genuinely works, at the cost of some ingest compatibility.

Will the MXF carry timecode from the RealMedia file?

No, because RealMedia has no standard timecode track to inherit. The output is stamped with a timecode track starting at 00:00:00:00. If your workflow needs a specific start timecode — a broadcast delivery slate, for example — that has to be set in an editing or mastering application after the wrap, not during it.

Does wrapping in MXF improve the picture at all?

No. The RealVideo inside a .rm was encoded for streaming bandwidth and has already discarded a great deal of detail; re-encoding it into MPEG-2 adds a second lossy generation rather than removing the first. What MXF gives you is a container professional systems will accept, all-intra frames that cut cleanly, and uncompressed audio. Those are workflow properties, not quality improvements. Keep Video resolution on "Keep original" — upscaling a small streaming-era frame produces a very large file with no extra information in it.

Does this deinterlace or correct the pixel aspect ratio?

Neither. There is no deinterlacing anywhere in this pipeline, so any combing in the source is carried through into every I-frame. Pixel aspect handling is narrower than it sounds: leaving Video resolution on "Keep original" preserves the source's own pixel aspect ratio, but any resize flattens it to square pixels. If your source is anamorphic and you need to rescale, use Width x Height and state the true display dimensions rather than using a height preset.

What happens to my uploaded file?

It is uploaded over an encrypted connection, decoded and re-encoded on our servers, and both the upload and the resulting .mxf are deleted automatically after a few hours. Nothing is shared or made public, no watermark is added, and no account is required. MXF output is large by design, so allow time for the download as well as the upload.