Build libavif with encoding support on Windows

[slouken]

I'd like to add support for saving images as AVIF. Could you rebuild libavif with encoder support?

[sezero]

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 License
• svt-av1: encoder and decoder, https://gitlab.com/AOMediaCodec/SVT-AV1, BSD-3-clause clear license

EDIT: I guess aom should be the choice, but you decide.

Either way, the dlls will noticeably increase in size

Apart from them, do you require libyuv support in libavif? (https://chromium.googlesource.com/libyuv/libyuv/, C++)

[slouken]

I think aom is the way to go. The HDR cases are not in the libyuv fast path, but it would be a shame for us to always use the slow path.

I’ve built it here statically linked with Visual Studio and libsharpyuv and the other bells and whistles. We can use that instead, if you want.

[sezero]

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?

The HDR cases are not in the libyuv fast path, but it would be a shame for us to always use the slow path.

Hmph.. Static libstdc++ bloat will be there. Will need to vendor libyuv too

I’ve built it here statically linked with Visual Studio and libsharpyuv and the other bells and whistles. We can use that instead, if you want.

In the interim maybe: those dlls will have all MSVC runtime and Win10 dll dependencies, no?

I'll try to build something using mingw later these days.

[slouken]

Yes, SDL3 only. The static linking with VC means we don’t have runtime dependencies.

I’ll go ahead and drop in the VC libs for now. @madebr, do you want to help with the vendoringand non-Windows builds?

[slouken]

If I remember correctly, dav1d is a faster decoder. Do we want both back ends configured?

[sezero]

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.

[sezero]

Here are the initial libavif dll builds with encoder support: 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, like this:

-DENABLE_DOCS=0 -DENABLE_EXAMPLES=0 \
 -DENABLE_TESTDATA=0 -DENABLE_TESTS=0 -DENABLE_TOOLS=0 \
 -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release \
 -DCONFIG_AV1_DECODER=0 -DAOM_TARGET_CPU=x86

IIRC, the cpu target needed explicit speciying for x86 - replace with x86_64 for x86_64

I didn't bother including libyuv yet: if you want I can do that too.

The dlls are large in size even after stripping.

[madebr]

avif has 2 configuration options to control encoding/decoding with aom: AVIF_CODEC_AOM_ENCODE and AVIF_CODEC_AOM_DECODE. Both are enabled by default.
I suppose we want AVIF_CODEC_AOM_DECODE=OFF instead?

Inside avif.c, the priority is dav1d > libgav1 > aom > rav1e > svg > avm

[sezero]

AVIF_CODEC_AOM_DECODE=OFF

Will try and get back immediately

[sezero]

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

[madebr]

Isn't that good? dav1d for decoding and aom for encoding?

[sezero]

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 of aom encoder inclusion (8.9M x86 dll and 13.4M x64 dll)

[sezero]

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

[slouken]

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

Fixed!

[slouken]

Only that I didn't expect these large dll sizes only because of aom encoder inclusion (8.9M x86 dll and 13.4M x64 dll)

I'm not surprised, the size of the aom encoder is pretty big. Remember these are optional DLLs, so users who don't want to include them in their project can leave them out.

[sezero]

Only that I didn't expect these large dll sizes only because of aom encoder inclusion (8.9M x86 dll and 13.4M x64 dll)

I'm not surprised, the size of the aom encoder is pretty big. Remember these are optional DLLs, so users who don't want to include them in their project can leave them out.

OK then

[sezero]

P.S.: We are currently vendoring aom 3.6.1, however 3.7.1+ has at least one CVE fix. I suggest upgrading to aom 3.7.2 or 3.8.1

[madebr]

When finished, it would also be useful to test storing avif in the test.

SDL_image/test/main.c

Line 153 in c9c809b

SDL_FALSE, /* can save */

[slouken]

P.S.: We are currently vendoring aom 3.6.1, however 3.7.1+ has at least one CVE fix. I suggest upgrading to aom 3.7.2 or 3.8.1

I used 3.6.1 because that is the version that is recommended with the libavif we're using. However, it looks like the API is pretty stable, we should be able to bump to a newer aom if we want.

[sezero]

Now that avif save commit c1600c4 is in, should I push the new dlls to msvc project I you aren't doing that yourself already?

[slouken]

Sure, go for it. However I'm going to ask @madebr's help with these:

-- libavif: libyuv not found; libyuv-based fast paths disabled.
-- libavif: libsharpyuv not found

[sezero]

Pushed 5d95dc1

[madebr]

Sure, go for it. However I'm going to ask @madebr's help with these:

-- libavif: libyuv not found; libyuv-based fast paths disabled.
-- libavif: libsharpyuv not found

libavif is looking for libyuv.
Unless we force disable it, should we vendor it?
It's c++ with lots of intrinsics.

[slouken]

I think we can vendor it. We already have libsharpyuv in webp.

[sezero]

libavif HEAD has inlined a very crippled version of libyuv under their 3rdparty directory without any cpu optimizations: We can do something similar if necessary with cpu optimizations included? And as a matter of fact most of libyuv can actually be built as C-only, at least the parts that are of interest to us: libavif's own vendored version is C-only for example.

[madebr]

The patch looks very straightforward.
For libsdl-org's fork, I would just unconditionally use the "crippled version", to avoid any dependency on a system libyuv.

[madebr]

This is done in 1d91d7e

[sezero]

I made a libyuv fork and created a branch for C-only build -- here if interested: https://github.com/sezero/libyuv/tree/sezero

[madebr]

Untested, but with set_source_files_properties(${sources} PROPERTIES LANGUAGE C), you can override CMake's automatic language detection.

[sezero]

Untested, but with set_source_files_properties(${sources} PROPERTIES LANGUAGE C), you can override CMake's automatic language detection.

OK, learnt something new about cmake - thanks.

[sezero]

Pushed 87c811f which updates libavif dlls with added libyuv support included (libyuv built from my C-only fork above, and of course statically linked.)

[sezero]

Just noticed that libyuv disables cpu optimizations if targeting x86 (not x64) and __SSE__ isn't defined and compiler isn't clang. My mingw x86 compiler is gcc (gcc 7.5.0) and doesn't enable __SSE__ by default. That seems to be why the x86 and x64 dlls have that crazy a difference in size.

[sezero]

Just noticed that libyuv disables cpu optimizations if targeting x86 (not x64) and __SSE__ isn't defined and compiler isn't clang. My mingw x86 compiler is gcc (gcc 7.5.0) and doesn't enable __SSE__ by default. That seems to be why the x86 and x64 dlls have that crazy a difference in size.

Pushed sezero/libyuv@11df275 to my libyuv fork to enable SIMD functions for x86 with gcc >= 4.9 by using target attributes. Rebuilt our libavif x86 dll against it and pushed d5eda04