x265 HEVC Encoder

[mandarinka]

Those are the fast and faster+ presets, I assume?

Originally Posted by mandarinka

Those are the fast and faster+ presets, I assume?

For 4K encoding on a quad-core desktop, we see a memory bandwidth bottleneck on Haswell processors with our fastest presets (ultrafast, superfast). Under this condition, Skylake can outperform Haswell by more than 2x.

[mandarinka]

I guess that makes sense. My "10%" (with older versions of x265 though) figure was for normal slow encoding where stuff is just CPU execution-bound. Since that is what matters to me...

[gamebox]

@brumsky:
Yesterday I've decided to put --ctu 32 back to use again, at least for SD. Quantizers did increase slightly (when comparing stats files), but I started having issues with 64x64 blocks containing letters or anything sharp - they leave big areas, often geometrically shaped (square), filled with mosquito noise. Apart from that, areas with less details (like human skin) get encoded with rather obvious alternating smooth (big) and sharp (smaller) blocks - though that difference in sharpness could be AQ-related as well. CTUs of 32 helped me a lot with parallelism and saturated all my 8 cores, so 2hrs long 480p video gets encoded with 3.5-4 fps instead of 2 fps.

I'll follow your advice and test --early-skip again in some time. I did most of my image quality tests "the fast and dirty way" - i.e. setting bitrate in 2-pass mode, doing full fast first pass on both videos, and encoding just a hundred or so frames in second passes, so I get some material for comparison as soon as possible. I expect more "final" and "trusty" results by comparing in CRF mode.

[brumsky]

@x265_project:

Can you go into more detail regarding --early-skip and how it interacts with rect and amp, if at all?

I'd like to know if my logic below is applicable or not...

Originally Posted by brumsky

--tu-inter-depth adds a descent amount of encoding time. Also, I'd suggest allowing rskip. You get better grain retention with psy-rd settings compared to most other changes. I'd suggest increasing psy-rd and psy-rdoq levels.

On another note:

I've been toying with --early-skip --limit-modes and --rect --amp. If I'm reading the x265 docs correctly, early skip only kicks in when no motion or not enough motion is detected. Once it detects enough motion it processes normally. I added rect and only noticed about a .5 fps decrease, rect + amp sees a total decrease of about 1.5 fps when early-skip and limit-modes are used together.

The idea being use early skip so you don't waste time when there isn't enough or no motion at all. Then allow the encoder to spend more time when motion is detected by using rect and/or amp.

Also, note that rect implies an additional tu-inter-depth automatically. I believe that means using --tu-inter-depth 1 with early-skip will prevent a lot of wasted time when no motion is detected. Then when motion is detected, rect kicks in and gives you an effective --tu-inter-depth 2 only in the spots that need it. Limit-modes just allows rect and amp to be more selective in its tests.

Here are my current settings.

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
 --limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4  --tu-intra-depth 3
 --tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[benwaggoner]

Originally Posted by brumsky

@x265_project:

Can you go into more detail regarding --early-skip and how it interacts with rect and amp, if at all?

I'd like to know if my logic below is applicable or not...

In general, features in the presets are turned on based on whether their quality/performance is right for a given speed/quality tradeoff, based on a whole lot of automated testing. In general it probably makes sense to follow those ladders when tuning in speed/quality. For example, some of the skip modes are turned off at pretty fast presets (quality hit is big relative to speed increase) and others only at the slowest presets (smaller quality gain relative to larger performance hit).

[benwaggoner]

Originally Posted by gamebox

@brumsky:
Yesterday I've decided to put --ctu 32 back to use again, at least for SD. Quantizers did increase slightly (when comparing stats files), but I started having issues with 64x64 blocks containing letters or anything sharp - they leave big areas, often geometrically shaped (square), filled with mosquito noise. Apart from that, areas with less details (like human skin) get encoded with rather obvious alternating smooth (big) and sharp (smaller) blocks - though that difference in sharpness could be AQ-related as well. CTUs of 32 helped me a lot with parallelism and saturated all my 8 cores, so 2hrs long 480p video gets encoded with 3.5-4 fps instead of 2 fps.

I'll follow your advice and test --early-skip again in some time. I did most of my image quality tests "the fast and dirty way" - i.e. setting bitrate in 2-pass mode, doing full fast first pass on both videos, and encoding just a hundred or so frames in second passes, so I get some material for comparison as soon as possible. I expect more "final" and "trusty" results by comparing in CRF mode.

What's your full command line? Are you using --qg-size? Did you increment the --tu-*-depth values by one? If you increase CU size, you'll need to correspondingly increase depth to make sure your minimum block size remains the same. That can help a lot in getting high detail regions to use smaller blocks.

With the new improved --rskip, the performance isn't as bad when doing my tu depth, and the results are a lot better.

[brumsky]

Hey Ben,

Thanks for the quick reply. Since I am running an old sandy bridge CPU I'm just trying to find the best balance between speed and quality. I guess I'm hoping that early skip is only used when no motion or very little motion is detected vs the majority of the time. If so areas that aren't in motion wouldn't be worth the encoding time.

Originally Posted by benwaggoner

In general, features in the presets are turned on based on whether their quality/performance is right for a given speed/quality tradeoff, based on a whole lot of automated testing. In general it probably makes sense to follow those ladders when tuning in speed/quality. For example, some of the skip modes are turned off at pretty fast presets (quality hit is big relative to speed increase) and others only at the slowest presets (smaller quality gain relative to larger performance hit).

[brumsky]

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
 --limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4  --tu-intra-depth 3
 --tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[gamebox]

@benwaggoner

I encode using "Simple x264 Launcher" by Mulder. 64-bit 8-bit encoder, slower preset, and this commandline (some switches are redundant):

--rd 6 --no-weightb --ref 6 --me star --subme 7 --merange 24 --b-intra --keyint 300 --min-keyint 50 --bframes 9 --aq-mode 2 --psy-rd 2.0 --psy-rdoq 1.0 --deblock=-2 --no-cutree --limit-refs 3 --limit-modes --rect --no-amp --aq-strength 2 --no-sao --no-strong-intra-smoothing --max-merge 2 --no-rskip --no-slow-firstpass --tu-inter-depth 3 --tu-intra-depth 3

I eliminated qg-size switch, as I wanted the encoder to alter quantizers in all types of blocks. Areas with background scenery are not that important in this case - in a typical Hollywood movie, or a documentary, background/static blocks would matter and I would use --cutree, and probably --qg-size 16 too. My previous encodes (if I remember well) were at tu-intra/inter-depth 2, enforced by preset.

[burfadel]

Don't forget to try:
--ipratio 1.38
--pbratio 1.28

Since you are using --rd 6, also try --rd-refine

I think to make rd 5/6 worth it you need to combine it with --rd-refine.

[youli]

x265 log:

x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut       : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 0 / 0
x265 [info]: References / ref-limit  cu / depth  : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init    : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=2.50 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I:   2296, Avg QP:22.68  kb/s: 36715.43
x265 [info]: frame P:  45621, Avg QP:23.68  kb/s: 26433.02
x265 [info]: frame B: 170292, Avg QP:24.34  kb/s: 17242.93
x265 [info]: consecutive B-frames: 13.7% 5.6% 5.6% 23.9% 9.6% 21.4% 20.2%

encoded 218209 frames in 111542.06s (1.96 fps), 19369.20 kb/s, Avg QP:24.19
Encoding finished 10.08.2016 21:08:00,73

Settings:

--crf 23 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40
--aq-mode 3 --aq-strength 0.5 --no-sao --no-deblock --rd 3 --psy-rd 1.5 
--b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25 
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 
--lookahead-slices 6 --qpstep 1 --no-strong-intra-smoothing --no-rskip

Source BD3D (left view) and x265 OverUnder:

[RainyDog]

Originally Posted by youli

--crf 23 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40
--aq-mode 3 --aq-strength 0.5 --no-sao --no-deblock --rd 3 --psy-rd 1.5 
--b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25 
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 
--lookahead-slices 6 --qpstep 1 --no-strong-intra-smoothing --no-rskip

Impressive results based on the comparisons. I usually encode at CRF 23 with qcomp 0.8 too as I find that higher CRF values (22-25) combined with higher qcomp gives better results than lower CRF (say 19-22) and qcomp 0.6 with most content.

But note that --psy-rdoq doesn't work with --rd 3. You need RD level 4 and above for psy rdoq to kick in.

[burfadel]

I believe changing the ipratio and bpratio too much isn't really beneficial when using CRF mode. That's why I recommended 1.28 and 1.38 respectively as the results were seemingly 'better' (cautiiously using that word on here!), however choosing anything much lower than that actually made things worse. Because it does affect everything in the encode, the small changes of 0.02 do make a difference.

[RainyDog]

Originally Posted by brumsky

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
 --limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4  --tu-intra-depth 3
 --tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

Increase CRF. Not all content needs the same CRF value for 'equal' quality, far from it.

I'm not afraid to go up to CRF 25 or even 26 for extremely grainy content, though this is with qcomp 0.8 so in your case probably 23 or 24 at default qcomp. But even then you'll still end up with overall bitrates of 6-7mbps on occasions unless you do some pre denoising. Though personally I've always found the results of denoising undesirable whenever I've tried it, be it externally or just using x264/5's built in --nr commands.

What I do is test a couple of 5 min segments from each film first to find the suitable CRF value. Which can be anywhere from CRF 20-22 for bitrates of 2-3mbps or CRF 25-26 for bitrates of up to 6-7mbps. The average target I'm happy with is CRF 23 with qcomp 0.8 at about 4mbps so that's where I always start. If tests come in around that then away we go with the full encode. But if CRF 23 is giving me too low (say 1-1.5mbps or less) or too high (7mbps+) a bitrate then I'll adjust along the CRF scale from there.

Is obviously more effort and time but worth it for me. I also quite enjoy doing it too so...

[youli]

Originally Posted by RainyDog

But note that --psy-rdoq doesn't work with --rd 3. You need RD level 4 and above for psy rdoq to kick in.

I'm not sure...

--rd 3 and above need for work --psy-rd (http://x265.readthedocs.io/en/defaul...option--psy-rd)

and

--rdoq-level is 1 or 2 need for work --psy-rdoq (http://x265.readthedocs.io/en/defaul...tion--psy-rdoq)

I think rd and rdoq are independent methods. Or not?

[youli]

Source BD3D (left view) and x265 OverUnder:







Settings: same as my sample above, just --psy-rdoq up from 2.5 to 3.0.

x265 log:

x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: Specifying a decoder level with constant rate factor rate-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut       : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 0 / 0
x265 [info]: References / ref-limit  cu / depth  : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init    : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=3.00 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I:   1478, Avg QP:22.63  kb/s: 46945.52
x265 [info]: frame P:  26825, Avg QP:23.66  kb/s: 23953.38
x265 [info]: frame B:  89359, Avg QP:24.56  kb/s: 11553.90
x265 [info]: consecutive B-frames: 13.5% 4.1% 8.4% 35.4% 11.0% 20.4% 7.0%

encoded 117662 frames in 47406.91s (2.48 fps), 14825.35 kb/s, Avg QP:24.33
Encoding finished 11.08.2016 11:29:31,81

[brumsky]

Originally Posted by youli

Source BD3D (left view) and x265 OverUnder:







Settings: same as my sample above, just --psy-rdoq up from 2.5 to 3.0.

x265 log:

x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: Specifying a decoder level with constant rate factor rate-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut       : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 0 / 0
x265 [info]: References / ref-limit  cu / depth  : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init    : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=3.00 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I:   1478, Avg QP:22.63  kb/s: 46945.52
x265 [info]: frame P:  26825, Avg QP:23.66  kb/s: 23953.38
x265 [info]: frame B:  89359, Avg QP:24.56  kb/s: 11553.90
x265 [info]: consecutive B-frames: 13.5% 4.1% 8.4% 35.4% 11.0% 20.4% 7.0%

encoded 117662 frames in 47406.91s (2.48 fps), 14825.35 kb/s, Avg QP:24.33
Encoding finished 11.08.2016 11:29:31,81

What's the point of using VBV with such high values? With a value of 100000 Kbps it'll almost never kick in. Plus when it does it using an extreme denoise to bring the bitrate down and blurs the shit out of it. I tried this with several test clips, it looks like shit when it kicks in. My VBV value was significantly less then yours on purpose, 4096 - 4608. My test clips are intentional noisy.

Your encodes are not even coming close to the limit you have set.

They do look great by the way!

Also, do you think subme 7 is necessary? the Placebo preset only goes up to 5. I've also read that me-range star is optimized more than umh...

[brumsky]

Originally Posted by RainyDog

Increase CRF. Not all content needs the same CRF value for 'equal' quality, far from it.

I'm not afraid to go up to CRF 25 or even 26 for extremely grainy content, though this is with qcomp 0.8 so in your case probably 23 or 24 at default qcomp. But even then you'll still end up with overall bitrates of 6-7mbps on occasions unless you do some pre denoising. Though personally I've always found the results of denoising undesirable whenever I've tried it, be it externally or just using x264/5's built in --nr commands.

What I do is test a couple of 5 min segments from each film first to find the suitable CRF value. Which can be anywhere from CRF 20-22 for bitrates of 2-3mbps or CRF 25-26 for bitrates of up to 6-7mbps. The average target I'm happy with is CRF 23 with qcomp 0.8 at about 4mbps so that's where I always start. If tests come in around that then away we go with the full encode. But if CRF 23 is giving me too low (say 1-1.5mbps or less) or too high (7mbps+) a bitrate then I'll adjust along the CRF scale from there.

Is obviously more effort and time but worth it for me. I also quite enjoy doing it too so...

Thanks Rainydog, that's what I've been doing. Just thought there might be another way.

I did mess with VBV and the results look like shit. Seriously, blurry and very ugly! I'd much rather let the bitrate spike then enable VBV haha!

[RainyDog]

Originally Posted by youli

I'm not sure...

--rd 3 and above need for work --psy-rd (http://x265.readthedocs.io/en/defaul...option--psy-rd)

and

--rdoq-level is 1 or 2 need for work --psy-rdoq (http://x265.readthedocs.io/en/defaul...tion--psy-rdoq)

I think rd and rdoq are independent methods. Or not?

Sorry, I wasn't entirely clear. It's RD=4 or above that you need to set for --psy-rdoq to be active. At RD=3 or below psy-rdoq is disabled even if you set a value for it.