Handbrake settings to convert MKV to MP4 while retaining the original quality

What's the problem with Handbrake?

When you're using Handbrake to convert from one container format to the other (i.e. MKV to MP4 in your case), Handbrake will re-encode the video. See also the respective feature request that would have enabled video passthrough:

Sorry, adding video passthrough is not planned. HandBrake is designed to be a video transcoder. It wasn't designed to allow passthrough.

So, anytime you're changing containers with Handbrake, your video is going to get re-encoded, which means it a) takes time and b) may introduce quality loss.

Do I have to re-encode? Couldn't I just swap the container?

Since passthrough is not possible, ask yourself: Do I need to re-encode? If you only want to change the container from MKV to MP4, you usually don't need to encode anything, you just change the "wrapping" around the video. This doesn't lose quality, and it'll be a much faster process.

You can swap containers easily with FFmpeg – you just have to tell it to copy the video and audio streams:

ffmpeg -i input.mkv -c copy -map 0 output.mp4

There are also tools like MP4Box which can also create MP4 containers — the same exists for MKV with MKVtoolnix.

However, there's a big caveat: this only works if the audio and video codecs are supported in the target (MP4) container, which is the case for H.264/H.265 and AAC, for example, but not for many others. Also, subtitle format support for MP4 is different from MKV, and actually quite restricted, so this command may fail.

If this command does not work, and if your input uses the wrong codecs for the output container, you will probably have to re-encode. In this case, the codecs will be adapted to the output container.

To understand why this is necessary, it's important to learn the difference between video codecs and containers. This will help you understand why changing containers works and why the containers MP4 and MKV have little to do with video codecs, actually.

Why is re-encoding bad, anyway?

You can (usually) not retain full quality when encoding a video that was already encoded. This is because the original has already been compressed by throwing away information, and by doing it again you're introducing generation loss.

Often, you want to re-encode video when for example its dimensions change, or you need a specific bit rate to squeeze your video stream into, or your original video uses a codec that you can't play for whatever reason.

So, if you load your MKV video into Handbrake, and re-encode it with x264, the H.264 encoder Handbrake uses, store it in an MP4 container, you are going to lose quality no matter what, unless you set the bitrate or quality factor so high that you won't (really) see the difference. But then, the file size will be bigger as well.

In the ideal case, you would convert the video to an uncompressed video, which won't lose you any quality, but give you files of a dozen Gigabytes in size, even for a few minutes of video material.

Okay, but I really have to re-encode!

If you really have to re-encode, make sure not to set an average bitrate, but choose a Constant Rate Factor, which is something like "constant quality". Just like "variable bit rate" for MP3: It will make sure to spend the bits on the video parts that need them and make the overall quality better — at the same file size.

Sane CRF values are from 19 to 24, where lower means "better". So, you could try with a Rate Factor of 19. Also, make sure to set the "High" profile, which enables the encoder to use all bells and whistles and optimize the quality for a given bit rate.

slhck

Posted 2012-09-10T17:23:32.573

Reputation: 182 472

For some mkv files this will fail with (Could not write header for output file...incorrect codec). Use ffprobe -i file.mkv to see what format the a/v is in, you will likely need to reecode with x264 video and aac/ac3 audio – ski_squaw – 2016-04-09T18:33:24.213

u 100% certain that rewrapping files doesn't cause quality loss?? – oldboy – 2017-09-14T00:45:03.323

i'm getting an error on some files (for mkv to mp4 and mp4 to mkv): Output file #0 does not contain any stream. Anybody have any idea what this means? – oldboy – 2017-09-14T01:09:40.573

@Anthony Yes, rewrapping the file does not change the quality. About the error, I cannot tell you why exactly that would happen. You need to show the complete command-line output – ideally ask a new question and let me know. – slhck – 2017-09-14T07:11:07.177

Unfortunately ffmpeg is buggy and fails to convert MTS containers with h264/aac to mp4 containers properly. MTS is used by my JVC cam corder. – Jonny – 2017-10-28T16:15:39.023

Note: I was able to fix the problem by changing for i in *.MTS; do ffmpeg -i "$i" -c:v copy -c:a copy "batchoutput/${i%.mts}.mp4"; done into for i in *.MTS; do ffmpeg -i "$i" -c:v copy -c:a ac3 "batchoutput/${i%.mts}.mp4"; done (using a batch script to put all .mts files into mp4 files in a subfolder). ffmpeg complained about frame size, however the error output is likely incorrect as overriding the audio codec fixes the problem. I don't think audio uses frame sizes :-P – Jonny – 2017-10-28T17:00:36.073

@Jonny Audio uses frames, but in another sense. It's hard to tell what exactly is the issue with your stream without seeing the full console output. Re-coding with AC-3 is perhaps not the best idea in terms of quality; do you want -c:a aac -b:a 128k instead? – slhck – 2017-10-29T15:55:59.207

Just to be clear, Handbrake is not capable of merely changing the container format without reencoding? – BallpointBen – 2018-06-13T23:44:29.367

@BallpointBen Not possible, no: https://github.com/HandBrake/HandBrake/issues/264#issuecomment-233147775

– slhck – 2018-06-14T09:17:38.647

@slhck You should make the above clarification clearer in your answer, as the current answer seems to be saying two contrasting things, especially to someone who understands little of the specialised glossary of the field. – Hashim – 2019-01-08T06:42:05.837

Also to be clear, if I'm using Handbrake anyway to re-encode a video's audio, and since Handbrake doesn't allow video passthru, converting mp4 to mkv while I'm there will introduce no further loss? – Hashim – 2019-01-08T06:45:12.740

1@Hashim I tried to clarify the post as requested. And regarding your question, since Handbrake does not allow passthrough, converting from MP4 to MKV will introduce quality loss. And it'll take a lot of time. Just do ffmpeg -i input.mp4 -c copy output.mkv and you should be fine. – slhck – 2019-01-08T09:18:15.173

That wasn't my question. I'm confirming that if I'm re-encoding the audio of a video with Handbrake anyway (and therefore have to set a CRF, which will encode the video), is there any further loss in changing the MP4 container to MKV while I'm there? Or will the only loss in the video file result from the actual video and audio encoding of the file. In other words, does Handbrake have loss of quality that's inherent to changing the containers? – Hashim – 2019-01-08T17:00:00.100

@Hashim No, there is no loss inherent to changing containers, but because Handbrake cannot copy the video stream, it has to encode it again, which introduces loss (unless you set a really low CRF). The container storage itself is lossless, so whether you are using MKV or MP4 does not matter. – slhck – 2019-01-08T22:25:19.667

Thank you! It seems you are the only one who seems to care about this question and help me out, I followed your advice and seems the quality is same as the original! :) – orange – 2012-09-11T18:46:00.617

Here is quite detailed guide on Handbrake's settings https://mattgadient.com/2013/06/12/a-best-settings-guide-for-handbrake-0-9-9/

– janot – 2015-05-18T23:38:22.857

i'm getting an error on some files (for mkv to mp4 and mp4 to mkv): Output file #0 does not contain any stream. Anybody have any idea what this means? – oldboy – 2017-09-14T01:15:30.653

Works like a charm. – Kit Johnson – 2016-03-21T06:36:28.480

I put this in the folder with ffmpeg.exe and then changed it to for %%a in ("*.mkv") do %~dp0ffmpeg.exe -i "%%a" -vcodec copy -acodec copy "%%~na .mp4" – davidtbernal – 2017-03-30T01:32:20.727