Open veikk0 opened 1 year ago
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.
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: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.