Converting Video Without Losing Quality Twice

Video conversion tools are numerous and most of them wrap the same underlying encoder. The choices that affect the result are about what you ask for, not which application you use.

Container versus codec

A container is the file wrapper: MP4, MKV, AVI, MOV, WebM. It holds streams and metadata.

A codec is how the video and audio are encoded: H.264, H.265, AV1, VP9 for video; AAC, MP3, Opus for audio.

The important consequence: changing the container does not require re-encoding. Copying the streams into a different wrapper is nearly instantaneous and loses nothing.

If a player will not open your MKV but plays MP4, and the codecs inside are compatible, you need a remux, not a conversion. Every decent tool offers this — it is usually labelled "copy" or "passthrough" for the stream.

When re-encoding is actually needed

The codec is not supported by the target device or platform.

The file is too large and you need to reduce the bitrate.

Resolution or frame rate must change.

You are editing and need a format the editor handles well.

Otherwise, do not re-encode. Every re-encode of a lossy format loses quality, and it is not recoverable.

Choosing a codec

H.264 — universally supported, hardware-decoded everywhere, larger files at equivalent quality. The safe default when compatibility matters.

H.265 — roughly half the size at the same quality, widely but not universally supported, and encumbered by patent licensing that keeps it out of some contexts.

AV1 — better compression again, royalty-free, support now broad in browsers and increasing in hardware. Encoding is slow unless hardware-accelerated.

VP9 — royalty-free, well supported in browsers, common for web video.

For audio: AAC for compatibility, Opus for efficiency where support allows.

Quality settings

Use constant quality rather than target bitrate for most purposes. Constant quality gives the encoder freedom to spend bits where they are needed, and a file that is the size it needs to be.

In tools built on the common encoders this is expressed as a CRF value, roughly 0 to 51 where lower is better quality and larger files.

Reasonable starting points: around 20 to 23 for H.264, around 24 to 28 for H.265 — the scales differ, so the same number means different things.

Use target bitrate only when you must hit a specific file size, such as an upload limit.

Preset controls speed against efficiency. Slower presets produce smaller files at the same quality and take longer. For anything you keep, a slower preset is worth the wait; for a quick share, fast is fine.

Hardware versus software encoding

Hardware encoding uses dedicated silicon on the graphics chip. Very fast, and at a given file size the quality is lower than a good software encode.

Software encoding is slower and produces better results per byte.

Use hardware for live streaming, screen recording, and quick conversions where time matters. Use software for anything archived or published where quality per byte matters.

Tools

Command-line encoders are what nearly everything else is built on. Direct use is the most capable and least convenient option, and it is the only sensible choice for batch work or scripting.

Graphical front ends wrap the same encoders with presets for common devices and platforms. For most people this is the right level.

Editors export video, and their export settings are frequently poor defaults. Check what codec and quality an editor is actually producing rather than accepting the preset.

Online converters upload your file to someone else's server, impose size limits, and frequently produce poor settings. Fine for a meme; not for anything private or anything you care about.

Practical situations

File will not play on a device. Check the codecs first. Frequently a remux to MP4 with stream copy solves it in seconds.

File is too large to send. Re-encode at a higher CRF, or reduce resolution. Reducing 4K to 1080p cuts the size dramatically and is invisible on a phone.

Uploading to a platform. Upload the highest quality you reasonably can. The platform re-encodes regardless, and giving it a better source produces a better result. Compressing before upload means two lossy passes.

Archiving. Keep the original. If space forces a choice, a slow software encode at a conservative quality setting is the best trade.

Extracting audio. Copy the audio stream rather than re-encoding it, which is instant and lossless.

The rule that matters most

Every lossy encode degrades the file, and the degradation compounds. Convert once, from the best source you have, to the format you actually need. A file that has been through three conversions looks like it has, and no tool will bring it back.

Mistakes people make

Re-encoding when a remux would do. Changing the container without touching the streams is near-instant and lossless. Most "conversions" are only container problems.

Compressing before uploading to a platform. The platform re-encodes anyway, so you have added a lossy pass for nothing. Upload the best source you have.

Using target bitrate when constant quality would be better. Constant quality lets the encoder spend bits where they are needed.

Using hardware encoding for archival. It is fast and produces lower quality per byte than a software encode.

Uploading private video to an online converter. The file goes to someone else's server, with a size limit and poor default settings.

Converting repeatedly. Each lossy pass compounds, and it is not recoverable.

The short answer

Check whether you need a remux rather than a re-encode. If you must re-encode, go from the best source you have, once, using constant quality and a slow preset for anything you keep. Copy audio streams rather than re-encoding them.