x265 HEVC Encoder

[Vesdaris]

After several tests I managed to approach the x264.
To do that I use medium profile I change ctu = 16 psy-rd = 1.00 rdoq-level = 2 psy-rdoq = 1.10.



What about CRF?

[LigH]

CRF limits the quality loss. The smaller rate factor, the less loss, the bigger the result. Find your own personal threshold of "visual transparency" (how much loss you find hardly noticable).

[luigizaninoni]

I also found adding --early-skip gave noticeably better performance without a quality or file size hit (or so fractionally slight the speed gain far outweighed any 'loss').

Basically --qg-size 16 is a must, and I believe --aq-mode 3 is as well :).

I tried your suggestions of early-skip and aq-mode 3.

I really like early-skip a lot, speed increase is incredible (about + 60%) and quality loss is minimal.

As far as aq-mode 3 is concerned, I don't know ... it increased bitrate by 25%, admittedly on a darkish clip. You probably could just bump down crf a notch or two and obtain similar results.

[Blowis]

what about crf?

I used CRF 21-22 or 23. For more visual detail is not the largest on the X265.

[Vesdaris]

OK..I've been testing for some time different settings encodign a small sample file. ..
x264 (4380 Kbps) crf18,10bit,very slow
cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / vbv_maxrate=150000 / vbv_bufsize=187500 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=2:1.00

x265 (2933 Kbps) crf 20, 10bit, medium, tune=grain, rdoq-level=2, psy-rdoq=1.00
wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=6 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=0 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=0.30 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.50 / rdoq-level=2 / psy-rdoq=1.00 / signhide / deblock=-2:-2 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.80 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.10 / pbratio=1.10


http://screenshotcomparison.com/comparison/153828

It's almost identical. x265 lacks a tiny bit of details here and there but it seems it's really close and encoding speed was nice.

I could prolly increase psy-rd a bit.or maybe change something else...What do you think?

[Blowis]

OK..I've been testing for some time different settings encodign a small sample file. ..
x264 (4380 Kbps) crf18,10bit,very slow


x265 (2933 Kbps) crf 20, 10bit, medium, tune=grain, rdoq-level=2, psy-rdoq=1.00



http://screenshotcomparison.com/comparison/153828

It's almost identical. x265 lacks a tiny bit of details here and there but it seems it's really close and encoding speed was nice.

I could prolly increase psy-rd a bit.or maybe change something else...What do you think?

Use ctu = 16 after increasing the psy-rd = 1.00 and = 1.10 psy-rdoq and also try aq-mode = 2. Especially increases psy-rd and psy-rdoq to sharpen the image
Here are but setting after several tries optimal and fast Profile Medium:

wpp / ctu=16 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=2 / merange=32 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=5 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=1 / no-limit-modes / weightp / weightb / aq-mode=2 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=1.00 / rdoq-level=2 / psy-rdoq=1.10 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

On my i7 4774k@4.3Ghz i am between 12.25 to 14.45 fps according to the video.
For a video of 1 hour 40 1080p encoding lasts 3 hours 30.

[Vesdaris]

I'm getting insta crash if I use anything past this (ur settings)

--wpp --ctu=16 --min-cu-size=8 --max-tu-size=16 --tu-intra-depth=3 --tu-inter-depth=3 --me=3 --subme=2 --merange=32 --no-rect --no-amp --max-merge=2 --temporal-mvp --early-skip --rdpenalty=0 --no-tskip --no-tskip-fast --strong-intra-smoothing --no-lossless --no-cu-lossless --no-constrained-intra --no-fast-intra --open-gop --no-temporal-layers --interlace=0 --keyint=240 --min-keyint=23 --scenecut=40 --rc-lookahead=20 --lookahead-slices=5 --bframes=4 --bframe-bias=0 --b-adapt=2 --ref=3 --limit-refs=1

I guess I'm doing something wrong lol

[burfadel]

I tried your suggestions of early-skip and aq-mode 3.

I really like early-skip a lot, speed increase is incredible (about + 60%) and quality loss is minimal.

As far as aq-mode 3 is concerned, I don't know ... it increased bitrate by 25%, admittedly on a darkish clip. You probably could just bump down crf a notch or two and obtain similar results.

Yeah. The quality difference was imperceptible for me, it really only shows if doing a SSIM and PSNR comparison. You can make up and surpass the quality drop by using better settings elsewhere without losing too much of that gain. By using early skip, I also believe the speed penalty of some other settings is minimised, making them viable to use.

Why isn't. --b--intra on by default? What disadvantages are there using --me star seeing as it is so fast?

In any case, when all the settings I use are taken into account, for me at least it is the most suitable outcome speed and performance wise regardless of content. I do use higher b frames, lower aq with animation.

[Ma]

I'm getting insta crash if I use anything past this (ur settings)

--wpp --ctu=16 --min-cu-size=8 --max-tu-size=16 --tu-intra-depth=3 --tu-inter-depth=3 --me=3 --subme=2 --merange=32 --no-rect --no-amp --max-merge=2 --temporal-mvp --early-skip --rdpenalty=0 --no-tskip --no-tskip-fast --strong-intra-smoothing --no-lossless --no-cu-lossless --no-constrained-intra --no-fast-intra --open-gop --no-temporal-layers --interlace=0 --keyint=240 --min-keyint=23 --scenecut=40 --rc-lookahead=20 --lookahead-slices=5 --bframes=4 --bframe-bias=0 --b-adapt=2 --ref=3 --limit-refs=1

I guess I'm doing something wrong lol

I tried to reproduce this crash but I wasn't able (console output attached). Can you specify more details?

[Vesdaris]

I'm not using command line per se.. I'm using Hybrid or Megui where you can put custom commands. I guess they conflict with something.

[foxyshadis]

I'm not using command line per se.. I'm using Hybrid or Megui where you can put custom commands. I guess they conflict with something.

You can find the actual command-line in Megui's log.

[Ma]

I'm not using command line per se.. I'm using Hybrid or Megui where you can put custom commands. I guess they conflict with something.

Thanks for some details. It could be related to outdated x265 version.

Problem with command line that hangs x265 was reported in P.S. part of this message http://forum.doom9.org/showthread.php?p=1746309#post1746309

Fix for this bug is in https://bitbucket.org/multicoreware/x265/commits/fff19fb6cbf9f278725c90dde994dde4afadad6b

You can update x265. (I'm only guessing.)

[foxyshadis]

Use ctu = 16

It's very disappointing that x265 is still so bad at mode decision that restricting ctu to 16 is useful, since that eliminates one of the key advantages over AVC. But I tested it, and it really does make the picture sharper even if it slightly increases noise, and retains grain better. Maybe psy-rd also needs to directly correspond to a much stronger version of --rd-penalty, where the higher the psy-rd the higher the threshold for 64x64 or 32x32 ctu becomes, so that larger can still be used when warranted, and the value of psy-rd directly indicates how much grain/fine detail the user is interested in keeping.

[Blowis]

It's very disappointing that x265 is still so bad at mode decision that restricting ctu to 16 is useful, since that eliminates one of the key advantages over AVC. But I tested it, and it really does make the picture sharper even if it slightly increases noise, and retains grain better. Maybe psy-rd also needs to directly correspond to a much stronger version of --rd-penalty, where the higher the psy-rd the higher the threshold for 64x64 or 32x32 ctu becomes, so that larger can still be used when warranted, and the value of psy-rd directly indicates how much grain/fine detail the user is interested in keeping.


For me the ctu16 it is best to have the detail with the ctu64 so smooth it was a clear image but less detail.
Here are photos and encodings (for the ctu64 i put RD Penalty: 2 Psy-RD: 1.20 Psy-RDOQ: 1.30, if I put as the encoding of ctu16 smooth it over):

wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=2 / merange=32 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=2 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=5 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=1 / no-limit-modes / weightp / weightb / aq-mode=2 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=1.20 / rdoq-level=2 / psy-rdoq=1.30 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Link Image ctu64: http://hpics.li/686abe6

wpp / ctu=16 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=2 / merange=32 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=5 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=1 / no-limit-modes / weightp / weightb / aq-mode=2 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=1.00 / rdoq-level=2 / psy-rdoq=1.10 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Link Image ctu16: http://hpics.li/93b5428

You see the differences on the teeth, lips, eyes on the ctu64 was a smoother face so clear but loses detail.
Here is the origin of the image x264: http://hpics.li/28b34fb

After a 80 inch TV i see no difference. For me the best is ctu16 all cases.

[undfeatable]

I can't speak to Handbreak specifically (it's more of a heartbreak for me whenever I've tried to us it for anything mildly interesting :)).

But there are a bunch of somewhat esoteric parameters that need to be set for a proper HDR-10 bitstream. Looking at a test file I did a few months ago:
--colorprim bt2020
--transfer 16
--colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0)"
--max-cll "1000,274"
--chromaloc 2
And, of course, you'll need to know what your master-display, MaxCLL, and MaxFALL values are for your content.

And you'll need to have a >=10-bit source that's already in the SMPTE 2084 PQ space, not gamma.

Also, I note you're targeting Level 5.1. AFAIK, there aren't any existing HEVC Main10 decoders that support beyond Level 5.1. Which can do 2160p60 :)!
I have those parameters set already, but really could use some help. Im going to post about it on the actual HDR post though to keep this thread on topic.
If the same binary works with SSE4.2 CPU and hangs with AVX2 CPU, you can add '--asm AVX' option or '--asm SSE4.2' option and retest.
Thanks! That solved it. I used --asm SSE4.2 and it now runs!

Question for the x265 crew though. Am I getting the full performance of my computer now or is it being hindered. I have a fully loaded 2015 MacBook pro w/ retina that has a 4.0GHz Intel i7 and 16gb of DDR3 ram. My practice clip is a 8 seconds long and 6GB uncompressed. It seems to take around 5-6 minutes to run through x265 on preset slow. Does that seem about right?

Side question, does everyone have to answer these questions before every post? Its frustrating to post and have to search around to answer a quest before a post!

[LigH]

You probably mean the anti-spam captchas for users with less than 5 posts?

[undfeatable]

You probably mean the anti-spam captchas for users with less than 5 posts?
Thats probably it lol. Its the most annoying "captcha" Ive ever encountered. Its just a random question and I never get it right the first 2 or 3 times. Well, this is post 5 so hopefully its gone for good.

[foxyshadis]

For me the ctu16 it is best to have the detail with the ctu64 so smooth it was a clear image but less detail.

After a 80 inch TV i see no difference. For me the best is ctu16 all cases.

There is definitely more annoying gibbs noise in the ctu16, but it's outweighed by the very annoying huge solid blocks with sharp sides that ctu64 has. With psy-rd 1.2 and rd-penalty 2 that should have been avoided as much as possible already.

My post was about how you shouldn't need to disable one of HEVC's greatest strengths just to get an acceptable encode, though. There has to be a way to fix the use of large blocks so that it works in harmony better.

[x265_Project]

... you shouldn't need to disable one of HEVC's greatest strengths just to get an acceptable encode, though. There has to be a way to fix the use of large blocks so that it works in harmony better.
Agree completely. The ability to code 32x32 and 64x64 blocks is perhaps HEVC's greatest asset. When can do this with low visual distortion, you get a big improvement in encoding efficiency. If you have visible distortion with large CUs, it could naturally be much more visible than with smaller CUs. We've got some ideas about how to improve our analysis to select the best PU and TUs, understanding that the distortion measurements used in x265 (and every HEVC encoder) are imperfect. It's just a matter of having the time to experiment and implement these ideas. Of course, as always, suggestions and contributions are welcomed.

[littlepox]

We've got some ideas about how to improve our analysis to select the best PU and TUs, understanding that the distortion measurements used in x265 (and every HEVC encoder) are imperfect. It's just a matter of having the time to experiment and implement these ideas.

Your efforts are always appreciated; we await the improvements.

[LigH]

Current state:

x265 1.8+167-e951ab673b1c (GCC 4.9.2) (https://www.mediafire.com/download/kkkz0d9mdvzjc3d/x265_1.8+167-e951ab673b1c.GCC492.7z)
x265 1.8+167-e951ab673b1c (GCC 5.2.0) (https://www.mediafire.com/download/4mps11mzk9x72ks/x265_1.8+167-e951ab673b1c.GCC520.7z)

New documented 'K' frametype ("keyframe", exact type depending on circumstances), several speedups and fixes (mostly in sao).

[microchip8]

Any news? (on the ctu & presets improvements & QoL)?

Cheers.

Impatient much?

[burfadel]

Any news? (on the ctu & presets improvements & QoL)?

Cheers.

A watched pot never boils :rolleyes:

[microchip8]

@froggy1: Retarded much?

This is going to get you nowhere ;)

Please don't ask when it's done. It'll be done when it's done

[Blowis]

I wanted to ask is it normal that me=star is faster than umh.
I tested two videos:

1a) Profil medium me= umh : 18.61 fps PSNR : 45.114 SSIM :0.971590
1b) Profil medium me= star : 19.14 fps PSNR : 45.113 SSIM : 0.971609

2a) Profil medium me= umh : 13.23 fps PSNR : 46.188 SSIM : 0.967780
2b) Profil medium me = star : 13.65 fps PSNR : 46.191 SSIM: 0.967778

On a video 2mn subme:star is 7s faster.

Visually I see no difference.

This is different from the x264 ?

[x265_Project]

I wanted to ask is it normal that me=star is faster than umh.
I tested two videos:...
Interesting, but the basic tradeoff with speed is not quality, it's efficiency (quality @ bit rate). What were the bit rates?

[Blowis]

Interesting, but the basic tradeoff with speed is not quality, it's efficiency (quality @ bit rate). What were the bit rates?


I use CRF:23 which gives a bitrate 1 724 Kbps and 2 597 Kbps.

After I tested rdpenalty:2 I lost 19% and 29% encoding time.
Visually minimal difference.

[x265_Project]

I use CRF:23 which gives a bitrate 1 724 Kbps and 2 597 Kbps.

I tested rdpenalty:2 I lost between 19% to 29% encoding time.
Visually minimal difference.

I'm confused. Can you put all the relevant information in a simple table?

command line options changed from default preset
bit rate
Global PSNR
SSIM
FPS

It would also help to know the details of your input video sequence (is it available, what is the pixel resolution, frame rate, and does it have low, medium or high motion)?

Lastly, it would help to know your computer system details (processor, memory, OS).

[Blowis]

I'm confused. Can you put all the relevant information in a simple table?

command line options changed from default preset
bit rate
Global PSNR
SSIM
FPS

It would also help to know the details of your input video sequence (is it available, what is the pixel resolution, frame rate, and does it have low, medium or high motion)?

Lastly, it would help to know your computer system details (processor, memory, OS).

I use StaxRip.
Video 1a Profil Medium and:
wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=2 / subme=2 / merange=32 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=5 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=0 / no-limit-modes / weightp / weightb / aq-mode=2 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=1.00 / rdoq-level=2 / psy-rdoq=1.10 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Video 1b unless such Me=3

The same for video 2a and 2b.

My Cpu I7 4770K@4.3Ghz DDR 8Go@2.4Ghz SSD 512go Samsung 840Pro Windows 10

[Motenai Yoda]

what x265_Project is trying to say is that you'll get the same quality but different bitrate, for the same bitrate you'll get different quality.

[LigH]

@ Blowis

command line options changed from default preset

That means the command line in your encoder call, not the whole set of internal parameters stored in the auxiliary data in the video stream (that's simply too much to recognize at one glance).

[x265_Project]

A patch with new performance presets was pushed today. We look forward to your feedback.

[Motenai Yoda]

The table shows 2 row for limit-refs, but I'm pretty sure the first was for limit-modes, and limit-modes there aren't at all in the code too, only defaulted at 0.

Anyway I didn't get how to enable the 2 pass mode for cfr+vbv, if I have to.

[x265_Project]

The table shows 2 row for limit-refs, but I'm pretty sure the first was for limit-modes, and limit-modes there aren't at all in the code too, only defaulted at 0.

Anyway I didn't get how to enable the 2 pass mode for cfr+vbv, if I have to.
Thanks for the feedback. We'll get this cleaned up before the patch is committed (tomorrow).

[LigH]

A patch with new performance presets was pushed today.

Just when I am away from my usual building PC ... well, I will try to publish one as soon as I rebuilt my compiling environments elsewhere.

P.S.:

... before the patch is committed (tomorrow).

Oh, then I have a little time, ok.

[LigH]

Merry Christmas (or similar holidays) with a current build with updated preset defaults (e.g. limit-modes/refs; please RTFM).

x265 1.8+187-da48f2690076 (GCC 4.9.2) (https://www.mediafire.com/download/tvvkyqf5md6m0ss/x265_1.8+187-da48f2690076.GCC492.7z)
x265 1.8+187-da48f2690076 (GCC 5.2.0) (https://www.mediafire.com/download/o5qyzouion38e69/x265_1.8+187-da48f2690076.GCC520.7z)

[Ajvar]

Hey guys, I've been away from my horse-powere laptop and so from encoding videos. Can somebody write a short-list of what drastically changed since 1.7.1? In efficiency/speed. Thanks.

[Selur]

"what drastically changed", the presets changed, pme and pmode were added but those only seem to be only really useful on systems 4+ core systems, all in all I wouldn't call any changed 'drastic'

[Blowis]

Hi,
I just tested the last days made. I chose the Medium profile I modified all its: --crf 22 --early-skip --aq-mode 2 --me star --merange 44 --rc-lookahead 60 --keyint 240 --psy-rd 1.3.

wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=2 / merange=44 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=23 / scenecut=40 / rc-lookahead=60 / lookahead-slices=5 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / weightb / aq-mode=2 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=1.30 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30


But I see --Limit-modes : 3 that normally there should be more than 0. You can set it to 0 or must be done manually.

[foxyshadis]

--limit-modes has no argument, it's either on or off. --limit-refs is 0-3.

Changes since 1.8: Modified presets, most are faster, higher quality, or both. Limit-modes. Intra refresh. 2-pass CRF. Monochrome (i400). Big psy-rd changes, possibly improvements. Lots of 12-bit speedups & bug fixes, and some other misc speedups and fixes for 8 & 10. Analysis save/load fixes. Level 8.5 (unlimited) allowed. i64x64 disabled until it's fixed.

See the 1.8 announcement (https://forum.doom9.org/showpost.php?p=1742032&postcount=2754) for changes since 1.7.

[x265_Project]

To see the changes, see this commit... https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce


increased the number of reference frames for slower, slow, fast, faster and veryfast
turned on --limit-refs for veryslow, slower, slow, medium, fast, faster, and veryfast
turned on --limit-modes for veryslow, slower and slow
turned on --cutree for faster, veryfast, superfast and ultrafast
increased max CTU size to --ctu 64 for veryfast

[Jamaika]

Updating presets for x265 v1.8.0.188 to improve coding efficiency and speed. | |ultrafast |superfast |veryfast |faster |fast |medium |slow |slower |veryslow |placebo |
| ctu | 32 | 32 | 64 | 64 | 64 | 64 | 64 | 64 | 64 | 64 |
| ref | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 4 | 5 | 5 |
| cuTree | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| limit-refs | 0 | 0 | 3 | 3 | 3 | 3 | 3 | 2 | 1 | 0 |
| limit-modes | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 |

Who knows why the placebo preset is disabled features "limit-refs/modes"? Could they not have been perfect?
When you expect the implementation of the "psy-rdoq = 50.0" for veryslow?
Who can explain to me what are the features "sao, amp, temporal-MVP, signhide, strong-intra-smoothin"? If you don't apply them for quick shots even playing the movie better presented.

[nevcairiel]

Who knows why the placebo preset is disabled features "limit-refs/modes"? Couldn't they have been perfect?

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed. The two limit options can slightly cost efficiency to gain substantial speed improvements, which is not something you want in placebo.

[Boulder]

To see the changes, see this commit... https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce


increased the number of reference frames for slower, slow, fast, faster and veryfast
turned on --limit-refs for veryslow, slower, slow, medium, fast, faster, and veryfast
turned on --limit-modes for veryslow, slower and slow
turned on --cutree for faster, veryfast, superfast and ultrafast
increased max CTU size to --ctu 64 for veryfast
After these changes, what it the recommended range for psy-rd and psy-rdoq if detail/noise/etc. retention is the goal? I've got one particularly difficult movie to encode (The Big Red One), with x264 and CRF18 it's ending up at ~9MBps at 1280x720 even with some denoising. I'd like to test to see what x265 can come up with.

[Jamaika]

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed. The two limit options can slightly cost efficiency to gain substantial speed improvements, which is not something you want in placebo.
Maybe it's the truth. For which CPUs was executed test presets. I use for veryslow "limit-ref = 3" because faster converts video.

PS Why does X265 v1.8.0.188 not retain the bitrate?
x265 x1.8.0.86 --bitrate 4500 --vbv-bufsize 10000 --vbv-maxrate 10000
Bit rate : 4 595 Kbps
Maximum bit rate : 6 030 Kbps
x265 x1.8.0.188 --bitrate 4500 --vbv-bufsize 10000 --vbv-maxrate 10000
Bit rate : 3 680 Kbps
Maximum bit rate : 4 923 Kbps

[Atak_Snajpera]

What do you think about increasing default --psy-rd value from very low 0.3 to 2?
According to my tests if you want to achieve similar level of details with x264 this must be increased in first place. Default 0.3 value can produce nasty banding effects in dark areas. (see jaw)

Source
http://i.cubeupload.com/AhAG58.png

x264 --veryslow --2pass --bitrate 2048
http://i.cubeupload.com/rKB3Sq.png

x265 --medium --2pass --bitrate 2048
http://i.cubeupload.com/FzFWFZ.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2
http://i.cubeupload.com/DKDrIR.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2 --aq-strength 2
http://i.cubeupload.com/nLhSxJ.png


I've also uploaded whole 10 min samples if you want to check how other scenes look like. (Use staxrip's video comparison tool)
https://mega.nz/#!pJFiHRaS!zxYtdhj4Obvp7CMQTMmwnXsmrdpqD6Ia8n6HIHYGDwo

[x265_Project]

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed.
That's generally the idea, although there are more things we could do to sacrifice performance for that last little bit of possible quality. We wouldn't want to slow x265 to the point where it is absolutely unusable under any reasonable circumstances. Some extreme quality-centric x265 users might be ok waiting a couple of days for their encode to finish, but not for weeks or months.

--me 4 slows performance by 13X, and I couldn't see a noticeable improvement in quality

--subme 7 slows performance by about 9%, and visually you may see a difference in quality, so we may still consider adding this to placebo

--merange 121 slowed performance by 13%, but I didn't really see a difference in the output bitstream

Of course, you're free to tweak any parameters you would like in an attempt to improve speed or quality. For example, you could also try --preset placebo with --limit-refs and/or --limit-modes, and it would run much faster.

[x265_Project]

What do you think about increasing default --psy-rd value from very low 0.3 to 2?
According to my tests if you want to achieve similar level of details with x264 this must be increased in first place. Default 0.3 value can produce nasty banding effects in dark areas. (see jaw)

Source
http://i.cubeupload.com/AhAG58.png

x264 --veryslow --2pass --bitrate 2048
http://i.cubeupload.com/rKB3Sq.png

x265 --medium --2pass --bitrate 2048
http://i.cubeupload.com/FzFWFZ.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2
http://i.cubeupload.com/DKDrIR.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2 --aq-strength 2
http://i.cubeupload.com/nLhSxJ.png


I've also uploaded whole 10 min samples if you want to check how other scenes look like. (Use staxrip's video comparison tool)
https://mega.nz/#!pJFiHRaS!zxYtdhj4Obvp7CMQTMmwnXsmrdpqD6Ia8n6HIHYGDwo
I think that psy-rd has been improved to the point where it can probably stand a higher default value, and possibly a higher upper limit. We plan to take another look at this.

[Jamaika]

I don't know why there are such differences in image quality in my results. The file size of CRF=37:qcomp=1.00 x264 is three times higher than for CRF=37:qcomp=1.00 X265. Is this correct result? I will present your findings to the X265 CRF=37. The two supposedly identical commands for X265 and two different results from the original.

Test 1
ffmpeg.exe -loglevel info -i "swimming.avi" -s 1920x1080 -r 50000/1000 -an -sn -f image2 -c:v png -pix_fmt rgba "swimming%%003d.png"
bpgenc.exe -v -a -e x265 -c rgb -q 37 -alphaq 37 -m 9 -fps 50 "swimming%%003d.png" -o "swimming_rgba.bpg"
Edit: bpgenc.exe -v -a -e x265 -b 8 -f 444 -c rgb -q 37 -m 9 -fps 50 (only 25) "swimming%%003d.png" -o "swimming_rgb.bpg"
Edit: bpgenc.exe -v -a -e x265 -b 8 -f 444 -c ycbcr -q 37 -m 9 -fps 50 (only 25) "swimming%%003d.png" -o "swimming_yuv444.bpg"
Using x265 preset: placebo
x265 [info]: HEVC encoder version unknown
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:4:4 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 60 / 0 / 2
x265 [info]: b-pyramid / weightp / weightb : 0 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 1 / 0 / 0
x265 [info]: Rate Control : CQP-37
x265 [info]: tools: rect amp rd=6 rdoq=2 tskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
Test 2
ffmpeg.exe -loglevel info -y -i "swimming.avi" -s 1920x1080 -r 50000/1000 -an -sn -f yuv4mpegpipe -strict experimental -pix_fmt yuv444p - |
x265.exe --y4m --input-csp i444 --preset placebo --high-tier --crf 37 --ref 1 --bframes 0 --qcomp 1.00 --no-open-gop --no-psy-rd --no-psy-rdoq --no-info --limit-modes --limit-refs 3 --range full - -o "swimming.h265"

y4m [info]: 1920x1080 fps 50/1 i444p8 unknown frame count
raw [info]: output file: swimming.h265
x265 [info]: HEVC encoder version 1.8+188-
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:4:4 profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 60 / 0 / 2
x265 [info]: b-pyramid / weightp / weightb : 0 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 1 / 1 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-37.0 / 1.00
x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
View single frames I/P:
http://i66.tinypic.com/v5zxc1.png
BPG x265 v0.9.6
http://i65.tinypic.com/2i436u.png
x265 v1.8.0.188
http://i68.tinypic.com/2gy63jn.png
Summary: Codec X265 with the same parameters fell much worse. The colors and sharpness are not the same. The cause is unknown.

[vivan]

The file size of CRF=37:qcomp=1.00 x264 is three times higher than for CRF=37:qcomp=1.00 X265. Is this correct result?Why it shouldn't? Those are completely different encoders.

Summary: Codec X265 with the same parameters fell much worse. The colors and sharpness are not the same. The cause is unknown.Unknown? How about 3x lower bitrate?