x265 HEVC Encoder

[Ajvar]

We found that restricting --merange to a value below 57 did not improve speed, but slightly reduced efficiency.

Speaking about I read on x265 site (http://x265.readthedocs.org/en/latest/cli.html) that 57 was due to 64-4-2 and then inus one extra pixel just in case the hex search method is used. Considering that user doubtfully with preset placebo and very slow will use HEX search method you could set 58 merange.
Also I manually set 58 for every encoding with star method, not sure if it gives any noticeable difference in efficiency.

[jlpsvk]

@Stax76
In latest beta, rdoq-level is forced to 0 even if I set the preset to SLOW (on which the default is 2). Bug or feature?

[RBX]

Is something wrong with rdoq setting? I've been using 1.5.27 with settings crf 18, preset slow, deblock -1, psy-rd 0.4, rc-lookahead 32 for some 720p vidoes on my laptop (i7 2630QM) and I used to get around 40% reduction in size at almost same visual quality as source.
Today I downloaded 1.5.245 and tried encoding a similar video with length 22m45s @575MB and noticed around 2h increase in estimated time required, and then saw param rdoq set to 2. I let the video be encoded hoping better compression, and 5.5 hours later the resultant file's size is around 3x the source's size @1.54GB. Moreover, the length was reduced to 8m9s (maybe I ran out of space in drive C).

Edit: I couldn't find an older version, so I encoded the same video using 1.5.27 16bpp vesion I had, and the same settings produced a file of size 286MB. So what does this --rdoq-level setting do to cause such huge differences in file size?

[stax76]

@Stax76
In latest beta, rdoq-level is forced to 0 even if I set the preset to SLOW (on which the default is 2). Bug or feature?

Maybe there is a bug, here it looks like this:

http://oi57.tinypic.com/szu4qx.jpg

[Ma]

I've made comparison between current x265 16bpp on stable (1.5+17) and on default (1.5+258) branch. Presets from fast to placebo, test file 720p50_parkrun_ter.y4m.

x265 --preset fast --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rd=2 psy-rd=0.30 deblock sao signhide fast-intra tmvp
encoded 504 frames in 32.04s (15.73 fps), 19217.34 kb/s
default 1.5+258
x265 [info]: tools: rd=2 rdoq=0 psy-rd=0.30 deblock sao signhide fast-intra tmvp
encoded 504 frames in 32.59s (15.47 fps), 19208.64 kb/s

x265 --preset medium --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rd=3 psy-rd=0.30 deblock sao signhide tmvp
encoded 504 frames in 51.48s (9.79 fps), 21811.92 kb/s
default 1.5+258
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp
encoded 504 frames in 52.18s (9.66 fps), 21806.25 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
encoded 504 frames in 147.72s (3.41 fps), 24253.88 kb/s
default 1.5+258
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
encoded 504 frames in 146.68s (3.44 fps), 24243.95 kb/s

x265 --preset slower --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 616.85s (0.82 fps), 21859.22 kb/s
default 1.5+258
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 615.08s (0.82 fps), 21760.06 kb/s

x265 --preset veryslow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 924.14s (0.55 fps), 21951.46 kb/s
default 1.5+277
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 954.37s (0.53 fps), 21952.69 kb/s

x265 --preset placebo --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp tskip
encoded 504 frames in 1329.03s (0.38 fps), 22108.24 kb/s
default 1.5+277
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp tskip
encoded 504 frames in 1440.43s (0.35 fps), 22103.18 kb/s

If someone wants to choose preset that gives smallest output file with crf 18 (for example), preset slow is the worst. It is better to use preset medium or slower.

[jlpsvk]

Maybe there is a bug, here it looks like this

After I have upgraded to the new version, I had my own preset created with preset SLOW and new version automatically adds "rdoq-level 0" to command line even with preset SLOW selected. :(

[LigH]

Another "weekly" again: x265 1.5+258-6461985f33ac (https://www.mediafire.com/download/hhhxruvvefdthn9/x265_1.5+258-6461985f33ac.7z)

[sborho]

about 32bit 16bpp builds:

x265 has tried to prevent this build option outright in the cmake configs for more than a year now because it is too easy to hit memory address-space limits at slower presets and large resolutions. Disabling assembly with this build option was a way to limit having to test and maintain assembly code for an unsupported build option. We still strongly recommend against 32bit 16bpp builds.

about rdoq-level:

Before introducing --rdoq-level, --rd-level 4, 5, or 6 implied what is now --rdoq-level 2. After --rdoq-level, it's enablement is independent of --rd-level but the presets which used to enable it (>= slow) still do. --rdoq-level 1 is actually the same as --rdoq-level 2 except for two short-cuts which prevent certain decimations, which means --rdoq-level 2 can often reduce bitrate quite a bit more than --rdoq-level 1, but --rdoq-level 1 will generally be better at preserving fine detail at the same bitrate (particularly when psy-rdoq is enabled).

[hector1980]

hi
what is the best app for encoding to hevc x265 with advanced settings?

[Ma]

I couldn't find an older version, so I encoded the same video using 1.5.27 16bpp vesion I had, and the same settings produced a file of size 286MB. So what does this --rdoq-level setting do to cause such huge differences in file size?

Yes, numbers:

x265 --preset slow --crf 18 --no-rdoq-level 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 126.42s (3.99 fps), 21445.36 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 148.96s (3.38 fps), 24243.95 kb/s

x265 --preset slow --crf 18 --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 143.56s (3.51 fps), 25158.41 kb/s

[stax76]

After I have upgraded to the new version, I had my own preset created with preset SLOW and new version automatically adds "rdoq-level 0" to command line even with preset SLOW selected. :(

It's a update/init issue requiring a deeper look in my design, the preset and tuning feature adds complexity, for now you have to update your profiles, projects and templates manually, you can reset x265 options to their defaults by double-clicking the label.

[LigH]

hi
what is the best app for encoding to hevc x265 with advanced settings?

A console. At least for me. I prefer batch scripting over any mouse-driven GUI. Your preferences may be different. But I don't know yours. What is important for you? By the way, many GUI authors may not yet try to support all advanced x265 options as long as the set of options keeps changing from week to week...

[benwaggoner]

A console. At least for me. I prefer batch scripting over any mouse-driven GUI. Your preferences may be different. But I don't know yours. What is important for you? By the way, many GUI authors may not yet try to support all advanced x265 options as long as the set of options keeps changing from week to week...
I concur. There's never been a GUI that exposed all the parameters I wanted to use at the same time.

[stax76]

Have you tried StaxRip? It exposes over 80 x265 switches and has useful features like a search to quickly navigate to an option or context sensitive help.

[Ma]

hi
what is the best app for encoding to hevc x265 with advanced settings?

MeGUI

[Motenai Yoda]

If someone wants to choose preset that gives smallest output file with crf 18 (for example), preset slow is the worst. It is better to use preset medium or slower.
but slow gives better quality than medium for the same crf or size...

but --rdoq-level 1 will generally be better at preserving fine detail at the same bitrate (particularly when psy-rdoq is enabled).
As I tested, just on 2/3 anime source, -preset medium --rdoq-level 2 --psy-rdoq 1.0, gives comparable output size than w/o rdoq, and, for the same size (about a point smaller crf), even better overall quality.

[LigH]

I concur.

:o Sorry for off-topic; just found another "false friend" for a German (non-native) English speaker:
"concur" [engl.] ~ agree/contribute/cooperate; "Konkurrent" [ger./lat.?] = competitor, business rival :rolleyes:
__

Indeed, stax76 is trying to keep up closely with the x265 development.

[xooyoozoo]

It turned out that to get "generalized P/B frames" (B-frame with both motion vectors pointing in the same direction), you'd only need trivial tweaks to some of x265's conditionals. I thought these results were interesting.

Normal:

x265 --crf 20 --preset veryslow --tune ssim --bframes 3

x265 [debug]: POC:99 P QP 23.27(25) 118048 bits RF:0.250 [SSIM: 16.784dB] [L0 96 94 92 90 88 ]
x265 [debug]: POC:98 B QP 24.38(27) 39832 bits RF:0.250 [SSIM: 16.978dB] [L0 96 94 92 90 86 ] [L1 99 ]
x265 [debug]: POC:97 b QP 25.48(28) 22112 bits RF:0.250 [SSIM: 17.187dB] [L0 96 94 92 90 ] [L1 98 99 ]
x265 [info]: frame I: 1, Avg QP:17.47 kb/s: 51097.60 SSIM Mean: 0.991970 (20.953dB)
x265 [info]: frame P: 25, Avg QP:18.06 kb/s: 20091.48 SSIM Mean: 0.987548 (19.048dB)
x265 [info]: frame B: 74, Avg QP:24.62 kb/s: 1090.81 SSIM Mean: 0.981455 (17.318dB)
x265 [info]: global : 100, Avg QP:22.91 kb/s: 6341.04 SSIM Mean: 0.983084 (17.717dB)

encoded 100 frames in 94.45s (1.06 fps), 6341.04 kb/s, SSIM Mean Y: 0.9830838 (17.717 dB)


GPB:

x265 [debug]: POC:99 P QP 23.27(25) 107656 bits RF:0.250 [SSIM: 16.866dB] [L0 96 94 92 90 88 ] [L1 96 94 ]
x265 [debug]: POC:98 B QP 24.38(27) 39448 bits RF:0.250 [SSIM: 16.997dB] [L0 96 94 92 90 86 ] [L1 99 96 ]
x265 [debug]: POC:97 b QP 25.48(28) 22152 bits RF:0.250 [SSIM: 17.194dB] [L0 96 94 92 90 ] [L1 98 99 ]
x265 [info]: frame I: 1, Avg QP:17.47 kb/s: 51097.60 SSIM Mean: 0.991970 (20.953dB)
x265 [info]: frame P: 25, Avg QP:18.06 kb/s: 19455.58 SSIM Mean: 0.987614 (19.071dB)
x265 [info]: frame B: 74, Avg QP:24.62 kb/s: 1086.37 SSIM Mean: 0.981535 (17.337dB)
x265 [info]: global : 100, Avg QP:22.91 kb/s: 6178.78 SSIM Mean: 0.983159 (17.736dB)

encoded 100 frames in 104.84s (0.95 fps), 6178.78 kb/s, SSIM Mean Y: 0.9831591 (17.736 dB)


Edit: Can't seem to get this working with tune zero latency, but when trying something close with "--bframes 1 --rc-lookahead 2", the results are expectedly better:


Normal:
(1.62 fps), 1779.75 kb/s, SSIM Mean Y: 0.9652713 (14.593 dB)

GPB:
(1.58 fps), 1524.07 kb/s, SSIM Mean Y: 0.9653855 (14.607 dB


Edit 2: Diff (http://pastebin.com/Qk9FCBHZ). Probably breaks in many places, but I won't continue working on it or anything.

[jlpsvk]

@stax76
Thanks for info. :) Anyway... rdoq-level 1 is now my default choice, as it has better fine detail retention at almost same bitrate as rdoq-level 2 (according to few comments here).

My command line currently is:
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --profile main10 --level-idc 4 --deblock -3:-3 --psy-rd 0.5

[RBX]

My command line currently is:
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --profile main10 --level-idc 4 --deblock -3:-3 --psy-rd 0.5

You are using decoder level 4, so I assume you're not encoding SD videos. With 16bpp encoder, does your CPU not get saturated that you require pmode?

----
10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?
Current: crf 20, tune off, preset slow, bframes 3, psy-rd 0.4, deblock -1, rc-lookahead 32
----
I tried encoding a 20 sec 4K video (which took insane amount of time) and got debug level log in following file (csv renamed to txt)
I'd like to learn how to decipher this to be able to choose better option.
Also, the source file plays well but the encoded video plays very poorly (4/8 cores show 100% usage). Do I need to set a lower decoder level for smooth playback?

[benwaggoner]

10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?
--frame-threads 1 will generally fix this. Depending on frame size, cores, and preset, you'll likely need to turn on --pmode to make up for the loss of parallelism.

I tried encoding a 20 sec 4K video (which took insane amount of time) and got debug level log in following file (csv renamed to txt)
I'd like to learn how to decipher this to be able to choose better option.
What sort of improvements are you trying to make? I take the .csv into Excel and do all sorts of parsing, but it's more useful to compare different quality/speed combos and figure out what's happening in particular problem spots.

Also, the source file plays well but the encoded video plays very poorly (4/8 cores show 100% usage). Do I need to set a lower decoder level for smooth playback?
For good software playback

Always use the lowest level compatible with frame size and fps
Only use Main Tier
At the higher presets, turning off b-intra can help with software decoding.
Always set vbv-maxrate and vbv-bufsize to legal values. The legal maximums in HEVC for Main Tier are quite a bit lower than for H.264 for the same frame size and fps; 25000 for Level 5.0.
ALWAYS use WPP (which is on by default)
8-bit will be at least a little faster to decode than 16-bit
Software decoders vary a lot in how well they perform, so you might get dramatically different results with different ones.
All that said, I've never seen smooth 2160p24 playback in software using just a 4 core system. My 16 core Ivy Bridge can do it, but my 12-core Sandy Bridge couldn't (at least with decoders of a few months ago)

[RBX]

What sort of improvements are you trying to make?

I'm trying to see if the settings I'm using are actually doing any good or am I just wasting computation power. A few pages back I saw a post which described how using more B-frames was just a waste, I'm interested in more stats like that so than I can make my own optimal presets.


For good software playback

Always use the lowest level compatible with frame size and fps
Always set vbv-maxrate and vbv-bufsize to legal values. The legal maximums in HEVC for Main Tier are quite a bit lower than for H.264 for the same frame size and fps; 25000 for Level 5.0.
Software decoders vary a lot in how well they perform, so you might get dramatically different results with different ones.
All that said, I've never seen smooth 2160p24 playback in software using just a 4 core system. My 16 core Ivy Bridge can do it, but my 12-core Sandy Bridge couldn't (at least with decoders of a few months ago)

So setting decoder level selection to auto won't select the lowest level possible, and I'll have to select it manually?
Also, you're talking here about just HEVC playback, right? The ones from youtube play very smoothly. The one I encoded with x265 wasn't doing well with Potplayer's default decoder, but selecting LAV helped a bit.

[jlpsvk]

I started to get error writing frame 0 with x265? Anybody help? Build 1.5.258 by LigH.

EDIT: I realised, that the cause was THREADS parameter. Interference with PMODE or FRAME-THREADS?

[LigH]

The former "--threads" parameter is now "--pools", which also supports NUMA thread pools (e.g. dual-socket mainboards, and even more distant CPUs).

[Ajvar]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
Level 2 is like disabled ambient occlusion and made brighter. Level 1 gives less banding/blocking, colors fit original more. Same bitrate on 720p, crf18.5, vbv-max 4000, preset slower by x265 8bpp.1.5+277-74496ce5d8ba [GCC 4.9.2][64 bit].
http://screenshotcomparison.com/comparison/116818
Original frame http://i.imgur.com/vvuEa4r.png

[sneaker_ger]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
I think it already is the default? At least it seemed to be when I tested it the other day.

Level 2 is like disabled ambient occlusionand made brighter. Level 1 gives less banding, colors fit original more.
You are probably doing something wrong, I don't think it will affect colors that badly. This might also give a false impression of increased banding. (And your source has a lot to begin with)

[Ma]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
Level 2 is like disabled ambient occlusionand made brighter. Level 1 gives less banding, colors fit original more. Same bitrate on 720p, crf18.5, vbv-max 4000, preset slower by x265 8bpp.1.5+277-74496ce5d8ba [GCC 4.9.2][64 bit].
http://screenshotcomparison.com/comparison/116818
Original frame http://i.imgur.com/vvuEa4r.png

Yes, impressive. Next movie I will definitely encode with --rdoq-level 1.

[Ajvar]

Yes, impressive. Next movie I will definitely encode with --rdoq-level 1.

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.
Links for encoded files:
http://www.ex.ua/load/156547833?fs_id=131
http://www.ex.ua/load/156555041?fs_id=131
Don't forget that I chose CRF18.5 but with a vbv limit of 4000kbps at preset slower!

[RBX]

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.

In my tests with 1.5.258 8bpp, rdoq level 1 files had more detail retention, slightly higher PSNR, and around 10% higher bitrate than rdoq level 2 files.
http://screenshotcomparison.com/comparison/116970
(The difference is much clearer with BMP screenshots, but I currently don't have access to a good connection)

[jlpsvk]

I got impressive results with RDOQ LEVEL 1. Much better fine details. Using StarRip 1.2.0.5 with DirectShow source using LAV Filters 0.64.0.11, pure CPU based, not touching rgb output levels. :)

[benwaggoner]

I'm trying to see if the settings I'm using are actually doing any good or am I just wasting computation power. A few pages back I saw a post which described how using more B-frames was just a waste, I'm interested in more stats like that so than I can make my own optimal presets.
You can turn --psnr and --ssim on so those get logged per frame, and see if you get significant differentials between those anywhere. Those aren't linear to perceptual quality by any means, but typically a P-frame with worse PSNR and SSIM is going to also look worse if all the perceptual settings are the same. But comparing the same frame number where different frame types got chosen is a whole lot harder. So comparing --slow and --slower where B-frames goes from 4 to 8 is going to be hard to do from a log file.

In the end, quantitative metrics are interesting and somewhat helpful, but in the end it all gets down to eyeballs. I mostly find it useful when I've already found a quality delta and what to see what was going on with the frames during that section.

So setting decoder level selection to auto won't select the lowest level possible, and I'll have to select it manually?
I believe if you do something like --preset veryslow that raises the ref count to 5, you'll automatically get bumped up to the level that allows that if you haven't specified a level. If you do specify a level, it'll reduce refs to the maximum legal value. x265generally gets it right, but not always, so if you need an explicit level, set it.

Also, you're talking here about just HEVC playback, right? The ones from youtube play very smoothly. The one I encoded with x265 wasn't doing well with Potplayer's default decoder, but selecting LAV helped a bit.
I'm just talking HEVC encoded with x265. H.264 normally gets a HW accelerated decode these days. And VP9 doesn't have levels, or equivalent knobs to tune perf while maintaining compatiblity with existing players.

[Ma]

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.
Links for encoded files:
http://www.ex.ua/load/156547833?fs_id=131
http://www.ex.ua/load/156555041?fs_id=131
Don't forget that I chose CRF18.5 but with a vbv limit of 4000kbps at preset slower!

It is too late, I just started encoding new movie with settings:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 @ 10-bit output

Besides I can't download your samples.

[jlpsvk]

Why you are encoding at CRF 17-18.5? I see CRF 20 sufficient? Any reason?

[Ajvar]

It is too late, I just started encoding new movie with settings:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 @ 10-bit output

Besides I can't download your samples.

Well, unless you limit bitrate buffer to some low values, your video will be really better with level 1 and keep more fine detail. So it is even good as people above mentioned.

[zerowalker]

In my tests with 1.5.258 8bpp, rdoq level 1 files had more detail retention, slightly higher PSNR, and around 10% higher bitrate than rdoq level 2 files.
http://screenshotcomparison.com/comparison/116970
(The difference is much clearer with BMP screenshots, but I currently don't have access to a good connection)

My i ask, why not .png? (as i am guessing you did jpeg), png == bmp.

[LigH]

JPEG has lossy compression.

PNG has lossless compression.

BMP has no compression at all for RGB24, and is not even a web standard (web browsers are not expected to support it at all).

[Motenai Yoda]

If you do specify a level, it'll reduce refs to the maximum legal value. x265 generally gets it right, but not always, so if you need an explicit level, set it.
I would like to see the same thing for vbv maxrate and buffer, setted according to the tier/level specified or automatically chosen.

[Ma]

Why you are encoding at CRF 17-18.5? I see CRF 20 sufficient? Any reason?

For me CRF 17 isn't sufficient, but lower CRF gives very small quality boost and big increase of output file size. So most people here are seeking option to boost visual quality (especially for human faces and skin) without insane encoded size.

For me acceptable size for normal movies is 8 GB and for good movies -- 16 GB.

Projected file size of video part for my current encoding is 6.23 GB.

[RBX]

My i ask, why not .png? (as i am guessing you did jpeg), png == bmp.
No, they are PNG. I was able to see more detail in BMP screenshots. Maybe Potplayer doesn't capture source frame correctly, or does lossy compression on PNG, or maybe I just captured screen frame (processed by MadVR) instead of source frame in BMP.

[jlpsvk]

For me CRF 17 isn't sufficient, but lower CRF gives very small quality boost and big increase of output file size. So most people here are seeking option to boost visual quality (especially for human faces and skin) without insane encoded size.

For me acceptable size for normal movies is 8 GB and for good movies -- 16 GB.

Projected file size of video part for my current encoding is 6.23 GB.

What screen are you using? And what x265? Are you using 8bit or 10bit? On 10bit there's no problem with the banding and color gradients. On CRF20, I am getting half of bitrate of x264 and the picture looks better to me with x265. Why to use x265, whe you are using same bitrates as on x264?

[jlpsvk]

@Stax76
Hi Stax. Thanks for your great work. But I noticed, that you still missed the "--threads" parameter. It does not exist in x265 anymore. Instead of that there is "--pools".

[Selur]

that's because the x265 folks removed '--threads'

[jlpsvk]

x265 still not using 100% of my CPU. Even with --pmode, -pools 12 CPU runs only at around 90%.

[LigH]

No shit, Sherlock. On a Dual Xeon (2×12 cores with HT) it didn't even reach 50%... Maybe it just doesn't use more threads than it can handle for the given video frame dimensions?

[x265_Project]

No shit, Sherlock. On a Dual Xeon (2×12 cores with HT) it didn't even reach 50%... Maybe it just doesn't use more threads than it can handle for the given video frame dimensions?

Easy guys... let's stick to the facts, and see what's happening. We'll let you know whether your CPU utilization numbers are expected, or not. jlpsvk, can you share your full command line?

[LigH]

^ possibly plus the x265 info console output before the encode starts.

[Ma]

I've noticed that headers in output HEVC files for:
x265 --preset slower --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
and
x265 --preset slower --rdoq-level 2 720p50_parkrun_ter.y4m 720p50_parkrun_ter2.hevc
are the same (1.5+363). The "rdoq-level" info is missing from header.

[Ma]

What screen are you using?

Eizo SX2262W (with 8-bit video card).

And what x265? Are you using 8bit or 10bit? On 10bit there's no problem with the banding and color gradients.

I'm using 10bit x265. Confirmed, color gradients are OK with 10bit encoding.

On CRF20, I am getting half of bitrate of x264 and the picture looks better to me with x265. Why to use x265, whe you are using same bitrates as on x264?

My bitrates with x265 encoding are also smaller that my x264 bitrates.

Some time ago I encoded movie "The Sessions", 2012. 10bit x265, preset slower, crf 18, it was 1.4+222 or older version of x265. At 11:50 time in this movie is scene when Mark told "I love you" to Amanda and there is important Amanda reaction -- only face (without words). It was epic fail with x265 encoding, the face was looking unnatural (plastic look, too much blur). It ruined whole movie. So I've changed x265 settings to crf 17, psy-rd=0.60, psy-rdoq=1.00 and re-encoded this movie. From this trauma I've never used crf 18 for my encodings.

[jlpsvk]

@LigH and @x265_Project
------------------------------------------------------------
x265
------------------------------------------------------------

"C:\StaxRip\Applications\avs4x26x\avs4x26x.exe" --x26x-binary "C:\StaxRip\Applications\x265\64-Bit 10-Bit\x265.exe" --crf 20
--preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1
--pools 12 --input-res 1920x784 --fps 23.976000 --output "D:\movie_encode_out.hevc" "D:\movie_encode.avs"

yuv [info]: 1920x784 fps 23976/1000 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.5+258-6461985f33ac
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 1 / wpp(13 rows)+pmode
x265 [info]: Internal bit depth : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=1 psy-rd=0.50 psy-rdoq=1.00 deblock(tC=-3:B=-3) sao signhide tmvp

Obviously....threads are still at 8, even if pools is set to 12. --pmode is helping to get another 2-4% from CPU.

@Ma
Try to encode that scene with 10-bit x265 with this command line and let me know. I'm curious. Use x265 1.5.258 or higher. :)
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1

[xooyoozoo]

I'm not sure if you're trying to ask about low CPU usage, but `--frame-threads 1` is almost certainly why.