Convert RMVB to MOD — Free Online Tool
Convert RMVB files — RealNetworks' variable bitrate streaming format — into MOD, the MPEG-2-based container used by JVC and Panasonic camcorders. The conversion re-encodes the video stream using H.264 (libx264) and the audio using AAC, producing a MOD file compatible with camcorder-based workflows and legacy MPEG-PS playback systems.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your RMVB 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
RMVB uses RealNetworks' proprietary RealVideo codec inside a RealMedia container, which is incompatible with the MPEG-PS structure that MOD files require. During conversion, FFmpeg fully decodes the RealVideo stream and re-encodes it as H.264 using libx264 with a CRF of 23, and similarly decodes and re-encodes the audio (typically RealAudio or AAC) into AAC at 128k bitrate. The output is wrapped in a MOD container — essentially a renamed MPEG-PS file — matching the structure JVC and Panasonic camcorders write to SD cards. Because both the video and audio must be fully transcoded rather than remuxed, processing takes more time and involves some generational quality loss compared to a container-swap conversion.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary — the underlying engine that handles all decoding, encoding, and container muxing for this RMVB-to-MOD conversion. In the browser, this runs as FFmpeg.wasm compiled to WebAssembly. |
-i input.rmvb
|
Specifies the input file in RMVB format. FFmpeg uses its RealMedia demuxer to read the container and decode the RealVideo and RealAudio streams stored inside. |
-c:v libx264
|
Re-encodes the video stream using the libx264 H.264 encoder. This is necessary because RealVideo cannot be stored in a MOD/MPEG-PS container — the stream must be fully transcoded into a compatible codec. |
-c:a aac
|
Re-encodes the audio stream as AAC using FFmpeg's native AAC encoder. The original RMVB audio (often RealAudio or legacy AAC) is decoded and re-encoded to ensure it is properly wrapped in the MPEG-PS structure of the MOD container. |
-crf 23
|
Sets the Constant Rate Factor for libx264 to 23, which is the default balanced quality level. A lower number produces better visual quality with a larger file, while a higher number compresses more aggressively — particularly relevant when re-encoding from already-compressed RMVB sources. |
-b:a 128k
|
Sets the AAC audio output bitrate to 128 kilobits per second. This is a standard bitrate for stereo audio that provides good intelligibility and music quality suitable for the typical speech and ambient audio found in camcorder-era MOD content. |
output.mod
|
Specifies the output filename with the .mod extension. FFmpeg recognizes this extension and muxes the H.264 video and AAC audio into an MPEG-PS container structured as a MOD file, matching the format written by JVC and Panasonic camcorders. |
Common Use Cases
- Archiving old RMVB-format downloads of home videos or event recordings into MOD format for ingestion into legacy JVC or Panasonic camcorder editing software that only accepts MOD files
- Preparing video content for use with older MPEG-PS-based video kiosks or playback devices that were designed to read camcorder MOD files directly from flash media
- Migrating a library of RMVB files sourced from early 2000s internet video archives into a more MPEG-standard container for long-term preservation workflows
- Testing MOD file playback compatibility across different editing suites or hardware players without needing a physical JVC or Panasonic camcorder to generate source files
- Re-encoding RMVB content with tighter quality control (via CRF adjustment) before packaging into a MOD container for use in broadcast or production environments that mandate MPEG-PS delivery
Frequently Asked Questions
Yes, some quality loss is inevitable because the RealVideo codec in the RMVB source must be fully decoded and then re-encoded as H.264. The default CRF of 23 produces visually good quality for most content, but it is not lossless. Files that were already heavily compressed as RMVB — a common distribution format in the early internet era — may show compounded artifacts after re-encoding. Lowering the CRF value (e.g., to 18) will preserve more detail at the cost of a larger output file.
Camcorder editing suites like JVC Everio MediaBrowser or Panasonic HD Writer expect MOD files to conform to specific MPEG-2 video encoding parameters — particularly the video codec, resolution, and frame rate — since MOD was originally designed around MPEG-2. This conversion uses H.264 (libx264) rather than MPEG-2, which may cause compatibility issues with strict camcorder-specific software. For maximum compatibility with those tools, you would need to substitute '-c:v mpeg2video' in the FFmpeg command, though that is not the default used here.
The output MOD file uses AAC audio encoded at 128k bitrate by default. AAC is broadly supported in modern MPEG-PS players and non-linear editors, but some older hardware players designed around the original MOD specification may expect AC-3 or MPEG-1 Layer II audio instead. If you encounter audio playback issues on legacy hardware, you can substitute '-c:a libmp3lame' in the FFmpeg command to use MP3 audio, which has wider compatibility with MPEG-PS-based devices.
Video quality is controlled by the '-crf' flag. The default value of 23 is a balanced midpoint — lower values produce higher quality and larger files, while higher values reduce quality and file size. For archival or high-fidelity output, try '-crf 18'; for smaller files where quality is less critical, '-crf 28' is a reasonable choice. The CRF scale for libx264 runs from 0 (lossless) to 51 (worst quality), so you have a wide range to tune the tradeoff for your specific RMVB source material.
Yes. On Linux or macOS, you can run a shell loop such as: 'for f in *.rmvb; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.rmvb}.mod"; done'. On Windows Command Prompt, use: 'for %f in (*.rmvb) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.mod"'. This processes each RMVB file in the current directory and outputs a corresponding MOD file. The browser-based tool handles one file at a time, so local FFmpeg is the practical choice for batch workflows.
The variable bitrate nature of RMVB affects the source file size and streaming efficiency, but it does not directly carry over to the MOD output. During conversion, FFmpeg decodes the RMVB stream entirely before re-encoding, so the output quality is governed by the CRF value you set — not the original RMVB bitrate. That said, RMVB files with very low average bitrates will have already lost significant detail, and no amount of CRF adjustment in the output can recover information that was discarded during the original RMVB encoding.
Technical Notes
RMVB (RealMedia Variable Bitrate) stores video in RealNetworks' proprietary RealVideo codec, which FFmpeg can decode via its built-in RealVideo demuxer but cannot encode to — meaning any conversion out of RMVB requires a full transcode rather than a simple remux. MOD is structurally an MPEG-PS container and was originally paired with MPEG-2 video by JVC and Panasonic, but modern players and editors increasingly accept H.264 inside MPEG-PS wrappers. Metadata such as chapter markers and subtitle tracks is not preserved, as neither RMVB nor MOD in this configuration supports those features. One notable limitation is that MOD does not support multiple audio tracks or embedded subtitles, so complex RMVB files with secondary audio streams will only carry the primary audio channel into the output. File sizes for MOD output will typically differ substantially from the RMVB source — RMVB files are often heavily compressed internet-distribution encodes, while the H.264 output at CRF 23 may be larger if the source was aggressively compressed, or smaller if the source had unnecessarily high bitrate sections.