Skip to content

· video-effects-sdk-web

Video Effects SDK 3.12.1 for Web

Compatibility release. 3.12.0 changed how the inference runtime (WASM) is located, and that change broke existing integrations. This release restores them. If you are on 3.12.0, upgrade.

What broke in 3.12.0#

3.12.0 moved to ONNX Runtime 1.27, which replaced the four runtime files (ort-wasm.wasm, ort-wasm-simd.wasm and their threaded/jsep variants) with a single ort-wasm-simd-threaded.asyncify.wasm. Two consequences were not handled:

  • npm consumers with no wasmPaths set. The default location was resolved from the SDK script's own URL, which does not exist in a bundled ESM build — the fallback then pointed at an address that did not serve the file, and the SDK failed to start.
  • Anyone using the pre-3.11 wasmPaths shape ({'ort-wasm.wasm': url, 'ort-wasm-simd.wasm': url, …}). The new code looked for a wasm key, found none, silently ignored the whole configuration and fell back to the default — so a perfectly good self-hosted setup stopped being used.

Neither produced a usable error message: the failure surfaced as an opaque runtime instantiation error that named no URL.

Fixed#

  • Default runtime URL is now version-specific. When wasmPaths is not set, the runtime is loaded from https://effectssdk.ai/sdk/web/<sdk-version>/ort-wasm-simd-threaded.asyncify.wasm. The runtime and the SDK are one build and must match, so the URL now carries the version.
  • Pre-3.11 wasmPaths configurations are accepted again. The file names in them no longer exist, so the directory is taken from the configuration: if it serves ort-wasm-simd-threaded.asyncify.wasm, the SDK keeps loading from your origin; if it does not, it falls back to the CDN so the integration keeps working. Either way a WASM_PATHS_DEPRECATED warning is reported with the URL that was chosen. This path costs one extra HEAD request and is not going to be supported indefinitely — migrate to { wasm: '<url>' }.
  • wasmPaths given as a directory prefix works. Passing a string was mangled into an object of character-indexed keys by config() and silently ignored.
  • sdk_url is taken into account. If you host the SDK assets yourself and the SDK is not loaded from a <script> tag (i.e. the npm package), the runtime is looked for at sdk_url before the CDN default is considered.

Added#

  • WASM_RUNTIME_LOAD_FAILED (1066). When the runtime cannot be loaded, the SDK now checks the URL it used and reports what is actually wrong instead of an opaque ORT failure: the URL, the HTTP status, and the response content type. It specifically recognises a server answering with a page instead of the binary — the usual symptom of an SPA fallback (try_files, dev servers, hosting rewrites) serving index.html for the .wasm path. data carries { url, status, contentType }. The check runs only after a failure, so nothing is added to the normal startup path.
  • WASM_PATHS_DEPRECATED (1067). Reported when a pre-3.11 wasmPaths shape is used; data.resolved is the URL the SDK settled on.

Runtime file resolution order#

  1. wasmPaths.wasm — an explicit URL of the runtime file.
  2. wasmPaths as a string — a directory prefix; the runtime file name is appended.
  3. A pre-3.11 wasmPaths map — the directory it names, with a fallback to the CDN (compatibility path, see above).
  4. The directory the SDK script was loaded from — applies to the <script> tag integration.
  5. sdk_url, when you configured one.
  6. https://effectssdk.ai/sdk/web/<sdk-version>/.

Upgrading#

No changes are required — 3.12.1 is a drop-in replacement for 3.12.0 and for 3.10.x configurations.

If you self-host the assets, note that the runtime file is not part of the npm package. Download it from the CDN folder matching your SDK version and serve it yourself:

https://effectssdk.ai/sdk/web/3.12.1/ort-wasm-simd-threaded.asyncify.wasm
sdk.config({
  wasmPaths: {
    wasm: 'https://your-domain.com/assets/ort-wasm-simd-threaded.asyncify.wasm'
  }
});

Serve it with Content-Type: application/wasm, and make sure the path is not caught by an SPA rewrite rule — a 200 response containing index.html is now reported explicitly, but it still prevents the SDK from starting.

Ready to try it in your app?

Start a free trial in the Developer Portal and run your first effect today.