Comments (33)
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?
from sdl_image.
Off-topic: I don't seem to have write permissions to our aom fork at https://github.com/libsdl-org/aom.git
Fixed!
from sdl_image.
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++)
from sdl_image.
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.
from sdl_image.
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.
from sdl_image.
If I remember correctly, dav1d is a faster decoder. Do we want both back ends configured?
from sdl_image.
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.
from sdl_image.
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.
from sdl_image.
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
from sdl_image.
AVIF_CODEC_AOM_DECODE=OFF
Will try and get back immediately
from sdl_image.
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
from sdl_image.
Isn't that good? dav1d for decoding and aom for encoding?
from sdl_image.
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)
from sdl_image.
Off-topic: I don't seem to have write permissions to our aom fork at https://github.com/libsdl-org/aom.git
from sdl_image.
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.
from sdl_image.
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
from sdl_image.
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
from sdl_image.
When finished, it would also be useful to test storing avif in the test.
Line 153 in c9c809b
from sdl_image.
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.
from sdl_image.
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?
from sdl_image.
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
from sdl_image.
Pushed 5d95dc1
from sdl_image.
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.
from sdl_image.
I think we can vendor it. We already have libsharpyuv in webp.
from sdl_image.
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.
from sdl_image.
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.
from sdl_image.
This is done in 1d91d7e
from sdl_image.
I made a libyuv fork and created a branch for C-only build -- here if interested: https://github.com/sezero/libyuv/tree/sezero
from sdl_image.
Untested, but with set_source_files_properties(${sources} PROPERTIES LANGUAGE C)
, you can override CMake's automatic language detection.
from sdl_image.
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.
from sdl_image.
Pushed 87c811f which updates libavif dlls with added libyuv support included (libyuv built from my C-only fork above, and of course statically linked.)
from sdl_image.
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.
from sdl_image.
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
from sdl_image.
Related Issues (20)
- longjmp/setjmp clobbered warning in IMG_png.c HOT 24
- upgrading libjpeg to 9f HOT 1
- [Cmake] [SDL2] Backport SDL3IMAGE_STRICT option to SDL2_image HOT 3
- cmake build: SDL2IMAGE_DEPS_SHARED option doesn't work HOT 3
- libwebp simd code not properly built with Cmake build system HOT 10
- SEGMENTATION FAULT with IMG_Load_RW in SDL2 HOT 4
- Build fails on MSYS2 HOT 4
- Failure to build SDL3_image HOT 4
- [2.8.x] Double-free if IMG_SaveJPG_RW_jpeglib() fails and IMG_SaveJPG_RW_tinyjpeg() is tried HOT 4
- Failing to save a JPEG with libjpeg crashes when it uses an uninitialized jmp_buf HOT 1
- [2.x] Autotools build can detect the wrong libjpeg HOT 10
- Factor out the parts of IMG_LoadJPG_RW where locals can be clobbered by setjmp()/longjmp()
- `SDL_RWops_renamed_SDL_IOStream` with latest SDL3 commit
- Create SDL3 stub library (.tbd) for use by the xcode projects of SDL satellite libraries
- CMake configure error on install with libavif with FetchContent on main (for SDL3) HOT 1
- Statically linking an executable with JPEG XL enabled breaks the build at link time HOT 2
- Build failed: too few arguments to function ‘SDL_CreateWindowAndRenderer’ HOT 1
- CI: macos ninja setup failure HOT 12
- jpeg-xl test have been failing on macos HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdl_image.