Bitrate-capped CRF

[easy2Bcheesy]

Hi - so we encode HEVC videos with x265 in Handbrake. Typically 4K at CRF20 on the 'fast' preset (though interestingly, I'm finding that CRF20 HEVC on fast is delivering lower quality than CRF20 h.264 on fast)

It seems that there are very limited scenarios where straight CRF can cause bitrate spikes up to 500Mbps, which is causing problem on target hardware (TV decoders, basically).

This is probably a very simple question - but what command line options should I put into the 'extra options' box on Handbrake to limit bitrate to 100Mbps max?

[Boulder]

The VBV settings should help you with that.

https://x265.readthedocs.io/en/maste...on-vbv-bufsize

EDIT: and the CRF values are not comparable between the two encoders, you need to do a 2-pass VBR encode for a fair comparison.

[easy2Bcheesy]

In general, with CRF encoding, I'm not sure I'm seeing any quality advantage with HEVC in terms of like-for-like bitrate vs h.264, which is surprising me. Only if I move the encoder to the 'slow' preset do I see the quality, and 4K encoding at 6fps on a 5950X isn't viable :/

Using vbv-bufsize=100000:vbv-maxrate=100000 which looks like it does the trick in Handbrake, thanks for the assist.

[Boulder]

Originally Posted by easy2Bcheesy

In general, with CRF encoding, I'm not sure I'm seeing any quality advantage with HEVC in terms of like-for-like bitrate vs h.264, which is surprising me. Only if I move the encoder to the 'slow' preset do I see the quality, and 4K encoding at 6fps on a 5950X isn't viable :/

I believe many others have reached the same conclusion. The preset slow or slower is pretty much required for the real benefits to start showing up. I think it's mainly due to rd-level switching to 4 at slow, at slower it goes even further at 6.

Oh, and --no-sao in every encode or x265 will just Smooth All Objects

[Nico8583]

Hi, just to know : does 2-pass VBR better than CRF ? And does no-sao should be used or not ? Thanks

[excellentswordfight]

Originally Posted by Nico8583

Hi, just to know : does 2-pass VBR better than CRF ? And does no-sao should be used or not ? Thanks

In my experience the difference is negatable at the same bitrate (I belive that the devs stated this as well once upon a time when they were active here).

Turning of SAO (i.e. no-sao) can and will be beneficial in a broad amount of scenarios with very little drawbacks. There are still some cases that do benefit of SAO, I use it for some animation/content with a lot of flat areas, and highly compressed encodes.

Originally Posted by Boulder

I believe many others have reached the same conclusion. The preset slow or slower is pretty much required for the real benefits to start showing up. I think it's mainly due to rd-level switching to 4 at slow, at slower it goes even further at 6.

Agreed, imo preset slow and lower are the only viable options for most scenarios. When using higher presets the speed/compression/image characteristics of x265 enters a weird place were starting to use HW-encode or x264 makes more sense.

[Nico8583]

Thanks ! And the preset "slow and lower" recommended usage is for both 2-pass VBR and CRF ? Or only for CRF ? Thanks.

[Asmodian]

Yes, 2-pass and CRF are very similar if the files end up the same size. The limitations of the various presets affect them in the same ways.

[Nico8583]

Thanks ! So I'll make some tests. Does the x264 still better than x265 for 1080p sources ? In the past I found x264 was better like easy2Bcheesy but I haven't tried it since 2 years... Thanks

[benwaggoner]

Originally Posted by Nico8583

Thanks ! So I'll make some tests. Does the x264 still better than x265 for 1080p sources ? In the past I found x264 was better like easy2Bcheesy but I haven't tried it since 2 years... Thanks

x265 generally offers quite a bit better compression efficiency than x264 for 1080p. You can equivalent quality in down to half the file size of H.264.

Encoding time is quite a bit longer, although x265 takes better advantage of lots of cores and AVX2 than x264 does, so the perf gap can really depend on your hardware.

But even at equivalent encoding times, x265 will still be better by x264 by a good chunk.

Very grainy sources have less of a gap and require a little more tuning in x265.

But don't assume you can just reuse --crf or other settings from x264 in x265. There is different tuning, and depending on settings, x265 can get away with a higher CRF a lot of the time.

[Nico8583]

Thanks !
Could you give me a good basis to start ?
A x265 command line to encode a 1080p FHD BD and a x265 command line to encode a 4K UHD BD ?
I was starting to look at x265 in the past but some events took all my time and now I would like to start with x265.
Thanks !

[benwaggoner]

Originally Posted by Nico8583

Thanks !
Could you give me a good basis to start ?
A x265 command line to encode a 1080p FHD BD and a x265 command line to encode a 4K UHD BD ?
I was starting to look at x265 in the past but some events took all my time and now I would like to start with x265.
Thanks !

Do you have particular quality, speed, file size, etc requirements?

[Nico8583]

I would keep a good quality, currently I use x264 preset slower CRF 18 but slower is very very slow with x265 (using Ryzen 7 3700X) so perhaps preset slow only.
I would like to store my BD FHD and UHD as a MKV with a reduced size but keep quality.
Thanks !

[benwaggoner]

Originally Posted by Nico8583

I would keep a good quality, currently I use x264 preset slower CRF 18 but slower is very very slow with x265 (using Ryzen 7 3700X) so perhaps preset slow only.
I would like to store my BD FHD and UHD as a MKV with a reduced size but keep quality.
Thanks !

x265 --preset medium should outperform x264 --preset slower with roughly similar speed. I like slower as it is where a lot of the cool HEVC features kick in, but that's more my personal preference that a requirement .

Of course, going to UHD is ~4x slower, or ~5x slower if you're going from 8-bit to 10-bit. As 4K Blu-ray is already HEVC, the potential file size reduction without quality loss may be less than you expect. Given how cheap HDs are these days, it's generally cheaper to just buy more storage than to reencode. $/TB has dropped below $20, which means cost to store a full BD-50 image is <$1 now. And few titles use close to that much for the actual main title.

...and thinking back to when I paid $5000 for a 4 GB RAID, and couldn't believe how cheap that was.

[excellentswordfight]

Originally Posted by Nico8583

I would keep a good quality, currently I use x264 preset slower CRF 18 but slower is very very slow with x265 (using Ryzen 7 3700X) so perhaps preset slow only.
I would like to store my BD FHD and UHD as a MKV with a reduced size but keep quality.
Thanks !

I would start with something like this.

1080p24 SDR:

--preset slow --profile main10 --level-idc 41 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao --deblock -1:-1

+ flags, e.g.:

 --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited

2160p24 HDR10:

--preset slow --profile main10 --level-idc 51 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao --deblock -1:-1 --hdr-opt

+ flags, e.g.:

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display"G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

SDR/HDR/Resolution can effect perceived quality @ given crf value a bit differently so you will probably have to play with that a bit. If you are more in to trying to keep video as lossless as possible you might wanna use aq-mode 1 instead of the default mode (2) as well. Going up to 8 bframes could be an good option as well, doesnt have much drawbacks and a few titles might enjoy it.

Not everyone is into specifying the level (i.e. --level-idc 41), but by doing so you are enforcing the vbv limits compliant to that level (i.e. the subject of this thread). And by doing so your encodes are much less prone to bitrate spikes that can cause playback issues down the line (network playback or some hw-playbackdevice etc). High tier for 4.1 and 5.1 is high enough either way to not interfere with encode quality that much.

There are ofc a lot of other tweaks that can be done, you will find command lines here that has a lot of amazing tuning. But do note that a lot of them might not be fire and forget parameters and might need title per title tuning. I find that most of the generic type settings are included in the presets, and when you tune speed/compression you can follow the settings in the presets.

[Boulder]

That combination is a very solid starting point for any encode. I'd like to add --rskip 2, possibly also --rskip-edge-threshold 2. At least use rskip mode 2, it seems to help reduce the amount of "onion artifacts".

[Nico8583]

Thanks all
I'll look at it, perhaps I'll make remux only then I'll encode, I don't know. I will look at quality, speed and size after an encode. If you have some others advices about parameters or recommended tweaks I'm interested. Thanks !

[Nico8583]

And just another question : what is the best solution to decode/encode ? AviSynth or VapourSynth with a plugin FFMS2 or L-SMASH + x265 ? Or FFmpeg as frameserver + encoder ? Thanks !

[Boulder]

If you have a recent enough NVidia graphics card, DGIndexNV/DGSource is the recommended combination. It's frame accurate and a very stable and capable decoder for AVC and HEVC video. Avisynth is probably the easiest to set up. Otherwise it depends on whether you just decode and feed data to the encoder, or if you resize, filter etc.

[Nico8583]

Thanks, I don't have a nVidia graphic card, just an embedded Intel card.
And yes I just want to feed data to the encoder, no filter.