I recommend using two pass. CRF is different in AV1 compared to HEVC, you can two pass it and it gives much better results.

That's true for VP9, that's not necessarily true for AV1. Fun fact with encoding. Ignore common knowledge unless you see hard benchmarks. https://preview.redd.it/ci1i7tir2o241.png?width=1022&format=png&auto=webp&s=cc3b8b1c9c89a816c35f19f3e1e21071a9d273b1 https://old.reddit.com/r/AV1/comments/e65dhl/libaom_vs_rav1e_vs_svtav1_test_results_with/

You gave an example of SVT encoder which has been proven many times to be very unstable and not that great efficiency wise, but has great multithreading. Judging from your command, you are using AOM which DOES benefit from two pass CRF. Additional note: AOM(libaom) > SVT > Rav1e Rav1e as of right now is just bad, don't use it. SVT is very unstable and you will rip your hair out trying to figure out whats not working. We had many many issues with it until we just dropped it. AOM is the most realistic choice with the biggest problem of it having poor multithreading (recently there was an update that improved it)

@2ndfire Why are you using my Benchmarks in a wrong way? What you are looking for is the Graph for libaom / aomenc: https://preview.redd.it/p4og3f0vvyf41.png?width=1433&format=png&auto=webp&s=487a0d3c8b485834d1259746210c3365d1d61470 All Results can also be found in the Excel Spreadsheet on the Reddit Post. 2 Pass encoding does help. It certainly gives better efficiency.

Very well, but then the question arises of does that small gap justify the massive increase (nearly double? Haven't done 2-pass with libaom) in encoding time, vs lowering cpu-used or something?

The way two pass works is this: First pass is being done at a very high speed (orders of magnitude faster than second pass) to gather information about the video, for example: where are the complex scenes, how it should filter specific parts and a bunch of other AV1 specific stuff. Second pass is done at the regular speed, which would be the same as using single pass, but because the encoder has a log file it can allocate the bits much more efficiently. Don't quote me on this, but the vmaf improvement is significant (almost 1 point higher if my memory serves well). Your encode is going to be around ~15% slower but with major improvement to the quality, so in the end yes it is very worth it. I would recommend doing higher cpu-used value and use two pass if you really care about speed, you will get better encode without increasing the amount of time you spent encoding. Hope this helps

@2ndfire, why not use a tool like av1an/qencoder and neav1e for the GUI support? They can do worker chunking, which can drastically increase multithreaded efficiency, and things like Boost to increase bitrate efficiency even further And since they can use separate builds of aomenc/rav1e/SVT-AV1, you can just use the latest builds separately on Windows/linked builds on Linux distros for maximum efficiency and speed improvements.

I was manually spltting them and running them in parallel and using nightly builds I was building myself. I also don't really care about GUI support, as I'm used to CLI. I will inspect those tools to see what they offer. > First pass is being done at a very high speed (orders of magnitude faster than second pass) to gather information about the video, for example: where are the complex scenes, how it should filter specific parts and a bunch of other AV1 specific stuff. TBH that should really really be done already via lag-in-frames as it's reading ahead already.

No problem then. You should really look at av1an still. It does chunking natively, which is great, but also supports a feature called Boost, which literally boost your CQ value according to psyscenedetect. This can allow for higher efficiency encoding on average, and give a higher bitrate to the scenes that need it. Finally, have you thought of using the argument --auto-alt-ref=1? This can be used to up encoding efficiency with barely any runtime cost, and increase decoding performance slightly. Only works in 2-pass mode.

auto-alt-ref=1 is a default now I thought. I looked at the boost, but it wasn't super clear how it worked. It appears that a 1st pass takes about 1/6th the time of a normal pass. I'm letting a test of clip of akira finish so I can compare quality.

That's bugged as fuck: 1-pass:[Parsed_psnr_0 @ 0000000003615740] PSNR y:31.288868 u:47.208504 v:44.831591 average:35.766977 min:22.868975 max:47.058213 [Parsed_ssim_0 @ 000000000360a200] SSIM Y:0.970418 (15.289727) U:0.984849 (18.195507) V:0.977769 (16.530456) All:0.97767 2-pass:[Parsed_psnr_0 @ 000000000220c880] PSNR y:33.039747 u:47.237377 v:45.010236 average:37.390855 min:23.969115 max:46.884770 [Parsed_ssim_0 @ 0000000003739d40] SSIM Y:0.972183 (15.556819) U:0.984869 (18.201276) V:0.977957 (16.567201) All:0.97833 They should be identical for CRF, most codecs (including av1) already scan ahead (25 frames in this case) already. Guess we're stuck with 2-pass until they fix it.

Nope, auto-alt-ref=1 is still not a a default parameter.

ARG_DEF(NULL, "auto-alt-ref", 1, "Enable automatic alt reference frames"); warn("auto-alt-ref > 1 is deprecated... setting auto-alt-ref=1\n"); ?

Well, that's new. It should work by using --auto-alt-ref=1 fine. Above 1 is not needed.