Use AOM_TUNE_IQ by default for YUV #2830

y-guyon · 2025-06-18T14:43:27Z

Based on #2599.

Note that "(Default: psnr)" was incorrect.

src/codec_aom.c

maryla-uc · 2025-07-10T08:53:30Z

WIth this PR, using -a sharpness=0 does nothing because when you set tune=iq it overrides it.
This also happens if you manually set -a sharpness=0 -a tune=iq. It only works as expected with -a tune=iq -a sharpness=0.

juliobbv-p · 2025-07-10T15:46:09Z

@maryla-uc good catch! tune iq sets up many optimized defaults (including --sharpness), so the codec control call to set tune iq should happen before the -a parameters.

y-guyon · 2025-07-23T13:22:25Z

@maryla-uc good catch! tune iq sets up many optimized defaults (including --sharpness), so the codec control call to set tune iq should happen before the -a parameters.

Done.

castano · 2025-10-03T04:31:30Z

Any idea what's holding up this PR?

y-guyon · 2025-10-03T08:18:05Z

Any idea what's holding up this PR?

There are a few consequences of TUNE=IQ to take into consideration when using it by default:

The quality encoding setting does not lead to the same file size and visual distortion, so the default encoding settings may end in noticeably different output after this change.
TUNE=IQ is slower to encode. One option may be to increase the default speed to 7 instead of 6, but that could also have side effects on output file size and decoding time.

juliobbv-p · 2025-10-04T00:17:01Z

@castano another thing worth mentioning: tune IQ is already considered production quality (on libaom 3.13.1 and newer). If a project doesn't have to worry about specific tune ssim behavior, then said project can just switch to use tune IQ right away.

For example, The Guardian has been using tune IQ for a few months, and we've received positive feedback from the website admin in the form of overall better image quality and consistency. Tune IQ's improvement in bit allocation by itself can be seen as a "bug fix".

I wouldn't wait for this PR to be merged as a sign of feature "readiness". On the contrary, we're just trying to be super thorough in understanding the inherent differences in bitrate allocation and encode time with tune IQ across images, compared to tune SSIM.

castano · 2025-10-04T03:40:17Z

I think it makes sense to evaluate the consequences of enabling tune IQ before making it the default choice, but it would be helpful to first add support for tune IQ as a user option, and only later make it the default after more users have had the chance to evaluate it and provide feedback.

I have clients interested in using tune IQ, but they won't maintain a custom build of libavif with modifications that they have to merge on every update.

Similarly, tools that use libavif won't offer this option until it's officially supported by libavif, so not having this exposed also delays its upstream adoption.

juliobbv-p · 2025-10-05T16:51:21Z

@castano you can enable tune IQ in avifenc with the following parameter: -a c:tune=iq. This is the official way to switch between different tunings, so it's guaranteed to never change.

avifenc in turn passes in the parameter to libavif as a key ("tune")/ value ("iq") pair in the following manner:

static avifBool avifCodecSpecificOptionsAdd(avifCodecSpecificOptions * options, const char * keyValue)
{
    const char * value = strchr(keyValue, '=');
    if (value) {
        // Keep the parts on the left and on the right of the equal sign,
        // but not the equal sign itself.
        const size_t keyLength = value - keyValue;
        return avifCodecSpecificOptionsAddKeyValue(options, keyValue, keyLength, value + 1);
    }
    // Pass in a non-NULL, empty string. Codecs can use the mere existence of a key as a boolean value.
    return avifCodecSpecificOptionsAddKeyValue(options, keyValue, strlen(keyValue), "");
}

avifenc.c has the necessary code to talk to libavif, including passing in codec-specific options.

castano · 2025-10-06T18:02:28Z

Hmm... I haven't tried avifenc, but I didn't see the iq option in the aomOptionDefs struct, so I assumed that would not work without additional changes:

https://github.com/AOMediaCodec/libavif/blob/40cb2c1fbff1e14b6c81816b73a364490b12ffb6/src/codec_aom.c#L397C39-L397C49

Ah, I see it gets routed to aom_codec_set_option, never mind!

wantehchang · 2025-10-06T18:10:09Z

Ignacio: The aomOptionDefs struct is only used with older versions of libaom that don't have the aom_codec_set_option() function. In that case, the feature detection macro HAVE_AOM_CODEC_SET_OPTION is not defined.

For testing this pull request, please use the latest version of libaom, v3.13.1 if you can. Thanks!

src/codec_aom.c

Co-authored-by: Vincent Rabaud <[email protected]>

CHANGELOG.md

apps/avifenc.c

src/codec_aom.c

wantehchang · 2026-01-22T19:52:29Z

src/codec_aom.c

+#if defined(AOM_HAVE_TUNE_IQ) && defined(AOM_USAGE_ALL_INTRA) && defined(ALL_INTRA_HAS_SPEEDS_7_TO_9)
+            // AOM_TUNE_IQ is favored for its low perceptual distortion on luma and chroma samples.
+            // AOM_TUNE_IQ sets --deltaq-mode=6 which can only be used in all intra mode.
+            if (image->matrixCoefficients != AVIF_MATRIX_COEFFICIENTS_IDENTITY && (addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE)) {


IMPORTANT: If the addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE test is intended to detect whether all intra mode is used, ideally we should wait until we have set the aomUsage variable and then test aomUsage == AOM_USAGE_ALL_INTRA.

This requires moving some code around and possibly save some variables such as aomUsage and useTuneIq in the codec->internal struct.

Would you like me to take a stab at this and attach a patch to this pull request?

Would you like me to take a stab at this and attach a patch to this pull request?

Thank you for the proposal. Could you do that in a separate pull request, so that this PR only switches t=IQ on by default?

Yes, we can reorder the code in a separate pull request.

Optional: If the addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE check is intended to detect whether all intra mode is used rather than whether we are encoding a still image, it would be good to use a local variable whose name clarifies the purpose of the check:

avifBool useAllIntra = (addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE) != 0; if (image->matrixCoefficients != AVIF_MATRIX_COEFFICIENTS_IDENTITY && useAllIntra) {

Done and in #2973.

This PR also includes the changes in #2973. Is that intended? Or is #2973 is prerequisite for this PR?

wantehchang · 2026-01-22T19:57:50Z

Yannis: Sorry about the late review. I missed your review request.

wantehchang

LGTM. Thanks!

src/codec_aom.c

wantehchang · 2026-01-23T18:50:58Z

src/codec_aom.c

+#if defined(AOM_HAVE_TUNE_IQ) && defined(AOM_USAGE_ALL_INTRA) && defined(ALL_INTRA_HAS_SPEEDS_7_TO_9)
+            // AOM_TUNE_IQ is favored for its low perceptual distortion on luma and chroma samples.
+            // AOM_TUNE_IQ sets --deltaq-mode=6 which can only be used in all intra mode.
+            if (image->matrixCoefficients != AVIF_MATRIX_COEFFICIENTS_IDENTITY && (addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE)) {


Yes, we can reorder the code in a separate pull request.

Optional: If the addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE check is intended to detect whether all intra mode is used rather than whether we are encoding a still image, it would be good to use a local variable whose name clarifies the purpose of the check:

avifBool useAllIntra = (addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE) != 0; if (image->matrixCoefficients != AVIF_MATRIX_COEFFICIENTS_IDENTITY && useAllIntra) {

apps/avifenc.c

Add non-RGB to avifenc help. Base tune default on aomUsage.

wantehchang · 2026-01-27T00:03:00Z

src/codec_aom.c

+    // Speed  8: RealTime    CpuUsed 8
+    // Speed  9: RealTime    CpuUsed 9
+    // Speed 10: RealTime    CpuUsed 9
+    unsigned int libavifDefaultAomUsage = AOM_USAGE_GOOD_QUALITY;


Nit: Remove "Default" from the variable name.

This AOM usage won't be overridden by something else, so it isn't a default value.

I also think the "libavif" prefix is unnecessary. You didn't add the "libavif" prefix to "aomCpuUsed".

wantehchang · 2026-01-27T00:08:11Z

src/codec_aom.c

+            libavifDefaultAomUsage = AOM_USAGE_REALTIME;
+#endif
+        }
+    }


I suggest also moving the following code that sets up aomCpuUsed:

// aom_codec.h says: aom_codec_version() == (major<<16 | minor<<8 | patch) static const int aomVersion_2_0_0 = (2 << 16); const int aomVersion = aom_codec_version(); if ((aomVersion < aomVersion_2_0_0) && (image->depth > 8)) { // Due to a known issue with libaom v1.0.0-errata1-avif, 10bpc and // 12bpc image encodes will call the wrong variant of // aom_subtract_block when cpu-used is 7 or 8, and crash. Until we get // a new tagged release from libaom with the fix and can verify we're // running with that version of libaom, we must avoid using // cpu-used=7/8 on any >8bpc image encodes. // // Context: // * https://github.com/AOMediaCodec/libavif/issues/49 // * https://bugs.chromium.org/p/aomedia/issues/detail?id=2587 // // Continued bug tracking here: // * https://github.com/AOMediaCodec/libavif/issues/56 if (aomCpuUsed > 6) { aomCpuUsed = 6; } }

wantehchang · 2026-01-27T00:16:21Z

src/codec_aom.c

+#if defined(AOM_HAVE_TUNE_IQ) && defined(AOM_USAGE_ALL_INTRA) && defined(ALL_INTRA_HAS_SPEEDS_7_TO_9)
+            // AOM_TUNE_IQ is favored for its low perceptual distortion on luma and chroma samples.
+            // AOM_TUNE_IQ sets --deltaq-mode=6 which can only be used in all intra mode.
+            if (image->matrixCoefficients != AVIF_MATRIX_COEFFICIENTS_IDENTITY && (addImageFlags & AVIF_ADD_IMAGE_FLAG_SINGLE)) {


This PR also includes the changes in #2973. Is that intended? Or is #2973 is prerequisite for this PR?

juliobbv-p reviewed Jun 18, 2025

View reviewed changes

src/codec_aom.c Outdated Show resolved Hide resolved

y-guyon force-pushed the iq branch from 4d53b87 to 7e6bd0d Compare June 19, 2025 11:53

y-guyon force-pushed the iq branch from 69a979d to 1422eb1 Compare July 23, 2025 13:20

y-guyon force-pushed the iq branch from c0aedb8 to 6df433f Compare December 15, 2025 14:34

juliobbv-p reviewed Dec 15, 2025

View reviewed changes

src/codec_aom.c Outdated Show resolved Hide resolved

y-guyon mentioned this pull request Dec 16, 2025

Set tuning before aom codec options #2935

Merged

y-guyon force-pushed the iq branch from 6df433f to 2f964b7 Compare January 5, 2026 10:38

y-guyon changed the title ~~Use AOM_TUNE_IQ by default~~ Use AOM_TUNE_IQ by default for YUV Jan 5, 2026

y-guyon force-pushed the iq branch from 2f964b7 to 5b14acb Compare January 8, 2026 10:02

y-guyon requested a review from wantehchang January 16, 2026 10:56

Use AOM_TUNE_IQ by default

be55e7c

Co-authored-by: Vincent Rabaud <[email protected]>

y-guyon force-pushed the iq branch from 5b14acb to be55e7c Compare January 22, 2026 13:49

wantehchang reviewed Jan 22, 2026

View reviewed changes

Fix preproc checks, comments and CHANGELOG

e2719c3

wantehchang approved these changes Jan 23, 2026

View reviewed changes

y-guyon mentioned this pull request Jan 26, 2026

Please add the tune=iq option to the --help text #2972

Closed

Remove define check

33d9d90

Add non-RGB to avifenc help. Base tune default on aomUsage.

wantehchang reviewed Jan 27, 2026

View reviewed changes

Use AOM_TUNE_IQ by default for YUV #2830

Are you sure you want to change the base?

Use AOM_TUNE_IQ by default for YUV #2830

Conversation

y-guyon commented Jun 18, 2025

Uh oh!

Uh oh!

maryla-uc commented Jul 10, 2025

Uh oh!

juliobbv-p commented Jul 10, 2025

Uh oh!

y-guyon commented Jul 23, 2025

Uh oh!

castano commented Oct 3, 2025

Uh oh!

y-guyon commented Oct 3, 2025

Uh oh!

juliobbv-p commented Oct 4, 2025

Uh oh!

castano commented Oct 4, 2025

Uh oh!

juliobbv-p commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

castano commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wantehchang commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wantehchang commented Jan 22, 2026

Uh oh!

wantehchang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

juliobbv-p commented Oct 5, 2025 •

edited

Loading

castano commented Oct 6, 2025 •

edited

Loading