一个 4GB 的录屏要发给客户，卡住的从来不是画质，是上传。等它传完的四十分钟里，你会有充足的时间思考：当初为什么要录 4K。
这时候多数人会搜「最好的视频压缩软件」。这个问题问错了。视频处理没有最好的工具，只有把四件不同的事分清楚之后，各归各位的工具。
1. 先分清四件事
转码是把编码换掉（H.264 换成 H.265），封装是把容器换掉（MKV 换成 MP4），切段是只保留某一段，压制是降低码率。四件事的计算量差了两个数量级，混在一起谈就会选错工具。
只换封装，几秒钟，不损失画质。只切段，也是几秒钟，前提是切点落在关键帧上。真正耗时的只有转码和压制。
另一个容易混的是容器和编码。MP4 是盒子，H.264 是里面的东西。把 MKV 改成 MP4 后缀名，播放器照样打不开，因为盒子没换，只是名字变了。
2. HandBrake：一次性的、要看着结果的活
HandBrake 是这四款里唯一把「预设」做成主界面的。它给你一排设备名，选完就能压。它的价值不是参数多，是把参数藏起来，让你不用懂也能出一个能看的文件。
适合的场景很具体：一个视频、要压、压完就发，之后不再碰。比如把手机拍的 200MB 素材压到 30MB 发微信，或者把课程录屏压到能上传平台的上限以下。
它的边界也在这里。批量队列有，但配置批量任务的体验一般；参数改动要一层层点开，改五个文件的不同参数会很想放弃。它不是给「每周处理四十个文件」的人准备的。
3. FFmpeg：要重复一百次的活
FFmpeg 不是软件，是一套命令行。它真正的价值不是功能多，是同一件事可以被写成一行、存进脚本、明天再跑一次结果一样。
ffmpeg -i input.mov -c:v libx265 -crf 24 -preset slow \
-c:a aac -b:a 128k -movflags +faststart output.mp4这一行的意思是：用 x265 编码，质量系数 24，慢速预设，音频转 AAC 128k，并把索引挪到文件头。最后那个参数决定了它在网页里是「点开就播」还是「先下载完再播」。
CRF 是恒定质量模式，18 到 23 之间是常用的视觉无损区间，数字越大文件越小、画质越差。同样 CRF 下，H.265 的文件通常比 H.264 小 30% 到 50%，代价是编码慢一倍以上，老设备可能解不动。
它不适合谁？不适合一个月只压一次视频的人，也不适合需要「先看一眼再决定」的人。命令行没有预览，参数写错要等半小时才知道。
4. ShanaEncoder：Windows 上批量加硬件编码
这款在国内用得多，原因很实际：Windows 原生、支持 NVIDIA 和 Intel 的硬件编码、队列直观、中文界面。它的定位是「把 FFmpeg 的能力装进一个能批量排队的窗口」。
硬件编码的取舍要写清楚。同一码率下，NVENC 的画质通常略逊于 x265 软编；要达到同样观感，文件往往大 10% 到 20%（这是通行经验值，具体看内容和代数）。换来的是速度：一段一小时的 1080p 素材，软编可能要四十分钟，硬编十分钟以内。
所以它的边界是：量大、时间紧、能接受一点体积损失。反过来，如果这批文件要长期存档，别用硬件编码省那半小时。
还有一件常被忽略的事：硬件编码的效果依赖显卡代数。同一张卡上的 NVENC，两代之间的画质差距可以大到让人以为换了软件。别人的「硬编够用」，是在他那张卡上成立的结论。
5. LosslessCut：根本不想重新编码的活
LosslessCut 只做一件事：在不重新编码的前提下切掉不要的部分。它切一刀是秒级完成，因为它根本没碰画面，只是把数据流按关键帧剪开再拼回去。
关键帧这三个字是它的全部限制。切点只能落在关键帧上，默认会自动吸附到最近的关键帧，所以切口可能和你拖的位置差半秒到两秒。想要帧级精确，就必须重新编码，那就不是它的活了。
典型用途：两小时的直播录像里挑三段各两分钟的片段。用转码工具处理，等于为了剪六分钟重算两小时；用它，三十秒。
| 维度 | HandBrake | FFmpeg | ShanaEncoder | LosslessCut |
|---|---|---|---|---|
| 操作方式 | 图形界面 | 命令行 | 图形界面 | 图形界面 |
| 批量能力 | 弱 | 靠脚本 | 强，队列 | 弱 |
| 硬件编码 | 支持 | 支持，需指定 | 支持，默认引导 | 不涉及 |
| 是否重编码 | 是 | 可选 | 是 | 否 |
| 可复现性 | 低 | 高 | 中 | 不适用 |
| 上手成本 | 低 | 高 | 中 | 低 |
6. 三套组合，各管一类人
组合一：一个月压两三个视频。只用 HandBrake。选一个接近的预设，改一下质量滑块，压完看一遍。不要为了这点量去学命令行，学习成本永远收不回来。
组合二：每周几十个文件，要统一规格。ShanaEncoder 排队压，配一个 FFmpeg 写的校验脚本，压完统一跑一遍，检查时长、分辨率、码率对不对。这一步不能省，批量任务的错误总是整批的。
组合三：长素材只取片段。LosslessCut 先切出需要的段，再交给 HandBrake 或 FFmpeg 压那一小段。顺序反过来会浪费几个小时，这是最常见的浪费。
7. 选错了的三个信号
信号一：你在命令行里反复改一个数字，只为看看效果。这说明你需要的是能预览的界面，不是脚本。切回 HandBrake，用它的预览窗口。
信号二：你在图形界面里一个一个拖文件，已经拖了二十分钟。这说明你需要队列或者脚本。数量超过十个，手动操作的出错率就开始上升。
信号三：你为了剪掉片头，把三小时的素材重新压了一遍。这说明你把「切段」当成了「转码」。切段不需要重编码，重编码是最贵的那条路。
还有第四个不那么明显：你为了省 200MB，把 CRF 从 23 调到 30，客户回来说「字看不清」。压缩比的账要按用途算，不是按体积算——发给客户看的演示，清晰度是交付物的一部分。
写在最后
这四个工具的关系，不是替代，是分层。LosslessCut 处理「要不要这一段」，HandBrake 处理「这个文件能不能发出去」，FFmpeg 处理「这件事能不能重复」，ShanaEncoder 处理「这四十个文件今晚要跑完」。
大部分人真正需要的只有一个：先想清楚这次是切、是压、还是转。想清楚之后，工具的选择几乎没有悬念。
反过来，先下载四个软件挨个试，最后往往是用最熟的那个干所有活。熟练度会伪装成适用性，这是工具选择里最贵的错觉。
你上一次压视频，是为了发出去，还是为了存起来？这两个目的选的参数其实不一样。
评论 (0)