While I think some of the posters here have valid points regarding performance, merely being able to do this in a browser makes this capability available to a ton of people who would otherwise be intimidated with the process of installing or compiling FFMPEG.
In particular, asm.js is explicitly disabled right now because of the need for memory growth. In the meantime, I'm planning on having a build with it enabled just to benchmark times on smaller files (where the growth is not needed).
They've had no algorithm development for years and nobody has bothered to tune them; it's more like a disassembled Lego box than an encoder.
Of course, if you include FAAC, LAME, or x264 it should be fine. But native libavcodec/x264 with their asm disabled is already considered too slow for use, so running them under a VM must limit it even more.
(In here goes the usual statement that OpenCL is not useful for this kind of work, and SIMD or direct asm is what's needed.)
Sounds like fun ;)
Or taking a bandwidth-bound problem and completely eliminating that bottleneck.
If you've got 1000 people converting videos at once, the embarrassingly parallel isn't going to help you much on the server.
This does look like fun, and really a nice validation for emscripten, and there's a ton of practical application.
Here are my results:
8 Workers, Test: 2^1024000000 mod 97777 = 20631, 1515 ms
4 Workers, Test: 2^1024000000 mod 97777 = 20631, 2899 ms
2 Workers, Test: 2^1024000000 mod 97777 = 20631, 5773 ms
1 Worker, Test: 2^1024000000 mod 97777 = 20631, 11508 ms
If they manage to move FFMPEG encoding into multiple web workers I'd love to read their writeup though!
If file size to download is an issue, why not build a "stripped down" version which works with just a couple of file format inputs and one output that uses a GPL codec?
For building a "stripped down" version, there is a config flag "--disable-everything" that can be used, and I will investigate it a little more. We probably won't end up hosting the compiled file, just out of the interest of repo-size, but I can certainly build a "build-minimal" script.
If this could encode an MPEG in realtime (it should be fast enough on Desktop PCs and browsers with asm.js support, right?), you could send WebCam video via WebSockets to a server, distribute it and decode again with jsmpeg. Sort of like the ghetto version of WebRTC, but without all the codec hassles :)
Regardless, there are some neat possibilities.
I wonder if you could also drop the size of the library significantly by dropping everything from FFmpeg except for what is needed for playback.
If you'd like to give this a shot, definitely open up an issue on Github and we can talk more about the details!
Use Opus, but if browser lacks support, render to Vorbis, RIFF Wave or MPEG Audio Layer 3. Obviously this isn't a serious suggestion, but I really wonder if it could work.
For swscale, was it compile problems or something later?
Also, if you have a way to run libav's "make fate" (regression tests), do you know which ones fail?
While Libav left with the server, bug tracker, etc., the FFmpeg project was restoring itself, with the help of some VideoLAN people (the FFmpeg sources are now hosted on git.videolan.org). Michael also started to merge the Libav changes back into FFmpeg every 1-2 day, with a lot of forgotten, previously rejected, sometimes controversial features, or in stand-by such as ffmpeg-mt.
The main point here is that the fork stimulated the competition, and FFmpeg became a way better (IMHO) and more complete project. Also, I must say the leader's attitude completely changed, in a very good way. This is certainly one of the most positive thing that came out of that war.
It shows how far the technologies have come. Truly a remarkable achievement.
- Upload a short video-clip and turn it into a looping gif without the webapp's backend doing the work?
- Take an already existing looping gif and append/truncate it
- Add watermark
- Make a ringtone from your music-in-the-cloud?(This is an idea I've been thinking about for awhile, btw)
- It'd be kinda cool to see a program like, say, Adobe After Effects or Photoshop re-implemented in a browser. This happened: http://pixlr.com/editor/
- ffmpeg also supports streaming to twitch.tv; it's the backend to http://www.ffsplit.com/. What if you could stream straight from your browser? Some HTML5 canvas window streamed via "ffmpeg.js" to some other place? Access your webcam/microphone maybe?
Encoding videos on the desktop with the native FFmpeg code will not only yield better performance, but I can't think of a scenario why you'd want to use as a web-based service.
Create screenshots? Really? What a complete triviality. I guess using standard software and hitting the PrtSc key is too difficult in comparison to using the browser for everything. Making screencasts is a different issue, but also one you'd do locally.
Sorry if I'm not so passionate.
That list changes every year, too. As JS runtimes get faster, more and more is now possible in the browser that would've been fully impractical just a few years ago. In just a few more years, I predict that stuff like video processing won't be so far-fetched either.
(shameless plug) more editing tools coming soon :)
Funnily enough I'm using a color pallete plugin written by @bgrins who is working on the OP project.
Still, I applaud the hacking :)
You're right, you're not going to use this to encode movies or very large media files, but for encoding shorter clips, the performance isn't unreasonable.