4 ms·

Yeah, that's definitely an issue! We had to "optimize" loading it twice. The first time, I moved it from auto-loading to when the user clicks convert to save

Yeah, that's definitely an issue! We had to "optimize" loading it twice. The first time, I moved it from auto-loading to when the user clicks convert to save on bandwidth. The second time, I moved it to after a file is selected. That gives it time to load while users are presented with options before converting. It's definitely a trade-off. For us, the choice was easy-ish because we want to keep the budget down as Indie Hackers, so we can't just offer a free tool that costs a ton in backend/serverless charges.

PowerfulWizard 6y ago
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.
daxfohl 6y ago
Have you tried running this as a fastly worker?
- Andrew_W 6y ago
  Nope! It's all running client-side, so it uses a bit more bandwidth, but there's no way a serverless platform can compete with the cost :) If the tool is popular long term, we might do a serverless option to make it accessible to Safari users or something though.
  - daxfohl 6y ago
    I'd be curious what difference it makes. Supposedly fastly compiles wasm down to native first, so it should run faster. Obviously fetch time would be faster since it's sitting on their hard drives. Data transfer would obviously be video file size and bandwidth dependent. A lot of variables there, but still it would be interesting to see even for your particular bandwidth and distance from a fastly server, for what file size the break even point is (for a few different operations).

PowerfulWizard 6y ago

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.

daxfohl 6y ago

Have you tried running this as a fastly worker?

Andrew_W 6y ago
Nope! It's all running client-side, so it uses a bit more bandwidth, but there's no way a serverless platform can compete with the cost :) If the tool is popular long term, we might do a serverless option to make it accessible to Safari users or something though.
- daxfohl 6y ago
  I'd be curious what difference it makes. Supposedly fastly compiles wasm down to native first, so it should run faster. Obviously fetch time would be faster since it's sitting on their hard drives. Data transfer would obviously be video file size and bandwidth dependent. A lot of variables there, but still it would be interesting to see even for your particular bandwidth and distance from a fastly server, for what file size the break even point is (for a few different operations).