3 ms·

I agree it makes a lot of sense for stuff that could never be offered as a free back-end service. FFmpeg is a complex app as well, I tried to measure the the si

I agree it makes a lot of sense for stuff that could never be offered as a free back-end service. FFmpeg is a complex app as well, I tried to measure the the size of the binary + all shared libraries on my linux system and I came up with almost 180MB. I couldn't tell if the .WASM file was being transferred compressed either, it should compress more than 2x. (This is how I tried to measure FFmpeg binary size, I have no idea if it is correct: ldd $(which ffmpeg) | egrep -o "/[^ ]+" | \ xargs readlink -f | xargs stat -c '%s' | \ python3 -c 'import sys; print(sum(map(lambda s: int(s.strip(), 10), sys.stdin.read().split())))' 178092232 )

Andrew_W 6y ago
Yeah. My biggest question when I started building this was whether there was enough in the wasm to support the features we wanted to build. I've been really happy with the results so far!
iso1210 6y ago
You're not adding the size of the ffmpeg binary itself with that. My ffmpeg which I compiled as follows (with my own filter) --enable-gpl --enable-version3 --enable-nonfree --enable-libx264 --enable-libx265 --enable-libmp3lame is 21,387,880 bytes Running with your command reports an additional 18,273,624 bytes linux-vdso.so.1 (0x00007ffcbcdfd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff60391b000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007ff6036a4000) libx264.so.152 => /usr/lib/x86_64-linux-gnu/libx264.so.152 (0x00007ff6032ff000) libx265.so.146 => /usr/lib/x86_64-linux-gnu/libx265.so.146 (0x00007ff60267e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff60245f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff60206e000) /lib64/ld-linux-x86-64.so.2 (0x00007ff605d14000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff601e6a000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007ff601c5f000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff6018d6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff6016be000) I guess it depends what you compile in.
- PowerfulWizard 6y ago
  This is a slightly more correct command I think: du -cb $(ldd $(which ffmpeg) | egrep -o "/[^ ]+" | cat <(which ffmpeg) - | xargs readlink -f) | tail -n1 I think this is what the ffmpeg.wasm-core project is compiling in: https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-wasm/wasm/build-scripts/configure-ffmpeg.sh https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-w... Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.

Andrew_W 6y ago

Yeah. My biggest question when I started building this was whether there was enough in the wasm to support the features we wanted to build. I've been really happy with the results so far!

iso1210 6y ago

You're not adding the size of the ffmpeg binary itself with that. My ffmpeg which I compiled as follows (with my own filter) --enable-gpl --enable-version3 --enable-nonfree --enable-libx264 --enable-libx265 --enable-libmp3lame is 21,387,880 bytes Running with your command reports an additional 18,273,624 bytes linux-vdso.so.1 (0x00007ffcbcdfd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff60391b000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007ff6036a4000) libx264.so.152 => /usr/lib/x86_64-linux-gnu/libx264.so.152 (0x00007ff6032ff000) libx265.so.146 => /usr/lib/x86_64-linux-gnu/libx265.so.146 (0x00007ff60267e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff60245f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff60206e000) /lib64/ld-linux-x86-64.so.2 (0x00007ff605d14000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff601e6a000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007ff601c5f000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff6018d6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff6016be000) I guess it depends what you compile in.

PowerfulWizard 6y ago
This is a slightly more correct command I think: du -cb $(ldd $(which ffmpeg) | egrep -o "/[^ ]+" | cat <(which ffmpeg) - | xargs readlink -f) | tail -n1 I think this is what the ffmpeg.wasm-core project is compiling in: https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-wasm/wasm/build-scripts/configure-ffmpeg.sh https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-w... Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.