Özkan Sezer

> It's useful for faster ci, and also useful for the satellite xcode projects to not need a pre-built SDL framework. We can drop SDL from `external`, and people can...

> This is purely about building the application, and let the user worry about where to get binaries. I meant in CI

You have to choose an encoder backend: - rav1e: https://github.com/xiph/rav1e, encoder-only, BSD 2-Clause License, requires rust compiler which I don't have - aom: encoder and decoder, https://aomedia.googlesource.com/aom, , BSD 2-Clause...

> I think aom is the way to go. OK, aom it is. We'll need to vendor it too, and drop dav1d support. Will this be for SDL3 only? >...

> If I remember correctly, dav1d is a faster decoder. Do we want both back ends configured? libavif allows multiple backends, don't know how it prioritizes codecs though.

Here are the initial libavif dll builds with encoder support: [dlls.tar.gz](https://github.com/libsdl-org/SDL_image/files/14055999/dlls.tar.gz) Included: dav1d 1.2.1 as decoder, aom 3.6.1 as encoder, libsharpyuv from libwebp HEAD. aom was configured without decoder support,...

> AVIF_CODEC_AOM_DECODE=OFF Will try and get back immediately

> > AVIF_CODEC_AOM_DECODE=OFF > > Will try and get back immediately Oops, noticed that I already disabled that option. So, these libavif builds use libaom really only for encoding

> Isn't that good? dav1d for decoding and aom for encoding? Yes it is, and it was the intention. Only that I didn't expect these large dll sizes only because...

Off-topic: I don't seem to have write permissions to our aom fork at https://github.com/libsdl-org/aom.git