MyMediaTools

Convert MKV to RMVB — Free Online Tool

Convert MKV files to RMVB format using FFmpeg in your browser, re-encoding video with H.264 (libx264) and audio with AAC — the codec combination that makes legacy RealMedia-based players and older media servers recognize the file. RMVB's variable bitrate container trades MKV's rich feature set for a leaner output suited to compatibility with RealPlayer-era software.

FFmpeg Command

Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg

Free — no uploads, no signups. Your files never leave your browser.

Estimated output:

Conversion Complete!

Download

How It Works

Unlike MKV-to-MP4 conversions where H.264 video can often be stream-copied without re-encoding, converting MKV to RMVB always requires active transcoding of both streams. The MKV source may contain any of several video codecs (VP9, HEVC, PNG, MJPEG, or H.264), all of which must be re-encoded to H.264 using libx264, since RMVB in FFmpeg only supports that single video codec. Similarly, audio codecs like Opus, Vorbis, FLAC, or MP3 from the MKV must be re-encoded to AAC or MP3 — only those two are supported in the RMVB container. Critically, MKV features such as embedded subtitles, chapter markers, and multiple audio tracks cannot be carried into the RMVB output and are silently dropped during conversion. The result is a variable-bitrate file in the RealMedia container, sized by CRF-controlled H.264 quality and a fixed AAC audio bitrate.

What Each Flag Does

Flag What it does
ffmpeg Invokes the FFmpeg binary, the open-source multimedia processing engine that powers both this browser-based tool (via WebAssembly) and the equivalent desktop command.
-i input.mkv Specifies the input Matroska file. FFmpeg reads all contained streams — video, audio, subtitles, chapters, and metadata — though only video and audio streams will ultimately be written to the RMVB output due to container limitations.
-c:v libx264 Re-encodes the video stream using the H.264 codec via libx264. This is required because RMVB only supports H.264 for video, meaning any source codec in the MKV (HEVC, VP9, MJPEG, etc.) must be fully decoded and re-encoded rather than copied.
-c:a aac Re-encodes the audio stream to AAC, one of the only two audio codecs the RMVB container supports. Any MKV audio codec (Opus, Vorbis, FLAC, MP3) will be decoded and re-encoded to AAC, which offers good quality at the default 128k bitrate.
-crf 23 Sets the Constant Rate Factor for H.264 encoding to 23, the libx264 default. This controls video quality on a scale where lower values (e.g., 18) produce larger, higher-quality files and higher values (e.g., 28–35) produce smaller, more compressed files — a tradeoff especially relevant when the MKV source was encoded in a more efficient codec like HEVC.
-b:a 128k Sets the AAC audio output bitrate to 128 kilobits per second, the default that balances file size and audio fidelity. Since RMVB does not support lossless audio and all MKV audio must be re-encoded, this bitrate is the primary lever for controlling audio quality and its contribution to overall file size.
output.rmvb Specifies the output filename with the .rmvb extension, which signals FFmpeg to use the RealMedia Variable Bitrate muxer. The .rmvb extension (versus .rm) is the standard indicator that the file uses variable bitrate encoding, and is the extension expected by legacy RealPlayer-compatible software.

Common Use Cases

  • Restoring compatibility with legacy set-top boxes, NAS media servers, or network-attached DVD players from the mid-2000s that only recognize RealMedia file extensions and refuse to play MKV files
  • Preparing video content for distribution on older Chinese video-sharing platforms or peer-to-peer networks where RMVB was historically the dominant format and some clients still filter by container type
  • Archiving re-encoded copies of MKV content in RMVB format specifically to test or demonstrate RealPlayer compatibility during software QA or media server configuration testing
  • Downsizing a multi-audio-track or subtitle-heavy MKV into a stripped-down single-stream file with smaller overhead, accepting the loss of advanced features in exchange for a simpler container structure
  • Converting H.265 or VP9 encoded MKV files into an H.264-based RMVB so that hardware decoders in older smart TVs or media players that cannot handle modern codecs can play the content
  • Generating RMVB output files locally to verify FFmpeg's RealMedia muxer behavior during development or integration testing of a media processing pipeline

Frequently Asked Questions

No — subtitles and chapters are permanently lost in this conversion. RMVB does not support subtitle tracks or chapter metadata in the way MKV does, and FFmpeg's RealMedia muxer simply discards them without raising an error. If preserving subtitles matters, you should burn them into the video stream before converting, or choose a different output container like MP4 that can retain subtitle data.
RMVB supports only a single audio track, so FFmpeg will automatically select the default audio stream from the MKV — typically the first track or whichever is flagged as default. All other audio tracks are dropped. If you need a specific language track, you can modify the FFmpeg command to add '-map 0:v:0 -map 0:a:2' (replacing '2' with the index of your desired track) before the output filename to explicitly choose which audio stream to include.
Yes, some quality loss is inevitable because the video must be fully decoded from HEVC or VP9 and then re-encoded to H.264. The default CRF of 23 produces a visually good result for most content, but H.264 at equivalent bitrates is generally less efficient than H.265 or VP9, meaning the RMVB file may be larger than the source or show slightly softer detail. If the source MKV is already H.264, the re-encoding still occurs (FFmpeg does not stream-copy into RMVB) and quality loss is minimal at CRF 23.
Adjust the '-crf' value: lower numbers produce higher quality and larger files, while higher numbers produce smaller files with more compression artifacts. CRF 18 is considered visually near-lossless for H.264, CRF 23 is the default balanced setting, and CRF 28–35 gives noticeably smaller files at the cost of visible quality reduction. To reduce audio file size, lower the '-b:a' value from 128k to 96k or 64k; to improve audio fidelity, raise it to 192k or 256k.
The single-file command shown is the direct equivalent of what this browser tool runs, but on your desktop you can batch process with a shell loop. On Linux or macOS: 'for f in *.mkv; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.mkv}.rmvb"; done'. On Windows Command Prompt: 'for %f in (*.mkv) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.rmvb"'. This is particularly useful for files over 1GB, which exceed the browser tool's limit.
If the source MKV contains H.265 (HEVC) or VP9 video, re-encoding to H.264 at CRF 23 can produce a larger file because H.264 is a less efficient codec — it requires more bits to represent the same visual quality. To counteract this, try increasing the CRF value (e.g., '-crf 28') to allow more compression, or accept that the output will be larger as the trade-off for RMVB compatibility. If the source MKV was already heavily compressed at a very low bitrate, re-encoding may also introduce artifacts rather than reduce file size.

Technical Notes

RMVB (RealMedia Variable Bitrate) is a proprietary container developed by RealNetworks and is now largely obsolete outside of legacy systems and certain regional media ecosystems. FFmpeg's RMVB muxer imposes strict codec constraints: only libx264 is accepted for video, and only AAC or libmp3lame for audio — any other codec from the MKV source triggers a full transcode. The variable bitrate nature of the container refers to RealNetworks' original codec behavior and does not affect H.264's own rate control, which is governed by the CRF parameter independently. Metadata preservation is minimal: basic title and duration fields may carry over, but MKV-specific metadata, stream tags, attachments (such as embedded fonts for subtitle rendering), and cover art are all discarded. There is no transparency support in RMVB, which is consistent with MKV's libx264 default anyway. One practical concern is that while FFmpeg can write RMVB files, playback compatibility depends heavily on the player: modern players like VLC handle it via their own H.264 decoder and largely ignore the container, but native RealPlayer may reject the file if the internal metadata does not conform to its expected RealVideo codec markers. For long-term archival, MKV or MP4 are strongly preferred; RMVB output is best treated as a compatibility shim for specific legacy playback scenarios.

Related Tools

Convert MKV to AIFF Convert MKV to MTS Convert MKV to 3G2 Convert HEVC to RMVB Convert FLV to RMVB Convert WTV to RMVB Compress MKV Extract Audio MKV to MP3