bluray 1080p to x265 10 bit extra settings

[Subwars]

Hi guys,

Been many years since i did any kind of encoding, since dvd to avi days.

I'm going to start doing my own h265 encodes from remuxed blurays.

Going to start with my TV collections, then move onto movies.

I'm going to be using handbrake and so far thinking settings from my readings of.

MKV, H265 10 bit, RF20, slow, frame rate same as source, and passing through the english audio as is, dts or whatever, and the english subtitles, leaving filters as default.

I think these settings should give pretty good results, I'm completely unsure about the advanced settings though, at this point i'm thinking it might be best to just leave it blank, from what i have been able to determine, options would very depending on the show itself?

Are there any general settings i should add as just a default?

Completely lost with what I can use in there. And what do you guys think of the other options i've chosen to go with, all good?

Thanks in advance for any advise you can give.

[Asmodian]

That does seem like a good starting point, after that optimal is somewhat source dependent. Most things that help will also slow it down.

Things not in a preset I use are --hme, --selective-sao 2, --fades, and --hist-scenecut. --tskip is really good for anime.

Depending on how many cores your CPU has you might benefit from setting --frame-threads lower, 1 or 2 if it isn't too slow for you. If you have a lot of cores --pmode is good for making the encode more parallel, but there is some overhead so it should only be used when you want to utilize a lot of cores.

[benwaggoner]

Blu-ray is 8-bit only, and HEVC doesn't get anything close to the 8-as-10 quality boost H.264 and x264 delivered. I'd just stick with 8-bit end-to-end.

And in general, with bitrates enough lower to make the reencoding worth it, there will be sections that aren't visually lossless in reencoding.

[Subwars]

Originally Posted by benwaggoner

Blu-ray is 8-bit only, and HEVC doesn't get anything close to the 8-as-10 quality boost H.264 and x264 delivered. I'd just stick with 8-bit end-to-end.

And in general, with bitrates enough lower to make the reencoding worth it, there will be sections that aren't visually lossless in reencoding.

Hi ben,

Sorry i didn't quite get what you mean, "there will be sections that aren't visually lossless in rencoding" do you mean just going 8bit will still give an almost lossless encode?

I decided to go with the 10bit as i read it gives less banding and a better quality encode?

Of course i'm only just starting out and can only go on what google has given me, hence why i came here for help.

I'm all for lower file sizes, but I do want good quality foremost.

[Asmodian]

Is compatibility with older hardware decoding at all important for you? I believe what Ben meant was that the benefit from going 10 bit with x265 is very small (unlike x264) and because bluray is only 8 bit there is no good reason to use 10 bit.
Edit: the mention of not visually lossless at lower bit rates simply means re-encoding does hurt visual quality, unless so large it is pointless. 10 bit or 8 bit.

My understanding is that 10 bit is never worse with x265, perhaps slower but not lower quality/size. However, unless you resized or did some filtering at a higher bit depth there is not really a benefit either. I still use 10 bit when I don't care about broader hardware compatibility (usually) but I do not notice a real improvement whenever I have casually tested it. I think memories of x264 are too strong and are twisting Internet advice (and my behavior).

The situation is mildly depressing because x264 gets a big benefit when encoding 8 bit content as 10 bit but almost no hardware decoders can handle it, while x265 does not benefit much if at all from encoding 8 bit content as 10 bit but pretty much all new hardware decoders can handle it.

[RanmaCanada]

10bit is fantastic for anime, and dark scenes as it reduces significant banding. Most hardware made within the last 5 years can decode 10bit without an issue.

[Subwars]

Originally Posted by Asmodian

Is compatibility with older hardware decoding at all important for you?

No, don't need it to support older hardware, and even if there was, I've got everything in plex, which will take care of it for me

[benwaggoner]

Originally Posted by RanmaCanada

10bit is fantastic for anime, and dark scenes as it reduces significant banding. Most hardware made within the last 5 years can decode 10bit without an issue.

But if the source is already 8-bit with banding baked in, encoding in 10-bit isn't going to help.

And there are definitely phones and tablets from 4-5 years ago without 10-bit decode support.

[foxyshadis]

I always do 10-bit, but that's because I always do some level of filtering (in 16-bit) beforehand, and sometimes even apply fan-created HDR profiles. If you're going directly from 8-bit DVD to 10-bit HEVC, without filtering (or only filtering in 8-bit), 10-bit gives you nothing.

You really are looking at half the encoding and decoding speed, so keep that in mind, it's a real trade-off.

[excellentswordfight]

I do not agree that 10bit wont give any benefits for 8bit sources. All test I've done have shown improvement with using main10 as shown here:

https://forum.doom9.org/showthread.p...38#post1895238

Most "users" will encode stuff compatible with their own target devices, so assuming that the targets are main10 capable (otherwise main10 wouldn't be an option anyway), making decode an non issue.

[charliebaby]

Originally Posted by excellentswordfight

I do not agree that 10bit wont give any benefits for 8bit sources. All test I've done have shown improvement with using main10 as shown here:

https://forum.doom9.org/showthread.p...38#post1895238

Most "users" will encode stuff compatible with their own target devices, so assuming that the targets are main10 capable (otherwise main10 wouldn't be an option anyway), making decode an non issue.

I am 100% agree with you for the improvement from 8bit to 10bit and see it very well on the encoded video

[benwaggoner]

Originally Posted by charliebaby

I am 100% agree with you for the improvement from 8bit to 10bit and see it very well on the encoded video

It might be worth redoing those tests with a more recent x265 and perhaps --hevc-aq. I suspect the gap was somewhat caused by bugs and is likely somewhat smaller now.

[Cary Knoop]

A processed 8-bit video can quickly become 10-bit or higher, due to sub-bit presicion operations, so it benefits to encode with 10-bit instead of 8-bit assuming your video was processed.
The same is true for resolution, doubling the resolution is beneficial since some operations would only have a sub-pixel impact.

I generally process SD videos double sized (obviously taking interlaced considerations into account) using a full float32 workflow, dithering the result to 10 or 12 bit YUV 444 before I encode to YUV444 intermediates.
Some operations will benefit from the original subsampled state, for instance deinterlacing, so it is key when to move to 444 in the processing chain.
Keeping your processing chain YUV is important because many filters depends on luminance operations, however for anything related to color correction it is better to (temporarily) convert to RGBS as YUV is a bad model for color correction.

Only the end result will typically be a 4:2:0 subsampled 8 or 10 bit YUV.

[huhn]

wasn't this tested back in the x264 days where 10 bit was just massively better even with 8 bit sources inputted as 8 bit.

and wasn't x265 tested for the same and it was found that 10 bit doesn't hurt and the back in the days x265 version which uses 8 bit internal was just massively inferior to the 16 bit version and encoding to 10 bit was only little bit better then 8 bit but not worse.

[excellentswordfight]

Originally Posted by benwaggoner

It might be worth redoing those tests with a more recent x265 and perhaps --hevc-aq. I suspect the gap was somewhat caused by bugs and is likely somewhat smaller now.

Same as last time, source is 25Mbps Bluray compatable x264 file encoded from the 4k y4m version of tos.

encode (x265 3.4+9):

"ffmpeg.exe" -i "tos_sample.1080p.x264.mp4" -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m --input-depth 8 --output-depth 10 --preset slow --profile main10 --level-idc 41 --bitrate 3000 --pass 1 --keyint 240 --min-keyint 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited - -o NUL
"ffmpeg.exe" -i "tos_sample.1080p.x264.mp4" -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m --input-depth 8 --output-depth 10 --preset slow --profile main10 --level-idc 41 --bitrate 3000 --pass 2 --keyint 240 --min-keyint 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited - -o "main10_3mbps.hevc"
"ffmpeg.exe" -i "tos_sample.1080p.x264.mp4" -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m --input-depth 8 --output-depth 8 --preset slow --level-idc 41 --bitrate 3000 --pass 1 --keyint 240 --min-keyint 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited - -o NUL
"ffmpeg.exe" -i "tos_sample.1080p.x264.mp4" -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m --input-depth 8 --output-depth 8 --preset slow --level-idc 41 --bitrate 3000 --pass 2 --keyint 240 --min-keyint 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited - -o "main_3mbps.hevc"

decode:

ffms2("main10_3mbps.mp4")
#ffms2("main_3mbps.mp4")
ConvertToRGB24(matrix="Rec709")
Spline36Resize(3840,2160)
crop(0,280,-1920,-800)

frame exported using avspmod

Samples:
https://ibb.co/0Q0CsmN
https://ibb.co/558ZMth

Big difference, actually much bigger then i anticipated.

This one is interesting as well, big difference in the white areas, and the 10bit version is actually introducing some issues on those wholes on that black thing compared to the 8bit version.

https://ibb.co/yFsyc47
https://ibb.co/j5DcHJQ

Overall main10 seems to try to keep more detail in flat areas.

[benwaggoner]

Originally Posted by huhn

wasn't this tested back in the x264 days where 10 bit was just massively better even with 8 bit sources inputted as 8 bit.

and wasn't x265 tested for the same and it was found that 10 bit doesn't hurt and the back in the days x265 version which uses 8 bit internal was just massively inferior to the 16 bit version and encoding to 10 bit was only little bit better then 8 bit but not worse.

All correct. 10-for-8 was much more beneficial in H.264 than HEVC, as HEVC had tools added to make 8-bit more efficient.

Ironically, 10-bit HEVC decoders are more common than 10-bit H.264 decoders. So the advantage of 10-bit wound being more "enables HDR" than bitrate savings.

But there is still some gain from 10 over 8. Maybe ~3%. Maybe not worth the encode speed hit, but if you're already at veryslow...

[benwaggoner]

Originally Posted by excellentswordfight

Same as last time, source is 25Mbps Bluray compatable x264 file encoded from the 4k y4m version of tos.

Wow, thanks for running that. Those are quite visible differences, I presume in motion at 1:1 scale as well. And again, kudos for documenting so well with your command lines!

It is probably worth sending this to MCW to see if there's a bug going on there somehow.

It might be worth trying reencoding with --preset slower or veryslow, which some different RD and psychovisual stuff can kick in.

As a data point, could also be nice to show encoding time delta between 8 and 10 as well.

[excellentswordfight]

Originally Posted by benwaggoner

Wow, thanks for running that. Those are quite visible differences, I presume in motion at 1:1 scale as well. And again, kudos for documenting so well with your command lines!

It is probably worth sending this to MCW to see if there's a bug going on there somehow.

It might be worth trying reencoding with --preset slower or veryslow, which some different RD and psychovisual stuff can kick in.

As a data point, could also be nice to show encoding time delta between 8 and 10 as well.

Yes, in this case its possible to tell them apart during normal playback.

I also double checked the encoder settings embedded after encode, and they are identical (I thought that main and main10 might have some different default settings).

If its bug, its been there a long time... 10bit has always produced better results for me (maybe the fourth time i've done some sort of apples to apples comparison), must have been years ago I did it the first time. And to me it always seemed logical that it would be better, and that 10bit is what gets most attention from MCW as Main10 should be the most relevant profile of hevc. To bad the devs are not active here anymore, it would be nice to get some explanation from someone familiar with the code.

And here is the speed comparison:

Main10
Pass1: 8.68
Pass2: 8.95

Main
Pass1: 11.31
Pass2: 11.66

[benwaggoner]

Originally Posted by excellentswordfight

And here is the speed comparison:

Main10
Pass1: 8.68
Pass2: 8.95

Main
Pass1: 11.31
Pass2: 11.66

Wow, that's a smaller gap than I would have expected. Are both saturating CPU?