Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st August 2020, 01:25   #1  |  Link
Subwars
Registered User
 
Subwars's Avatar
 
Join Date: Aug 2002
Location: Australia
Posts: 166
bluray 1080p to x265 10 bit extra settings

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.
Subwars is offline   Reply With Quote
Old 21st August 2020, 02:27   #2  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,343
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.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 21st August 2020, 18:08   #3  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd August 2020, 11:26   #4  |  Link
Subwars
Registered User
 
Subwars's Avatar
 
Join Date: Aug 2002
Location: Australia
Posts: 166
Quote:
Originally Posted by benwaggoner View Post
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.
Subwars is offline   Reply With Quote
Old 22nd August 2020, 13:30   #5  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,343
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.
__________________
madVR options explained

Last edited by Asmodian; 22nd August 2020 at 13:45.
Asmodian is offline   Reply With Quote
Old 22nd August 2020, 15:47   #6  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 283
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.
RanmaCanada is offline   Reply With Quote
Old 23rd August 2020, 04:14   #7  |  Link
Subwars
Registered User
 
Subwars's Avatar
 
Join Date: Aug 2002
Location: Australia
Posts: 166
Quote:
Originally Posted by Asmodian View Post
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
Subwars is offline   Reply With Quote
Old 24th August 2020, 01:50   #8  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
Quote:
Originally Posted by RanmaCanada View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th August 2020, 12:23   #9  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,565
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.
foxyshadis is offline   Reply With Quote
Old 28th August 2020, 13:07   #10  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 246
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.
excellentswordfight is offline   Reply With Quote
Old 30th August 2020, 08:35   #11  |  Link
charliebaby
Registered User
 
charliebaby's Avatar
 
Join Date: Jun 2020
Posts: 36
Quote:
Originally Posted by excellentswordfight View Post
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
__________________
charliebaby is offline   Reply With Quote
Old 31st August 2020, 18:56   #12  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
Quote:
Originally Posted by charliebaby View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 31st August 2020, 19:20   #13  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
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.

Last edited by Cary Knoop; 1st September 2020 at 06:36.
Cary Knoop is offline   Reply With Quote
Old 1st September 2020, 06:01   #14  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,444
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.
huhn is offline   Reply With Quote
Old 1st September 2020, 11:20   #15  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 246
Quote:
Originally Posted by benwaggoner View Post
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):

Code:
"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:

Code:
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.

Last edited by excellentswordfight; 1st September 2020 at 11:37.
excellentswordfight is offline   Reply With Quote
Old 1st September 2020, 18:59   #16  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
Quote:
Originally Posted by huhn View Post
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...
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st September 2020, 19:04   #17  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
Quote:
Originally Posted by excellentswordfight View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd September 2020, 16:06   #18  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 246
Quote:
Originally Posted by benwaggoner View Post
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

Last edited by excellentswordfight; 2nd September 2020 at 16:10.
excellentswordfight is offline   Reply With Quote
Old 2nd September 2020, 17:17   #19  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,142
Quote:
Originally Posted by excellentswordfight View Post
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.