Open veikk0 opened 1 year ago
The caching is based on saving results from a previous sample-encode run and re-using them for identical future sample-encode runs.
If the min/max crf changes it'll change the binary search crf points (starting with the mid point) so run different sample-encodes and not make use a cached values.
If the new crf-search wants to sample-encode a previously analysed crf it will use the cached result, but the algorithm isn't otherwise aware of previous runs.
Thanks to the cached results, it would be very efficient if the previous CRF and VMAF results of the previous runs were taken into account as a delimiter for the next binary search, taking the upper and lower (if they exist) CRF values of the previous run results with the VMAF score closest to the current target, and acting as a minimum when the VMAF from the previous run closest to the current target was higher than current target, and acting as a maximum when the VMAF was lower than current target.
Example: Run 1: target VMAF 90, default min/max crf, binary search range 10-55
Run 2: target VMAF 90, new max_crf (set by user) = 63, previous closest crf to target vmaf = 55 --> min_crf (set by ab-av1) = 55, new binary search range 55-63
That way, being the new binary search range more delimited, it would have a higher probability of reaching the target with fewer samples. It could potentially find the desired target in just one try in a second run, or at least save the time of 1-2 samples whose results were proven to be inadequate in the previous run.
I was encoding some 1080p animation using SVT-AV1 and a VMAF target of 92. I forgot to change the
--max-crf
value to 63 (the default is 55) and ab-av1 chose a CRF of 55, leading to a VMAF of 94.5, well above what I was going for.So I decided to re-run the search, which I think should be pretty quick since multiple CRFs have already been sampled. However, after adding
--max-crf 63
to the command, ab-av1 seems to start the entire sampling process all over again, even though it should have the advantage of having already run multiple CRF samplings with the same settings (especially the last maximum CRF).I don't know exactly know what's causing this, but is
--max-crf
being counted as an encoder settings change that leads to a unique ID in the cache? If this is the case, then it probably should be changed (and also--min-crf
, though I haven't tested that one, I only suspect it behaves similarly).