Any plans to have a version without SharedArrayBuffer?

PaTiToMaSteR commented 3 years ago

Is your feature request related to a problem? Please describe. It's a known problem that SharedArrayBuffer was removed due to Spectre and Meldown hacks.

Describe the solution you'd like A safe version without SharedArrayBuffer

Describe alternatives you've considered I don't have the knowledge in Emcripten nor how you transpile the code to know if it's possible.

Additional context To be able to run this amazing project everywhere we need a version without SharedArrayBuffer!

brunoluiz commented 2 years ago

After seeing so many replies with the same subject, I am going to publish here how to deal with this and how you can compile ffmpeg yourself (some might be afraid or lazy).

Because of the nature of ffmpeg, it is better to have multi-threading to have a better performance. This requires SharedArrayBuffer though, which is the reason many complain it doesn't work / it is not production ready.

@jeromewu already added support to single-thread in the main branch of ffmpeg.wasm-core. The trick is that it is not being published to npm, but it is ready for use basically (trust me). Saying that, to use it you have to do two things:

Build `ffmpeg.wasm-core`

You can build manually by heading to https://github.com/ffmpegwasm/ffmpeg.wasm-core and following the instructions
You can:
- Fork it https://github.com/ffmpegwasm/ffmpeg.wasm-core
- Enable the Github Actions (just go to the Actions tab)
- Push a dummy commit
- Wait the Github Action to spill artefacts (similar to https://github.com/ffmpegwasm/ffmpeg.wasm-core/actions/runs/1050801687)

Fix `ffmpeg.wasm`

In your application, you will realise quite quickly that just using the new compiled ffmpeg will not work (some error message around main or proxy_main).

When you build without multi-threading, proxy_main is not published anymore, if i understood correctly. It is because this is used as a proxy entry point by ECMScripten when dealing with multi-threading + workers to not block the main thread (more details here). With the single-threaded version you want to use main as an entry point.

The easiest way to deal with this is (again) forking this repository, applying this patch and build a dist: https://github.com/ffmpegwasm/ffmpeg.wasm/pull/235. This one is quite straight forward to do locally (npm ci && npm build basically).

Now, in theory your application should work with the following options:

const ffmpeg = createFFmpeg({
  corePath: './<path-to-ffmpeg-core-dist>/ffmpeg-core.js',
  mainName: 'main'
});

Conclusion

While someone doesn't push these changes in a nicer packaged way, there are still work arounds.

About Chrome/Firefox extensions

It seems Chrome manifest v2 extensions have support to SharedArrayBuffer, but Firefox doesn't (as of Jan 2021). So, if you are planning to use the instructions above for browser extensions, bear in mind you will need two versions of the same thing.

brunoluiz commented 2 years ago

I usually vendor the libs used on my Chrome Extensions, so if anyone is looking for compiled versions of the ffmpegwasm-core single-threaded, you are welcome to copy the files at src/vendor/ffmpeg-st*: https://github.com/brunoluiz/gifsane-extension. The ffmpegwasm in there as well is patched to fix the proxy aforementioned issues.

I've written a post with the tricks and caveats around implementing FFmpeg in an extension. Mainly a bit of pain on Firefox, due to the missing SharedArrayBuffer, but I had my way: https://brunoluiz.net/blog/2022/jan/gif-sane-playback-control-ffmpegwasm/

merri-ment commented 2 years ago

Hi @brunoluiz

Thanks for putting together the post.

I have followed it step-by-step (and also tried your vendor files), but i keep coming up against this error when running the single threaded version (Chrome emulator, v98);

Uncaught (in promise) RuntimeError: abort(CompileError: WebAssembly.instantiate(): expected magic word 00 61 73 6d, found 0a 76 61 72 @+0). Build with -s ASSERTIONS=1 for more info.

and similar, yet differently worded error on Safari v15.3 ;

Unhandled Promise Rejection: RuntimeError: abort(CompileError: WebAssembly.Module doesn't parse at byte 0: module doesn't start with '\0asm'). Build with -s ASSERTIONS=1 for more info.

My implementation;

import { createFFmpeg } from '@/vendor/ffmpeg.min'

load = () => {
    return new Promise(async resolve => {
      this.ffmpeg = createFFmpeg({
        log: true,
        corePath: './ffmpeg/ffmpeg-core.st.js',
        mainName: 'main',
      })
      await this.ffmpeg.load()
      resolve()
   })
}

Have you encountered this?

Any help appreciated, Thanks Cam

merri-ment commented 2 years ago

Ok, managed to resolve it. It was to do with the 'st' / 'mt' - id's within the file name.
I didn't following your symbolic link approach, therefore the ffmpeg-core.js could never locate ffmpeg-core.wasm.

web86 commented 2 years ago

Hello @brunoluiz Thanks for the guidence, I have followed all steps, but stacked with the last one:

The easiest way to deal with this is (again) forking this repository, applying this patch and build a dist: #235. This one is quite straight forward to do locally (npm ci && npm build basically).

Sorry for maybe noob question. After changing createFFmpeg.js acording to #235 I should build a package, from this point could you explane more detaily? How to build the package? Can I build it via workflows/main.yml? If so could you share your yml script?

brunoluiz commented 2 years ago

Sorry for maybe noob question. After changing createFFmpeg.js acording to https://github.com/ffmpegwasm/ffmpeg.wasm/pull/235 I should build a package, from this point could you explane more detaily? How to build the package? Can I build it via workflows/main.yml? If so could you share your yml script?

To build the package, you need to:

Clone the ffmpeg.wasm locally
Apply the patch
Call npm ci (installs dependencies)
Call npm build
(Optional) If you want to have your own patched version saved somewhere, you might want to push to your own fork

This will generate a new JS package. The caveat is that, if you want to install in other projects through npm, you might need to publish in npm. You can publish perhaps under a personal scope, such as @USER/ffmpegwasm or something, but PLEASE leave a README note saying that this is a fork etc. As I used it in a Chrome extension, I didn't need to go through this (copied to a local lib folder).