h264-mp4-encoder
                                
                                 h264-mp4-encoder copied to clipboard
                                
                                    h264-mp4-encoder copied to clipboard
                            
                            
                            
                        Ideas on Improving Performance
First, thanks for this work so far! I’ve got a fork where I’m exploring ways to improve performance, among them:
- use the wasm build as it should load and run faster for some browsers, in theory. This may not be ideal for npm/distribution but having it as an additional built file for users to download might be nice.
- use two workers in my app, one for rendering frames to YUV, and another for encoding YUV with the wasm lib.
- using more direct memory access from JS
https://github.com/mattdesl/h264-mp4-encoder
I followed the guide below and ended up finding an alternative approach that seems to run a lot faster, by just passing a pointer to emscripten’s HEAP8 memory to the C lib rather than a full buffer. Details: https://developer.mozilla.org/en-US/docs/WebAssembly/existing_C_to_wasm
You can see my version in the fork and also in this test app: https://github.com/mattdesl/client-mp4-test/blob/7d9ce9bb05c5cbed83a38b27eba590413b1acf80/encoder/encoder.js#L45
So, perhaps a more optimized / manual memory access API could be exposed for a subset of users of your library looking for a bit more speed. I’m also wondering if there are some other areas in the JS or C++ code that could be improved overall, as it’s still very slow compared to ffmpeg.
Nevertheless I’m impressed it’s working so well. :)
Some updates if you are curious —
I have a demo now that combines some workers, direct Emscripten HEAP8 access, and other things to get really high performance encoding:
https://mattdesl.github.io/mp4-wasm-encoder/
I've made lots of tweaks in my fork of your repo, as well as some slight tweaks in my minih264 fork to try and get more SIMD operations inclued in the WASM build. My version is now using minimp4 instead of libmp4v2 to write NAL data and create the MP4. As a result, the code is a bit simpler and the WASM size went from ~700KB to ~200KB. Pretty impressive gains compared to the current ~1.7MB pure asm.js version!
@mattdesl this is awesome! I've been this module today extensively for recording some awesome demos for work, but wished it would be faster — takes 5 minutes to encode an 8-second 1920x1080x60 video. Can't wait for this work to get packaged into a bundle with the same API!