What H.264/H.265 video compression parameters provide DVD-equivalent quality with better compression?

Question

I have got a box of DVD video disks that I seek to get rid of while I'd like to keep the videos by converting them into MP4 files to store them on a hard drive.

Considering superiority of the modern H.264 AVC and H.265 HEVC compression algorithms over the DVD-standard MPEG2 I hope to save hard drive space by compressing the video while saving ~99% of the DVD original quality.

What

• H.264 (FFMPEG + libx264) compression parameters
• H.265 (FFMPEG + libx265) compression parameters

should I use to achieve my goal?

By parameters I mean the CBR/CRF values, the preset (no veryslow/placebo please), flags etc.

PS: I'd prefer to constraint the case with using -pix_fmt yuv420p and -profile:v baseline -level 3.0 to ensure the file plays OK on all the devices including old devices relying on old hardware decoder chips. Using somewhat increased I-frames frequency (using the -g parameter) is also desirable to facilitate low-speed and high-latency media usage.

For HEVC, I'd as well prefer using parameters that would ensure smooth hardware-accelerated playback on devices that support it but I don't mean to focus on this constraint as I haven't seen any devices offering hardware-accelerated H.265 decoding at all yet.

Solution

Note that for this, you should always use the latest ffmpeg version, and preferably compile it yourself. This gives you access to the most recent libx265 and libfdk-aac for audio encoding.

Also, the data rate savings will be quite drastic if you're going from a ~10 MBit/s DVD to around 1–2 MBit/s for H.264 video and 0.5–1 MBit/s for H.265 video. Changing the quality in the below steps may influence the bitrates, but still the data reduction should be significant.

H.264

For the quality / rate control, you want to use CRF mode in libx264 rather than a constant bitrate. Using CRF ensures that an average quality is preserved, independent of the original video resolution or its complexity. Constant bitrate is only really useful if you're constrained by the transmission medium (e.g. hard drive speed, Internet throughput).

Choosing the CRF value is the tricky part. It requires you to look at the output. The default for libx264 (23) offers a quite good tradeoff between size and quality. But given that your original source is already compressed (and not with a very good quality compared to Blu-rays), you may want to change the CRF to be a little lower, such as 20. This will increase needed bitrate by about a third.

Choose the preset according to how long you want to wait. slow seems like a good value here.

ffmpeg -i input \
-c:v libx264 -crf 20 -pix_fmt yuv420p \
-x264-params keyint=240:min-keyint=20 \
-preset:v slow -profile:v baseline -level 3.0 \
-c:a libfdk_aac -vbr 4 \
output.mp4

The built-in ffmpeg AAC encoder can be used if libfdk-aac is not available. Use -c:a aac -strict experimental -b:a 128k instead of -c:a libfdk_aac -vbr 4.

H.265

Research suggests that using HEVC will lead to up to 74% bitrate saving compared to H.264. This is based on subjective viewing data of Ultra-HD sequences. Of course, it depends on the temporal complexity of the source content, and the amount of data saved will not be as high for hard to code sequences. Either way you can safely say that 50% data reduction is absolutely possible.

The default CRF for libx265 is 28. Using the same source content, it results in about half the bitrate compared to libx264 at CRF 23. This is irrespective of the actual bitrate, i.e., if the H.264 version takes 1.5 MBit/s, then H.265 will use around 750 kBit/s, but it's 750 kBit/s vs. 350 kBit/s for another sequence. I ran it on a couple of sequences at DVD-PAL resolution and was not able to tell the difference in terms of quality.

ffmpeg -i input \
-c:v libx265 -pix_fmt yuv420p \
-x265-params crf=28:keyint=240:min-keyint=20 \
-preset:v slow \
-c:a libfdk_aac -vbr 4 \
output.mp4

For more information, here are the relevant resources:

• FFmpeg Wiki on H.264 encoding and H.265 encoding
• ffmpeg documentation on libx265
• x265 documentation

Comments

[Ivan]

Thank you for a fine answer. What does keyint mean practically by the way?

[slhck]

The keyint in x264/x265 is the interval between IDR-frames, i.e. the interval between keyframes at which the decoder can refresh. In between, there can be non-keyframe I-frames, e.g. when a scene cut occurs. It's equivalent to the -g parameter if I'm not mistaken.

[Ivan]

BTW, @slhck, a thing that has surprised me in your answer - the attention you give to the choice of an AAC encoding library. I used to think they are all almost the same and give little or no difference, that the things are simple in the audio part (just choose the bitrate and go and that all the major lossy codecs like MP3, AAC and Vorbis sound almost or exactly the same at 128 kbps and above). Do you mean there actually is notable difference between libfdk-aac and ordinary aac?

[Elisa Cha Cha]

+1 on mentioning recent builds since old ones may not set the correct number of -refs for libx264 as defined by the desired -level (old bug 3307, and one other one IIRC).

[slhck]

Well @Ivan, it depends on how much of an audiophile you are or how much attention you pay to the audio quality. In fact, like you mention, at some bitrate threshold there will be no difference between the encoders, but I'm trying to encourage people to use libfdk whenever possible since the libvo-aacenc that you get with most ffmpeg builds has really bad quality (Japanese only, sorry). The built-in one is nice but doesn't do VBR.

[Ivan]

I am using the latest Zeranoe FFmpeg Win32 builds from ffmpeg.zeranoe.com/builds and the only way I have managed to get AAC out of it was -c:a libvo_aacenc. I would try building it on my own if I were running GNU/Linux but am afraid to imagine building software from sources (other than a VisualStudio project) on Windows...

[Golar Ramblar]

@Ivan (1st comment): See ffmpeg-wiki: "Based on quality produced from high to low: libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1 For AAC only: (Because it is a little bit confusing, with 3 encoders available): libfdk_aac > aac > libfaac The >= sign means greater or the same quality."