More CRF-SEARCH logic questions

[raysv]

Hi,
This is not a bug, and it may be a good reason for why it works this way, but my question.

You have a file, run a vmaf search, it always starts on CRF 32 which is fine, if its lower or higher it always goes down to 21 or up to 40ish something.

Lets say you then have a vmaf target of min 95, and it hits 94.89 on 21, why does it jump all the way down to 10 again, just to do another pass at 20.

Isn't the 10, or actually 11 drops enough to establish that VMAF score is aprox 0.25 pr CRF "point" on this particular source? So when going 32-21 it should have been able to figure out the baseline and the next try should have been 20 and not skip all the way down to 10, for then do jump to 20 again?

When doing gpu encodes this dosnt take much time, but when doing cpu encoding it seems to be alot wasted time and and power resources going into this when useing low presets. and atleast from a "novice" view seems it goes thru more steps than it needs.

[alexheretic]

Yes I agree to some extent. The interpolated binary search needs 2 points to work. The search starts with the min/max mid point crf. After that we need a 2nd bound, we could just go straight to the min/max crf instead we go half way this is a guess based on some initial experiments with svt-av1 back at the start of the project.

crf/vmaf relationship is not linear, so the linear interpolated binary search is not exact. Searches I was doing would generally be in the middle 50% of the range so this logic would improve search speed. However, in the case you need, e.g. below crf 21, this step probably slows down the search.

It is an interesting idea to interpolate down using 32 & 21 -> x (in [10,20]). I guess the problem could be when interpolation is a poor fit this could result in very poor searches (e.g. 20,19,18...,10 fail). However, this may be worth trying.

Another options is to just remove the "middle 50%" guess, e.g. for default settings go 32 then 10 then interpolated binary search. Or make it configurable. I'd like to confirm this guess is actually helping too as I haven't done such analysis for some time.

[alexheretic]

In #227 I noted that the "middle 50%" guess also falls down once users start setting their own min/max crf ranges.

I think having a configurable crf-search strategy makes sense. The first two options could be

• Middle then min/max then interpolated binary search. (This should probably be the default if you change the min or max crf)
• Current default: "middle 50%" optimised version of above.

We could also, or alternatively, generalise the "middle 50%" idea. So you could configure a crf range hint that you think will be right. E.g. the default could be the current middle 50% / [21, 43] range that should get faster search results with the downside being slower searches for crfs outside that range (but they'll still be found).

[stderr-to-devnull]

I will just leave here the link to my latest reply from #227, for any possible manifested interest.

[raysv]

Not sure i understand what the "middle 50%" guess" is here. Is it that you assume most svt-av1 to get vmaf 95 is between 21-32 CRF? From my experience its not, you get some lucky once in the middle, but often with av1 and svt i feel it is in one end or the other. One ep in the low 10's (11-16) and next one is usually good in its 30+, and its the rare cases in the middle :D

[alexheretic]

Not sure i understand what the "middle 50%" guess" is here. Is it that you assume most svt-av1 to get vmaf 95 is between 21-32 CRF?

"middle 50%" means 21-43.

There other aspect is making two iterations this way cuts the crf range down to a quarter before then using linear interpolation. I think this is important too generally as linear interpolation falls down when used in larger ranges.

#234 tweaks the tradeoffs but not fundamentally. If your manually picking a small crf range the 2nd iteration binary cut makes less sense + widening the cut a little accounts for the benefit of the right crf being in the "middle".