DVR to MXF Converter

Convert DVR to MXF: Check the Audio Sample Rate First

MXF (SMPTE ST 377-1) is the wrapper broadcast ingest, playout and tapeless archive systems expect, so wrapping a set-top-box or PVR recording in it is a reasonable thing to want. But the MXF writer has one hard constraint that catches almost everyone, and it is worth knowing before you upload a two-hour recording: the audio in your source must be 48 kHz.

Anything else — 44.1 kHz, 32 kHz, 22.05 kHz — stops the job. The underlying muxer refuses with the message "only 48khz is implemented" and nothing gets written. We reproduced it by taking one clip and changing only the audio sample rate: at 44 100 Hz the output was zero bytes; at 48 000 Hz the identical encode succeeded. There is no sample-rate control on this page, so this is not something you can fix here — the source has to arrive at 48 kHz.

The good news for DVR recordings specifically is that broadcast audio is normally 48 kHz already. ATSC uses AC-3 at 48 kHz and DVB mandates 48 kHz for its MPEG audio, so a genuine off-air recording almost always passes. The failures come from recordings that have been through consumer editing software, screen-capture tools or webcam-style CCTV apps, which happily write 44.1 kHz.

How to Convert DVR to MXF

1. Confirm the Source Audio Is 48 kHz: Open the recording in VLC and check Tools → Codec Information, or run ffprobe on it. If it is not 48 kHz, resample it in a local tool first — the conversion will fail otherwise, and the failure produces an empty file rather than a helpful nudge.
2. Upload Your DVR Recording: Drag the .dvr file onto the page or click "+ Add Files". The file is identified by its actual contents rather than by its extension, so transport-stream, program-stream and ASF-derived recordings are all read the same way.
3. Choose the Video Codec: Open Advanced Options. Video Codec offers exactly two entries — MPEG-2, which is preselected, and H.264. Audio Codec offers only PCM 16-bit Little Endian, because that is what the wrapper carries here. MPEG-2 is the safer pick for a traditional playout server; H.264 gives a much smaller file for the same picture.
4. Set Quality and Convert: File Compression opens on Quality Preset ("Very High (Recommended)"). Video resolution can Keep original or conform the frame to a delivery spec, and Trim can export a single Time Range. Click Convert and download the .mxf. No sign-up, no watermark.

What the Output Actually Is

The GOP=1 line is the one with a size consequence. The MXF muxer places strict limits on frame offsets, so the converter writes intra-only essence — every frame complete, none predicted from its neighbours — to stay inside them. On our 5-second 640×480 test clip the all-intra file was 3.55 MB against 2.23 MB for an otherwise identical encode with a 15-frame GOP: about 1.6× larger at the same quantizer setting. On a long recording that multiplier is the difference between a manageable file and an awkward one. It also means the file behaves like a mezzanine format — every frame is a cut point — which is exactly why editors like intra-only essence in the first place.

Which Quality Controls Actually Reach the Encoder

MPEG-2 has no CRF mode, and the converter's MPEG-2 path handles the quality-style controls by translating them into a bitrate. Two of them get discarded on the way.

That minimum bitrate is derived from the frame size, and it is also a floor under the modes that do work — asking for something very low will not get you below it. Roughly: 2 Mbit/s for anything up to 720×576, about 2.8 Mbit/s at 1280×720, about 7.5 Mbit/s at 1920×1080. If a low Specific-file-size target seems to be doing nothing on an MPEG-2 MXF, this floor is why; reduce the frame size instead, or switch the Video Codec to H.264.

Frequently Asked Questions

My MXF came back as a zero-byte file. What went wrong?

Almost certainly the 48 kHz rule. When the audio in the source is at any other sample rate, the MXF writer refuses to write a header at all, and because nothing gets written the job ends with an empty output rather than a partial one. Check the recording's audio sample rate before assuming the file is corrupt — ffprobe yourfile.dvr prints it, as does VLC's Codec Information panel. Resample to 48 kHz locally and the same conversion will succeed unchanged.

Does wrapping in MXF improve the quality of my recording?

No, and it is worth being clear about this because "broadcast format" sounds like an upgrade. MXF is a wrapper: it packages the compressed picture and sound, plus timecode and metadata, in a structure professional systems can read. The picture is re-encoded on the way through — to MPEG-2 or H.264 as you choose — and re-encoding a lossy source can only preserve or lose detail, never add it. What MXF buys you is acceptance by systems that reject consumer containers, not better pixels.

Should I pick MPEG-2 or H.264?

MPEG-2 if the file is going into a traditional broadcast playout or ingest server, which is the environment MXF exists for and where MPEG-2 essence is the long-standing expectation. H.264 if the destination is a modern NLE such as Premiere Pro or Resolve and you care about file size — H.264 will be substantially smaller for comparable quality. If you do not know where the file is going, MPEG-2 is the more conservative answer, at the cost of a much bigger file.

Why does my editor still reject the file even though it opens elsewhere?

The usual culprit is the operational pattern. This converter writes OP1a, a single self-contained file with picture and sound interleaved, which is what delivery, interchange, playout servers, Premiere Pro and Resolve expect. Avid Media Composer's media database instead wants OP-Atom, where each essence track lives in its own file and the picture and every audio channel are separate. A perfectly valid OP1a MXF will be refused by an Avid media import for that reason alone. There is no setting here that produces OP-Atom; Avid's own consolidate/transcode step is the route.

Will interlaced recordings be deinterlaced?

No. There is no deinterlacing filter in the pipeline, so a 1080i or 480i recording keeps its field structure and its comb artefacts on moving edges exactly as recorded. For an archive or ingest copy that is arguably correct behaviour — you are preserving what the recorder captured — but if the material is destined for a progressive delivery you will want to deinterlace in your editor after import.

Why is PCM the only audio codec I can choose?

Because it is the audio essence this wrapper writes here, and there is no second option to expose. That is also why the file is large: PCM is uncompressed, so 48 kHz 16-bit stereo runs at 1 536 kbit/s regardless of how quiet the recording is. It is the right choice for a mezzanine or ingest file — broadcast workflows generally want uncompressed audio rather than a second generation of lossy encoding — but it is a poor choice for anything you intend to email or upload.

How big will the MXF be compared with my DVR recording?

Larger, usually considerably. Three things push the size up together: the intra-only GOP roughly 1.6× versus a predicted encode at the same quantizer, uncompressed PCM audio at 1 536 kbit/s, and the MPEG-2 minimum-bitrate floor described above. A one-hour SD recording that sat at a few hundred megabytes as a transport stream will typically land in the low gigabytes as MXF. If size matters more than broadcast compatibility, DVR to MP4 is a far better fit.

Can I convert just part of a long recording?

Yes. Trim in Advanced Options starts at "Unchanged"; switch it to a Time Range and set Start time and Duration in seconds or as HH:MM:SS.sss. Given how much MXF inflates a file, trimming to the section you actually need is usually the difference between a practical output and one that is awkward to move around. Only one range can be exported per conversion.

What happens to my file after the conversion?

It is uploaded over an encrypted connection, converted on our servers, and both the upload and the .mxf output are deleted automatically after a few hours. There is no sign-up, no watermark, and files are never shared or made public. The recording on your own machine is untouched. Because MXF output is much larger than the source, the practical limit on a long recording is upload and download time over your connection rather than anything about the conversion itself.