Convert MOV to RM — Free Online Tool
Convert MOV files to RealMedia (RM) format directly in your browser, re-encoding video with the MJPEG codec and audio with AAC. This conversion bridges Apple's professional QuickTime container to RealNetworks' legacy streaming format — useful for archival workflows or legacy system compatibility.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your MOV 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
MOV and RM are fundamentally different containers with almost no codec overlap. Because RM only supports MJPEG for video, the video stream from your MOV file — regardless of whether it was encoded in H.264, H.265, VP9, or another codec — must be fully re-encoded frame-by-frame into MJPEG. This is a computationally intensive process, not a simple remux. MJPEG stores each video frame as an independent JPEG image, which means there is no inter-frame compression; the resulting file will typically be significantly larger than an H.264-encoded MOV of the same content. Audio is encoded to AAC at 128k bitrate. Crucially, MOV features like multiple audio tracks, chapter markers, subtitle tracks, and transparency data are all dropped during this conversion, as the RM format does not support any of them.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg tool. In the browser-based version of this tool, FFmpeg runs as a WebAssembly (WASM) binary entirely within your browser — no data is sent to a server. The same command can be run locally on your desktop if you have FFmpeg installed. |
-i input.mov
|
Specifies the input file as a MOV (QuickTime) container. FFmpeg reads the container structure, identifies all streams (video, audio, subtitles, chapters), and makes them available for processing. Only the primary video and audio streams will be carried through to the RM output. |
-c:v mjpeg
|
Sets the video codec to MJPEG (Motion JPEG), which is the only video codec the RM container supports in FFmpeg's muxer. This forces a full re-encode of the source video — whether it was H.264, H.265, VP9, or any other codec — into a stream of independently compressed JPEG frames. |
-c:a aac
|
Encodes the audio stream to AAC, the default and recommended audio codec for RM output in FFmpeg. AAC provides reasonable audio quality at moderate bitrates and is one of only two audio codecs (alongside MP3) that FFmpeg's RM muxer accepts. |
-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 balanced midpoint. Unlike CRF used in the source MOV's H.264 encoding, MJPEG quality directly controls per-frame JPEG quantization — lower values produce less blocking and ringing in each individual frame. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second. This is a standard bitrate that provides acceptable stereo audio quality for voice and music content. It can be lowered to 96k to reduce file size or raised to 192k or 256k for higher fidelity, within the limits the RM format supports. |
output.rm
|
Specifies the output filename with the .rm extension, which triggers FFmpeg to use the RealMedia muxer. The .rm extension is the standard file type for RealMedia video files, as distinct from .ra (RealAudio-only) or .rmvb (RealMedia Variable Bitrate). |
Common Use Cases
- Feeding modern MOV footage into a legacy RealPlayer-based kiosk or exhibition system that only accepts RM files
- Archiving early 2000s multimedia projects that were originally built around RealMedia playback infrastructure
- Converting Apple QuickTime recordings for use with older corporate or educational streaming servers that were configured exclusively for RealNetworks technology
- Creating RM versions of MOV content for inclusion in retro web design projects or historical digital media collections
- Testing MJPEG video output from a MOV source when a standalone MJPEG stream is needed for a hardware device or industrial camera system that ingests RM containers
Frequently Asked Questions
There will be noticeable quality loss. MJPEG compresses each frame independently as a JPEG image, so it lacks the inter-frame prediction that makes modern codecs like H.264 efficient. At the default quality setting of -q:v 5 (on a scale of 1 best to 10 worst), results are acceptable for general viewing but will show JPEG-style compression artifacts, particularly in areas of fine detail or motion. If your source MOV was already lossily compressed in H.264 or H.265, re-encoding to MJPEG introduces a second generation of quality loss.
This is expected when converting from an inter-frame codec like H.264 (common in MOV files) to MJPEG. H.264 achieves high compression by encoding differences between frames rather than storing each frame in full. MJPEG stores a complete compressed image for every single frame, which is far less efficient for typical video content. A MOV at 100MB could easily produce an RM file several times that size at equivalent visual quality. If file size is a concern, lower the audio bitrate or use a higher -q:v value, though both further reduce quality.
No. RealMedia does not support any of these features. During conversion, all subtitle tracks, chapter markers, and secondary audio tracks present in your MOV file are silently discarded. Only the primary video stream (re-encoded to MJPEG) and the primary audio stream (encoded to AAC at 128k) are written to the output RM file. If preserving this metadata is important, RM is not a suitable target format.
No. RealMedia does not support transparency or alpha channels, and MJPEG within an RM container has no mechanism for storing alpha data. If your MOV file contains a transparency layer — common in motion graphics or ProRes 4444 exports — that alpha channel will be lost during conversion. Typically the transparent areas will be rendered as black or white depending on how FFmpeg composites the frame during re-encoding.
Change the -q:v value in the command. The scale runs from 1 (highest quality, largest file) to 10 (lowest quality, smallest file), with 5 as the default. For example, replacing -q:v 5 with -q:v 2 will produce sharper MJPEG frames at the cost of a larger output file. You can also adjust audio bitrate by changing -b:a 128k to values like 96k (smaller), 192k, or 256k (better audio quality). The full command would look like: ffmpeg -i input.mov -c:v mjpeg -c:a aac -q:v 2 -b:a 192k output.rm
On Linux or macOS, you can use a shell loop: for f in *.mov; do ffmpeg -i "$f" -c:v mjpeg -c:a aac -q:v 5 -b:a 128k "${f%.mov}.rm"; done. On Windows Command Prompt, use: for %f in (*.mov) do ffmpeg -i "%f" -c:v mjpeg -c:a aac -q:v 5 -b:a 128k "%~nf.rm". This is particularly useful for the desktop FFmpeg command shown on this page, since batch processing large collections of files over 1GB may exceed browser tool limits.
Technical Notes
RealMedia (.rm) is a proprietary format from the late 1990s with very limited codec support by modern standards. FFmpeg's RM muxer accepts only MJPEG for video and AAC or MP3 for audio, making full re-encoding unavoidable regardless of the source MOV's codec. The MJPEG codec in this context operates as Motion JPEG — a sequence of individually compressed JPEG frames with no temporal compression — meaning bitrates are high relative to perceived quality compared to modern codecs. MOV files can carry rich metadata including color space information, timecode tracks, and edit lists; none of this survives in RM. There are no special muxer flags available for RM (unlike MOV's -movflags +faststart for progressive web delivery). Seeking in the resulting RM file may be less reliable than in modern container formats because MJPEG's intra-only nature ironically does not guarantee that RM players implement clean random-access seeking. This conversion is best treated as a legacy compatibility measure rather than a quality-preserving archival strategy.