MXF to RM Converter

MXF to RM: What Happens to a Broadcast Master in a RealMedia Container

An MXF is normally the highest-quality copy of a programme anyone holds — a mastered clip out of an ingest, a playout server or an NLE, wrapped in the SMPTE container that professional systems pass around. RealMedia is a proprietary container RealNetworks built for streaming over dial-up and early broadband, and the encoders available for it top out at 640 × 480.

So this is a deliberate downgrade, and the honest way to write this page is to tell you exactly which of the controls change the result, which of them render but are discarded before the encoder ever sees them, and — most importantly — what the geometry rules will do to a 16:9 HD master if you leave the resolution alone. That last one catches nearly everybody, so it comes before the option tables.

How to Convert MXF to RM

1. Upload Your MXF File: Drag the .mxf onto the page or click "Add Files". Several files can be queued and all run with the same settings. Masters are often several gigabytes; if you only need a section, trimming first with the Video Cutter, which accepts .mxf, saves far more time than any encoder setting will.
2. Choose a Video Codec: Video Codec offers RealVideo 1.0 (RV10), which the page opens on, and RealVideo 2.0 (RV20). They are not interchangeable — RealVideo 1.0 carries a hard frame-size ceiling that RealVideo 2.0 does not, described in the next section.
3. Pick an Audio Codec and set Video resolution: Audio Codec lists AAC, AC3 and RealAudio 1.0. Choose one explicitly rather than relying on a preselection, because two competing rules govern what is selected here and neither can be depended on. Video resolution opens on Keep original, with Preset Resolutions, Resolution Percentage, Width, Height and Width x Height alongside — and on a RealVideo target the choice between those changes the shape of your picture, not just its size.
4. Convert and Download: Click Convert and save the .rm. Files are uploaded over an encrypted connection, re-encoded on our servers, and deleted automatically after a few hours — no sign-up, no watermark.

The Geometry Rules Decide Whether Your Output Is the Right Shape

Three rules apply to every RealVideo encode here, and they interact in a way that is easy to get wrong from an HD source.

Both axes are capped at 640 and 480 independently. On Keep original the converter asks for the source's own dimensions and then clips each axis to the ceiling separately, with no aspect-ratio correction. A 1920 × 1080 master therefore comes out 640 × 480 — a 16:9 picture squeezed into a 4:3 frame, with everyone in it visibly narrower. This is the single most common surprise on this conversion, and it is entirely avoidable.

Preset Resolutions behave differently, and better. A preset sets the height only and lets the width follow the source's aspect ratio, so it is not subject to the per-axis clip in the same way. We encoded a 1920 × 1080 source at the 480p preset and the RealVideo stream came out 848 × 480 with the shape intact, muxing into the .rm without complaint. Presets above 480 lines are pulled down to 480 by the height ceiling, so 720p and 1080p both land in the same place. If your master is bigger than the cap — and an MXF master almost always is — choosing a preset is strictly better than leaving Keep original alone.

Dimensions are floored to a multiple of 16. RealVideo codes in 16 × 16 macroblocks, so both axes are rounded down before encoding. We converted a 640 × 360 MXF and the output measured 640 × 352: the eight lines that did not fit a whole macroblock row were dropped. If you enter your own Width x Height, pick multiples of 16 inside the ceiling — 640 × 352 rather than 640 × 360 — and you will get exactly what you asked for.

RealVideo 1.0 has a hard limit RealVideo 2.0 does not. The RV10 encoder refuses any frame of 4,096 macroblocks or more, which is roughly one megapixel. We confirmed both sides of that boundary: at 1024 × 1024 — exactly 4,096 macroblocks — the encoder failed to open at all and no file was written, while RealVideo 2.0 opened the same frame size without objection. Since RealVideo 1.0 is what the page starts on, a large master plus Keep original is the combination to avoid.

Which Compression Controls Actually Do Something

The File Compression panel looks the same as on an H.264 target, but the RealVideo encoders accept far less, and the pipeline strips what they cannot use.

Constraint Quality is the trap on this page. The field accepts a Max bitrate, and the value is discarded: RealVideo 1.0 and 2.0 support a plain target bitrate or a quantiser, not the buffer-based rate control that mode depends on, so the pipeline strips the maxrate and buffer arguments for those two codecs specifically. Use Constant Bitrate or Specific file size if you need a ceiling.

There is also a bitrate ceiling you cannot exceed. The RealMedia muxer has a packet limit of roughly 64 KB per frame, so the pipeline caps the video bitrate at a value derived from that limit and the source frame rate — on the order of 4 to 5 Mbit/s at ordinary frame rates. Asking a 100 Mbit/s mezzanine master to stay at 100 Mbit/s simply gets you the cap.

MXF and RM Side by Side

Common Errors and How to Fix Them

• "My 16:9 master came out squashed into 4:3." The 640 × 480 ceiling was applied per axis on Keep original. Switch Video resolution to Preset Resolutions and choose 480p, which sets the height and lets the width follow the source shape.
• "The conversion failed and gave no obvious reason." Almost certainly the RealVideo 1.0 macroblock limit on a large frame. Switch Video Codec to RealVideo 2.0, or pick a preset at 480p or below.
• "The output is a few lines shorter than I asked for." Expected: both axes are floored to a multiple of 16 for macroblock alignment, which is why our 640 × 360 test came back 640 × 352.
• "I set a Max bitrate under Constraint Quality and nothing changed." That mode is discarded for RealVideo output. Use Constant Bitrate or Specific file size.
• "I asked for a high bitrate and got something much lower." The RealMedia muxer's per-frame packet limit caps the rate. There is no setting that lifts it.
• "The audio is 8 kHz and sounds like a telephone." You chose RealAudio 1.0, which is a narrowband speech codec fixed at 8 kHz mono — we measured it landing there regardless of what the source carried. Pick AAC instead for anything but speech destined for a genuinely old RealPlayer target.
• "There is no audio at all." Check whether the MXF's audio is on a track the decoder read. Masters sometimes carry several mono PCM tracks rather than one stereo pair, and only one stream is taken through.

Frequently Asked Questions

Should I choose RealVideo 1.0 or RealVideo 2.0?

RealVideo 2.0, unless something specific asks for the older stream type. RealVideo 1.0 is what the page opens on and it is fine for small frames, but its encoder refuses anything of 4,096 macroblocks or more — we watched it fail to open at 1024 × 1024, writing no file at all, while RealVideo 2.0 accepted the same frame size. RealVideo 2.0 is also the later and more efficient of the two designs, so at equal bitrate it looks better.

Which audio codec should I pick, and why is nothing preselected reliably?

Pick one deliberately. Two rules in the page configuration both claim the right to set the audio codec on a RealMedia target, and which of them lands depends on the order the page resolves them, so there is no preselection worth building on. AAC is the right answer for anything you will play on a computer and handles music and speech alike; we confirmed all three choices mux into the container. AC3 is worth it only if a receiver wants Dolby Digital. RealAudio 1.0 is 8 kHz mono speech and appropriate only for a period-correct RealPlayer target.

Why is the Constant Quality field labelled CRF when the scale is 1 to 31?

Because that numeric control is shared with the H.264-class codecs, where CRF is the correct name and the range is much wider. RealVideo takes a quantiser instead, on a 1-31 scale where lower is better — the opposite direction from what most people expect from a slider labelled that way. The control does genuinely work, so it is usable if you know what a quantiser is; the label simply belongs to another codec family. Leave the mode on Quality Preset if you are not deliberately setting one.

Will converting my MXF to RM lose quality?

Yes, substantially, and there is no setting that avoids it. An MXF master typically holds MPEG-2 or H.264 at a mezzanine bitrate at HD resolution or larger; RealVideo 1.0 and 2.0 are late-1990s designs capped at 640 × 480. Everything above that frame size is thrown away before encoding even begins, and the codec itself is far weaker than what the master used. The server always re-encodes both streams — there is no path that copies the existing essence through untouched.

What is the difference between RM and RMVB?

The container is identical; the label describes the encoding strategy. RealMedia was designed around constant-bitrate delivery over a connection with known bandwidth, while RMVB was introduced for locally stored files, where a variable bitrate can spend more bits on complex scenes for the same overall size. We checked the bytes: a file written to .rmvb carries exactly the same .RMF header as one written to .rm. If you want the variable-bitrate extension instead, use MXF to RMVB.

Does the timecode, reel name or other MXF metadata survive?

No. MXF wraps a rich descriptive metadata model around its essence — timecode tracks, reel and clip names, and structural information about how the material was assembled. RealMedia has no equivalent structure, and the conversion decodes and re-encodes the picture and sound rather than migrating metadata. Keep the original .mxf if any of that matters; treat the .rm purely as a delivery copy.

My MXF has several separate mono audio tracks — what happens to them?

One audio stream is carried into the output. Broadcast masters frequently hold four, eight or sixteen discrete mono PCM tracks for different languages and mixes, and RealMedia is not the container for that arrangement. If you need a specific pair, remix them in an editor first and export a stereo master, then convert that. Do not assume the pair you wanted is the pair that survived — check the result before you rely on it.

Is RM the right target at all, or should I use something else?

For nearly every purpose, something else. RealMedia is proprietary, has no open specification, no browser support, and no current hardware ecosystem. If a specific player, set-top box or archive names .rm, this is the conversion for you; otherwise MXF to MP4 plays on phones, browsers, televisions, editors and media servers with no codec archaeology, and MXF to MKV is the better choice when you want a flexible open container that can hold several audio tracks at once.

How are my uploads handled and how long are they kept?

Your .mxf is uploaded over an encrypted connection, decoded and re-encoded on our servers, and both the upload and the resulting .rm are deleted automatically after a few hours. Files are never shared or made public, there is no watermark and no account is required. Because masters are large, the real constraint is upload size and time rather than the conversion itself — trimming the section you need beforehand is usually the fastest route to a result.