Hi HN,
I love new web tech, and was excited to see ffmpeg ported to WebAssembly so decided to build a free tool that uses it to:
- Clip/trim videos - Overlay text and images - Resize - Create GIFs or convert to a web-friendly MP4
All of this done in your browser, without ever uploading a file to a web server! (* Except Safari, it doesn't support SharedArrayBuffers)
A little more:
I've been building a video creation app with my cofounder, and being a 2-man team, we wanted to think outside of the box on an "eng as marketing" strategy.
As a techy on a budget, ffmpeg.wasm sounded like the perfect library to make a powerful free tool without requiring a ton of server resources.
So we looked up some common tasks people want to do with videos and set out to build a quick tool to accomplish them.
I think there's a ton more we can build into this - it's been about a 2 week project, but thought it was cool enough to do an initial release now.
Hope you like it, and have suggestions on what we can improve!
I have previously tinkered with ffmpeg in the browser and implemented a workaround[1] for the (then) missing pthread support. It turned out quite clunky, but worked.
- First they were disabled due to Spectre. - Chrome reenabled them. - New HTTP headers were added for cross-origin resource partitioning. - FF/Chrome are both requiring those headers (FF now, Chrome next month)
That's awesome that you've played around with this, too. It was quite a bit of fun :)
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.
Even our mp4s aren't very well-optimized right now.
If you work with video a bit and think this tool might be helpful to you, let me know!
I'm using ffmpeg.wasm, it's basically ffmpeg compiled for the browser, and it's a simple layer where you basically treat it like the ffmpeg command, eg:
ffmpeg.run(['-i', 'input.gif', ..., 'output.gif').then(() => { // handle output file })
That sounds like a great use case for us to handle! Although I think ffmpeg in the browser loses some efficiency over the command line.
I think we added cropping as a possible future feature. I'll bet ffmpeg makes that really easy to do.
I think we should also work on optimizing the output size. I think we use a pretty high (err, low) -crf, which can result in ridiculous file sizes.
Thanks for the comment! Appreciate hearing use cases :)
Our tool definitely isn't as slick, but I think that has its benefits too. Like our trim interface doesn't look as nice, but shows a live preview of where you're at in the video.
I want their UI and style haha
Would love to chat about what you guys doing.Potentially collab and improve both our products!
Reach out rahul@modfy.video
Our app plug: 7 years back we did a quick tool to shrink JPG's in browser (Again needs Chrome or Firefox) without uploading images to server: http://shrinkjpeg.com
It's so cool to do it all in the browser!
I even built a simple landing page creator that let you change text and images, then created a zip file that you could extract to your web host - no backend needed!
I think for me, CORS is the biggest hindrance to some of my ideas, esp. around editing, creation, and working with the content.
But also get it if you mean you're not in a good place to test the tool at the moment haha
To improve the tool it would be nice to play the part clipped with the sound to check if it's ok. Also the tool failed to load one video.
Good job !
There are some pretty crazy security restrictions (no external scripts!) just to get ffmpeg running. I can't imagine the additional security precautions that would prevent exploits for WebGPU.
EDIT: working again now, looks pretty cool!
This description is absolutely killing me.
Adding the ability to loop the gif back and forth would be great!
I haven't checked the exact hit, but that's mostly because our focus for this tool was on people who would never touch ffmpeg or a command line.
Also, the alternative for us would've been to upload remotely and run on Lambda or similar, which I think would lack hardware acceleration as well.
Unfortunately, of course, they then want to get paid during playback, but that's the reality for everyone already.
When it failed to load the video, did it show a convert option that failed to load it as well? I think there are some limitations to the ffmpeg.wasm compile. Do you know the extension, or any details of the codecs, etc?
And I'm still learning a ton :)
We're trying to keep this tool super simple for our end users, but I think we might be able to add a webm preset.
If you'd like me to look into it, drop me an email: andrew@<domain in link> and show me a sample command :)
ffmpeg -i input.mp4 -b:v 0 -crf 30 -pass 1 -an -f webm /dev/null
ffmpeg -i input.mp4 -b:v 0 -crf 30 -pass 2 output.webm
ffmpeg -i FILE -codec:v libvpx-vp9 -qscale:v 0 -codec:a libvorbis -qscale:a 0 FILE.webm
(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())))')
My ffmpeg which I compiled as follows (with my own filter)
--enable-gpl --enable-version3 --enable-nonfree --enable-libx264 --enable-libx265 --enable-libmp3lame
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.
du -cb $(ldd $(which ffmpeg) | egrep -o "/[^ ]+" | cat <(which ffmpeg) - | xargs readlink -f) | tail -n1
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.
I've been really happy with the results so far!
If the tool is popular long term, we might do a serverless option to make it accessible to Safari users or something though.