DV to RM Converter

DV to RM: Two Formats From Opposite Ends of 1997

DV was designed to record everything: a fixed data rate of around 25 Mbit/s, every frame compressed independently, nothing thrown away between frames so a tape could be shuttled and edited. RealMedia was designed to throw away as much as possible: RealNetworks built RealVideo to push moving pictures down a dial-up modem, and the container and codecs still carry the constraints of that job. Converting one to the other is a deliberate step down, and this page is about doing it with your eyes open.

The realistic reasons to want an .rm today are narrow — feeding a legacy RealServer or kiosk system, reproducing a file for an archive that catalogued RealMedia, or satisfying software that only opens what it opened in 2003. If none of those apply, DV to MP4 gives you a smaller file that plays on everything, and DV to MPEG keeps the footage in the MPEG family for older authoring tools.

Side-by-side

How to Convert DV to RM

1. Upload Your DV File: Drag the .dv onto the page or click "+ Add Files". Tape captures are large — DV is roughly 13 GB per recorded hour — so the upload is the slow part of this job, not the encode.
2. Choose a Video Codec and an Audio Codec: Video Codec offers exactly two entries, RealVideo 1.0 and RealVideo 2.0, with RealVideo 1.0 pre-selected. Audio Codec offers AAC, AC3 and RealAudio 1.0; pick one deliberately rather than relying on what the page opens with, because two configuration rules compete to set the audio default here and the winner is not something you should have to guess.
3. Set the Quality With Constant Quality: Under File Compression, Constant Quality exposes a slider labelled CRF that runs 1 to 31 on this page. It is a quantizer scale, not a CRF scale, so lower numbers mean better pictures — the opposite of the H.264 convention. Leave Video resolution on Keep original unless you have a reason to shrink; a DV frame is already small.
4. Convert and Download: Click Convert and save the .rm. Files upload over an encrypted connection, are decoded and re-encoded on our servers, and are deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.

What the Quality Slider Actually Does

On RealVideo the numeric quality control is a quantizer, coerced into the range 1 to 31, where 1 is the finest quantization and 31 the coarsest. Encoding the same 3.97-second 720 x 480 NTSC DV capture at four points on that scale gives the shape of the curve:

Note how flat the curve gets past the middle: going from 15 to 31 saves under 100 KB while costing a great deal of picture. The useful range on this codec is the low end.

What the RM Container Drops

Three limits are worth knowing before you convert, because none of them announce themselves in the output.

• Pixel aspect is not carried. A DV frame is 720 pixels across whether it was shot 4:3 or 16:9, with the intended shape signalled as a flag. Encoding the same capture to Matroska preserves that flag; encoding it to RealMedia does not, and the .rm reports no pixel aspect at all. A 16:9 tape therefore plays back squashed. If the shape matters, set an explicit Width x Height under Video resolution — 848 x 480 for a 16:9 NTSC capture, since RealVideo dimensions are snapped down to multiples of 16 and 854 is not one.
• Constraint Quality's ceiling is discarded. The mode renders, and its Max bitrate field accepts a value, but the RealVideo encoders only understand a simple target bitrate or a quantizer, so the maximum-rate and buffer parameters are stripped before the encode runs. Use Constant Quality instead — on this codec it genuinely works.
• Bitrate is capped for you. The RealMedia container cannot store a compressed frame larger than about 64 KB, so a bitrate high enough to produce one would break the file. Rather than fail, the encoder's target rate is clamped based on the frame rate — around 5 Mbit/s at 29.97 fps. Asking for 20 Mbit/s therefore does not get you 20 Mbit/s. Standard-definition DV sits comfortably inside this, which is precisely why DV is a well-behaved source for RealMedia; upscaling to 720p or 1080p is where this limit starts to bite.

Frequently Asked Questions

Which audio codec should I pick, and why does the page not just decide for me?

Pick one explicitly. Three entries are offered — AAC, AC3 and RealAudio 1.0 — and on RealMedia targets two configuration rules both claim the right to set the default, so the pre-selected value is not something worth relying on. If you want an authentic RealMedia file for a legacy player, choose RealAudio 1.0; it is a very low-rate speech codec and it will sound like one. If you want the audio to be listenable and the file will be opened by a modern player, choose AAC. AC3 is the choice when something downstream expects Dolby Digital.

Why is my 16:9 footage squashed in the RM file?

Because RealMedia does not carry a pixel aspect ratio. DV records 720 pixels across for both 4:3 and 16:9 and signals the intended shape separately; that signal survives into containers like Matroska and is simply absent from the .rm, so the player draws 720 x 480 as if the pixels were square. The fix is to bake the correct shape into the pixel grid: choose Width x Height under Video resolution and enter 848 x 480 for a 16:9 NTSC capture or 640 x 480 for 4:3. RealVideo snaps dimensions down to multiples of 16, which is why 848 rather than 854.

The CRF slider goes 1 to 31 and lower numbers look better. Is that a bug?

It is a label mismatch, not a bug. The control is called CRF throughout the interface because most of our targets use H.264-style constant rate factors, where the range is 16 to 51 and lower is better. RealVideo does not have a CRF mode; it takes a quantizer between 1 and 31, and the slider is correctly re-ranged for it. Lower is still better, but the numbers mean something different: 5 on this page is a good working value, whereas 5 on an H.264 page would be near-lossless overkill.

Should I use RealVideo 1.0 or RealVideo 2.0?

RealVideo 1.0 is what the dropdown opens on and is the safer pick for maximum compatibility with old players, since anything that reads RealMedia at all reads RV10. RealVideo 2.0 is the slightly later codec and generally makes better use of a given bitrate. Both are decoded by current ffmpeg-based players such as VLC, so if the file is going to be opened by anything modern the choice barely matters; if you are feeding genuinely old software, stay on 1.0.

Will interlacing from the tape survive into the RM file?

Yes, baked in. Standard-definition DV is normally interlaced, with two fields per frame captured a fiftieth or sixtieth of a second apart, and there is no deinterlacing step anywhere in this pipeline — no filter is applied and none is offered. Moving edges will show the classic comb pattern in the output, and RealVideo's coarse quantization tends to make combs look worse rather than hide them. If the footage matters, deinterlace it in an editor before uploading.

Can I get the file down to a specific size?

Yes — Specific file size under File Compression takes a target in bytes, kilobytes or megabytes, with an Auto Scale option that reduces the frame size as well when the target is very aggressive. It works by computing a bitrate to fit, so on this codec it is subject to the same clamp described above: you can always ask for a smaller file, never for a much bigger one. For most standard-definition tape footage the quantizer approach gives a better-looking result for a given size, because it spends bits where the picture needs them instead of holding an average.

Is the conversion lossless if I set the quality to maximum?

No. The server always decodes and re-encodes, and RealVideo has no lossless mode at any setting — quantizer 1 is the finest step available, not a bypass. There is also a generation change happening regardless: DV compresses each frame on its own with DCT at a fixed rate, while RealVideo predicts most frames from their neighbours. Even at the finest quantizer you are re-describing the picture in a very different codec. Keep the original .dv capture if it is your only copy of the tape.

Why is there no .dv output anywhere on the site?

DV is registered as an input-only format here. That reflects what DV is: a tape acquisition format with a fixed frame size, a fixed data rate and a fixed structure, useful for getting footage off a camcorder and not much use as a delivery target. Everything you would want to do with the footage afterwards is better served by a modern container. If you want to keep quality high while moving off DV, an MP4 at a generous bitrate loses far less than a RealMedia file does.

Can I convert several tape captures in one go?

Yes — queue them and they convert with the same settings. The constraint is upload rather than processing: DV runs about 13 GB per recorded hour, so a handful of full tapes is a large upload. If you only need part of a capture, trim it first with Video Cutter, which accepts .dv directly, and convert the shorter clip. That is usually much faster than uploading an hour to keep two minutes.

How are my files handled, and how long are they kept?

Your .dv is uploaded over an encrypted connection, decoded and re-encoded on our servers, then deleted automatically after a few hours along with the .rm it produced. There is no sign-up, no watermark, and nothing is shared or made public. Because DV captures are large, upload time is the dominant cost of this conversion; the encode itself is quick, since RealVideo at standard definition is very light work by modern standards.