failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): Compiling function #67 failed: Invalid opcode 0xfe (enable with --experimental-wasm-threads)

[schyjxy]

emscripten version 2.011
ffmpeg version 4.2.2， when the android brower load the wasm file, it print the error:
failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): Compiling function #67 failed: Invalid opcode 0xfe (enable with --experimental-wasm-threads) @+16226

this is my build scripts:

emcc -I "./include"
-O2
-s WASM=1
-lavcodec -lavformat -lavutil -lswscale
-s TOTAL_MEMORY=${TOTAL_MEMORY}
-L ./lib
-s ASSERTIONS=1
-s EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS}"
ffmpegTest.c
-s RESERVED_FUNCTION_POINTERS=14
-s ALLOW_MEMORY_GROWTH=1
-s USE_PTHREADS=0
-o ffmpeghelper.js

[sbc100]

This probably means that WebAssembly threading (and SharedArrayBuffer which it requires) is not enabled. Enabling SharedArrayBuffer outside of desktop chrome requires special HTTP headers. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Security_requirements

[sbc100]

Oh, sorry, I see you are trying to build without USE_PTHREADS. In that case I think probably what is happening is that you are compiling some object files with atomics enabled (-pthread or -sUSE_PTHREADS) but linking without threading. I think case emscripten is assuming that the browser is able to lower the atomics away relying on this feature of the threads proposal: WebAssembly/threads#144.

Perhaps chrome for android does not yet support that feature? @tlively do you know the status? In which case the safest option is to find and remove any -pthread arguments from any/all object files that you include.

[schyjxy]

Maybe chrome for android dosn't support thread or atomics, can I add the options "-- disable-pthreads " to avoid this error ?
this is my ffmpeg compile scripts:

emconfigure ./configure
--cc="emcc"
--cxx="em++"
--ar="emar"
--ranlib="emranlib"
--prefix=$(pwd)/dist
--enable-cross-compile
--target-os=none
--arch=x86_32
--cpu=generic
--enable-gpl
--enable-version3
--disable-avdevice
--disable-swresample
--disable-postproc
--disable-avfilter
--disable-programs
--disable-logging
--disable-everything
--enable-avformat
--enable-decoder=hevc
--enable-decoder=h264
--enable-decoder=aac
--disable-ffplay
--disable-ffprobe
--disable-ffserver
--disable-asm
--disable-doc
--disable-devices
--disable-network
--disable-hwaccels
--disable-parsers
--disable-bsfs
--disable-debug
--enable-protocol=file
--enable-demuxer=mov
--enable-demuxer=flv
--disable-indevs
--disable-outdevs

[tlively]

Hmm, it would be sad if Chrome on Android didn't support atomic instructions with unshared memories. @dtig, do you know what the status is there?

In which case the safest option is to find and remove any -pthread arguments from any/all object files that you include.

I agree that this is the best fix in the meantime. You could examine the output with EMCC_DEBUG=1 to search for errant -pthread flags.

[schyjxy]

I had added the flags "--disable-pthreads --disable-w32threads " yesterday. It can run on chrome mobile now，but it is inefficient. It will spent 50 ms to decode a h264 high profile frame.

[dtig]

IIRC, this should be supported by default everywhere - this used to be behind a flag in the backend, but now should be enabled everywhere. I don't see anything specific to Android here, except perhaps an older Chrome version that does not support this? @schyjxy Could you update this thread with the version of Chrome you are currently using?

[tlively]

@schyjxy

It can run on chrome mobile now，but it is inefficient.

Unfortunately just getting atomic operations to work on chrome mobile won't be enough to improve performance. You would need real threading support with SharedArrayBuffer and shared WebAssembly memories to see an improvement. I'm not sure what the timeline for supporting those on mobile looks like.

[sbc100]

@schyjxy

It can run on chrome mobile now，but it is inefficient.

Unfortunately just getting atomic operations to work on chrome mobile won't be enough to improve performance. You would need real threading support with SharedArrayBuffer and shared WebAssembly memories to see an improvement. I'm not sure what the timeline for supporting those on mobile looks like.

I though that all worked now as long as you setup you http headers correctly: https://web.dev/coop-coep/. Am I wrong?

[schyjxy]

@tlively Chrome for mobile(version 87.0.4280.101) is disabled by default, you can open url chrome://flags/ to enable WebAssembly threads support.

[dtig]

@sbc100 SharedArrayBuffers are not available by default on Android, so that is probably the gating issue. From the Web.dev article linked, "Shared Array Buffer on Android Chrome will be available from Chrome 88.".

[schyjxy]

It's a feasible measure to put the video code on a webworker.