RM to MTS Converter

Convert RM to MTS

RM is RealNetworks' RealMedia container from the streaming era; MTS is the file extension AVCHD camcorders write to their own memory cards. This converter decodes the RealVideo and RealAudio streams inside a .rm file and re-encodes them into an MPEG-2 transport stream carrying H.264 video, saved under the .mts name. It is a full re-encode — RealVideo and H.264 share no bitstream, so nothing is copied through untouched.

This page is deliberately specific about what the resulting .mts is and is not, because "MTS" and "AVCHD" get used interchangeably and they are not the same thing.

How to Convert RM to MTS

1. Upload Your RM File: Drag and drop the .rm file onto the page or click "Add Files". Several clips can be queued at once and they all convert with the same settings. Files are uploaded over an encrypted connection and processed on our servers.
2. Confirm Video Codec and Audio Codec: The output opens on H.264 video with AAC audio. H.264 is correct for anything calling itself AVCHD; switch Audio Codec to AC3 if a strict AVCHD tool is downstream. The other selectable video codecs are H.265, MPEG-1, MPEG-2, MPEG-4, DivX and Xvid, and the other audio codecs are AC3, DTS (DCA), EAC3, MP2 and MP3.
3. Set Quality and Video Resolution: Under File Compression the page opens on Quality Preset at Very High (Recommended); Specific file size, Constant Bitrate, Variable Bitrate, Constant Quality and Constraint Quality are the alternatives. Leave Video resolution on Keep original for a standard-definition RealMedia source, and use Trim to take a time range instead of the whole clip.
4. Convert and Download: Click Convert and save the .mts file. No sign-up, no watermark; uploaded and converted files are deleted automatically after a few hours.

RM (RealMedia) at a Glance

MTS at a Glance — and What "AVCHD" Actually Requires

What the .mts File Really Contains

We converted a 10-second 320×240 RealVideo (RV20) test clip through the same H.264 + transport-stream path this page uses and inspected the bytes. The output starts with sync byte 0x47 at offset 0 and the next sync lands at offset 188 — plain 188-byte transport-stream packets. That is the right framing for a .mts name. The related .m2ts extension is different: encoding the identical source to .m2ts produces 0e bf 46 22 47 …, with the sync byte pushed to offset 4 by a 4-byte arrival-timestamp prefix — 192-byte BDAV framing. FFmpeg infers which of the two to write from the output extension, so the choice of .mts versus .m2ts is not cosmetic.

Two practical consequences. First, if a camcorder-oriented editor wants AVCHD-legal audio, switch Audio Codec to AC3 before converting — AAC plays fine in general-purpose players but is outside the AVCHD audio list. Second, if the goal is just a file that plays everywhere, MTS is the wrong target and RM to MP4 is the right one.

How the Quality Preset Lands on a Small RealMedia Frame

H.264 supports constant-quality encoding, so the Quality Preset resolves to a CRF value, then shifts by up to two steps depending on how large the output frame is — smaller frames get a lower (tighter) CRF, because compression artifacts are more visible when there are fewer pixels to hide them in.

Because standard-definition RealMedia sources sit at the bottom of that table, the default preset encodes them very conservatively — which is why the output is often larger than the input.

Frequently Asked Questions

Is an .mts file from this converter the same thing as AVCHD?

Not quite, and the distinction matters. AVCHD is a camcorder specification from Sony and Panasonic that pins H.264 video with Dolby AC-3 or linear PCM audio inside an MPEG-2 transport stream, usually within a BDMV folder structure on the card. This page produces the transport stream with H.264 video, which is the part most editors key on, but the default audio is AAC rather than AC-3 and there is no surrounding disc structure. Switch Audio Codec to AC3 if a strict AVCHD importer is downstream.

Why is my .mts bigger than the .rm I started with?

Because the preset is protecting the picture, not the size. We measured this on a 10-second 320×240 RV20 clip encoded at 200 kbit/s: the 443 KB source came out as a 693 KB .mts at the Very High preset, which resolves to CRF 16 on a frame that small. Stepping down to High (CRF 18 here) produced 530 KB, Medium (CRF 21) produced 383 KB, and Low (CRF 24) produced 309 KB — only at Low did the output finally come in under the original. If size matters more than a pristine re-encode, drop the preset, or switch File Compression to Specific file size and name a target.

Should I choose H.264, or one of the other codecs on the list?

H.264, unless something specific demands otherwise. It is the only codec the AVCHD specification allows, so it is the one an AVCHD-aware editor expects to find inside a .mts file. Selecting H.265, MPEG-2, MPEG-4, DivX or Xvid still produces a valid transport stream, but the file is then .mts in name only and camcorder-oriented tools may refuse it. MPEG-2 also behaves differently in this pipeline: its encoder has no constant-quality mode, so only resolution really moves the output.

Should I upscale a 320×240 RealMedia clip to 1080p?

No. Preset Resolutions set the output height and let the width follow the source aspect ratio, so choosing 1080p on a small RealMedia frame just interpolates the existing pixels across a much larger canvas — bigger file, same detail, and the CRF table above then loosens by two steps because the frame is larger. Leave Video resolution on Keep original. Genuine upscaling needs a dedicated super-resolution tool, not a container change.

Does converting to MTS remove the interlacing comb lines in my old clip?

No. There is no deinterlacing anywhere in this pipeline, so if the RealMedia source was captured from an interlaced broadcast or DVD, the comb artifacts are decoded as-is and re-encoded into the H.264 stream. The same applies to pixel aspect ratio: leaving resolution on Keep original preserves the source's sample aspect, but any resize flattens it to square pixels, which will visibly stretch an anamorphic source. If a source is anamorphic, set an explicit Width x Height that matches its display shape.

Can I convert RMVB files here too, or only .rm?

This page accepts .rm. RMVB is the variable-bitrate sibling of the same container and has its own page at RMVB to MTS — same codecs, same options. Whichever you use, the conversion is a full decode-and-re-encode; RealVideo and H.264 have nothing in common at the bitstream level, so there is no pass-through path and the RealVideo generation of loss is permanent.

What happens to the audio track from the RealMedia file?

It is decoded and re-encoded. RealMedia can carry RealAudio 1.0/2.0, Cook, Sipro, ATRAC3, AC-3, RealAudio Lossless or AAC, and whichever of those is present is decoded and written out as AAC by default. AC3, DTS (DCA), EAC3, MP2 and MP3 are the other selectable outputs. Because the source was almost certainly a lossy low-bitrate stream, this is a lossy-to-lossy step — pick a codec your target tool reads rather than chasing a high bitrate that cannot recover anything.

Would MP4 or TS be a better target than MTS for my file?

For general playback, yes. RM to MP4 gives you the same H.264 video in a container that phones, browsers, TVs and editors all open without argument. Choose .mts only when a specific camcorder-import or AVCHD-aware editing workflow keys off that extension. If you want the transport stream but without the AVCHD association — for broadcast or streaming tooling — RM to TS writes the same 188-byte packets under the neutral .ts name.

How are my files handled while they are on your servers?

The .rm file is uploaded over an encrypted connection, converted on our servers, and both the upload and the converted .mts are deleted automatically after a few hours. There is no account to create, no watermark on the output, and files are never shared or made public. The practical limit on a long RealMedia clip is upload size and time — if that is the obstacle, trim the source first with the Video Cutter, which accepts .rm directly.