FFmpeg-online: ffpmeg running on the browser
ffmpeg-online.vercel.appAs their github page says, based on https://ffmpegwasm.netlify.app ...
I'm guessing no one did GPU-optimizations? I saw a web app (not an ffmpeg transpilation) that went clever and used WebGL so it can access the GPU and use its parallel processing capabilities...
The algs for media codecs are typically in handwritten assembly in combination with C. Actual GPU hardware acceleration implements specific media algorithms in hardware and is not accessible from the browser. I'm not aware of any kind of gpu codec algs that work in browser.
They could use the WebCodec APIs to decode frames using the hardware, similar to how ffmpeg already supports VA-API for hardware decoding.
It’s nice if you have a modern computer, but I wonder what happens when the client has a very old computer or a “Chromebook”.
Will the experience for those low end computers be degraded?
It’s been awhile since I actually used ffmeg directly but I do recall trying to transcode some video to a different format and it took some time on a 2015 MacBook (not a MBP, like a thinner version of the MBA, lol)
This might also be interesting to the readers. In Wasmer we recently ported ffmpeg to Wasm/WASIX. It runs fully in both client (browser) and also fully on the server: https://wasmer.io/wasmer/ffmpeg (is multithreaded, all codecs supported)
Here's a video showcasing it! https://twitter.com/wasmerio/status/1687238131395768320
I believe we can bring ffmpeg to any programming language quite easily... stay tuned!
I implemented ffmpeg.wasm in my own web app, and it's working out really well. I didn't have to set up a Lambda to resize video, it happens in the user's browser and the result is uploaded directly to S3. It saves me processing cost, and complexity. It was really easy to implement and works perfectly.
The only caveat I'd mention here for anyone else looking to do something similar is that if you're planning to use ffmpeg to convert a video into multiple different formats for serving at different bitrates or to different devices, then doing it clientside opens up the door for users to upload completely different videos for different formats; you are trusting the client ultimately to send you the data.
Plenty of scenarios where that doesn't matter and it's fine to trust the client, but just something to be aware of.
What you said is definitely true. But in my system the videos are resized and converted into RAW format which I then extract color information from at different pixel locations, so it wouldn't really matter if it's an exe file or something else - it's only going to extract the binary data as color information to be used in other ways, and the converted files are never served. I doubt there's too much risk involved with my project using it in this way, but in other projects I'm sure it could be a security risk.
Yep, definitely didn't mean to imply that your project in specific was vulnerable, just wanted to give more of a general heads up for anyone else looking to do the same thing.
How large is the wasm binary?
Last I looked into this it was around 30MB. wasm does compress really well.
Thanks. That's good to know.
Related:
ffmpeg.wasm – a pure WebAssembly / JavaScript port of FFmpeg - https://news.ycombinator.com/item?id=33794122 - Nov 2022 (23 comments)
FFmpeg for browser and Node, powered by WebAssembly - https://news.ycombinator.com/item?id=28251801 - Aug 2021 (87 comments)
A pure WebAssembly / JavaScript port of FFmpeg - https://news.ycombinator.com/item?id=24987861 - Nov 2020 (125 comments)
Similar, but nicer UI: https://ffmpeg.app
Anyone know what the browser support is likely to be for this?
I’m working on something right now where I’m having to use a web service to merge an mp3 and mp4. Doesn’t even need to re-encode. So this might be perfect if a decent amount of browsers can run it.
"Not IE": https://caniuse.com/?search=wasm
Multithreading probably requires https://caniuse.com/sharedarraybuffer
Or better use the WebCodecs API to be able to use your hardware encoding and decoding facilities.
Generally speaking, CPU decoding isn't that slow in the first place (compared to any kind of encoding), and hardware encoding is low-quality and lacking in options.
Hardware encoding is great for quickly getting a camera feed to disk at a non-professional quality level, but it's hard to imagine ever using it to do a re-encode of anything -- where you usually want to prioritize quality and a smaller size over encoding speed.
Depends what you're decoding. :) 4k H.265 or AVC will cook your CPU.
When will it become practical to run Linux inside the browser using WASM?
It’s been possible for years. I’m not sure what a good definition of “practical” would be though.
That's exactly why I said "practical" ;)
Probably before WASM bytecode can manipulate the DOM without JavaScript.
The browser seems on track to do everything except giving first-class support for other languages.
I've been studying the WebGPU API, which seems good, and visions of even our game engines being written in JavaScript are continually before my eyes.
Anyone can explain to me why order of input file flag has such an impact on the accuracy of copy ? (Ffmpeg adds/removes randomly few sec)
Are you using it with seeking? Order of the input flag while using seeking determines whether you're using input seeking or output seeking.
Thanks thats probably it.