feat: allow passing binary data directly to load()

[JacobiusMakes]

Summary

• Adds coreData, wasmData, and workerData options to FFMessageLoadConfig accepting ArrayBuffer | Uint8Array | Blob
• When binary data is provided, it takes precedence over the corresponding URL option and is converted to a Blob URL internally via URL.createObjectURL()
• Zero changes to the web worker — binary data is transparently resolved to Blob URLs before being sent

Motivation

Closes #865

Environments like userscript extensions (Greasemonkey/Violentmonkey) can fetch WASM binaries via GM_xmlHttpRequest (which bypasses CORS), but cannot pass the result to ffmpeg.wasm because load() only accepts URL strings. This change lets callers pass pre-fetched binary content directly:

const wasmBinary = await GM_xmlHttpRequest({ url: WASM_CDN, responseType: 'arraybuffer' });

const ffmpeg = new FFmpeg();
await ffmpeg.load({
  coreURL: 'blob:...',       // or coreData
  wasmData: wasmBinary,      // ArrayBuffer, Uint8Array, or Blob
});

Implementation

The conversion happens in the main thread (classes.ts) before the config is sent to the worker via postMessage. A small toBlobURL helper creates a Blob URL from the binary data using the appropriate MIME type (text/javascript for core/worker JS, application/wasm for WASM). The worker receives plain URL strings as before, so no worker-side changes are needed.

Test plan

• Verify existing URL-based load() still works (no regression)
• Verify load({ wasmData: new Uint8Array(...) }) loads successfully
• Verify load({ wasmData: new Blob([...]) }) loads successfully
• Verify load({ coreData: ..., wasmData: ... }) with both binary options works
• Verify binary data takes precedence when both wasmURL and wasmData are provided
• TypeScript compilation passes with no errors

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for ffmpegwasm canceled.

Name	Link
🔨 Latest commit	ad665df
🔍 Latest deploy log	https://app.netlify.com/projects/ffmpegwasm/deploys/69c6130bfdedda0008d28f1c