-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve CDEF parameter selection #845
Comments
@tterribe suggested as a preliminary step, simply varying the weights depending on quantizer. It may be worth it to dump whatever libaom's using as parameters for different QP. |
From running this script on subset1 tmatth@hydra ~ $ cat hack_metrics.sh
#!/bin/sh
set -e
set -u
SEQ=${1:-/mnt/raid/Videos/subset1-y4m/Air_Force_Academy_Chapel,_Colorado_Springs,_CO_04090u_original.y4m}
BASENAME_SEQ=$(basename ${SEQ})
AOMDIR=aom-master/aom_build
OUTDIR=~/out
mkdir -p ~/out
cd ${AOMDIR}
for x in 20 32 43 55 63; do
echo $x
OUTPUT=${BASENAME_SEQ}.$x.ivf
./aomenc ${SEQ} --ivf --tile-rows=2 --tile-columns=2 --passes=1 --quiet --rt --cpu-used=8 --end-usage=q --cq-level=$x -o ${OUTDIR}/${OUTPUT}
done I see that aomenc uses these CDEF parameters per QP:
|
@tterribe suggests making cdef parameters depend on quantizer in terms of
|
@tterribe suggests that for inter frames, we may want to search (as master is doing) but between 2 choices: strength dependent on qp vs. disabling CDEF entirely. I also want to compare only forcing strength based on QP for keyframes (and leaving inter frames with the existing search) to see if inter frames are where objective fast is regressing. |
CDEF strength from QP for intra frames only gives a -0.39% improvement across metrics, but no real encoder speed improvement on objective-fast-1: Compared to always selecting CDEF strength from QP (for inter and intra): |
So commit 5625ee3 is pretty restrictive in terms of CDEF search (effectively disabling it), I think the next step would be to put the CDEF from QP mode behind a speed setting for low QP. |
Basically this is at implementing this TODO: Line 946 in dc8bb63
|
Some notes based on research from Blue and me in aomenc: Pick from Q is pretty effective for the most part. I think when implementing the full CDEF search, it would be smart to define the search range based on the Q. i.e. for CDEF search, if pick from Q would give a strength of 2, the search could test 1, 2, 3. aomenc instead defines a constant subset of strengths to search depending on speed level. In some cases this is worse than pick from Q because at one level, it only searches strengths 0 and 11, so CDEF is either off or full strength. This leads to some quality inconsistencies at speeds 5 and 6. The other item of note is that Wiener LR seems to introduce more blur than SGR, so it may make sense to disable Wiener filters at lower Qs. |
Ideally, for CDEF, we should be using the full 0-15 strengths available on all speeds below speed 6, but prune instead the available strengths based on quantizer. Higher quantizer = less pruning. |
Paraphrasing @tterribe:
For a given frame, we can have up to 8 sets of CDEF parameters for superblocks to choose from (note: it is better to have fewer than 8 for lower bitrates, to reduce the cost of coding them per SB).
Currently these are hard coded.
We could do a feedforward approach, where for the last frame of a given type, you greedily search for better CDEF parameters, then select those for the next frame of the same type (inter/intra, pyramid level, etc.?).
We could also look at stats and try and find decent values to hardcode for lower bitrates.
Once we can buffer a frame in rav1e, that would allow to do something closer to what libaom does, where we do multiple passes of one frame and greedily search for better sets, i.e. swapping in parameters that perform better.
The text was updated successfully, but these errors were encountered: