Differences between ripping H.264 and H.265

[vieekk]

I am kind of a newbie at video encoding, but I've started ripping and encoding parts of my DVD and Blu-ray library.

I rip the discs using MakeMKV and then encode the files using Handbrake with the "HQ 1080p30 Surround" preset with CRF@20 and with just a few changes: MKV container, encoder tune "Film" and choosing the subtitles I can understand.

This works fine and I think I am content with the quality produced. Recently, I also started to produce an alternate version using preset "H.265 MKV 1080p30" as base configuration and then changing CRF to 20 which I thought would match the H.264 preset, but reading up on this I gather they don't translate.

Am I stupid to encode these 1080p Blu-ray's with H.265 8-bit? Does H.265 only matter for 4K and HDR content? How do I know if any of my 1080p Blu-ray's have HDR? I do not think I own any HDR-compliant monitor as of right now, but I will in the near future.

I would appreciate if someone could guide me through this jungle. I am kind of tech-savvy (developer), but not in this part of the jungle.

Thank you in advance! Been wanting to post this in r/handbrake for months now, but I am never allowed in. I discovered I had an account here, probably from asking about ancient media players or DVD region codes some years ago.

[Prototype v1.0]

My experience of trying to make H.265 is - depending on the content - for many video files in 1080p or less tend to have a smaller size if I choose the same quality factor as for h.264. This is probably not an issue at all, but if you're planning to replay those videos on old (2008 'ish and older) computers, they may not be able to play.

I tend to use Avidemux over Handbrake for encoding videos.

[Cornucopia]

p30? From DVDs (many of which are film-based) and Blurays (many more of which are film-based)?
Look into IVTC to get true framerates for film-based material.

h.265 certainly makes more sense for 4k/HDR, but much depends on how much time you mind encoding plus what playback systems you have.

Neither DVDs nor Blurays have HDR. It is not supported in the specs for either of them. Only 4k (UHD) Blurays may have it (though not all do).

All your source discs are 8bit. You're not really gaining anything by making them 10bit in the re-encode except MAYBE smoothing out some possible banding that might occur in lower-bitrate re-encodings.

Scott

[vieekk]

My experience of trying to make H.265 is - depending on the content - for many video files in 1080p or less tend to have a smaller size if I choose the same quality factor as for h.264. This is probably not an issue at all, but if you're planning to replay those videos on old (2008 'ish and older) computers, they may not be able to play.

I tend to use Avidemux over Handbrake for encoding videos.

Yes, that is true. That is why I've been encoding H.264 also. My 2011 PC seems to be barely playing it and the Roku media players and Android devices I've been using seem to support it. For me, it's about am I making the quality worse by using the H.265 preset? I gain some storage space, but in my book it isn't worth it if I lose in quality. I cannot really see any difference by myself using the old monitors I have.

[vieekk]

p30? From DVDs (many of which are film-based) and Blurays (many more of which are film-based)?
Look into IVTC to get true framerates for film-based material.

h.265 certainly makes more sense for 4k/HDR, but much depends on how much time you mind encoding plus what playback systems you have.

Neither DVDs nor Blurays have HDR. It is not supported in the specs for either of them. Only 4k (UHD) Blurays may have it (though not all do).

All your source discs are 8bit. You're not really gaining anything by making them 10bit in the re-encode except MAYBE smoothing out some possible banding that might occur in lower-bitrate re-encodings.

Scott

Correction, I am using "HQ 576p25 Surround" preset for my DVD's if they are Swedish/European. "HQ 1080p30 Surround" for Blu-ray's.

Thank you for the certainty on HDR. I believe of all of my Blu-ray's are simple 1080p, so I would not have any HDR content by your "judgement". (Not meant to be taken badly, I am not a native English speaker.)

I am interested in file size. Can I get the same quailty of the HQ 1080p H.264 preset to H.265 and how would I go about that?

[abolibibelot]

[Disclaimer : I hadn't read the replies above when I wrote mine ; please don't go all manono on me if there's something below that was already stated in fewer words.]

Am I stupid to encode these 1080p Blu-ray's with H.265 8-bit? Does H.265 only matter for 4K and HDR content? How do I know if any of my 1080p Blu-ray's have HDR? I do not think I own any HDR-compliant monitor as of right now, but I will in the near future.

No, H.265 is presumably (add this adverb out of caution as I haven't seen unquestionable proof) more efficient than H.264 even for lower resolutions, it's just that (from what I could gather) it was designed for 4K+ resolutions first and foremost, so that's where it supposedly shines and vastly outperforms H.264 (again, I can only repeat what I read). Depending on who you ask, the expected efficiency improvement means that the same subjective quality should be obtained with a 20-30% reduction in bitrate. (I've read up to 50% but it seems exaggerated ; I've seen a few movies encoded in 720p in H.265 with a low bitrate, indeed the general quality was decent and could be considered satisfying by casual viewers, but it also produced ugly motion artifacts which I've never seen on low bitrate H.264 encodes.)
Don't know enough about HDR to comment on this aspect.

"HQ 1080p30 Surround"

Does this output a correct 23.976FPS framerate ? Haven't used Handbrake in a long while, but I've seen Handbrake-made encodes with stupid settings, for instance episodes of Columbo, originally shot on film and converted to NTSC 29.97FPS through telecine processing (if I'm not mistaken), which would require an IVTC processing before re-encoding as progressive, being instead encoded as progressive 29.97FPS, thus producing jerkiness and interlacing artifacts which can no longer be corrected at playback. Since Handbrake is targeted at casual, not tech-savvy users, it should definitely detect that kind of mistake and issue a DON'T DO DAT warning. (Goes to show that there's a fine line between software that is “idiot proof” and software showing proof that it was designed by idiots.)
And does this preset preserve the native audio track (DTS or AC3) or re-encode it ? If using Handbrake and the surround audio is AC3, better leave it that way. The included AAC encoder is not the best there is, and the size saving is too small (compared with the size reduction on the video side) to be worth the quality loss. If there's a DTS track, it makes sense to re-encode to AAC, but using a better encoder would be preferred. MeGUI allows to choose several, including qaac (based on Apple encoder) which is generally considered as the best currently available. The learning curve is steeper, but it's more versatile and offers much more control over how things are actually done under the hood.

[vieekk]

[Disclaimer : I hadn't read the replies above when I wrote mine ; please don't go all manono on me if there's something below that was already stated in fewer words.]

Am I stupid to encode these 1080p Blu-ray's with H.265 8-bit? Does H.265 only matter for 4K and HDR content? How do I know if any of my 1080p Blu-ray's have HDR? I do not think I own any HDR-compliant monitor as of right now, but I will in the near future.

No, H.265 is presumably (add this adverb out of caution as I haven't seen unquestionable proof) more efficient than H.264 even for lower resolutions, it's just that (from what I could gather) it was designed for 4K+ resolutions first and foremost, so that's where it supposedly shines and vastly outperforms H.264 (again, I can only repeat what I read). Depending on who you ask, the expected efficiency improvement means that the same subjective quality should be obtained with a 20-30% reduction in bitrate. (I've read up to 50% but it seems exaggerated ; I've seen a few movies encoded in 720p in H.265 with a low bitrate, indeed the general quality was decent and could be considered satisfying by casual viewers, but it also produced ugly motion artifacts which I've never seen on low bitrate H.264 encodes.)
Don't know enough about HDR to comment on this aspect.

"HQ 1080p30 Surround"

Does this output a correct 23.976FPS framerate ? Haven't used Handbrake in a long while, but I've seen Handbrake-made encodes with stupid settings, for instance episodes of Columbo, originally shot on film and converted to NTSC 29.97FPS through telecine processing (if I'm not mistaken), which would require an IVTC processing before re-encoding as progressive, being instead encoded as progressive 29.97FPS, thus producing jerkiness and interlacing artifacts which can no longer be corrected at playback. Since Handbrake is targeted at casual, not tech-savvy users, it should definitely detect that kind of mistake and issue a DON'T DO DAT warning. (Goes to show that there's a fine line between software that is “idiot proof” and software showing proof that it was designed by idiots.)
And does this preset preserve the native audio track (DTS or AC3) or re-encode it ? If using Handbrake and the surround audio is AC3, better leave it that way. The included AAC encoder is not the best there is, and the size saving is too small (compared with the size reduction on the video side) to be worth the quality loss. If there's a DTS track, it makes sense to re-encode to AAC, but using a better encoder would be preferred. MeGUI allows to choose several, including qaac (based on Apple encoder) which is generally considered as the best currently available. The learning curve is steeper, but it's more versatile and offers much more control over how things are actually done under the hood.

I won't go manono on you for sure. That was a horryfing read.

Most of my movies seem to be 23.976024 FPS for both source and encode. I am only verifying in VLC though. From what I understand Handbrake handles this automatically, but I could be wrong.

The preset I am using takes the first audio file and converts it to AAC, then takes the same audio and converts it to AC3 or if it's already AC3 pass it through, I believe. I might have done unnecessary AC3 encoding here if I didn't notice there was an AC3 track.

[abolibibelot]

That was a horryfing read.

Tell me about it... é_è I must have a natural propensity to attract this kind of... unpleasantness, shall we say, especially these days when I really could use the opposite, a little bit of friendliness for a change, as I also got that one recently (starting with my first post in that thread, same nickname as here). Not quite as harsh as the other one, but still, the spiders in my kitchen are more pleasant to interact with.

The preset I am using takes the first audio file and converts it to AAC, then takes the same audio and converts it to AC3 or if it's already AC3 pass it through, I believe. I might have done unnecessary AC3 encoding here if I didn't notice there was an AC3 track.

Indeed that's what it did with the default settings when I used to use it. I understand that it's meant to ensure maximal compatibility for complete n00bs who don't want to bother with the intricacies of audio formats, but it's generally unnecessary : either you know that the standalone device you want to play the file with only recognizes AC3, then it's unnecessary to put a second track in AAC, or the device reads AAC and your priority is size reduction, then the AC3 track is unnecessary. Since nowadays nearly all standalone devices can play AAC audio anyway, specifically encoding native audio (DTS in that case, I would suppose — as it would be even sillier to re-encode AC3 to AC3) in AC3 seems pointless, as it's a very inefficient lossy format, which if I'm not mistaken doesn't even support variable bitrate. (But again, converting 5.1 AC3 to 5.1 AAC is rarely worth is, since the bitrate per channel is already very low anyway, and won't compress that much more with settings meant to preserve a near “transparent” level of quality.)

[vieekk]

That was a horryfing read.

Tell me about it... é_è I must have a natural propensity to attract this kind of... unpleasantness, shall we say, especially these days when I really could use the opposite, a little bit of friendliness for a change, as I also got that one recently (starting with my first post in that thread, same nickname as here). Not quite as harsh as the other one, but still, the spiders in my kitchen are more pleasant to interact with.

I feel you. I don't know how some people seem to get off by being so rude and unpleasant to randoms with a similar interest. Exactly the person I would never like to be working with.

The preset I am using takes the first audio file and converts it to AAC, then takes the same audio and converts it to AC3 or if it's already AC3 pass it through, I believe. I might have done unnecessary AC3 encoding here if I didn't notice there was an AC3 track.

Indeed that's what it did with the default settings when I used to use it. I understand that it's meant to ensure maximal compatibility for complete n00bs who don't want to bother with the intricacies of audio formats, but it's generally unnecessary : either you know that the standalone device you want to play the file with only recognizes AC3, then it's unnecessary to put a second track in AAC, or the device reads AAC and your priority is size reduction, then the AC3 track is unnecessary. Since nowadays nearly all standalone devices can play AAC audio anyway, specifically encoding native audio (DTS in that case, I would suppose — as it would be even sillier to re-encode AC3 to AC3) in AC3 seems pointless, as it's a very inefficient lossy format, which if I'm not mistaken doesn't even support variable bitrate. (But again, converting 5.1 AC3 to 5.1 AAC is rarely worth is, since the bitrate per channel is already very low anyway, and won't compress that much more with settings meant to preserve a near “transparent” level of quality.)

I think I am fine with the default AAC and AC3 tracks provided by Handbrake preset. I am using Plex as a media server and I've seen it advised to provide AAC and AC3 for maximum compability with clients.

But the major part is the video bit. I've understood that CRF@20 is pretty good for H.264/1080p and that is what I've been encoding the majority of my library with, and now I wonder what the equivalent setting for H.265 might be. My reasoning is if I encode each future movie/series with the H.265 equivalent also I can safely delete H.264 versions when I've verified that H.265 versions work on all clients used.

[4kblurayguru]

Choose x264, change res to 720p, enable 2pass encoding at 2500bitrate, add avg/min/max bitrate and crf23 in "more settings", set fps to "same as source" and "constant frame rate", set de interlace to off (it defaults to de comb when i open mine), Set audio to whatever you want, i'd choose 128k stereo aac..

[abolibibelot]

Choose x264, change res to 720p, enable 2pass encoding at 2500bitrate, add avg/min/max bitrate and crf23 in "more settings", set fps to "same as source" and "constant frame rate", set de interlace to off (it defaults to de comb when i open mine), Set audio to whatever you want, i'd choose 128k stereo aac..

This seems completely irrelevant to the questions that were asked here... Which were : what x265 setting would be equivalent to CRF = 20 for x265 ? And what about 8bit vs. 10bit encoding ? Noone has provided a clear answer for the first one ; I have zero first hand experience on that matter, so I'd be interested to get some informed insight as well. As for the second one, I can only copy a few statements I gathered here and there.

From here :

I can answer your first question. At the same bitrate and transcoding from an 8-bit source 10-bit HEVC is better than 8-bit HEVC, because it hardcodes dither. https://gist.github.com/l4n9th4n9/4459997 I am still unsure, whether that makes 12-bit HEVC transcodes superior to 10-bit, thats why I ended up here.
answered Jun 20 '16 at 8:27

After I ran some tests I have found that 10bit also results in higher file sizes too. I'm curious if the bitrate was raised for the 8bit encode to match the final size of 10bit would it result in the same quality. – Fallen Jun 20 '16 at 19:57

From here :

Yes, you can get better compression efficiency (i.e. better quality at same bitrate) with 10-Bit, even when your source is "only" 8-Bit and the final output is 8-Bit too, simply because the encoder's and decoder's internal precision is higher (-> less rounding errors). On the other hand support for 10-Bit or even 12-Bit H.264 doesn't exist in any (consumer) playback device at the moment. Even software decoders are still very rare currently. So this is something you probably don't want to use yet. Also high-bitdepth H.264 will be significant slower to encode/decode. It was said that 8-Bit basically is a trade-off for speed.

From here :

10bit is more efficient in compression than 8bit, so it's used for better compression, not because the source has more bits.
You can read about it here.

“Anyway 10bits per channel can be radically helpful during editing since you avoid nasty banding so much more easily, etc. OTOH very very few people actually have displays that can show true 10bits even some of the fancy editing monitors only provide fake 10 bits so not many have a way to see a finished 10bit product and make use of a finished 10bit file. Almost anyone could make use of 10bit source footage though when trying to create something.”

From here :

Already, standard 8-bit HEVC encodes look great, but in many corners of the Internet, we're seeing more people using 10-bit encoding. This started years ago (around 2011) with the introduction of 10-bit AVC Hi10P encodes among anime lovers. Since hand drawn and cartoon-type animation often consist of large portions of the frame filled by solitary colors with little noise, really fine gradients and slight color irregularities can result in "banding" from 8-bit quantization that might not otherwise be noticeable in natural image capture where noise, film grain, and fine details are expected. A 10-bit encode would expand the quantization by 4x (ie. maximum 256 shades of gray now increased to 1024 shades), plus with the enhanced color accuracy, hence no need to "hard encode" extra dithering, bitrate can actually decrease and still achieve improved quality. The problem with these 10-bit AVC's though is that the decoding "profile" ("High 10 Profile" AVC) used is typically beyond the specifications of most consumer hardware. This meant that at least back in 2011 or so, you needed a pretty decent computer running the software decoder; typically at least a Core 2 Duo or equivalent... But that was then and computing power is not really an issue now unless we're looking at low-power Intel Atoms and ARM SoC's like the Raspberry Pi.
These days, with the advancement of video hardware and computing speed, I think it's time to look ahead and I believe that 10-bit HEVC will be the next ubiquitous "standard" for high quality encoding for the foreseeable future (next 10 years). [...]
Pretty straight forward selection of the "H.265 10-bit (x265)" encoder. "Constant quality" level 24 looks great for 4K encodes (I'll typically use 22 for 1080P - lower number is higher quality, given the lower resolution and less leeway for noticeable quality degradation especially on my 75" Vizio P75-C1 TV). In the "Encoder Preset", I use "Medium" which slows down the encoding process by allowing the lossy analysis to have more time to optimise the search for interframe changes to improve quality. Also, notice that I've selected "High Profile" on the right which will not automatically downsize the image resolution when doing 4K/2160P.
Note that there is value in using 10-bit encoding even with 8-bit videos. The file size could be smaller for 10-bit video than 8-bit due to the extra precision available to represent each pixel in a "constant quality" encode. In my own tests, I typically find file sizes about the same (+/-10%) which is really insignificant difference. However, realizing that 10-bit encoding could reduce banding especially in situations with limited bitrate makes it worthwhile I think.

(And here some comparisons from the same website.)


And this from a text file included in a pack of episodes of some series I happen to have found some place, which might be somewhat interesting :

This was proudly encoded by ****** using x265/HEVC and AAC audio.
[...]
"What the difference between lq, 10bit, q18 and q22?"
The LQ version is fixed bitrate two pass of variable image quality.
The ones with 10bit and not a Q number are just 2 pass encodes.
The Q22 version is fixed quality of variable size.
The Q18 version is fixed blu-ray quality of variable size.

IF the Q22 version is smaller than the LQ version, that means that the video was easy to compress to that quality.
AND in that case the LQ version is higher quality.

Tuned Encode Tag
The Tuned Encode is a full effort by me. First, I take samples and take every encoder setting one at a time finding the best result at a reasonable performance no slower than half the speed of slow. I combine the settings with a measurable quality improvement into a specific encoding setting for that content.
Then I combine the best of my 2 pass and q22 encodes.
I use some math to take the quality difference of the two encodes plus a kick based off the S score under 100 to try and get the best quality. Usually this ends up in a file size between the two pass and q22 but at higher quality than either.

"What does the S## or FS## on some of your titles mean?"
We are experimenting with using a SSIM based quality metric for our encodes to help users understand the quality of our work. The SSIM measures the accuracy of the outputted encode verse the source. It does not reflect on the sharpness or awesomeness of the image; only how close it is to the source material. An "S##" is a score where filters where not used. "FS##" is an encode where we used filters before the encoder, usually for nasty amounts of grain, this can throw off the score usually in a positive way and we like to be clear and honest at UTR. I also have been using a sophisticated sharpen filter, this can make a much more detailed and sharper image, but this has the effect of lowering the S score. To be clear the SSIM score represents how accurately we encoded the file, a crappy looking movie from the 90's with an FS89 will probably still look worse than a current UHD movie with a S45.
Some content, usually lacking detail doesn't score very high no matter what the bitrate. I have a q18 encode at 25,000KBs that only scored S64. For us trying to get the best quality for you, that still lets us compare settings for that file, higher is still better.
To make things simple I think of it as a grade; where a S91 would be an A- and a S78 would be a C effort.

* This encode includes a high quality degrain filter

Anyway, try not to be fooled by the dumpers taking credit for our work.