x265-encoding setting suggestions for cartoon/anime encodes?

[Forteen88]

I've read that low --aq-strength (like 0.5) is good for cartoon/anime. Anyone got any recommendations?
Thanks in advance.

UPDATE: I mean for high-quality encodes, around CRF 18.
BTW, I've also read that I should have as many --refs and --bframes as possible for cartoon-encoding but I don't know what numbers I need to set maximally within main10@5.0 for GPU-decoding compatibility.
UPDATE2: Now I know that setting --ref 6 --bframes 16 is great for anime/cartoon, and it keeps GPU-decoding compatibility (well, maybe 1 less ref for 4k-resolution encodes)!

[MeteorRain]

We are using the tuning from vcb-s, which can be found here (https://github.com/msg7086/x265-Yuuki-Asuna/blob/Yuuki/source/common/param.cpp#L536).

For general purpose we use --tune lp.

[lansing]

I think the best approach is to test it yourself because all anime are different.

Here's my thought, first create a test clip of the anime, stacks all the complex scenes into one for testing, like high motion scenes and dark scenes. Then do some test encodes to find the bitrate/crf point where it gives you transparent result with a high enough preset like "slow/slower". For example, you can probably get transparent result with 3000kb/s or less on older anime, you should be able to get it in a few tries.

After that you can start tuning down the preset to find the lowest needed preset for the same quality as before. Then should you start tuning the individual setting like aq-strength.

[Blue_MiSfit]

I've had some good luck with just increasing deblocking, reference frames, and bframes.

I recently encoded my collection of South Park BluRay discs at 1080p CRF 24 using 10 bit x265 and they came out looking quite nice at between 1 and 2.5 Mbps on average typically.

[RanmaCanada]

There was an entire thread dedicated to this about a year ago. Search is your friend. https://forum.doom9.org/showthread.php?t=174921

Heck all you had to do was spend 5 minutes on the forum and you could have found it.

[Forteen88]

@RanmaCanada. That thread should only be about "baseline x265 settings", so I created a new thread for cartoon/anime.
Also, they had crazy many parameters in their settings :)

@MeteorRain. Thanks, but don't you do newer builds of your x265?

[benwaggoner]

@RanmaCanada. That thread should only be about "baseline x265 settings", so I created a new thread for cartoon/anime.
Also, they had crazy many parameters in their settings :)

@MeteorRain. You don't do newer builds of you x265?
I'd expect some of the older tunings may no longer be appropriate for current x265 builds, with the new lambda table and other improvements.

[Wolfberry]

According to nmm-hd (https://www.nmm-hd.org/newbbs/viewtopic.php?t=1592)

The main difference to regular build is that it added some private patches, mainly to provide humanized changes, without affecting the coding core.

LITE version = MP4/MKV
FULL version = LITE + LAVF/FFMPEG/ZIMG

The project was managed to be hosted on Github, with a dual-branch structure, the Asuna branch followed the stable, and the Yuuki branch followed the master.
The version number has also changed, no longer follow the version number submitted by the official version of Mercurial, but based on the number of branch submissions.

The last time they update their tune lp/vcb was in 5/27/2018, so I guess it is not that old.

[MeteorRain]

@MeteorRain. Thanks, but don't you do newer builds of your x265?

Just saying that it's not the correct way to @ me. Actually this forum does not support @, so you'll have to shoot me a PM or even (feel free to) raise a GitHub issue. Although I'm planning to move the project out of GitHub at sometime.

So, yes I do update x265 from time to time. But since x265 itself is pretty stable now compared to years ago, I'm not planning to update that frequently following the master branch. I'm aiming at providing more stable binaries since there are a few downstream users that rely on those functionalities that I provide. There was once an incident in x265 scene cut detection algorithm change on the master branch that wasted thousands of hours encoding time and varies hours to recall those stuff etc. So we became more careful choosing versions since then.

Current version scheme is that Asuna is following the oldstable branch, which is the 2nd last stable version released (2.7). Yuuki is following the current stable branch (2.8). By the time 2.9 is released, Yuuki will be rebased to 2.9, and Asuna will be 2.8 (usually results the same binary as the previous Yuuki except the encoder signature).

The version scheme consists of 2 parts, the vanilla and the patch level. Vanilla version is version plus commits since being tagged, usually starting at 2 or 3 due to some meta commits. The patch level is the number in the last part, currently +19 on Asuna, and slipstreamed into +18 on Yuuki, fixing a stupid buffer overflow.