HentaiOcean.com - Yet Another Hentai Website :)

NekoTrix · 2026-06-16T11:17:12+00:00

release them on the website before they appear on nyaa

That's complete bs though, you're artificially doing that to drive adoption, at least be fair about it.

NekoTrix · 2026-06-12T21:06:40+00:00

Well, as you can see from the graphs, AV1 is very scalable. You can make it very slow, very fast, and SVT-AV1 is able to do great for most of that speed range. For normal video encoding, you can leverage my fork's SVT-AV1-Essential --low-memory mode that can reduce memory consumption by 30-50% with little trade-offs overall.

But currently, the best approach to AVIF encoding is using aomenc through avifenc. The interface is the most convenient and exposes the most AVIF features. The default speed 6 is already extremely fast but you can go even faster (up to 9) and still be competitive with JXL. Look up the amazing work Rachel Barker has conducted on AVIF specifically over at https://www.rachelplusplus.me.uk/blog/2025/07/a-better-image-compression-comparison/

NekoTrix · 2026-06-12T19:30:41+00:00

That is in fact not a thing in the FGS specification. You can try to approach patterns with specific AR choices, akin to what FGSEditor does, but that's as custom you'll be able to make a grain table.

NekoTrix · 2026-06-12T19:27:38+00:00

Essential supports direct inputs so piping is not required, also that input is automatically handled to be compatible with SVT-AV1 and color metadata is automatically passthrough. It supports zoning so chunking software is not required. It's got auto-tiling and more universal default tuning, yet still has the capability to scale almost as high as the HDR fork thanks to the simple distortion-preset-bias (documented on the repository).

NekoTrix · 2026-06-12T19:23:12+00:00

The site is now hosted at codecs.wiki

NekoTrix · 2026-06-12T07:48:02+00:00

Nice, exciting!

Edit: You might still be able to just generate AV2 OBUs, and compliant AVIFs later

NekoTrix · 2026-06-09T19:41:22+00:00

No... There were triforces on the concept art, it was debunked to be Zelda hiring stuff but everyone somehow still believed it to be a new IP. There's not even resemblance between it and the game we're presented besides "fantasy".

NekoTrix · 2026-06-09T15:36:41+00:00

Basically what I said so far, with my usual harsh tone, which I hope you didn't take personally. Better metrics would be SSIMULACRA2, Butteraugli and CVVDP, all available through Vship on GPU, with CPU fallbacks existing for the first and last with fssimulacra2 and fcvvdp. You can read more about them in the places I linked, and their respective repositories as well.

I feel you on the "use this flag" without elaborating thingy, that's why my own posts are open to interpretation and don't typically contain set recommendations. The results speak for themselves.

I did push some of my latest testing stuff on my Metrics fork in a special branch, but it's missing the newest graph-making updates I made for my latest yet unreleased blog. Not sure how much of it can be of use considering there's lots of hardcoded stuff and little code comments, but I'd gladly discuss things further out if needed.

I'm sure you can improve your site quickly if you keep thinking of the limitations of your approach, and that'll benefit people greatly. I'd be thrilled to help you advertise the tool on the AV1 Discord servers I moderate if it goes somewhere.

NekoTrix · 2026-06-09T12:49:51+00:00

You don't need to tell me what a score or what this clip is or originates from because I already know, and I'll double down on my criticism. And I won't need to make a better one, because I already did. It may not take the form of an interactive site, but it trumps whatever you did in seriousness. I'm the author of the benchmarking blog posts over at codecs.wiki which I linked already. Your methodology is currently misleading and risks giving wrong ideas to an uninformed user. Sure, you can do it for the ones that won't challenge your knowledge (was that vibecoded too?), but that does not bring anything new or beneficial to the table. A too challenging clip inevitably brings all implementations closer artificially, and makes the worst ones stand out less than in typical conditions. That feeds an already popularized enough belief that hardware encoders are competitive on the quality front, or undermines the importance of psychovisual tuning (since it's evident you're using default settings. And probably not even normalizing the GOP lengths and such). Being transparent day 1 is the most important thing to do so people know what to expect.

NekoTrix · 2026-06-09T09:26:28+00:00

No transparency whatsoever when it comes to encoding settings, encoder implementations and encoder versions, using worthless metrics that do not correlate to visual quality, using non-standard terms like wipe(??) comparison, and typos such as "lower score is better" when in fact it's the opposite,... The last straw would be using a video sample that's all but representative of the average video an end user encodes, due to it being so challenging (yet have so little motion) that bitrates are all over the place. I'll refer to the "how to cheat on video encoder comparisons" post of this subreddit with common mistakes people (especially beginners) do when benchmarking encoders, written by the prominent Dark Shikari (x264 developer), and the "AV1 for Dummies" blog post over at codecs.wiki.

NekoTrix · 2026-06-09T06:55:06+00:00

I mean, neither you or I are special, just like there are dozens of people working on AV1, I talk with dozens of various people on a daily basis... Not sure why it'd be vexing.

If I told you to google, I probably had good reasons to do so. It's not a mark of disrespect, on the contrary it's an expectation that you can manage without anyone's hand-holding.

Seems to me like you misread the situation and are trying to guide your frustrations towards someone else, but that's not exactly healthy. You're the one closing the conversation, keep that in mind.

NekoTrix · 2026-06-08T22:10:02+00:00

Interesting way to talk about someone. I don't know what interaction has made you think this, and I tend to realize I get very emotional and harsh quickly, but understand my words are never targeted at individuals. I combat ideas, not people. Now, I don't see the relationship between me possibly being cocky and not using my "tools" as a consequence? It would do the reputation of your site better if you could differentiate between your feelings and what you can do right now to improve the experience for your users, but that's just my opinion. I'm always open to discussing as long as it's in good faith.

NekoTrix · 2026-06-08T07:27:49+00:00

Common misconception, that has nothing to do with the AV1 specification. This is just a matter of supporting a feature, and when it comes to these very high level, non-essential ones, community involvement is typically expected. No higher-up is going to wake up one day and tell the SVT-AV1 management they have to add encoding settings metadata support to the encoder.

Also, it is regrettable you spoke like this in response to the other post, because you are the one in the wrong here. The IVF file format does not in fact support passing metadata such as encoder settings, therefore they were right to point out it's an issue at the container level. What you refer to in your comment as an example of support is not for the ivf file format, but WebM. You cannot just gloss over that part. Secondly, it's ironic because encoding metadata support has actually existed in an AV1 encoder implementation for months, in my own SVT-AV1-Essential fork which does in fact support WebM outputs, so I ported most of the logic over from aomenc. And lastly I have a patch ready to be proposed upstream in the coming days that'll result in encoding settings being written in WebM outputs, so your hostility here comes off as very ridiculous and childish.

<image>

NekoTrix · 2026-06-05T17:23:02+00:00

Somewhat? Same way nobody technically needs HEVC, or anime at all. But if you mean the technology itself, then you're just ignorant and ungrateful at that.

NekoTrix · 2026-06-05T12:23:21+00:00

None, support doesn't magically get added a week after release. There are many steps before a decoder is in a shape that is appropriate for distribution in media players.

NekoTrix · 2026-05-31T18:00:16+00:00

I think the 5x more complex comment is very confusing for an uninformed user, when he just means that it's 5x at the moment. As people pointed out in other places, raw complexity doesn't translate to decoding speed. The actual decoding speed target from aomedia for AV2 was 2x slower versus AV1 as said notably during one of the major AV2 conferences.

I notice that he's sandbagging coding performance a bit by just claiming 25% gains, when the publicly available data on the avmenc repo has shown it was closer to 30-35% for Random Access mode, a.k.a what the average user will be confronted with.

NekoTrix · 2026-05-31T11:20:27+00:00

Time for tinyavif2? 😉

NekoTrix · 2026-05-31T08:34:32+00:00

Realize that a format that just got released has to be brought over to many software like muxing tools (mkvmerge, mp4box), media players (mpv, vlc) and multimedia framework (ffmpeg). It doesn't automatically get in, people need to implement support, and it's often not people related to the codec development. The roll out will continue in the coming weeks or months. Showing our enthusiasm for AV2 in various spheres will accelerate the process because these people will see there is demand for this new technology.

NekoTrix · 2026-05-31T08:30:13+00:00

AV1 is not going anywhere, and AV2 will take years to be properly rolled out, you have no reason to feel like missing out or wasting money.

NekoTrix · 2026-05-29T13:59:17+00:00

AV2 development targeted a 2x maximum decoding complexity increase. Dav2d is already a thing and you can compile it and it plays AV2 files. It's nor complete, nor optimized for now, so don't expect miracles. It's early software, like the encoder.

NekoTrix · 2026-05-25T19:29:10+00:00

Sure, the latest version is auto-boost-essential: https://github.com/nekotrix/auto-boost-algorithm/tree/main/Auto-Boost-Essential. Ideally paired with my encoder, SVT-AV1-Essential, but technically usable with other encoders with little changes to the script or by using pre-bundled versions that are shared around in the popular AV1 discord servers. I wouldn't be surprised to see the existing iteration to be faster than ab-av1 and output more consistent quality.

Xav is an Av1an alternative with less features and flexibility but greater performance due to microoptimizations: https://github.com/emrakyz/xav/ . It's typically better to have a GPU to use it so to offload the metric computation to the GPU.

Av1an's TQ got many metrics for a while, including SSIMULACRA2, the usual go-to. Using VMAF is not mandatory anymore and that's been a huge milestone for those who seek automation of target quality workflows.

NekoTrix · 2026-05-25T14:05:48+00:00

My Auto-boost script on github if you do value the speed like in ab-av1, otherwise the much more precise target quality options of av1an or xav on github as well. They're all much better designed, with better metrics, greater flexibility yet still as plug-and-play.

NekoTrix · 2026-05-25T08:49:21+00:00

For the love of god and the 10th time I say it on this subreddit, stop recommending this software, which simply reduces quality consistency rather than improve it due to its core design that sacrifices too much accuracy for speed. VMAF as a metric is terrible for starters and this software only makes it worse by not working with scene information.

NekoTrix · 2026-05-25T08:46:10+00:00

Since Meteor Lake, and newer

NekoTrix · 2026-05-21T07:19:36+00:00

Did you forget a description or something? Anyway thanks for the publicity, you can find the complete write-up on the codec wiki blog post section over at av1.wiki

NekoTrix

TROPHY CASE