aomenc --passes=1 processes running, despite setting --passes 2

[veikk0]

While running av1an with -e aom and --passes 2 in VMAF target mode (using the latest master docker), some aomenc processes are still running with --passes=1. I don't know about the implementation details or if this is a bug or intentional, but from observation I assume these are the probe processes and only the final pass for a chunk is done with --passes=2.

If only running 2-pass for the final encode is intentional and done to save the CPU cycles of running the first pass, I'd like to point out that with libaom and libvpx, the first pass log can be reused for different cq-level/bitrate encodes. So for a given input file, you can just run the first pass once and use the log file for running multiple encodes with different CRF/bitrate settings; the first pass file is identical no matter what cq-level or target-bitrate setting you use.

If you want, you can verify this libaom behavior yourself by running a bunch of first passes at different cq-level settings and calculating the checksums for the log files produced. For example, here's the output of sha1sum * for a directory of log files that I created with different aomenc CRF, target-bitrate, and cpu-used settings:

7b1848135eb622e5eb359ae857328e5eaeb1911e  cpu0.2M.log
7b1848135eb622e5eb359ae857328e5eaeb1911e  cpu0.CRF20.log
7b1848135eb622e5eb359ae857328e5eaeb1911e  cpu0.CRF30.log
7bfc439d5d03a15f0a17180d281f406816e33520  cpu1.2M.log
7bfc439d5d03a15f0a17180d281f406816e33520  cpu1.CRF20.log
7bfc439d5d03a15f0a17180d281f406816e33520  cpu1.CRF30.log
939ba8f8b372a955c57e06c471bf6639ec92d8a3  cpu2.2M.log
939ba8f8b372a955c57e06c471bf6639ec92d8a3  cpu2.CRF20.log
939ba8f8b372a955c57e06c471bf6639ec92d8a3  cpu2.CRF30.log
8ff5ae8363d925c3bea109c08613f24fa6bbc5ed  cpu3.2M.log
8ff5ae8363d925c3bea109c08613f24fa6bbc5ed  cpu3.CRF20.log
8ff5ae8363d925c3bea109c08613f24fa6bbc5ed  cpu3.CRF30.log
f42a2efb70654b58a7be91549ae8d9f4411ffcd7  cpu4.2M.log
f42a2efb70654b58a7be91549ae8d9f4411ffcd7  cpu4.CRF20.log
f42a2efb70654b58a7be91549ae8d9f4411ffcd7  cpu4.CRF30.log
eb533bdaab45c4b6e302d2fc8ae7a0f9c63f5ec9  cpu5.2M.log
eb533bdaab45c4b6e302d2fc8ae7a0f9c63f5ec9  cpu5.CRF20.log
eb533bdaab45c4b6e302d2fc8ae7a0f9c63f5ec9  cpu5.CRF30.log
89947cd7051600e60e2a5d54753627e49b7f681f  cpu6.2M.log
89947cd7051600e60e2a5d54753627e49b7f681f  cpu6.CRF20.log
89947cd7051600e60e2a5d54753627e49b7f681f  cpu6.CRF30.log

Given this, how I'd expect 2-pass behavior to work in av1an when using libaom or libvpx is that the first pass is run only once for a chunk, and all the encodes, probes included, use 2-pass with the log file generated during the first pass.

[master-of-zen]

VMAF mode runs a lot of probes before finding CQ for the final encode. Probes have settings that make them as fast as possible with reasonable deviation from final encode (that being 1 pass with a lot of compression features disabled). If higher precision is important, there is "probe slow" that use your encoding commands for probes.