Free browser-based media tool

Merging Video in a Browser: What It Costs in Memory and Time

The two merge paths differ by two orders of magnitude. Copy-merge moves existing packets, re-encode decodes everything at once. We measured both across 20, 40 and 80 seconds of footage, plus the case that makes a merge fail outright.

Merging Video in a Browser: What It Costs in Memory and Time

The short answer

Merging cost depends entirely on which path runs, and the two paths are not close. Copy-merge only moves the packets that already exist: 8 clips totalling 80 seconds finished in 0.07 seconds with a peak memory of 18 MB. Normalised re-encode has to decode every clip, unify its geometry, and encode the result again: the same 80 seconds took 7.31 seconds and peaked at 301 MB.

So the question 'how long a video can I merge in a browser' does not have one answer. On the copy path, length is almost free and the limit is how long you are willing to wait for the file to be read. On the re-encode path, memory grows with total duration and that is the number to watch.

What we measured

Eight clips of identical 640x360 30fps footage with audio, each 10 seconds, merged into a 1280x720 output.

Copy-merge, 20 s total: 0.04 s, 17 MB peak, output 20.021 s.
Copy-merge, 40 s total: 0.05 s, 17 MB peak, output 40.021 s.
Copy-merge, 80 s total: 0.07 s, 18 MB peak, output 80.021 s.
Re-encode, 20 s total: 1.72 s, 226 MB peak, output 20.010 s.
Re-encode, 40 s total: 5.07 s, 249 MB peak, output 40.021 s.
Re-encode, 80 s total: 7.31 s, 301 MB peak, output 80.042 s.

Why the copy path is nearly free

Look at the 80-second row: 0.07 seconds, and the peak memory barely moved from the 20-second case. That is because no frame is ever decoded. The tool writes a short playlist listing your clips and asks the engine to concatenate the existing streams, so the work is proportional to the file size, not to the duration.

The failure mode that made pre-flight necessary

Copy-merge is only safe when every clip shares the same codec, resolution, pixel format, frame rate and audio parameters. When they do not, the merge does not politely stop. We merged a 640x360 30fps clip with a 1280x720 25fps clip, both exactly 2 seconds. The output came back as 3.696 seconds and 110 frames — 10 frames short of the 120 it should have contained — and the command exited with success and no warning at all.

That is why the merge tool probes every clip before it starts instead of waiting for an error. If the signatures do not match, it does not try the copy path and then fall back — it switches to the re-encode path up front and tells you which parameter differed.

Re-encode has to use the concat filter rather than the concat demuxer, and the difference is measurable. Re-encoding the mismatched pair through the demuxer produced 3.715 seconds; the filter produced 4.025 seconds, within a frame of the real 4.000.