Convert DVR to MKV — Free Online Tool
Convert DVR recordings — such as captured TV broadcasts or surveillance footage — into MKV (Matroska) files using H.264 video and AAC audio. MKV's open-standard container unlocks subtitle tracks, chapter markers, and multiple audio streams that proprietary DVR formats cannot carry, making your recordings far more portable and editable.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your DVR file here
or click to browse
Free — no uploads, no signups. Your files never leave your browser.
Settings
Note: Browser-based encoding uses approximate quality targets. For precise CRF compression, copy the FFmpeg command above and run it on your desktop.
Estimated output:
Conversion Complete!
DownloadHow It Works
DVR files typically store video encoded with H.264 (libx264) or MJPEG alongside AAC or MP3 audio inside a proprietary container tied to specific recorder hardware or software. During this conversion, FFmpeg reads the DVR container, decodes and re-encodes the video stream using libx264 at CRF 23 — a perceptually transparent quality level — and encodes audio as AAC at 128k bitrate, then wraps everything into the Matroska container. Because both formats share libx264 and AAC as common codecs, quality loss is minimal at default settings, but a full re-encode does occur rather than a lossless stream copy, since the DVR container's stream packaging is not directly compatible with MKV's muxer.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary — the open-source multimedia processing engine running under the hood of this browser tool via WebAssembly (FFmpeg.wasm). |
-i input.dvr
|
Specifies the input DVR file. FFmpeg probes the proprietary container to detect the video codec (typically H.264 or MJPEG) and audio codec (typically AAC or MP3) stored inside by the DVR device. |
-c:v libx264
|
Re-encodes the video stream using the libx264 encoder, producing an H.264 output that is universally compatible with media players, editors, and devices — and is natively supported by the MKV container. |
-c:a aac
|
Transcodes the audio stream to AAC-LC, ensuring the audio is cleanly re-encoded regardless of whether the source DVR file used AAC, MP3, or another codec, and that it is correctly muxed into the MKV container. |
-crf 23
|
Sets the Constant Rate Factor for the libx264 encoder to 23 — the default perceptually high-quality setting. Lower values (e.g., 18) produce larger files with better quality; higher values (e.g., 28) reduce file size, which can be useful for long surveillance recordings. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second, which is sufficient for the mono or stereo audio typical of DVR recordings from broadcast capture or surveillance systems. |
output.mkv
|
Defines the output filename and tells FFmpeg to use the Matroska muxer, wrapping the re-encoded H.264 video and AAC audio into an open-standard MKV container that supports subtitles, chapters, and multiple audio tracks. |
Common Use Cases
- Archive recorded TV broadcasts from a PVR or DVR box into a widely-supported MKV file that any media player can open without proprietary software
- Prepare surveillance or security camera footage for review in a professional video editor like DaVinci Resolve or Premiere Pro, which handle MKV far better than closed DVR containers
- Add subtitle tracks or chapter markers to a converted recording — features MKV supports but the source DVR format does not
- Share a recorded sports match or TV episode with friends by converting it to MKV, which is playable on smart TVs, Kodi, Plex, and most streaming devices out of the box
- Consolidate hours of DVR surveillance footage into organized MKV files with embedded metadata for long-term storage and searchability
- Strip the proprietary DVR container before uploading footage to a video archive or evidence management system that requires a standard open format
Frequently Asked Questions
There is some quality loss because the video is fully re-encoded rather than copied, but at the default CRF 23 setting the difference is typically imperceptible to the human eye. DVR recordings are already lossy (using H.264 or MJPEG), so you are not converting from a lossless source. If you want to minimize generation loss further, lower the CRF value — for example, use CRF 18 — at the cost of a larger output file.
Even though DVR files often contain an H.264 stream, the proprietary DVR container structures its data in a way that FFmpeg cannot reliably remux directly into MKV without re-encoding. Attempting a stream copy with '-c:v copy' can produce files with broken timestamps, missing keyframes, or sync issues, especially with footage from surveillance or broadcast capture systems. Re-encoding with libx264 ensures a clean, well-structured output.
Adjust the '-crf' value to control the quality-to-size tradeoff. The CRF scale runs from 0 (lossless) to 51 (worst quality). The default of 23 is a balanced starting point for DVR footage. Use CRF 18 for near-lossless quality at a larger file size, or CRF 28–36 to produce smaller files suitable for long-term archival storage where some quality reduction is acceptable. For audio, change '-b:a 128k' to '192k' or '256k' if you are converting recordings with high-quality stereo audio.
Yes. On Linux or macOS you can run: for f in *.dvr; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.dvr}.mkv"; done. On Windows Command Prompt use: for %f in (*.dvr) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.mkv". This is especially useful for processing large archives of surveillance or broadcast recordings offline.
Yes — one of the main advantages of converting to MKV is that the Matroska container natively supports subtitle tracks, chapter markers, and multiple audio streams, none of which the DVR format supports. After conversion you can add subtitle files or chapter metadata to the MKV using tools like MKVToolNix without re-encoding the video again.
FFmpeg will attempt to carry over any metadata tags present in the DVR file, but proprietary DVR formats often store recording timestamps and device metadata in non-standard fields that do not map cleanly to MKV's metadata schema. Critical metadata like the original recording date may be lost or incomplete. If preserving the exact recording time is important — for surveillance evidence, for example — document the timestamp before conversion or use '-metadata' flags to embed it explicitly into the output MKV.
Technical Notes
DVR is not a single standardized format — it is a catch-all extension used by dozens of hardware manufacturers (security DVRs, cable PVRs, broadcast capture cards) with proprietary container structures. FFmpeg's ability to read a given DVR file depends on how closely it conforms to recognizable structures; some files may require probing or format hints. The output MKV container uses Matroska's mature muxer, which is far better supported by modern software. The libx264 encoder at CRF 23 produces a YUV 4:2:0 H.264 stream compatible with virtually every playback device, from smartphones to smart TVs. Because DVR files often have irregular GOP structures and non-monotonic timestamps from broadcast capture or motion-triggered recording, the re-encode also normalizes keyframe intervals, improving seek performance in the output file. Audio is transcoded to AAC-LC at 128k, which is appropriate for the typically mono or stereo audio found in DVR recordings; surveillance footage rarely benefits from higher audio bitrates. Note that DVR files do not carry subtitle or chapter data, so those MKV features must be added manually after conversion if needed.