Repository navigation
fix(ffmpeg): backport upstream load, proxy, writeFile and Node path fixes - #72
Conversation
…tream load, proxy and writeFile fixes
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 58 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
This PR backports several upstream fixes: (1) second load() waits for in-flight load and returns false without creating a duplicate core; failed loads clear state for retry. (2) load() errors name the wasmURL when the response isn't WebAssembly. (3) mount() uses Object.hasOwn to reject proto/constructor. (4) on/off are arrow functions so they work through Proxies. (5) writeFile adds {transfer:false} to copy instead of transfer. (6) Node worker accepts filesystem paths and file: URLs for coreURL/wasmURL via pathToFileURL. (7) fetchFile(Blob) uses blob.arrayBuffer() instead of FileReader. (8) Dynamic import carries turbopackIgnore. Tests cover all new behavior.
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
Backports from upstream ffmpegwasm/ffmpeg.wasm, fitted to this fork's code.
Changed
load()on a loaded instance no longer creates a second core and leaks the first. It waits for any load in flight, keeps the loaded core, and resolvesfalse(the existing "first" meaning ofIsFirst, so the return type is unchanged). A failed load clears the state so a retry works. Bothworker.tsandworker-node-entry.mts. From #972.load()throws an error naming thewasmURL. Also from Fix double load(), name a non-wasm wasmURL, TS < 4.4 types, internal setTimeout ffmpegwasm/ffmpeg.wasm#972. The TS<4.4 typing change is skipped.mount()checksObject.hasOwnonFS.filesystems, so__proto__andconstructorreturnfalse. From #958, that part only.onandoffare arrow-function class fields, so they work through a Proxy such as Vue'sreactive()(upstream issue Using vite + vue:TypeError: Cannot read from private fieldffmpegwasm/ffmpeg.wasm#687).writeFile(path, data, { transfer: false })copies the array instead of transferring it; the default is unchanged. Docs and theload()doc comment updated. From #979, without its unload-after-trap part (PR fix(core): end the argv array with NULL #70 covers that area)./* turbopackIgnore: true */next to@vite-ignoreon the dynamic core import. From #994.classWorkerURLresolution is untouched.file:URLs forcoreURLandwasmURL, converting paths withpathToFileURL.fetchFile(Blob)usesblob.arrayBuffer(), so it works whereFileReaderis undefined. Remainder of #956.CHANGELOG has an Unreleased section for these.
Tests
Added to
tests/ffmpeg-node.test.mjs: Blob read withoutFileReader,on/offthrough a Proxy, secondload()keeps the core,mount("__proto__")andmount("constructor")return false,writeFiletransfer vstransfer: false, pathcoreURL/wasmURL, and a non-wasmwasmURLerror.Verified locally
pnpm install --frozen-lockfile,pnpm build,pnpm lint,pnpm run test:node:helpers:args, and the Blob, Proxy andfetchFilecases offfmpeg-node.test.mjs(they need no core).Not run locally
ffmpeg-node.test.mjs(second load, mount names, transfer, path URLs, non-wasm error), in st and mt. No built core on the Pi.Noticed, not fixed
load()calls where the first fails: the waiting calls reject with the same error rather than retrying.