Some of images from link-u/avif-sample-images cannot be decoded

[HappySeaFox]

libavif used: 0.9.1 with strict checks disabled.

Please see link-u/avif-sample-images#4

>avifdec --no-strict --info D:\images\avif\plum-blossom-large.profile0.8bpc.yuv420.alpha-limited.monochrome.avif
ERROR: Failed to decode image: BMFF parsing failed
Diagnostics:
 * Multiple Box[ipma] with a given pair of values of version and flags. See HEIF (ISO 23008-12:2017) 9.3.1

I understand that the files were possibly encoded with a buggy encoder. But what we can do? One of the possible workaround could be introducing a new flag to disable this particular strict check? Or, alternatively, wait until the original author fixes them? Please share your ideas.

[joedrago]

They will need to be updated, yes. I have a good working relationship with the link-u folks and they made some of the earliest test files for people to use, which I'm grateful for. That said, if the files are noncompliant, they will need fixes. I recommend filing issues with https://github.com/link-u/cavif, so they can update their files and get them adjusted in av1-avif's sample files repo.

As libavif was being written, we've had windows of time where it didn't enforce various things in the spec, for various reasons (simple oversights, minor confusion in wording, perhaps unnecessary strictures in the standard, etc). We've been trying to close these gaps over the last year (look for all GitHub issues with the compliance tag), as future implementations might simply look to see what the reference decoder or most modern browsers will tolerate, not necessarily what the standard says. This puts the burden on us to ensure that we follow the standard exactly while AVIF is still new, and/or amend the standard when we encounter situations where the standard asks for something redundant or impractical.

All of this is still a work in progress, and any strictness we've added in this vein has come out of long conversations with implementers of major browsers and the authors of the relevant standards. We weigh the cost of the pain associated with this kind of friction versus permanently being in a situation where people must accept invalid AVIFs because we didn't clamp down while AVIF was in its infancy; a situation many other file formats have.

It's an unfortunate situation, but I think the pros of ensuring we're as standards compliant as possible outweighs the permanent cons of being too lenient.

[HappySeaFox]

Thanks, Joe! I think the issue can be closed now.