aom-av1-lavish VS rav1e

Yeah you are right, I was looking at the wrong branch in git(the one with the latest commit is https://github.com/Clybius/aom-av1-lavish/tree/Endless_Merging).

Various tunes have been added: https://github.com/Clybius/aom-av1-lavish/wiki/Tune-Comparison

git clone https://github.com/Clybius/aom-av1-lavish

The aom-av1-lavish fork can address this as well with the proper settings

I had never heard of aom-av1-lavish before, so I looked it up:

If you want to explore potentially better photon noise, you can compile lav1sh's fork of aomenc and you'll end up with photon_noise_table.exe (in the 'examples' folder) which supports chroma blending when generating tables and can potentially match your source better. You can follow this guide https://www.reddit.com/r/AV1/comments/s6eh5f/how_to_compile_av1_in_windows_without_crying/ but use "git clone https://github.com/Clybius/aom-av1-lavish/" or we have a compiled photon_noise_table.exe in the #community-builds channel in the discord.

As of November 9th 2022, rav1e for quality consistency, and aom-av1-psy for maximum fidelity in heavy grain scenes and low end performance: https://github.com/Clybius/aom-av1-lavish

A good encoder will look deeper to improve, and deeper, a bit more deeper, DEEPER

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

Again, if anything AOM would be the one restricting licenses to AV1 (if they chose to) except AOM has stated and also published AV1 in a way to allow license free access to development (which allows people to make forks of the official build like it's open source) and usage. (1)(2) I don't see why they would suddenly change this.

You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.

That remember me of https://github.com/xiph/rav1e which is an AV1 encoder

I put in the request for ffmpeg passthrough mastering-display data a few years ago and haven't heard of any support yet.

It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000

It's entirely possible to re-use bits of other HW encoders for the first pass (motion estimation, etc).