Why not use the release version of libaom? about libavif

[joedrago]

I don't work directly on the libaom team and simply hadn't noticed that they made that tag 2 weeks ago. The checked-in SHA there was only from a month prior. As I note in aom.cmd, the SHA in there is just the most recent commit I've personally tested and known to work, and I'll update it periodically.

I've updated it just now to point at v1.0.0-errata1, fixed the compile issues related to the SHA update, and bumped the version to v0.3.7. It is going through the builders now, but assuming no new issues crop up, you should be able to use v0.3.7 along with your baked-in libaom on your distro now.

[joedrago]

I think they've internally switched to using 16bpc all the time, which has broken libavif's decode path. I'm investigating now.

[joedrago]

Oh god, I just realized what happened. The v1.0.0-errata1 version is ancient, and I missed the timestamp on that tag (2018!). I'm undoing all of this nonsense now.

[joedrago]

Okay, I've successfully reverted these changes, but had to push a new build. 0.3.8 is effectively 0.3.6 in functionality, and I've flagged 0.3.7 as do-not-use. This will teach me to read GitHub issues right when I wake up in the mornings.

Let's start over here:

The v1.0.0-errata1 tag is very old, and libaom has had many improvements/fixes in the >12 months since the tag was made. I think the best bet here would be to update the PKGBUILD file for Arch to point at a fresher SHA, or build libaom locally with libavif (using aom.cmd and -DAVIF_BUILD_AOM=1 on the CMake cmdline).