日常处理视频，八成需求落在四件事上：换个能播的格式、把几段拼成一段、把冗长的录屏加速、从里面抽一张封面图。它们看起来都是「点几下就完事」，但耗时能差出上百倍——有的几秒钟结束，有的要等十几分钟。差别的根源在于是否需要重新编码画面。把这条线索抓住，参数怎么设、什么时候会失败，就都能推出来。
一、mp4 只是个盒子：容器与编码的区别
这是最值钱的一个概念，理清它能省掉一半的困惑。
容器是文件的外壳，规定「一个文件里怎么摆放视频轨、音频轨、字幕轨和时间索引」。常见的有 MP4、MOV、MKV、WebM、AVI，文件扩展名说的就是容器。
编码是轨道里数据本身的压缩方式。视频侧常见的是 H.264（也写作 AVC）、H.265（HEVC）、VP9、AV1；音频侧是 AAC、MP3、Opus、Vorbis。
所以「MP4 格式的视频」这句话严格说没说清任何事——同一个 MP4 里可能装着 H.264，也可能装着 H.265，前者几乎所有设备都能播，后者在老设备上一片黑屏。这也解释了两个常见现象：
- 明明是 MP4，某台电视就是播不出来。 容器对了，编码不对。真正需要做的是把视频流转成 H.264，而不是反复改扩展名。
- 改扩展名有时候好像「管用」。 那是因为播放器本来就靠嗅探文件头识别容器，改名根本没改变文件内容，播得出来说明它原本就能播。改名不是转换，遇到真正的编码不兼容时一定会露馅。
顺着这条线看：只换容器不换编码，可以流复制，很快；换编码，就必须解码再压一遍，慢，而且有损。
二、格式转换：参数按「投放目标」倒推
视频格式转换 提供质量预设、分辨率、视频码率、帧率、音频质量几组参数。与其逐个纠结，不如从「这个文件最终在哪播」倒推。
- 分辨率：可选保持原始，或降到 1080p、720p、480p、360p。原则是只降不升。把 720p 拉到 1080p，编码器只是在插值放大，画面细节一点没多，码率需求却涨了一倍多，纯浪费。手机上看的内容，720p 通常和 1080p 肉眼无差。
- 视频码率：8000 / 5000 / 2500 / 1000 kbps 几档，也可以交给自动。码率要和分辨率匹配才有意义——给 360p 配 8000kbps，多出来的比特没有画面细节可承载；给 1080p 只配 1000kbps，运动镜头会糊成一片马赛克。参考量级是：1080p 用 5000kbps、720p 用 2500kbps、480p 用 1000kbps 属于稳妥选择。
- 帧率：可保持原始，或指定 60 / 30 / 25 / 24。降帧率能省不少体积，但不要随手改成非整数倍的值。60 降到 30 是整齐的隔帧丢弃，观感干净；60 降到 25 需要不均匀地丢帧，画面会出现细微的一顿一顿。没有明确需求就保持原始帧率。
- 音频质量：320 / 128 / 64 kbps 三档加「无音频」。纯讲解类内容 128kbps 足够，带音乐的选 320kbps。
三、多段合并：极速模式成立的三个条件
视频合并拼接 提供两种模式，理解它们的差别能直接决定你是等 5 秒还是等 5 分钟。
- 极速模式：直接把各段的原始数据流首尾相接，完全不重新编码，几秒就能完成，画质与原片一致。但它要求所有片段的视频编码、分辨率、帧率完全一致——因为拼出来的文件只有一套流参数，播放器会用第一段的参数去解后面所有段，参数不匹配就是花屏、卡死或者干脆解不出来。同一台设备连续录制、被自动分段的视频（行车记录仪、会议录制、手机长视频分片）通常天然满足这个条件。
- 兼容模式：先把所有片段统一成你指定的目标分辨率和帧率，再重新编码合并。任何来源都能拼，代价是耗时与总时长和分辨率成正比，几段高清素材等十几分钟很正常。
实操建议是先试极速模式，失败了再切兼容模式，别一上来就选兼容浪费时间。
还有一个专门要提的坑：如果某个片段没有音轨，务必取消勾选音轨处理，否则合并会失败。原因是合并流程会尝试为每一段映射音频流，某段根本没有音频流可映射时整条命令直接报错。混合了「有声片段」和「无声片段」是最容易翻车的组合，遇到时先用工具确认每段是否都有声音。
四、变速与倒放：音调是怎么保住的
视频倍速与倒放 里最容易被误解的是音频。很多人的经验是「加速视频会变成花栗鼠音」，这里不会，原因在于用了两种不同的处理方式。
画面侧改的是每帧的显示时间戳：把时间戳除以倍速，等于让同样的帧在更短的时间里放完，帧本身不变。
音频侧如果照搬这个思路——直接按比例重采样——那么波形被压缩，频率随之升高，就是经典的变声。所以音频走的是变速不变调的算法（atempo），它把波形切成小片段做重叠拼接，删掉或复制片段来改变总长度，而单个片段内部的波形周期保持原样，音调因此不变。
这里有个实现层面的限制值得知道：这类算法单次只能可靠处理 0.5 到 2 倍的范围，超出范围要串联多次。所以 4 倍速实际上是「2 倍再 2 倍」，0.25 倍是「0.5 倍再 0.5 倍」。串联次数越多，重叠拼接引入的轻微金属感和回声感越明显。想要 8 倍速这种极端加速，通常不如干脆去掉音频。
倒放要单独对待。 倒放不能流式处理——要输出最后一帧，必须先知道最后一帧在哪，也就得把整段视频读进内存再逆序重排。这让内存占用与视频时长成正比，长视频极容易耗尽浏览器给单页的内存额度，直接崩掉。实际建议是只对一分钟以内的短片使用倒放；需要给长视频做倒放效果，先剪出要用的那几秒再处理。
变速和倒放都必须重编码，处理时间与时长、分辨率成正比。工具用的是速度优先的编码预设，配合可调的画质档位，日常够用；但它毕竟跑在浏览器里的 WebAssembly 引擎上，比装在系统里的原生工具慢一截，长视频请留足时间，中途不要切走标签页导致页面被浏览器降频。
五、抽封面：这个操作可以很快
视频封面截帧 是这组工具里的异类：它不使用 WebAssembly 处理引擎，而是直接借用浏览器自带的视频解码能力——把视频跳转到目标时刻，再把当前画面画到画布上导出图片。
好处很明显：不用下载几十兆的引擎，定位到哪一帧就导出哪一帧，几乎瞬时完成，还能按固定间隔批量截取多张打包成 ZIP。
代价同样明显：它只能处理浏览器本身能播放的格式。MP4、WebM、MOV 这类没问题；MKV、AVI 这些浏览器不解的容器打开就是一片空白，需要先用视频格式转换转成 MP4 再来截图。
导出格式上，PNG 是无损的，适合画面里有文字、UI 界面这类需要边缘锐利的内容；JPEG 体积小得多，适合实拍画面。作为视频封面上传时优先选 JPEG 并把质量给到 0.9 左右，肉眼看不出差别，体积只有 PNG 的几分之一。
常见问题
转换后文件反而变大了，是不是搞错了？
很可能没错。如果源文件本来是高效编码（比如 H.265）且码率压得很低，你转成 H.264 并给了更高的码率，体积上涨是必然的。同理，从有损编码转向更宽松的参数也会变大。想减小体积应该明确地降码率或降分辨率，而不是指望「换个格式就会变小」。
能不能只换容器、不重新编码，速度快一点？
视频格式转换是按「重新编码到目标参数」设计的，不提供纯换壳的流复制选项。真正能吃到流复制好处的是两个场景：视频去音轨保持原容器时对画面做流复制，以及视频合并的极速模式。如果你的目标只是让某个播放器认这个文件，先确认它到底是容器不认还是编码不认，后者换壳也没用。
合并后的视频前半段正常，后半段没声音，为什么？
典型的音轨参数不一致。极速模式下播放器沿用第一段的音频参数去解后面的段，采样率或声道数不同就可能解不出声音，而画面因为视频参数恰好一致所以正常。解决办法是改用兼容模式重新合并，让所有片段被统一成同一套参数。
处理一个 20 分钟的 1080p 视频大概要多久？
没法给准数，取决于你的 CPU、浏览器版本和其他程序占用情况，但可以给个量级：需要重编码的操作，通常比视频本身时长还要久，10 到 30 分钟都属于正常范围。缩短等待的实际办法是先降分辨率——编码耗时大致与像素总数成正比，1080p 降到 720p，工作量少一半以上。