Initializing... drag & drop files here
Supports: RM
RM is RealNetworks' RealMedia container — a proprietary streaming format from the RealPlayer era that wrapped RealVideo and RealAudio for delivery over dial-up and early broadband. 3GP is the 3GPP file format, an MPEG-4 Part 12 derivative standardised for mobile handsets, and it is the format an older phone, a car head unit or a legacy MMS pipeline will still accept when nothing else works.
The two formats were built for the same constraint — very little bandwidth — which is why this conversion usually lands cleanly: an RM clip is already small and low-resolution, so there is nothing that 3GP has to throw away. What matters on this page is the codec pair you choose, because 3GP accepts four different video codecs here and one of them, H.263, will silently resize your video for you. The sections below say exactly what each choice does.
| Property | RM (RealMedia) | 3GP (3GPP file format) |
|---|---|---|
| Owner / standards body | RealNetworks (proprietary) | 3GPP (open telecom standard) |
| Origin | RealNetworks streaming stack, late 1990s | 3G mobile services, early 2000s |
| Structural basis | RealNetworks' own chunked layout | MPEG-4 Part 12 (ISO base media file format) |
| Video payload | RealVideo RV10, RV20, RV30, RV40 | H.263, MPEG-4 Part 2, H.264/AVC, VP8 |
| Audio payload | RealAudio 14.4/28.8, Cook, SIPR, ATRAC3, later AAC | AMR-NB, AMR-WB, AAC-LC, HE-AAC, MP3 |
| Designed for | Constant-bitrate internet streaming | Cellular delivery to handsets |
| Typical frame size | Low — often 320×240 or smaller | Low — QCIF/CIF-class mobile frames |
| Browser playback | None | Firefox for Android only, per MDN |
| Desktop playback | VLC, MPlayer, old RealPlayer builds | VLC, QuickTime, most desktop players |
| Status | Legacy | Legacy, but still accepted by mobile hardware |
.rm onto the page or click "Add Files" to browse for it. Several clips can be queued and converted with one set of settings..3gp. Files are uploaded over an encrypted connection, processed on our servers and deleted automatically after a few hours. No sign-up, no watermark.| Codec | What you get | Pick it when |
|---|---|---|
| H.264 | Modern AVC video in a 3GP wrapper. Best quality per byte of the four, and the resolution you choose is the resolution you get | Almost always — this is what the page opens on |
| MPEG-4 | MPEG-4 Part 2 Simple/Advanced Simple Profile, the codec most 2000s handsets shipped with | A phone or head unit rejects the H.264 file |
| Xvid | The open-source MPEG-4 Part 2 encoder — same standard as above, different implementation | You are matching an existing Xvid workflow |
| H.263 | The original 3GP video codec, and the only one on this page with a hard-coded list of legal frame sizes | A very old handset or MMS gateway insists on it |
H.263 is the one to be careful with. The codec accepts only five picture sizes — 128×96 (SQCIF), 176×144 (QCIF), 352×288 (CIF), 704×576 (4CIF) and 1408×1152 (16CIF) — and refuses anything else outright. Ask ffmpeg directly for a 320×240 H.263 encode and it stops with "The specified picture size of 320x240 is not valid for the H.263 codec." Our pipeline does not let the job fail: it picks the largest legal size that fits inside your source and scales to that. A 320×240 RM therefore comes out at 176×144, and a 640×480 one at 352×288. Two consequences follow. The snap overrides whatever you selected under Video resolution, and because the legal sizes are 4:3-ish but not exactly your source's shape, the picture can stretch slightly. If you want the frame size you asked for, use H.264, MPEG-4 or Xvid.
Two further notes on the non-H.263 codecs. MPEG-4 rounds each output dimension down to a multiple of 4, while H.264 and Xvid round to an even number, so an odd requested width can shift by a pixel or two. And switching away from H.264 changes what the Constant Quality slider means: on H.264 it is a true CRF value on a 16–51 scale, while MPEG-4, Xvid and H.263 use ffmpeg's 1–31 qscale, where lower is better and the usable band is much narrower. On those three, Constraint Quality — a quality target with a maximum bitrate ceiling — is the more predictable control.
AAC, if you leave the Audio Codec picker alone. The picker lists AAC, AMR Narrow Band and AMR Wide Band, and for a 3GP target our server falls back to AAC when no codec has been explicitly chosen. That is the right default for anything with music in it. AMR is a speech codec — narrowband is fixed at 8 kHz mono, wideband at 16 kHz mono — so pick it only when a handset or voice-messaging system specifically requires AMR, and expect music to sound thin.
You picked H.263. That codec only encodes five fixed picture sizes, so we snap the frame to the largest legal one that fits inside your source before encoding rather than letting the job fail. For a typical 320×240 RealMedia clip the largest legal size that fits is 176×144. The snap happens after your Video resolution selection and replaces it. Switch the Video Codec to H.264, MPEG-4 or Xvid and the resolution you choose is the one you get.
Yes. Your RM file is a real video with a real bitrate, so the preset has something to scale — it moves the target quality up or down relative to the source. That is different from a still-image source, where there is no source bitrate for a preset to work from. On the page's default H.264 codec the preset maps onto the encoder's CRF control; on MPEG-4, Xvid and H.263 it scales the source bitrate instead. Either way, "Very High (Recommended)" is a sensible starting point and is what the dropdown opens on.
Only if something in your chain demands the .3gp extension. Both containers descend from MPEG-4 Part 12 and both can carry H.264, so a 3GP file and an MP4 file built from the same source are close cousins — but MP4 plays natively in every current browser while MDN lists 3GP support as Firefox for Android only. If the destination is a computer, a modern phone or a web page, use RM to MP4 instead.
No. Re-encoding cannot recover detail the source never recorded, and RealMedia clips were compressed hard for narrowband streaming in the first place. The conversion buys you playability on hardware that has never supported RealMedia, not resolution. Raising the Quality Preset limits how much additional loss the second encode adds; it cannot undo the first one.
Yes. Set Trim to Time Range and give a start time and a duration, in plain seconds or in HH:MM:SS.sss, and only that stretch is encoded. Doing the cut here is cheaper than converting the whole file and trimming afterwards. If you would rather work on the source visually first, video-cutter accepts RealMedia files directly.
Yes. RealMedia was a proprietary streaming format tied to RealPlayer, and it never picked up broad third-party support; browsers, phones and smart TVs have no decoder for it. VLC and MPlayer still open most .rm files on the desktop because their decoders were reverse-engineered years ago, which is also why our servers can read your upload. Converting to a standard container is the durable fix.
Often not much, and it can be slightly larger. RealMedia was engineered for tight low-bitrate streaming, so there is not a lot of fat left to remove, and a second lossy encode has to spend bits reproducing the first encoder's artefacts. If you need a specific size, switch File Compression to Specific file size and name it in bytes, kilobytes or megabytes — with Auto Scale on, the resolution drops as needed to hit the target.
Your RM file is uploaded over an encrypted connection, converted on our servers and deleted automatically after a few hours. Files are never shared or made public, there is no sign-up and no watermark. The practical limit on a large upload is transfer time rather than the conversion itself, since RealMedia clips are small by modern standards.