I had originally named this project Cake Town as an homage to a scene in that video, however the domain cake.town was taken so I chose https://madeitfor.fun/ instead :)
The goal was to be able to animate images and gifs over a video with controls that worked easily on both mobile and desktop, all on a website. I started to realize that with more things being compiled to WebAssembly, I could take advantage of video encoding directly on the page (no server encoding required). The web is truly a powerful platform!
I had previously used this ffmpeg WASM port (https://github.com/Kagami/ffmpeg.js) and hadn't seen the one you're using before (https://github.com/ffmpegjs/ffmpeg.js). Any thoughts on their pros & cons?
Also, I'm the maintainer of the awesome-ffmpeg list - mind if I add this to there?
Overall ffmpegjs/ffmpeg.js has been really nice. I would honestly prefer less API: they wrapped everything into a worker and made their own API calls, but I'd prefer the raw Emscripten filesystem and no worker/proxying. Then maybe a second library that wraps it up would be nice for ease of use.
I ran into one issue where the memory being used by ffmpeg was too great for running on an Android Pixel 3a (malloc failed). I split up the video encoding into 30 frame chunks. I don't think this was related to ffmpegjs/ffmpeg.js however.
This is wonderfully executed hack, for any feedback all I would have are nits. Well done, you have made my Friday.
What more can you ask for? It's incredible work. Keep it up!
How is that even possible in the browser?!
I think I will make this change because the ffmpeg legality seems hairy. Thank you!
Any idea how far away we are from doing this kind of stuff - https://vimeo.com/hawkeyeinnovations - in the browser. What would it take?
Edit - better example clip - https://vimeo.com/402159917
Who knows, one day maybe the browser will handle multiple vid feeds and the compute. Atleast thats what your site made me imagine.
"... The license allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. ... "
" ... For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components. ..."
If you just do the equivalent of
npm install --save ffmpeg.js
Thanks for the tip, I'm certainly no legal expert!
If I remember right the H264 encoder is not in the GPL version.
You could spin up simultaneous workers but you'd have to figure out how to break up what you're doing into separable parts. The file system is not shared between workers so you'd need to either send all the data back over or do something clever. This would be very doable, but I don't want to overload the browser especially on mobile.
Looking forward to when web threads are safe again... SharedArrayBuffer ;)
There's lots of work doing less sexy things like building workflows for transforming existing video libraries to something to use in various OTT platforms. Think B&W films or older TV programs. Understanding old video formats and how to prep them for modern platforms is something that not everyone does well. Of course that would require deep dive into the history of Film->Video.
There's also lots of options on developing supporting software to do non-sexy things like storing descriptive metadata and making it available. Transforming closed captions, subtitles and other ancillary file formats that support video.
Shared anim: https://madeitfor.fun/?data=eNq9XF2PVLkR%2FSutiVazq4Cxy3aVjc...
However, I'll happily take fixes for it!
Other Show HN tips here: https://news.ycombinator.com/item?id=22336638