Ver 10.0.6.4 h265 10-bit and CUDA SIZE PROBLEM

[LeRoy3rd]

I've been using h265 10-bit to encode all of my videos because using the standard (8-bit?) h265 profile, there's a HUGE lack of contrast... I think this is a problem with the black level? For instance, when encoding in h264, I threw in Star Wars, the opening scene with the starfield on black space looks great, nice and inky blacks... Moving to h265, everything is VERY grey, this isn't a small difference, and screenshots show how terrible it looks (I can provide these if you're interested)... h265 10-bit fixes this, but runs MUCH slower. I opted for picture quality over rendering speed.

I just updated DVDFab to the latest version and was excited to see that h265 10-bit encoding would now use the CUDA cores in my GTX 1080ti... Instead of taking almost an hour to render a blu-ray episode of Big Bang Theory, it look less than 3 minutes! Unfortunately, and here's the problem, size. h265's biggest selling point is the approximately 50% space saving over h264... That's not the case when using CUDA (and the 10-bit profile)... Also, using h265 standard, the file sizes are HUGE...


Blu-ray, Big Bang Theory, MKV, CRF 18, Length: 21:22
h264 CUDA: Time to render: <1.5 min, Size: 3.40GB
h265 standard CUDA: Time to render: <1.5 min, Size: 3.25GB
h265 10-bit CUDA: Time to render: <3 min, Size: 2.95GB
h265 10-bit CPU ONLY: Time to render: >54 min, Size: 1.74GB


Is this something that will be fixed? I mean, if the file sizes for h265 10-bit and h264 are virtually identical when using CUDA, and the video quality is virtually the same (I'm not using UHD discs with HDR, the only reason I'm using 10-bit is because of the bug(?) that kills the contrast in the 8-bit version of h265), but the h265 rendering times are THROUGH THE ROOF, what's the point of using h265 10-bit (no visual difference or space saving... but h265 takes more processing power to play, AND MUCH longer to render)? So, I'd use h264 since the quality is great, but the file sizes are about double what I get with h265 10-bit on the CPU... I can't use standard h265 as that kills the picture quality (and is HUGE, for some reason), h265 10-bit results in acceptable file sizes and excellent quality, but the cost in time is immense...

I'll still use h265 10-bit on the CPU, as the file size savings is what I'm after, but is there a chance the huge file sizes using CUDA will be fixed, OR that the h265 standard profile will be fixed to not have terrible quality? I'd love to use standard h265 8-bit, but the quality is abysmal... :'((

Little help?
Thanks,
LeRoy Wood III


EDIT: Random observation, why is the h265 10-bit file using CUDA SMALLER than the h265 8-bit file using CUDA???

[Wilson.Wang]

From Our Developer,
1. Intel/Nvidia/AMD hardware encode not have same crf as soft.
It is actually CONSTQP, and similary to crf.

2. In DVDFab h264 profile crf default is 20, h265 profile crf default is 26.
If your use crf 18 for h264, you should use 24 for h265 encode.

3. Some video encode gropus often use soft crf 18 VS nvidia constqp 22.
It better to test ripper a chapter to decide which should use 22, 23 or 24.
They all reasonable for balance video quality and size for hevc crf (CONSTQP) encode.

[LeRoy3rd]

From Our Developer,
1. Intel/Nvidia/AMD hardware encode not have same crf as soft.
It is actually CONSTQP, and similary to crf.

2. In DVDFab h264 profile crf default is 20, h265 profile crf default is 26.
If your use crf 18 for h264, you should use 24 for h265 encode.

3. Some video encode gropus often use soft crf 18 VS nvidia constqp 22.
It better to test ripper a chapter to decide which should use 22, 23 or 24.
They all reasonable for balance video quality and size for hevc crf (CONSTQP) encode.

Thanks for your response, knowing that the CRF is different could make a HUGE difference, thanks for the info! Looks like it's time to go back to testing... I didn't even think to re-evaluate the CRF quality...

I've attached the log.

-LeRoy