--target=armv7-linux-gcc --disable-neon --disable-avx2 Do not use --enable-shared if you only need one binary. Use --enable-static and let the linker garbage-collect unused functions ( -ffunction-sections -Wl,--gc-sections ). libvpx has a little-known flag:
From the perspective of an IoT developer with 32 MB of total flash storage: The default libvpx is a nightmare of redundant symbol tables and CPU dispatchers that will never fire on their hardware.
If you are just decoding video (not encoding), consider dav1d for AV1 or ffmpeg with --enable-libvpx --disable-everything . But that is a story for another day. bloat libvpx
./configure --disable-runtime-cpu-detect --enable-static This tells the compiler: "Don't write the dispatcher. Just write the code for the CPU I am sitting on." This can cut binary size by 30-40%. Don't need VP8? (You probably don't; you want VP9). Or vice versa? You can't fully disable one easily, but you can reduce features:
In the world of open-source multimedia, libvpx is a titan. Developed by Google, it is the reference implementation for the VP8 and VP9 video codecs—the technologies that power YouTube, WebM, and billions of browser-based video calls. If you are just decoding video (not encoding),
The problem isn't Google's code. The problem is that the open-source ecosystem has standardized on a as the default. We need better documentation for "embedded" or "minimal" profiles.
Until then, if your binary is too fat, remember: It's not the codec's fault. You just compiled the reference implementation for the reference machine. Trim the flags, target your silicon, and libvpx will slim down. Just write the code for the CPU I am sitting on
--disable-vp8-encoder --disable-vp9-decoder When cross-compiling, specify exactly the architecture: