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();
};
rounded output in ms:
531
387
372
402
401
443
502
597
622
741
817
801
1102
1259
1237
1372
1410
1504
1636
1687
############
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
];