x265 HEVC Encoder

[kosta1000]

hi guys. Where can I find changelog for x265 3.0 ???

on official site, changelog exists only for version 2.9

another question : When Ryzen 2 get out around this June, would this processor have much better performance in x265 encoding, while AMD put 256-bit AVX2 now, along with many other notable improvments.

[Selur]

hi guys. Where can I find changelog for x265 3.0 ???
Probably hasn't been written yet,... iirc there hasn't been a 3.0 final/stable flag last tag was '3.0_RC'.

[benwaggoner]

Probably hasn't been written yet,... iirc there hasn't been a 3.0 final/stable flag last tag was '3.0_RC'.
The best bet for the moment is to read the documentation that got added to —fullhelp in the checking.

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

[agressiv]

Looks like 3.0 is finally released! Congrats to the team! Here are the release notes:

New features
-------------
1. option:: '--dolby-vision-profile <integer|float>' generates bitstreams confirming to the specified Dolby Vision profile. Currently profile 5, profile 8.1 and profile 8.2 enabled, Default 0 (disabled)

2. option:: '--dolby-vision-rpu' File containing Dolby Vision RPU metadata. If given, x265's Dolby Vision metadata parser will fill the RPU field of input pictures with the metadata
read from the file. The library will interleave access units with RPUs in the bitstream. Default NULL (disabled).

3. option:: '--zonefile <filename>' specifies a text file which contains the boundaries of the zones where each of zones are configurable.

4. option:: '--qp-adaptation-range' Delta-QP range by QP adaptation based on a psycho-visual model. Default 1.0.

5. option:: '--refine-ctu-distortion <0/1>' store/normalize ctu distortion in analysis-save/load. Default 0.

6. Experimental feature option:: '--hevc-aq' enables adaptive quantization
It scales the quantization step size according to the spatial activity of one coding unit relative to frame average spatial activity. This AQ method utilizes
the minimum variance of sub-unit in each coding unit to represent the coding unit’s spatial complexity.

Encoder enhancements
--------------------
1. Preset: change param defaults for veryslow and slower preset. Replace slower preset with defaults used in veryslow preset and change param defaults in veryslow preset as per experimental results.
2. AQ: change default AQ mode to auto-variance
3. Cutree offset reuse: restricted to analysis reuse-level 10 for analysis-save -> analysis-load
4. Tune: introduce --tune animation option which improves encode quality for animated content
5. Reuse CU depth for B frame and allow I, P frame to follow x265 depth decision

Bug fixes
---------
1. RC: fix rowStat computation in const-vbv
2. Dynamic-refine: fix memory reset size.
3. Fix Issue #442: linking issue on non x86 platform
4. Encoder: Do not include CLL SEI message if empty
5. Fix issue #441 build error in VMAF lib

[Selur]

4. option:: '--qp-adaptation-range' Delta-QP range by QP adaptation based on a psycho-visual model. Default 1.0.
6. Experimental feature option:: '--hevc-aq' enables adaptive quantization

Sadly still unkown how they are related to the normal aq-modes,..

[benwaggoner]

Sadly still unkown how they are related to the normal aq-modes,..
--hevc-aq overrides whatever --aq-mode is set to. I suspect that --aq-strength may get overridden itself, with --aq-adaption-range being the equivalent. Or both parameters could be used together, ala the interaction of CRF with maxrate/bufsize.

[brumsky]

@excellentswordfight

I've come to the same conclusion as well. merange should be based off of the CTU. If you leave CTU at 64 then merange should also be reduced. It'll be searching outside of it's original block. Not to say that is bad necessarily though. I've seen certain "high quality" encodes that use meranges larger than the CTU. I'm not 100% sold that it provides tangible differences thoughs.

I personally drop merange to 26 when using CTU 32. Since I never plan on using hex search I should probably change merange to 58 when using CTU64...

Best way to find out is to try it for yourself.

[brumsky]

another question : When Ryzen 2 get out around this June, would this processor have much better performance in x265 encoding, while AMD put 256-bit AVX2 now, along with many other notable improvments.

I hope it does. I also hope AMD allows them to be fused like they current do with two 128-bit AVX FPUs that can run one 256-bit AVX2. If they do this then they will have the lead in AVX512!

Intel's top of the line 18 core CPU only has 2 AVX512 units on it. Imagine a Zen 2 CPU with up to 8 AVX512 fused units!!! I know there is an extra cycle or two when doing a fused operation but still up to 8 AVX512 operations will be nice!

[Selur]

--hevc-aq overrides whatever --aq-mode is set to.
okay
I suspect that --aq-strength may get overridden itself, with --aq-adaption-range being the equivalent. Or both parameters could be used together, ala the interaction of CRF with maxrate/bufsize.
And here it get's confusing to me. :)
Questions are:
a. is '--aq-strength' an option for both '--aq-mode' and '--hevc-aq' or just '--aq-mode'?
b. is '--aq-adaption-range' an option for both '--aq-mode' and '--hevc-aq' or just '--hevc-aq'?

Cu Selur

[nevcairiel]

I know there is an extra cycle or two when doing a fused operation but still up to 8 AVX512 operations will be nice!

Other then compatibility, that really doesn't offer anything. AVX/AVX2 instructions making use of those 256-bit units would be about the same speed.

256-bit AVX on current Ryzen isn't that much faster then 128-bit SSE due to that.

In any case, there have been zero hints about AVX512 support.

[benwaggoner]

Other then compatibility, that really doesn't offer anything. AVX/AVX2 instructions making use of those 256-bit units would be about the same speed.

256-bit AVX on current Ryzen isn't that much faster then 128-bit SSE due to that.

In any case, there have been zero hints about AVX512 support.
And so far, AVX512 in x265 has only been demonstrated to be helpful on Intel systems doing UHD at slower+ presets; it'll make things slower for other scenarios on existing processors. That's why it is off by default even on a system with AVX512 support. AVX & AVX2 are always used if there is hardware support because they help significantly most of the time, and I don't know of any cases where they hurt.

Generally the value of AVX? instructions have improved over time, as microarchitecture improvements help with thermal throttling and other bottlenecks.

[benwaggoner]

okay

And here it get's confusing to me. :)
Questions are:
a. is '--aq-strength' an option for both '--aq-mode' and '--hevc-aq' or just '--aq-mode'?
b. is '--aq-adaption-range' an option for both '--aq-mode' and '--hevc-aq' or just '--hevc-aq'?

It is definitely not b. So either a, or:

c. --aq-strength is an parameter for --aq-mode, and --aq-adaption-range is a parameter for --hevc-aq, and neither is used when the other aq type is used.

[Boulder]

And so far, AVX512 in x265 has only been demonstrated to be helpful on Intel systems doing UHD at slower+ presets; it'll make things slower for other scenarios on existing processors. That's why it is off by default even on a system with AVX512 support. AVX & AVX2 are always used if there is hardware support because they help significantly most of the time, and I don't know of any cases where they hurt.

Generally the value of AVX? instructions have improved over time, as microarchitecture improvements help with thermal throttling and other bottlenecks.

At least with a first generation Ryzen, you'll want to disable AVX2 in the x265 command line. It's slightly faster that way.

[Stereodude]

At least with a first generation Ryzen, you'll want to disable AVX2 in the x265 command line. It's slightly faster that way.
The Zen 2 architecture doubles the width of the datapath and the execution units to 256-bits which should double the performance of AVX2 on it vs. Zen.

The whole FPU got supersized in Zen 2 (vs. 1).

2x wider datapath (256-bit, up from 128-bit)
2x wider EUs (256-bit FMAs, up from 128-bit FMAs)
2x wider LSU (2x256-bit L/S, up from 128-bit)

from: https://en.wikichip.org/wiki/amd/microarchitectures/zen_2

[NikosD]

Another important advantage of Zen 2 architecture and its implementation of Ryzen 3000 series, will be the CPU clock during heavy execution of AVX2 instructions, like running x265 app.

If AMD has been interpreted correctly, we will see no performance penalty due to lower clocks during x265 AVX2 code execution.

Intel sees lower clocks leveraging AVX2 instructions of x265 with all CPU architectures, so far.

I think Ryzen 3000 (and Threadripper, EPYC) based on Zen 2 architecture has all the benefits to be a lot faster than any Intel CPU ever released with the same number of cores.

And due to the fact that all AMD CPUs have more cores than Intel nowadays, then x265 could be a killer app for AMD, like Cinebench.

[chinobino]

x265-v3.0+1-ed72af837053 (https://drive.google.com/open?id=1Hj4yBUrk_w8yVkkmWFib1gWcGDWeQS2H) [ICC 1900][64 bit]

Redistributable Libraries for Intel® C++ (https://software.intel.com/sites/default/files/managed/72/e7/ww_icl_redist_msi_2019.1.144.zip)

x265-v3.0+1-ed72af837053-multilib (https://drive.google.com/open?id=1rGceIuQCOnGsjpnAMEBfCMNnITmIBLJt) [GCC 8.2.1][64 bit]

Perfect, thankyou.

[hajj_3]

HEVC licensing info article: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Video-Codec-Licensing-Update-129386.aspx

[WhatZit]

HEVC licensing info article: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Video-Codec-Licensing-Update-129386.aspx

"Tragedy Of The Commons” a.k.a. "Stake The Velos Vampires"

[Barough]

x265 v3.0_RC+13-ae085e5cd8a2 (http://www.mediafire.com/file/pl12i5umh5sck83/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

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

NOTE :
Checked with Pradeep (@MulticoreWare) about why the Default Branch haven't been pushed to v3.0 'Stable' and this is the reply/info i got

"
Our plan is to continue to use 3.0_RC on the default branch and have completed tags only on the stable branch. So we don't intend to merge back.
"

[NikosD]

This is only true on server CPU. There is no separate frequency for AVX on client CPU (7700K, 8700K, 9900K, etc.). The extent to which you may see "lower clocks" on non-server is if you are encoding faster and running into the 65/95 W power limit, and in that case AMD will be no different. But this is exactly the case for AMD, that they will not hit that power limit because of better efficiency/ architecture of Zen 2 implementing AVX2 instructions than any Intel architecture so far.

Probably 7nm could help too, keeping the same clocks for AVX2 like all the other instruction sets.

[StvG]

And so far, AVX512 in x265 has only been demonstrated to be helpful on Intel systems doing UHD at slower+ presets...

A simple test with 4K video downscaled to 1080p with avs+ and passed to x265 with avs2yuv, preset slower + ctu 32, AVX2@4500, AVX512@4500:
AVX2 - 7.08 fps
AVX512 - 7.87 fps

Another 1080p encoding with the same preset slower + ctu 32:
AVX2 - 7.68 fps
AVX512 - 8.08 fps

Also:
AVX2 ~ 290W
AVX512 ~ 250W

I'm using adaptive offset for vcore. So my vcore is 1.24v for @4800 (non-avx) and when encoding with AVX2 my core speed is @4500 but vcore remains the same 1.24v. When encoding with AVX512 my core speed is @4500 and vcore is 1.13v.

[nevcairiel]

AVX-512 only reduces performance on server chips because of artificial frequency limits that Intel imposes. After the downclock, x265 actually draws less power and runs cooler, showing how it was unnecessary. Hopefully the next generation of server improves the power management algorithm so downclocking will not be needed.

On Skylake-X/WS and Cannon Lake, AVX-512 only ever increases performance. It will presumably also be the case on Ice Lake.

Actually the offset is needed to maintain stability. I know, because I have a 7900X, and tried to get the best out of it.
You wouldn't notice this problem with x264 or x265, because its AVX512 usage is pretty "light", but if you run some heavy AVX512 tasks on all cores, and don't configure an appropriate offset, the chip just crashes. The energy density of the AVX512 units is just too high for running at full turbo clocks, nevermind OCed.

If x265 is the only AVX512 you ever run, and you want to risk it, sure, you can disable the offset and hope that it never happens. But I prefer to know that my system is stable no matter what software does. :)
But be careful, and do know that you can not judge the requirement from one pretty lightweight workload.

The only way the offset is getting lower is when the cores get more efficient, which they really only do on a process shrink. So hopefully that'll significantly reduce the AVX512 offset, even if I don't expect it to go away quite just yet.

This is easily testable by anyone with such a chip. For example, recent versions of the Intel LINPACK floating-point benchmark will put enough AVX-512 stress on the CPU to cause this.

[excellentswordfight]

A simple test with 4K video downscaled to 1080p with avs+ and passed to x265 with avs2yuv, preset slower + ctu 32, AVX2@4500, AVX512@4500:
AVX2 - 7.08 fps
AVX512 - 7.87 fps

Another 1080p encoding with the same preset slower + ctu 32:
AVX2 - 7.68 fps
AVX512 - 8.08 fps

Also:
AVX2 ~ 290W
AVX512 ~ 250W

I'm using adaptive offset for vcore. So my vcore is 1.24v for @4800 (non-avx) and when encoding with AVX2 my core speed is @4500 but vcore remains the same 1.24v. When encoding with AVX512 my core speed is @4500 and vcore is 1.13v.
I think he is refering to this https://software.intel.com/en-us/articles/accelerating-x265-with-intel-advanced-vector-extensions-512-intel-avx-512

And his statment is true for xeons. I did some tests on a Xeon Gold 6126 and even got lower performance for 2160p preset slow, clockspeeds down almost 20%, while gains of running avx512 gave maybe 10%. OCd X299 platforms are a niche (altough maybe not here).

[NikosD]

That statement makes no sense. If AVX2 does not "hit that power limit," that means that the frequency for non-AVX was too low. As long as it can reach a higher throughput with AVX, that means that either AVX will reduce frequency or non-AVX will be underutilized. But it does make sense in the context of real-world code optimization/execution.

Do you really hear from me for the first time that most non-SIMD code can't utilize a modern CPU in the way that SIMD code can ?

The only way to reach TDP limits of a modern CPU is from optimized SIMD code.

There are other limits to reach before power limits for non-AVX code.

[NikosD]

Non-AVX code can and does reach power limits. SKX 28-core can easily reach 165 W in p95 non-AVX. RyZen 2000 hits around 150 W in p95 non-AVX with power limits disabled (which implies throttling with 95 W power limit enforced). Anyway, SIMD code existed before AVX2, like MMX, SSE, SSE2, SSE3, SSSE3, SEE4.x etc.

For all those SIMD instruction sets, we never had lower clocks not even for AVX1.

AVX2 is even denser than all of those sets, but that doesn't mean that there is no architecture with no performance hit.

Zen 2 could be the first one.

[katzenjoghurt]

Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

E.g. if a character turns on a red light, his face would turn suddenly totally blocky.
Blue light is fine, green light also seems to be a bit bad, but red light is the devil.
Looks like x265 (also x264 I think) detects the scene as super-dark and reduces
the bitrate like crazy.

I doubt that it's just a display thing as I can see the problem on my Dell display,
my Benq display and my Samsung TV.

By now I fix it by scanning every source for red scenes before encoding and setting
zones like crazy via --zones startframe,endframe,b=1.5/startframe,endfr....
Super-tedious.

I was shocked again today after I checked my encoding of Disney's Aladdin...
Red sand with black dots -> blurred to unshaded flat areas.
Red stone wall backgrounds -> bluuuurr.

Looks like I need to double or triple the bitrate manually in these scenes just to keep
the subjectively visible detail level compared to the non-reddish scenes.

AQ3 won't help all too much either. The overall bitrate would get just too high if
I want to retain the details that way. *sigh*

[benwaggoner]

AQ3 won't help all too much either. The overall bitrate would get just too high if
I want to retain the details that way. *sigh*
Raise CFR with aq-mode 3. The question is what looks best at a given bitrate.

I wish x265 gave us a way to change the SAO parameters, so we could adjust how the smoothing works in different luma ranges.

[benwaggoner]

That is why I said that hopefully the next version will have better power management to enable higher AVX and AVX-512 frequency in low intensity workloads.
And we saw thermal throttling for AVX2 get a lot better between Haswell and Skylake SP, so there is precedent for exactly that.

I suspect a truly optimized x265 would actually have different ASM depending on processor generation due to this kind of stuff.

[katzenjoghurt]

Raise CFR with aq-mode 3. The question is what looks best at a given bitrate.

I wish x265 gave us a way to change the SAO parameters, so we could adjust how the smoothing works in different luma ranges.

AQ3 isn't the solution for me...
I tried again yesterday... the file size doubled and still I didn't really
reach the quality I could achieve by defining zones manually.

SAO might add to it... but the issue is also there with SAO disabled.


In fact two of my past problems eventually seemed to come just from
the lighting / red area issue.

I wondered why Star Wars III gave me so much more trouble encoding than other Star Wars movies -> Answer: As Anakin turns evil here, the movie got a more reddish color coding.
https://forum.doom9.org/showpost.php?p=1851237&postcount=6353

Here the problem was in fact the character's dark red hair:
https://forum.doom9.org/showpost.php?p=1848566&postcount=11


With Aladdin I have the same issue now... it's dark red all over the place and super-hard to encode due to that.
It's even a problem in bright scenes.
Everything is crisp... and than there is this character wearing a dark red Fez. And the Fez is blocky and blurry.

[fauxreaper]

Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

Use --cbqpoffs and --crqpoffs with negative values.

[katzenjoghurt]

Woah! These parameters sound interesting! I need to get home and try them out!
Thank you, fauxreaper!

[benwaggoner]

AQ3 isn't the solution for me...
I tried again yesterday... the file size doubled and still I didn't really
reach the quality I could achieve by defining zones manually.
You need to compare at the same bitrate. So try 2-pass VBR or a higher CRF. SDR content can often get away with a higher CRF with aq-mode 3.

Trying the chroma offsets is also a great idea, at least for those scenes. So glad to have —zones!

[katzenjoghurt]

I'm giving up... crqpoffs and its brother also didn't work wonders. The bitrate went up... but even at the maximum of -12 it still didn't reach a detail retention level I liked.

And aq-mode 3 didn't work out for me as well... I went as far as setting aq-strength from 1 to 5, ultimately with a crf of 33 (~6000kbps) but... no.


If someone is out for a challenge... grab Aladdin and try to bring it down to a 5000kbps encoding without totally smeared red backgrounds.
You'll start to hate the ladies at the window at 0:07:19 - 00:07:24. :)

Personally I'll go on with zones... It'll take hours but it will work in the end.

[Stereodude]

I'm giving up... crqpoffs and its brother also didn't work wonders. The bitrate went up... but even at the maximum of -12 it still didn't reach a detail retention level I liked.

And aq-mode 3 didn't work out for me as well... I went as far as setting aq-strength from 1 to 5, ultimately with a crf of 33 (~6000kbps) but... no.


If someone is out for a challenge... grab Aladdin and try to bring it down to a 5000kbps encoding without totally smeared red backgrounds.
You'll start to hate the ladies at the window at 0:07:19 - 00:07:24. :)

Personally I'll go on with zones... It'll take hours but it will work in the end.
What speed preset are you using? Ultrafast?

[katzenjoghurt]

Medium

[benwaggoner]

Medium

Ah. I suggest slower as the fastest preset that really starts exercising HEVC’s more unique features. I might throw in --tskip to see if that might help this weird case. It can sometimes help with sharp and weird edges.

Also, if you have a target file size and are comparing different encoder settings, you really should be using 2-pass VBR. It’s really hard to compare features when both output AND file size is changing.

Lastly, Are we sure that negative values reduce chroma QP? I had it in my head it was the other way around. But I rarely use that feature.

[katzenjoghurt]

http://forum.doom9.net/showpost.php?p=1720028&postcount=2269 :)

[benwaggoner]

http://forum.doom9.net/showpost.php?p=1720028&postcount=2269 :)
Thanks! Yes, negative numbers reduce chroma QP and thus enhance chroma quality.

[jlpsvk]

Ok... give up on Dolby Vision encoding now. Question is. How to encode my first HDR10+ bluray with x265 to preserve HDR10+? Can HDR10+ be played from MKV? Or must be m2ts?

[Selur]

@jlpsvk: What do you use for playback on a pc? (For reencoding HDR-10+ data: 1. extract meta data using hdr10plus_parser 2. reencode with x265 while specifying the extracted data 3. multiplex to the container of your choice)

[jlpsvk]

@jlpsvk: What do you use for playback on a pc? (For reencoding HDR-10+ data: 1. extract meta data using hdr10plus_parser 2. reencode with x265 while specifying the extracted data 3. multiplex to the container of your choice)

Thanks for that. I am playing on OPPO, not PC.

[SeeMoreDigital]

Thanks for that. I am playing on OPPO, not PC.Do you have an HDR10+ compatible TV too?

[jlpsvk]

Do you have an HDR10+ compatible TV too?

yes i have. :) Samsung UE65NU7442

Should I use --dhdr10-opt too??? can i crop?

[Selur]

Should I use --dhdr10-opt too???
should be optional and do no harm, so you can probably use it without running into issues.

can i crop?
I guess the HDR-10+ data would need to be adjusted, since at least the 'AverageRGB' should change when applying most filters.
But since you got the equipment, try and report back.

[Barough]

x265 v3.0_RC+14-46b84ff665fd (http://www.mediafire.com/file/4j25u9ds0mvzklp/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

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

NOTE :
Checked with Pradeep (@MulticoreWare) about why the Default Branch haven't been pushed to v3.0 'Stable' and this is the reply/info i got

"
Our plan is to continue to use 3.0_RC on the default branch and have completed tags only on the stable branch. So we don't intend to merge back.
"

[sonnati]

Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

E.g. if a character turns on a red light, his face would turn suddenly totally blocky.
Blue light is fine, green light also seems to be a bit bad, but red light is the devil.
Looks like x265 (also x264 I think) detects the scene as super-dark and reduces
the bitrate like crazy.

I doubt that it's just a display thing as I can see the problem on my Dell display,
my Benq display and my Samsung TV.

By now I fix it by scanning every source for red scenes before encoding and setting
zones like crazy via --zones startframe,endframe,b=1.5/startframe,endfr....
Super-tedious.

I was shocked again today after I checked my encoding of Disney's Aladdin...
Red sand with black dots -> blurred to unshaded flat areas.
Red stone wall backgrounds -> bluuuurr.

Looks like I need to double or triple the bitrate manually in these scenes just to keep
the subjectively visible detail level compared to the non-reddish scenes.

AQ3 won't help all too much either. The overall bitrate would get just too high if
I want to retain the details that way. *sigh*

HVS is more sensible to yellow-red chrominance (>>550nm)
than violet-blue (<<500nm). Red has always been a mess in encoding, especially when encoding in yuv420 where chroma is subsampled and red pictures appear in their glorious blockiness.

There's still a lot of work to be done to optimize encoders to accomodate for perception: we should improve quantization both in dark picture and red-dominant picture, but this depends also on the viewing conditions (i.e. not so important in small mobile screens)

Not to mention higher order of complexity optimizations like saliency based optimizations or similar.

I have developed many times models that change params using zones-like params to improve the performance of a given encoder. This is one of those cases.

[LigH]

x265 3.0 RC+14-46b84ff665fd (https://www.mediafire.com/file/xnu5ejz4kbmi4ww/x265_3.0_RC%2B14-46b84ff665fd.7z) (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.2.1)

:rolleyes:

[birdie]

Version 3.0 (https://bitbucket.org/multicoreware/x265/downloads/x265_3.0.tar.gz)
===========

Release date - 23/01/2019

New features
-------------
1. option:: '--dolby-vision-profile <integer|float>' generates bitstreams confirming to the specified Dolby Vision profile. Currently profile 5, profile 8.1 and profile 8.2 enabled, Default 0 (disabled)

2. option:: '--dolby-vision-rpu' File containing Dolby Vision RPU metadata. If given, x265's Dolby Vision metadata parser will fill the RPU field of input pictures with the metadata
read from the file. The library will interleave access units with RPUs in the bitstream. Default NULL (disabled).

3. option:: '--zonefile <filename>' specifies a text file which contains the boundaries of the zones where each of zones are configurable.

4. option:: '--qp-adaptation-range' Delta-QP range by QP adaptation based on a psycho-visual model. Default 1.0.

5. option:: '--refine-ctu-distortion <0/1>' store/normalize ctu distortion in analysis-save/load. Default 0.

6. Experimental feature option:: '--hevc-aq' enables adaptive quantization
It scales the quantization step size according to the spatial activity of one coding unit relative to frame average spatial activity. This AQ method utilizes
the minimum variance of sub-unit in each coding unit to represent the coding unit’s spatial complexity.

Encoder enhancements
--------------------
1. Preset: change param defaults for veryslow and slower preset. Replace slower preset with defaults used in veryslow preset and change param defaults in veryslow preset as per experimental results.
2. AQ: change default AQ mode to auto-variance
3. Cutree offset reuse: restricted to analysis reuse-level 10 for analysis-save -> analysis-load
4. Tune: introduce --tune animation option which improves encode quality for animated content
5. Reuse CU depth for B frame and allow I, P frame to follow x265 depth decision

Bug fixes
---------
1. RC: fix rowStat computation in const-vbv
2. Dynamic-refine: fix memory reset size.
3. Fix Issue #442: linking issue on non x86 platform
4. Encoder: Do not include CLL SEI message if empty
5. Fix issue #441 build error in VMAF lib

[LigH]

Hooray, I should have waited one more day... :o

[Selur]

@LigH: Why? Last code change was from 2019-01-25,... 3.0 release was out there since 2019-01-23 -> https://bitbucket.org/multicoreware/x265/commits/72188bd2f03447e71e789a5fd2f10364bb232c2c