x265 HEVC Encoder

[Selur]

Also:
Boosting the brightness and looking at the source sometimes shows lots of compression artifacts, so some smoothing/denoising of the dark areas might help to understand where the bit rate goes.
Dark areas often contain lots of noise and artifacts which the encoder interprets as details that should be preserved.

[benwaggoner]

Why did you not lower crf?
Yeah, I recommend doing 2-pass VBR encoding when trying to figure out quality/bitrate tradeoffs, and then figuring out the optimal CRF from there.

[Forteen88]

@katzenjoghurt. Maybe you should set x265: --zones
and increase/decrease bitrate where you want.

[LigH]

Intentionally, aq-mode 3 (https://x265.readthedocs.io/en/default/cli.html#cmdoption-aq-mode) is supposed to help with dark scenes, even without zones; but it needs a matching aq-strength too, and sufficient bitrate, and possibly other circumstances — and still can't work wonders...

[Forteen88]

My settings were: --crf 23 --tune grain --profile main12 --output-depth 12 --rskip --qcomp 0.8 --no-open-gop --no-deblock --no-strong-intra-smoothingAre you aware of that GPU-decoding (certain newer GPUs) doesn't support 12-bits x265-video, but maximum 10-bits x265-video?

[LigH]

And if you have source material with only 8 bit precision per color component, an internal precision of 12 bit per quantization coefficient would be a waste anyway.

[brumsky]

Hi guys,

I'm currently trying to convert Star Wars Episode III to x265... and hell... it's a beast.
This movie gives me super ugly artifacts in dark scenes.

Original: https://i.imgur.com/PA9cWuR.png
Encoding: https://i.imgur.com/HpVbyf4.png (with meagre 2,300kb/s in that scene, 4,500kb/s on avg for the whole movie)

My settings were: --crf 23 --tune grain --profile main12 --output-depth 12 --rskip --qcomp 0.8 --no-open-gop --no-deblock --no-strong-intra-smoothing

I already tried aq-mode 3 but to retain an okayish quality I had to set the aq-strength to 1.5 and ended up with 12 mbit/s for this scene.
I then tried aq-strength 3 and ended up with with perfect quality... and wopping 43 mbit /s.

Why are dark scenes so much more costly than brighter scenes?
This does not feel right...
What can I do?

To me it looks like your PSY values are set very high. That could be an effect of tune grain though. Have you tried it without tune grain? Maybe take tune grain out and try playing with the PSY values. I've found aq-mode 3 to work well but it needs a bit high bit rate to help it. When I use aq-mode 3 I try to set the strength setting between .85-1, then up the bit rate as needed to reach my target quality.

[katzenjoghurt]

Hey brumsky et al.!

Yes... psy_rd was set to 4.
I kept grain mode but reduced psy_rd to 1 and set crf to 21 now and the artifacts are gone (while the file size got a bit smaller) ... the result is a bit smeared though.
Also it kills most of the grain.
https://i.imgur.com/eqQJXy7.png

Lowering Crf or Psy further won't do any good though... quite the contrary. At least on that example scene.

[katzenjoghurt]

Why did you not lower crf?

I didn't know that this is good practice.
Tried it out but didn't find any sweet spot yet though. :-/

Are you aware of that GPU-decoding (certain newer GPUs) doesn't support 12-bits x265-video, but maximum 10-bits x265-video?

Just something I tried out... 12-bit seemed to have helped in this thread (https://forum.doom9.org/showthread.php?t=173870). But no. Didn't work out for me.

[excellentswordfight]

I didn't know that this is good practice.
Tried it out but didn't find any sweet spot yet though. :-/



Just something I tried out... 12-bit seemed to have helped in this thread (https://forum.doom9.org/showthread.php?t=173870). But no. Didn't work out for me.
Tune grain usually gives pretty bad results, I found it to be usefull in very few instances.

I would start over with main10, keep --no-strong-intra-smoothing and --no-sao, try a slower preset and a lower CRF value. If that doesnt give you good results start playing with AQ and qcomp

[Forteen88]

My settings were: --crf 23 --tune grain --profile main12 --output-depth 12 --rskip --qcomp 0.8 --no-open-gop --no-deblock --no-strong-intra-smoothingTry setting --psy-rdoq 0.0 (default for --tune grain is --psy-rdoq 10.0) or set it to around 2.0.
I never liked that corresponding PSY-setting in x264 either, it was too strong.

[katzenjoghurt]

Try setting --psy-rdoq 0.0 (default for --tune grain is --psy-rdoq 10.0) or set it to around 2.0.
I never liked that corresponding PSY-setting in x264 either, it was too strong.

huh! I set --psy-rdoq 0 and got the exact same output (same pic and bytesize).
I then checked with mediainfo and all my test videos so far were already encoded with --psy-rdoq 0.

[katzenjoghurt]

Tune grain usually gives pretty bad results, I found it to be usefull in very few instances.

I would start over with main10, keep --no-strong-intra-smoothing and --no-sao, try a slower preset and a lower CRF value. If that doesnt give you good results start playing with AQ and qcomp

I will try tomorrow or during the weekend. As with any proposal that seems to be a bit more time consuming.

I'm quite happy with Tune Grain... I use it for every movie.
E.g. every Star Wars movie came out well with it so far... only Star Wars III seems like it was specifically made to make x265 look bad - pick your poison:
a) no grain b) 15k+ bitrate c) wobbling faces with artefacts

[Forteen88]

huh! I set --psy-rdoq 0 and got the exact same output (same pic and bytesize).
I then checked with mediainfo and all my test videos so far were already encoded with --psy-rdoq 0.Oh, weird, I got that info about --tune grain from,
https://x265.readthedocs.io/en/default/presets.html
That webpage says that --tune grain sets --psy-rdoq 10.0

Did you set --psy-rdoq 0 AFTER setting --tune grain? I think it overwrites the --psy-rdoq that --tune grain sets then.

[jd17]

He was most likely using a non-slow preset.
--psy-rdoq 10.0 is only set starting at --preset slow and slower.

This is why --tune grain actually looks quite good on medium or fast preset.

@katzenjoghurt:
Simply try --preset slow --profile main10 --output-depth 10 --no-sao at a CRF between 17 and 20.
Maybe that helps with bitrate and quality. :)

[Forteen88]

My settings were: ... --no-deblockThat'll create blocks on big screens. I would not remove deblock, most people use minimum --deblock -3:-3
I've never seen an encode (including x264-encodes) with lower --deblock than --deblock -3:-3

[katzenjoghurt]

Hi guys,

just wanted to thank you for your support.
Unfortunately I'm too dead tired from work to do some test encodings today.
But thanks! Much appreciated.
Will try out some of your proposals during the weekend and let you know what worked out.

[jlpsvk]

That'll create blocks on big screens. I would not remove deblock, most people use minimum --deblock -3:-3
I've never seen an encode (including x264-encodes) with lower --deblock than --deblock -3:-3

why? i am using --no-deblock with CRF ano NO BLOCKING... depends on bitrate and with CRF, no blocking should be presented. :)

[Forteen88]

why? i am using --no-deblock with CRF ano NO BLOCKING... depends on bitrate and with CRF, no blocking should be presented. :)Yeah, that's true to a point (until the screen is VERY big) :) What is the inch of the big screen you're using for playing such encodes?
If you're setting --no-deblock on UHD-encodes, it's obviously also less of a difference compared to encodes at lower resolutions.

[Boulder]

In theory, is it better to use smaller (C)TU sizes to retain detail? I've been thinking about the rdpenalty parameter - earlier I've used --ctu 32 --max-tu-size 16 --tu-inter-depth 4 --tu-intra-depth 4 --limit-tu 3, but I've wondered if --max-tu-size 32 --rdpenalty 1 would allow some more flexibility for the encoder without sacrificing detail.

[benwaggoner]

Yeah, that's true to a point (until the screen is VERY big) :) What is the inch of the big screen you're using for playing such encodes?
If you're setting --no-deblock on UHD-encodes, it's obviously also less of a difference compared to encodes at lower resolutions.
Deblocking also improves quality by making prediction more efficient. Even if you can't see a sharp block boundary on a given screen, it being there makes that area a poor reference for a predicted block. Using deblocking can reduce residual substantially, and thus lower QPs overall.

[Midzuki]

x265.exe 2.8+68-fa57fa584898

https://forum.videohelp.com/threads/357754-[HEVC]-x265-EXE-mingw-builds?p=2529259#post2529259

[katzenjoghurt]

@katzenjoghurt:
Simply try --preset slow --profile main10 --output-depth 10 --no-sao at a CRF between 17 and 20.
Maybe that helps with bitrate and quality. :)

The quality is nice at crf 17 slow.
I tried a bigger test encode with crf 18 medium but looks like I'll get close to a 10mbit bitrate then.
But lowering the bitrate further will kill the grain on the other hand.
*sigh*

At least I can confirm that the artifacts indeed seem to be caused by tune grain. As soon as I enable it artifacts start showing up at bitrates <10mbit.


This movie is really weird. Looking at it my gut feeling is that it should be encodable with 5,000kbit/s.
But it demands far more... more than some 60's movie with grain everywhere.

[Barough]

x265 v2.8+70-33a782b23f2c (http://www.mediafire.com/file/ikq55der79o1fb9/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[RainyDog]

Is someone able to explain what --hdr-opt does please?

I've started to try a couple of hdr encodes and have always used --cbqpoffs -2 and --crqpoffs -2 in my standard x265 settings. But wondered if setting --hdr-opt together with those might cause issues as they all seem to be chroma/luma QP optimizations...

Thanks.

[tuanden0]

Is someone able to explain what --hdr-opt does please?

I've started to try a couple of hdr encodes and have always used --cbqpoffs -2 and --crqpoffs -2 in my standard x265 settings. But wondered if setting --hdr-opt together with those might cause issues as they all seem to be chroma/luma QP optimizations...

Thanks.

https://x265.readthedocs.io/en/default/cli.html#cmdoption-hdr-opt :D

[benwaggoner]

Is someone able to explain what --hdr-opt does please?

I've started to try a couple of hdr encodes and have always used --cbqpoffs -2 and --crqpoffs -2 in my standard x265 settings. But wondered if setting --hdr-opt together with those might cause issues as they all seem to be chroma/luma QP optimizations...

Thanks.
Indeed, --hdr-opt does adjust QP in a way that probably will allow you to turn off or at least lower the c?cpoffs options. I've been surprised how much a little chroma offset can increase bitrate with HDR content, so using --hdr-opt instead improves overall quality/efficiency.

[RainyDog]

https://x265.readthedocs.io/en/default/cli.html#cmdoption-hdr-opt :D

Well, yes... That's why I asked what it actually does :D As that doesn't really explain.

--hdr-opt, --no-hdr-opt

Add luma and chroma offsets for HDR/WCG content. Input video should be 10 bit 4:2:0. Applicable for HDR content. It is recommended that AQ-mode be enabled along with this feature. Default disabled.

By 'add' luma and chroma offsets, is it also tweaking cbqpoffs and crqpoffs and, if so, how?

[Magik Mark]

May I ask which among the switches will enable faster encoding in 2 pass (default medium) with minimal or no degradation in picture quality? So far I have identified the ff:

1. --no slow first pass
2. --multi-pass-opt-analysis
3. --multi-pass-opt-distortion

I might be missing couple more things?

[alex1399]

There're two elephants in the room. Your frame-crushing machine or your expectation about the speed of x265 at medium preset or both of them.

[benwaggoner]

Well, yes... That's why I asked what it actually does :D As that doesn't really explain.







By 'add' luma and chroma offsets, is it also tweaking cbqpoffs and crqpoffs and, if so, how?


Yes, the -cp?offs ARE the chroma offsets.

I don’t recall the exact math; it was based on an IEEE paper a couple years back. But it is adaptive based on luma, and so is going to be better than just fixed offsets.

[benwaggoner]

May I ask which among the switches will enable faster encoding in 2 pass (default medium) with minimal or no degradation in picture quality? So far I have identified the ff:

1. --no slow first pass
2. --multi-pass-opt-analysis
3. --multi-pass-opt-distortion

I might be missing couple more things?


Those are what I know about.

When using —no-slow-firstpass you probably want to make sure to set the number of ref and b-frames to match the second pass. The first pass is less useful as a reference without those, which will hurt quality a bit, and might slow encoding.

That said, the multi-pass options and no-slow-firstpass might be incompatible in practice, since x265 can’t refine stuff that the first pass didn’t do. Or at least, some parameter fine-tuning might be required to make sure the 1st pass is a good reference.

[NikosD]

I have 2 recent Smart TVs (Samsung and Panasonic) and 3 blu-ray players (2 from Samsung and 1 from LG). The Samsung BD players are UHD models

None of the devices above support 10-bit H.264 decodingSorry for the OT.

I just got my budget Chinese tablet with MediaTek MT6797 (Xelio X20) inside - a 2016 SoC

It supports in hardware MPEG2, VC-1/ WMV3, VP8, VP9 (8bit/10bit), H.264 (8bit/10bit), H.265 (8bit/10bit)

Also, my Sony is an ATV2 with MediaTek MT5891 SoC inside and supports H.264 10bit too.

End of OT.

[Majorlag]

May I ask which among the switches will enable faster encoding in 2 pass (default medium) with minimal or no degradation in picture quality? So far I have identified the ff:

1. --no slow first pass
2. --multi-pass-opt-analysis
3. --multi-pass-opt-distortion

I might be missing couple more things?

--no slow first pass, I think misses the point of 2 pass encoding. 2pass means to spend that much more time on encoding to get that much more quality or to hit that target size. Otherwise you would just stick to 1pass encoding for speed.

I would keep options 2 and 3, and add --no-strong-intra-smoothing --no-sao --multi-pass-opt-rps for some speedups as well.

[RainyDog]

Yes, the -cp?offs ARE the chroma offsets.

I don’t recall the exact math; it was based on an IEEE paper a couple years back. But it is adaptive based on luma, and so is going to be better than just fixed offsets.

Ok, thanks again benwaggoner.

I'll leave --c*qpoffs at default for HDR ecndoes then and set --hdr-opt instead.

[Barough]

x265 v2.8+74-fd517ae68f93 (http://www.mediafire.com/file/23ssbmzdtdwxzx2/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[benwaggoner]

Ok, thanks again benwaggoner.

I'll leave --c*qpoffs at default for HDR ecndoes then and set --hdr-opt instead.
And please report back your results!

[Boulder]

Apart from the required bitrate to encode a frame, is the only real difference between --rd 4 and --rd 6 just the amount of effort required by the encoder? So I could switch to using --rd 4 if I'm ready to accept that it will probably produce a bigger file but take much less time? The presets don't seem to change the setting at all from the default 3, but 4 is the one where the other settings related to RDO kick in.

[Barough]

x265 v2.9+1-169e76b6bbcc (https://www.mediafire.com/file/5yy1p714hc41iyv/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/all

[LigH]

What? v2.9? Without any announcement yet? Is the mailing list broken?

[Barough]

What? v2.9? Without any announcement yet? Is the mailing list broken?

v2.9 have been out since yesterday.

[LigH]

x265 2.9+1-169e76b6bbcc (http://www.mediafire.com/file/mv79mzv7kdgx485/x265_2.9%2B1-169e76b6bbcc.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

surprise

[benwaggoner]

Apart from the required bitrate to encode a frame, is the only real difference between --rd 4 and --rd 6 just the amount of effort required by the encoder? So I could switch to using --rd 4 if I'm ready to accept that it will probably produce a bigger file but take much less time? The presets don't seem to change the setting at all from the default 3, but 4 is the one where the other settings related to RDO kick in.
That seems a reasonable premise to me, for CRF encoding where VBV limits aren’t a quality constraint.

I don’t know if it’d be THAT much less time, but it’ll help.

[katzenjoghurt]

Thanks for providing builds for v2.9, guys! :)

I just always wonder - how to tell which cpu capabilities a build is using (AVX? AVX2? None?).
As far as I can tell x265.exe -V is misleadingly saying "using CPU capabilities X Y Z" but in fact it is actually just listing MY CPU's capabilities.
Is that right?

[Forteen88]

Thanks for providing builds for v2.9, guys! :)

I just always wonder - how to tell which CPU capabilities a build is using (AVX? AVX2? None?).
As far as I can tell x265.exe -V is misleadingly saying "using CPU capabilities X Y Z" but in fact it is actually just listing MY CPU's capabilities.
Is that right?This page got links to different builds of x265, some explicitly supports AVX2,
All binaries do the same, so it is only about encoding speed. My recommendations are: for AVX2-CPU the fastest should be VS 2017 AVX2 version, for AVX-CPU – VS 2017 AVX version, for SSE4-CPU – VS 2017 none or GCC none version, for SSSE3-CPU – GCC SSSE3 version, for CPU without even SSSE3 – GCC none version. You can determine fastest version by comparing encoding time on the same short sample. http://www.msystem.waw.pl/x265/

[nevcairiel]

I just always wonder - how to tell which cpu capabilities a build is using (AVX? AVX2? None?).
As far as I can tell x265.exe -V is misleadingly saying "using CPU capabilities X Y Z" but in fact it is actually just listing MY CPU's capabilities.
Is that right?

x265 uses all those instruction sets by default using runtime selection. If you CPU support it, and x265 has code for it, it'll get used.

Some people try to get a tiny bit of extra performance by allowing the C/C++ compiler to use those instructions sets to optimize the code, however one should know that compilers are limited in what they can do, and the majority of the "hot" (ie. important) code is manually optimized and unaffected by the compilers choices.

In my experience, the differences between a generic build with just the ASM enabled that the x265 developers wrote, and a build that allows the compiler to additionally use AVX/AVX2 to optimize the remaining code is relatively small, probably low single digits percentages.

[hajj_3]

are we ever going to get a changelog for v2.9 then?

[birdie]

Version 2.9

Release date - 05/10/2018
New features

Support for chunked encoding
Option:`--chunk-start and --chunk-end` Frames preceding first frame of chunk in display order will be encoded, however, they will be discarded in the bitstream. Frames following last frame of the chunk in display order will be used in taking lookahead decisions, but, they will not be encoded. This feature can be enabled only in closed GOP structures. Default disabled.

Support for HDR10+ version 1 SEI messages.

Encoder enhancements

Create API function for allocating and freeing x265_analysis_data.
CEA 608/708 support: Read SEI messages from text file and encode it using userSEI message.

Bug fixes

Disable noise reduction when vbv is enabled.
Support minLuma and maxLuma values changed by the commandline.

[katzenjoghurt]

@Forteen88:
Thanks, man. That's where I'm usually grabbing my builds from. But no 2.9 yet.
But there are cool guys here too, providing builds. :)

@nevcairiel:
Moin nevcairiel,
thanks for the insights! Huh.
The x265.exe --V output made me think that there are some AVX2 optimizations in the project's code itself. That's why I'm asking.
But you're saying it's just about compiler optimizations. Hm.

[Forteen88]

@Forteen88:
Thanks, man. That's where I'm usually grabbing my builds from. But no 2.9 yet.Np. There are 2.9 builds there under "x265 binaries for Win64/32 — stable branch"!