ffmpeg.wasm: Does not work in Firefox 79+ because SharedArrayBuffer is undefined

Describe the bug The front page says:

Your browser doesn’t support SharedArrayBuffer, thus ffmpeg.wasm cannot execute. Please use latest version of Chromium or any other browser supports SharedArrayBuffer.

To Reproduce Steps to reproduce the behavior:

Go to https://ffmpegwasm.github.io/
Scroll down to ‘Demo’
See quoted error

Expected behavior As SharedArrayBuffer is available in the aforementioned versions of Firefox (on certain conditions), I think it is fair we don’t fall into the “this only works in Chrome” bane of Web applications made today, especially if the application may in fact work in Firefox and the latter only refuses to provide the object for security reasons: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#JavaScript

Desktop (please complete the following information):

OS: Windows 10 x86-64
Browser Firefox 64-bit
Version 81.0.1

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 11
Comments: 29

Most upvoted comments

For those that want to host a demo/app on a domain where you can’t control the headers, with a service worker you can actually set the required COOP and COEP headers. See the coi-serviceworker repo, and this blog post that explains the approach.

It’s a bit crazy, but it’s a solution for demos hosted on Github pages.

gzuidhof on Aug 21, 2021

I was able to fix this in Chrome for a react project on netlify by creating a netlify.toml with these headers:

[[headers]]
  for = "/*"
  [headers.values]
      Cross-Origin-Opener-Policy = "same-origin"
      Cross-Origin-Embedder-Policy = "require-corp"

trybick on Aug 7, 2021

The header issue in Firefox is also coming to Chrome: https://blog.chromium.org/2021/02/restriction-on-sharedarraybuffers.html

thijstriemstra on Feb 17, 2021

If someone is using vite as a dev environment, I managed with this. https://github.com/chaosprint/vite-plugin-cross-origin-isolation

Fanna1119 on Nov 9, 2021

For local development, I recommend using --enable-features=SharedArrayBuffer to launch Chrome. https://web.dev/cross-origin-isolation-guide/#:~:text=gotchas

agektmr on Aug 6, 2021

To enable SharedArrayBuffer, the website needs to adopt “cross-origin isolation”. Here’s a guide to enable it: https://web.dev/cross-origin-isolation-guide/

The downside of this is all resources loaded onto the same page needs to opt-in by sending Cross-Origin-Resource-Policy: cross-origin header or provide CORS. Otherwise the resource will be blocked loading. There are some other nuances too. To learn more details: https://web.dev/coop-coep/

You can try emulating the headers on this demo site: https://first-party-test.glitch.me/

What I would recommend is to determine whether the page is cross-origin isolated by examining self.crossOriginIsolated. Use SharedArrayBuffer when it returns true and do not use when it returns false.

agektmr on Apr 6, 2021

Sorry, I should’ve been more clear. When I said locally, I meant serving them locally as opposed to from unpkg.com. Starting in May, the unpkg cdn will be broken for everyone because the headers required restrict including assets from other URLs.

Here’s the hack I came up with to serve it from the same domain: https://github.com/ffmpegwasm/ffmpeg.wasm/issues/166#issuecomment-794615598

I totally get that this is a tech demo and bleeding edge. I think the long term solution would be to fallback to a single thread without SharedArrayBuffer. But I have no idea how complex that is in practice 😃

A non-shared array fallback would make it work for most browsers, and more cases where developers don’t have access to web server configs.

AndrewDubya on Mar 10, 2021