You should add a comment to the thread giving the backstory of how you came to work on this, and explaining what's different about it. That tends to seed discussion in a good direction.
This is brilliant - I'm amazed how humble you are in calling it a stupid website. I've always wanted to do "something" with video development, just because it's always been a massive black hole for me. Any tips?
What aspect do you want to get into? Making plugins for post production? Developing new codecs? Streaming? Broadcast? Apps?
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.
I would definitely recommend trying something with JavaScript/HMTL5 videos. Doing anything native has always been decently complicated and there's a lot of setup work involved. If you want to get your toes wet, writing basic filters is fun :)
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 very well done, intuitive to use, and fast - I'm impressed! Only tweak I would want is a way to move the ends of a selected timeline segment, at least for mobile.
This is really cool! It’d be even better if you added “playsinline” attributes to your video elements so your videos didn’t play in fullscreen on iPhones.
Done! I took a bit of a shotgun approach because I don't have an iOS device to test, and the documentation on playsinline seems lacking (or at least non-standard). Hope that works!
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!
It could certainly be adapted to work on live streams, but I'm not sure what kind of setup they have to track the ball in that example. Seems decently complicated!
Be careful how you use ffmpeg. ffmpeg is LGPLed. you can call it like a DLL. You can not run some compiler/transpiler on top of it that combines it with other non GPLable code. AFAICT you must keep the LGPLed code a separate file and connect at runtime. Which means sticking in npm and running a standard bundler over it so it gets all put into a single file would either make your code illegal or require you to also release your app as LGPL (assuming the 650 other deps you probably pulled in were LGPL compatible)
This is a good point, actually this might be what ffmpeg.js is already doing. I was wondering why they went out of the way to run the worker and pull ffmpeg code from unpkg.com, but I suppose that makes sense now!
Thanks for the tip, I'm certainly no legal expert!
This is the standard for GPL licenses and your focus on this particular aspect of the license amounts to FUD. LGPL, GPL and many other copyleft licenses are in common usage across the ecosystem, including the Linux kernel.
From Wikipedia[1]:
"... 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. ..."
I am not spreading FUD and I am not dissing the license. FFmeg is great software. My only point is the standard build process for JavaScript versions will go against the license.
If you just do the equivalent of
npm install --save ffmpeg.js
webpack
You've may have just built something that must be LGPLed. That's a good thing to know so you can take steps to honor the license and either LGPL your stuff or keep ffmeg out of your build process and just link it at runtime as the license requires
LGPL does not require dynamic linking; what it requires is to distribute the application in a form which allows the user to replace the LGPL-covered parts. Dynamic linking is one way to accomplish this, but not the only one.
This is super cool. Very impressive project. I had not realized ffmpeg could run client side. This opens up some really interesting possibilities for media editing and sharing (imagine if video sharing platforms enabled people to edit/annotate videos in the browser before publishing)
For sure! Although this project is using a worker for ffmpeg, currently it only runs one which means it's like you're running encoding on a single core machine, but with even more JavaScript overhead.
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 ;)
Awesome!, If you want to try without the ffmpeg dependency in the future, you might have some luck with the Canvas captureStream API [1] and the MediaStream Recording API
50 comments
[ 0.20 ms ] story [ 111 ms ] threadOther Show HN tips here: https://news.ycombinator.com/item?id=22336638
Shared anim: TrevorSundberg ↗ Haha thanks for sharing, it's the first time I've seen anyone use it and share the link so I'm pretty excited!
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.
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.
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!
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.
How is that even possible in the browser?!
What more can you ask for? It's incredible work. Keep it up!
Thanks for the tip, I'm certainly no legal expert!
If I remember right the H264 encoder is not in the GPL version.
From Wikipedia[1]:
"... 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. ..."
[1] https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Lice...
If you just do the equivalent of
You've may have just built something that must be LGPLed. That's a good thing to know so you can take steps to honor the license and either LGPL your stuff or keep ffmeg out of your build process and just link it at runtime as the license requiresYou 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 ;)
However, I'll happily take fixes for it!
[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
[2] https://developer.mozilla.org/en-US/docs/Web/API/MediaStream...
https://developer.mozilla.org/en-US/docs/Web/API/CanvasCaptu...
I think I will make this change because the ffmpeg legality seems hairy. Thank you!