Convert RM to 3G2 — Free Online Tool
Convert legacy RealMedia (.rm) files to 3G2 format using H.264 video encoding and AAC audio — transforming decade-old streaming content into a mobile-compatible container designed for CDMA networks. This tool re-encodes the MJPEG video stream from RM into efficient H.264, dramatically reducing file size while improving compatibility with 3GPP2-compliant devices.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your RM file here
or click to browse
Free — no uploads, no signups. Your files never leave your browser.
Settings
Note: Browser-based encoding uses approximate quality targets. For precise CRF compression, copy the FFmpeg command above and run it on your desktop.
Estimated output:
Conversion Complete!
DownloadHow It Works
RealMedia files typically contain MJPEG-encoded video and AAC or MP3 audio wrapped in RealNetworks' proprietary container. Because MJPEG and the 3G2 container's preferred codec (H.264/libx264) are fundamentally different compression formats, the video must be fully re-encoded — not just remuxed. Each MJPEG frame (which is essentially a standalone JPEG image) is decoded and then re-encoded using H.264's interframe compression, which references previous and future frames to achieve far smaller file sizes. The AAC audio stream may be passed through with minimal processing if it already conforms to the required profile, but the container itself changes from the proprietary .rm wrapper to the 3GPP2-standardized .3g2 format. The -movflags +faststart flag reorganizes metadata to the beginning of the file, enabling progressive playback on mobile devices even before the full file is downloaded.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary — the underlying engine that powers this browser-based conversion via its WebAssembly (FFmpeg.wasm) build. The same command runs identically on a local desktop FFmpeg installation for files over 1GB. |
-i input.rm
|
Specifies the input RealMedia file. FFmpeg automatically detects the proprietary RealMedia container and identifies the enclosed MJPEG video and AAC/MP3 audio streams for processing. |
-c:v libx264
|
Instructs FFmpeg to re-encode the MJPEG video stream from the RM file using the H.264 encoder (libx264). This is a full transcode — not a stream copy — because MJPEG and H.264 use entirely different compression methods, and H.264 is the standard video codec expected in 3G2 containers for CDMA mobile devices. |
-c:a aac
|
Encodes the audio stream to AAC (Advanced Audio Coding), which is the standard audio codec for the 3G2 container. If the source RM file already contains AAC audio, FFmpeg may re-encode it to ensure it conforms to the correct AAC profile for 3G2 compatibility. |
-crf 23
|
Sets the Constant Rate Factor for the H.264 encoder to 23, the default quality level. This replaces the per-frame quality model of the source MJPEG (where each frame was encoded independently as a JPEG) with a scene-adaptive bitrate model — lower values produce higher quality and larger files, higher values produce smaller files with more compression artifacts. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second, a standard target for stereo audio in mobile streaming contexts. For the mono or low-bitrate audio typical of legacy RealMedia streaming files, this setting preserves all audible detail while keeping the 3G2 file compact for CDMA network transmission. |
-movflags +faststart
|
Performs a post-encoding step that relocates the 3G2 file's 'moov' metadata atom from the end of the file to the beginning. This is critical for mobile streaming use cases: it allows 3GPP2-compliant devices to begin playing the video immediately upon receiving the first bytes, rather than waiting for the entire file to download. |
output.3g2
|
Specifies the output filename with the .3g2 extension, signaling FFmpeg to wrap the encoded H.264 video and AAC audio in the 3GPP2 container format — the standard multimedia format designed for CDMA mobile networks and devices. |
Common Use Cases
- Archiving RealMedia news broadcasts or documentaries from the early 2000s into a mobile-viewable format that plays on modern 3GPP2-compatible devices
- Transferring old RealMedia video content onto CDMA-based mobile devices that lack a RealPlayer plugin but natively support the 3G2 container
- Reducing the massive per-frame storage overhead of MJPEG-encoded RM files by re-encoding to H.264, which can achieve the same visual quality at a fraction of the bitrate
- Preparing legacy streaming media content for distribution over low-bandwidth CDMA mobile networks where 3G2's low-bitrate optimization is essential
- Converting RealMedia lectures or training videos from corporate or educational archives into a format playable on older CDMA smartphones without additional software
- Recovering and modernizing RealMedia content from CD-ROMs or archived hard drives into a container format with broader long-term codec support
Frequently Asked Questions
Because RealMedia files store video as MJPEG — a format where every frame is a full JPEG image with no interframe compression — the conversion to H.264 requires decoding every single frame individually and then re-encoding them using H.264's motion estimation and temporal compression algorithms. This is a computationally intensive full transcode, unlike container-swap conversions (like MKV to MP4 with H.264 content) where the video stream can simply be copied. The longer processing time reflects genuine encoding work being done, not inefficiency.
Almost certainly yes, and often dramatically so. MJPEG, the video codec used in RealMedia, stores each frame as a complete image without referencing other frames, making it inherently storage-inefficient. H.264 in the output 3G2 file uses interframe compression to encode only the differences between frames, typically achieving 5–10x better compression at equivalent visual quality. A 100MB MJPEG-based RM file might produce a 10–25MB 3G2 file at the default CRF 23 quality setting.
For most RealMedia files, yes — but with some caveats. The 3G2 container does not support subtitles, chapters, or multiple audio tracks, but standard RealMedia files from the streaming era rarely contained these features either. The primary content — video and a single audio track — converts cleanly. However, any RealNetworks-specific metadata, streaming markers, or proprietary synchronization cues embedded in the RM container will be lost, as these are meaningless outside the RealPlayer ecosystem.
Adjust the -crf value in the command. CRF (Constant Rate Factor) controls H.264 quality on a scale where lower numbers mean higher quality and larger files: -crf 0 is lossless, -crf 18 is visually near-lossless, -crf 23 is the default and a good balance, and -crf 51 is the lowest quality. For archiving old RealMedia content you want to preserve faithfully, try -crf 18. For mobile streaming where file size matters more, -crf 28 or -crf 35 will produce significantly smaller files. You can also adjust audio quality by changing -b:a 128k to values like 96k (smaller) or 192k (higher quality).
Yes. On Linux or macOS, you can use a shell loop: for f in *.rm; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k -movflags +faststart "${f%.rm}.3g2"; done. On Windows Command Prompt, use: for %f in (*.rm) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k -movflags +faststart "%~nf.3g2". This web tool processes one file at a time, but the displayed FFmpeg command is designed to be scriptable for bulk processing large archives of legacy RealMedia content on your local machine.
While the 3G2 container technically supports MJPEG, it would be a poor choice for mobile delivery. MJPEG files are dramatically larger than H.264 at equivalent quality, defeating the purpose of the 3G2 format, which was specifically designed for efficient transmission over low-bandwidth CDMA mobile networks. H.264 (libx264) is the native, expected video codec for 3G2 content and is what 3GPP2-compliant devices are optimized to decode. Using libx264 gives you a file that is both smaller and more compatible with the devices and networks the 3G2 format was built for.
Technical Notes
The core technical challenge in this conversion is the MJPEG-to-H.264 transcode. MJPEG, as used in RealMedia containers, treats video as a sequence of independent JPEG frames with intra-only compression — there are no predicted (P) or bidirectional (B) frames. This makes MJPEG robust for editing but wasteful for storage and streaming. H.264's libx264 encoder applies Discrete Cosine Transform (DCT) compression within frames and motion-compensated prediction across frames, yielding vastly superior compression. The default CRF 23 setting is rate-controlled per scene complexity, so fast-motion segments will use more bits automatically. The -movflags +faststart flag is particularly important for 3G2 files intended for mobile streaming: it moves the 'moov' atom (which contains index and metadata) to the front of the file via a post-processing step, allowing a media player to begin rendering the video immediately without buffering the entire file. Note that the 3G2 container imposes practical constraints: it does not support HDR, subtitles, chapters, or multiple audio tracks. Since RM files from the streaming era typically had resolutions of 240p to 480p with mono or stereo audio only, these limitations are rarely a real-world concern. Metadata preservation is minimal — RealNetworks-proprietary tags do not map to standard 3G2/MP4 metadata fields and will be discarded during conversion.