Convert MP4 to RM — Free Online Tool
Convert MP4 files to RealMedia (RM) format directly in your browser, re-encoding video with the MJPEG codec and audio with AAC. This tool is primarily useful for legacy compatibility with RealPlayer or archiving content in the classic streaming format that dominated dial-up internet in the late 1990s and early 2000s.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your MP4 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
MP4 files typically store video in H.264 or H.265 and audio in AAC. Since RealMedia's FFmpeg-compatible output path only supports MJPEG for video, the video stream must be fully re-encoded — every frame is converted into an individual JPEG-compressed image sequence, a fundamentally different approach from the motion-compensated compression used by H.264. Audio encoded as AAC in the MP4 can be passed through or re-encoded into AAC for the RM container. The result is a lossy .rm file with significantly larger file sizes than the source MP4 for comparable quality, due to MJPEG's lack of inter-frame compression. Metadata such as chapters, subtitle tracks, and secondary audio tracks present in the MP4 are dropped entirely, as the RM container does not support these features.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg command-line tool. In this browser-based tool, FFmpeg.wasm runs this same command via WebAssembly entirely within your browser — no server receives your file. |
-i input.mp4
|
Specifies the input file, your source MP4. FFmpeg reads the container and identifies the internal streams — typically an H.264 or H.265 video stream and an AAC or MP3 audio stream — which will each be processed separately for the RM output. |
-c:v mjpeg
|
Sets the video codec to Motion JPEG, the only video codec compatible with FFmpeg's RealMedia muxer. This triggers a full re-encode of every video frame from the MP4's source codec (usually H.264) into individual JPEG-compressed images, discarding all inter-frame compression. |
-c:a aac
|
Sets the audio codec to AAC for the RM output. If the source MP4 already contains AAC audio, FFmpeg will still re-encode it at the specified bitrate rather than copy it, since the RM container's stream formatting differs from MP4's. |
-q:v 5
|
Sets the MJPEG video quality on a scale of 1 (best quality, largest file) to 10 (worst quality, smallest file). A value of 5 represents a midpoint balance; unlike the MP4's CRF scale, a lower number here means higher quality, not lower. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second, which is the standard default for acceptable stereo audio quality. You can increase this to 192k or 256k for better audio fidelity, noting that RealMedia's audio quality options cap at 256k. |
output.rm
|
Specifies the output filename with the .rm extension, which signals FFmpeg to use the RealMedia muxer. The .rm extension is the standard container extension for RealMedia video files, as distinct from .ra (RealAudio-only) or .rmvb (RealMedia Variable Bitrate). |
Common Use Cases
- Preparing video content for playback in legacy RealPlayer installations on older Windows or enterprise systems that cannot be updated
- Archiving early-2000s web video projects in their historically authentic RM format for digital preservation purposes
- Testing or demonstrating retro streaming setups that replicate the dial-up era internet experience using RealMedia infrastructure
- Converting training or educational MP4 videos for compatibility with legacy corporate intranet portals that only accept RealMedia files
- Generating MJPEG-encoded video files via the RM wrapper when a downstream workflow specifically requires frame-independent MJPEG encoding
- Recreating period-accurate multimedia exhibits or museum installations that historically used RealPlayer as the designated media player
Frequently Asked Questions
This is expected and is a fundamental consequence of switching from H.264 (used in most MP4 files) to MJPEG (used in RealMedia via this conversion path). H.264 achieves its small file sizes by encoding only the differences between frames, whereas MJPEG compresses each frame independently as a full JPEG image with no reference to surrounding frames. A typical MP4 at CRF 23 might use 1–3 Mbps for standard definition content; MJPEG at quality level 5 can use 5–15 Mbps for the same content. If file size is a concern, raising the -q:v value toward 10 will reduce quality and size.
Modern versions of RealPlayer may struggle with this output because the RM container produced by FFmpeg uses MJPEG video, which differs from RealNetworks' proprietary RealVideo codec that original .rm files used. Authentic RealMedia files from the late 1990s used RealVideo (RV10, RV20, etc.) and RealAudio codecs, which FFmpeg cannot encode. The .rm file generated here uses the RealMedia container wrapper around MJPEG and AAC streams, which some media players handle better than others. VLC is the most reliable player for this output.
No. The RealMedia container format does not support subtitle tracks, chapter markers, or multiple audio tracks. Any of these present in your source MP4 will be silently dropped during conversion. If your MP4 contains burned-in (hardcoded) subtitles as part of the video image itself, those will survive since they are part of the visual frame, but any soft subtitle tracks stored as separate streams will not be included in the output.
Adjust the -q:v value, which controls MJPEG quantization quality. The scale runs from 1 (highest quality, largest file) to 10 (lowest quality, smallest file), with 5 as the default. For example, replace '-q:v 5' with '-q:v 2' for noticeably sharper frames at the cost of a larger file, or '-q:v 8' for a more compressed, artifact-heavy image that is significantly smaller. Unlike the CRF scale used in your source MP4's H.264 encoding, lower numbers mean better quality here.
Yes. On Linux or macOS, you can use a shell loop: 'for f in *.mp4; do ffmpeg -i "$f" -c:v mjpeg -c:a aac -q:v 5 -b:a 128k "${f%.mp4}.rm"; done'. On Windows Command Prompt, use: 'for %f in (*.mp4) do ffmpeg -i "%f" -c:v mjpeg -c:a aac -q:v 5 -b:a 128k "%~nf.rm"'. The in-browser tool processes one file at a time, so the FFmpeg command is particularly valuable for bulk conversions of large libraries.
Yes, and the quality loss is significant. Your source MP4 was already lossy (compressed with H.264 or similar), and re-encoding to MJPEG introduces a second generation of lossy compression. Every pixel in every frame is re-quantized through MJPEG's JPEG compression algorithm, which can introduce visible blocking artifacts, color banding, and softness — especially in areas of fine detail or motion. There is no lossless path from MP4 to RM using this toolchain; MJPEG is inherently lossy and the RM container does not support any lossless video codec.
Technical Notes
RealMedia (.rm) is one of the few container formats still writable by FFmpeg that predates the modern era of video compression. The critical technical constraint is that FFmpeg's RM muxer accepts only MJPEG for video — the native RealVideo codecs (RV10, RV20, RV30, RV40) are decoder-only in FFmpeg and cannot be used for encoding, meaning any MP4-to-RM conversion through FFmpeg necessarily uses Motion JPEG rather than authentic RealVideo. MJPEG treats video as a sequence of individually compressed JPEG frames, making it highly seek-friendly (any frame is a keyframe) but extremely storage-inefficient compared to H.264's temporal compression. The audio side is more straightforward: AAC is supported in the RM container and is passed through or re-encoded at the specified bitrate. The RM container itself imposes hard limitations: no support for subtitle streams, chapter metadata, secondary audio tracks, or transparency. The -movflags +faststart optimization used in MP4 for web streaming has no equivalent in RM. File sizes for MJPEG-encoded RM output should be expected to run 3–8x larger than a quality-equivalent H.264 MP4, making this format unsuitable for modern distribution and appropriate only for legacy compatibility or archival scenarios.