Description
While reviewing src/lib/ffmpeg.worker.ts, I noticed a possible issue with log listener cleanup in the non-GIF export flow.
A logListener variable is declared before the export logic:
let logListener: ((event: { message: string }) => void) | null = null;
Later, another logListener is declared and registered with FFmpeg:
const logListener = ({ message }: { message: string }) => {
...
};
ffmpeg.on("log", logListener);
However, the cleanup code in the finally block appears to reference the outer variable:
if (logListener) {
ffmpeg.off("log", logListener);
}
Since the inner declaration shadows the outer one, it looks like the registered listener may not be the same reference used during cleanup.
File
src/lib/ffmpeg.worker.ts
Suggested Fix
Instead of redeclaring logListener, assign the callback to the existing variable so the same reference can be used for both registration and cleanup.
logListener = ({ message }) => {
...
};
ffmpeg.on("log", logListener);
I checked existing FFmpeg-related issues and found previous work around progress listener cleanup, but I couldn't find anything covering this specific log listener path.
Description
While reviewing
src/lib/ffmpeg.worker.ts, I noticed a possible issue with log listener cleanup in the non-GIF export flow.A
logListenervariable is declared before the export logic:Later, another
logListeneris declared and registered with FFmpeg:However, the cleanup code in the
finallyblock appears to reference the outer variable:Since the inner declaration shadows the outer one, it looks like the registered listener may not be the same reference used during cleanup.
File
src/lib/ffmpeg.worker.tsSuggested Fix
Instead of redeclaring
logListener, assign the callback to the existing variable so the same reference can be used for both registration and cleanup.I checked existing FFmpeg-related issues and found previous work around progress listener cleanup, but I couldn't find anything covering this specific log listener path.