这是我7年前在某乎上提出的问题。7年后的今天，终于能给出一个相对完整的答案。

    篇幅有些长，主要涉及对编码流程的讲解以及纠正一些常见误区。等不及分析的可以直接拖到后面看结论，但我还是建议有时间可以看完。

    TL;DR “压制”软件的核心都是相同的固定的几种，各路“压制”软件实质就是给固定几种命令行工具套个带界面的“壳子”。区别无非对应的版本新旧，参数可定义程度，用得是否顺手罢了。推荐软件在全文最后。

    在回答用什么软件“压制”之前，我想问一下各位，所谓的“压制”，到底是什么？

    压制这个词乍看上去就是“压缩体积”，很多人的目标也是单纯为了“压缩体积”。但实际上，如果用一个影视界常见的名词来形容，我们常说的“压制”其实更像是完整的音视频后期处理过程。

    具体来说，整个流程大致分为以下几步：

音视频分离与解码

视频画面处理（音频一般不做处理）

音视频重编码（这也是最接近“压制”这个词本身的一步）

音视频重封装（以及加入章节信息等）

    那么我们一个一个说。

    首先解释第一条，这里就要引出封装和编码的概念。

    我们常看到的 MOV MP4 FLV MKV 这些后缀，叫做封装格式。他们相当于一个盒子，是音轨视频轨字幕轨等等的外包装。无论是播放器进行播放，还是我们进行处理，所需的第一步就是把盒子拆开，拿到单独的音频视频字幕等轨道，才能进行下一步操作。

    同时，分离出来的视频、音频轨，往往是经过编码的数据，简单来说，就是所谓“压缩”过的数据。那么视频是怎么“压缩”的呢？

    视频编码有两个维度。从信号处理的角度，叫时间维度和空间维度。但是用人话来说，就是单帧画面和多帧组成的序列。对应就叫帧内编码和帧间编码。

    首先先说单帧的帧内编码。显然，视频里一帧就是一张图片。

    相信你应该听说过将 bmp / tiff 压缩为 jpg / png / webp 等等的有损或无损的图像压缩算法，而所谓帧内编码，就是在对视频每一帧做图像压缩。也就是说，压缩的参考对象范围只有当前帧的画面。

    帧内编码的好处是编解码运算量小，缺点则是由于需要每帧编码一次，所以体积相比 RAW 视频（可以理解为未经压缩的原始图像序列）并不会小很多。常见的 ProRes 格式，就是因为其采用帧内编码的特点，非常便于非编软件（i.e. 剪辑、特效、调色……）进行流畅地编辑，而流行起来。

    帧间编码就要复杂一些，因为它参考的是多帧画面的组合，记录的是运动趋势。再说简单点，就是在关键帧之间记录变化。

    比如说，对于“车辆在树木和楼房前驶过”这个场景。显然树木和楼房在车辆的整个行驶过程中几乎没有变化。那么这个区间大可以只在关键帧保留树木和楼房。而中间帧保留车辆位置与运动信息。这样就可以减少每一帧几乎不变的树木、楼房占用的体积。

    因此，不难看出，帧间编码可以在保证画面影响不大的情况下，大幅削减中间帧的体积；而缺点在于解码压力相对帧内更大。此外，一旦关键帧损坏或丢失，那么参考这一帧的中间帧也会无法正常查看。这是看到“花屏”的常见原因之一。

    当然了，不同压缩算法，采用的具体策略各不相同。比如，帧间编码算法往往会采用两种编码方式的组合。这也可以解释为什么你无法通过通用的文件压缩算法对编码后的视频减少体积，因为压缩时已经进行过这样的操作了。

    我们这里说的音频（重）编码，是对数字形式的音频信号的二次处理。与帧间编码为主的视频流不同，音频可以做到无损压缩的同时降低较多体积。

    音频编码的选择受到封装的限制。比如：典型的 MP4 封装要求采用 AAC 编码。由于这是一种有损编码，在声源非 AAC 格式的时候，就必须进行有损失的重编码操作。而常见的如“为 Web 源视频添加‘硬’字幕”的场景中，由于源音轨同样为 AAC 格式，因此压制时就可以不对音轨进行处理，直接原封不动跟处理后视频封装即可。

    可以说，让所谓“压制”打上引号，即不等同于单纯重编码或者减小体积的原因，正是因为发布组或者字幕组的“压制”流程往往伴随着画面的处理。

    与影视行业后期不同，就笔者的经验来看，字幕组/压制组的这一流程，通常不涉及复杂特效。

    这里首先解释“滤镜”的概念。和非编软件（i.e. 非线性编辑，比如视频剪辑/特效/调色软件，与之相对是传统的物理胶片剪辑）一样，在处理过程中，习惯性把各个处理器称为“滤镜”。比如，一开始的读取、解码视频流就是“源滤镜”的工作，其作用就是把编码后的视频还原为可供处理的原始图像序列。此外，常见的还有视频黑边的去除（裁剪）、画面分辨率缩放（超分/降采样）、对隔行扫描片源的反交错或反胶卷过带、以及为原视频加上硬字幕（字幕滤镜）等等。

    复杂一点，比如常在非编软件中出现的降噪、锐化、调色等，包括现在流行甚至大有滥用之势的补帧、AI修复等等，只要有相关插件支持，都可以出现在这个流程中。

    这里值得强调的地方，就是“画面瑕疵类型的识别和相应对策”。尤其在以相对规律的二维手绘动画片源的场景，针对性的修复往往可以获得较好的观感提升。目前比较直观且便于参考的就是 VCB 组长 LP 在 16 年亲自撰写的一篇文章：[VCB-Studio 科普教程 6] 动漫视频常见的瑕疵/缺陷介绍 （https://vcb-s.com/archives/4738）。

如果说，“压制”的核心是视频的画面处理，那么识别出画面的缺陷并进行合适的处理（i.e. 选择合适的滤镜并赋予合适的参数），可以说就是核心中的核心，乃至视频修复/增强这一图形学领域的核心。

最后提一下在“压制”环节，字幕组常见的画面处理的工具。目前最常见的方式，就是通过脚本与对应的解析器实现。其最大的优势就是可以通过编写和运行脚本的方式进行滤镜逐级调用，从而实现直观简洁的视频处理，不需动用 AE / PR / 达芬奇这类臃肿的非编软件。

常用的脚本解析器（或者说视频处理框架）有两种，其一是 AviSynth（AVS）；其二是VapourSynth（VS）。前者由于无法利用 CPU 多核心等原因，逐渐被后者取代。

无论是非编软件还是上述脚本解析器，最终成片都要进行重编码。作为一个压制者，到了这里基本只需要确定两件事：（1）选择什么编码（2）选择这种编码方式的哪种实现

选择编码，就是 2.2 中说的，根据你的目标封装格式、目标设备选择，比如常见的 AVC HEVC 或者影视圈常见的 ProRes 等等。我想着重说说第二条，也就是同样编码方式的不同实现的问题。

最简单的例子，就是 GPU 跟 CPU 编码 AVC / HEVC 的区别。这一点，其实就是所谓的“开启硬件加速”。利用显卡的专用编码电路实现转码效率的大幅提高。不过显而易见，肯通过（3）的方式二次处理片源，通常意味着对画质更高的追求，所以一般对于非赶时间、或者视频网站发布的片源，会优先选择速度较慢，但编码效率更高（i.e. 相同质量体积更低/相同体积质量更高）的 CPU 编码。

另外，除了编码硬件的区别，同样硬件下，不同编码器的实现依然有所不同。比如 CPU 编码的 x265 有 Yuuki 跟 Asuna 的版本；同样是 N 卡编码的 NvEnc，日本 rigaya 大佬的实现就要比 Handbreak 默认集成的版本以及 Adobe Media Encoder 的口碑好很多。

    那么我们在 2.3 中拿到了处理后（或者保持原样）的音频流，在 4 中拿到了处理完并重新编码过后的视频流，最终要做的就是像打包快递一样，通过封装工具给他们重新包回去。最简单的方法就是通过通用工具—— ffmpeg 的一行命令。不过你当然可以选择各个格式特定的工具，比如 mp4box 、mkvtoolnix 操作。除了基本的音视频流之外，诸如封装外挂字幕、字体等等，可以根据封装格式的说明自行操作，这里就不再赘述了。

    至此，整个“压制”的完整流程就结束了。

    我们从头开始理顺一下。

    还记得刚才说到的完整流程吗？没关系，我再给大家写一遍。

    首先是第一步，从封装好的视频中将音视频分离，得到单独的视频、音频文件。

    接下来，对视频轨道进行解码和处理，处理后再次重编码。

    再对音频轨道进行处理，通常只进行重编码或者保持不变。

    最终，将处理后的音视频轨道，以及其他需要附加的内容如字幕等重新封装，从而得到最终处理好的新文件。

    如果你完整看到了这里，首先恭喜你，因为无论是否完全理解，至少你已经对整个流程有了一个相对直观的印象。那么，回到我们最开始的问题——究竟该怎么选择软件呢？

    我们一步步来说。

    首先，封装的拆与装，通常可以采用同一软件。也就是在 5 中提到的，类似 ffmpeg 这样的通用工具，以及 mp4box 、mkvtoolnix 这类封装的特化工具。

    接下来，就是我在 3 中提到，视频的解码和处理，目前习惯性通过两款脚本解析器（或者说处理框架）实现—— AviSynth、VapourSynth。当然，除了本体之外，你可能还需要额外安装一些所需的滤镜，不过这就不是这篇基础教程涉及的内容了。你当然也可以把 AE 这种大家伙算在这里，因为确实有些神组用 AE 加字幕效果的。

    在切入视频编码器之前，上述处理器和编码器之间可能需要一些中介作用的工具。比如 VS 脚本需要 vspipe （自带），Adobe 全家桶想要解锁高级编码设置需要额外安装的 Media Encoder 或者帧服务器类软件。

    那么就是视频编码器了，x264.exe 也好，nvenc.exe 也好，在 4 之中说得差不多了，细节的问题交给搜索引擎就好了。

    音频编码器其实和视频编码器一样，也是先选编码，再根据编码选不同的实现。比如，AAC 格式口碑比较好的编码器是苹果家的 qaac 。

    大概就这么几种。

    说到这里有人就会感到奇怪，为什么我看到别人推荐什么 MeGUI、小丸工具箱、格式工厂、Handbreak、MediaCoder 这些软件呢？他们和前面说的这一大堆有什么区别呢？

    回到我在文章最前面加粗的结论：“压制”软件的核心都是相同的固定的几种，各路“压制”软件实质就是给固定几种命令行工具套个带界面的“壳子”。区别无非对应的版本新旧，参数可定义程度，用得是否顺手罢了。

    什么意思呢，如果你感兴趣观察一下上面几款软件的输出日志，你会发现密密麻麻如同命令行显示的内容。其实，这就是背后的命令行工具的执行结果。也就是说，他们的本质就是为这些工具提供了一个漂亮或者不漂亮的输入输出界面，而背后运行的还是刚才说的封装、编码、处理流程中的各个工具。

    单纯使用命令行工具看着酷炫，但对于业余用户确实是不够友好。此外，因为涉及多种工具的组合，还有中间文件、临时文件的清理等等问题，修改参数也比较麻烦，这便催生了上面说的这些带界面的一键化工具。从而实现了“无脑”一键压制。

    因此就是我结论中最后一句，选择这类壳子的标准就是“整合了什么工具以及什么版本”、“是否方便美观”，以及自定义的参数是否全面等等。

    我们可以刨析一下经典的几个壳子：

    格式工厂因为支持调整的参数与编码器过少，导致输出效果达不到预期，所以并不推荐。

    MeGUI 与小丸工具箱，整合工具比较多，整体使用比较方便，特别是一键生成 AVS 脚本。不过考虑到 AVS 不支持多核优化，所以不建议在简单处理上使用。

    MediaCoder 自定义参数过多，有些让人不知所措，但也确实可以考虑。

    等等。

    罗列完可以看出，上述软件优缺点都不少。这也是后来我们很多人自己去造壳子的原因。但无论如何，最好的方案永远是了解这套流程的原理，虽然不求了解图形学、信号处理这类过于底层的知识，但最起码要知道这些壳子下面跑的基础软件是什么，该如何使用。

    对于有一定追求的玩家来说，既然壳子下面都是命令，那干脆直接把命令整合一下运行：压制组手里总要有那么几个现成的 bat 或者 sh，甚至自己写壳子。这就是用什么压制的终极结论。

ffmpeg - 音视频界瑞士军刀，无数播放器的底层。编解码分析甚至一些基础滤镜齐全。不追求效果其他都可以不装。只不过没界面。

rigaya编写的编码器 - 特别是N卡用的nvenc，目前最推荐的nvenc x264编码器。

https://github.com/rigaya

VapourSynth Editor 2 - VS脚本浏览必备工具

https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/

Visual Studio Code - 轻量化检查脚本的问题，编辑命令行代码和脚本的免费工具

非要我推荐一个壳子的话，推荐一下 @HoshinoKun_困 写的，NvEnc + ffmpeg 光速压字幕传 B 站神器。

https://github.com/hoshinohikari/StarTools/blob/master/README_CN.md

    7年时间，从当时那个只会用Pr剪电子相册的高中生到如今软件工程本科毕业，方向还就是视频处理；一路上遇到了太多予以帮助和支持的小伙伴，想想都觉得有些不可思议。现在已经在新的领域开始摸索。不知道7年之后的我，会如何看待现在的自己呢？

    以上。