(minor) Adjust min/max/speed defaults in avifenc?

[joedrago]

As I think any actual avifenc commandline "recipe" will be quite explicit in its settings so this is semi-moot, my goal with the defaults for avifenc are to create reasonably-nice looking AVIFs at a decent speed, with opinionated-but-sensible defaults for other settings. With that in mind, I think the min/max/speed defaults might be missing the mark a bit.

speed is currently set to 8, which is a nice and snappy experience for new avifenc users, but internally it will engage libaom's AOM_USAGE_REALTIME, which is probably not what we want. I think 4 might be a better default, but it will make the default experience slower.

min and max are currently set to 0 and 10 respectively, which I believe is a bit too "high quality". The resultant files look very nice, but should probably be larger QP to show off AVIF for the first time for new people.

My suggestion is to switch to something like speed=4, min=24, max=26. I'm hoping to hear feedback on min/max/speed defaults from some folks I know have experimented with recipes or are very familiar with AV1's guts.

@wantehchang @AurelC2G @kornelski @jonsneyers @dwbuiten @cconcolato (I'm sure I'm missing folks)

[kornelski]

Yes, I think for command-line tools it's better to do their best, even if that's slow. Image conversions done off-line or as part of build scripts can be slow.

There's another use-case of realtime on-the-fly conversion, but implementation of such setup is much more involved, so more advanced developers can be expected to customize speed settings for their need. Also, to be honest, AV1 encoding is too slow for such use-cases, so it's better to focus on off-line conversion.

[adityamavlankar]

The proposed defaults look good to me. From my experiments on compression efficiency vs speed I've observed that speed 4 incurs a single digit BD-rate loss (4-9%) compared to the best case (speed 0). Speed 8 incurs a bigger loss (20-35%). So speed 4 seems like a good tradeoff. Also agree on min/max 24/26. What I've seen with min=0 (regardless of max setting) is the encoder can employ very low QPs for several blocks -- thereby spending lot of bits for not-really-noticeable quality improvement. Perhaps the min/max could be tuned to output resolution. For smaller images (boxshot like with plenty visual info packed in there) a good default might be lower -- like min/max 20/22 or 22/24.

[wantehchang]

Joe: The current default speed of 8 is not ideal for the libaom encoder. The new default speed can be one of the following:

• 6: This is the fastest speed in libaom's AOM_USAGE_GOOD_QUALITY usage mode.
• 3: This will give better compression. (Your suggestion of speed 4 is very close. You can pick one based on testing.)

As for min/max, I don't have a good suggestion. 24/26 should be fine because it's based on your testing. Note that we use libaom's codec-specific option cq-level instead (in conjunction with -a end-usage=q), and set min/max to the libaom defaults of 0/63.

[wantehchang]

Hi Joe,

Frank Galligan (my manager) tested speeds 3, 4, 6, 8 on 20 images. He found that

• For PSNR, speeds 3, 4, 6 are close.
• For encoding time, speeds 6 and 4 are relatively close (42 seconds vs 63 seconds), and speed 3 is much slower (125 seconds). (Speed 8 is 11 seconds.)

Frank recommends changing the default encoding speed to speed 6. I will write a pull request for the change.

[rubo77]

Why do you suggest a different value of min and max? I noticed, that you get the same filesize if you use min/max 20/20 and 20/22