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
wasmPathsset. 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
wasmPathsshape ({'ort-wasm.wasm': url, 'ort-wasm-simd.wasm': url, …}). The new code looked for awasmkey, 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
wasmPathsis not set, the runtime is loaded fromhttps://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
wasmPathsconfigurations are accepted again. The file names in them no longer exist, so the directory is taken from the configuration: if it servesort-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 aWASM_PATHS_DEPRECATEDwarning is reported with the URL that was chosen. This path costs one extraHEADrequest and is not going to be supported indefinitely — migrate to{ wasm: '<url>' }. wasmPathsgiven as a directory prefix works. Passing a string was mangled into an object of character-indexed keys byconfig()and silently ignored.sdk_urlis 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 atsdk_urlbefore 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) servingindex.htmlfor the.wasmpath.datacarries{ 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.11wasmPathsshape is used;data.resolvedis the URL the SDK settled on.
Runtime file resolution order#
wasmPaths.wasm— an explicit URL of the runtime file.wasmPathsas a string — a directory prefix; the runtime file name is appended.- A pre-3.11
wasmPathsmap — the directory it names, with a fallback to the CDN (compatibility path, see above). - The directory the SDK script was loaded from — applies to the
<script>tag integration. sdk_url, when you configured one.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.