Hi there,
I'm looking into replacing our usage of ffmpeg.wasm with MediaBunny and generally it's great, access to Web Codecs is wonderful. In a specific transmuxing use case I'm having performance problems though. There is a chance this is still user error, but I have really tried to bottom out any potential performance sinks; the result though is that no matter how I manage to optimise the MediaBunny transmux flow, the ffmpeg.wasm path is still an order of magnitude faster.
This might just be an inevitability of WASM vs JS, and we can keep using ffmpeg.wasm for this limited case if you folks don't feel the need to dig into it, but I thought I should raise it with you anyway.
So as an example, with Opus packets in a Webm container I had these results. The audio file in each case was between 2 - 3 hours long.
┌───────────────────────────────────────┬───────┬───────────┬───────────┬──────────────┐
│ Config │ Input │ executeMs │ per-MB │ per-packet │
├───────────────────────────────────────┼───────┼───────────┼───────────┼──────────────┤
│ Conversion + StreamTarget chunked │ 56 MB │ 13.8 s │ 246 ms/MB │ — │
├───────────────────────────────────────┼───────┼───────────┼───────────┼──────────────┤
│ Conversion + BufferTarget │ 41 MB │ 8.1 s │ 196 ms/MB │ — │
├───────────────────────────────────────┼───────┼───────────┼───────────┼──────────────┤
│ Manual pump + StreamTarget chunked │ 43 MB │ 8.3 s │ 193 ms/MB │ 68 µs/packet │
├───────────────────────────────────────┼───────┼───────────┼───────────┼──────────────┤
│ Manual pump + BufferTarget (this run) │ 63 MB │ 14.9 s │ 237 ms/MB │ 85 µs/packet │
└───────────────────────────────────────┴───────┴───────────┴───────────┴──────────────┘
Whereas the ffmpeg equivalent completes in less than a second.
I think this boils down to a synchronous loop + a memecpy in WASM for the ffmpeg version vs the overhead of microtasks, allocation, etc. in JS; so as I said, understandable if it's not something you want to / can't improve right now, shipping your own WASM blob would also be a big ask!
Hi there,
I'm looking into replacing our usage of ffmpeg.wasm with MediaBunny and generally it's great, access to Web Codecs is wonderful. In a specific transmuxing use case I'm having performance problems though. There is a chance this is still user error, but I have really tried to bottom out any potential performance sinks; the result though is that no matter how I manage to optimise the MediaBunny transmux flow, the ffmpeg.wasm path is still an order of magnitude faster.
This might just be an inevitability of WASM vs JS, and we can keep using ffmpeg.wasm for this limited case if you folks don't feel the need to dig into it, but I thought I should raise it with you anyway.
So as an example, with Opus packets in a Webm container I had these results. The audio file in each case was between 2 - 3 hours long.
Whereas the ffmpeg equivalent completes in less than a second.
I think this boils down to a synchronous loop + a memecpy in WASM for the ffmpeg version vs the overhead of microtasks, allocation, etc. in JS; so as I said, understandable if it's not something you want to / can't improve right now, shipping your own WASM blob would also be a big ask!