Reset to defaults
Need help?RM to RM: Why Re-encode a RealMedia File Into Another RealMedia File?
Converting .rm to .rm is not a rename and it is not a passthrough — the server decodes the RealVideo stream and encodes a brand new one, so this only makes sense when you want to change what is inside the container while keeping the .rm wrapper that some archival index, playlist, or ancient player insists on. The four honest reasons are: normalising a mixed library onto one codec and bitrate, shrinking a file that is too big, cutting a long recording down to one section, and swapping an audio codec that the receiving decoder cannot handle. If your actual goal is a file that plays today, stop here and use RM to MP4 instead — RealVideo has no browser support and no hardware decoders.
Because there is no stream-copy path, every run through this page costs a generation of quality. Plan for that: pick the settings you want once and convert from the best source you have, rather than re-running the same file repeatedly.
How to Convert RM to RM
- Upload Your RM File: Drag the
.rmonto the page or click "Add Files". Several RealMedia clips can be queued, and they all share one set of settings — useful when the point is to normalise a folder of mismatched captures. - Pick Video Codec and Audio Codec: Video Codec offers exactly two entries, RealVideo 1.0 (RV10) and RealVideo 2.0 (RV20). Audio Codec offers AAC, AC3 and RealAudio 1.0; set it deliberately rather than accepting whatever is showing, for the reason in the audio section below.
- Choose a File Compression mode and Video resolution: File Compression lists Quality Preset, Specific file size, Constant Bitrate, Constant Quality and Constraint Quality. Video resolution opens on Keep original, with Resolution Percentage, Preset Resolutions, Width, Height and Width x Height as the alternatives. Trim can be switched from Unchanged to Time Range with a Start time and a Duration.
- Convert and Download: Click Convert and save the new
.rm. Files are uploaded over an encrypted connection, processed on our servers and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.
The Two RealVideo Encoders Are Narrow, and That Shapes Everything
RealVideo 1.0 and 2.0 are early H.263-derived codecs from the late 1990s, and the encoder enforces limits that modern codecs simply do not have. Three of them decide what this page can produce.
| Constraint | What it means for your output |
|---|---|
| Frame dimensions must be a multiple of 16 | The encoder rejects anything else outright, so the pipeline rounds width and height down to the nearest multiple of 16 before encoding. A 350 x 290 source becomes 336 x 288. |
| Maximum frame size 640 x 480 | Each dimension is clamped independently before encoding, whatever Video resolution says — so a 1280 x 720 frame becomes 640 x 480 and loses its 16:9 shape in the process. RealVideo was never a high-definition format. |
| RM packets cannot exceed 64 KB | The muxer refuses a frame that does not fit, so the encoder's bitrate is capped from the frame rate. At 25 fps that ceiling works out near 4.4 Mbps and at 30 fps near 5.2 Mbps; asking for more silently gets you the cap. |
That last one is the reason a high bitrate does not buy you a better-looking .rm. Once you are at the packet ceiling, extra bitrate has nowhere to go, and the only remaining levers are resolution and duration.
Which File Compression Mode Actually Does Something
RealVideo does not support CRF, so the mode names on this page do not all mean what they mean on an H.264 page.
| Mode | Behaviour on an RM output |
|---|---|
| Quality Preset | Scales the source clip's own bitrate up or down. Works, and is the simplest choice. |
| Specific file size | Computes a bitrate from your byte target and the clip duration. Works, subject to the packet ceiling above. |
| Constant Bitrate | Sets a flat bitrate. Works, subject to the packet ceiling. |
| Constant Quality | Labelled "CRF" but the input range is 1–31 — this is an MPEG quantiser scale where 1 is best quality and 31 is worst, the opposite direction from a CRF number's usual feel. It does take effect. |
| Constraint Quality | The quantiser part applies, but the Max bitrate box is discarded: RV10 and RV20 accept only simple bitrate or quantiser control, so the pipeline strips the rate-control ceiling before encoding. Use Constant Bitrate if you need a real cap. |
There is no Variable Bitrate entry on this page, and that is correct rather than an omission — neither RealVideo encoder supports it.
The Audio Codec Choice Is the One That Bites
Audio Codec offers AAC, AC3 and RealAudio 1.0, and which one is showing when the page loads is genuinely ambiguous — two different configuration rules both claim the RealMedia target, so treat the audio codec as unset and choose it yourself.
That matters because RealAudio 1.0 is fixed at 8 kHz mono. It is the codec RealNetworks shipped for dial-up voice, and it does exactly that: an encode through it lands at an 8 kHz sample rate with a single channel, no matter what the source carried. Music turns to mush. Pick it only when you are feeding something that genuinely will not decode anything else. AAC is the sane default for a file you still want to listen to; AC3 is worth choosing when the destination is an AV receiver or a set-top box that passes Dolby Digital straight through.
Frequently Asked Questions
Can I re-wrap an RM without re-encoding it?
No. There is no stream-copy path on this page — the RealVideo stream is decoded and a new one is encoded every time, so every pass is a fresh generation of lossy compression. If nothing about the codec, bitrate or size needs to change, keep the original file. If you only need a shorter clip, Trim RM is the tool aimed at that job, and Video Cutter accepts .rm directly as well.
Should I choose RealVideo 1.0 or RealVideo 2.0?
RealVideo 2.0 (RV20, the "G2" generation) is the more capable of the two and is the better pick when the player supports it, which anything from RealPlayer G2 onwards does. Choose RealVideo 1.0 only when you are targeting a very old decoder or matching an existing archive that is uniformly RV10. Neither will look good next to H.264 at the same bitrate; both are 1990s designs.
Why did my output come out smaller than 640 x 480 when I asked for more?
Because RealVideo tops out at 640 x 480 in this pipeline, and each dimension is clamped separately rather than being scaled proportionally — so a widescreen frame larger than that comes back squeezed into 4:3. On top of that, width and height are rounded down to a multiple of 16, which the encoder requires: feeding it 350 x 290 makes the encoder refuse the job outright, so the rounding is what keeps the conversion working at all. If your source is bigger than 640 x 480, set Width x Height yourself to something inside that box with the proportions you want.
I raised the bitrate a lot and the file barely changed. What happened?
You hit the RM container's 64 KB per-packet limit. The muxer cannot write a frame larger than that, so the pipeline derives a maximum bitrate from the clip's frame rate — roughly 4.4 Mbps at 25 fps, 5.2 Mbps at 30 fps — and clamps anything above it. Past that point the only ways to improve the picture are a smaller frame size or a less demanding source.
Why does the Max bitrate box under Constraint Quality do nothing?
RealVideo's encoders accept a target bitrate or a quantiser value and nothing else — no VBV buffer model — so the maximum-rate and buffer-size arguments are removed before the encode runs. The quantiser half of Constraint Quality still applies. If you need a hard rate ceiling on an RM output, use Constant Bitrate, which the encoder does honour.
Is the Constant Quality number a CRF like on an MP4 page?
No, and the label is misleading. The box accepts 1 to 31, which is an MPEG quantiser scale: 1 is the highest quality and largest file, 31 is the coarsest. On an H.264 page the same control runs 0–51 and behaves differently. If you are used to setting CRF 23 for MP4, typing 23 here will give you a very poor-looking RealVideo file.
Will the audio survive if my source has a RealAudio track?
Yes, but it is re-encoded into whichever of AAC, AC3 or RealAudio 1.0 you select — there is no way to carry the original audio bytes through untouched. Watch the sample rate: choosing RealAudio 1.0 forces 8 kHz mono, which is fine for speech-only dial-up-era content and destructive for anything else.
My RM is a .ram file or will not decode at all. What now?
A .ram is a plain-text pointer file, not media — it lists URLs for a stream that in most cases no longer exists, so there is nothing to convert. Files with RealNetworks rights management on them cannot be decoded by any general-purpose converter either. And a partially downloaded .rm may decode up to the damaged point and stop there, which shows up as an output that is shorter than the source.
Would I be better off converting to something else entirely?
Almost certainly, unless a specific system demands .rm. RM to MP4 gives you H.264 that plays in every browser, phone and editor; RM to MKV is the better choice if you want to keep multiple audio tracks or subtitles alongside the video. Staying in RealMedia is worth doing only when the container itself is the requirement.
What happens to my file after the conversion finishes?
It is uploaded over an encrypted connection, converted on our servers and deleted automatically after a few hours, along with the output. There is no sign-up, no watermark and nothing is shared or made public. Large RealMedia archives are usually small by modern standards, so upload time is rarely the bottleneck here.