视频合并
把几个片段按你排的顺序接成一个视频。同一台相机、同一次录制出来的片段，参数往往一致，数据包一段接一段搬过去就行——不解码、不重编，画质原样保留，几秒钟就完事。FFmpeg 全程在浏览器标签页里跑，文件不会上传。
- 开始之前先把每个片段和第一个逐项比一遍，只要对得上就直接拼接，不重新编码
- 分辨率不一样、手机横过来拍的、整段没声音的，这几种情况都会先识别再处理
把视频片段拖到这里
可以一次选多个——文件留在你自己机器上，不会上传
可读取 MP4、MOV、MKV、WebM、AVI、WMV、FLV、MPEG-TS、MPG、3GP，以及 FFmpeg 认识的绝大多数格式。
还没有片段
添加两个以上视频文件就能开始。引擎会在你添加之后才下载。
功能简介
想合并的片段，多数是同一台设备前后几分钟里拍的，在每一项要紧的参数上本来就完全一致。这个工具会先把这件事查清楚，一旦成立，就一帧都不解码地把它们接起来。
- 01
能不重编就不重编
GoPro 的分段、行车记录仪的一段段录像、录屏到 4 GB 自动切开的两半——它们编码格式、画面尺寸、声音参数都一样，所以数据包可以原封不动地并进同一条轨道。这是几秒钟的事，结果和原片一模一样。那些一律重编的网站，是在为同一件事收走你一个小时和一代画质。
- 02
把不一致的地方指到具体哪一段
每个片段都会和第一个逐项比对：编码格式、画面尺寸、旋转角度、像素格式、帧率，还有声音那几项参数。哪一项不一样，就把两边的值和是哪个片段一起摆出来。这就是「这活儿得干一个小时」和「九段里只有一段是 720p」之间的差别。
- 03
把没声音的那段处理对
一段有声音、一段没声音接在一起，是多数工具悄悄出错的地方：要么那一段在时间轴上直接没了位置、后面的声音整体提前，要么整条音轨干脆消失。这里的做法是按那段的长度补上等长的静音，声音从头到尾都待在该待的位置。
- 04
给你之前先自己核一遍
合并可以顺利结束、退出码为零，却把某一段的数据包丢掉了——文件能播，只是提前结束。这种事往往要等发出去之后才有人发现。所以做好的文件会被重新读一遍，跟各片段加起来的总时长比对，短了就报出来，而不是直接交给你。
- 05
顺序是真的能调
拖一行就能换位置，也可以用箭头按钮。按文件名排序是按人读的方式排的，clip2 在 clip10 前面、GX010042 在 GX020042 前面；也可以按文件写入时间排——相机那种自作主张的分段编号，这一招最管用。每一行都有缩略图，顺序是看出来的，不用靠猜。
- 06
全程本地，不上传
FFmpeg 编译成 WebAssembly 在标签页里运行。不上传、不排队、不打水印、不绑账号，也不会限制单个片段的长度。浏览器内存决定了总大小的实际上限，而采访素材、客户录像、执法记录仪文件则始终留在你自己的机器上。
如何使用
从一堆散片段到一个文件，四步。
- 01
把视频文件加进来——可以一次拖好几个，也可以用文件选择框。引擎从这时开始下载，大约 31 MB，只需要这一次。随后每个片段都会被读一遍编码格式、画面尺寸、帧率和声音。
- 02
排好顺序。可以拖动某一行、用箭头按钮微调，也可以按文件名或按时间排序——相机的分段文件通常按一下「按文件名」就归位了。
- 03
看右边的比对结果。它会说这些片段能不能不重编就接起来，如果不能，是哪一项参数、哪个片段不一样。除非你需要一个指定的画面尺寸或输出格式，否则方式就放在自动。
- 04
按合并。做好的文件会先和各片段的总时长核对一遍，再出现在右边，下载之前就能先播来看看。
功能说明
决定你拿回来的到底是不是想要的那个文件的那些细节。
- 参数一致时直接复制数据流完成拼接，全程没有解码这一步，画质分毫不损
- 逐片段比对编码格式、画面尺寸、旋转角度、像素格式、编码档次、像素宽高比、帧率和声音各项参数
- 帧率单独标注，因为仅帧率不一致时不会直接触发重新编码
- 一次最多 20 个片段，可拖动排序、用按钮微调，也能按文件名或文件时间排序
- 文件名按人读的方式排序，clip2 排在 clip10 前面，相机分段自然落回拍摄顺序
- 每个片段都有浏览器在本地画出的缩略图，顺序是看出来的而不是推出来的
- 给没有音轨的片段补上等长静音，后面的片段不会因此整体提前
- 参数不一致时自动统一到同一个画幅、同一个帧率、同一个像素格式和同一套声音参数
- 形状对不上输出画幅的片段可选完整放入并用黑、白或自选颜色补边，也可以填满裁掉或直接拉伸
- MP4、MKV、WebM、MOV 四种输出容器，默认跟随片段自身的容器，好让参数一致的一组能走复制
- 成品会拿总时长和各片段加起来的长度核对，中途截断的合并会被报出来而不是直接交付
- 全程在浏览器标签页里完成——不上传、不排队、不注册、不打水印，也不限制单个片段时长
适合哪些场景
人们跑来找视频合并工具时，手上通常是这几种情况。
-
GoPro 或运动相机的分段文件
运动相机会把一次长录像切成一串编号文件——GX010042、GX020042 这样，原因是文件系统的限制，画面本身并没有变。它们彼此完全兼容，所以按文件名排一下再按合并，几秒钟就接回去了，一帧都不用动。
-
一趟行程的行车记录仪录像
行车记录仪每一分钟、三分钟或五分钟就新起一个文件，开一个小时就是二十来个。在查看或者提交事故素材之前把它们接成一个，整段经过才读得下去；文件名乱七八糟的时候，按时间排序也能把顺序摆正。
-
录屏录到 4 GB 自动切开
长时间录制会撞上 FAT32 或者相机的大小上限，然后在第二个文件里接着录，往往正好断在一句话中间。两半出自同一个编码器，所以合并就是一次复制——接缝正好落在当初切开的位置，周围不会多出一段被重编过的画面。
-
手机每隔几分钟就停一次的那些片段
同一次录制里拍的片段，各项设置完全相同，哪怕跨了几天也能不重编就接上。竖屏和横屏混在一起才是这条规律失效的时候，而比对结果会在你花时间之前就告诉你。
-
给视频加片头或片尾卡
从幻灯片或设计工具导出的卡片，形状和帧率很少跟正片一致，而且通常没有声音。这两件事都有对应处理：卡片会被放进正片的画幅，同时按它的长度补上静音，声音不会因为片头而整体提前。
-
中途休息后接着录的采访或课程
因为中间去倒了杯咖啡而分成三段的录音录像，本来就是同一件事的三个文件。在本地合并对这类素材的意义不只是方便——采访、医疗记录和法律材料本来就不该出现在别人的服务器上，而合并期间什么都没离开标签页这件事，看一眼网络面板就能确认。
-
从不同来源凑一个合集
从各处下载或导出的片段，参数很少能一致，这也确实是必须重编的那种情况。比对结果会一开始就告诉你，而不是等一个小时之后；输出的画幅、帧率和缩放方式也由你来定，而不是替你猜。
-
剪掉中间一段之后再拼回去
把录像切成要留的几段、再把这几段接回来，是不动剪辑软件就删掉中间部分的常规做法。无损切出来的片段仍然能无损接回去，所以这一来一回一点代价都没有。
为什么合并视频通常没有代价，偶尔却代价不小
合并出来的视频不是把旧片段重录一遍，而是一条轨道要同时把所有片段都描述清楚。就这一条限制，解释了为什么有的合并只要几秒，有的却要一个小时。
-
一条轨道只写一份说明
MP4 里的视频轨会在开头一次性声明：用什么编码、多大画面、什么像素格式、转多少度。按另一份说明编码出来的数据包，没法归到这份说明底下。规则就这一条，下面几条全是从它推出来的。
-
所以参数一致的片段接起来没有代价
同一台相机的两个分段，是同一个编码器用同一套设置压出来的，一份说明就能同时管住两边。它们压缩好的数据包被搬进同一条轨道，全程没有解码。没有二次压缩，也就没有画质损失，花的时间就是写字节的时间。
-
而一段不一样就全体重编
一堆 1080p 里混进一个 720p，就没有哪一个画面尺寸能同时描述它们。唯一的出路是把每个片段都解码、缩放到同一个画幅，再整体编码成一个新视频。代价和那段有多不一样无关——只要有一处不匹配，整套都得重编。
-
帧率是个例外
MP4 和 Matroska 记的是每一帧各自的时长，而不是整条轨道一个统一时钟，所以 30 fps 和 60 fps 的片段通常可以待在同一条轨道里、各按各的节奏播。只有帧率不一致时，这个工具不会因此立刻重编，比对表也因此把它单独标出来；成品仍会核对总时长。
-
旋转是个标记，不是画面本身
手机横过来拍，存的其实还是一幅正常的横向画面，外加一条「请转过来」的标记。这条标记属于轨道，不属于片段，所以把正着拍的和转过来拍的接在一起，一条标记会同时作用于两者，结果就有一半是躺着播的。两个片段可以报出同样的画面尺寸却在这里不同——所以旋转是单独比的。
-
容器不是编码器
把输出从 MP4 换成 MKV 并不会重新编码任何东西，只是把同一批数据包写进另一层外壳。这一点在合并被拒绝直接拼接时很有用：MKV 几乎什么流都收，MP4 收不下的，它往往照收不误，而里面的画面两种情况下都没变过。
使用建议
一次就能拿到一个好文件的几个习惯。
- 按下任何按钮之前先看一眼比对结果——只要一秒，就能知道这是十秒钟的活儿还是一个小时的活儿
- 方式先放在自动，只有在播放器打不开合并结果、或者你确实需要另一个画面尺寸或编码格式时才去改
- 比对结果说参数一致时就别动输出格式，它默认就跟着片段自身的容器，而那正是能走复制的那一个
- 相机和行车记录仪的分段按文件名排，文件名是一串没人读得动的时间戳时按时间排
- 画幅或声音参数看着不对时先检查第一个片段：所有比对都以它为准，直接拼接出来的结果也继承它的参数
- 直接拼接失败就退到 MKV——它几乎什么流都收，往往能把一次被拒绝的复制重新变成复制
- 从原片开始合并，别从之前的合并或转换结果开始，因为每一次重编都是叠在上一次之上的
- 时间长、分辨率高的合并用电脑浏览器做，所有片段是同时压在内存里的，手机能给标签页的内存少得多
边界与注意事项
这个工具刻意不做的事，以及它力不从心的地方。
- 它只做「一段接一段」，别的都不做。片段之间没有转场、淡入淡出或叠化，也没有字幕、背景音乐和贴图——那些是剪辑的活儿，不是合并的活儿。
- 片段是整段接进去的。想先从某一段的开头切掉几秒，那是另一步，用下面链接里的另一个工具。
- 直接拼接是无损的，但只要重编就不是。H.264、VP8 这些都是有损格式，所以重编过的合并结果不管画质调多高，都比原片又远了一代。
- 每个片段只带走一条视频轨和一条音频轨。额外的语言音轨、字幕流和章节会被丢掉，这一点对带好几条音轨的 MKV 下载资源影响最大。
- 环绕声布局不一致的片段会被混缩成立体声，因为一条轨道只能记一种布局，而把立体声升成环绕声等于凭空造出从没录进去的声道。
- HEVC 片段参数一致时走复制拼接，不一致时会被重编成 H.264——本引擎读得了 HEVC 却写不了。所以一组参数不一致的 HEVC 片段，合并出来是 H.264 而不是 HEVC。
- AV1 是唯一一种彻底没法统一的编码。参数一致的 AV1 片段能走复制正常合并，因为那条路根本不解码；但参数不一致就必须解码，而本构建的 AV1 解码器需要 WebAssembly 够不着的硬件。这种情况会被直接拦下，而不是让你白等一场。
- 一次最多 20 个片段，而且所有片段连同结果都同时占着内存。WebAssembly 是 32 位的，所以不管几个片段，总大小超过四分之一 GB 左右就开始不稳。
- 重新编码是在 WebAssembly 里单线程跑的，所以比电脑上装的 FFmpeg 干同样的事慢。复制不受影响——那条路几乎不怎么用处理器。
- 引擎第一次用时大约 31 MB。之后会被缓存，但在全新的浏览器配置里第一次合并要承担这次下载。
- MKV 输出在这里没法预览，因为没有浏览器播它，但文件本身是正确生成的。下载下来用播放器打开即可。
- 缩略图是浏览器自己的解码器画的，所以浏览器本来就播不了的格式——MKV、AVI、WMV——只会显示一个占位图标。这不影响该片段被读取、比对和合并，和别的片段完全一样。
- 给静音片段补的静音，长度取自文件自己声明的时长，精度到百分之一秒。所以静音片段很多的一组，整体可能会有百分之几秒的偏差。
常见问题
几个片段要变成一个时，常会遇到的问题。
怎么把多个 MP4 合并成一个而不损失画质？
把片段加进来，方式保持自动，然后看一眼比对结果是不是说它们一致。一致的时候，合并是把压缩好的数据包直接搬进同一条轨道——全程不解码，所以没有画质可损失，也没有哪个设置能改变这一点。同一台相机或录制设备出来的片段，正常都是这个结果，几秒钟而不是几分钟。只有比对发现了真实差异、片段必须被统一到同一套参数时，才会有画质损失。
怎么把 GoPro 或行车记录仪的分段文件合成一个视频？
把整个文件夹一次拖进来，按一下「按文件名」，然后合并。运动相机和行车记录仪把一次录制切成编号文件，是因为文件系统的限制，画面本身没有任何变化，所以每一段的编码格式、画面尺寸和声音参数都一样——这正是直接拼接存在的意义。按人读的方式排序会把 GX010042 放在 GX020042 前面、clip2 放在 clip10 前面，所以点一下顺序通常就对了。
我的视频会被上传到什么地方吗？
不会。引擎是编译成 WebAssembly 的 FFmpeg，就在你的浏览器标签页里运行。每个片段从硬盘读进标签页的内存，合并结果再作为下载写回去。没有任何一段内容经过网络，合并的时候看一眼网络面板就能确认。
分辨率不一样的视频能合并吗？
能，但是有代价的。一条视频轨只能声明一个画面尺寸，所以分辨率混杂意味着每个片段都要解码、缩放到同一个画幅、再重新编码。画幅由你选——最大那段的、第一段的，或者一个预设值；形状不同的片段怎么放进去也由你定：补边、裁掉填满，或者拉伸。比对结果会在你决定花这个时间之前，先告诉你是哪一段不一样。
为什么合并出来的视频只播第一段？
这就是「片段其实没那么兼容，但做合并的那个工具当成兼容了」的典型症状——第一段的参数被写进轨道，后面的数据包对不上，播放器于是停住或者卡死。网上随手抄一条命令来合并文件，最经典的翻车就是这个。这个工具会先比对片段，做完之后又把成品读回来核对总时长，所以截断的合并会被报出来而不是交给你。要是看到那条提醒，把方式切到重新编码。
片段的播放顺序能改吗？
能。列表从上往下播，任何一行都可以拖到新位置，也可以用箭头按钮挪一格，还能按文件名或按每个文件的写入时间整体排序，倒序按钮则把整份列表翻过来。每一行都带缩略图，哪段在哪儿是看出来的，不用从文件名推；顺序在你按下合并之前一直都能改。
其中一段没有声音会怎么样？
会按那一段的长度补上等长的静音再接进去。这件事比听起来重要：不补的话，那一段完全不贡献音频，它后面每一段的声音都会提前开始——一个放在片头的标题卡就足以让整条声音轨错位。另外，有声音和没声音的片段混在一起，本身也会逼出一次重新编码，因为「有没有音轨」正是一条轨道要一次性声明的东西之一。
MOV 和 MP4 能合并到一起吗？
通常可以，而且往往不用重编。MOV 和 MP4 只是包着同样的 H.264 和 AAC 的两层不同外壳，所以关键不在扩展名，而在里面的流对不对得上——画面尺寸、像素格式、声音参数这些。比对就是直接查这些，容器本身不看。输出选 MP4 或 MOV，参数一致的话片段就会被原样复制进去。
最多能合并多少个视频、多大？
一次最多 20 个片段。真正的限制是内存而不是数量：所有片段连同成品都同时压在标签页里，而 WebAssembly 是 32 位的，总大小超过四分之一 GB 左右就开始不稳。走复制的话，总时长多少都很快，因为根本没有解码；走重编则和时长、分辨率成正比，而且是单线程跑的，所以又长又高清的一组要花实打实的时间。
片段之间能加转场或者淡入淡出吗？
不能。片段之间是硬切，一段接一段。加淡入淡出意味着即使参数完全一致也要把每个片段解码重编一遍，那正好把这个工具值得用的地方全丢掉了。需要转场的话，剪辑软件才是对的工具；只是想把片段接起来，这里做这件事没有代价。
为什么上次合并是瞬间完成，这次却很慢？
因为这是两种不同的活儿。一组参数一致的片段走的是复制，基本上只是在写字节。只要有一段不一样——分辨率不同、手机横过来拍的、一堆有声音的里混了一段没声音的——整组就得解码、统一参数、当成一个视频重新编码。比对面板会指出是哪一项、哪一段造成的，很多时候你可以去改输入，而不是为这次重编买单。
输出格式该选哪个？
多数情况下别动：输出默认跟随第一个片段本来的容器，而那正是保证能收下这些流、不用重编的那一个。要分享、上传或者拿到各种设备上播，就明确选 MP4；直接拼接被拒绝时选 MKV，它几乎什么流都收；目标是 Final Cut 或 QuickTime 就选 MOV；WebM 只在你确实需要网页上的开放格式时才选，因为它一定要付一次完整的重新编码。