>Horrible upscale by studio
How's this work for anime that was already 1080p? Thought that kind of stuff was limited to older anime since the resolutions never really match what they put on the Blu-Ray and rarely do they ever do a remaster from the original cels.

>>28877
The only things being produced in native 1080p are high budget movies. Everything else is somewhere between 720p-986p. Usually a mixture of many lower than 1080p resolutions. All of which gets upscaled to 1080p for release.

The only thing truly 1080p in most anime are the OP/ED credits. There are tools to find the native resolution things were produced at and if you're lucky you can downscale them with the same kernel then re-upscale to 1080p using a better kernel than the studio used. MahoAko is sadly not one of the shows where this is an option. So we're forced to employ other tricks instead to deal with the awful aliasing on the BD release.


>>28874
I'm going to make proper guide for this soon but I need to kill time at the moment and wanted to get this down. So enjoy rant/explanation no one asked for. Perhaps someone here wants to learn more about x265 codec and will appreciate this. Here are some settings we use (that no one else uses) and why we use them. We've noticed a certain someone copy/pasting some of these in recent releases but it's obvious they have no idea what they're doing. So perhaps you could send it along to them.

From mediainfo/my local config;

>--input-depth 16
>--output-depth 10
>--dither
The above are pretty self explanatory but worth mentioning because most don't do it this way. We do all filtering/editing in 16-bit. We release in 10-bit. The dither switch tells x265 to internally dither the 16-bit input down to 10-bit. You can do this in your frameserver scripts but there is really no reason to do it manually. This way the codec can make its own decisions about how to dither. There is really no difference though so I'm mostly doing it because I'm lazy.

>--repeat-headers --aud --idr-recovery-sei
These are all related to metadata. They allow the decoder to recover from errors (dropped frames/bad network connection) and maintain some semblance of sanity in those situations. Since we target Jellyfin/Plex clients these are really useful when combined with some other settings used below. No reason why anyone shouldn't turn these on in their own encodes. They cost nothing and add useful feature for anyone streaming over network.

>--level-idc=4.1 --high-tier
We target level 4.1 main usually. For this show we target 4.1 high. This sets some limits in the codec for things like bitrate and amount of b-frames. Pretty much any device can decode level 4.1. Most BD players are level 5+. Anime doesn't really require that high of bitrate so using slightly lower level helps low-end devices decode video using less resources. Resources that can be used for real time .ass rendering instead.

>--vbv-maxrate=49000 --vbv-bufsize=50000 --crf 15
Someone that didn't know what they were talking about said I was stupid for doing the above while using CRF mode. The point of this is to set a hard cap on bitrate. I use -1,000 for maxrate compared to buffer so there is always a little cushion in the bitrate buffer. No frame within the entire episode can be larger than 49,000kbps. Most anime rarely goes above 15,000kbps. Hence this limit is very high and there is absolutely no reason why we should ever get anywhere near it. When using main profile 4.1 we use 20,000kbps/19,000kbps limit.

>--ctu 32
For detailed explanation on what CTU means go here: https://en.wikipedia.org/wiki/Coding_tree_unit

The default in x265 is 64x64. This was made with 4k+ content in mind. We've found that 720p-1080p content benefits a lot from using 32x32 instead. Usually makes for a sharper image that retains more detail. Every source is different though so some shows might be better with 16x16 or 64x64. I do test encodes for each show and pick the best one. 9 times out of 10 that's 32x32. Try for yourself you may be surprised by the results you get.

>-tu-intra-depth 4 --tu-inter-depth 4 --min-cu-size 8 --max-tu-size 16
These all relate to the CTU change above. Allows the codec to make smarter decisions about where to spend bitrate at the expense of longer encoding times. I've found these to be the best settings for anime when combined with the above CTU change. Check x265 docs if you want the math. For now just understand that you should adjust these away from the defaults if you change your CTU setting.

>--hevc-aq
We do not like using x265 or any codec forks if we can help it. In main branch of x265 there are only 3 standard AQ modes and this separate AQ mode. It should really be AQ mode 4 instead of its own thing. But they did it this way for some reason.

As this feature has been marked experimental in the docs for years no one seems to test it. I haven't seen it used in the wild by anyone doing anime. Which is sad because it's really good with animated content. I tested it when it became stable a couple of years ago and ended up liking it more than AQ mode 3. So I've stuck with it. I've tried the x265 forks with AQ mode 5 and it doesn't give me as good of results at this AQ mode at the same bitrate. I encourage you to try it. It's basically a more dynamic version of AQ mode 3 and allows the codec to spend more bits in areas that benefit from them.

>>28881
cont.

--rc-lookahead=120 --lookahead-slices 0 --frame-threads 1
120 is kind of overkill for this with our GOP settings but we use it anyway for one very important reason. This loads 120 frames into RAM for the codec to analyze when making decisions about what kind of frames to place within each GOP. Lookahead-slices are disabled to force codec to look at entire frames when making those decisions. frame-threads 1 forces codec to not split frames it's looking at over multiple threads/cpu cores when making decisions. We're trading a lot of speed on multi-core CPU for gain in overall quality of each frame here. If you go for a lot of parallelization with multiple slices+frame-threads you're forcing the codec to guess in a lot of situations simply because it can't see entire frames when it's calculating where to spend bits.

>--no-sao --strong-intra-smoothing --deblock=-2:-1
The above get changed from series to series. We do not consider the SAO in-loop filter to be that bad anymore despite the reputation it gained in the early days of x265 of "smoothing all objects". Sometimes we employ it in a limited mode instead of turning it off. Deblock is similar and we tend to leave it on to let it do its thing. We search around for the best settings for each show. We always leave strong-intra-smoothing on because when it's needed it really helps out a lot.

Basically, none of these in-loop filters really matter at the bitrates we're encoding at since they only do anything when you're near the bitrate limits. As I said before most anime gets nowhere near those if you know what you're doing. Each source is different so don't take the advice you see peddled everywhere about these as gospel. They're really really good for what they're designed to do.

>--bframes=8
We limit bframes to 8 max for several reasons. Mainly, that's what the level we target specifies as the maximum. But also because long strings of b-frames are very hard for the codec to decode on lower end hardware. Most people shoot for as many b-frames as possible without any care in the world about what might be decoding them. In truth, b-frames do not save nearly as much space as people think and you'll rarely get strings of more than about 6-8 b-frames even with mostly static content. Which brings me to my next point.

>--no-open-gop --min-keyint=1 --keyint=120
GOP = "Group of pictures".

Most encoders use "open GOP" aka "infinite GOP". This means the codec can use long strings of p/b-frames and only inserts I/IDR (real frames) during major scene changes or similar situations. This is _very_ taxing on lower end hardware but it also has another bad side effect. Which is it increases seek times by a lot and requires far more CPU to do random seeking within the timeline.

What the above settings do are;
1) Force "closed" GOPs meaning a "real frame" is inserted every <x> number of frames no matter what
2) Set the maximum number of frames in a GOP to 120 frames (or 5 seconds)
3) Allow the codec to insert an I/IDR-frame anywhere in the timeline (keyinit=1 means it doesn't have to wait <x> number of frames to insert another "real frame")

Result is seeking times are very fast on all devices. Lower end devices don't stress out a lot decoding random frames. This does not bloat up file size as much as you might think. The "bloat" is worth it for the improved response times. You could burn an encode we do to disc and play it back on old BD player and it would seek just as fast as high end CPU running mpv.

>--tskip --rd-refine
For whatever reason this is _really_ good for animation but it requires turning on some other slow settings (rd=6) and slows down encoding time by hours on my CPU. But the benefits are worth it. Trust me I've tested this with a bunch of stuff and it should be on by default if you're doing animation. There is a "fast" version that gets you most of the benefits without the high cost in CPU time. But since I use such aggressive settings elsewhere it only saves me like 1-2 hours for 12-36 hour encodes per 24 minute episodes.

It's magic math.

>--rect --amp
More magic math that will allow you to heat a small home in the middle of winter. It basically does more scanning of CUs than the codec would do normally. Hours of CPU time for maybe a little gain in compression/quality. I leave them enabled because I'm a madman. There are "fast" versions of these but I don't get much benefit from using them.

>>28882
cont. last

>--crqpoffs -3 --cbqpoffs -3
These allow you to spend less bits on chroma channel and use them for luma channel instead. Never go below -3. Most shows should use -1 or -2. Never go above 0 (for anime). Someone copied this from my last release and set them to -5 because they don't know what they're doing and do not read the man pages. So their "work" ends up looking pretty awful.

In fact, he seems to insert the number 5 for anything he isn't sure about. But another story for another time. You have to play around with these for each and every show you're doing to find the best setting for it. Typically, they should be set the same for both options. At least I've never run into anything where setting them different provided any benefits.

>--cu-lossless
What this does is pretend to do a lossless encode for each and every CU. Then it compares it to the lossy encode. If they're close it uses the lossless CU instead of the lossy CU. It costs A LOT of CPU time but when you're using the bitrates I'm using it's very beneficial.

>--zones 2972,3689,b=1.3/3788,5778,b=1.8/6943,7333,b=1.8/7489,7632,b=1.8/7785,7843,b=1.3/8377 etc
Probably the most important of all. Zones are pretty widely used _outside_ of anime encoding scene but rarely used within it (because again none of them read man pages and it's cargo cult). What this does is allow you to manually boost/reduce bitrates for ranges of frames.

What I do is go through each and every episode I encode looking for dark scenes, scenes with lots of motion, scenes with a lot of red color and scenes that might suffer from banding. For those scenes I manually boost the bitrate up sometimes doubling it for short bursts. After initial test encodes I'll go back and find the most important scenes or places where the codec struggled. Those scenes get boosted up by at least 1.2x. I typically do this from a txt file but in this example I'm showing you how to do it from the CLI.

There are some other things to cover (lots of them) but I don't have time to keep going right now. I was surprised when I found out just how little most people releasing anime know about codecs these days. Most seem to be copy/pasting other people's settings and using the same settings for everything with very minimal modification. They're doing the same thing with their *synth scripts/filtering. You'd be shocked to find out just how bad things really are.

Someone insulted me and has attempted to blacklist one of my releases from all public sources. They even refused to include it on that popular fansub comparison website. He claimed my release looked awful in all public places with comment sections. Yet every release he's made since then is a copy/paste of my x265 settings with stupid modification (like the -5 example above) because he can't be bothered to read man pages.

Speaking of reading man pages. We were forced to go hunting for .dll files on discord of all places a few days ago. While we were there we couldn't help but grep through past conversations. We quickly discovered that most of the people doing releases in the last couple of years on English websites are in fact ESL. While we don't really care if someone is ESL we do find it very ironic that they want to release things in a language that isn't their native language. We also find it ironic that most of their issues could simply be solved by reading English man pages.

We were forced to retreat from the enemy's territory because we felt out IQ dropping like a stone. We never engaged the enemy. We simply lurked. We won't be going back. The .dll took us 4 hours to locate and it didn't even work. We ended up writing our own script instead.

I hope this rant is helpful to someone out there.

>>28881
>--hevc-aq
One other note about this since you won't find it covered anywhere on the web. When using this AQ mode you should adjust your CRF (constant rate factor) setting by +2-4. What I mean is

>aq-mode 3 + crf 12
is almost equal to
>hevc-aq + crf 15
if hevc-aq and aq-mode 3 were 100% equal. You'll see a lot of people attempting to judge an encode without watching it based on what CRF setting was used. In reality CRF depends on _every other setting_. So things can change a lot depending on what is and is not enabled/disabled. I've found the forked x265 AQ-mode 5 to be nearly equal to aq-mode 3. In fact, it's the same aq-mode it just has a different algorithm about how it spreads bit into dark areas of scenes.

hevc-aq is unlike any other aq-mode in x265. If you enable it the codec will automatically disable all other aq-mode settings even if they're defined _after_ your hevc-aq switch. That's how different it is.

I've found hevc-aq to be much better than the others. However, a lot of people that don't know better might pass by something I release at say CRF 18 because they think the CRF 15 encode someone else did is "better". In reality you can't judge stuff just based on mediainfo unless someone is doing something really stupid and obvious (which a lot of people do).

Point being. If you haven't played with it yet expect your file sizes to get _very_ large if you use the same CRF settings as you do with other aq-modes. I typically stick to about 15 with this aq-mode and that is near-lossless in almost all situations. Really I should be setting it much higher to something like 17-20. But I don't mind if the files are a few 100MB larger since anything under 1.2-1.5GB is acceptable to most people these days. Although ideally I try to aim for about 500MB per episode when I can get away with it. 500MB with my x265 setting should be comparable/better than the standard 10-bit x264 encode at 1.2+GB.

Please excuse my autism. I'll have fun things for you to download from here again soon. We're going to release MahoAko in 4-5 batches as BDs come out. Then when we're done with that we'll do a proper archive release with manga+OST+everything else we can track down like we've done for other things.

We'll be retaining our same group tag for awhile this time since so many people flooded into the public comment sections last time. Typically, we would use unique tag for each and every release we do since it helps us avoid the whole name problem and the associated problems that come with it.

Take care!

are you gonna be including the scanlated manga or the official one? both have their derpness and i haven't seen any serious attempt at comparing them
also i have a really kuso laptop i can try this, integrated graphics from over a decade levels of bad
>>28884
>--hevc-aq
>One other note about this since you won't find it covered anywhere on the web.
well you made me google it out of curiosity and i came across an interesting thread:
http://forum.doom9.org/showthread.php?t=182534
i assume you're familiar with these guys, but there's a comment here that caught my eye
>Any updates on this topic?
>Yes, what was being developed as --hevc-aq was completed as --aq-mode 4. Don't ever use the old version!
there's more but i kinda got lost there honestly

>>28885
We typically do scanlation
>doom9
You should be aware that the man you're quoting is mostly interested in selling his book and the fact that he works for amazon has little bearing on his knowledge about codecs. He is not a developer.

It's true aq-mode 4 and hevc-aq are similar. But they behave very differently in practice. Also mode 4 is so recent the official documentation doesn't even mention it yet: https://x265.readthedocs.io/en/2.5/cli.html#cmdoption-aq-mode

"Mode 4" can also refer to two or three different modes that have been in 3rd party builds for years that all behave slightly differently.

In other words; He might be right. But you'll notice that was posted only last month. In addition, x265 devs have closed ranks as of about 2020 and no longer maintain public repos. So even if he is right there is zero documentation or release notes to be found on the web. You have to get in there and read the source code (after you find it) and frankly I'm not the interested in changing my ways mid-stream for something that may or may not provide the same benefits as I'm already getting.

This is a huge problem with their entire rats nest in general. Scripts are hidden in private discord channels. Codecs no longer have public repos. Bad advice is peddled around as gospel. People that know are shouted down by people that don't know. Certain people establish themselves within the community as being all-knowing then try to sell you snake oil (BUY MY CODEC BOOK! I WORK FOR AMAZON PRIME!). On and on it goes.

Frankly, even if it were true I'd be inclined not to believe it just because of who's posting it on doom9. Don't get me wrong. There are some smart people on doom9 and I'd prefer all information be openly posted there like the old days. But there are just as many jackasses. They're just like the ones locking away .dll files and scripts in discord chats behind moderator walls. Then making you take 100 point test for entry. Once you're in you discover the .dll doesn't even work and the script is just renamed version of something a guy named mfToon released 25 years ago.

There are a lot of people peddling voodoo in other words.

But I'll grab the source code and check. Since I need to update my local version anyway. Typically, I stick with a stable version for 2-3 years and never change mid-project. So even if it were true my local build probably doesn't have the update yet. If it does I am sure it isn't mathematically the same. Meaning many test encodes at 8-36 hours each. Just to find out what changed and how to adjust other things to work around it. Probably all I'll discover is there was no point in changing anyway. We're not talking about much different. It's just a different mode where you hope the codec automatically shifts some bits to a different area of frames to save you like 20kb per 10 seconds of video tops. Things are really that good and have been for the last several years. In the words of nyaa
>What are you, poor?

At any rate I didn't know because I neglected to check the forum in the last month. That's how recent the information is. I'm typically pretty on top of this stuff. It'll be months before I incorporate it into my work flow even if there is a benefit. Even then I'm sure someone somewhere is already crying that aq-mode 4 isn't as good as Random guy's x265 custom anime edition build with aq-mode 666 and extra -03 optimizations. Like I said it's cluster fuck.

I was actually looking at that thread back in January and it barely had 10 replies. All I can tell you is what works for me. The aq-mode is actually the least of your worries if you're just starting out.

Also you'll notice most everything in that thread is about 3DPD encoding. The rules are different when you're dealing with gradients, lines, static content and bright colors. You can spend a life time working on 3DPD content and not be able to produce a passable 2D encode even with that knowledge base. I came at this from the other direction. I'm pretty useless with 3DPD stuff. I can do it but I certainly wouldn't share them with other people.

>>28886
interesting, interesting, it really is super recent and that makes sense
(i can't believe 1999 was 25 years ago)

>>28887
Time flies. Also I should have mentioned. You can browse the source code for the official branch at bitbucket. But no one outside of the in-group can submit merge requests. Also they used to host it openly on github but they yanked it down a few years back because drama/copyright/blah blah blah. So a lot of people that were contributing left for AV1. Which isn't going to be used by anyone outside of a handful of crazy folks for another 10+ years (no hardware support, no set-top support).

hevc-aq vs. aq-modes 3/4/5 is also very source dependent. They don't do anything end user side that makes a difference. It'll all play fine in the standard decoder even the "hack" that is aq-mode 5. It's only different on the encoding side of things. So even if hevq-aq was "broken" and "old" as such it will still continue to work until the heat death of the universe. So one could work with it as I have and produce good results provided they were willing to work with it instead of against it.

Most people are just throwing garbage in and getting garbage out and calling it good. In truth I don't really require an aq-mode to pull bits to dark areas of the picture. I'm already doing that by;
1) Injecting artificial grain into darker scenes via scene filtering
2) Manually boosting bitrates for those scenes using --zones

Another thing you might find interesting; There is another "experimental" feature called --aq-motion. It does some math magic in all aq modes to pull bits to areas where there is motion. Neat right? Here is the problem. No one uses it. The docs haven't been updated in at least 4 years concerning it. No one seems to have worked on it in that time. Most people don't know it exists.

But if you have good google-fu there is an anime blog or forum post from years ago that suggests using it for "high quality BD encoding of anime". Yet it doesn't describe what it does, why it's better or what groups have used it. So it's basically ones guy's word that didn't even bother to leave any contact details.

Most likely he threw random BD at it and thought it looked better to his eyes on his monitor on that particular day. But now it's gospel. Since he's obviously the authority of such subjects since he's got a thread on encoding forum that is referenced by every newbie trying to break-in to this stuff.

The journey for every encoder is the same; You decide you want to start playing around with this hobby. You find doom9 forums. You find out all the information is very outdated. You turn to discord and the "experts" from the private trackers and nyaa for help. They tell you the information on doom9 is old and bad. You trust them. You spend weeks downloading their scripts and chasing down crap in various chat rooms that aren't hosted on proper websites for some reason. You mess around with python and vapoursynth for days. You break python install somehow. You fix it. You spend 12-24 hours at a time waiting around for test encodes to finish. They look like crap. You go back for more advice. No one wants to help you because you're a newbie. You do this for years.

Then at the end of your journey you discover all the experts don't really know much at all. For example, they can barely speak English, they couldn't pass high school algebra and they usually have bad taste in anime. The foremost "expert" on anime on discord right now is a guy that rips anime from CR and other web services, runs it through a python script and publishes the results to a blog. Everyone praises him like he's anime jesus. Half the time he didn't even run that script correctly and his information is wrong. You can verify it yourself because if you can into python interpreter and download the public script you can get the result yourself in 60 seconds. Since it'll automatically descale/rescale with every available kernel and spit out a fancy graph for you.

Then you go further down the hole. You start seeing the same names you've seen on trackers on the discord channel. They're talking about inane bullshit and admit to the dumbest things. They link directly to posts on /a/ and cry about them. They don't understand humor. They admit that they don't like the anime they're releasing. They admit that they don't know what DAR/SAR and NTSC/PAL means. Along with other grade school-tier knowledge about video that even my out of touch father knows. They admit to doing stuff like keeping other people's work off the public trackers and engaging in witch hunts/shaming campaigns to get people banned from such places. They link directly to comment sections and threads and ask everyone else to dogpile in. They call 16 year old anime girls "lolis" and claim everyone is a pedophile/homophobic/nazi/today's buzzword while also claiming they're being oppressed/mistreated/don't like bullies/don't like use of slurs. You know the type.

It's at that point when you realize they probably aren't worth paying attention to. But also that their scripts and advice is just re-packaged avisynth script from 25 years ago. Oh and the avisynth version uses half the RAM and runs twice as fast. Oh and it produces a better result. But it's "old" and "bit rotting" so you shouldn't even try it. Just ignore that thread on doom9 where a guy is keeping all that stuff up to date and constantly adding new features. You should use vapoursynth instead. Where the editor takes 50 seconds to open on a modern CPU and freezes all of the time for no reason.

If I sound old and bitter it's because I am.

This is probably the signal most frustrating hobby to get into as a newbie.

Erhm, i didn't read your huge ass posts but ganbatte!

If you are so inclined to use third party builds something interesting came out about a week ago.

https://github.com/jpsdr/x265/releases/tag/3.50.116

Grab the build from there (or source code). Instead of --hevc-aq you'll want
>--aq-auto 10
What it does:

This third party build have implemented yet another hack on top of the aq-mode 5 hack. It'll automatically switch it on/off for each frame based upon some magic math you can read about in the readme. Note for HDR you don't want "10". I think you want "6" but I haven't converted over from binary or tested it yet.

This might be interesting enough to get me to finally move off official builds. But that remains to be seen. Last time I tried aq-mode 5 I wasn't that impressed with the results despite everyone claiming it was the best thing ever. I was getting better results using my manual method of dealing with the problem it's trying to solve.

But note I am an odd-ball by modern standards. Most of these guys aren't even QCing or even manually encoding anymore. They have batch script to automatically rip from CR (or grab rip from tracker) -> feed to script+frameserver using standard script -> feed to encoder -> feed to muxer -> feed to crc application -> post to tracker using standard template.

Hence why quality is so bad. The leechers are the quality check. Same reason why no one is doing original translations anymore aside from the few remaining hang-ons from the old days.

>>28893
I read your short post and I chose to reply to it to be kind.

>>28894
I got interested enough that I killed testing encode I was doing to test aq-auto. I'll let you know how it compares in about 9-12 hours.

>If anything bothers you about existing TLs of anime speak up now or forever hold your peace.
I'm patiently waiting on someone to do justice to Kaiji S2.

>>28874
>and beg for free labor
what do you want?

Oh are you moving your discussion to here from the /qa/ thread? Well, I'll just link what I said there >>>/qa/122453

up

>>29618
not much

>>29143
>>29635
Might as well move it to /qa/. I forgot I posted that other thread. I got really busy over the course of April-early May with IRL stuff.

I replied to the thread on /qa/ for those interested. I'll move discussion back to this board if in the future it's required. I mainly posted it here originally because I wasn't sure if you guys wanted to attract any attention but it seems that isn't much of an issue.

>28921
I'd eventually like to re-release this series as well. I recently re-watched it after including it on our media server and the subtitles are frankly very bad even for season 01 in the more popular releases.

>>28895
To whomever asked about this; I ended up doing my own custom builds for x265 after playing with the new AQ modes and some third-party patches (along with some of my own modifications). They are slightly better for some content but not as good as hevc-aq for others. I just wanted to say the guy linked at doom9 claiming the new AQ modes are just "finished hevc-aq" was wrong after looking at the source code some more. The new AQ modes operate very differently. They are basically just slightly modified versions of AQ modes 2 and 3.

At any rate going forward I'll be encoding most things with my custom builds as they support both and let me shitpost in mediainfo for the lulz. Current build is "Meat Banana Edition" as suggested by a friend I work on Onimai with. If you're interested in my builds and patches I'll try to upload them somewhere soon.

As per-usual I wrote some novels. You can find them here.
>>>/qa/124411
>>>/qa/124412
>>>/qa/124414
>>>/qa/124416
>>>/qa/124418
>>>/qa/124421
>>>/qa/124423
>>>/qa/124424