Closed jakearchibald closed 4 years ago
Surprised that there is apparently some code path that prevents the encoder from being stripped out. Giving this to @RReverser to make a call on this.
I've committed my manually built smaller wasms for AVIF. #805 is filed to fix it up properly.
If it indeed works properly even with undefined symbols, it should be fairly trivial to add those options to the corresponding cmake
invocation in the Makefile. You mentioned you're not very familiar with Make, but those are really just shell commands with Tab indentation.
You sure you don't want to give upstreaming changes a try? :)
Maybe I'm not that familiar with shell commands then 😄. The bit that isn't clear to me is running the build twice with the different options. Right now it only builds AOM once.
Oh right, I see. Yeah, parameterising Make commands is somewhat more complicated. I'd personally start with a simple copy-paste of https://github.com/GoogleChromeLabs/squoosh/blob/dev/codecs/avif/Makefile#L31-L59 and customizing one copy with your params for the encoder output, and another with params for the decoder output. Then, we can clean it up later, but at least it would work.
But sure, if you don't want to, I can try to do this when I'm back from OOO. I'm just a bit wary of having Wasm files that don't match build scripts in the repo.
Right now, both the encoder and the decoder contain both the encoder and decoder.
If I build the encoder with
CONFIG_AV1_DECODER
andCONFIG_AV1_HIGHBITDEPTH=0
in the AOM build, it knocks around 200k off the wasm.If I build the decoder with
CONFIG_AV1_ENCODER=0
, it knocks almost 1mb off the wasm.It complains about missing symbols, so I included
-s ERROR_ON_UNDEFINED_SYMBOLS=0
in the emscripten part, but it seems to function correctly.I'm not familiar enough with MAKE etc to automate this. @surma @RReverser can you take a look? Best to do it on the
avif-options
branch, as I've made some changes to the cpp there.