x265 HEVC Encoder

[Atak_Snajpera]

We hope to have the improved AQ integrated this week.

That's a good news because x265 on default settings still blurs too much in dark areas.

x265 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/hQF1Ui.png

x264 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/m1JemQ.png

[x265_Project]

That's a good news because x265 on default settings still blurs too much in dark areas.

x265 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/hQF1Ui.png

x264 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/m1JemQ.png
I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

[burfadel]

I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

Is the AQ modified from x264? If so, what about the recently added mode 3 added to x264?
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=d72a85b549acd981a8dae3dc5b71920ab2aeea4f

[Atak_Snajpera]

I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

x265 --2pass --bitrate 1024 --aq-mode 2 --aq-strength 2
http://i.cubeupload.com/SQOWTh.png

[Ajvar]

There's no such thing as 2 pass CRF (there is only 2 pass ABR).

CRF is a rate control mode that doesn't care about the bit rate... it only cares about the quality level. So, when you encounter complex content, the bit rate can soar. Some people use VBV with CRF (a combination known as capped VBR) to cap the bit rate at some reasonable maximum during periods of complex content. This is tricky, as you first have to have some idea of the average bit rate you will get from your CRF setting with your content, and then set the VBV maxrate at a level that is reasonably higher than the average bit rate you will get from your CRF value. Setting a reasonably large VBV bufsize just gives VBV more memory to do it's thing without difficult constraints. I think that 2x the maxrate is a good value to use.

OK, got it, thanks.

[burfadel]

In addition to the new AQ mode I mentioned above in x264, there is this non-committed patch which I believe some people find useful for film grain retention:
http://komisar.gin.by/old/2538/p/x264_fgo_DS.2377.diff

I thought I mention those two since they are for issues people mentioned in x265, I'm sure they could be ported (or the principle ported) to x265 :).

How about scene fade, any issues there?
http://komisar.gin.by/old/2538/p/x264_fadecomp.2208.diff

[x265_Project]

The NAB show starts Monday. We have a private suite where we'll have some great demos of our latest capabilities including real-time 4K encoding, high quality offline encoding, and decoding on a variety of platforms including tablets. We look forward to discussing our product roadmap with all of our customers and partners, and learning more about their plans and requirements.

If you're going to the NAB show, and you'd like to meet up, email me (tom.vaughan at multicorewareinc dot com). The x265 team's meeting schedule is nearly packed from 8 am to 6 pm every day, but we have a couple of slots open on Tuesday and Wednesday. I'll also be at Ben's Compressionist's party Tuesday night, but it looks like I'll get there a bit late.

[Gravitator]

On this show come the guys from V-Nova (http://www.v-nova.com/en/press.html).
There and will be held fights PERSEUS vs HEVC :D

[burfadel]

I guess that's a 'no' to the AQ question I had earlier :D all good!

[x265_Project]

Is the AQ modified from x264? If so, what about the recently added mode 3 added to x264?
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=d72a85b549acd981a8dae3dc5b71920ab2aeea4f

Yes, our dev team is looking at this.

[x265_Project]

In addition to the new AQ mode I mentioned above in x264, there is this non-committed patch which I believe some people find useful for film grain retention:
http://komisar.gin.by/old/2538/p/x264_fgo_DS.2377.diff

I thought I mention those two since they are for issues people mentioned in x265, I'm sure they could be ported (or the principle ported) to x265 :).

How about scene fade, any issues there?
http://komisar.gin.by/old/2538/p/x264_fadecomp.2208.diff
We're always open to reviewing contributions. We're going to be very busy this week, so don't expect fast or thorough responses to open questions. But I definitely look forward to learning more about these patches.

[burfadel]

I apologise for sounding a bit impatient :). Thanks for the work being done on x265!

[mandarinka]

Oh, it is a port of FGO to x265? That thing was a pure hack and probably not too efficient, so dunno if it makes sense to include it upstream, unless it gives really good results...
The fade compensate one was a bit less messy though, IIRC, that might be a usable thing.

[nandaku2]

I apologise for sounding a bit impatient :). Thanks for the work being done on x265!

Sorry for the delay in checking in fine grained AQ. We're looking into a hash error bug in a YUV422 test case, and will check it in as soon as this is resolved.

[zerowalker]

Read about the VBV thing not being what i thought it was, i use it as a cap as i was sure it was just "Birate up to this point".
This is with x264 though, here is my settings: preset=superfast crf=18 vbv-bufsize=40000

So this is actually bad?
I just wanted it to try to limit to around 40mbps in case of some super complex scene as normally it's around 20-35mbps.

(Off topic sorry).

[Motenai Yoda]

Read about the VBV thing not being what i thought it was, i use it as a cap as i was sure it was just "Birate up to this point".
This is with x264 though, here is my settings: preset=superfast crf=18 vbv-bufsize=40000

So this is actually bad?
I just wanted it to try to limit to around 40mbps in case of some super complex scene as normally it's around 20-35mbps.

(Off topic sorry).

I think u mean --vbv-maxrate
http://forum.doom9.org/showthread.php?p=1292411#post1292411

[zerowalker]

Oh, that make sense.
So maxrate is then, more of a constant that tells "This is the limit", not "we can only accept this much data cause of speed limits"?

EDIT: Okay doesn't seem to be the case either;P

[x265_Project]

Oh, that make sense.
So maxrate is then, more of a constant that tells "This is the limit", not "we can only accept this much data cause of speed limits"?

EDIT: Okay doesn't seem to be the case either;P
VBV models how a decoder works. You can think of it as a leaky bucket. The size of the bucket is the bufsize. VBV maxrate is the maximum rate that the bucket can be filled... the maximum rate that the decoder will be able to receive the HEVC bitstream (the channel bandwidth). If the decoder can only be "filled" with data at a limited speed, it limits the peaks and valleys that you can allow in the instantaneous bit rate (a moving average of a small # of frames), otherwise the bucket (buffer) will overflow or underflow.

See https://www.doom9.org/showthread.php?p=1690632

[zerowalker]

Complicated, get it kinda, Buffer tells it how much it can throw as long as it keeps the steady rate, so if it has been low, it can push high awhile to run ahead.
Though maxrate as you explain it makes it sound like a peak limit, which it's not if i get it correctly, hard stuff.

But i guess buffer/maxrate is the closest thing one can get to constrained crf?

Thanks

[LigH]

The bitrate constraining devices may be drives reading from source media, but also networks or broadcasts with a bandwidth limit. Limiting the (per-GOP or per-second) video bitrate to a hard threshold is neither as useful nor as necessary as keeping the predicted decoding buffer filling level in the valid range. The buffer dimensions are designed for some overhead. And even more interesting, high peaks are sometimes less an issue than longer lasting low bitrate scenes (which might fill a decoding buffer with more frames than a GOP has).

[Sleepysonic]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

Will my current processor ever be able to complete this conversion in even just twice realtime (As in, 44 minutes video done in 1.5 hours)?
Currently with these settings, it seems things are 13.8 x real-time. so a 44 minute video would take... almost 10.5 hours to convert... Even if I had 20% faster cores + double as many cores (8) it is still 5.5x realtime.

That means, in a magical world where more cores = more performance, I still wouldn't get realtime even with 40 cores.

[LigH]

Encoding performance will be improved further, especially for AVX2 capable CPUs. Still, the complexity of the HEVC encoding algorithm is a lot higher than the one of AVC, so if you are interested in realtime encoding, don't insist on "slower" presets...
__

x265 1.6+174-4cccf22b00ee (https://www.mediafire.com/download/fnkm1a9k21bcxob/x265_1.6+174-4cccf22b00ee.7z)

Supports a switch for the "Annex B" format internally, which may be interesting for builds supporting already multiplexed outputs. Raw HEVC video shall always be formatted according to Annex B, I was told.

Coming builds may require a decision to be either compatible to Vista without — or to Win7+ with support for NUMA thread pools. May my Win32 builds be XP compatible (and without much use for multi-socket encoding anyway), but my Win64 builds will then probably prefer Win7+ compatibility with NUMA support.

[MeteorRain]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

...

Since when can we do 2-pass slower 720p within 2x realtime?

In the 3rd year after x264 was released, the fastest processor we have is Core 2 Duo, or if you are an AMD fan, Athlon X2 7750. I doubt you can get that speed with latest x264 on these platforms, even on 480p.

== Edit ==

I did a quick encoding test on my desktop. I limited x264 on a single core to emulate an old CPU.
My 4770 has a passmark score of 2238 on single core, the Athlon 7750 has a passmark score of 1576 on all cores.
Encoding a 640x480 on x264 0.147.2538 with --preset slower --tune film --crf 21 gives me 16.5 fps in average.
You can imagine how fast it was in the year 2009.

[burfadel]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

Will my current processor ever be able to complete this conversion in even just twice realtime (As in, 44 minutes video done in 1.5 hours)?
Currently with these settings, it seems things are 13.8 x real-time. so a 44 minute video would take... almost 10.5 hours to convert... Even if I had 20% faster cores + double as many cores (8) it is still 5.5x realtime.

That means, in a magical world where more cores = more performance, I still wouldn't get realtime even with 40 cores.

Unless you require a specific end file size, it might be better to use CRF. If encoding TV shows, by having a fixed end file size the quality of each episode will vary. This is because some episodes require more bitrate than others for the same quality.

Now, in terms of the presets, you need to play around with the settings and work out what works best for you. Start with a CRF of say, 22 and go from there (based on the final file size of a test encode).

For the options, many of them result in significantly more processing time required with little gain in quality.

Try the following settings on the normal preset, it's what I use:
--tu-inter-depth 2
--b-intra
--aq-mode 2
--nr-intra 400
--nr-inter 400
--subme 3
--max-merge 5
--bframes 6
--rc-lookahead 90
--ref 6

Try --me-range 24 or 25 for 720P stuff.


Note that --tu-inter-depth 2 gave benefits for me, but intra didn't. The --nr-intra/inter settings are for noise reduction. I tried to choose a value that works for me. The noise reduction it does is very light (hasn't really affected the encodes), but it improves encoding efficiency. You could always get rid of it, or try a value of 200 or 300 (400 is about the limit of where it is beneficial for encoding efficiency).

So, try those settings and see how you go :). I'm not saying they're right or right for every purpose etc, just that they work for me and provide the best performance/quality tradeoff. The quality loss and file size increase is extremely minimal over settings that make it many times slower.

[x265_Project]

Complicated, get it kinda, Buffer tells it how much it can throw as long as it keeps the steady rate, so if it has been low, it can push high awhile to run ahead.
Though maxrate as you explain it makes it sound like a peak limit, which it's not if i get it correctly, hard stuff.

But i guess buffer/maxrate is the closest thing one can get to constrained crf?

Thanks
You just have to think of how a decoder works in a real-world situation. Keep in mind...
- Hardware decoders have a fixed memory buffer size.
- A decoder may receive the video bitstream from a medium with a fixed, limited bandwidth (read from a storage medium, or receive through a network).
- The number of bits for each frame varies quite a bit, and if too many large frames are trying come to the decoder in sequence, they may not be able to fit through the channel in time.

[Atak_Snajpera]

devs what do you think about OpenCL 2.0 ? More usefull for x265 or not really?

[Ma]

I've made another speed test of 10-bit x265. There are new versions of GCC -- 5.0.1 and 6.0.0.

Builds: I've prepared 8 builds of 10-bit x265 -- GCC 4.9.2, 4.9.3, 5.0.1 and 6.0.0 each in 2 optimize variants -- O2 and O3. All builds with option "-march=corei7-avx". Source code version 1.6+185.

Test movie: http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

Platform: Windows 7 64-bit, i5 3450S.

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

Result:
492-O2 | 463.57s | 0.43 fps | 100.0%
492-O3 | 468.73s | 0.43 fps | 101.1%
493-O2 | 470.43s | 0.43 fps | 101.5%
493-O3 | 467.71s | 0.43 fps | 100.9%
501-O2 | 534.50s | 0.37 fps | 115.3%
501-O3 | 522.02s | 0.38 fps | 112.6%
600-O2 | 533.66s | 0.37 fps | 115.1%
600-O3 | 520.11s | 0.38 fps | 112.2%

Full result and builds: www.msystem.waw.pl/x265/test4.7z

GCC 6.0.0 is fractionally faster than 5.0.1.
-O3 optimize option is better than -O2 for GCC 6.0.0, 5.0.1 and 4.9.3 (this is new behavior of GCC 4.9.3)

So they don't improve GCC 5.0.1 but they destroy GCC 4.9.3 (with -O2 option). Sad...

[Motenai Yoda]

I've made another speed test of 10-bit x265. There are new versions of GCC -- 5.0.1 and 6.0.0.
Can u compare this too? I've simply made it with the build batch and last yasm (1.3.0.6.x).

http://bit.ly/1aQPqVy

@zerowalker u can alway set --vbv-bufsize to 500, but it give me some buffer underflow error, and don't go up to 12000k setted as maxrate, just a bit under 3000k..

[MeteorRain]

I even observed fractionally slower on pgo version compared to the regular one.

[Ma]

Can u compare this too? I've simply made it with the build batch and last yasm (1.3.0.6.x).

http://bit.ly/1aQPqVy

Your build is not working on my CPU -- you probably have AVX2 CPU and you made native build.

[LigH]

Just be careful with new GCC versions, wouldn't be the first time that overly aggressive optimization may lead to invalid binaries (e.g. removing loops which were detected to have no purpose, because their side effects were not recognized).

[Motenai Yoda]

Your build is not working on my CPU -- you probably have AVX2 CPU and you made native build.

Nop I have a Bloomfield one and made with build batch with vs2013 comunity mode "Relase" (was yet setted in cmake)

[Ajvar]

So they don't improve GCC 5.0.1 but they destroy GCC 4.9.3 (with -O2 option). Sad...

As long as your GCC 4.9.2 builds work for me I'm fine. But I guess GCC is like Windows - breaking old which worked fine and building new just because it's new.

[Kurtnoise]

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

why this kind of value for the keyint switch ?

[Ma]

why this kind of value for the keyint switch ?

288 for keyint when I test only 200 frames is quite strange. For normal encodings I use --keyint 288 for better compression (at given crf). 12 s * 24 fps = 288 (this test video is 50 fps, but normally I encode 23.976 fps sources).

[Ma]

Nop I have a Bloomfield one and made with build batch with vs2013 comunity mode "Relase" (was yet setted in cmake)

So it should work, but it doesn't. I see inside the .exe that it needs MSVCP120.dll and MSVCR120.dll -- but if I execute your build there is no error message. Strange...

It could be the reason because I have only 32-bit version of these dll. Could you compile this build with static linking?

[burfadel]

So it should work, but it doesn't. I see inside the .exe that it needs MSVCP120.dll and MSVCR120.dll -- but if I execute your build there is no error message. Strange...

It could be the reason because I have only 32-bit version of these dll. Could you compile this build with static linking?

Install this:
https://db.tt/pLDXUkxh

It removes existing Visual C++ runtimes and installs the latest versions available (some of these are even later than the ones you specifically download from Microsoft as standalones).

It includes the 32-bit and 64-bit runtimes for 2005, 2008, 2010, 2012, and 2015, as well as some key older runtimes.

[Motenai Yoda]

luckily I still have dd45 archive https://1fichier.com/?9qcyeprobh
Note that isn't compiled with test option coz it give me a warning.
CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/CMakeASMInformation.cmake:35 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.

Quoted variables like "ASM" will no longer be dereferenced when the policy
is set to NEW. Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
cmake/CMakeASM_YASMInformation.cmake:63 (include)
test/CMakeLists.txt:1 (enable_language)
This warning is for project developers. Use -Wno-dev to suppress it.

[NikosD]

Install this:
https://db.tt/pLDXUkxh

It removes existing Visual C++ runtimes and installs the latest versions available (some of these are even later than the ones you specifically download from Microsoft as standalones).

It includes the 32-bit and 64-bit runtimes for 2005, 2008, 2010, 2012, and 2015, as well as some key older runtimes.

I think the script is about Office Updates, not Visual C++ runtimes.

[Ma]

luckily I still have dd45 archive https://1fichier.com/?9qcyeprobh

Now I can test. I take only 1.6+200 version. I add my generic GCC 4.9.3 builds (with -O2 option) and generic profiled (in 10 minutes) GCC 4.9.2.

Test movie: http://media.xiph.org/video/derf/y4m...oy_1080p50.y4m

Platform: Windows 7 64-bit, i5 3450S.

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

Result:
10b-492-P | 464.76s | 0.43 fps | 100.0%
10b-493-O2| 465.50s | 0.43 fps | 100.2%
10b-msvc18| 467.52s | 0.43 fps | 100.6%
------------------------------------------------
8b-492-P | 393.19s | 0.51 fps | 100.0%
8b-493-O2| 393.52s | 0.51 fps | 100.1%
8b-msvc18| 395.38s | 0.51 fps | 100.6%

Full result and builds: www.msystem.waw.pl/x265/test5.7z

All builds are pretty equal.

[Ma]

As long as your GCC 4.9.2 builds work for me I'm fine. But I guess GCC is like Windows - breaking old which worked fine and building new just because it's new.

I've made stupid test -- I've compiled x265 with profile procedure but without movies -- x265 runs, displays
x265 [error]: unable to open input file
and exits. This build was much slower than normal (without profiling). So it looks like bad profiled build is worse than not profiled.

Last build I profiled with settings:
./x265.exe --preset slower --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 1920x800-hob.y4m -o NUL ; ./x265.exe --preset veryslow --crf 17 --rdoq-level 1 --psy-rd 0.5 --deblock -2 1920x800-ret.y4m -o NUL ; ./x265.exe --preset slow --crf 22 --ssim --psnr --pme 720p50_parkrun_ter.y4m -o NUL ; ./x265.exe --preset placebo --bitrate 12000 --rdoq-level 1 --psy-rd 0.4 --deblock -1 -f 150 1920x800-hob.y4m -o NUL ;

Do you use any option that is missing in my profile procedure?

[Ajvar]

build was much slower than normal (without profiling). So it looks like bad profiled build is worse than not profiled.
Do you use any option that is missing in my profile procedure?
Not a big surprise for any kind of optimizations. I encode like this but last time I encoded was since 1.6+3 or so, latest downloaded is +174 though.
x265 --preset slower --crf 22.7 --psy-rd 0.5 --psy-rdoq 1 --deblock=-1:-1 --pmode --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 5 --bframe-bias 1 --vbv-maxrate 8000 --vbv-bufsize 16000

[burfadel]

I think the script is about Office Updates, not Visual C++ runtimes.

Oops, wrong link :D.

Here's the correct one:
https://db.tt/9ZYc08hk

[littlepox]

To x265 team:

Currently, I'm sort of disappointed by the grain retention of x265. After hundreds of tests, we conclude that for grainy sources, we'd better use x264 --tune film --qcomp 0.7 if we are trying to encode in middle~high quality. We hope to see improvements soon.

However, for less grainy sources, e.g., anime, we do find that x265 is very capable of providing extremely high quality with low bit-rate. It can easily beat x264 with quality up to x264_crf=16 level.

Our tests focus on 4 paramters: crf, qcomp, rd+rdoq, and aq. Experiences from x264 tell us that these parameters can alter RC behaviors a lot and should be adjusted according to the source-type and quality-expectation; Meanwhile, you don't need to sacrifice the encoding time like using slower ME options.

When you start from a set of parameters and you wish to increase the bit-rate for better quality, one choice is to lower crf. However, increasing qcomp, rd+rdoq or aq can have the similar effect. So which choice is the best given the source and quality-level? That's what is to be tested.

Our tests showed such a combination best suit 1080p anime encoding in middle-high quality:

--qcomp 0.78 (lower crf, higher qcomp. recommend to use values in 0.75~0.8)
--rd 5 --psy-rd 1.0 --psy-rdoq 10.0 --rdoq-level 1
--aq-strength 1.0 (lower crf, higher aq. recommend to use values in 0.8~1.1)
--deblock -2:-2
--rd-penalty 2 --no-sao --no-strong-intra-smoothing (These are parameters we believe to have negative effects on middle-high bit-rate)
--me_range 25 --no-rect --no-amp (These are parameters we believe to be wasting the time under 1080p with almost 0 gain in quality)

We believe this may be a good draft for --tune animation


Important tips from the tests:

1. We use 10-bit x265.
2. We compare the quality with our eyes, NOT psnr/ssim. Parameters favoring psnr/ssim give you nothing but heavily blurred images; we believe that's why currently x265 is poor with grain retention.
3. We think that currently the rc scheme of x265 is not optimized for lower crf values like x265_crf=17. It may do a good job for default x265_crf=28, but certainly there are people wish to set much lower crf. We can have access to qcomp/psy/aq, but there must be dozens of other varible/constants we cannot tweak, and they are the bottleneck under high bit-rate. We hope the team can identify them and come up with some solutions, for example, give us more options to tweak and tell us their behaviors.


Here are some pairs of comparison (right click on the image and open it in a new tab to see the full-size one)
Source_________________________10 bit HEVC encode

https://nmgspw.bn1301.livefilestore.com/y2plKC6Yx6G-AtkCwHdjSPDewBfHCGvkpjQuGknFvthHsJYMsKrrRXoXnDTrX-lUvnTNadQ4CnDIpR8jg40RllYnw16l_WheXBCGbhseBiODpOSi5-eQk2t4V_UEsjAeRxUnBlIrLOlnBM0M9TYwSTGDA/2116s.png (https://nmgspw.bn1301.livefilestore.com/y2pgyhXjttleHnFyfxmmOMqY42x4nsSgwvwRUjdm-R3nQhtXvsM0I0focsGIs3TEza-GqEoDKAjdQgIjie2qQ3uocAQ39xVRYLeud8k_JGHoVQTH-QDVZe4Hxsz9nJqz9IWJKMjRq5DtDG6kul93fSEWw/2116.png) https://nmgspw.bn1301.livefilestore.com/y2plKC6Yx6G-AtkCwHdjSPDewBfHCGvkpjQuGknFvthHsJYMsKrrRXoXnDTrX-lUvnTNadQ4CnDIpR8jg40RllYnw16l_WheXBCGbhseBiODpOSi5-eQk2t4V_UEsjAeRxUnBlIrLOlnBM0M9TYwSTGDA/2116s.png (https://nmgspw.bn1301.livefilestore.com/y2p6_MxGR-Ox9iPzeHfT-h1MUmcqihtlh6h4jjQz8GX3bvfR6Ttl0Bmom01bjhtJE__kxWt9bKVdwBUSYYXGS0ssh_-9cWQlPe_gxfvgBgBt3v_mruEwot12SXiL92FltBcTD2GvRlUJWrvBYqUrlBKgA/2116v.png)
https://nmgspw.bn1301.livefilestore.com/y2peC7pqlRZEYORYJnkxzCP88CCYSI1l5BufVUkN4nEMi3cK6GGtxg5LBxWnQx1NsvUtSxDZLCN709RyVlvv5DYQsJ-unxLYtI5ZHMa7pJaIvGoNrpcODs_a3LRMc6wf-T6YwpvfPr5sNTyxk0TXdMzZA/3092s.png (https://nmgspw.bn1301.livefilestore.com/y2pdb4rIDpmaoKdWvH6TOel8orSAAr327WeXTQKjTYg0J8mqDV74V_kHQ6EGFdr9n20UT3H5aUTZAl9u_cr7N2kKm9A73DnhiN4R7hShab9RXaqkQHzwYippUUh-DVBU48lQQCMdURVp4OSl9L68sJhJg/3092.png) https://nmgspw.bn1301.livefilestore.com/y2peC7pqlRZEYORYJnkxzCP88CCYSI1l5BufVUkN4nEMi3cK6GGtxg5LBxWnQx1NsvUtSxDZLCN709RyVlvv5DYQsJ-unxLYtI5ZHMa7pJaIvGoNrpcODs_a3LRMc6wf-T6YwpvfPr5sNTyxk0TXdMzZA/3092s.png (https://nmgspw.bn1301.livefilestore.com/y2pdqhWC18fdn9r8aYYaMorkCrh266Kz0ZqyNRyzKuESrvvzgOCYW8wb0FQ7akA_lmA_v4CXzTpOqtYxJnaaFeePz-ySumMyFSLexxW97lRve80BSxQGrXz3OC6W-Ul6-GzO3nAJxAAtGSQHfXkVVFWqg/3092v.png)
https://nmgspw.bn1301.livefilestore.com/y2pUwJFsWQ5W1JioN1acx2AoSsy9vfNGzlKFHI43Ydr3H1RGvqdwffJo89J7swp0EHnElL8cAfpuMXsOcVf8JJY-PvOWQad4D1snTAmRuwMBvMO8oW3mpkRRnVul-6kB_9dXY1Btpb6ndL1rBL7khRZLw/5436s.png (https://nmgspw.bn1301.livefilestore.com/y2p3dmhvNeZz0GUnZpawmNwsZdofPSeu18D9-HXqjO1pQ6okN8TU-BZRUUuHweHhScgiLKSa-LIPtmXxrjHSf_RSmp9bex6uoZrMaeWrE_Uh_R_B2X0Nua_r0aNh1UjpimtzxKi-j9_3GVz0jgGQ4_lvQ/5436.png) https://nmgspw.bn1301.livefilestore.com/y2pUwJFsWQ5W1JioN1acx2AoSsy9vfNGzlKFHI43Ydr3H1RGvqdwffJo89J7swp0EHnElL8cAfpuMXsOcVf8JJY-PvOWQad4D1snTAmRuwMBvMO8oW3mpkRRnVul-6kB_9dXY1Btpb6ndL1rBL7khRZLw/5436s.png (https://nmgspw.bn1301.livefilestore.com/y2p_8Fh8-q8fBTUWvwB1dK6SQCqhZ29gkhpcTiFptY-S2tbZrzb63vbB3p6UfPW7FEKi9CHEb4FdgTw8pLuo1tPt-54WNDa5A6e7Rfe_SDswl8925Sy8cCOs19g7FRIQT82xchuEK4vf81POwMW8cIDig/5436v.png)
https://nmgspw.bn1301.livefilestore.com/y2pl-tV1QJv4uKt6QLKFQ0wtBGLAT0yl13GY1LNr_QnjwHRkCYr2ckEXTzcIO1MWz2e0I9UopEpGivHqcIrYB1yNPQVTabpclPnksAaAK8QATPy3WO2ZK6DmXjtFuk771VQxMnIKvglLRrm-LwL8KCsCg/7454s.png (https://nmgspw.bn1301.livefilestore.com/y2pHzTd4ok4rdGYBAOfqKzlE7X8wOBzIt4XD3zsoEwhq54g33COaTbgMscJvM7LbNbZgOPZnMOqjzL5iubgAQtgiXK85mL4XZbuGopffSkH2lQRMphz2Uf9jHTC-OuC_2Q23Olp92kFFRWXxhyv7_t_gg/7454.png) https://nmgspw.bn1301.livefilestore.com/y2pl-tV1QJv4uKt6QLKFQ0wtBGLAT0yl13GY1LNr_QnjwHRkCYr2ckEXTzcIO1MWz2e0I9UopEpGivHqcIrYB1yNPQVTabpclPnksAaAK8QATPy3WO2ZK6DmXjtFuk771VQxMnIKvglLRrm-LwL8KCsCg/7454s.png (https://nmgspw.bn1301.livefilestore.com/y2pQGRZ4yxOmInAd8jlM6BKdJjT1yclHxKNotGts1csBSGU6p38zy_KmhRgnlZtH8oQRSwxc76-9yopjpyh9K7zaXWif5Mcrvgx_DSbwE7LxJxzjzZwPHalIiT-CybzGoxo0RVq4OhPtzA_nBNOZPzQoQ/7454v.png)
https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pvEy7c8rSooPbJf14Ev12QmNJtrqBIRigUJgFn9_9hiQEVHpRpDBaYa2zRXilj5le6Vs8UfQuc8TLFgMGlnX2y8f8rc6I1yfWvZBDAaZa8L0m_ZBfHLSw7NFrFtFTsR592GPdvIhwYSYANNR5bmSYqQ/10806.png) https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pB3kclUn0Oia767B8rpbK7VYn95n_GUH_YDsquRd4LygpXmsfKKpBiPZa3Tqaw0TeK0B-4sTg7kE8YxUvf6OWq2Xli2Py7lrMLAnWGkBPaOGv0t1W1yxAmm6po5j2qhItjXQfGn2EZat9RBEkwjHwCA/10806v.png)
https://nmgspw.bn1301.livefilestore.com/y2pLj7iJIdMaZKWB-O5IaycJnSOZbWO0cv5C2V90tVqvO02TR0dOEImxPgPplYGxjwYyAviicaWrTMfajKaZTY1dBDjnuDpZ5C3eIRwdHaQxu2cJJq6dRA-kIc3YBezAFtIvignF0vFoB8xJI8bhbfFKg/13214s.png (https://nmgspw.bn1301.livefilestore.com/y2prHNMpF-sy4Ie-3eOLlXF1doCq6qVheFIDnSu-j03tM96ofWTE3OEufJoDB639-k8EY3nVCO0r77HAehafe53YuRuNz2KasPq4C5SbdWPOA0Bdfe6H71gMJLskYnVYnbfhveBz-DAFUdIYBAcYRJZUg/13214.png) https://nmgspw.bn1301.livefilestore.com/y2pLj7iJIdMaZKWB-O5IaycJnSOZbWO0cv5C2V90tVqvO02TR0dOEImxPgPplYGxjwYyAviicaWrTMfajKaZTY1dBDjnuDpZ5C3eIRwdHaQxu2cJJq6dRA-kIc3YBezAFtIvignF0vFoB8xJI8bhbfFKg/13214s.png (https://nmgspw.bn1301.livefilestore.com/y2pweddQr7lLZQsUIV0ce5U4kMMV0r218FLi49L3fPWXQznBeezdX0S25fzWwnxC_i1fn37W8XcHbvQhylkm-cJviArVWTxMz_9xOyRKAkx5YOx7tuSJXQWER2q1a3XoR66O92uQZvITA-sOGG3xRYLBg/13214v.png)
https://nmgspw.bn1301.livefilestore.com/y2pWfsn2eOjYu0bCKqAIaEdBcD92zeO9EeJ3uEXLDuAxwBiWJYN9zetnjhs4oMaR8ytY-c0Sgy_h0gXvYRVdmrZZMlUAsaehQ_FQI_3AhDeL-SOVbBd3z31BwIMmkgycasj5DZ3sXz3ypGLj4epJktkcA/15525s.png (https://nmgspw.bn1301.livefilestore.com/y2peCKj65zWibV-R01-J1H9ucqC14DW0LnnkfLLVVVQIdhrte_OGzJ8bpKkcS9U9jPFpypCEdKrx8HxaxSgCuiRRvJbsa0EFSdHakyjhDuUKkS7UoaodhuAfn1R0pJExCekPYCW5FARKiL6nCEYIE9Ppw/15525.png) https://nmgspw.bn1301.livefilestore.com/y2pWfsn2eOjYu0bCKqAIaEdBcD92zeO9EeJ3uEXLDuAxwBiWJYN9zetnjhs4oMaR8ytY-c0Sgy_h0gXvYRVdmrZZMlUAsaehQ_FQI_3AhDeL-SOVbBd3z31BwIMmkgycasj5DZ3sXz3ypGLj4epJktkcA/15525s.png (https://nmgspw.bn1301.livefilestore.com/y2p0a5Ile0o9I_mX9QPukBCGfx78eg3cuZGud3Otb8Md3rBrwMBpFdvSpilZVFuKV63zxdE2V8DNCEqCH_HC8O3iK3krmJV7pkHqNhgwsiVurINJG7ZrJwEylj-ljbZUvcMoLsHOgk9pDoi6l4Xh1BCtA/15525v.png)
https://nmgspw.bn1301.livefilestore.com/y2pHo9clAptcdfAYvlFv6uJoiIh9uh-zc0S_RxFfDuTqGkerF0cHb_jzA_es8dFlYNUOU5xRNm85CRkh7pFp_rmGQRfp25DJdhISpxRGAGG4wpVnYegTY8MaUfXls3wl6iHSRAzQpYLGLpYYSNK_25qMQ/23207s.png (https://nmgspw.bn1301.livefilestore.com/y2pVihdXOST2Up-Bp0f__j71TYTQZUEGabmJpa9M9WxrF9NpMByx2nlMi3MlrdKiUnPqlFcCGZkUCtjNcxHNKeo-O5vYjNua-s-X_N89CnWPADHHkB0aVT-5NnOLK-akbeqxcr4zV5DyiUGfDzFuYXFog/23207.png) https://nmgspw.bn1301.livefilestore.com/y2pHo9clAptcdfAYvlFv6uJoiIh9uh-zc0S_RxFfDuTqGkerF0cHb_jzA_es8dFlYNUOU5xRNm85CRkh7pFp_rmGQRfp25DJdhISpxRGAGG4wpVnYegTY8MaUfXls3wl6iHSRAzQpYLGLpYYSNK_25qMQ/23207s.png (https://nmgspw.bn1301.livefilestore.com/y2pDqgDAp3oNg913uWqpcRCFuzsX6W6-5eU212ZxfaywZDvf6fkyptn8NfKCbWowvyU_uLkBt_wKzJF63LfNgXzO1yB1WUePQBr9PcZmvGKPECNGqYI8FYMdxUKSI8W9KIm1fsX4QEgtmHjb2v7ba0o_A/23207v.png)
https://nmgspw.bn1301.livefilestore.com/y2pn3SRa50k8mN_BtAA_lc4xbP_2YOE1yBo4RrrFQo7DM16hlDj7m7Xpe0kDFAQu28g3RNaxXThCNAFDtM_1oS3McQKN_GRz1HsCLGZOuP-_WzuMNUprSTJYdq88DU_Zsnm6b34rh8TeDAr08WOrXPw1w/23370s.png (https://nmgspw.bn1301.livefilestore.com/y2p3Z3ZQfRSIibK1vVD7-wdnQsDWg5pTKq8OSPsr3VV2CzsHNl43RmeaTQ9A5D10zB0mZJH30jtb5FPI4Ha_r5tu_hZ-2yBE7ClnTsQCd5U-yYuvG2W3afhSl1mJ1u-IPtl0hHPAg4APsTVl0tONSY3bw/23370.png) https://nmgspw.bn1301.livefilestore.com/y2pn3SRa50k8mN_BtAA_lc4xbP_2YOE1yBo4RrrFQo7DM16hlDj7m7Xpe0kDFAQu28g3RNaxXThCNAFDtM_1oS3McQKN_GRz1HsCLGZOuP-_WzuMNUprSTJYdq88DU_Zsnm6b34rh8TeDAr08WOrXPw1w/23370s.png (https://nmgspw.bn1301.livefilestore.com/y2pyqYrIaPdi3QXRBsTkBGYdzke_qio8bXr4pMTQnUEiHe7BpWexJhN-YlZ2I2lcVMcwlwlU2EPme-rB9cGDvtNm0Gefs7nlsSPaAtkeiIRjJDAVlCsYZWrwS3PcX8fAfpFIQQKPyUX_7LbneQBhjP2HA/23370v.png)
https://nmgspw.bn1301.livefilestore.com/y2p2UaZcOuG5K2FSDmAL0OZFeiEDTKc3nR2-JCPiSp0RL6PK3xfMiBoZ1AH5BV0pRX_2tZtmNDSxr0S6MrwyRvKQCRmh96fH-PytLpFSa8jVwABiL9BFEM7jO4tOwm0cWBogATdLE9j-vpOASyb1yzjdg/30177s.png (https://nmgspw.bn1301.livefilestore.com/y2pBDrt8Jacl1hlhDoZL4-JvC5AScLBUlGNlpNOqleS1ads5VLDOdhRzDhgmjlBsdw8l30N6BvTCI0Ckiw0JXhB4HdH5JYB4BblfGfcLGUJNc6u_THzdvns5jYbMFVtUw9XcpWvXtiDODwAbUD0jkjdog/30177.png) https://nmgspw.bn1301.livefilestore.com/y2p2UaZcOuG5K2FSDmAL0OZFeiEDTKc3nR2-JCPiSp0RL6PK3xfMiBoZ1AH5BV0pRX_2tZtmNDSxr0S6MrwyRvKQCRmh96fH-PytLpFSa8jVwABiL9BFEM7jO4tOwm0cWBogATdLE9j-vpOASyb1yzjdg/30177s.png (https://nmgspw.bn1301.livefilestore.com/y2ptrnysgDPzuoTAV_K0U2sS1RFctAb3qWjy4_MypYDM32IeXo4S3yHaKyNd1u6u4Hm04vEIuyHYXLR4k2vg7Iqky-Oa5qukvvMWDi-Zyz4BvSjM64PxwivvZ2SGtVceFd_NHo4T6ypxu8QPIr-vU1J5A/30177v.png)

parameters used for this project: --preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2

[Motenai Yoda]

I think merange 25 is too low for 1080p, with negible gain, and bframes over 5 don't worth it
also rdoq-level for my test 2 give better results than 1 for anime content for the same bitrate (test on crf range 20~25)
at mid-crf (17~23) I'd use a bit less qcomp (.7/.75) aq (.8/.85) and deblock (-1,-1 / -1,0)
and even in your screen there is still a very little bit of detail loss

but those are almost no grain new anime, I'd like to see what u get with old fashioned heavy grained anime too.

ps psnr will be high sensitive to grain retention (at high quality) also most of your settings will increase ssim a lot.

[littlepox]

I think merange 25 is too low for 1080p, with negible gain, and bframes over 5 don't worth it
also rdoq-level for my test 2 give better results than 1 for anime content for the same bitrate (test on crf range 20~25)
at mid-crf (17~23) I'd use a bit less qcomp (.7/.75) aq (.8/.85) and deblock (-1,-1 / -1,0)
and even in your screen there is still a very little bit of detail loss

but those are almost no grain new anime, I'd like to see what u get with old fashioned heavy grained anime too.

ps psnr will be high sensitive to grain retention (at high quality) also most of your settings will increase ssim a lot.

Thanks for the reply.

For me, I've been testing with crf=15~19, that's why I set the parameters more aggressively.

I'd review your recommendations for --bframes and --me_range; would you explain how your tests support your idea? I mean have you tested them and compared the quality/statistics?

For this anime, I performed some slight de-noise on non-edge areas to reduce the bit-rate; so the clean background is expected ONLY on non-edge areas.

I've made the comparison with x264-10bit preset=veryslow crf=16 mbtree=1 qcomp=0.8 aq=3:0.8, They are almost at the same quality; over dozens of screenshot pairs, I cannot conclude which one is definitely better than the other, but the HEVC ver reduces 20% size of the AVC ver, claiming its victory(1.2GB vs 1.5GB). Using x264-10bit crf=17.0 qcomp=0.75 gives similar file-size to HEVC, but the quality is considerably worse.

I've also made some other encodes like SAO II, shirobako, Saenai Heroine no Sodatekata, ...... All of them are "almost no grain new anime", and HEVC can do better than the 10bit-AVC's ver. However, on grainy sources, I'm afraid we should stick on with x264, unless you are a grain-hater and you perform de-grain before encoding.

[RBX]

I have no idea if this works according to resolution, but I encode only 720p videos, and bframes 9 works well for anime, 5 for film content, and 0-3 for videos recorded with cell phone.

[mandarinka]

https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pvEy7c8rSooPbJf14Ev12QmNJtrqBIRigUJgFn9_9hiQEVHpRpDBaYa2zRXilj5le6Vs8UfQuc8TLFgMGlnX2y8f8rc6I1yfWvZBDAaZa8L0m_ZBfHLSw7NFrFtFTsR592GPdvIhwYSYANNR5bmSYqQ/10806.png) https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pB3kclUn0Oia767B8rpbK7VYn95n_GUH_YDsquRd4LygpXmsfKKpBiPZa3Tqaw0TeK0B-4sTg7kE8YxUvf6OWq2Xli2Py7lrMLAnWGkBPaOGv0t1W1yxAmm6po5j2qhItjXQfGn2EZat9RBEkwjHwCA/10806v.png)

You have some weird large block-boundary discontinuities in this frame - around the girl, it's fairly visible if you switch back and forth. Did you use the dump/load analysis data option when doing these tests? I've seen similar trouble with that feature.

[Motenai Yoda]

I get some test with well known test clips 720p, with x264, show no gain over merange 24, 1080p with 32 get a little gain specially on park_run and park_joy (tracking shots), also x265 should aim for 4k.
With x265 park_joy 1080p50 --crf 18 I get those results
merange 24 - 2.91fps, 51765.78kbps, psnr 35.228, ssim 12.801
merange 57 - 3.02fps??, 51685.29kbps, psnr 35.227, ssim 12.801

For this anime, I performed some slight de-noise on non-edge areas to reduce the bit-rate; so the clean background is expected ONLY on non-edge areas.
Yep on non-edge areas there is a bit of loss, source's screenshot are yet denoised? I also notice an artefact near chest on #5 (edit preceded by mandarinka)

unless you are a grain-hater and you perform de-grain before encoding
Sometimes I have to remove (did u see Urusei Yatsura?), sometimes I have to add..

I hope they port aq3 and aq4, or something like triaq...

[littlepox]

You have some weird large block-boundary discontinuities in this frame - around the girl, it's fairly visible if you switch back and forth. Did you use the dump/load analysis data option when doing these tests? I've seen similar trouble with that feature.

Oops, I forgot to mention something important, it is about the defects in psy that I'd like to inform the x265 team:

large psy values can cause this to happen. In high-motion scenes, you can easily find blocks with most of the picture static and only a very small portion, like the background, changing in motion. These blocks are likely to be coded skipped, with the residual unhandled. That's why I actually set the psy values lower than recommended, but still it may happen, as appeared on those screenshots selected randomly.

However, such artifacts can only be found in high-motion scenes; it may not affect normal watching a lot, if you don't watch it frame by frame.

There is no way to completely avoid this unless you disable psy——That would be a disaster since psy is the primary weapon to fight blurring. using lower crf and lower psy generally reduces the possibility. You can find similar problems in x264, but far less serious; it only happens @ very low bit-rate and insanely high psy values.