Initializing... drag & drop files here
Supports: AVCHD
AVCHD is the HD camcorder format Sony and Panasonic announced in May 2006: H.264/AVC at up to 24 Mbit/s, rising to 28 Mbit/s in the 2011 AVCHD Progressive revision, carried in an MPEG-2 transport stream. RM is RealNetworks' RealMedia container, which shipped alongside RealPlayer in 1997 and was tuned for streaming video down a dial-up line.
Converting one into the other only makes sense for a specific reason — a Helix or RealServer pipeline that ingests RealMedia, an archive standardised on RM, or an audience running RealPlayer on machines nobody is allowed to update. If you simply want the camcorder footage to play, AVCHD to MP4 is the correct page and this one is not. The sections below set out exactly what the format change costs, because on this pair it is unusually large.
| Property | AVCHD (your source) | RM (what you get here) |
|---|---|---|
| Announced | May 2006, Sony and Panasonic | 1997, RealNetworks |
| Container | MPEG-2 transport stream, .mts / .m2ts |
RealMedia |
| Video coding | H.264 / MPEG-4 AVC | RealVideo 1.0 or 2.0, both derived from H.263 |
| Audio coding | Dolby AC-3 or linear PCM | AAC, AC3 or RealAudio 1.0, your choice |
| Peak video bitrate in the spec | 24 Mbit/s; 28 Mbit/s in AVCHD 2.0 | Not the limiting factor — the container is (see below) |
| Frame sizes | 1920x1080, 1440x1080, 1280x720, 720x576, 720x480 | Anything, rounded down to a multiple of 16 |
| Scan modes | 60i, 50i, 24p; 50p and 60p in AVCHD 2.0 | Carried through as-is, combing included |
| Browser playback in 2026 | None | None |
| Desktop playback | VLC, MPV, every current editor | RealPlayer, VLC, MPV |
| Compression generation | 2003-era, still competitive | 1997-era, roughly two generations behind |
RealVideo predates HD by nearly a decade, and two hard limits follow from that. Neither is a setting you can change; both are worth knowing before you judge the output.
The container caps the bitrate. The RM muxer allows about 64 KB per packet, and a keyframe is typically around three times the size of an average frame. That works out to a practical video bitrate ceiling of roughly 4.4 Mbit/s for 25 fps footage and about 5.2 Mbit/s at 29.97 fps, rising to roughly 8.7 and 10.5 Mbit/s for 50p and 60p material. Ask for more than that under Constant Bitrate and the request is quietly reduced to what the container can carry. Since AVCHD routinely records at 17 to 24 Mbit/s with a far more efficient codec, the RM version of a 1080p clip will look markedly softer no matter what you set.
The frame size is rounded to a multiple of 16. RealVideo works in 16-pixel macroblocks, so each dimension is rounded down to the nearest multiple of 16 before encoding. A 1920x1080 camcorder frame becomes 1920x1072 — eight lines are dropped from the bottom. This is normal for the codec and invisible in practice, but it does mean the output will not report the resolution you typed.
One consequence of that rounding: because a scale step is always present on this target, the pixel aspect ratio is normalised to square. Anamorphic 1440x1080 AVCHD, which a player is supposed to stretch to 16:9, therefore arrives looking 4:3. If your camcorder recorded 1440x1080, set an explicit Width x Height of 1920x1080 so the widescreen shape is baked in rather than lost.
.avchd file onto the page or click "+ Add Files". This page's uploader takes the .avchd spelling; camcorder cards that write .MTS or .M2TS have their own pages. Queue several clips to run them through the same settings..rm. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours. No sign-up, no watermark.The File Compression list is shared across every video target we support, so not every mode behaves the same way once RealVideo is the output codec:
| Mode | Behaviour on an RM target | Verdict |
|---|---|---|
| Quality Preset | Scales the source clip's own bitrate — this works on a video source such as AVCHD, then meets the container ceiling described above | The sensible default |
| Constant Bitrate | Sets a target rate directly, capped at what the RM packet limit allows | Use this when you need a predictable size |
| Specific file size | Works back from a size in megabytes to a bitrate, subject to the same cap | Useful for a fixed storage budget |
| Constant Quality | Labelled "CRF" but on RealVideo it is a 1-31 quantiser scale where lower is better, and it opens at 5 | Works, but read the scale backwards from what the label suggests |
| Constraint Quality | The maximum-bitrate half of this mode is discarded for RealVideo, which cannot do that kind of rate control | Avoid — you get the quantiser and nothing else |
Beyond those, resolution is the strongest lever you have. Dropping a 1080p camcorder clip to 480p or 576p under Preset Resolutions does far more for the look of an RM file than any bitrate setting, because RealVideo was designed for exactly those frame sizes.
| RealVideo 1.0 (RV10) | RealVideo 2.0 (RV20) | |
|---|---|---|
| Derived from | H.263 | H.263 with Scalable Video Technology |
| Shipped with | RealPlayer 5, 1997 | RealPlayer 6 |
| Compression at the same bitrate | Baseline | Slightly better |
| Compatibility with very old players | The safest choice | Needs RealPlayer 6 or later |
| Preselected here | Yes | No |
Pick RealVideo 2.0 unless you genuinely have to reach a RealPlayer 5-era client. On HD source material the difference is small but it is free.
Two reasons compound. RealVideo 1.0 and 2.0 are H.263-derived codecs from the late 1990s and are roughly two generations behind the H.264 in your camcorder file, so they need far more bits for the same picture. On top of that the RM container caps the video bitrate at around 4.4 Mbit/s for 25 fps material, which is a fraction of the 17 to 24 Mbit/s AVCHD typically records at. Reducing the frame size under Video resolution helps far more than raising the bitrate, because it gives the old codec a job it was designed for.
Because RealVideo encodes in 16-pixel macroblocks, and each dimension is rounded down to the nearest multiple of 16 before the frame reaches the encoder. 1080 is not divisible by 16, so it becomes 1072 and eight lines come off the bottom. Nothing is broken and the effect is invisible in practice, but it explains why the file's reported resolution differs from what you set.
Your camcorder almost certainly recorded 1440x1080 anamorphic, where the player is expected to stretch the picture to 16:9. Because a scale step is always applied on an RM target, the pixel aspect ratio is normalised to square and that stretch instruction is lost, leaving a 4:3-shaped picture. Set an explicit Width x Height of 1920x1080 before converting so the widescreen geometry is written into the pixels themselves.
It depends entirely on what will play the file. RealAudio 1.0 is the safe answer for genuinely old RealPlayer builds, which expect RealAudio inside an RM container and may refuse anything else. AAC and AC3 are both offered and both work in modern players such as VLC, and AC3 has the advantage of matching what AVCHD already carries. If the file is going to an unknown RealPlayer installation, take RealAudio 1.0.
Because most consumer AVCHD is interlaced — 1080i or 576i — and each frame is two fields captured a fiftieth or sixtieth of a second apart. This conversion applies no deinterlacing, so those interleaved fields are encoded as they are, and anything that moved between them shows horizontal teeth. Progressive AVCHD footage, meaning 24p or the 50p and 60p modes from the 2011 revision, does not have this problem. If it matters, deinterlace in a video editor first and convert the progressive export.
RM is constant-bitrate and was designed for streaming down a fixed-bandwidth link; RMVB is the variable-bitrate variant, which produces smaller files at the same perceived quality but is less predictable to stream. If the destination is a streaming server, stay here. If it is a download or offline playback, AVCHD to RMVB uses the same codecs with better size behaviour.
No. Browsers have not decoded RealMedia natively for well over a decade, and the plugin route disappeared when Chrome and Firefox removed NPAPI-era plugins. You need a desktop player — RealPlayer on Windows, or VLC and MPV on any platform. That is the whole reason this conversion is a niche one: RM only earns its place inside a pipeline that already expects it.
Yes, though not without another lossy pass. RM to MP4 decodes the RealVideo and RealAudio streams and re-encodes them to H.264 and AAC, which plays everywhere. Bear in mind that it cannot recover what RealVideo discarded on the way in — if you still have the original camcorder file, converting that directly will always give a better result than a round trip through RM.
Lower the frame size rather than the bitrate. RealVideo handles 480p and 576p well because those are the sizes it was built for, and a 576p RM at a moderate bitrate looks considerably better than a 1080p RM squeezed into the same budget. Trim is the other big lever: cutting a long camcorder recording down to the section you actually need removes bytes without touching quality at all. To shrink an RM you already have, compress RM works on the existing file.
Your AVCHD clip is uploaded over an encrypted connection, converted on our servers, and both the upload and the RM output are deleted automatically after a few hours. Nothing is shared or made public, no account is required, and there is no watermark. Camcorder files are large, so the wait is usually dominated by upload time rather than the encode — trimming before you upload is the fastest thing you can do.