Description
this benchmark clearly shows that even though I'm deleting every single file from FFmpeg’s virtual FS, each execution time with the same args still climbs steadily from ~300 ms at iteration 0 up to ~2s at iteration 25. Since the on‐disk file count stays at seven, this is almost certainly a leak inside the in‐memory Wasm instance itself (heap growth, cached JIT, growing command history, etc.), not a buildup of files on the virtual filesystem.
the surprising part is the single core version doesn't have this issue.
setting the -threads to 1 doesn't help the mt-core either.
THE TEST:
for (let i = 0; i < 20 ; i++) {
console.time();
await ffmpeg.exec(args);
await ffmpeg.deleteFile(outputName); // Remove from FFmpeg FS
console.timeEnd();
};
OUTPUT:
531.352783203125 ms
386.77001953125 ms
372.251953125 ms
402.16015625 ms
401.3720703125 ms
443.300048828125 ms
502.0791015625 ms
596.52490234375 ms
621.933837890625 ms
740.550048828125 ms
816.83203125 ms
800.94580078125 ms
1102.08984375 ms
1258.649169921875 ms
1236.9541015625 ms
1372.076904296875 ms
1410.0791015625 ms
1504.469970703125 ms
1635.94091796875 ms
1686.94482421875 ms
############
in the single core version, intervals are steady for 25 iterations in a row. I don't have the output to prove it anymore.
############
tested on chrome, multicore, 4 threads:
const args = [
'-ss', region.start.toFixed(2),
'-i', 'input.mp4',
'-t', (region.end - region.start).toFixed(2),
// VIDEO
'-c:v', 'libx264', // Standard YouTube codec
'-crf', '20', // Sweet spot for YouTube-like quality
'-preset', 'ultrafast', // No size compression - around 2.5 larger files than input
'-profile:v', 'high', // YouTube-compatible profile
'-pix_fmt', 'yuv420p', // Standard YouTube pixel format
'-movflags', '+faststart', // Enable streaming
// AUDIO
'-c:a', 'aac', // YouTube's audio codec
'-b:a', '128k', // YouTube-standard bitrate
// PERFORMANCE
'-threads', '4',
'-avoid_negative_ts', '1',
outputName
];