ffmpegwasm/ffmpeg.wasm

each exec() takes more and more time (mt-core)

ofirgaash1 opened this issue · 1 comments

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
    ];

same issue.