免费浏览器端媒体工具

在浏览器里合并视频：内存与时间的真实成本

两条合并路径的成本差两个数量级：流拷贝只搬运已有数据包，统一重编码要同时解码所有片段。我们在 20、40、80 秒三档时长上分别实测了两者的内存与耗时，也测了会让合并直接失败的那种情况。

在浏览器里合并视频：内存与时间的真实成本

先说结论

合并的成本完全取决于走哪条路径，而两条路径不在一个量级上。流拷贝只搬运已经存在的数据包：8 段合计 80 秒的素材，0.07 秒完成、峰值内存 18 MB。统一重编码要把每段都解码、统一画幅、再重新编码：同样的 80 秒耗时 7.31 秒、峰值内存 301 MB。

所以「在浏览器里能合并多长的视频」没有单一答案。走流拷贝时，时长几乎不花成本，限制只在于您愿意等文件读取多久；走重编码时，内存随总时长增长，那才是需要盯住的数字。

实测数据

八段规格完全一致的 640x360、30fps 带音轨片段，每段 10 秒，合并输出为 1280x720。

流拷贝，合计 20 秒：0.04 秒、峰值 17 MB、输出 20.021 秒。
流拷贝，合计 40 秒：0.05 秒、峰值 17 MB、输出 40.021 秒。
流拷贝，合计 80 秒：0.07 秒、峰值 18 MB、输出 80.021 秒。
重编码，合计 20 秒：1.72 秒、峰值 226 MB、输出 20.010 秒。
重编码，合计 40 秒：5.07 秒、峰值 249 MB、输出 40.021 秒。
重编码，合计 80 秒：7.31 秒、峰值 301 MB、输出 80.042 秒。

为什么流拷贝几乎不花成本

看 80 秒那一行：0.07 秒，峰值内存和 20 秒那档几乎没区别。原因是一帧都没有被解码。工具只写一份列出片段的播放清单，然后让引擎把已有的流拼接起来，因此工作量与文件体积相关，而与时长无关。

那个让「预检」变得必要的情况

只有当所有片段的编码、分辨率、像素格式、帧率和音频参数完全一致时，流拷贝才是安全的。不一致时，它不会礼貌地停下。我们把一段 640x360、30fps 和一段 1280x720、25fps 合在一起，两段各自正好 2 秒；输出却是 3.696 秒、110 帧 —— 比应有的 120 帧少了 10 帧，而命令以「成功」退出，没有给出任何警告。

这就是合并工具为什么在开始前先逐段探测，而不是等它报错。一旦发现各段参数不一致，它不会先试流拷贝再回退，而是直接改用重编码路径，并告诉你是哪个参数不一样。

重编码必须用 concat 滤镜，而不是 concat 解复用器，这个差别是可测量的。同样那对异规格片段，走解复用器重编码得到 3.715 秒；走滤镜得到 4.025 秒，与真实的 4.000 秒只差一帧以内。