undefined | Better HN

0 pointsAndrew_W5y ago0 comments

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.

0 comments

PowerfulWizard5y 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

)

iso12105y 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.

PowerfulWizard5y 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-w...

Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.

Andrew_WOP5y 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!

daxfohl5y ago

Have you tried running this as a fastly worker?

Andrew_WOP5y 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.

daxfohl5y 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).

j / k navigate · click thread line to collapse

0 comments

PowerfulWizard5y ago

(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

)

iso12105y 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

I guess it depends what you compile in.

PowerfulWizard5y 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-w...

Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.

Andrew_WOP5y 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!

daxfohl5y ago

Have you tried running this as a fastly worker?

Andrew_WOP5y 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.

daxfohl5y ago

j / k navigate · click thread line to collapse