Does not work in Firefox 79+ because SharedArrayBuffer is undefined

[amn]

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:

1. Go to https://ffmpegwasm.github.io/
2. Scroll down to 'Demo'
3. 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

[n0x3u5]

Could it be because of missing COOP/COEP headers?

I faced the same issue in the ffmpeg.wasm demo in its Github page. Some casual searching led me to this issue in Bugzilla which led me to this page on web.dev. Also the Firefox 79 for developers page which @amn linked says the same thing.

I guess the Github page needs to be configured to send the correct headers?

[jeromewu]

Yes, it is the retriction in github page, please reference this issue for more details: #102

[jeromewu]

I have tried to host the page in Google App Engine, in firefox the SharedArrayBuffer is detected but there is an OOM error in the end, for those who are interested, please check this link: https://ffmpegwasm.et.r.appspot.com

[diegocr]

video.src = URL.createObjectURL(new Blob([data.buffer], { type: 'video/mp4' }));

This kind of usage will always raise an OOM with any relatively large video, rather the transcoded chunks should be streamed into an MSE container.

[jeromewu]

The interesting part is that the exactly same code works fine on Chrome, so I think there is some limitation inside Firefox that makes it OOM.

[amn]

This OOM detour isn't FFmpeg specific per se, but I'd still want to point out the following.

When in doubt, look at the spec -- https://w3c.github.io/FileAPI/#blob-section -- does the spec mandate anything that would say, force a user agent vendor to implement Blob in a way where a large enough Blob would always bring about OOM error(s)? I don't see anything in the spec pointing to that. Certainly, if I were making a user agent, for construction of blobs from other blobs, or even byte arrays, I could implement some sort of copy-on-write strategy, where a blob would share memory with the data that was passed to it during construction -- a blob is immutable, after all, so that makes it ever more so appealing to not copy data which certainly would cause memory consumption to baloon given enough blobs of large enough size.

My point is that this is browser specific since the spec does not say anything of the "you must allocate memory for each blob" sort. A naive implementation would certainly do, but there are ways to avoid that. For instance, let's say you already have a big number of smaller blobs, you then construct a large blob using an array of the smaller blobs. How much additional memory must a user agent allocate? There is no definite answer to that -- beyond the allocation of an array of what amounts to trivial references to existing blobs, even the large blob constructed may simply reference existing blobs in a way that is transparent to the Blob API consumer, including other facilities in the user agent itself, that use blobs.

Practically, and exactly because the spec also does not mandate blobs reuse references to data they were constructed with (no mandating copy-on-write), you cannot guarantee there won't be OOM errors. Most likely there will be, even in Chrome, given sufficient amount and sizes of blobs. Memory is finite resource. The only way out is another API, a ReadableStream perhaps, but now I am being very general here.

[amn]

If you "stream chunks to an MSE container" (MediaSource.appendBuffer I think is what is being hinted at here), versus allocating a resource (which you can download in its entirety) using a Blob and a URL, you won't ever have the entire resource if it's sufficiently large -- MSE API deals with buffers differently -- earlier data may be evicted while you're appending more data, meaning that it's playback of some subset of the resource that is guaranteed, like with live streaming -- the video may not provide you with everything you ever appended to it, don't count on being able to "Save As" what's playing from start to finish. It will only work for preview (although it will indeed). See https://w3c.github.io/media-source/#sourcebuffer-coded-frame-eviction.

What you could do, and this is speculation now on my part, is look into the Cache API to see if you could construct a "cached" version of the resulting resource, which is allocated on disk (being that the Cache API uses persistent storage), and then construct a URL to the cached resource and/or fetch the resource (which can be intercepted and served from the cache).

[diegocr]

Blobs in Chrome may be disk-based, so using them may doesn't hit an OOM like in Firefox, memory is finite just like persistent/disk storage or given the restrictions browser vendors may impose on this (beyond what is stated in an specification), hence any browser including Chrome can face an OOM depending the amount of data you feed it. Did anybody tested this with a +3GB video?

Here MSE shall be used if the end purpose is streaming the video as in the demo, in a nutshell that is by appending the transcoded chunks in real-time until a certain threshold is reached to prevent the MSE's SourceBuffer from reaching a quota error (i.e. ala-OOM). This way should certainly be much more cross-browser reliable and UX-friendly than loading/transcoding the whole video in memory and then start playing it, by using MSE it could start playing within a few seconds.

[jeromewu]

I managed to run it in Firefox 79 in Kali OS, here is the screenshot for your reference:

[thijstriemstra]

See #102 (comment) on how to fix the header issue in Firefox.

[AE1020]

Hello, I am trying http://ffmpegwasm.et.r.appspot.com/ with Firefox 83 and it is saying that SharedArrayBuffer is undefined, as in the issue title.

I can confirm from the inspector tools that the headers are set appropriately mentioned in #102. They are included in the lower right of the screenshot below:

I see the last comment on this issue is recent (18 days ago)...so I'm wondering if it's something that just broke, or if it's just something weird about my Firefox?

My settings in about:config are the default (I think). I have messed with them in the past but this is a fresh Firefox install:

[AE1020]

I think I figured out the problem...it is because of having an http link instead of https.

(It seems that demo URL is not automatically forwarding to the secure site if you have a non-secure link.)

[thijstriemstra]

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

[anesuc]

Yep can confirm. I get a warning about this in chrome in dev tools:

Deprecation] SharedArrayBuffer will require cross-origin isolation as of M91, around May 2021. See <URL> for more details.